I never said anything about production. This would be (in our environment, anyway) set automatically for any development compiles only.
________________________________ From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of Farley, Peter x23353 <peter.far...@broadridge.com> Sent: Friday, August 18, 2017 8:39 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Possible COBOL RFE to abend if any warnings occured I agree with Jeffrey's comment and will add one of my own: No program should be installed into QA or UAT or production libraries with SSRANGE or ZONECHECK or any other debugging option turned on at all. There should be lifecycle software rules in place to automatically prevent it from ever happening. Debugging options are for debugging problems and for unit and regression testing, never for production. You are costing yourself serious CPU usage to leave them turned on in production. When a programmer is debugging or changing code they should already know enough to look at the message output (batch or CICS) when they have debugging compiler options turned on. If they don't know that then they don't deserve the label "programmer". Like the old vaudeville routine said, "Patient: Doctor! Doctor! It hurts when I do that!" "Doctor: Well, don't do that!" Peter -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jeffrey Holst Sent: Friday, August 18, 2017 9:03 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Possible COBOL RFE to abend if any warnings occured Unless you have other specific examples, both NUMCHECK and SSRANGE already offer the ABD sub-option. I would think the RFE would be rejected as already delivered. On Fri, 18 Aug 2017 00:19:14 +0000, Frank Swarbrick <frank.swarbr...@outlook.com> wrote: >Not yet submitted. Please comment. > >COBOL Language Environment �warning� messages (severity code 1) are written to >the destination supplied by the MSGFILE runtime option. This defaults to >CEEMSG for batch jobs and the CESE TD queue for CICS (where CESE is generally >mapped to the CEEMSG DD�) > >There is nothing about the execution of a program currently that will give any >indication that any warning conditions occurred, other than the existence of >these messages. So if you want to know if a particular execution of a program >caused any warning conditions you must look at the appropriate output. > >Enterprise COBOL has recently added new compile options with sub-options ABD >and MSG. When ABD is specified the program will, when certain conditions >occur, raise a severity 2 LE condition, which in turn (if not �handled�) will >cause the program to abend with code U4038 (or return code 3000 when runtime >option ABTERMENC(RETURN) in used instead of the default ABTERMENC(ABEND). > >When MSG is specified then only a severity 1 LE condition is raised. This >causes COBOL to simply write the message and then continue on to the next >COBOL statement. > >Unless you are specifically thinking that your program run might have warnings >you may not check for them. This is especially true for a CICS transaction, >since there is generally no �batch output� to review. > >It could be useful to have a run-time condition that optionally would be >raised at the termination of the run-unit (via STOP RUN or a GOBACK of the >�initial� program) if any COBOL warning condition was raised within the >run-unit. This new condition should be at least a level 2 condition so that >it will in turn cause the existing CEE0198S condition to be raised if it is >not suppressed by a condition handler or other method, which in turn would >cause the U4038 abend. > >Use case: >COBOL program is compiled with SSRANGE(MSG) and NUMCHECK(MSG). When a >condition is raised as a result of something these options check for it causes >an appropriate warning message to be written to the LE MSGFILE. As part of >COBOL run-unit termination it should check to see if any SEV 1 conditions >caused warning messages to be written. If so it should raise a new SEV 2 (or >above) condition. > >Considerations: >- Can/should this be done such that the current unit of work is committed >prior to the abend occurring? >- Use of this feature might necessitate the ability to suppress warning >messages that are expected. This would probably have to be done at compile >time. Perhaps a new �compiler directive� statement could be used to >�surround� code that causes a warning condition to occur but where you want to >suppress the warning. > >Other discussion: >I thought that I might be able to code this myself as a condition handler >which I would then specify as the second parameter to the USRHDLR run-time >option. I could not get this to work, because it appears that you cannot >�promote� the CEE0199W condition to another condition. > >Additionally, if you end your run-unit via a GOBACK instead of a STOP RUN it >does not cause any condition to occur, and thus the handler is not invoked at >run-unit termination. So there would be no way to cause a new condition via >the handler in this case. >Frank -- 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
