[Default] On 13 Nov 2019 16:05:58 -0800, in bit.listserv.ibm-main frank.swarbr...@outlook.com (Frank Swarbrick) wrote:
>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... So far as I am concerned,any program running with CBLQDA(ON) is a program with undesirable consequences waiting to happen. With QDA(ON) if there is no DD statement for a given output COBOL file, a temporary disk file is created, written to, and deleted at the end of the step. This is a subtle action which can lead to much head scratching. In a shop where I was consulting, I convinced management to make sure QDA was off and we found one program that was altering the DDNAME associated with the FD to direct output to different SYSOUT DDs. If there was no DD the printout went to the bit bucket. It was an interesting task to correct the program so that there was an appropriate action for missing DD statements. Clark Morris > >________________________________ >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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
