Re: DLL linkage vs static linkage
https://www.ibm.com/support/pages/fix-list-and-new-features-enterprise-cobol-zos Shows Cobol 6.3 has AMODE 64 PTFs. On Thu, Aug 12, 2021 at 1:35 PM Frank Swarbrick wrote: > > Barry, > > Looks like you are on the right track with regard to XPLINK being the > difference. 31-bit COBOL does not have XPLINK support, so I can't test that, > but 64-bit COBOL uses only XPLINK. If you try to do a static link of a > 64-bit XPLINK application to the 64-bit stub in SCSFSTUB it fails: > IEW2469E 9907 THE ATTRIBUTES OF A REFERENCE TO CSNERNGL FROM SECTION RNGL DO > NOT MATCH THE ATTRIBUTES OF THE TARGET SYMBOL. REASON 2 > Where "Reason 2": The xplink attributes of the reference and target do not > match. > I'm guessing only 64-bit assembler programs (that don't use XPLINK) can be > statically linked with the 64-bit stubs. > > If you override the static linkage attempt by using the restricted no-call > you still get the warning, but you get RC=0 instead of RC=4. My wild guess > is this is the case because the static linkage, if attempted, would have > failed. Kind of a weird distinction, but probably not worth requesting a > change in behavior. > > You are correct about LET=0 being the cause of my other issue. It works fine > with LET=4. Guess I shot myself in the foot with my decision long ago to > specify LET=0! > > Thanks, > Frank > > On Thu, 12 Aug 2021 11:56:54 -0500, Barry Lichtenstein > wrote: > > >Frank, > > > >I suspect that I tried out the restricted no-call LIBRARY statements with > >XPLINK C programs, because there I do not get the IEW2455W message. I'm > >pretty sure you should not get that message for NOXPLINK either, whether it > >be C or COBOL. (It's not obvious to me why it's happening, but the NOXPLINK > >import/export mechanism is significantly different than XPLINK, to start > >with it uses the original (Prelinker style) Q-con PR (offset) rather than > >the R-con/V-con representing the descriptor.) I think it's a reportable > >problem if you wish to pursue with binder, but an RFE might be a better > >thing to spend energy on. > > > >You do need to compile the COBOL modules differently in order for them to be > >DLL-enabled (C++ and XPLINK C are always DLL-enabled, but not COBOL). > >Though you could always compile them DLL-enabled and still link everything > >statically, you probably wouldn't want that overhead so you'd want a > >different proc or proc invocation. Thus whatever that switch was could also > >choose to include or exclude all the no-call LIBRARY statements. > > > >As for the IEW2638S message and the binder not saving the module, that's > >because you've got the binder parm LET=0 coded. The default is LET=4 (it's > >LET=8 if you code LET with no value). LET=0 tells the binder to mark it Not > >Executable (NX directory attribute) if the return code is higher than 0, and > >binder will not (by default) Replace an existing module that is marked > >Executable with one that is not. > > > >Barry > > > >On Wed, 11 Aug 2021 12:42:29 -0500 Frank Swarbrick > > wrote: > >> > >> 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. > >> > > . . . > >> > >> 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. > >> > > . . . > >> > >> 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. > >> > > . . . > >> > >> Next let's try Barry's suggestion: > >> > > . . . > >> > >> 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 TYPESYMBOL DLL DDNAME > >> SEQ MEMBER > >> - -- > >> --- - > >>IMPORT CODECSNBRNGLCSFDLL31SIEASID > >> 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.
Re: DLL linkage vs static linkage
I mis-stated one thing. I don't get the NOCALL/NEVERCALL warning in the 64-bit XPLINK case, which explains why RC=0 instead of 4. On Thu, 12 Aug 2021 13:35:27 -0500, Frank Swarbrick wrote: >Barry, > >Looks like you are on the right track with regard to XPLINK being the >difference. 31-bit COBOL does not have XPLINK support, so I can't test that, >but 64-bit COBOL uses only XPLINK. If you try to do a static link of a 64-bit >XPLINK application to the 64-bit stub in SCSFSTUB it fails: >IEW2469E 9907 THE ATTRIBUTES OF A REFERENCE TO CSNERNGL FROM SECTION RNGL DO >NOT MATCH THE ATTRIBUTES OF THE TARGET SYMBOL. REASON 2 >Where "Reason 2": The xplink attributes of the reference and target do not >match. >I'm guessing only 64-bit assembler programs (that don't use XPLINK) can be >statically linked with the 64-bit stubs. > >If you override the static linkage attempt by using the restricted no-call you >still get the warning, but you get RC=0 instead of RC=4. My wild guess is >this is the case because the static linkage, if attempted, would have failed. >Kind of a weird distinction, but probably not worth requesting a change in >behavior. > >You are correct about LET=0 being the cause of my other issue. It works fine >with LET=4. Guess I shot myself in the foot with my decision long ago to >specify LET=0! > >Thanks, >Frank > >On Thu, 12 Aug 2021 11:56:54 -0500, Barry Lichtenstein >wrote: > >>Frank, >> >>I suspect that I tried out the restricted no-call LIBRARY statements with >>XPLINK C programs, because there I do not get the IEW2455W message. I'm >>pretty sure you should not get that message for NOXPLINK either, whether it >>be C or COBOL. (It's not obvious to me why it's happening, but the NOXPLINK >>import/export mechanism is significantly different than XPLINK, to start with >>it uses the original (Prelinker style) Q-con PR (offset) rather than the >>R-con/V-con representing the descriptor.) I think it's a reportable problem >>if you wish to pursue with binder, but an RFE might be a better thing to >>spend energy on. >> >>You do need to compile the COBOL modules differently in order for them to be >>DLL-enabled (C++ and XPLINK C are always DLL-enabled, but not COBOL). Though >>you could always compile them DLL-enabled and still link everything >>statically, you probably wouldn't want that overhead so you'd want a >>different proc or proc invocation. Thus whatever that switch was could also >>choose to include or exclude all the no-call LIBRARY statements. >> >>As for the IEW2638S message and the binder not saving the module, that's >>because you've got the binder parm LET=0 coded. The default is LET=4 (it's >>LET=8 if you code LET with no value). LET=0 tells the binder to mark it Not >>Executable (NX directory attribute) if the return code is higher than 0, and >>binder will not (by default) Replace an existing module that is marked >>Executable with one that is not. >> >>Barry >> >>On Wed, 11 Aug 2021 12:42:29 -0500 Frank Swarbrick >> wrote: >>> >>> 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. >>> >> . . . >>> >>> 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. >>> >> . . . >>> >>> 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. >>> >> . . . >>> >>> Next let's try Barry's suggestion: >>> >> . . . >>> >>> 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 TYPESYMBOL DLL DDNAME >>> SEQ MEMBER >>> - -- >>> --- - >>>IMPORT CODECSNBRNGLCSFDLL31SIEASID >>> 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 >>>
Re: DLL linkage vs static linkage
Barry, Looks like you are on the right track with regard to XPLINK being the difference. 31-bit COBOL does not have XPLINK support, so I can't test that, but 64-bit COBOL uses only XPLINK. If you try to do a static link of a 64-bit XPLINK application to the 64-bit stub in SCSFSTUB it fails: IEW2469E 9907 THE ATTRIBUTES OF A REFERENCE TO CSNERNGL FROM SECTION RNGL DO NOT MATCH THE ATTRIBUTES OF THE TARGET SYMBOL. REASON 2 Where "Reason 2": The xplink attributes of the reference and target do not match. I'm guessing only 64-bit assembler programs (that don't use XPLINK) can be statically linked with the 64-bit stubs. If you override the static linkage attempt by using the restricted no-call you still get the warning, but you get RC=0 instead of RC=4. My wild guess is this is the case because the static linkage, if attempted, would have failed. Kind of a weird distinction, but probably not worth requesting a change in behavior. You are correct about LET=0 being the cause of my other issue. It works fine with LET=4. Guess I shot myself in the foot with my decision long ago to specify LET=0! Thanks, Frank On Thu, 12 Aug 2021 11:56:54 -0500, Barry Lichtenstein wrote: >Frank, > >I suspect that I tried out the restricted no-call LIBRARY statements with >XPLINK C programs, because there I do not get the IEW2455W message. I'm >pretty sure you should not get that message for NOXPLINK either, whether it be >C or COBOL. (It's not obvious to me why it's happening, but the NOXPLINK >import/export mechanism is significantly different than XPLINK, to start with >it uses the original (Prelinker style) Q-con PR (offset) rather than the >R-con/V-con representing the descriptor.) I think it's a reportable problem >if you wish to pursue with binder, but an RFE might be a better thing to spend >energy on. > >You do need to compile the COBOL modules differently in order for them to be >DLL-enabled (C++ and XPLINK C are always DLL-enabled, but not COBOL). Though >you could always compile them DLL-enabled and still link everything >statically, you probably wouldn't want that overhead so you'd want a different >proc or proc invocation. Thus whatever that switch was could also choose to >include or exclude all the no-call LIBRARY statements. > >As for the IEW2638S message and the binder not saving the module, that's >because you've got the binder parm LET=0 coded. The default is LET=4 (it's >LET=8 if you code LET with no value). LET=0 tells the binder to mark it Not >Executable (NX directory attribute) if the return code is higher than 0, and >binder will not (by default) Replace an existing module that is marked >Executable with one that is not. > >Barry > >On Wed, 11 Aug 2021 12:42:29 -0500 Frank Swarbrick > wrote: >> >> 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. >> > . . . >> >> 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. >> > . . . >> >> 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. >> > . . . >> >> Next let's try Barry's suggestion: >> > . . . >> >> 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 TYPESYMBOL DLL DDNAME >> SEQ MEMBER >> - -- >> --- - >>IMPORT CODECSNBRNGLCSFDLL31SIEASID >> 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
Re: DLL linkage vs static linkage
Frank, I suspect that I tried out the restricted no-call LIBRARY statements with XPLINK C programs, because there I do not get the IEW2455W message. I'm pretty sure you should not get that message for NOXPLINK either, whether it be C or COBOL. (It's not obvious to me why it's happening, but the NOXPLINK import/export mechanism is significantly different than XPLINK, to start with it uses the original (Prelinker style) Q-con PR (offset) rather than the R-con/V-con representing the descriptor.) I think it's a reportable problem if you wish to pursue with binder, but an RFE might be a better thing to spend energy on. You do need to compile the COBOL modules differently in order for them to be DLL-enabled (C++ and XPLINK C are always DLL-enabled, but not COBOL). Though you could always compile them DLL-enabled and still link everything statically, you probably wouldn't want that overhead so you'd want a different proc or proc invocation. Thus whatever that switch was could also choose to include or exclude all the no-call LIBRARY statements. As for the IEW2638S message and the binder not saving the module, that's because you've got the binder parm LET=0 coded. The default is LET=4 (it's LET=8 if you code LET with no value). LET=0 tells the binder to mark it Not Executable (NX directory attribute) if the return code is higher than 0, and binder will not (by default) Replace an existing module that is marked Executable with one that is not. Barry On Wed, 11 Aug 2021 12:42:29 -0500 Frank Swarbrick wrote: > > 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. > . . . > > 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. > . . . > > 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. > . . . > > Next let's try Barry's suggestion: > . . . > > 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 TYPESYMBOL DLL DDNAME > SEQ MEMBER > - -- > --- - >IMPORT CODECSNBRNGLCSFDLL31SIEASID > 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
Re: DLL linkage vs static linkage
I believe you are correct. It's one of those things that is a bad idea even if it does seem to work. Eric Rossman, CISSP® ICSF Cryptographic Security Development z/OS Enabling Technologies edros...@us.ibm.com "IBM Mainframe Discussion List" wrote on 08/12/2021 12:13:39 PM: > From: "Barry Lichtenstein" > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 08/12/2021 12:13 PM > Subject: [EXTERNAL] Re: DLL linkage vs static linkage > Sent by: "IBM Mainframe Discussion List" > > Eric, > > To the best of my knowledge SYS1.SIEALNKE members are not intended > to be linked directly into programs. > SYS1.CSSLIB (or other component-specific libraries like LE's > CEE.SCEELKED) should have the stubs for their functions. > SYS1.SIEALNKE is one of the datasets which are by default part of > the LNKLST concatenation, specifically: SYS1.LINKLIB, SYS1.MIGLIB, > SYS1.CSSLIB, SYS1.SIEALNKE, and SYS1.SIEAMIGE -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DLL linkage vs static linkage
Eric, To the best of my knowledge SYS1.SIEALNKE members are not intended to be linked directly into programs. SYS1.CSSLIB (or other component-specific libraries like LE's CEE.SCEELKED) should have the stubs for their functions. SYS1.SIEALNKE is one of the datasets which are by default part of the LNKLST concatenation, specifically: SYS1.LINKLIB, SYS1.MIGLIB, SYS1.CSSLIB, SYS1.SIEALNKE, and SYS1.SIEAMIGE Barry On Wed, 11 Aug 2021 15:37:42 -0400 Eric D Rossman wrote: > Reply > > 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^62^AF > ICSF Cryptographic Security Development > z/OS Enabling Technologies > edros...@us.ibm.com > Tieline: 295-6882 or (845) 435-6882 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DLL linkage vs static linkage
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 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" wrote on
>08/11/2021 04:02:03 PM:
>
>> From: "Frank Swarbrick"
>> 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"
>>
>> 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
>> 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" wrote on
>> >08/11/2021 01:42:29 PM:
>> >
>> >> From: "Frank Swarbrick"
>> >> 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"
>> >>
>> >> 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=
>> >> // JCLLIB ORDER=(IGY.V6R3M0.SIGYPROC)
>> >> //COMPILE EXEC PROC=IGYWCL,
>> >> // PARM
Re: DLL linkage vs static linkage
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" wrote on
08/11/2021 04:02:03 PM:
> From: "Frank Swarbrick"
> 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"
>
> 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
> 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" wrote on
> >08/11/2021 01:42:29 PM:
> >
> >> From: "Frank Swarbrick"
> >> 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"
> >>
> >> 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=
> >> // 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 SYSLIB01
> >CSNBRNGL
> >> 0 A8 CSNBRNGL LABEL
> >>
> >>
> >> Next
Re: DLL linkage vs static linkage
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 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" wrote on
>08/11/2021 01:42:29 PM:
>
>> From: "Frank Swarbrick"
>> 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"
>>
>> 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=
>> // 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 SYSLIB01
>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=
>> // 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 TYPESYMBOL DLL
>> DDNAME SEQ MEMBER
>> - --
>> --- -
>>IMPORT CODECSNBRNGLCSFDLL31
>> SYSLIN02 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=
>> // JCLLIB ORDER=(IGY.V6R3M0.SIGYPROC)
>> //COMPILE EXEC PROC=IGYWCL,
>> // PARM.COBOL='NODYNAM DLL',
>> // PARM.LKED='LIST=
Re: DLL linkage vs static linkage
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" wrote on 08/11/2021 01:42:29 PM: > From: "Frank Swarbrick" > 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" > > 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= > // 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 SYSLIB01 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= > // 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 TYPESYMBOL DLL > DDNAME SEQ MEMBER > - -- > --- - >IMPORT CODECSNBRNGLCSFDLL31 > SYSLIN02 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= > // 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 SYSLIB01 CSNBRNGL > 0 1A8 CSNBRNGL LABEL > > > --- SOURCE > IMPORT/EXPORT TYPESYMBOL DLL > DDNAME SEQ MEMBER > - -- > --- - > *** NO SYMBOLS IMPORTED *** > > Next let's try Barry's suggestion: > > //CSFLINK JOB NOTIFY= > // 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
Re: DLL linkage vs static linkage
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= // 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 SYSLIB01 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= // 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 TYPESYMBOL DLL DDNAME SEQ MEMBER - -- --- - IMPORT CODECSNBRNGLCSFDLL31SYSLIN02 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= // 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 SYSLIB01 CSNBRNGL 0 1A8 CSNBRNGL LABEL --- SOURCE IMPORT/EXPORT TYPESYMBOL DLL DDNAME SEQ MEMBER - -- --- - *** NO SYMBOLS IMPORTED *** Next let's try Barry's suggestion: //CSFLINK JOB NOTIFY= // 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.
Re: DLL linkage vs static linkage
I was using SCSFMOD0 as indicated in the documentation for an earlier release: https://www.ibm.com/docs/en/zos/2.1.0?topic=cca-linking-program-icsf-callable-services It does look like more recent documentation recommends the SCSFSTUB library, as you say. https://www.ibm.com/docs/en/zos/2.4.0?topic=icsf-linking-program-callable-services But of course I wasn't aware of this new library, and the "old" way still works, so there was nothing to lead me to know I should change it. Regardless, I will change it now. It does not seem to make any effective difference. Anyway, I am now able to use Barry's suggestion successfully. Details in a follow-up reply. I do want to mention that your recommendation of using SIEALNKE (rather than SCSFSTUB) for static linkage for LE programs both doesn't seem to be documented, nor does it seem to work, as there are no modules or aliases for the routines in that library. So I'm not sure what your intent was there. SIEALNKE appears to have the DLLs that satisfy the run-time DLL linkage, but I don't see how it has any link/bind time effect. Thanks, Frank On Tue, 10 Aug 2021 19:29:56 -0400, Eric D Rossman wrote: >Just to be clear, there is no case to ever include SYS1.SCSFMOD0. That >dataset should never be in any since HCR77D0 (z/OS V2R4) because it is not >a programming interface. Everything that was in there that was intended as >a programming interface is now in SYS1.SCSFSTUB. > >ASM programs should be using SYS1.SCSFSTUB (static) or LOAD/LINK (dynamic) >LE programs (such as C) should be using SYS1.SIEASID (dynamic) or >SYS1.SIEALNKE (static). > >I'd love to help. Do you have a simple test (source and link job) that >replicates this error? > >Eric Rossman, CISSP� >ICSF Cryptographic Security Development >z/OS Enabling Technologies >edros...@us.ibm.com > >"IBM Mainframe Discussion List" wrote on >08/10/2021 05:41:46 PM: > >> From: "Frank Swarbrick" >> To: IBM-MAIN@LISTSERV.UA.EDU >> Date: 08/10/2021 05:42 PM >> Subject: [EXTERNAL] Re: DLL linkage vs static linkage >> Sent by: "IBM Mainframe Discussion List" >> >> Hi Barry, >> >> Interesting. But I can't quite get it to work. What's bizarre is >> that the DLL linkage seems to get resolved: >> >> IMPORT/EXPORT TYPESYMBOL DLL >> DDNAME SEQ MEMBER >> - -- >> --- - >>IMPORT CODECSNBRNGLCSFDLL31 >> SIEASID 01 CSFDLL31 >> >> But the binder is still giving me an error: >> >> IEW2455W 9205 SYMBOL CSNBRNGL UNRESOLVED. NOCALL OR NEVERCALL >> SPECIFIED. >> IEW2638S 5384 AN EXECUTABLE VERSION OF MODULE *NULL* EXISTS AND >> CANNOT BE REPLACED BY THE NON-EXECUTABLE MODULE JUST >> CREATED. >> >> Very odd! > > >-- >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
Re: DLL linkage vs static linkage
Hi Frank, Two things I'd check: * You've invoked the binder with the DYNAM=DLL parm * The reference(s) are dynamic (descriptors) so that they can be satisfied by the IMPORT Otherwise the binder cannot resolve them dynamically and since you now told it to not autocall... Barry On Tue, 10 Aug 2021 16:41:46 -0500 Frank Swarbrick wrote: > > Hi Barry, > > Interesting. But I can't quite get it to work. What's bizarre is that the > DLL linkage seems to get resolved: > > IMPORT/EXPORT TYPESYMBOL DLL DDNAME > SEQ MEMBER > - -- > --- - >IMPORT CODECSNBRNGLCSFDLL31SIEASID > 01 CSFDLL31 > > But the binder is still giving me an error: > > IEW2455W 9205 SYMBOL CSNBRNGL UNRESOLVED. NOCALL OR NEVERCALL SPECIFIED. > IEW2638S 5384 AN EXECUTABLE VERSION OF MODULE *NULL* EXISTS AND CANNOT BE > REPLACED BY THE NON-EXECUTABLE MODULE JUST > CREATED. > > Very odd! > > Frank -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DLL linkage vs static linkage
Just to be clear, there is no case to ever include SYS1.SCSFMOD0. That dataset should never be in any since HCR77D0 (z/OS V2R4) because it is not a programming interface. Everything that was in there that was intended as a programming interface is now in SYS1.SCSFSTUB. ASM programs should be using SYS1.SCSFSTUB (static) or LOAD/LINK (dynamic) LE programs (such as C) should be using SYS1.SIEASID (dynamic) or SYS1.SIEALNKE (static). I'd love to help. Do you have a simple test (source and link job) that replicates this error? Eric Rossman, CISSP® ICSF Cryptographic Security Development z/OS Enabling Technologies edros...@us.ibm.com "IBM Mainframe Discussion List" wrote on 08/10/2021 05:41:46 PM: > From: "Frank Swarbrick" > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 08/10/2021 05:42 PM > Subject: [EXTERNAL] Re: DLL linkage vs static linkage > Sent by: "IBM Mainframe Discussion List" > > Hi Barry, > > Interesting. But I can't quite get it to work. What's bizarre is > that the DLL linkage seems to get resolved: > > IMPORT/EXPORT TYPESYMBOL DLL > DDNAME SEQ MEMBER > - -- > --- - >IMPORT CODECSNBRNGLCSFDLL31 > SIEASID 01 CSFDLL31 > > But the binder is still giving me an error: > > IEW2455W 9205 SYMBOL CSNBRNGL UNRESOLVED. NOCALL OR NEVERCALL > SPECIFIED. > IEW2638S 5384 AN EXECUTABLE VERSION OF MODULE *NULL* EXISTS AND > CANNOT BE REPLACED BY THE NON-EXECUTABLE MODULE JUST > CREATED. > > Very odd! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DLL linkage vs static linkage
Hi Barry, Interesting. But I can't quite get it to work. What's bizarre is that the DLL linkage seems to get resolved: IMPORT/EXPORT TYPESYMBOL DLL DDNAME SEQ MEMBER - -- --- - IMPORT CODECSNBRNGLCSFDLL31SIEASID 01 CSFDLL31 But the binder is still giving me an error: IEW2455W 9205 SYMBOL CSNBRNGL UNRESOLVED. NOCALL OR NEVERCALL SPECIFIED. IEW2638S 5384 AN EXECUTABLE VERSION OF MODULE *NULL* EXISTS AND CANNOT BE REPLACED BY THE NON-EXECUTABLE MODULE JUST CREATED. Very odd! Frank On Tue, 10 Aug 2021 13:40:10 -0500, Barry Lichtenstein wrote: >This complaint has come up every so often. There is something already in the >binder that works. However it requires a control statements one-for-one with >each IMPORT statement. The control statement is a restricted no-call LIBRARY >statement, it looks simply like this (with the parentheses): > > LIBRARY (symname) > >That tells the binder to not resolve symbol 'symname' from an autocall >library. You can still explicitly include it, or the symbol could come in >statically due to being part of another module. The binder will still always >resolve statically first -- or more accurately it will only attempt to >"resolve dynamically" symbols that are unresolved after final autocall. (It's >a bit of a misnomer, the binder is only promised that the symbol will be there >when LE tries to find it, so the binder dutifully builds the construct for LE >to do so.) > >I'd suggest having this statement at the top of a file of control statements, >to avoid having to quote all the symbol names: > > SETOPT PARM(CASE=MIXED) * Avoid quoting symbol names on LIBRARY > >Barry > >On Mon, 9 Aug 2021 23:36:37 + Frank Swarbrick > wrote: >> Reply >> >> In the LE Programming Guide, section "Building a simple DLL application" >> (https://www.ibm.com/docs/en/zos/2.4.0?topic=dlls-building-simple-dll-application), >> the >following statement is made: >> >> "After final autocall processing of DD SYSLIB is complete, all DLL-type >> references that are not statically resolved are compared to IMPORT control >> statements. Sy >mbols on IMPORT control statements are treated as definitions, and cause a >matching unresolved symbol to be considered dynamically rather than statically >resolved. > A dynamically resolved symbol causes an entry in the binder B_IMPEXP to be > created. If the symbol is unresolved at the end of DLL processing, it is not > accessible > at run time." >> >> This means (and I have tested this), if the called routine can be resolved >> both statically and via DLL, it will always choose to bind statically. >> >> For example, ICSF provides both individual program modules for each callable >> service, and also DLLs that provide entry points for each callable service. >> DLL lin >kage for these routines requires including the appropriate DLL side deck >(CSFDLL31). But you also cannot include in your "autocall concatenation" the >library that > contains the individual called routines (in this case CSF.SCSFMOD0), > otherwise those modules are statically linked, and the DLL imports are > ignored. For example, > here's an excerpt from the program binder step: >> >> //SYSLIN DD * >> INCLUDE SIEASID(CSFDLL31) >> /* >> // DD DSN=&OBJMOD,DISP=(OLD,DELETE) >> // DD DDNAME=USERLIN >> //SYSLIB DD DSN=CEE.SCEELKED,DISP=SHR >> // DD DSN=CEE.SCEELKEX,DISP=SHR >> // DD DSN=CSF.SCSFMOD0,DISP=SHR >> //SIEASID DD DSN=SYS1.SIEASID,DISP=SHR >> >> You must not include the CSF.SCSFMOD0 library if you want to use DLL linkage >> for those modules. >> >> In my shop we have all libraries that have modules that any of our programs >> might want to use (rather than having processes to allow for explicitly >> including tho >se libraries only when used). But if we were to migrate to using DLLs (we are >a COBOL shop, btw) we'd have to do something so that "DLL applications" don't >have t >he "static libraries" in the binder SYSLIB. This is "annoying". Would I get >any support from the community if I were to open an RFE and request a binder >option t >o prioritize DLL linkage over static linkage? Or better yet, is there already >a way to accomplish this? >> >> 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
Re: DLL linkage vs static linkage
This complaint has come up every so often. There is something already in the binder that works. However it requires a control statements one-for-one with each IMPORT statement. The control statement is a restricted no-call LIBRARY statement, it looks simply like this (with the parentheses): LIBRARY (symname) That tells the binder to not resolve symbol 'symname' from an autocall library. You can still explicitly include it, or the symbol could come in statically due to being part of another module. The binder will still always resolve statically first -- or more accurately it will only attempt to "resolve dynamically" symbols that are unresolved after final autocall. (It's a bit of a misnomer, the binder is only promised that the symbol will be there when LE tries to find it, so the binder dutifully builds the construct for LE to do so.) I'd suggest having this statement at the top of a file of control statements, to avoid having to quote all the symbol names: SETOPT PARM(CASE=MIXED) * Avoid quoting symbol names on LIBRARY Barry On Mon, 9 Aug 2021 23:36:37 + Frank Swarbrick wrote: > Reply > > In the LE Programming Guide, section "Building a simple DLL application" > (https://www.ibm.com/docs/en/zos/2.4.0?topic=dlls-building-simple-dll-application), > the following statement is made: > > "After final autocall processing of DD SYSLIB is complete, all DLL-type > references that are not statically resolved are compared to IMPORT control > statements. Sy mbols on IMPORT control statements are treated as definitions, and cause a matching unresolved symbol to be considered dynamically rather than statically resolved. A dynamically resolved symbol causes an entry in the binder B_IMPEXP to be created. If the symbol is unresolved at the end of DLL processing, it is not accessible at run time." > > This means (and I have tested this), if the called routine can be resolved > both statically and via DLL, it will always choose to bind statically. > > For example, ICSF provides both individual program modules for each callable > service, and also DLLs that provide entry points for each callable service. > DLL lin kage for these routines requires including the appropriate DLL side deck (CSFDLL31). But you also cannot include in your "autocall concatenation" the library that contains the individual called routines (in this case CSF.SCSFMOD0), otherwise those modules are statically linked, and the DLL imports are ignored. For example, here's an excerpt from the program binder step: > > //SYSLIN DD * > INCLUDE SIEASID(CSFDLL31) > /* > // DD DSN=&OBJMOD,DISP=(OLD,DELETE) > // DD DDNAME=USERLIN > //SYSLIB DD DSN=CEE.SCEELKED,DISP=SHR > // DD DSN=CEE.SCEELKEX,DISP=SHR > // DD DSN=CSF.SCSFMOD0,DISP=SHR > //SIEASID DD DSN=SYS1.SIEASID,DISP=SHR > > You must not include the CSF.SCSFMOD0 library if you want to use DLL linkage > for those modules. > > In my shop we have all libraries that have modules that any of our programs > might want to use (rather than having processes to allow for explicitly > including tho se libraries only when used). But if we were to migrate to using DLLs (we are a COBOL shop, btw) we'd have to do something so that "DLL applications" don't have t he "static libraries" in the binder SYSLIB. This is "annoying". Would I get any support from the community if I were to open an RFE and request a binder option t o prioritize DLL linkage over static linkage? Or better yet, is there already a way to accomplish this? > > Frank -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
DLL linkage vs static linkage
In the LE Programming Guide, section "Building a simple DLL application" (https://www.ibm.com/docs/en/zos/2.4.0?topic=dlls-building-simple-dll-application), the following statement is made: "After final autocall processing of DD SYSLIB is complete, all DLL-type references that are not statically resolved are compared to IMPORT control statements. Symbols on IMPORT control statements are treated as definitions, and cause a matching unresolved symbol to be considered dynamically rather than statically resolved. A dynamically resolved symbol causes an entry in the binder B_IMPEXP to be created. If the symbol is unresolved at the end of DLL processing, it is not accessible at run time." This means (and I have tested this), if the called routine can be resolved both statically and via DLL, it will always choose to bind statically. For example, ICSF provides both individual program modules for each callable service, and also DLLs that provide entry points for each callable service. DLL linkage for these routines requires including the appropriate DLL side deck (CSFDLL31). But you also cannot include in your "autocall concatenation" the library that contains the individual called routines (in this case CSF.SCSFMOD0), otherwise those modules are statically linked, and the DLL imports are ignored. For example, here's an excerpt from the program binder step: //SYSLIN DD * INCLUDE SIEASID(CSFDLL31) /* // DD DSN=&,DISP=(OLD,DELETE) // DD DDNAME=USERLIN //SYSLIB DD DSN=CEE.SCEELKED,DISP=SHR // DD DSN=CEE.SCEELKEX,DISP=SHR // DD DSN=CSF.SCSFMOD0,DISP=SHR //SIEASID DD DSN=SYS1.SIEASID,DISP=SHR You must not include the CSF.SCSFMOD0 library if you want to use DLL linkage for those modules. In my shop we have all libraries that have modules that any of our programs might want to use (rather than having processes to allow for explicitly including those libraries only when used). But if we were to migrate to using DLLs (we are a COBOL shop, btw) we'd have to do something so that "DLL applications" don't have the "static libraries" in the binder SYSLIB. This is "annoying". Would I get any support from the community if I were to open an RFE and request a binder option to prioritize DLL linkage over static linkage? Or better yet, is there already a way to accomplish this? Frank -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
