Apologies, you certainly did not say anything about production. I don't like the idea of someone else turning on all the checking options "automatically" when my program needs some development or maintenance. I prefer to be the one to decide which (if any) of those options I may need to debug a problem or verify new code. Besides, all a programmer has to do to thwart any automatic option setting is to use a PROCESS card to turn off the options they don't want to use.
From the application programmer's point of view, your RFE if automatically imposed would force me to keep changing code until all messages were handled because my program always abends when it completes if I don't handle those messages. From a managers point of view, why are you forcing my programmer to make unplanned code changes that may introduce as many bugs as it purportedly resolves? I don't necessarily always subscribe to this philosophy, but it is very common and managers do have some legitimate concerns about unplanned code changes. Unit testing is a bit more challenging when your program always abends while you are trying to test a logic change not associated with the code that generates checking messages. Annoying too if you are running an interactive debugging session and the program abends at the end of processing. I might see turning the existing checking options on automatically with the ABD sub-option in the full-volume regression testing stage to see if any bugs were missed during unit testing because those logic paths were not exercised, but not otherwise and probably not at all if I know there are unhandled checking messages being generated for this particular maintenance cycle. I still agree with Jeffrey's response that since the compiler options already allow for the ABD sub-option you will probably get "already delivered" as an answer to your RFE. Not a big help if you have "legitimate" code that triggers the option check which you don't want to change right away, but I would first question whether any such code is actually legitimate and not a problem. If it's actually broken it ought to be fixed ASAP, though one's manager may or may not agree with that opinion (see above). If the point is to generate all the possible sub-option MSG messages from a batch run or CICS transaction and then "tell the programmer" via abend to be sure to go look at the message output, I do not see any real usefulness in such an option. If the programmer doesn't know enough to go look at the messages when they asked for them (or were told they must ask for them and check the results), then there isn't much you can do beyond telling them to RTFM and talk to their manager about it. OTOH I think the idea of being able to "turn off" selected options around sections of code could be a useful idea. Kind of like C/C++ "pragma(packed) and "pragma(reset)" around structure definitions but for executable code. That has possibilities, but again you (and your manager) should probably first question whether such code sections are really "ignorable" for any given check. HTH Peter -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Frank Swarbrick Sent: Friday, August 18, 2017 11:44 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Possible COBOL RFE to abend if any warnings occured 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 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
