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 <[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 -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
