Why would you want to do that? If you are not going to do anything about it, why not put a monitor in your program and avoid the manual step?
Next, we cannot really answer your question as we do not know the details behind the cause of the error. If it is a critical field you may want to notified so you can correct data and rerun.
Please give us more information as to what your process is doing and what is causing the error.
Thanks for your quick response. I understand the causes of a decimal data error. What we are trying to do is, allow operators to respond to the error if possible without programming intervention. In a test environment the operator responded with many "G's" and the error went away. That to me sounds like the Cobol program stepped down further and looped until it found valid data. Not a good idea to me.
First, I suspect that the message ID was LNR7200 in message file QLNRMSG (assuming ILE COBOL) rather than MCH1202 since MCH1202 does not take any response at all. MCH1202 is a machine-check message. This would be handled by default by COBOL by sending LNR7200 as a *INQ message to get a response. The LNR7200 message would contain text saying that a MCH1202 was detected and asking how it should be handled. If it's not LNR7200, we need to know what the actual *INQ message was.
For LNR7200, a 'G' response says:
G -- To continue the program at the next MI instruction.
Mostly, it means to ignore the error and simply go on to the next compiled machine instruction as if no error happened. It's almost impossible to predict what the result would be, but it's effectively guaranteed that some incorrect value was passed along from instruction to instruction. The calculation that was being done did not change the result field. Whatever happened to be in that memory location at the time simply stayed there and was used in whatever processing came next.
Note that the message that you showed in your comment is not a MCH1202 message. It looks like LNR7200. The full text of that message is:
Message file . . . . . . . . . : QLNRMSG Library . . . . . . . . . . . . : QSYS
Message IDs: LNR7200
LNR7200
Message . . . . : Message &1 in program object &3 in library &4 (C D F G).
Cause . . . . . : Message &1 was detected in COBOL statement &2 of COBOL
program &5 in program object &3 in library &4.
Recovery . . . : Enter a G to continue the program at the next MI
instruction, or a C if no dump is wanted, a D if a dump of the COBOL
identifiers is wanted, or an F to dump both the COBOL identifiers and the
file information. The message text for &1 follows: &7
Possible choices for replying to message . . . . . . . . . . . . . . . :
C -- No formatted dump is given
D -- A dump of the COBOL identifiers is given
F -- A dump of the COBOL identifiers and file information
G -- To continue the program at the next MI instruction.
Only a review of the source code could help understand the possible impact of answering 'G'. If the program is doing any important updates or reports, you can feel certain that there are incorrect results being generated. Whether incorrect results are important to your business or not, you'll have to decide. It'll probably be difficult to determine where any incorrect results could be found, so correction would also be difficult.
Note that alternative responses could be as bad or worse or better. There's no way for us to know without knowing everything about the program. The program itself needs to be corrected to handle the condition and avoid the unknown consequences.
Discuss This Question: 5  Replies
Why would you want to do that? If you are not going to do anything about it, why not put a monitor in your program and avoid the manual step?
Next, we cannot really answer your question as we do not know the details behind the cause of the error. If it is a critical field you may want to notified so you can correct data and rerun.
Please give us more information as to what your process is doing and what is causing the error.
First, I suspect that the message ID was LNR7200 in message file QLNRMSG (assuming ILE COBOL) rather than MCH1202 since MCH1202 does not take any response at all. MCH1202 is a machine-check message. This would be handled by default by COBOL by sending LNR7200 as a *INQ message to get a response. The LNR7200 message would contain text saying that a MCH1202 was detected and asking how it should be handled. If it's not LNR7200, we need to know what the actual *INQ message was.
For LNR7200, a 'G' response says:
Mostly, it means to ignore the error and simply go on to the next compiled machine instruction as if no error happened. It's almost impossible to predict what the result would be, but it's effectively guaranteed that some incorrect value was passed along from instruction to instruction. The calculation that was being done did not change the result field. Whatever happened to be in that memory location at the time simply stayed there and was used in whatever processing came next.
Tom
A MCH1202 produces this message to the operator.
Message 'MCH1202' in program object 'Object Name' in library 'Library Name' (C D
F G).
Reply . . : G
Our operators are answering with a "G". and yes that will execute the next instruction. I'm against answering with a "G" while others think it's okay.
Note that the message that you showed in your comment is not a MCH1202 message. It looks like LNR7200. The full text of that message is:
Only a review of the source code could help understand the possible impact of answering 'G'. If the program is doing any important updates or reports, you can feel certain that there are incorrect results being generated. Whether incorrect results are important to your business or not, you'll have to decide. It'll probably be difficult to determine where any incorrect results could be found, so correction would also be difficult.
Note that alternative responses could be as bad or worse or better. There's no way for us to know without knowing everything about the program. The program itself needs to be corrected to handle the condition and avoid the unknown consequences.
Tom