Gil, I agree 100%, but I'll add that *both* would be valuable (>100 parm, and JCL/SET variables visible).
Kirk Wolf Dovetailed Technologies On Mon, Sep 21, 2009 at 11:48 AM, Paul Gilmartin <[email protected]>wrote: > On Mon, 21 Sep 2009 11:03:31 -0500, Kirk Wolf wrote: > > > >My suggestion for having JCL/SET variables in a ASASYMBM "user" table has > to > >do with what a program would see when it runs in the initiator. Of > course, > >each step would see different variables/values. > > > Gilbert has concocted a more bizarre example. > > >On Sat, Sep 19, 2009 at 2:06 AM, Gilbert Saint-Flour wrote: > > > >> > >> What Kirk Wolf calls "ASASYMB-style symbol table" has a simple format > >> because > >> each variable it contains has a single (and stable) value. The structure > of > >> a "JCL variable symbols" table defined when the job's JCL is analysed > would > >> be more complex because a variable can by set several times in a job, > even > >> in > >> a job step. Example: > >> > >> // SET VAR=AAAAAAAA > >> //STEP1 EXEC PGM=MYPROG,PARM=&VAR > >> // SET VAR=SYS1.MACLIB > >> //DD1 DD DSN=&VAR,DISP=SHR > >> // SET VAR=SYS1.MODGEN > >> //DD2 DD DSN=&VAR,DISP=SHR > >> > >> When MYPROG looks for the value of &VAR, what does it find ? AAAAAAAA, > >> SYS1.MACLIB, or SYS1.MODGEN ? All three ? No, this definitely can't > be > >> as simple as ASASYMB. > >> > It depends on the perceived objective. If it is that the program > executing be able to know the names and values of all symbols which > might have affected the conversion of the job step that is, as > you observe, very difficult. > > If, rather, it is to provide the programmer a mechanism to pass > name/value pairs to the program, fixing the bindings at the point > of the EXEC statement is quite sufficient. > > All in all, we've lapsed into a form of tunnel vision. More > generally useful would be a relaxation of the 100-character > PARM limit and/or native support of symbol substitution in > SYSIN data sets by the reader/converter/interpreter. But we've > been so conditioned to perceive either of those possible > enhancements as violations of Natural Law that we flounder about > proposing ever more bizarre (and perhaps less practical) alternatives. > > -- 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
