On Wed, 7 Nov 2012 11:22:15 -0500, Sam Golob wrote:
>
> For most purposes, the z/OS system doesn't seem to use the volser
>that is in the HDR1 label. ...
>
I've just submitted an RCF on this:
Hello, MHVRCFs,
In:
Title: z/OS DFSMS: Using Magnetic Tapes
Document Number: SC26-7412-03
2.2.2 Format of IBM Standard Data Set Label 1 (HDR1/EOV1/EOF1)
I read:
...
Figure 6 shows the format of data set label 1.
The shaded areas represent fields that the operating system
writes in the label, but that are not used or verified
during processing.
Field 4, Data Set Serial Number, in 22-27 is shown as shaded.
However, in the subsequent text I read:
4--Data Set Serial Number (6 bytes)
...
Processing: If this field has inconsistent values in the
volumes in a volume set as described in Figure 3 in topic 2.1 and
Figure 4 in topic 2.1, the system writes a warning message.
This warns that one of the volumes might be the wrong volume.
The message number is IEC709I. ...
There's a contradiction here. It's impossible to issue a warning
message if the field is "not used or verified".
Thanks,
gil
> ... But you always need
>BLP=YES capability, because COPYMODS treats all tape labels as if they
>were data. When you run COPYMODS, all tapes have to be designated in
>the JCL, as BLP.
I had thought that EXCP could treat labels as if they were data regardless
of the LABEL option. But I guess this can't override the volser specified
in the DD statement.
Had I known about COPYMODS several years ago, I could have avoided
considerable trouble. We had committed to delivering a product on tapes
with VOL=SER=WD6000, and discovered when we attempted to produce
the first master that there was a DASD volume mounted with a similar
volser. Fortunately, it was not critical, and we were able to dismount the
DASD volume long enough to produce the master tape.
Our offline Tape Replication System balks at empty files; it will copy
nothing past one. We are constrained to supply an analogue of
"This page intentionally left blank." And our program management
sometimes balks at this and requires us to omit the dummy file and
adjust the position numbers in our documentation accordingly.
And I wondered what would happen if the volser conflict had occurred
in a customer shop, and with a critical DASD volume? Lately, we have
an IBM-registered component prefix (or several). Our recent FMIDs
incorporate the registered prefix as characters 2-4, and our product
tape volsers as characters 1-3, following IBM recommendations. All
IBM customers would do well to avoid other use of volsers beginning
with any ISV's registered component prefix. I doubt this is prevailing
practice.
I could be thoroughly perverse and use lower case characters in the
volser, assuming that no colleague would have the same idea.
They're accepted in a JCL DD statement if surrounded by apostrophes,
but not on TSO ALLOCATE or operator commands. TMS may have its
own ideas. (A vain consistency ...) (Example available on request.)
Thanks for your efforts,
gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
