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
