On 10/24/2012 10:55 AM, Paul Gilmartin wrote:
In JCL I specified UNIT=esoteric-for-(virtual)-tape device. z/OS
instead allocated DASD. After some thrashing around and asking
the requester if he knew what was going on, I apealed to our systems
programmer, who said:
... in that job that you did not get any tape mounts for that
first step. The reason was because the SMS ACS routines
recognized the XXXXXX hilevel qualifier and assigned it to the
YYY storage class. The YYY storage class has the GUARANTEED
SPACE attribute set to NO so the UNIT and VOLUME parameters were
ignored. If the GUARANTEED SPACE attribute had been YES, we
would have gotten some type of a conflict message and the job
would have failed earlier.
Is there any MSGLEVEL I can specify that will tell me exactly what
happened, and why so I neednt bother the sysprogs? Or, perhaps
a utility (cbttape.org?) which will analyze a DD statement image
and tell me what really happens?
This design is WRONG! It's fine for SMS to supply elided options,
but any options explicitly supplied by the programmer should be
honored, or result in a JCL error _clearly_ describing the cause
and citing the applicable SMS rule. The message I received about
missing SPACE option wasn't helpful. Is there a setting for this?
There's too much DWIM here.
-- gil
...
The design is not totally wrong if the shop has a data set naming
standard for tape and DASD data sets and you violated that standard.
Granted, more helpful messages warning of conflicts would be better, but
sometimes users do things that SysProgs didn't anticipate (or haven't
been given enough free time to resolve more cleanly).
There may be a legitimate installation reason why preventing the
creation of non-standard-named datasets on tape was judged as higher
importance than failure clarity. For example, creating a test MVS, tape
management system test environment can be simplified, and recovery from
some types of catalog failures or Tape Management System failures can be
simpler, if all cataloged tape data sets are isolated to specific user
catalogs and not mixed indiscriminately with non-tape data sets.
--
Joel C. Ewing, Bentonville, AR [email protected]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
