To be clear: I'm the author of CSFDLL31 (as well as much of the ICSF LE libraries). I guarantee CSFDLL31 is just stubs (they are pretty much the LE linkage equivalent to the OS linkage stubs in SCSFSTUB). The only patches (so far) have been to add new callable service entry points.
I do agree with you that it is not always useful to bind CSFDLL31 in (it would save the overhead of shared object loading but at the cost of a lot of code). While the linkage for stubs in SCSFSTUB is mostly the same for CSFDLL31, for CSFDLL3X and CSFDLL64, you will almost certainly encounter trouble (both use XPLINK). Short summary: It is not a supported configuration to call a stub in SCSFSTUB with LE linkage or call an entry points in CSFDLL* with OS linkage. While it might work, it's not the right way and IBM does not support it. Eric Rossman, CISSP® ICSF Cryptographic Security Development z/OS Enabling Technologies [email protected] "IBM Mainframe Discussion List" <[email protected]> wrote on 08/11/2021 04:02:03 PM: > From: "Frank Swarbrick" <[email protected]> > To: [email protected] > Date: 08/11/2021 04:02 PM > Subject: [EXTERNAL] Re: DLL linkage vs static linkage > Sent by: "IBM Mainframe Discussion List" <[email protected]> > > It appears you CAN explicitly link in the actual DLL ("INCLUDE > SIEALNKE(CSFDLL31)"), but I believe that to be unwise for several reasons > 1) It acts as if you are simply trying to add your application to > the DLL (with your new name), rather than simply utilizing the DLL. > That is, your bind step creates a side deck that has all of the ICSF > DLL's entry points mapped to your executable. > 2) The DLL appears to not be "just stubs" but rather has the actual > implementation of each routine. This causes your executable to be > (IMO) excessively large. And I imagine that any patches to the > actual DLL would not be picked up by your application until you > rebind to the upgraded DLL. > > I don't think that OS linkage vs LE linkage makes any (useful) > difference. LE languages can use OS linkage just fine, since from a > caller perspective they are the same (as far as I can tell). I > believe a subroutine only needs LE linkage if it itself requires LE services. > > Frank > > On Wed, 11 Aug 2021 15:37:42 -0400, Eric D Rossman > <[email protected]> wrote: > > >I would like to point out that the stubs in SCSFSTUB use OS linkage and > >the entry points in CSFDLL31 use LE linkage. You should use whichever > >matches the linkage declared (or defaulted) for the ICSF callable > >services. > > > >It is never correct to specify both SCSFSTUB and an ICSF side-deck in the > >same link operation. It might work but it might not. > > > >As to what I meant by static, I suspect that I might be using the wrong > >terminology for this and perhaps I am misremembering how it works. I > >thought you could directly linkedit a shared object [like > >SIEALNKE(CSFDLL31)] into a load module and it would be treated as if it > >were an archive (.a) instead of shared object/DLL (.so). > > > >Eric Rossman, CISSP� > >ICSF Cryptographic Security Development > >z/OS Enabling Technologies > >[email protected] > >Tieline: 295-6882 or (845) 435-6882 > > > >"IBM Mainframe Discussion List" <[email protected]> wrote on > >08/11/2021 01:42:29 PM: > > > >> From: "Frank Swarbrick" <[email protected]> > >> To: [email protected] > >> Date: 08/11/2021 01:42 PM > >> Subject: [EXTERNAL] Re: DLL linkage vs static linkage > >> Sent by: "IBM Mainframe Discussion List" <[email protected]> > >> > >> I've now been successful in implementing your suggestion. Some > >> comments follow. > >> > >> The following is successful for a static link. Cobol compiler > >> options "NODYNAM NODLL" and the inclusion of SYS1.SCSFSTUB in the > >> binder SYSLIB. > >> > >> //CSFLINK JOB NOTIFY=&SYSUID > >> // JCLLIB ORDER=(IGY.V6R3M0.SIGYPROC) > >> //COMPILE EXEC PROC=IGYWCL, > >> // PARM.COBOL='NODYNAM NODLL', > >> // PARM.LKED='LIST=NOIMP MAP XREF LET=0' > >> //COBOL.SYSIN DD * > >> id division. > >> program-id. rngl. > >> procedure division. > >> call 'csnbrngl' > >> goback. > >> > >> end program rngl. > >> //LKED.SYSLIB DD DISP=SHR,DSN=SYS1.SCSFSTUB > >> > >> Results: > >> A8 CSFRNGL * CSECT 1D0 SYSLIB 01 > >CSNBRNGL > >> 0 A8 CSNBRNGL LABEL > >> > >> > >> Next is a successful "DLL link". Cobol compiler options "NODYNAM > >> DLL". Added "DYNAM=DLL CASE=MIXED" to the binder parameters. The > >> CSFDLL31 side file is included "in place" of SCSFSTUB. > >> > >> //CSFLINK JOB NOTIFY=&SYSUID > >> // JCLLIB ORDER=(IGY.V6R3M0.SIGYPROC) > >> //COMPILE EXEC PROC=IGYWCL, > >> // PARM.COBOL='NODYNAM DLL', > >> // PARM.LKED='LIST=NOIMP MAP XREF LET=0 DYNAM=DLL CASE=MIXED' > >> //COBOL.SYSIN DD * > >> id division. > >> program-id. rngl. > >> procedure division. > >> call 'csnbrngl' > >> goback. > >> > >> end program rngl. > >> //LKED.SYSIN DD DISP=SHR,DSN=SYS1.SIEASID(CSFDLL31) > >> > >> Results: > >> > >> ------- SOURCE -------- > >> IMPORT/EXPORT TYPE SYMBOL DLL > >> DDNAME SEQ MEMBER > >> ------------- ------ ---------------- ---------------- > >> -------- --- --------- > >> IMPORT CODE CSNBRNGL CSFDLL31 > >> SYSLIN 02 CSFDLL31 > >> > >> > >> Now, if we take the previous example (DLL resolution) and add back > >> SYSLIB with SYS1.SCSFSTUB, the static resolution takes precedence > >> over DLL resolution, which is what I don't want. > >> > >> //CSFLINK JOB NOTIFY=&SYSUID > >> // JCLLIB ORDER=(IGY.V6R3M0.SIGYPROC) > >> //COMPILE EXEC PROC=IGYWCL, > >> // PARM.COBOL='NODYNAM DLL', > >> // PARM.LKED='LIST=NOIMP MAP XREF LET=0 DYNAM=DLL CASE=MIXED' > >> //COBOL.SYSIN DD * > >> id division. > >> program-id. rngl. > >> procedure division. > >> call 'csnbrngl' > >> goback. > >> > >> end program rngl. > >> //LKED.SYSLIB DD DISP=SHR,DSN=SYS1.SCSFSTUB > >> //LKED.SYSIN DD DISP=SHR,DSN=SYS1.SIEASID(CSFDLL31) > >> > >> Results: > >> 1A8 CSFRNGL * CSECT 1D0 SYSLIB 01 > >CSNBRNGL > >> 0 1A8 CSNBRNGL LABEL > >> > >> > >> ------- SOURCE -------- > >> IMPORT/EXPORT TYPE SYMBOL DLL > >> DDNAME SEQ MEMBER > >> ------------- ------ ---------------- ---------------- > >> -------- --- --------- > >> *** NO SYMBOLS IMPORTED *** > >> > >> Next let's try Barry's suggestion: > >> > >> //CSFLINK JOB NOTIFY=&SYSUID > >> // JCLLIB ORDER=(IGY.V6R3M0.SIGYPROC) > >> //COMPILE EXEC PROC=IGYWCL, > >> // PARM.COBOL='NODYNAM DLL', > >> // PARM.LKED='LIST=NOIMP MAP XREF LET=0 DYNAM=DLL CASE=MIXED' > >> //COBOL.SYSIN DD * > >> id division. > >> program-id. rngl. > >> procedure division. > >> call 'csnbrngl' > >> goback. > >> > >> end program rngl. > >> //LKED.SYSLIB DD DISP=SHR,DSN=SYS1.SCSFSTUB > >> //LKED.SYSIN DD * > >> INCLUDE SIEASID(CSFDLL31) > >> LIBRARY (CSNBRNGL) > >> //LKED.SIEASID DD DISP=SHR,DSN=SYS1.SIEASID > >> > >> Unlike my attempt to do this with our standard compile proc, this > >> does seem to work as designed. > >> It does put out the following warning, which causes an RC of 4 > >> instead of 0, which is annoying. > >> > >> IEW2455W 9205 SYMBOL CSNBRNGL UNRESOLVED. NOCALL OR NEVERCALL > >SPECIFIED. > >> > >> But in the end it succeeds with the DLL import to resolve it. > >> > >> *** I M P O R T E D A N D E X P O R T > >> E D S Y M B O L S *** > >> > >> ------- SOURCE -------- > >> IMPORT/EXPORT TYPE SYMBOL DLL > >> DDNAME SEQ MEMBER > >> ------------- ------ ---------------- ---------------- > >> -------- --- --------- > >> IMPORT CODE CSNBRNGL CSFDLL31 > >> SIEASID 01 CSFDLL31 > >> > >> When I modify our standard compile proc in a similar (!!) manner I > >> still get an error: > >> > >> IEW2638S 5384 AN EXECUTABLE VERSION OF MODULE *NULL* EXISTS AND > >> CANNOT BE REPLACED BY THE NON-EXECUTABLE MODULE JUST > >> CREATED. > >> > >> I'm unclear as to what I am doing differently here. Not sure if > >> I'll research it any further, however, as I don't think this is > >> really the solution I'm looking for. Two reasons: > >> 1) I can't use it for non-DLL applications, and thus it defeats my > >> desire to have a single proc that works for both DLL and non-DLL > >> applications (without overrides). > >> 2) That warning message just bugs me! > >> > >> I am still thinking about making an RFE to give DLL linkage > >> priority. Is this a lost cause, or should I do it? > >> > >> Thanks! > >> Frank > > > > > >---------------------------------------------------------------------- > >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
