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=&&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
