Haha, sorry for the bad assumption! I was just looking at the CSECT lengths
for each entry in CSFDLL31 and they seemed to be larger than I would expect for
a simple stub procedure.
Frank
On Wed, 11 Aug 2021 16:24:10 -0400, Eric D Rossman <edros...@us.ibm.com> wrote:
>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
>edros...@us.ibm.com
>
>"IBM Mainframe Discussion List" <IBM-MAIN@LISTSERV.UA.EDU> wrote on
>08/11/2021 04:02:03 PM:
>
>> From: "Frank Swarbrick" <frank.swarbr...@outlook.com>
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Date: 08/11/2021 04:02 PM
>> Subject: [EXTERNAL] Re: DLL linkage vs static linkage
>> Sent by: "IBM Mainframe Discussion List" <IBM-MAIN@LISTSERV.UA.EDU>
>>
>> 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
>> <edros...@us.ibm.com> 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
>> >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
>>
>> ----------------------------------------------------------------------
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
>
>----------------------------------------------------------------------
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
