Gil, For the DD * statement, have you tried this? //DD2 DD * /* // SET // DD PATH= ....
Maybe the terminator /* after a DD * might work? Lizette > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf Of Paul Gilmartin > Sent: Wednesday, December 23, 2015 7:13 AM > To: [email protected] > Subject: Re: Where is SET allowed in JCL? > > 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 [email protected] with the message: INFO IBM-MAIN
