standalone physical restore issue

[shixinlong-bot]

standalone physical restore issue

[shixinlong-bot]

Also, I noticed step 1.3 of your procedure, you say:

1.3  convert the volume backup and the two standalone program to aws format

I would like to try to reproduce your problem on my own system (I have z/OS 1.10, 2.1, 2.3, 2.4 and 2.5), but I do not know how to do step 1.3! ("convert the tapes to .aws format") Can you help me with that? I don't know z/OS! Help!

Hi Fish,
I convert the tape file backup to awstape format using below jcl as guided in the below link:

• https://sdl-hercules-390.github.io/html/hercload.html

//TAPECONV EXEC PGM=TAPECONV
//SYSPRINT DD SYSOUT=*
//SYSUT1   DD  DSN=VDRES50,DISP=(OLD),
//         UNIT=TTAPE,LABEL=(1,SL),
//         VOL=(,RETAIN,,,SER=000001),
//         DCB=(BLKSIZE=64K,RECFM=U,TRTCH=COMP)
//SYSUT2   DD  DSN=DEV.TAPECONV.VDRES50,DISP=(,CATLG),
//         UNIT=SYSDA,VOL=SER=(DOMO40,DTMP50,DHSM40,DTSO41),
//         SPACE=(CYL,(2000,300),RLSE)
//         PEND

For the compress option, I will give it a try and let you know the results accordingly.

Thank you!

[shixinlong-bot]

device information in the mainframe

ICK00700I DEVICE INFORMATION FOR DEVN IS CURRENTLY AS FOLLOWS:
          PHYSICAL DEVICE = 3390
          STORAGE CONTROLLER = 2107
          STORAGE CONTROL DESCRIPTOR = E8
          DEVICE DESCRIPTOR = 0C
          ADDITIONAL DEVICE INFORMATION = 4800003C
          TRKS/CYL = 15, # PRIMARY CYLS = 10017

[Fish-Git]

EDITOR'S NOTE: The below appears to have been caused by a temporary problem with GitHub.

• detail procedure.txt
• Environment info.txt
• hercules.log
• hercules.cnf.txt

NONE of your files can be download.

They ALL report "Error 404 Not Found".

Did you attach/upload them correctly?

Notice the GitHub input box, where you type in your comments/reply. It has two tabs at the top: "Write" and "Preview".

Now notice at the bottom of the box, there is a link that says "Markdown is supported", and another one that says "Paste, drop, or click to add files".

You can click that link, and then select the file you want to upload, or you can simply drag-and-drop the file from your desktop into the GitHub comment box.

Please re-upload/attach your files. We cannot help you without the proper information we need.

[shixinlong-bot]

I am not sure what's wrong with the attachment uploaded.
The attachment in other case (for example #640) also report 'Error 404 Not Found'

[shixinlong-bot]

the attachment could be downloaded now, kindly retry.

[Fish-Git]

I am not sure what's wrong with the attachment uploaded.
The attachment in other case (for example #640) also report 'Error 404 Not Found'

I can download Issue #640's attachments just fine.

Oddly, I can also download your attachments just fine now too!

I guess it was a temporary problem with GitHub?  I apologize.

[Fish-Git]

the attachment could be downloaded now, kindly retry.

Thank you. I guess it was probably a temporary problem. It's working fine now. Sorry.

[Fish-Git]

shixinlong-bot,

I don't know z/OS. So please forgive me.

The errors you are getting are:

HHC00306E 0:50C2 CCKD file[0] /home/hercules/volume/DASD/DRES50.50C2: trklen error for BCCHH = 010012000c
HHC00343E 0:50C2 CCKD file[0] /home/hercules/volume/DASD/DRES50.50C2: uncompress error trk 282: 010012000c

CCHH X'0012000C' is cylinder 18, head 12 (track 282), which is very close to the beginning of the restore.

Both messages indicate Hercules was unable to decompress the track image.

I noticed on step 1.1 of your procedure ("backup the whole resident volume"), you specified compression:

//STEP1    EXEC PGM=ADRDSSU,REGION=0M
//SYSPRINT DD   SYSOUT=*
//DASD1    DD UNIT=3390,VOL=SER=DRES00,DISP=SHR
//TAPE1    DD DSN=VDRES00,DISP=(NEW,KEEP,DELETE),
//         UNIT=TTAPE,LABEL=(1,SL),
//         VOL=(,RETAIN,,,SER=000001),
//         DCB=(BLKSIZE=64K,RECFM=U,TRTCH=COMP)
//SYSIN    DD *
  DUMP INDDNAME(DASD1) OUTDDNAME(TAPE1) COMPRESS OPT(4) -
  ALLDATA(*) ALLEXCP WAIT(0,0) FULL

I am wondering if maybe z/OS's compression is incompatible with Hercules;s compression?

Can you try again, but NOT use compression?

Also, I noticed step 1.3 of your procedure, you say:

1.3  convert the volume backup and the two standalone program to aws format

I would like to try to reproduce your problem on my own system (I have z/OS 1.10, 2.1, 2.3, 2.4 and 2.5), but I do not know how to do step 1.3! ("convert the tapes to .aws format") Can you help me with that? I don't know z/OS! Help!

Thanks.

[Fish-Git]

Apparently I'm going to be needing a lot of z/OS hand holding!

I'm trying to perform step 1.1 of your procedure ("backup the whole resident volume"), but the job is failing with the message:

IEF210I FISH#001 STEP1 TAPE1 - UNIT FIELD SPECIFIES INCORRECT DEVICE NAME

and I don't know why.  :(

(Printout of failed run):

• S0W1 IBMUSER #643 STEP 1 FISH#001 JOB00447 2024-03-13 17.27.44.pdf

 
The JCL that I used was:

//FISH#001 JOB (123),'#643 STEP 1',CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1),
//             NOTIFY=&SYSUID
//******************************************************************
//* CREATE THE VIRTUAL TAPE DUMP OF THE DASD VOLUME
//******************************************************************
//STEP1    EXEC PGM=ADRDSSU,REGION=0M
//SYSPRINT DD   SYSOUT=*
//DASD1    DD UNIT=3390,VOL=SER=GH0643,DISP=SHR
//TAPE1    DD DSN=VDRES00,DISP=(NEW,KEEP,DELETE),
//         UNIT=TTAPE,LABEL=(1,SL),
//         VOL=(,RETAIN,,,SER=000001),
//         DCB=(BLKSIZE=64K,RECFM=U,TRTCH=COMP)
//SYSIN    DD *
  DUMP INDDNAME(DASD1) OUTDDNAME(TAPE1) COMPRESS OPT(4) -
  ALLDATA(*) ALLEXCP WAIT(0,0) FULL
/*
//

Dasd volume "GH0643" is the one I'm trying to dump (backup), but it appears to be complaining about my UNIT=TTAPE specification.

Should I specify a specific tape unit device address instead? (e.g. UNIT=0301?)

I don't know z/OS!

Help!       :(

[shixinlong-bot]

IEF210I FISH#001 STEP1 TAPE1 - UNIT FIELD SPECIFIES INCORRECT DEVICE NAME

. . .

Should I specify a specific tape unit device address instead? (e.g. UNIT=0301?)

Hi Fish,

Just specify the tape unit device address or your tape device type is ok.Thanks.

[shixinlong-bot]

Could you guide me?

Is there any other way for me to move the resident volume on mainframe to hercules emulated DASD? I don't have the z/OS system up on the hercules host. Thanks!

[Fish-Git]

Is there any other way for me to move the resident volume on mainframe to hercules emulated DASD?

Well, supposedly one of our former developers wrote a program that you can run on your mainframes to either dump an entire dasd volume to a dataset or load a dataset to a dasd volume, but I don't know much about it.

Everything you need is supposed to be contained in the "cckddump-cckdload.zip" file in the "util" directory of Hercules's source code distribution.

Basically, as I understand it, you assemble and catalog the programs you need (either cckddump or cckddu64 to dump the dasd volume to a dataset, and/or cckdload to load the dataset to a dasd volume) and then use them accordingly.

To transfer the dasd volume from your mainframe to Hercules, you run cckdump (for 3390-3 or smaller) or cckddu64 (for 3390-9 or larger) to create the dataset on your mainframe. Then you ftp that dataset to your Hercules z/OS dataset, and then finally run cckdload to load that dataset to your Hercules dasd.

To transfer a dasd volume from Hercules to your mainframe, you do the opposite.

But as I said, I don't know much about it. I'm not a z/OS person, and I have never tried it myself.

Maybe you can figure it out? Or maybe you can ask the Hercules group for help? I'm sure there are probably several Hercules users who have used it, and maybe they can help you with it?

IMO, the way you are currently trying to do it (dump to tape, then restore from tape) it is the simplest and most correct way!

But as I said, I am not a z/OS person! I am a Hercules developer. I know about Hercules, but I do not know about the many, many different operating systems that Hercules can IPL and run!

[Fish-Git]

shixinlong-bot,

(Do you prefer a different name/greeting?)

I need some more help from you.

I have successfully completed step 1.1: backup the whole resident volume. Thank you for your help!

Now I wish to perform step 1.2, but I do not want to create a dataset. I want the output to go directly to tape. How do I change your step 1.2 JCL to have the output go directly to a tape device?

[shixinlong-bot]

shixinlong-bot,

(Do you prefer a different name/greeting?)

I need some more help from you.

I have successfully completed step 1.1: backup the whole resident volume. Thank you for your help!

Now I wish to perform step 1.2, but I do not want to create a dataset. I want the output to go directly to tape. How do I change your step 1.2 JCL to have the output go directly to a tape device?
. . .

Fish,

Try this:

//GEN     EXEC PGM=IEBGENER
//SYSPRINT DD  SYSOUT=*
//SYSIN    DD  DUMMY,DCB=BLKSIZE=80
//SYSUT1   DD  DSN=SYS1.SAMPLIB(ICKSADSF),DISP=SHR
//SYSUT2   DD  DSN=DEV.ICKDSF,
//             DISP=(NEW,KEEP,DELETE),
//             DCB=(BLKSIZE=64K,RECFM=U,TRTCH=COMP),
//             UNIT=0300,LABEL=(1,SL),        <--- CHANGE TO YOUR TAPE DEVICE
//             VOL=(,RETAIN,,,SER=000001)

//BUILDSA EXEC PGM=ADRDSSU,PARM='UTILMSG=YES',REGION=8M
//SAMODS   DD  DSN=SYS1.SADRYLIB,DISP=SHR
//TAPEDD   DD  DISP=(NEW,KEEP,DELETE),
//             DCB=(BLKSIZE=32760,RECFM=U,TRTCH=COMP),
//             DSN=DEV.BUILDSA.TAPE,
//             UNIT=0300,LABEL=(1,SL),        <--- CHANGE TO YOUR TAPE DEVICE
//             VOL=(,RETAIN,,,SER=000001)
//SYSPRINT DD  SYSOUT=*
//SYSIN    DD  *
  BUILDSA -
  INDD(SAMODS) -
  OUTDD(TAPEDD) -
  IPL(TAPE)
/*

[shixinlong-bot]

Is there any other way for me to move the resident volume on mainframe to hercules emulated DASD?

Well, supposedly one of our former developers wrote a program that you can run on your mainframes to either dump an entire dasd volume to a dataset or load a dataset to a dasd volume, but I don't know much about it.

Everything you need is supposed to be contained in the "cckddump-cckdload.zip" file in the "util" directory of Hercules's source code distribution.

Basically, as I understand it, ...

. . .

But as I said, I don't know much about it. I'm not a z/OS person, and I have never tried it myself.

Maybe you can figure it out? Or maybe you can ask the Hercules group for help? I'm sure there are probably several Hercules users who have used it, and maybe they can help you with it?

Thank you so much!

[Fish-Git]

Now I wish to perform step 1.2, but I do not want to create a dataset. I want the output to go directly to tape. How do I change your step 1.2 JCL to have the output go directly to a tape device?
. . .

Fish,

Try this:

THANK YOU!  :-D

I did have to make a few minor changes to your JCL though, but I was able to figure it out for myself. For example, in each of the jobs, I changed the VOL=(,RETAIN,,,SER=000001) clause in each job to specify a different serial number. In the step 1.1 backup job for example, I used SER=000001, but in the step 1.2 IEBGENER ICKDSF job, I used SER=000002, and in the ADRDSSU DFSMSDSS job, I used SER=000003.

I also discovered that the UNIT=... for my tape drive needed to be only 3 digits. I tried using e.g. UNIT=0591, but z/OS didn't like that. When I changed it to UNIT=591 however, it worked! (although I was still prompted for the device address of the tape drive unit I wanted to use, which I thought was odd)

Anyway, now that I have the necessary tapes created, I can try to reproduce your problem to see why it is failing for you.

Thank you again for your kind help!  :)

[Fish-Git]

Okay, I've completed my attempt to reproduce your problem, and I'm sorry to report that my attempt was unsuccessful. I was unable to reproduce your problem. My stand alone ADRDSSU DFSMSDSS restore worked perfectly. Hercules did not report any I/O errors. It ran to successful completion. (It was a very small volume with almost no data on it. Should I try a larger volume? One with lots of data on it?)

I also used z/OS 2.5c too.

What version of z/OS are you using?

I noticed in step 2.1 of your instructions, you specified -z in your dasdinit64 command to create your empty DRES50.50C2 dasd volume. This will create a CCKD64 dasd image that uses zlib compression to compress its track data. Does you system have zlib installed? Maybe you need to create it using -bz2 instead?

OR... what you might want to try is to use dasdinit64 to create a normal uncompressed CKD64 empty dasd image instead, and restore your tape to that instead. Then, if that is successful, you can then use dasdcopy64 to convert it to CCKD64 to save space.

Have you tried doing a cckdcdsk -ro -3 on your dasd (DRES50.50C2) to verify it's not damaged? What about cckdmap -i? Does it work okay? What does it report? Or, you could do a cckddiag to try and dump the track that has the error.

I'm afraid I'm out of ideas!  :(

[Fish-Git]

If you still cannot get anything to work, you might want to enable CCW and CCKD tracing on your dasd image before attempting your restore. Then attach the Hercules log so I can look at it.

t+50C2
cckd debug=1
ipl 500
...

[shixinlong-bot]

If you still cannot get anything to work, you might want to enable CCW and CCKD tracing on your dasd image before attempting your restore. Then attach the Hercules log so I can look at it.

t+50C2
cckd debug=1
ipl 500
...

Here is the tracing log you asked for:

 
Below is the cckdcdsk64 you asked me to do:

[root@lx-hemu-app-u1 DASD]# /home/hyperion/cckdcdsk64 -ro -3 DRES50.50C2
HHC02499I Hercules utility lt-cckdcdsk64 - CCKD64 dasd image verification - version 4.7.0.11119-SDL-gf7d2360a
HHC01414I (C) Copyright 1999-2024 by Roger Bowler, Jan Jaeger, and others
HHC01417I ** The SDL 4.x Hyperion version of Hercules **
HHC01415I Build date: Mar 11 2024 at 12:09:55
HHC00379I 0:0000 CCKD file DRES50.50C2: starting lt-cckdcdsk64 level 3 (read-only)...
HHC00371W 0:0000 CCKD file DRES50.50C2: trk[282] offset 0x000000000002D73E len 13269 validation error
HHC00007I Previous message from function 'cckd64_chkdsk' at cckdutil64.c(1791)
HHC00373I 0:0000 CCKD file DRES50.50C2: 0 trk images recovered
HHC00375W 0:0000 CCKD file DRES50.50C2: recovery not completed: file opened read-only
HHC00007I Previous message from function 'cckd64_chkdsk' at cckdutil64.c(2418)
HHC00380W 0:0000 CCKD file DRES50.50C2: lt-cckdcdsk64 level 3 complete; rc=-1
HHC00007I Previous message from function 'main' at cckdcdsk64.c(160)

 
I now have two more questions:

1. Is there any incorrect configuration in my hercules.cnf file per my linux version?
2. What is the VTOC value for you when initialize the volume?

[shixinlong-bot]

Okay, I've completed my attempt to reproduce your problem, and I'm sorry to report that my attempt was unsuccessful. I was unable to reproduce your problem. My stand alone ADRDSSU DFSMSDSS restore worked perfectly. Hercules did not report any I/O errors. It ran to successful completion. (It was a very small volume with almost no data on it. Should I try a larger volume? One with lots of data on it?)

I noticed in step 2.1 of your instructions, you specified -z in your dasdinit64 command to create your empty DRES50.50C2 dasd volume. This will create a CCKD64 dasd image that uses zlib compression to compress its track data. Does you system have zlib installed? Maybe you need to create it using -bz2 instead?

OR... what you might want to try is to use dasdinit64 to create a normal uncompressed CKD64 empty dasd image instead, and restore your tape to that instead. Then, if that is successful, you can then use dasdcopy64 to convert it to CCKD64 to save space.

Have you tried doing a cckdcdsk -ro -3 on your dasd (DRES50.50C2) to verify it's not damaged? What about cckdmap -i? Does it work okay? What does it report? Or, you could do a cckddiag to try and dump the track that has the error.

I'm afraid I'm out of ideas!  :(

1. zlib version:
   Package zlib-devel-1.2.11-39.el9.x86_64 is already installed.

2. If uncompress, another length error occurs, as shown in the below log:

3. With UNcompressed DRES50.50C2:

[root@lx-hemu-app-u1 DASD]# /home/hyperion/cckdcdsk64 -ro -3 DRES50.50C2
HHC02499I Hercules utility lt-cckdcdsk64 - CCKD64 dasd image verification - version 4.7.0.11119-SDL-gf7d2360a
HHC01414I (C) Copyright 1999-2024 by Roger Bowler, Jan Jaeger, and others
HHC01417I ** The SDL 4.x Hyperion version of Hercules **
HHC01415I Build date: Mar 11 2024 at 12:09:55
HHC02424E Dasd image file format unsupported or unrecognized: DRES50.50C2
HHC00007I Previous message from function 'main' at cckdcdsk64.c(106)

[shixinlong-bot]

Test results with creating file via dasdinit64 -bz2 -lfs option:

[root@lx-hemu-app-u1 DASD]# /home/hyperion/cckdcdsk64 -ro -3 DRES50.50C2
HHC02499I Hercules utility lt-cckdcdsk64 - CCKD64 dasd image verification - version 4.7.0.11119-SDL-gf7d2360a
HHC01414I (C) Copyright 1999-2024 by Roger Bowler, Jan Jaeger, and others
HHC01417I ** The SDL 4.x Hyperion version of Hercules **
HHC01415I Build date: Mar 11 2024 at 12:09:55
HHC00379I 0:0000 CCKD file DRES50.50C2: starting lt-cckdcdsk64 level 3 (read-only)...
HHC00371W 0:0000 CCKD file DRES50.50C2: trk[282] offset 0x000000000002C359 len 13750 validation error
HHC00007I Previous message from function 'cckd64_chkdsk' at cckdutil64.c(1791)
HHC00373I 0:0000 CCKD file DRES50.50C2: 0 trk images recovered
HHC00375W 0:0000 CCKD file DRES50.50C2: recovery not completed: file opened read-only
HHC00007I Previous message from function 'cckd64_chkdsk' at cckdutil64.c(2418)
HHC00380W 0:0000 CCKD file DRES50.50C2: lt-cckdcdsk64 level 3 complete; rc=-1
HHC00007I Previous message from function 'main' at cckdcdsk64.c(160)

[Fish-Git]

Here is the tracing log you asked for:

• trace-log.zip

Thank you. I will look at it and let you know what I find.

 

I now have two more questions:

1. Is there any incorrect configuration in my hercules.cnf file per my linux version?

No. I did not see anything wrong. It looks okay to me.

 

2. What is the VTOC value for you when initialize the volume?

VTOC? Do you mean VOLSER? I don't understand your question.

I know what a VTOC is, but as far as I know, dasdinit does not create a VTOC. It only creates a VOLSER if you ask it (which is the default).  If you specify the -r option however, it will not create a VOLSER.

But dasdinit does not create a VTOC.  It is ICKDSF that creates the VTOC. Yes?

 

2. If uncompress, another length error occurs, as shown in the below log:

• uncompress-trace-log.zip

Thank you. I will look at it and let you know what I find.

 

3. With UNcompressed DRES50.50C2:

[root@lx-hemu-app-u1 DASD]# /home/hyperion/cckdcdsk64 -ro -3 DRES50.50C2
HHC02499I Hercules utility lt-cckdcdsk64 - CCKD64 dasd image verification - version 4.7.0.11119-SDL-gf7d2360a
HHC01414I (C) Copyright 1999-2024 by Roger Bowler, Jan Jaeger, and others
HHC01417I ** The SDL 4.x Hyperion version of Hercules **
HHC01415I Build date: Mar 11 2024 at 12:09:55
HHC02424E Dasd image file format unsupported or unrecognized: DRES50.50C2
HHC00007I Previous message from function 'main' at cckdcdsk64.c(106)

This is expected! There is nothing wrong. The cckdcdsk utility only works on compressed (CCKD) dasds. Its purpose is to verify the integrity of the of the Compressed CKD (CCKD) format. It is not designed for normal uncompressed CKD dasds. You should only run cckdcdsk on compressed CCKD dasds, not on normal uncompressed CKD dasds.

 

Test results with creating file via dasdinit64 -bz2 -lfs option:

• create file with bz2 option trace.zip

Thank you. I will look at it and let you know what I find.

 
Two questions:

1. When you did the FTP from your mainframe to your Linux host, were you careful to specify binary transfer mode?
2. Is it possible for me to obtain a copy of your /home/hercules/volume/TAPE/VDRES50 tape? I presume it is a .aws tape? Yes?

Since I am unable to reproduce your problem, I am thinking maybe your tape is bad? I would like to take a look at it, and try to use it on my system. If I have the same tape data as you, then I might be able to reproduce your problem. Thanks!

[shixinlong-bot]

Here is the tracing log you asked for:

Thank you. I will look at it and let you know what I find.

 

I now have two more questions:

1. Is there any incorrect configuration in my hercules.cnf file per my linux version?

No. I did not see anything wrong. It looks okay to me.

 

2. What is the VTOC value for you when initialize the volume?

VTOC? Do you mean VOLSER? I don't understand your question.

I know what a VTOC is, but as far as I know, dasdinit does not create a VTOC. It only creates a VOLSER if you ask it (which is the default).  If you specify the -r option however, it will not create a VOLSER.

But dasdinit does not create a VTOC.  It is ICKDSF that creates the VTOC. Yes?

 

2. If uncompress, another length error occurs, as shown in the below log:

Thank you. I will look at it and let you know what I find.

 

3. With UNcompressed DRES50.50C2:
   [root@lx-hemu-app-u1 DASD]# /home/hyperion/cckdcdsk64 -ro -3 DRES50.50C2
   HHC02499I Hercules utility lt-cckdcdsk64 - CCKD64 dasd image verification - version 4.7.0.11119-SDL-gf7d2360a
   HHC01414I (C) Copyright 1999-2024 by Roger Bowler, Jan Jaeger, and others
   HHC01417I ** The SDL 4.x Hyperion version of Hercules **
   HHC01415I Build date: Mar 11 2024 at 12:09:55
   HHC02424E Dasd image file format unsupported or unrecognized: DRES50.50C2
   HHC00007I Previous message from function 'main' at cckdcdsk64.c(106)

This is expected! There is nothing wrong. The cckdcdsk utility only works on compressed (CCKD) dasds. Its purpose is to verify the integrity of the of the Compressed CKD (CCKD) format. It is not designed for normal uncompressed CKD dasds. You should only run cckdcdsk on compressed CCKD dasds, not on normal uncompressed CKD dasds.

 

Test results with creating file via dasdinit64 -bz2 -lfs option:

Thank you. I will look at it and let you know what I find.

  Two questions:

1. When you did the FTP from your mainframe to your Linux host, were you careful to specify binary transfer mode?
2. Is it possible for me to obtain a copy of your /home/hercules/volume/TAPE/VDRES50 tape? I presume it is a .aws tape? Yes?

Since I am unable to reproduce your problem, I am thinking maybe your tape is bad? I would like to take a look at it, and try to use it on my system. If I have the same tape data as you, then I might be able to reproduce your problem. Thanks!

Hi Fish,

1、sure, the transfer mode is binary
2、i will check the tape file too.

For VTOC question, I would like to know the value you specify in the step 2.4 following the re-procedure the issue.

Thank you for your time and effort.

[Fish-Git]

Hi Fish,

1. sure, the transfer mode is binary

Good.

 

2. i will check the tape file too.

May I get a copy?

 

For VTOC question, I would like to know the value you specify in the step 2.4 following the re-procedure the issue.

I used the exact same command that you showed in your document. The only thing I changed was the device address and the volser:

INIT UNITADDRESS(0AC0) NOVERIFY VTOC(0,1,224) VOLID(GH0643)

 

Thank you for your time and effort.

You are very welcome!

Can I get a copy of your original tape? Can you upload it somewhere? Thanks.

[shixinlong-bot]

Hi Fish,

I am happy to report that I have found what was wrong in my procedure!

In step 1.1, the backup the of volume to tape, the block size was specified as 64K:

      //TAPE1    DD DSN=VDRES00,DISP=(NEW,KEEP,DELETE),
      //         UNIT=TTAPE,LABEL=(1,SL),
      //         VOL=(,RETAIN,,,SER=000001),
      //         DCB=(BLKSIZE=64K,RECFM=U,TRTCH=COMP)

After I changed it to 32760 instead:

      //         DCB=(BLKSIZE=32760,RECFM=U,TRTCH=COMP)

(and keeping the remainder of all of the steps the same), it works!

I am not sure if there is a bug in Hercules's tapeconv.jcl pertaining to 64k blocksizes or not (causing Hercules to create 64k blocksize .aws tape files), but when a blocksize of less than 64K is used (such as 32760), the DFSMSDSS restore step (step 2.6) works just fine!

If no further action is needed, you may close this issue.

Thanks again so much for your help with this problem.

[Fish-Git]

I am happy to report that I have found what was wrong in my procedure!

FANTASTIC!  :-D

I am VERY happy to hear that, shixinlong-bot!!  :))

I am not sure if there is a bug in Hercules's tapeconv.jcl pertaining to 64k blocksizes or not (causing Hercules to create 64k blocksize .aws tape files), but when a blocksize of less than 64K is used (such as 32760), the DFSMSDSS restore step (step 2.6) works just fine!

Well, looking at Hercules's tapeconv.jcl, it is designed to support a maximum block size of 65520:

hyperion/util/tapeconv.jcl

Lines 65 to 70 in f7d2360

	C R4,=F'65520' Is the block > 65520 ?
	BH EXIT020 yes, take error exit
	C R4,=F'32760' Is the block > 32760 ?
	BNH UNDER32 no, skip
	L R4,=F'32760' yes, set write length to max
	UNDER32 DS 0H

So I do not think the problem is with tapeconv.jcl.  That is to say, I believe tapeconv.jcl is okay.  tapeconv.jcl does not contain a bug.

I believe the actual bug was indeed the incorrect BLKSIZE that you specified in your very first 1.1 ADRDSSU step.

Well done, shixinlong-bot!   Good catch!   :)

I am closing this issue as "(Invalid/PEBKAC)" -- i.e. "User Error".

[Fish-Git]

Additional Information:

I found the following IBM web page which seems to confirm that DFSMSdss's (ADRDSSU's?) maximum supported blocksize is indeed 32760 bytes:

• https://www.ibm.com/docs/en/zos/2.4.0?topic=efficiently-space-considerations
   

...

The default block size for output records that are written to tape
is the optimum block size for the output device (262144 is the maximum).
You can change this default to 32760 by using the installation options
exit routine.   . . .

. . .

For output records that are written to DASD, the block size is the track
length of the output volume for devices whose track length is less than
32KB. It is one half the track length for devices whose track length is
greater than 32KB. You can select a different block size for tape or DASD
by coding DCB=BLKSIZE=block size in the corresponding data set definition
(DD) statement. The minimum block size is 7892 bytes; the maximum is 32760
bytes.

. . .

(Emphasis added)