In a recent note, R.S. said: > Date: Fri, 13 May 2005 14:49:53 +0200 > > 256 bytes ? > IMHO it is not worth to change from 100 to 256. Many "should be enough" > limits occured much too short. > BTW: I know *existing* OS/390 application using more than 256 bytes in > PARM. It is c89 compiler. I vaguely recollect, it creates "pseudo job" > for compilation, this job looks like regular JCL, but all the compiler > options are in PARM field (many LINES of PARM) and that's why it is > circumvented in some way. I don't remember details, but the need is obvious. > As you note, it's a "pseudo job", so no circumvention is necessary. The compiler is invoked by an ATTACH macro; the JCL is never executed.
> Personally I vote for > //STEP EXEC ... PARMX=ddname > //DDNAME DD * > put here as much as you want (i.e. 64k) > /* > > Or (good for PROCLIB) > PARMX1=' ', > PARMX2=' ' > etc. > Then what? "EXEC whatever,PARM=(&PARMX1,&PARMX2)"? The constructed PARM string is still subject to the 100 character limit. Thinking on the idea of a Binder option to declare the ability of a program to accept a long PARM, there are a couple alternatives: o A PARMLIB option, allowing each installation to select what the JCL and TSO CALL PARM string limit should be. Any site could specify, 100, 255, 65535, or even a value less than 100 if that suited them. o A RACF privilege class identifying the set of users (none, some, or all) permitted to use long PARM strings in JCL or in TSO CALL. Otherwise, I wonder how the PARM is represented while a job is in the input queue? Does it reside in a control block? Is the structure of that block documented as a programming interface? Is there a hazard of other breakage if it changes? -- gil -- StorageTek INFORMATION made POWERFUL ---------------------------------------------------------------------- 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
