On Wed, 20 Jun 2018 18:35:01 -0400, Steve Smith wrote: >Actually, the upshot is exactly not that. Symbols in SYSIN are always >resolved when requested by SYMBOLS=. The program that reads that SYSIN >never sees any symbols. > >The 2nd parm of SYMBOLS is a DDname for a substitution report. I would >have assumed you'd get that regardless, but evidently, the SYSIN file has >to be OPENed to get the substitution report. > I suspect that substitution is lazy, performed at the last possible moment. For example if the SYSIN is in a PROC called multiple times with different values of a symbol in effect, won't different executions show those different values substituted?
Even more, it's possible to cause a (simulated) I/O error if substitution causes an overlong line. Will lines prior to that point be read correctly? >On Wed, Jun 20, 2018 at 5:35 PM, Jesse 1 Robinson wrote: > >> I think the upshot here is that support for symbols in *data* is a >> function of the program being executed. The 'system' will resolve symbols >> encountered in JCL, but the 'application' has to resolve symbols read from, >> We might quibble about the distinction between 'system' and 'application'. I believe the substitution is done by the access method or JES. Is that 'system' or 'application'? >> say, SYSIN. That's why TYPRUN=SCAN will not show resolved symbols in data: >> the program is not actually executed. Whether it's EZACFSM1 or IEBGENER, >> the program has to run in order to resolve symbols. > TYPRUN=SCAN is a farce; increasingly so as new features appear in JCL and SCAN (SCAM?) fails to accommodate them. But it never reported things as basic as overlong qualifiers in data set names. -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
