Peter, There is no way in COBOL (at least not in any version of which I am aware) to tell the compiler that a called module is written in another language.
The importance of being able to dynamically call C library routines is only that some shops forbid using static calls as part of normal program development and automatically enforce the rule (my shop is one such) to prevent the ancient problem of shop-wide subroutines changed and needing to re-link all programs that use those shop-wide subroutines. But you are correct - from a first look, dynamic calls of C library routines would probably be a "bad thing" to do as a general rule, due to the no-doubt extensive interconnections between them. HOWEVER, because the SYS1.SCEELKED C library routines are all actually just stubs to the "real" routines, I think it will work just fine. The "real" routines are where the cross-linkage exists, not between the stubs. Now, whether C library routines or even their stubs should be coded to ASSUME static linking is a different question. I would argue that any good library routine design should ASSUME dynamic calling from the start, but that is just my humble opinion. I think IBM has solved the design problem with these stubs, since none of them actually contains any C library code, thus bypassing any problem with cross-linked subroutines. Whether allowing the use of SYS1.SCEELKED in STEPLIB or JOBLIB in a production JCL is a good idea or not is probably a judgment call for each unique shop. Understanding the technology, I would support it as reasonable when the C library functions provide good ROI for the development team. Again, just my humble opinion. Peter (BTW, good name, there are not that many of us around . . . :) ) -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Peter Hunkeler Sent: Monday, April 10, 2017 9:45 AM To: [email protected] Subject: Re: Opinion: Using C "standard library" routines in COBOL. Sorry for the late reply. I've been trying to find the documentation that talks about calling C/C++ library functions from other HLL code, such as Cobol. All I found was information about doing interlanguage calls, but this is all about "own" code, not the functions that the C/C++ runtime library provides. >Subsequent COBOL V5.2 testing showed that including CEESG003 at link/bind time >also works for COBOL V5.2 dynamic call. SYS1.SCEELKED is still required in >STEPLIB/JOBLIB/LINKLIST for dynamic calls to work. Language Environment uses signature CSECTs CEESGnnn to represent those LE supported HLL languages that are being used in the current load module. When a new (or first) load module is loaded into the enclave, LE looks for the signature CSECTs that are present in the load module, compares that with the list of LE languages already initialized, and then initializes any new language. This process, amongst other things, lets the pointer in the CAA point to the correct structures. Pardon my ignorance, I'm not fluent in Cobol, but the code you showed does not seem to tell the compiler that the dynamically called routine CUSERID is a C routine. Therefore the compiler does not include CSECT CEESG003. Is there a means in Cobol to declare a certain dynamically called routine is written in C, so that the compiler would know? The stubs in SYS1.SCEELKED are not complete load modules, they are intended to be used in the link/bind step (yes, I'm still eager to find this documented explicitly). The do not the signature CSECTs, so LE has not handle to recognize a new language is to be initialized when one of those routines is dynamically called. Apart from all that, I still do not understand why it is so important to you to have those calls be dynamic calls. When you code a C routine, you are using a lot of the runtime library functions, aren't you? All of those are statically bound. If there was danger of missing an important LE service update with those, IBM would need to mark those PTFs with a HOLD action "Must rebind any and alll your programs using C functions". Not something I can imagine to ever happen. I would not have a good feeling with manually including signature CSECTs and running with SYS1.SCEELKED in the steplib concatention. -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
