Re: Dynamically detect if CBLQDA is active from a COBOL program?
Not my call, I'm just an application programmer trying to get my assigned work done on time. All I can do is raise the issue to my management. They have the ultimate say in such matters. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Clark Morris Sent: Friday, November 15, 2019 5:55 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Dynamically detect if CBLQDA is active from a COBOL program? [Default] On 15 Nov 2019 11:22:17 -0800, in bit.listserv.ibm-main peter.far...@broadridge.com (Farley, Peter x23353) wrote: >Unfortunately not possible here. Dev shares LPAR's with QA and even some >Prod, so it is not realistically possible to properly test turning it off >except perhaps during a full DR exercise off-site and independently of the >actual production environment. Immediately start a project to convert to CBLQDA(OFF). CBLQDA(ON) means that if a DD statement is missing for a sequential output file, a temporary file will be created, written to and deleted at the end of job step. Clark Morris > >Peter > >-Original Message- >From: IBM Mainframe Discussion List On >Behalf Of Frank Swarbrick >Sent: Friday, November 15, 2019 2:11 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: Dynamically detect if CBLQDA is active from a COBOL program? > >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 on >behalf of Farley, Peter x23353 >Sent: Friday, November 15, 2019 11:17 AM >To: 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 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 on >behalf of Farley, Peter x23353 >Sent: Wednesday, November 13, 2019 4:59 PM >To: 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 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
Re: Dynamically detect if CBLQDA is active from a COBOL program?
Holy cripes. Sorry man! From: IBM Mainframe Discussion List on behalf of Farley, Peter x23353 Sent: Friday, November 15, 2019 12:21 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Dynamically detect if CBLQDA is active from a COBOL program? Unfortunately not possible here. Dev shares LPAR's with QA and even some Prod, so it is not realistically possible to properly test turning it off except perhaps during a full DR exercise off-site and independently of the actual production environment. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Frank Swarbrick Sent: Friday, November 15, 2019 2:11 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Dynamically detect if CBLQDA is active from a COBOL program? 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 on behalf of Farley, Peter x23353 Sent: Friday, November 15, 2019 11:17 AM To: 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 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 on behalf of Farley, Peter x23353 Sent: Wednesday, November 13, 2019 4:59 PM To: 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 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
Re: Dynamically detect if CBLQDA is active from a COBOL program?
[Default] On 15 Nov 2019 11:22:17 -0800, in bit.listserv.ibm-main peter.far...@broadridge.com (Farley, Peter x23353) wrote: >Unfortunately not possible here. Dev shares LPAR's with QA and even some >Prod, so it is not realistically possible to properly test turning it off >except perhaps during a full DR exercise off-site and independently of the >actual production environment. Immediately start a project to convert to CBLQDA(OFF). CBLQDA(ON) means that if a DD statement is missing for a sequential output file, a temporary file will be created, written to and deleted at the end of job step. Clark Morris > >Peter > >-Original Message- >From: IBM Mainframe Discussion List On Behalf Of >Frank Swarbrick >Sent: Friday, November 15, 2019 2:11 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: Dynamically detect if CBLQDA is active from a COBOL program? > >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 on behalf of >Farley, Peter x23353 >Sent: Friday, November 15, 2019 11:17 AM >To: 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 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 on behalf of >Farley, Peter x23353 >Sent: Wednesday, November 13, 2019 4:59 PM >To: 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 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
Re: Dynamically detect if CBLQDA is active from a COBOL program?
Unfortunately not possible here. Dev shares LPAR's with QA and even some Prod, so it is not realistically possible to properly test turning it off except perhaps during a full DR exercise off-site and independently of the actual production environment. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Frank Swarbrick Sent: Friday, November 15, 2019 2:11 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Dynamically detect if CBLQDA is active from a COBOL program? 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 on behalf of Farley, Peter x23353 Sent: Friday, November 15, 2019 11:17 AM To: 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 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 on behalf of Farley, Peter x23353 Sent: Wednesday, November 13, 2019 4:59 PM To: 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 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.
Re: Dynamically detect if CBLQDA is active from a COBOL program?
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 on behalf of Farley, Peter x23353 Sent: Friday, November 15, 2019 11:17 AM To: 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 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 on behalf of Farley, Peter x23353 Sent: Wednesday, November 13, 2019 4:59 PM To: 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 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
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 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 on behalf of Farley, Peter x23353 Sent: Wednesday, November 13, 2019 4:59 PM To: 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 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
Re: Dynamically detect if CBLQDA is active from a COBOL program?
[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 on behalf of >Farley, Peter x23353 >Sent: Wednesday, November 13, 2019 4:59 PM >To: 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 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
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 on behalf of Farley, Peter x23353 Sent: Wednesday, November 13, 2019 4:59 PM To: 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 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
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 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
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! << -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dynamically detect if CBLQDA is active from a COBOL program?
And a follow-up question: If I have to chase control blocks, it is possible for a COBOL program to determine the CAA address without using an assembler subroutine? If it matters, COBOL version here is currently 5.2, 6.x is coming soon. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Farley, Peter x23353 Sent: Tuesday, November 12, 2019 1:28 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? I have reviewed the LE callable subroutines and don't see an existing service which returns that information. Do I have to chase the LE control blocks to determine this information? (CAA -> CEECAAEDB -> CEEEDBOPTCB -> CEEOCB_CBLQDA) If so, what bit determines if it is currently turned on (I don't care where it came from, just whether it is active or not)? Would that be CEEOCB_CBLQDA_ON = "X'80'"? z/OS release is 2.2 if that matters. Peter -- 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
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? I have reviewed the LE callable subroutines and don't see an existing service which returns that information. Do I have to chase the LE control blocks to determine this information? (CAA -> CEECAAEDB -> CEEEDBOPTCB -> CEEOCB_CBLQDA) If so, what bit determines if it is currently turned on (I don't care where it came from, just whether it is active or not)? Would that be CEEOCB_CBLQDA_ON = "X'80'"? z/OS release is 2.2 if that matters. Peter -- 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
