On 2015-12-23, at 05:44, R.S. wrote:
>>
>> I hate JCL!
> Just curious: why do you need to insert SET into DD concatenation?
>
No "need" just style for clarity. I could have put all my SET
statements a hundred lines earlier, immediately after JOB. Instead
I thought my JCL would be easiest to read if I placed each as close
as possible to the references to its value. See modified example
below.
On 2015-12-23, at 05:55, Hardee, Chuck wrote:
> The reason is that the Converter/Interpreter is expecting data as a result of
> the "//DD2 DD *".
> It found none so it is now looking for a new "starting" JCL statement.
> It found one, the "// SET" statement.
> After processing the "// SET" statement it again looks for a new "starting"
> statement.
> It didn't find one, at least not syntactically correct. It recognized the
> next statement "// DD ...." as a DD statement, but since the previous DD had
> been terminated by the "// SET", the JCL rules call for the first DD in a
> concatenation (even a concatenation of 1 DD statement) to have a label. This
> DD does not have a label so it is assumed to be a continuation, but there is
> no logically "active" DD in effect so, you get the "misplaced DD statement"
> error.
>
> Make sense?
>
No.
I routinely code empty SYSIN, perhaps just to save keystrokes, as in:
//STEP EXEC PGM=IEBGENER
//SYSIN DD * # Nothing here; works fine.
//SYSPRINT DD SYSOUT=(,)
...
And my rewritten example:
//*
3 //STEP EXEC PGM=IEFBR14
//*
4 //DD1 DD * # "DD *" with no data is just fine.
5 // DD *
//*
6 // SET V1=WOMBAT
7 // DD PATH='/tmp/&V1'
//*
IEFC653I SUBSTITUTION JCL - PATH='/tmp/WOMBAT'
8 // SET V2=XYZZY
9 // DD PATH='/tmp/&V2'
//*
IEFC653I SUBSTITUTION JCL - PATH='/tmp/XYZZY'
10 //DD2 DD *
11 // SET V3=WOMBAT
12 // DD PATH='/tmp/&V3'
IEFC653I SUBSTITUTION JCL - PATH='/tmp/WOMBAT'
13 //
STMT NO. MESSAGE
12 IEFC019I MISPLACED DD STATEMENT
******************************** BOTTOM OF DATA **********************
All the assertions you make should have been equally true of the empty
instream data sets at line 4 or line 5. Why does the C/I accept those
but reject the one at line 12?
I invite, even challenge, any IBM representative to provide a plausible
rationale for the restriction in the Reference that Lizette and I cited.
How does that rule benefit customers? Rather, it makes the Reference
thicker, increases the learning burden on programmers, and engenders an
unpleasant Astonishment Factor. I suspect it arose througn no purposeful
design, but through developer ineptitude and indolence. It didn't work
as intended, so they documented it and called it a feature.
I hate JCL!
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
