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 <[email protected]> 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 ><[email protected]> 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 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
