Coming from the z/VSE world, some of the JCL stuff in z/OS just is 'weird'.
1) In z/VSE, the conditional jcl statements are more logical, not
something akin to RPN.
2) Our SETPARMs are sequential. You can have multiple SETPARMs of the
same variable in the same step and intervening statements are processed
using the 'then value' of the SETPARM.
3) We can modify and even define SETPARM values via programs as a way to
pass information between steps.
Don't get me wrong, there are good things in both, but sometimes issues
with the underlying basics of each lead to strange 'higher level' items.
Working daily on z/VSE, z/VM and z/OS really get's confusing sometimes.
Even simple things like responding to a console message. z/VSE needs the
outstanding message number, followed by a space, then the response. Yet,
z/OS usually needs a comma where z/VSE had the space, but not always.
Tony Thigpen
Paul Gilmartin wrote on 3/30/20 9:57 AM:
On Mon, 30 Mar 2020 09:29:35 -0400, Tony Thigpen wrote:
Actually, it makes sense to me, in a strange way.
I don't know if I can describe why it makes sense, but I will try.
1) An // EXEC card is read and a 'step' begins. The // EXEC card itself
must be interpreted.
2) The rest of the step 'stuff' (until the next // EXEC) is read in to
the pre-processor.
3) The pre-processor first handles things that don't require read-ahead
processing to the end of the step.
4) The pre-processor next handles things that did require read-ahead
processing, such as "//PARMDD DD *,SYMBOLS=JCLONLY" that it could not
process on the first pass.
Now, why it worked without PARMDD is because the '// EXEC' is processed
and intrepreted before all the "let's get the step stuff now" logic
(step 2 above).
Like I say, hard to describe.
Sucks. WAD. Sucks.
I raised this issue here several years ago and got the
(condescending, IIRC) explanation: Of course it works that way.
The converter(?) builds a control block listing all EXPORTed JCL
symbol definitions for the step and passes that to the interpreter.
I suspect the substitution is actually performed by JES during
execution.
I had tried to use different values of the same symbol name in
multiple SYSINs in the same step.
I resorted to a cumbersome renaming so names would be
distinct.
IBM could have done better. IBM doesn't care.
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
