32760 = max[n | (n <= 32767) & (n = 0 mod(8))] On 2/5/13, Paul Gilmartin <[email protected]> wrote: > On Tue, 5 Feb 2013 07:27:11 -0600, John McKown wrote: > >> http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=ca&infotype=an&appname=iSource&supplier=877&letternum=ENUSZP13-0013 >> >>In z/OS V2.1, a number of JCL improvements are planned: >> >>Support for passing parameter lists up to 32,760 bytes in length to a >>program from JCL. A new PARMDD DD statement keyword is planned to >>allow more than 100 characters to be passed to any program in JCL. A >>new LONGPARM binder attribute is planned to enable APF-authorized >>programs to use this new function. No changes are planned to be needed >>for unauthorized programs. This new support is intended to make it >>easier to pass a large number of parameters to a program without >>writing intermediate programs. >> > Yaaay! But why not 32767 or 65535? Actually32760 is plenty; just > curious. Try passing HLASM 32768 to witness some bizarre behavior. > But BPXBATCH is happy with 65535. > > This has considerable overlap with: > > | execute the program with an argument greater than 100 bytes, then a > BPX.EXECMVSAPF.program_name profile should be defined. > > Do we really need two ways of doing this? If they conflict, which one > predominates. (This was introduced by APAR which I'd call an integrity > APAR, which was mentioned in the manual. The reference to the APAR > seems to have vanished.) > >>Enhancements for symbol processing in JCL in JES2 environments. This >>new function is designed to make both JCL and system symbols available >>during job execution. For example, you will be able to specify that >>symbols be used in instream data sets, such as SYSIN data sets, and >>that symbols be retrieved from the system using new programming >>services. This support is intended to make symbols more usable and >>accessible and to make it easier to use identical copies of JCL in >>multiple environments. >> > Yaaay! Synergistic with PARMDD. But still no system symbols in > batch JCL? Rats! How is record overflow handled when a > symbol's value exceeds the length of its name. 72-column > limitation? Continuation convention? > >>Support for the use of exported JCL symbols that are accessible in >>other contexts, including programmatic access. A corresponding >>function is planned for Language Environment . >> >>Support for new, JES-independent JCL specifications. New SYSTEM and >>SYSAFF keywords for the JOB statement are planned to allow you to >>specify z/OS MVS� system names, JES2 MAS member names, and JES3 main >>system names. Both job entry subsystems will be designed to direct the >>job to an appropriate system. >> >>JES2 is planned to add support to allow you to specify the JES2 >>procedure library concatenation to be used for a job, improve OUTPUT >>processing by allowing you to specify that an OUTPUT statement be used >>for multiple SYSOUT data sets, and optional improvements in >>converter/interpreter processing. These changes are intended to make >>it easier to write JCL that can run unchanged under either primary >>subsystem, JES2 or JES3. >> ... >>JES3 is planned to support in-stream data sets in cataloged procedures >>and INCLUDE groups. This is intended to allow you to simplify the JCL >>used in PROCs by using in-stream data sets in place of those pointed >>to by DD statements that use the DSN keyword. >> > Didn't this appear a release or two ago? Or only JES2? May we assume > (always dangerous to assume consistency from IBM) that those > instream data sets may include PARMDD, with symbol substution, and > that different symbol values will be substituted if the same PROC is > invoked in different steps? (I.e. the substitution is performed at the > point of PROC expansion, not at PROC definition.) > > -- gil > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN >
-- John Gilmore, Ashland, MA 01721 - USA t. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
