On Mon, 2 Jun 2008 16:19:43 -0400, John P. Baker wrote:
>
>One would think that after more than 40 years we could expect clear and
>concise documentation, but sadly, that is still not the case.
>
>Actually, documentation does not appear to contain anything clearly spelling
>out the rules insofar as symbolic substitutions and continuations are
>concerned.
>
>-----Original Message-----
>From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
>Of Patrick O'Keefe
>
>On Mon, 2 Jun 2008 11:04:35 -0700, Edward Jaffe
><[EMAIL PROTECTED]> wrote:
>
>>You're right. For some reason I remembered incorrectly that those
>>"extra" commas were "eaten" by the system and not surfaced to the
>>application. But, I guess not. :-(
>
My understanding is that "extra" apostrophes and outermost parentheses
are "eaten". I take no issue with this particular behavior; there's
good rationale for it.
>Not correctly remembering these intuitively obvious rules?
>For shame!
>
But overall I agree with the prevailing sentiment here, but with
a different perspective.
Documentation of JCL syntax is convoluted because the product is
chaotic. It needs not to be described, but to be repaired; made
uniform, orthogonal.
o The 100-character PARM limit should be relaxed. That thread
surfaced again today in MVS-OE.
o Restrictions on placement of instream data sets should be removed:
they should be allowed after any EXEC statement (i.e. with in PROCs).
(This was suggested and quickly refuted as a circumvention in the
same MVS-OE thread.)
o Symbols should be substituted wherever they occur, eliminating
the list of rules and restrictions. This includes:
- always between apostrophes
- as statement labels
- as statement command names
e.g. // SET S=SET
// &S X=&S
- as positional parameters on DD statements
i.e. // SET STAR='*'
// SET L=SYSIN
//&L DD &STAR
- in the bodies of instream data sets, however, in this case
enabled by an option on the DD statement.
etc.
o The restriction on splitting continued strings within symbol names
and doubled apostrophes and ampersands should be removed.
o The hedging on the description of the syntax of the boolean expression
on the IF statement should be removed: either it should be described
exactly as it works, or the "unpredictible" should be removed from
the description, and IF made to work exactly as described.
Etc. Simpler is Better. Consider how much ambiguous verbiage miget
be removed from the documentation!
-- 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
