Paul (et al): As I have alluded, there is a product available through IBM that can address all of these issues. If a JCL characteristic is allowed, the tool will ensure it is coded properly. If it is required, the tool will enforce any site-specific requirements. If it is not allowed, the tool will prevent any JCL from reaching any point in the change life cycle where it is inappropriate. It will also format each JCL statement in any order and number of keywords per site standards. Obviously, it does everything a team of "JCL experts" try to do manually.
Regards, Mitch McCluhan, Legacy Modernization Consultant www.lcmg.us -----Original Message----- From: Paul Gilmartin <[email protected]> To: IBM-MAIN <[email protected]> Sent: Sat, Nov 9, 2013 10:28 am Subject: Re: JCL 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 ike to see in JCL (or it's replacement). 've read your later, longer, well-reasoned followup. I agree with its pirit; 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, o request for execution time looping. (Converter time looping ight be a different matter.) Many of these are trivial; ninuscule. In the aggregate they ncrease the learning burden for newcomers and increase the hickness of the Reference Manual. I'll argue for consistency nd 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 ---------------------------------------------------------------------- or IBM-MAIN subscribe / signoff / archive access instructions, end email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
