On Thu, 7 Nov 2013 22:19:18 -0600, John McDowell wrote: >I am curious to know what "things are on your list", regarding what you would >like to see in JCL (or it's replacement). > I've read your later, longer, well-reasoned followup. I agree with its spirit; in interest of brevity I won't quote it.
How long a post is allowed here? We'll see. I'll not challenge the fundamental static design of JCL. So, no request for execution time looping. (Converter time looping might be a different matter.) Many of these are trivial; ninuscule. In the aggregate they increase the learning burden for newcomers and increase the thickness of the Reference Manual. I'll argue for consistency and orthogonality whereever possible. Forgive any plagiarism. I may think of others or read suggestions and extend the list. o Allow TABs as whitespace in JCL statments. Some of us edit JCL on desktop systems and reflexively use TAB for formatting. the "invalid character" message then has a high Astonishment Factor. o More user-friendly convention for continuing quoted strings to a following line. Done properly, this might remove the last vestige of column 72 sensitivity. o Uniform DSNAME syntax. At present, on the DD statement hyphens are allowed in DSN=dsname; prohibited in DCB=dsname. Permit hyphens in both places. (I see no plausible rationale for this inconsistency other than Conway's Law; perhaps others can enlighten me.) o Relax any RECFM and LRECL limitations on JCLLIB data sets. o Allow UNIX directories in the JCLLIB list. o Relax RECFM and LRECL restrictions on instream data sets in library PROCs. o Allow UNIX directories in STEPLIB concatenation. o Support setting DCB attributes for allocated UNIX files by reference to model catalogued data set or referback, even as is possible for allocated legacy data sets. o Support overriding DSORG for allocated UNIX files and directories, even as supported for legacy data sets. o When DISABLE(DSNCHECK) is in effect, allow any data set name that might be catalogued to be specified. (Probably this would require that the name be quoted.) o Relax the RECFM and LRECL restrictions for the ISPF and TSO SUBMIT commands. (I know; this isn't JCL. But it's so closely related as to be relevant.) o Relax the JESLRECL=254 maximum in FTP (I know; ...) o When PROC calls are nested, support completely unambiguously qualified overrides and referbacks. (This might be done compatibly with existing control block layouts by supplying converter-generated proc step names.) I can't imagine that when PROC call nesting was made a requirement the requester expected lack of complete support for overrides and referbacks. o At present, substitution is performed for symbol names appearing in quoted strings in only three specific parameters. Support symbol substitution in quoted strings whereever quoted strings are allowed. o At present, the minimum syntax for defaulting SYSOUT class is SYSOUT=(,); SYSOUT=() is a syntax error. This is silly (but perhaps a LISP programmer wouldn't think so). Remove the requirement for the comma. o Even in a single statement, DD, there's lack of syntactic uniformity: subparameters of DCB are all keyword; subparameters of SPACE, LABEL, ... are all positional. Provide keyword forms for all. (The positional shorthand might be retained for brevity as an option.) o Simplify the SPACE parameter. The programmer shouldn't need to specify anything but (maximum) BLKSIZE (to be used in DCB merge for allocating buffers), average block size (to be used by allocation for calculating gap overhead), primary allocation size (bytes), and secondary extent size (bytes). AVGREC is bizarre: I studied it and experimented. I understood it for about an hour thereafter. Eliminate any need for AVGREC. Imagine: SPACE=(AVG=bytes,PRI=bytes,SEC=bytes), for any size data set up to the largest supported by hardware. o TYPRUN= (empty argument) is allowed in JES2; a syntax error in JES3. Make this uniform, either by permitting the JES2 syntax in JES3, or by providing an explicit assertion of the default (perhaps TYPRUN=RUN) in both. -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
