Gil, if you hate JCL, why not look at Jol? With simple English like syntax.
It does more than JCL, run in backgound/batch or you can execute jobs
under TSO.
It has a simple PANEL instruction to make interactive screens.
You can pass Symbolic Parameters from job to job.
It has a Scheduling Facility.
There are versions that run under Z/OS, Windows and Linux - even OS/2.
The Windows and Linux versions will create JCL or TSO pseudo code OR
execute programs on Windows and Linux.
See http://start.oscar-jol.com/
Cheers,
Clem Clarke
much what JCLPaul Gilmartin wrote:
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
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
