I like most have had to deal with the strange limit of 100 characters on the PARM statement. I would support raising the limit in any way that would not break the old programs still running. That is the passing of the PARM value should be done in the same way as today. This way, current programs would not need to even be aware of the change. (Yes some person could change the JCL to pass more than 100 characters to a program that would not handle it, but then that person needs to change the program first. IE 255 as a max.
Now as for breaking the 8 bit limit, I would say a new parameter in the JCL that can not be used if PARM is. The only thing with the keyword name is; one should look down the line when the current PARM is not used / supported, if ever, and only the new keyword is in use. Use XPARM, PARMX ... whatever as the keyword; but the way the parameter is passed would seem to be the important thing. RR1 => full word length followed by value, program would have to know that the new keyword was used. RR1 => 2 full words. One being the length of the value, the other pointing to the value. So the address of the value is not necessary in storage right next to the length of the value. Use R0 to contain the length and R1 point to the 8 bits of zeros followed by the value, so an old program thinks the length is zero and no PARM was passed. Use a macro to get the length of the PARM and its location, returned in R0 and R1. Let MVS deal with the where the PARM and address are hidden in some control block. R1 on entry would look as if no PARM was passed. Or any of a number of other ways to get a long parameter list to a program. The second thing IBM should provide is a macro that would convert the new PARM format, back to the old one, when the length is 100 characters or less. This way the JCL could be changed to the new way and with a small change, insert MACRO x in the program, all will be well. Kenneth Leidner Imagination is more important than knowledge. -----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Paul Gilmartin Sent: Friday, May 13, 2005 11:07 AM To: [email protected] Subject: Re: PARM= 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 ---------------------------------------------------------------------- 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
