Re: Possible COBOL RFE to abend if any warnings occured

[Frank Swarbrick]

I am a (lead) developer, not a sysprog, so I wouldn't be forcing anything on 
anyone but my own group.  We (I) already made the decision that SSRANGE (with 
abend, as that's the only option at our release) would be the development 
compile default for COBOL V5.2.  I have not heard one complaint, and I know 
that many errors have been fixed.  (Perhaps everyone is just afraid of me.)  If 
you truly have no time to fix any of the issues that setting these checks 
reveals then you certainly have the option to override it at dev compile time.

My concern is that if the issue isn't forced then no one has incentive to ever 
turn it on.  I'm not aware of anyone in my shop who used SSRANGE regularly 
prior to my forcing the issue with V5.2.  I myself only used it occasionally, 
and usually when I was experiencing an issue which might be explained by a 
subscript out of range issue.

I also turned on ZONECHECK (NUMCHECK(ZON)) for a couple programs where COBOL 5 
was giving different results from COBOL 4 and I was shocked how many issues it 
found.  Some affecting business logic and some not.  This was my incentive to 
desire this option to always be set.  At this point we have not turned 
ZONECHECK on by default, but I am leaning toward doing it with the MSG option 
(in dev only!).  And there lies my desire for the option to force an abend at 
the end of the job if any warnings were issue.  Obviously with the option of 
turning it off if there is no time to resolve the revealed issues!

Frank


From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of 
Farley, Peter x23353 <peter.far...@broadridge.com>
Sent: Saturday, August 19, 2017 8:29 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Possible COBOL RFE to abend if any warnings occured

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

Re: Possible COBOL RFE to abend if any warnings occured

[Farley, Peter x23353]

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

Re: Possible COBOL RFE to abend if any warnings occured

[Frank Swarbrick]

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 +, 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 
>opti

Re: Possible COBOL RFE to abend if any warnings occured

[Frank Swarbrick]

They do, but the point of the MSG option as it exists today is to "change 
SSRANGE [etc.] checking to issue a non-terminating, warning-level runtime 
message which in turn allow COBOL to report on all subscript or index 
out-of-range conditions, in a single run of the application." (quoted from 
http://www-01.ibm.com/support/docview.wss?uid=swg1PI74933).  Note the "in a 
single run of the application."  The point of my RFE would be so that the user 
could know that any warnings actually occurred.  If someone has a better idea I 
am open to suggestions.


From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of 
Jeffrey Holst <jeffrey.ho...@pnc.com>
Sent: Friday, August 18, 2017 7: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 +, 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
>
>--
>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 

Re: Possible COBOL RFE to abend if any warnings occured

[Farley, Peter x23353]

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 +, 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 an

Re: Possible COBOL RFE to abend if any warnings occured

[Jeffrey Holst]

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 +, Frank Swarbrick 
 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
>
>--
>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

Possible COBOL RFE to abend if any warnings occured

[Frank Swarbrick]

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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN