We all know and love (well, at least know) that the limitation in JCL for PARM= is 100 total characters. We are thinking (again) about expanding this, and would like to hear your thoughts.
Some of the possibilities include
- just extending, in JCL processing, so that the target routine
gets what it does today (halfword length followed by string,
only the string would potentially be >100). This is obviously
the nicest from the target routine's perspective if it can handle
the extended length
- a service that the target routine can call to "give me my parameters".
Obviously the target routine would have to change in order to utilize
that service, and likely would have to dual-path for systems that do
not have the service
One choice that proved not feasible was using a second parameter. Various utilities already take advantage of the "known" structure and pass additional data as additional parameters.
Some of the potential problems an existing target routine might have
with an extended length parameter are
- It provided an area via DS of 100 characters, "knowing" that the
limit was 100, and then did an EX (execute) of an MVC to move the
parameter string, using the length in the halfword. Unfortunately,
if the length is (for example), 256, this would overlay the next 156 bytes
- It did some operation (MVC, TRT, whatever) that is limited to 256
characters which works fine when the limit is 100, but if the routine
was passed 257 characters of data, it might process that as 257 mod 256
characters in some ways.
What do you think?
Peter Relson z/OS Core Technology Design
I would be quite happy if you expanded the current PARM keyword to allow for 65535 chars. This could have some issues for older programs, but the benefits when running parameter intensive job steps (like IMS or a compiler) are worth the trouble.
There are two other issues with JCL that I wish you would consider addressing at some point. Allowing instream datasets in JCL procedures and symbolic replacement in parameter datasets.
Possibly because of the historically short parameter length, many programs use files instead of JCL parms for simple control statements. This leads to the creation of two very common user written utilities -- a JCL-parm-to-dataset utility and a replace-symbolics-in-a-dataset utility. I believe there are several versions of both of these available from the CBT tape and other sources.
Getting a client to install unsupported freeware or convincing one's own management to allow unsupported freeware is often a problem. Thus it seems that every shop has a completely different way of doing these two simple but very necessary tasks. Most of the flavors of these utilities are quite easy to use, but they all consume one of the very precious 255 job steps.
Rather that write:
//BLAH PROC HLQ=PROD
//*
//S1 EXEC PGM=PARM2DS,PARM=' DELETE CLUSTER(&HLQ..SOME.DATA.SET.NAME) '
//POUT DD DSN=&&DELPRM,...
//*
//S2 EXEC PGM=IDCAMS
//SYSIN DD DSN=&&DELPRM
...
I would much prefer something like:
//BLAH PROC HLQ=PROD
//*
//S1 EXEC PGM=IDCAMS
//SYSIN DD *,SYMBOLS=YES
DELETE CLUSTER(&HLQ..SOME.DATA.SET.NAME)
/*Not only is it clearer to read and understand, but it would save a step. It might look trivial in the simple example above, but with more complicated, multi-line parameters these home spun utilities start to make JCL look quite nasty.
Anyway, I'm looking forward to an expanded PARM option.
Thanks for listening,
Joe Zitzelberger [EMAIL PROTECTED]
---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
