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

Reply via email to