On Tue, 18 Nov 2025 22:57:10 -0500, Phil Smith III wrote: >Ok, that was what I guessed you were hinting at. > >So it's sorta not JCL, despite looking like it (and presumably getting >re-injected into the stream by SMP/E at the appropriate time, at which point >it sorta is JCL). > Not even that. SMP/E uses only the lowest qualifiers in the apparent data set names to identify DDDEFs and invokes utilities via their API.
>Any suggestions to solve the problem? > Do // EXPORT SYMLIST=* and DD *,SYMBOLS =JCLONLY solve the problem? I fear not if you want the substitution performed at the customers' sites, not at the supplier's. For that reason, I supplied a tailoring ISPF Edit macro to be used by customers. I suspect there were complaints; Tier 1 Support shielded me from them. I had an intense discussion (argument) with a coworker who insisted that I show him a data set named in JCLIN. There was none such. Our development system used RXSQL on CMS, remotely invoking utilities on MVS. I chose to make the specification resemble JCL, which I parsed to generate SQL commands. I might as well have used makefile syntax, but I might have received intense partisan resistance. I suspect there was a precursor of SMP/E which actually submitted the JCLIN. (I don't recall its name. AI might.) At the transition, SMP/E incorporated the JCL from that earlier product. Or, SMP/E chose to use JCL, ugly as it is, because of developer preference. >-----Original Message----- >From:Seymour J Metz >Sent: Tuesday, November 18, 2025 9:12 PM > >Therefore you don't get SMP doing symbol substitution for JCLIN the way that >you get in JCL. -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
