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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
