On Wed, 4 Jun 2008 13:25:53 -0500, McKown, John wrote:
>
> ... I would prefer that JCL be VB.
>There would be no sequence numbering at all.
>
Bravo!
>2b) Embedded comments require a /* to start and */ to end. Comments may
>be embedded within comments. This means that every /* must have an
>corresponding */. This is to allow commenting-out of information which
>itself contains comments. I hope I'm making sense. /* this is /* an
>embedded */ comment */.
>
Does this allow multi-line comments? Multi-line comments
can be a debugging nightmare.
>4) New subparameter on the EXEC. LPARM= for a long parm which can be
>more than 100 characters. All this does is remove the JCL restriction.
>It would be used by a user who wants to pass more than 100 characters to
>a program which he knows can handle this situation. The only reason to
>have LPARM= instead of removing the restriction on PARM= is due to the
>possibility that the program cannot handle > 100 characters and the user
>wants to be told, via a JCL error, if he exceeds the 100 character
>limit.
>
Does long PARM conflict with existing control block structures?
>6) A new parameter on the DD * and/or DD DATA, SYMBOLS=YES. This tells
>JES2 to examine the instream data, looking for symbols which can be
>resolved, such as &SYSUID, &HOME, a static system symbol, or any other
>symbol set with the // SET statement, and replace the symbol with its
>value. If there is no value for that symbol, leave the symbol alone.
>
Allow instream data sets in PROCs. A preprocessor could handle
them by converting them to overrides.
>7) Allow UNIX paths in the JCLLIB statement so that I can keep my PROCs
>in a UNIX subdirectory. No, there is no reason for this.
>
JCLLIB should have the syntax of a DD statement, like STEPLIB.
This would allow both UNIX paths and uncatalogued data sets.
(Yeah, I know, the initiator handles STEPLIB; the converter
would need to handle JCLLIB.)
>Some of the above, I could actually by writing a JCL pre-processor to
>take the Enhanced JCL and "compile" it to standard JCL. The biggest
>problem that I might be with long PARM statements that could not be
>broken at a comma.
>
A preprocessor could rely on the fact that somewhere after
column 59 (or so?), there must be a breakable point which
does not fall within:
o A symbol name
o A doubled apostrophe
o A doubled ampersand
break at that point and pad through column 71 with:
// SET N=''
&N from column 69
&N. from column 68
&N&N from column 67
&N&N. from column 66
&N.&N. from column 65
&N&N&N. from column 64
etc. '+' in column 72 and continue in column 16 of the
next line. (No, I do not consider the availability of
this cumbersome circumvention to justify the restrictions
in the current JCL processor.)
Reference to undefined symbols should be treated as JCL
error.
Abolish the "SYSIN DD * GENERATED STATEMENT". I never
use the construct deliberately. It happens only when
I've made a typo; omitted a '/' or whatever, in which
case I'd much prefer it to be treated as JCL Error.
Use of any construct documented as "unpredictable" in
the JCL RM should be treated as JCL error.
If the label(s) on the ENDIF (and ELSE) do not match
that on the IF, the construct should be treated as a JCL
error in order to assist debugging.
(The current JES2 behavior with long lines is that JCL
statements are quietly truncated after column 80, then
treated as card images. Instream data sets are processed
to their full input length. The jobstep program may
get I/O errors if it assumes F-80.)
-- gil
----------------------------------------------------------------------
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
