This is a blue sky idea for discussion. It is not a request to IBM. But
it derives from an earlier thread on the short comings of the current
JCL. So, I was just thinking of possible enhancements which should not
affect the "internal text" or only do so minimally. Just some idea. I'll
try to organize them logically, but no guarantees.
1) Remove the "card image" requirement. JCL basically starts with a //
in columns 1-2 and is 80 bytes long for a single line. So, my first
desire is to remove this requirement. I would prefer that JCL be VB.
There would be no sequence numbering at all.
2) JCL comments:
2a) any line which starts with //* is totally ignored as if it weren't
there. This means it can be placed
in the midst of a series of continuations. Eg:
//DD1 DD DISP=SHR,
//* DISPOSITION
// DSN=THIS.FILE
//* THE NAME OF THE DATASET
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 */.
2c) All characters after a double dash, --, are comments until the end
of the logical line and are ignored. Eg:
//DD1 DD DISP=SHR, -- THIS IS A COMMENT
3) Continuation.
3a) If the last non-blank, non-comment is a comma, then the next logical
line is a continuation of this line. The first three characters of the
next line must be "// ". The continuation actually starts with the first
non-blank after the third character of the next line. Eg:
//DD1 DD DISP=SHR, -- SPECIFY DISPOSITION HERE
// DSN=THIS.FILE -- THE NAME OF THE DATASET
3b) If the last non-blank, non-comment is a dash, -, then leading blanks
on the next line are not ignored and the continuation starts with the
fourth character of the next line. Blanks before the dash are
significant. Eg:
//STEP1 EXEC PGM=MYPROG,PARM='THIS IS -
// THE PARM'
//* PARM='THIS IS THE PARM'
3c) If the last non-blank, non-comment is a plus, +, then leading blanks
on the next line are ignored. The continuation strats with the first
non-blank after the third character of the next line. Note that the
current line need not end in a comma to indicate continuation. All
blanks before the plus are significant. Eg
//STEP1 EXEC PGM=MYPROG,PARM='THIS IS +
// THE PARM'
//* PARM='THIS IS THE PARM'
As can be seen by 3b & 3c, you can continue a qouted string across
multiple lines. This eliminates the problem of a long string being
passed in a PARM or PATH=.
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.
5) New predefinded symbol: &HOME . This is the RACF user's OMVS "home"
subdirectory (without an ending slash) as specified in the OMVS segment
for the user. If the user does not have an OMVS segment but the "default
UNIX user" is defined, then it is the "default UNIX user's" home
directory. If neither of the previous two are available, then a JCL
error results if &HOME is used. Eg:
//INPUT DD PATH='&HOME/filename.txt'
I realize this symbol has the same problem as some of the other symbols
which might vary depending on the system. However, I would state up
front that this symbol is resolved on the system which does the
conversion, at the time of the conversion. If something else is wanted
(as with an NJE job), then the user would need to use some other method
to do this.
Thought: should the tilde, ~, expand to the user's home directory as is
normal in UNIX shell scripting?
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.
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.
8) Allow the // INCLUDE to have a new parameter: FILE= which specifies
the UNIX file to INCLUDE instead of a member from the JCLLIB
concatenation. If the FILE= specified does not start with a slash,
assume that the FILE is relative to the user's UNIX HOME directory as
with &HOME. Again, a JCL error if this cannot be resolved.
9) Similar to 6 above, but maybe somebody here would like to do it. A
subsystem which can be used on a DD statement to translate system
symbols to their value as lines are read from the file (be it a dataset,
UNIX file, or instream). This could either be done by specifying another
DD statement which points to the input stream or, more advanced, which
dynamically allocates the input stream (won't work for instream, of
course) as specified by the DSN or PATH. Eg:
//INPUT DD SUBSYS=(XLAT,'DD=INPUT0')
//INPUT0 DD DISP=SHR,DSN=INPUT.DATA.SET
Try reading up on EZACFSM1 at:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/F1A1B371/1.2.
10.1
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.
Just blue skying. Not a requirement. Just some thoughts. Maybe I just
need more sleep?
--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology
The information contained in this e-mail message may be privileged
and/or confidential. It is for intended addressee(s) only. If you are
not the intended recipient, you are hereby notified that any disclosure,
reproduction, distribution or other use of this communication is
strictly prohibited and could, in certain circumstances, be a criminal
offense. If you have received this e-mail in error, please notify the
sender by reply and delete this message without copying or disclosing
it.
----------------------------------------------------------------------
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
