Paul Gilmartin wrote: > ... 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. ...
Of course, like everybody, I would like both things to be implemented, but because of their difficulty, I don't count on them any time soon. a. the 100-character PARM limit isn't easy to increase, as the length of SWA control blocks is 176 bytes (due to SYS1.SYSJOBQE, IIRC) Years ago, I wrote a utility program which allows the JCL PARM to be longer than 100 bytes, but, frankly, this isn't a solution I recommend :) b. native support of symbol substitution in SYSIN data sets by the reader/converter/interpreter is a problem because JES2/JES3 readers "extract" in-line cards and store them separately from JCL in the SPOOL. So, if I'm not mistaken, the interpreter doesn't see in-line cards. Again, IIRC ! If symbol substitution is added, it should be an option to prevent existing jobs to fail, like in this example: // SET VAR=AAAAAAAA //STEP1 EXEC PGM=MYPROG,PARM=&VAR //SYSIN DD * &VAR /* The user does not expect the SYSIN card to contain anything other that &VAR, so the reader/converter/interpreter should NOT replace it with AAAAAAAA OK, perhaps this isn't something that happens often ! :) -- Gilbert Saint-Flour GSF Software http://gsf-soft.com ---------------------------------------------------------------------- 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
