I would vote for the DD solution. A reserved (maybe changeable) DD name for the long PARM's
The current continuation rule's in the JCL PARM are very strange.
We could keep this somehow with an XPARM or PARMX,. If you simply extend the PARM length , nobody could foresee the
effects.
At first, I agreed with this, for two reasons (details below):
1. It obviates the buffer overflow problem.
2. It's already difficult to pass parms with embedded quotes, spaces, and parentheses when continued.
I disagree with it, though, for implementation reasons. Pointing the parm to a DD means that the system will have to open that DD, read the data, parse it, and then give it to the program. If you want that done, why not just program it yourself and have even more flexibility? Several programs (like Sort) do just that. Many uses of the PARM= are specifically to have those parms in the JCL where they can be easily seen and manipulated by scheduling packages and ISPF skeletons processing.
OTOH, almost anything you do within JCL hits the problem of continuing the command across several card images. Perhaps if the XPARM pointed to a // PARM statement (like the // OUTPUT statement), the // PARM statement could have less arcane continuation rules than the PARM= parameter of the EXEC statement.
As I was typing this, I realized that I think that Gil had the right idea (Message-ID: <[EMAIL PROTECTED]>); an attribute on the load module that allows for more than 100 characters in the parm. If the attribute is off, and more than 100 characters are coded, it should abend. An overt action is required to say that a particular program supports more than 100 characters, even if no code change is needed. The main difference between now and this proposal is that now the job will get a JCL error immediately instead of an abend when it runs.
This proposal doesn't make coding the parm across statements any easier, but at least it doesn't make it any harder.
Promised details from numbered points above:
1. Somewhere, there are programs, possibly APF authorized programs, which rely on the fact that PARM= can't specify more than 100 characters. (Maybe no one on *this* list has coded any, but it's a safe bet that they're out there, somewhere.) Let's not let that cause system crashes. Let's *especially* not let malicious users take advantage of it. We should leave that kind of thing for other operating systems.
One of the benefits of running a successor to OS is that most programs written and assembled nigh on 40 years ago can still run. Some do. Let's leave them doing so, safely.
2. Continuing any JCL statement at other than the end of a subparm requires many people to grab the JCL manual. Doing so within a PARM= adds yet another complication (e.g. the parentheses requirement). Passing a parm with, for instance, 80 consecutive blanks is tricky. (No need to post the answer; I'm just saying it requires more thought than it ought to.)
---------------------------------------------------------------------- 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
