If this default is at the system level, rather than at an individual program level, I wonder if you might have it changed in a development instance and see if it has any adverse effect.
________________________________ From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of Farley, Peter x23353 <peter.far...@broadridge.com> Sent: Friday, November 15, 2019 11:17 AM To: IBM-MAIN@LISTSERV.UA.EDU <IBM-MAIN@LISTSERV.UA.EDU> Subject: Re: Dynamically detect if CBLQDA is active from a COBOL program? Yes I do. It appears that our shop standard value is CBLQDA(ON). Why that is the case I do not know. Peter -----Original Message----- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Frank Swarbrick Sent: Wednesday, November 13, 2019 7:06 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Dynamically detect if CBLQDA is active from a COBOL program? Do you have any reason to believe that CBLQDA(ON) is ever used in your shop? If CBLQCA is not already set to ON as default in your shop it seems unlikely to me that anyone is setting it explicitly somewhere. But I only have my own shop to go by, so who knows... ________________________________ From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of Farley, Peter x23353 <peter.far...@broadridge.com> Sent: Wednesday, November 13, 2019 4:59 PM To: IBM-MAIN@LISTSERV.UA.EDU <IBM-MAIN@LISTSERV.UA.EDU> Subject: Re: Dynamically detect if CBLQDA is active from a COBOL program? Hi Tom, thanks for the reply. The specific problem I am trying to address is whether or not in the startup code for an application-wide utility subroutine I can safely test for the presence of a COBOL OPTIONAL output file used only for certain event-specific processing. If CBLQDA is ON then I will always get FILE STATUS '00' for an OPEN OUTPUT of that optional file, but what I really need to know is whether a DD statement was *actually* provided in the invoking JCL and not added dynamically by CBLQDA processing. Supplying a PARM with '.../CBLQDA(OFF)' or CEEOPTS in the JCL with CBLQDA(OFF) is not an option since this is a subroutine used by multiple main programs across a large number of production jobs. Changing that many jobs is not practical or desirable, and other unrelated code in the same run units may in fact depend on CBLQDA being ON. The application requirements can accept that in such cases the COBOL OPTIONAL output file will never be used. It seems illogical to me that there is no standard LE interface available to test whether and how various LE runtime options are set for dynamic decisions, or that there is not at least a COBOL intrinsic function or predefined global variable for this particular option that affects only COBOL LE programs. Not knowing the value of CBLQDA makes it impossible to safely and correctly use COBOL OPTIONAL output files. I could accept a new FILE STATUS code returned from OPEN OUTPUT for a COBOL OPTIONAL file that was dynamically allocated by CBLQDA if no other option seems possible or reasonable to implement. Peter -----Original Message----- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Tom Ross Sent: Wednesday, November 13, 2019 5:46 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Dynamically detect if CBLQDA is active from a COBOL program? >Is it possible for a COBOL program to dynamically detect if LE option >CBLQDA is active? Not easily...but I would be surprised if it is different for different programs in the same region. You can run a program with RPTOPTS(ON) to get an "options in effect" report from LE. You could search for CEEUOPT in your load library to see if anyone is setting LE options on a single program. Most likely all programs are running with the same setting of CBLQDA. Another way we might help you is to learn why you want to know about the setting of CBLQDA for a specific program? What problem do we need to solve here? Cheers, TomR >> COBOL is the Language of the Future! << ---------------------------------------------------------------------- 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
