开云体育

ctrl + shift + ? for shortcuts
© 2025 开云体育

Whats the best way to transfer dasd from z/os to Hercules


 

I looked at the code in CCKDDU64 and just prior to every branch to the user abend 99 code, there is a #MSG message macro that will print a single line explaining why the program is abending.? This message should be written to the SYSPRINT DD dataset.? Unfortunately, whomever decided to write this code chose to use PUT-Locate for the writes to SYSPRINT.?? This is a problem in the abend case because the line won't be written until either (a) another PUT is issued (which there is not), or (B), a CLOSE macro is issued against the SYSPRINT DCB before the ABEND macro.
?
If the program did not force an abend, then the message would be written properly.? This message could provide a clue on why it is failing for a 3390-54.?
?
The easiest solution is to add a CLOSE (prdcb) statement just prior to the ABEND 99,DUMP macro, so it would go from this:
?
abend?? ABEND 99,DUMP
?
to this:
?
abend?? EQU *
???????????? CLOSE (prdcb)
???????????? ABEND 99,DUMP
?
The CLOSE macro will alter registers 14-1 before the dump is taken, which isnt ideal in most cases, but right now the priority is to get the error message text.? After that, one could examine the older U0099 dump without the CLOSE.? Alternately, the message buffer should be in the dumps you already have.? But finding it means following a trail of control blocks and it wont be easy.
?
Longer term, the PUT-Locate method and logic for handling SYSPRINT should probably changed to use PUT-Move (MACRF=PM) and this lack-of-message-on-abend issue will go away. Even better, just use a WTO macro to display it on the console and job log.
?
When I last used CCKDDUMP in approximately 2014, I used it against a 3390-54 volume, but that volume was not full and the resulting cckd dasd image was a little over 3 GB in size.? CCKDDU64 did not exist at the time.? However, in order to get CCKDDUMP to work at all, I had to modify the SYSUT2 DCB in the code to add a DCBE macro, and the DCBE needed to specify BLOCKTOKENSIZE=LARGE.?? However, I see now that in the current version of CCKDDUMP and CCKDDU64, this DCBE parameter is now coded in the source.
?
Regards,
Bob


 

It works fine for 3390-3, 3390-9 and 3390-27.? It fails for 3390-54, and I don't have anything in between to see exactly where it breaks.
?
The site with the smaller 3390-54 tracks is because that's what they chose when they installed their array.? They probably multiplied wrong, but in any case CCKDDU64 does work with the volumes I tested above, just not the 3390-54 ones.?
?
Hopefully someone has a solution for fixing this for larger drives.? If so, I'm willing to test it for them.
?
Brian


 

SUGGESTION?

Standard stupid-simple basic debugging:

Sprinkle as many additional detailed "#MSG" macro calls after the last one that was successfully issued ("file SYSUT2 opened for output") in the CCKDDU64 source code itself, and then re-assemble and re-link the CCKDDU64 program, and give it another try!

We have simply GOT to determine WHERE things went wrong.

We have simply GOT to determine where Brian's USER=99 abend is occurring, and WHY it is occurring.

Guessing will get us nowhere, and is a big waste of time.

Let's get to the root of the problem.

Let's fix the bug in CCKDDU64.

Or am I crazy.

--
"Fish" (David B. Trout)
Software Development Laboratories

mail: fish@...


 

For what it's worth, it does get the number of cylinders right on my system:

cckddump 0.3.1 starting????????????????????????????????????????????????????

main workarea is at address 0x24b36000, 24-bit workarea is at address 0x7000

MVS1OP vtoc opened?????????????????????????????????????????????????????????

MVS1OP has 65520 cyls, 15 trks/cyl and 982800 total trks???????????????????

MVS1OP vtoc has 1450 total dscbs???????????????????????????????????????????

storage obtained for vtoc area, addr 0x24b39000 size 203000????????????????

reading MVS1OP vtoc????????????????????????????????????????????????????????

MVS1OP vtoc closed?????????????????????????????????????????????????????????

624 datasets are on MVS1OP?????????????????????????????????????????????????

storage obtained for dsn area, addr 0x24b6b000 size 47652??????????????????

storage obtained for trk vector, addr 0x24b77000 size 3931200??????????????

storage released for vtoc area, addr 0x24b39000 size 203000????????????????

716524 tracks out of 982800 will be dumped?????????????????????????????????

storage obtained for MVS1OP i/o area, addr 0x9000 size 852480??????????????

storage obtained for compression, addr 0x24b39000 size 57344???????????????

persistent c environment created, handle=0x24b37ee8????????????????????????

file SYSUT2 opened for output????????????????????????? ? ? ? ? ? ? ? ? ? ??


On Fri, Jan 17, 2025 at 2:31?AM Tom Brennan via <tom=[email protected]> wrote:
A few years ago I wrote some scripts to produce CLI commands that define
disks in a DS8000.? Customer asked for some unusual sizes, such as:

mkckdvol -dev ibm.2107-75XXX11 -extpool P1 -cap 60102 0100-0113
mkckdvol -dev ibm.2107-75XXX11 -extpool P1 -cap 30051 0114-0147

So like Mike mentioned, you can basically set the number of cylinders to
whatever you want, up to the max.

After ICKDSF init, the number of cylinders is stored in the VTOC type 4
record (DS4DEVSZ) so z/OS can easily get to it.? I assume ICKDSF does
some kind of sense CCW to ask the hardware what the actual number is.

So do we call that 60102 guy a mod-54?? I guess so.? Internally it might
still be called a mod-9 though.? I seem to remember bits for that somewhere.

On 1/16/2025 10:17 PM, Fish Fish via wrote:
> What model dasd of dasd has 60102 cylinders?!
>
> A 3390-54 is supposed to have 65520 cylinders!
>







--
Jay Maynard


 

A few years ago I wrote some scripts to produce CLI commands that define disks in a DS8000. Customer asked for some unusual sizes, such as:

mkckdvol -dev ibm.2107-75XXX11 -extpool P1 -cap 60102 0100-0113
mkckdvol -dev ibm.2107-75XXX11 -extpool P1 -cap 30051 0114-0147

So like Mike mentioned, you can basically set the number of cylinders to whatever you want, up to the max.

After ICKDSF init, the number of cylinders is stored in the VTOC type 4 record (DS4DEVSZ) so z/OS can easily get to it. I assume ICKDSF does some kind of sense CCW to ask the hardware what the actual number is.

So do we call that 60102 guy a mod-54? I guess so. Internally it might still be called a mod-9 though. I seem to remember bits for that somewhere.

On 1/16/2025 10:17 PM, Fish Fish via groups.io wrote:
What model dasd of dasd has 60102 cylinders?!
A 3390-54 is supposed to have 65520 cylinders!


 

We don't know how the Cylinder field is filled. If a LH from a 2 bytes
field was used, it would sign extend the high order bit of x'1' from
32K+1 to 64K.

On Fri, Jan 17, 2025 at 1:54?AM Mike Schwab via groups.io
<Mike.A.Schwab@...> wrote:

The Multiply uses the register as a signed field. Is there a Multiply Logical?

non eav have Count records with x'CCCCHHHHRR'
3390s EAV have Count records with x'ccccCCChRR' where the actual
Cylinder number is CCCcccc and the head value is the x'h'.

On Fri, Jan 17, 2025 at 1:03?AM Fish Fish via groups.io
<david.b.trout@...> wrote:

Mike Schwab wrote:

Is the number of cylinders 2 bytes signed?
According to what I'm seeing in the source code for the CCKDDU64 program (one of the files in Herc's "cckddump-cckdload.zip" file in the 'util' subdirectory), it's actually a 4-byte fullword field within the data returned by the "DEVTYPE" macro (which I know nothing about! I'm *not* a z/OS programmer!), which I'm guessing is being used to retrieve the source device's (source volume's) dasd geometry and other information.

But what concerns and confuses me is that it's not using a DSECT to access the individual fields in the returned data, and is instead using a simple hard coded EQUate (which *appears* to be WRONG, which is what's confusing me!).

According to what I am seeing on IBM's web site:

*

*


====================================================================
THE FOLLOWING SECTION IS RETURNED BY DEVTYPE FOR INFO=DASD.
====================================================================

0 (0) STRUCTURE 16 DVAIDASD
0 (0) UNSIGNED 4 DVAICYL NUMBER OF CYLINDERS
4 (4) UNSIGNED 4 DVAITRK TRACKS PER CYLINDER
8 (8) UNSIGNED 1 DVAIFLAG FLAGS


But what I'm seeing in CCKDDU64 is:

*/* ----------------------------------------------------------------
* * get device information for sysut1 [the volume to be dumped]
* * ---------------------------------------------------------------- */

MVC devtl,model_devtl
DEVTYPE =CL8'SYSUT1',(devta,L'devta), x
INFOLIST=devt_infol_2,MF=(E,devtl)
LTR rf,rf
BNZ ut1_devt_err
TM devta+2,UCB3DACC check for dasd device
BNO ut1_not_dasd
TM dev_flags,X'80' check for eckd
BNO ut1_not_eckd
L r3,cyls
M r2,trks_per_cyl total number of trks
ST r3,trks


Notice it's loading the number of cylinders into R3 from the "cyls" field, which is defined as:

devta DS XL(32)

cyls EQU devta+4,4
trks_per_cyl EQU devta+8,4
dev_flags EQU devta+12,2


Offset 4 for a length of 4! Which is wrong! (At least according to IBM's DSECT anyway!)

Maybe this explains the incorrect number of cylinders being reported by CCKDDU64 that Brian reported in his post?

Methinks something is awry somewhere! :(

I'm actually quite surprised that Brian reports it *seems* to work just fine for 3390-3, 3390-9 and 3390-27! (Really?!)

%-(

<me: confused!>

--
"Fish" (David B. Trout)
Software Development Laboratories

mail: fish@...









--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?





--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?


 

The Multiply uses the register as a signed field. Is there a Multiply Logical?

non eav have Count records with x'CCCCHHHHRR'
3390s EAV have Count records with x'ccccCCChRR' where the actual
Cylinder number is CCCcccc and the head value is the x'h'.

On Fri, Jan 17, 2025 at 1:03?AM Fish Fish via groups.io
<david.b.trout@...> wrote:

Mike Schwab wrote:

Is the number of cylinders 2 bytes signed?
According to what I'm seeing in the source code for the CCKDDU64 program (one of the files in Herc's "cckddump-cckdload.zip" file in the 'util' subdirectory), it's actually a 4-byte fullword field within the data returned by the "DEVTYPE" macro (which I know nothing about! I'm *not* a z/OS programmer!), which I'm guessing is being used to retrieve the source device's (source volume's) dasd geometry and other information.

But what concerns and confuses me is that it's not using a DSECT to access the individual fields in the returned data, and is instead using a simple hard coded EQUate (which *appears* to be WRONG, which is what's confusing me!).

According to what I am seeing on IBM's web site:

*

*


====================================================================
THE FOLLOWING SECTION IS RETURNED BY DEVTYPE FOR INFO=DASD.
====================================================================

0 (0) STRUCTURE 16 DVAIDASD
0 (0) UNSIGNED 4 DVAICYL NUMBER OF CYLINDERS
4 (4) UNSIGNED 4 DVAITRK TRACKS PER CYLINDER
8 (8) UNSIGNED 1 DVAIFLAG FLAGS


But what I'm seeing in CCKDDU64 is:

*/* ----------------------------------------------------------------
* * get device information for sysut1 [the volume to be dumped]
* * ---------------------------------------------------------------- */

MVC devtl,model_devtl
DEVTYPE =CL8'SYSUT1',(devta,L'devta), x
INFOLIST=devt_infol_2,MF=(E,devtl)
LTR rf,rf
BNZ ut1_devt_err
TM devta+2,UCB3DACC check for dasd device
BNO ut1_not_dasd
TM dev_flags,X'80' check for eckd
BNO ut1_not_eckd
L r3,cyls
M r2,trks_per_cyl total number of trks
ST r3,trks


Notice it's loading the number of cylinders into R3 from the "cyls" field, which is defined as:

devta DS XL(32)

cyls EQU devta+4,4
trks_per_cyl EQU devta+8,4
dev_flags EQU devta+12,2


Offset 4 for a length of 4! Which is wrong! (At least according to IBM's DSECT anyway!)

Maybe this explains the incorrect number of cylinders being reported by CCKDDU64 that Brian reported in his post?

Methinks something is awry somewhere! :(

I'm actually quite surprised that Brian reports it *seems* to work just fine for 3390-3, 3390-9 and 3390-27! (Really?!)

%-(

<me: confused!>

--
"Fish" (David B. Trout)
Software Development Laboratories

mail: fish@...









--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?


 

On Fri, Jan 17, 2025 at 12:17?AM Fish Fish via groups.io
[deleted]
D31US3 has 60102 cyls, 15 trks/cyl and 901530 total trks
What model dasd of dasd has 60102 cylinders?!

A 3390-54 is supposed to have 65520 cylinders!

--
"Fish" (David B. Trout)
IBM ESS F20+ could have any number of cylinders from 1 to 64K. And
you would often get some odd amount of space at the end of a raid
group that would assigned as a volume.


 

Andrew wrote:

The steps to use CCKDDU64 are fairly straightforward.
<snip>

Thank you, Andrew! Much appreciated.

Of course, I was hoping for a more detail (small baby steps!) so that someone who has ZERO practical knowledge/experience with z/OS (like me!) could understand and follow, so that I could try it for myself, but that's okay. I can get one of my other friends to help me with that.

[...]
4) Optional, but highly recommended, use CCKDCOMP64 to
optimise the CCKD64
Personally, I would use "convto64" instead. It's probably much faster and produces better results.

But again, THANK YOU for explaining the steps.

Now all we need to do is figure out why 3390-54 is failing. :(

--
"Fish" (David B. Trout)
Software Development Laboratories

mail: fish@...


 

Mike Schwab wrote:

Is the number of cylinders 2 bytes signed?
According to what I'm seeing in the source code for the CCKDDU64 program (one of the files in Herc's "cckddump-cckdload.zip" file in the 'util' subdirectory), it's actually a 4-byte fullword field within the data returned by the "DEVTYPE" macro (which I know nothing about! I'm *not* a z/OS programmer!), which I'm guessing is being used to retrieve the source device's (source volume's) dasd geometry and other information.

But what concerns and confuses me is that it's not using a DSECT to access the individual fields in the returned data, and is instead using a simple hard coded EQUate (which *appears* to be WRONG, which is what's confusing me!).

According to what I am seeing on IBM's web site:

*

*


====================================================================
THE FOLLOWING SECTION IS RETURNED BY DEVTYPE FOR INFO=DASD.
====================================================================

0 (0) STRUCTURE 16 DVAIDASD
0 (0) UNSIGNED 4 DVAICYL NUMBER OF CYLINDERS
4 (4) UNSIGNED 4 DVAITRK TRACKS PER CYLINDER
8 (8) UNSIGNED 1 DVAIFLAG FLAGS


But what I'm seeing in CCKDDU64 is:

*/* ----------------------------------------------------------------
* * get device information for sysut1 [the volume to be dumped]
* * ---------------------------------------------------------------- */

MVC devtl,model_devtl
DEVTYPE =CL8'SYSUT1',(devta,L'devta), x
INFOLIST=devt_infol_2,MF=(E,devtl)
LTR rf,rf
BNZ ut1_devt_err
TM devta+2,UCB3DACC check for dasd device
BNO ut1_not_dasd
TM dev_flags,X'80' check for eckd
BNO ut1_not_eckd
L r3,cyls
M r2,trks_per_cyl total number of trks
ST r3,trks


Notice it's loading the number of cylinders into R3 from the "cyls" field, which is defined as:

devta DS XL(32)

cyls EQU devta+4,4
trks_per_cyl EQU devta+8,4
dev_flags EQU devta+12,2


Offset 4 for a length of 4! Which is wrong! (At least according to IBM's DSECT anyway!)

Maybe this explains the incorrect number of cylinders being reported by CCKDDU64 that Brian reported in his post?

Methinks something is awry somewhere! :(

I'm actually quite surprised that Brian reports it *seems* to work just fine for 3390-3, 3390-9 and 3390-27! (Really?!)

%-(

<me: confused!>

--
"Fish" (David B. Trout)
Software Development Laboratories

mail: fish@...


 

3390-54 isn't EAV, is jsut twice the size of a 3390-27


 

Brian Westerman wrote:

Well, It doesn't seem to work for 3390-54, (it abends with
a USER=99, but no text as to why), the last thing printed is:
[...]
D31US3 has 60102 cyls, 15 trks/cyl and 901530 total trks
What model dasd of dasd has 60102 cylinders?!

A 3390-54 is supposed to have 65520 cylinders!

--
"Fish" (David B. Trout)
Software Development Laboratories

mail: fish@...


 

A 3390-54 has 65520 cylinders; a -27 has half that number.


On Thu, Jan 16, 2025 at 10:44?PM Mike Schwab via <Mike.A.Schwab=[email protected]> wrote:
Is the number of cylinders 2 bytes signed?
2 bytes logical can get you to 64k.
And if you want EAV you are going to need more bytes.
Right now it is 16 *64k = 1M (849G) for the current z/OS.
Cylinder field expandable to 4K*64K = 256M (216T).

On Thu, Jan 16, 2025 at 9:03?PM Jay Maynard via
<jaymaynard=[email protected]> wrote:
>
> I got those same results.
>
> On Thu, Jan 16, 2025 at 8:27?PM Brian_Westerman via <Brian_Westerman=[email protected]> wrote:
>>
>> Well, It doesn't seem to work for 3390-54, (it abends with a USER=99, but no text as to why), the last thing printed is:
>> cckddump 0.3.1 starting
>> main workarea is at address 0x15f36000, 24-bit workarea is at address 0x8000
>> D31US3 vtoc opened
>> D31US3 has 60102 cyls, 15 trks/cyl and 901530 total trks
>> D31US3 vtoc has 10000 total dscbs
>> storage obtained for vtoc area, addr 0x15f39000 size 1400000
>> reading D31US3 vtoc
>> D31US3 vtoc closed
>> 25 datasets are on D31US3
>> storage obtained for dsn area, addr 0x1608f000 size 2128
>> storage obtained for trk vector, addr 0x16090000 size 3606120
>> storage released for vtoc area, addr 0x15f39000 size 1400000
>> 281380 tracks out of 901530 will be dumped
>> storage obtained for D31US3 i/o area, addr 0xa000 size 852480
>> storage obtained for compression, addr 0x15f39000 size 57344
>> persistent c environment created, handle=0x15f37188
>> file SYSUT2 opened for output
>>
>>
>>
>> It does appear to execute for 3390-3, 3390-9 and 3390-27, they were able to be uploaded and seem to be perfectly fine and useable, but still the 3390-54 doesn't work.? Does anyone have a CCKDDU64 that was changed for 3390-54 dasd?
>
>
>
> --
> Jay Maynard
>
>



--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?







--
Jay Maynard


 

Is the number of cylinders 2 bytes signed?
2 bytes logical can get you to 64k.
And if you want EAV you are going to need more bytes.
Right now it is 16 *64k = 1M (849G) for the current z/OS.
Cylinder field expandable to 4K*64K = 256M (216T).

On Thu, Jan 16, 2025 at 9:03?PM Jay Maynard via groups.io
<jaymaynard@...> wrote:

I got those same results.

On Thu, Jan 16, 2025 at 8:27?PM Brian_Westerman via groups.io <Brian_Westerman@...> wrote:

Well, It doesn't seem to work for 3390-54, (it abends with a USER=99, but no text as to why), the last thing printed is:
cckddump 0.3.1 starting
main workarea is at address 0x15f36000, 24-bit workarea is at address 0x8000
D31US3 vtoc opened
D31US3 has 60102 cyls, 15 trks/cyl and 901530 total trks
D31US3 vtoc has 10000 total dscbs
storage obtained for vtoc area, addr 0x15f39000 size 1400000
reading D31US3 vtoc
D31US3 vtoc closed
25 datasets are on D31US3
storage obtained for dsn area, addr 0x1608f000 size 2128
storage obtained for trk vector, addr 0x16090000 size 3606120
storage released for vtoc area, addr 0x15f39000 size 1400000
281380 tracks out of 901530 will be dumped
storage obtained for D31US3 i/o area, addr 0xa000 size 852480
storage obtained for compression, addr 0x15f39000 size 57344
persistent c environment created, handle=0x15f37188
file SYSUT2 opened for output



It does appear to execute for 3390-3, 3390-9 and 3390-27, they were able to be uploaded and seem to be perfectly fine and useable, but still the 3390-54 doesn't work. Does anyone have a CCKDDU64 that was changed for 3390-54 dasd?


--
Jay Maynard



--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?


 

I got those same results.

On Thu, Jan 16, 2025 at 8:27?PM Brian_Westerman via <Brian_Westerman=[email protected]> wrote:

Well, It doesn't seem to work for 3390-54, (it abends with a USER=99, but no text as to why), the last thing printed is:
cckddump 0.3.1 starting ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
main workarea is at address 0x15f36000, 24-bit workarea is at address 0x8000 ? ? ??
D31US3 vtoc opened ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??
D31US3 has 60102 cyls, 15 trks/cyl and 901530 total trks ? ? ? ? ? ? ? ? ? ? ? ? ??
D31US3 vtoc has 10000 total dscbs ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
storage obtained for vtoc area, addr 0x15f39000 size 1400000 ? ? ? ? ? ? ? ? ? ? ??
reading D31US3 vtoc ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
D31US3 vtoc closed ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??
25 datasets are on D31US3 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
storage obtained for dsn area, addr 0x1608f000 size 2128 ? ? ? ? ? ? ? ? ? ? ? ? ??
storage obtained for trk vector, addr 0x16090000 size 3606120 ? ? ? ? ? ? ? ? ? ? ?
storage released for vtoc area, addr 0x15f39000 size 1400000 ? ? ? ? ? ? ? ? ? ? ??
281380 tracks out of 901530 will be dumped ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??
storage obtained for D31US3 i/o area, addr 0xa000 size 852480 ? ? ? ? ? ? ? ? ? ? ?
storage obtained for compression, addr 0x15f39000 size 57344 ? ? ? ? ? ? ? ? ? ? ??
persistent c environment created, handle=0x15f37188 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
file SYSUT2 opened for output ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
?
?
?
It does appear to execute for 3390-3, 3390-9 and 3390-27, they were able to be uploaded and seem to be perfectly fine and useable, but still the 3390-54 doesn't work.? Does anyone have a CCKDDU64 that was changed for 3390-54 dasd?



--
Jay Maynard


 

Well, It doesn't seem to work for 3390-54, (it abends with a USER=99, but no text as to why), the last thing printed is:
cckddump 0.3.1 starting ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
main workarea is at address 0x15f36000, 24-bit workarea is at address 0x8000 ? ? ??
D31US3 vtoc opened ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??
D31US3 has 60102 cyls, 15 trks/cyl and 901530 total trks ? ? ? ? ? ? ? ? ? ? ? ? ??
D31US3 vtoc has 10000 total dscbs ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
storage obtained for vtoc area, addr 0x15f39000 size 1400000 ? ? ? ? ? ? ? ? ? ? ??
reading D31US3 vtoc ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
D31US3 vtoc closed ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??
25 datasets are on D31US3 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
storage obtained for dsn area, addr 0x1608f000 size 2128 ? ? ? ? ? ? ? ? ? ? ? ? ??
storage obtained for trk vector, addr 0x16090000 size 3606120 ? ? ? ? ? ? ? ? ? ? ?
storage released for vtoc area, addr 0x15f39000 size 1400000 ? ? ? ? ? ? ? ? ? ? ??
281380 tracks out of 901530 will be dumped ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??
storage obtained for D31US3 i/o area, addr 0xa000 size 852480 ? ? ? ? ? ? ? ? ? ? ?
storage obtained for compression, addr 0x15f39000 size 57344 ? ? ? ? ? ? ? ? ? ? ??
persistent c environment created, handle=0x15f37188 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
file SYSUT2 opened for output ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
?
?
?
It does appear to execute for 3390-3, 3390-9 and 3390-27, they were able to be uploaded and seem to be perfectly fine and useable, but still the 3390-54 doesn't work.? Does anyone have a CCKDDU64 that was changed for 3390-54 dasd?


 

The steps to use CCKDDU64 are fairly straightforward.

1) Once-off build/preparation of the CCKDDU64 load module.
2) Execute CCKDDU64 (batch job) to dump a volume.
3) Binary FTP the resulting output file (which is in CCKD64 format) to your local workstation.
4) Optional, but highly recommended, use CCKDCOMP64 to optimise the CCKD64 file before first use.
5) Attach it to your Hercules system and you're good to go.

1. Once off build
The once off build can be quite daunting, but thankfully there is a prepared package in xmi format here:-

It has, amongst other members, a Load Library containing a compiled CCKDDU64 (X$CCKDL) and JCL to execute it (E$DUMP).
Alternately, you can follow the steps in $$README to build the load module(s) from source.
The default CCKDDU64 outputs a 64-bit Compressed CKD with zlib compression.

Hope this helps
Andrew


 

Do you have a copy of the CCKDDU64 load module that works that you can share?? Alternatively, if you can explain the process you used to assemble/link it on the mainframe side that would be great too.?
?
Once you have that CCKDDU64 created output file, transferring it to the PC should be pretty simple (probably FTP in binary format), and that file is probably already in CCKD format so it can be inserted into your hercules config file, but maybe instead you might be uploading it a work volume under hercules and then restoring it to a emulated 3390-x inside hercules using CCKDDUMP to restore it.?
?
If you could detail the process a bit it would be very helpful.? I would like to formalize something so that people can do the process simply and easily.? My current method is long and drawn out, (and not a lot of fun).
?
Thanks,
?
Brian


 

I meant the mechanics or process of dumping a volume on a "real" mainframe z/OS in some format that I can transfer that volume to be used under Hercules z/OS.
?
?
On Wed, Jan 15, 2025 at 02:58 AM, Patrik Schindler wrote:

Hello Brian,

Am 15.01.2025 um 07:53 schrieb Brian_Westerman via groups.io <Brian_Westerman@...>:

So how do people transfer a 3390-x full volume backup from zos to Hercules?
You did not yet clarify what you mean with this sentence. I asked for details last week but failed to recognize an answer from you.


 

Andrew wrote:

I use the 64bit CCKDDU64 all the time for full volume images.
Haven't had a problem with it yet. Just need a (few) large
volumes on the source system to temporarily stage the output
dataset before FTP'ing it to local workstation.
Wow! That's good to know, Andrew! Thanks for that!

Can you briefly document for us how you do it?

As I understand it, you have to first get the CCKDDU64 assembler source code (from Hercules's cckddump-cckdload.zip file in its 'util' subdirectory) onto your source z/OS system (presumably running on real hardware, but I fully understand that's not a requirement), assemble and link it, and then run it to "dump" the desired volume to a very large dataset. Yes?

Then download that dataset (presumably using FTP) to your target system (where your Hercules usually runs), and then (this is what I'm unclear about) "do something" to convert that file into a Hercules CCKD64 dasd image. Yes? Is that correct?

What utility/tool do you use to convert the downloaded file back into a Hercules dasd?

OR... Do you instead "download" (FTP) the source dataset directly to your running Hercules z/OS system? (And then presumable run the corresponding CCKDLO64 program on your Hercules z/OS system to take that very large dataset and write it directly to an already exists z/OS dasd volume?)

Forgive me Andrew, but I'm not a z/OS person! But I do very much want to understand how to accomplish this process, so I can try it for myself! To verify for myself and for our other Hercules users whether it indeed does work okay, so I can create a "Here's how you do it!" document.

Thanks!

(This is GREAT!)

--
"Fish" (David B. Trout)
Software Development Laboratories

mail: fish@...