VSHDLIB is a ddname.
-- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר ________________________________________ From: IBM Mainframe Discussion List <[email protected]> on behalf of Phil Smith III <[email protected]> Sent: Wednesday, November 19, 2025 3:46 PM To: [email protected] <[email protected]> Subject: Re: Variables in SMP/E JCLIN records? External Message: Use Caution First, I hope it's clear that I'm not arguing to argue, I know you're the expert! I was quoting the book, which says what I copied about LIBRARY. I guess "not supported" to me means "It's guaranteed to fail" but you're saying "might work", which is clearly not full support. Makes sense. But I'm still confused: "SMP/E does not ensure a ddname specified on the LIBRARY statement gets allocated before calling the binder." The LIBRARY statement is: //VSHDLIB DD DISP=SHR,DSN=VSH.VSHDLIB //SYSLIN DD * INCLUDE VSHDLIB(LOGPRINT) ... LIBRARY '&USSPATH.lib/libsapi.a' I see no ddname there? The point is that there are hundreds of routines in those libraries, so we want it to resolve automatically, not require a zillion INCLUDE statements. Plus the entry point names are largely > 8 bytes, which is why it's in USS: we used to do a horrible hack where we'd just copy all the object decks into one huge MVS member and INCLUDE that, but that makes the executable bigger, with everything from the library included whether it's used or not. This is code shared on various platforms, so there's lots of unused stuff. In any case, that's still in the JCLIN, so I don't get how it would help: the DD would still specify &USSPATH?! I feel like we're making progress here, but I'm still very lost... -----Original Message----- From: IBM Mainframe Discussion List <[email protected]> On Behalf Of Kurt Quackenbush Sent: Wednesday, November 19, 2025 2:58 PM To: [email protected] Subject: Re: Variables in SMP/E JCLIN records? >>3. The binder LIBRARY statement in JCLIN is not supported by SMP/E. > Well...not quite true per the book: I stand by what I said: the LIBRARY statement is not supported by SMP/E. If you code a LIBRARY statement in your JCLIN link edit step, you might get it to work, but SMP/E makes no effort to recognize it or to ensure it keeps working as you intend. For example, SMP/E does not ensure a ddname specified on the LIBRARY statement gets allocated before calling the binder. >> INCLUDE tgtddname('libsapi.a') TYPE=UTIN > If I understood this, I'd do it. "use the INCLUDE statement"--where? In JCLIN? In your JCLIN, within the stream of binder control statements, replace the LIBRARY statement with an INCLUDE. Assuming the subject file resides in a directory that is managed by SMP/E, specify on the INCLUDE the ddname that corresponds to the target directory for that file. If a DD statement for that ddname exists in the APPLY job, or a DDDEF entry with that name is defined in the target zone, then SMP/E will ensure the ddname is allocated before calling the binder so that the binder can find the subject file. And you can specify a relative file name between the parenthesis if necessary to allow the binder to find the file relative to the directory identified by the ddname. Kurt Quackenbush IBM | z/OS SMP/E and z/OSMF Software Management | [email protected] Chuck Norris never uses CHECK when he applies PTFs. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
