In a recent note, Bob Rutledge said:
> Date: Mon, 5 Mar 2007 19:22:08 -0500
>
> How is it not working? Is not // DD DDNAME=MOREDD being treated as DD DUMMY?
>
I see that it's documented that it should work that way:
#<<< 12.17.5 "z/OS V1R7.0 MVS JCL Reference"
12.17.5 Location in the JCL
...
Errors
in Location of Referenced DD Statement
The system treats a DDNAME parameter as though it were a DUMMY parameter and
issues a
warning message in the following cases:
* If the job step or called procedure does not contain the referenced DD
statement.
Ugh! I don't like this because of a feature of DUMMY (also documented),
which I intensely dislike:
#<<< 12.24.4 "z/OS V1R7.0 MVS JCL Reference"
12.24.4 Relationship to Other Control Statements
...
The system treats data sets concatenated to a DUMMY data set as dummy data
sets in that
I/O operations are bypassed. However, the system performs disposition
processing and
allocates devices and storage for any concatenated data sets.
I see little point in that design; it was a rude surprise when I
discovered it by accident. I would find it far more useful if I/O
operations on data sets concatenated to a DUMMY data set were performed
normally; then I could nullify one catenand as DUMMY and leave the
remaining catenands in effect; or, I could nullify all succeeding
catenands as DUMMY if I desired that instead. As it is, if I wish
to nullify only one interior catenand, I allocate a temporary data
set (DISP=(,DELETE),SPACE=0) in its place.
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
