Like everyone else who has replied so far, I think lifting the 100 byte
restriction is a good idea. But let's be careful about over-architecting a
solution to a real but--c'mon guys--a minor problem. The run-time PARM=
serves two main purposes:
1. Supply quickly and simply a modest number of run-time overrides by mere
JCL manipulation.
2. Provide critical information to a program about how it's supposed to
begin execution, e.g. DDNAMEs to OPEN in lieu of default ones or a date in
lieu of 'today'.
The call for thousands of bytes of data is overkill. If your program
depends on that many knobs and switches, then it should support a PARMFILE.
For example, JESx offers hundreds of options in the PARMFILE deck but only
a handful of PARM= keywords on START JESx. These subsystems demonstrate the
appropriate use of each kind of control mechanism.
The problem with this approach is that there is no standard way to provide a DDNAME with parameters. And even the non-standard ways that each individual program creates absolutely require a concrete parameter file be known at the time a proc is written. Using the JCL parameter allows a standard style to communicate the parameters and it allows the resolution of the parameters to be delayed until the proc is executed.
Late binding of those parms becomes a big deal as systems get larger and more complex.
I'm not saying that JESx isn't complex, but from a JCL perspective it is quite simple -- a single job step with a single control file and a single instance per machine -- 1 * 1 * 1 is pretty simple. Any started task is going to be pretty much that simple.
Consider a system that runs for a few hundred clients with a few hundred daily jobs, each with a few dozen steps, each with a parameter file -- 100 * 100 * 24 * 1. Even a small system quickly has a huge number of possible parameter file configurations.
Who on earth would want to code dozens or *hundreds* of JCL cards?
No person in their right mind, and few in their left mind.
How many could you possibly override in any give run?
Any or all of them, that is why the are parameters and not hard coded values embedded in the program.
For what purpose?
To delight one's employer and/or clients so that they give you money ... isn't that what enterprise computing is really all about?
The fact that non-JCL program execution supports 32 KB is quirky but
irrelevant. Be honest: has anyone here really needed to pass an entire page
worth of data at execution, let alone eight pages? Was this need so dire
that processing an option file was an onerous burden?
Many times. Pretty much everything I write can be invoked from within a program or as a job step (after all, INIT is just another program). To my mind, the 100 byte parm is a limitation on an otherwise acceptable number of 32k or 64k.
The call for thousands of bytes, 65535 to be exact is because it is simple, the current format supports such a thing. Any number you selected is going to be inadequate for some purposes, as 100 bytes is now -- but the larger the number, the fewer instances of inadequacy. That 65535 fits in the already existing halfword makes it an easiest change with the least number of inadequacies.
Let's just KISS: increase the allowable string length to 256. That should
be plenty for any well-designed application. Most assembler programs that
choose to store the entire PARM= string pick up the length and execute a
move instruction: EX Rn,SAVEPARM. This technique will work fine for
anything up to 256; it will fail miserably for even one byte more. If a
program overruns a 100-byte work area, then that program will have to be
changed. Let's not opt for a solution that requires *every* program to be
changed. Let's leave the menagerie of JCL keywords alone. LET'S LEAVE
BINDER ALONE--PUHLEEZE. Let's build a little swatter to squish an
irritating gnat.
We have to remember that resources expended on one wish-list goody are
unavailable for other goodies. Surely there are more luscious goodies than
this to crave.
JO.Skip Robinson
Consider a simple Cobol compile -- there are some 60 or 70 options, each with four or five possible values. Add in integrated translator for CICS/DLI, another few dozen options. Add in the SQL integrated preprocessor for another few dozen options. You could exceed 256 just in keywords and opening and closing parens.
Ok, now I will admit that most of those 150-or-so options will not be needed and can be allowed to default. But consider just a few that are quite large. Think of the DB2 preprocessor VERSION option -- at the very least you need the library name (44 chars) and/or a timestamp (26 chars) to make a unique, but identifiable, version id so that you don't trash other copies of that package bound to the same DB2 subsystem. Just that single option, VERSION(44C+26C) is close to a third of the 256-bytes you would provide.
[EMAIL PROTECTED]
This tagline intentionally left blank.
---------------------------------------------------------------------- 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
