In <[EMAIL PROTECTED]>, on
06/04/2008
at 01:25 PM, "McKown, John" <[EMAIL PROTECTED]> said:
>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.
It's also important to not break existing JCL.
>1) Remove the "card image" requirement. JCL basically starts with a //
>in columns 1-2 and is 80 bytes long for a single line.
The Devil is in the details. I like the basic suggestion, but I disagree
with regard to sequence numbers. I'd prefer for the last 8 columns to be
sequence numbers for FB and the first 8 for VB. I'm not sure whether
there's a way for the C/I to tell which is which, and I'm not sure of the
best way to handle continuation for VB.
>There would be no sequence numbering at all.
That breaks existing functionality. Currently I can look at the error
messages and direct the editor to the line in error, even if there are
multiple lines with the same contents.
>2b) Embedded comments require a /* to start and */ to end.
That's reasonable if and only if the imbedded comment is somewhere where
/* is currently illegal.
>2c) All characters after a double dash, --, are comments until the end
>of the logical line and are ignored.
That's reasonable if and only if the comment is somewhere where -- is
currently illegal.
> //DD1 DD DISP=SHR, -- THIS IS A COMMENT
That would be a comment even without the --.
>3a) If the last non-blank, non-comment is a comma, then the next logical
>line is a continuation of this line.
That's current syntax outside of apostrophes. Doing it for text inside of
apostrophes would break existing JCL. The same issue exists for 3b and
3c..
>As can be seen by 3b & 3c, you can continue a qouted string across
>multiple lines.
You can already.
>This eliminates the problem of a long string being
>passed in a PARM or PATH=.
What problem?
// EXEC PGM=FOO,PARM=(TOM,
// DICK,
// HARRY,
// 'Tom, Dick and Harry are out')
>4) New subparameter on the EXEC. LPARM= for a long parm which can be
>more than 100 characters.
It's a good idea, it's been discussed before, and there are some
compatibility issues that IBM would have to resolve if they accepted a
requirement.
>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.
As you noted, that has the same problem as other system symbols; on which
system do you look up the user? I wouldn't expect IBM to do anything about
this unless they also provided a solution for static system symbols, and
they don't seem to like the idea of using the conversion system. And, no,
I don't agree with IBM's position.
>Thought: should the tilde, ~, expand to the user's home directory as is
>normal in UNIX shell scripting?
Yes. IMHO the expansion should be at run time.
>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.
Yes. This has also been discussed before.
>7) Allow UNIX paths in the JCLLIB statement so that I can keep my PROCs
>in a UNIX subdirectory.
Yes.
>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.
Yes, but why not use the keyword from the DD statement rather than a new
keyword? INCLUDE PATH= works for me.
>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).
There used to be a subsystem (GPSAM?) on the CBT that would be a good
starting point, although it would be nice if IBM provide a standard
subsystems for this.
>Just some thoughts.
If you want it to go anywhere, you'll need to write it up and submit it as
a formal requirement, with a sound business case.
In <[EMAIL PROTECTED]>, on
06/05/2008
at 11:59 AM, "McKown, John" <[EMAIL PROTECTED]> said:
>It is not TSO, per se. It is the way that the program uses TSO parse.
In the case of data sets allocated to the terminal, it's controlled by the
TSO support in BSAM/QSAM, not by the application, and doesn't involve
PARSE.
In the case of a data set name in apostrophes, it may be IKJDAIR rather
than IKJPARSE that converts it to upper case.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)
----------------------------------------------------------------------
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
