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 edros...@us.ibm.com Tieline: 295-6882 or (845) 435-6882 "IBM Mainframe Discussion List" <IBM-MAIN@LISTSERV.UA.EDU> wrote on 08/11/2021 01:42:29 PM: > From: "Frank Swarbrick" <frank.swarbr...@outlook.com> > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 08/11/2021 01:42 PM > Subject: [EXTERNAL] Re: DLL linkage vs static linkage > Sent by: "IBM Mainframe Discussion List" <IBM-MAIN@LISTSERV.UA.EDU> > > 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
