On Tue, 3 Nov 2009 09:33:01 -0600, McKown, John wrote: >I still say dump the request for a change to PARM length max for JCL and/or >the PARMX=. For __NEW__ functionality, implement POSIX environment variables >into the JCL. Perhaps using the current SET syntax! Then __NEW__ programs can >do an getenv() type call to grab the environment variable(s) they are >interested in. The plus of this is that others, in other threads, have wanted >to be able to get the contents of SET variables in their programs. Again, this >would allow that. But it would take a change to the converter/intepreter as >well as the initiator. Another plus is that you could use this instead of >parsing the PARM field. > >For example, instead of: > >// EXEC PGM=MYPROG, >// PARM='VAR1=VAL1,VAR2=VAL2,VAR7=VAL7,VAR3=VAL3' > >You could have: > >// SET VAR1=VAL1 >// SET VAR2=VAL2 >// SET VAR7=VAL7 >// SET VAR3=VAL3 >// EXEC PGM=MYPROG > >and MYPROG would simply do a getenv("VAR1") to get the value of VAR1 and so >on. No parsing of the PARM= needed. > I'd almost support that. And a simple wrapper program to concatenate variables of a distinguished format could assemble a PARM of enormous length and issue a CALL. If the wrapper is not itself AC=1, there's no hazard of invoking authorized programs with oversized PARM.
My reservation? Use of symbols in the operand of SET is not supported. Damn! -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html