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 TYPE SYMBOL DLL DDNAME SEQ
MEMBER
------------- ------ ---------------- ---------------- -------- ---
---------
IMPORT CODE CSNBRNGL CSFDLL31 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!
Frank
On Tue, 10 Aug 2021 13:40:10 -0500, Barry Lichtenstein <[email protected]>
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 +0000 Frank Swarbrick
><[email protected]> 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=&&amp;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 [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
