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. Who on earth would want to code dozens or *hundreds* of JCL cards? How many could you possibly override in any give run? For what purpose? One problem I've seen in recent years is REXEC, where the pathname-command can be a very long PARM= string. Again, there are already alternatives by way of side files to supply the data needed. 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? 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 Southern California Edison Company SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile [EMAIL PROTECTED] IBM Mainframe Discussion List <IBM-MAIN@BAMA.UA.EDU> wrote on 05/12/2005 14:36:08: > 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. > <snip> > > What do you think? > > Peter Relson > z/OS Core Technology Design ---------------------------------------------------------------------- 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
