On 5 Feb 2013 07:58:30 -0800, in bit.listserv.ibm-main you wrote: In the discussion below, I note that once again the JES2 customers get more new function than those using the higher priced JES3.
Clark Morris who still nurses a grudge because JES3 customers had to buy BDT(Bulk Data Transfer) to get SNA-NJE while JES2 customers got SNA-NJE built in. It was one of the nails in the coffin for JES3 at my shop. Thankfully we were able to get much of the function we needed by a combination of CA7 which we were getting anyway, A great exit 6 from the CBT tape which I extended to lo proc usage and set job class based on submitter and resources and an MPF exit. >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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
