|
View previous topic :: View next topic
|
| Author |
Message |
RickBig
New User
Joined: 11 Jul 2016
Posts: 10
Location: Canada
|
|
|
|
We have a (very) old series of batch jobs that read selected volumes of a multi-volume tape file. This is just a technique for splitting the file into 'manageable' segments.
So the code is like:
| Code: |
//COPY01 EXEC PGM=SORT
//*
//SORTIN DD DISP=SHR,DSN=MY.BIG.TAPE.FILE,
// UNIT=TAPE,VOL=SER=(UC4622,UI0455) |
Now until recently, this has been working fine, the step would only read the first two volumes.
Recently however, we see the following on the job output:
| Code: |
| IEC716I SORTIN :TAPE MULTIVOLUME LIST CORRECTED |
and instead of just the first two volumes being read, the entire file is read. Notably, if the volumes listed do not include the first volume, only the volumes in the scope of the VOL=SER are read.
Our systems people have not explained what caused this to change. Any ideas?
BTW, bypassing label processing, OPTCD=B, resolves the issue. |
|
| Back to top |
|
 |
Nic Clouston
Global Moderator
Joined: 10 May 2007
Posts: 2455
Location: Hampshire, UK
|
|
|
|
| No idea but...DISP=SHR for tape is "invalid". You cannot share a tape volume - you should use OLD. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8697
Location: Dubuque, Iowa, USA
|
|
|
|
| Quote: |
| BTW, bypassing label processing, OPTCD=B, resolves the issue. |
Actually, LABEL=BLP is the DCB subparameter to bypass label processing. What you are doing, from the JCL Reference manual, is:
| Quote: |
B
requests that the end-of-volume (EOV) routine disregard the end-of-file (EOF) recognition for magnetic tape. For an input data set on a standard-labeled (SL or AL) tape, the EOV routine treats EOF labels as EOV labels until the volume serial list is exhausted. This option allows SL or AL tapes to be read out of volume sequence or to be concatenated to another tape with the same data set name using one DD statement. See "Data Sets that Span Libraries" in z/OS MVS JCL User's Guide for a description of allocation processing for multi-volume data sets created in different tape libraries. |
|
|
| Back to top |
|
|
steve-myers
Active Member
Joined: 30 Nov 2013
Posts: 917
Location: The Universe
|
|
|
|
| Nic Clouston wrote: |
| No idea but...DISP=SHR for tape is "invalid". You cannot share a tape volume - you should use OLD. |
You are correct when you say two jobs cannot "share" a tape volume, but what DISP=SHR is saying is another job can "share" the data set name.
Actually, two jobs can "share" a tape volume, but only one job at a time can have a data set open on the volume. For that matter, one job cannot have 2 (or more) data sets open on one volume at a time. In other words, this won't work -
| Code: |
//A EXEC PGM=SORT
//SYSOUT DD SYSOUT=*
//SORTIN01 DD DISP=SHR,LABEL=1,UNIT=TAPE,VOL=SER=TAPEV1,DSN=TAPEV1.FILE1
//SORTIN02 DD DISP=SHR,LABEL=2,UNIT=TAPE,VOL=SER=TAPEV1,DSN=TAPEV1.FILE2
//SORTOUT DD ...
//SYSIN DD *
MERGE ... |
|
|
| Back to top |
|
|
RickBig
New User
Joined: 11 Jul 2016
Posts: 10
Location: Canada
|
|
|
|
Thanks for the valuable feedback. I'm still mystified, however, that the same job would work one way one month, and then differently the next.
I'm unaware of any system changes in the interim (at least I wasn't told of any). Perhaps a PTF was applied...
I'll forward any answer I receive from our support group. |
|
| Back to top |
|
|
Bryan Lehner
New User
Joined: 29 Jul 2016
Posts: 1
Location: United States
|
|
|
|
| I experienced this same situation, and a new version of CA-1 had been installed that leveraged the IBM Label Anomaly Exit. We had to start using the OPTCD=B for jobs that read individual tapes of a multi-volume group. |
|
| Back to top |
|
|
RickBig
New User
Joined: 11 Jul 2016
Posts: 10
Location: Canada
|
|
|
|
| Thanks, I will check and see if we had a similar update to CA-1 in that time period. |
|
| Back to top |
|
|
|
|
