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 <[email protected]> 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 <[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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
