Well I did ask for comments, so I got what I deserved. I do
appreciate the time you have all spent. If I do use some of your
great ideas, please do me a favor and don't sue IBM for taking your
intellectual property. I hate talking to lawyers.
I'll try to address some (hopefully all) of the issues:
1. Hitching your cart to the wagon. That is, adding on marginally
relevant (however worthwhile) enhancements to the PARM= >100
line item. So far:
a. The START command should support more than 61 characters
on a passed parm string. I've let the Console folks know
about the requirement.
b. The ASIS issue. Quotes in JCL, who knows on CALL, TEST, etc.
I will not likely be changing this, due to enough compatibility
concerns already. Would make a good SHARE requirement.
c. Support for inline DD * within procedures. I want it too.
2. Length 32K or 64K.
I've flip-flopped on this one and agree 32K is safer and likely
big enough for anything reasonable. This will avoid the issue of
a negative length and I hope to retire before I see JCL with
more than 32K of parms. Note that long parms are diced into SWA
block sized pieces (x'B0') bytes in length. Long parm processing
will be slow.
3. PARMLIB option to activate PARM>100
This is needed, not just for the compatibility issue. Even if we
forced a binder attribute, we still need a control to allow a
customer to get all systems in a JES plex to a level that supports
long parms before it is activated.
Once you accept that, then if we don't support a command to change
the setting, then we potentially force a sysplex wide IPL.
z/OS developers get demerits for these.
I believe we could do away with the DISPLAY support, in particular
if we add the message to JCL output when long parms are active.
4. Compatibility issue. Everyone is right. We shouldn't have to
worry about it, since it will unlikely be a problem, yet it will
break somewhere and cause lots of yelling and screaming. To do it
safe, we need a binder attribute. I am working on getting that
sized. If we can't contain the cost, then I would likely go with
only unauthorized programs getting long parms and if you don't want
to take the chance, then turn off the system wide option.
Since LE already supports long parms, we would want the C compiler
to automatically specify the long parm binder option.
As for a separate option for whether authorized programs can have
long parms, I would rather go with the binder attribute, since it
would be hard to verify that all authorized programs had been
checked.
5. As for TSO commands, CALL, TEST, TESTAUTH.
This has increased in complexity due to the untimely death of
Martin Gally. I will need to find someone else to take up where
Martin left off. We will all miss him.
6. SWA changes. Any program which cares about viewing or modifying
the parms in SWA will be exposed to an incompatible change. Once
this gets settled and targeted to a release, we will give as much
warning as possible. The SCTX would be unchanged. The SCT would
have a new field anchoring the chain of parm blocks. All parm
blocks would be above the line.
7. As for user exits, I imagine that one could code IEFUSI to look at
the SCT and make a determination as to whether to fail a job with
parms > 100. This assumes we don't have the binder option. With
the binder option, I would see no point in having any exit care
about this.
8. As for allowing the parmlib option to specify the max size parm
string to support, instead of just an on/off switch. Sounds like a
good idea. The default would be 100. Customers could set it to 256
and get some benefit out of it. I will look into this further.
The message we add to JCL output when the
length is anything but 100 could be something like this:
IEF777I PARAMETER LENGTH nnnnn DETECTED OUT OF POSSIBLE mmmmmm
SUPPORTED.
9. The other solutions involving a different JCL keyword (e.g. PARMX=)
or a PARMDD type solution were rejected due to cost and
incompatibility with exiting batch job streams. We would need to
implement the symbolic substitution in the specified file.
Ding/Ding - Round 2
Don Ault, 8-295-1750, 845-435-1750
----------------------------------------------------------------------
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
