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
