CPF9999 is a gobal escape message used bu IBM.
There are parameters passed to it so that when you get it you will have enough information to determine your problem.
==================================================
CPF9999 is the general 'function check' message. A function check condition is similar in concept to 'machine check' except it refers to software faults that have no error correction procedure rather than hardware error correction.
Very simplified, it means that the program ran into an error and did nothing about it. Whoever wrote the program needs to fix it. The CPF9999 message will include the error condition that was ignored and needs to be fixed.
Tom
Last Wiki Answer Submitted: November 28, 2009 6:51 am by TomLiotta107,695 pts.
If you live outside the United States, by submitting your email address you consent to having your personal data transferred to and processed in the United States.
can you please explain in detail. i found both CPF0000 and CPF9999 displaying same type of information. Only difference is that function check message appears during CPF9999 and the program completes normally without going to message wait.
8801 – CRTPF FILE(QTEMP1/F55506T6) RCDLEN(32766) SIZE(*NOMAX)
Cannot find object needed for file F55506T6 in QTEMP1.
File F55506T6 not created in library QTEMP1.
Error occurred when sending message IXA0020.
2 > /* ISDB stopped at statement 8801 in program J55506T */
3 > *SYSTEM/DSPJOB
Function check. CPF7302 unmonitored by J55506T at statement 8801,
instruction X’004A’.
Using CPF0000 –
8801 – CRTPF FILE(QTEMP1/F55506T6) RCDLEN(32766) SIZE(*NOMAX)
Cannot find object needed for file F55506T6 in QTEMP1.
File F55506T6 not created in library QTEMP1.
2 > /* ISDB stopped at statement 5000 in program J55506T */
3 > *SYSTEM/DSPJOB
2 > /* ISDB stopped at statement 16600 in program J55506T */
Function check. CPF7302 unmonitored by J55506T at statement 8801,
instruction X’004A’.
This is the CPF9999 function check message. It is saying that program J55506T received a CPF7302 message at statement 8801 and didn’t do anything about it.
File F55506T6 not created in library QTEMP1.
As in the previous case, this is the CPF7302 message. It was apparently caught by a MONMSG for CPF0000. It’s not clear if anything was done about it beyond catching it.
When you monitor for message IDs that end in ’00′ or ’0000′, you are using a generic message identifier. This statement:
MONMSG CPF9800
…will monitor for any message ID from CPF9801 through CPF98FF. This statement:
MONMSG CPF0000
…will monitor for any message ID from CPF0001 through CPFFFFF. (Message IDs end in four hex characters.)
Note that monitoring for a message ID should include code that actually handles the message condition. Simply catching a condition doesn’t mean that the program should continue, though it’s often a reasonable thing to do.
When an error condition appears, the system expects you to remove that condition and do something about it. If your program doesn’t do that, then the system will send the CPF9999 function check message up the stack to the calling program. The calling program is notified by that so it knows that an error happened that the called program didn’t catch nor handle. The calling program can take the info from a CPF9999 message and forward it to someone responsible.
can you please explain in detail. i found both CPF0000 and CPF9999 displaying same type of information. Only difference is that function check message appears during CPF9999 and the program completes normally without going to message wait.
like this:-
Using CPF9999-
8801 – CRTPF FILE(QTEMP1/F55506T6) RCDLEN(32766) SIZE(*NOMAX)
Cannot find object needed for file F55506T6 in QTEMP1.
File F55506T6 not created in library QTEMP1.
Error occurred when sending message IXA0020.
2 > /* ISDB stopped at statement 8801 in program J55506T */
3 > *SYSTEM/DSPJOB
Function check. CPF7302 unmonitored by J55506T at statement 8801,
instruction X’004A’.
Using CPF0000 –
8801 – CRTPF FILE(QTEMP1/F55506T6) RCDLEN(32766) SIZE(*NOMAX)
Cannot find object needed for file F55506T6 in QTEMP1.
File F55506T6 not created in library QTEMP1.
2 > /* ISDB stopped at statement 5000 in program J55506T */
3 > *SYSTEM/DSPJOB
2 > /* ISDB stopped at statement 16600 in program J55506T */
Function check. CPF7302 unmonitored by J55506T at statement 8801,
instruction X’004A’.
This is the CPF9999 function check message. It is saying that program J55506T received a CPF7302 message at statement 8801 and didn’t do anything about it.
File F55506T6 not created in library QTEMP1.
As in the previous case, this is the CPF7302 message. It was apparently caught by a MONMSG for CPF0000. It’s not clear if anything was done about it beyond catching it.
When you monitor for message IDs that end in ’00′ or ’0000′, you are using a generic message identifier. This statement:
…will monitor for any message ID from CPF9801 through CPF98FF. This statement:
…will monitor for any message ID from CPF0001 through CPFFFFF. (Message IDs end in four hex characters.)
Note that monitoring for a message ID should include code that actually handles the message condition. Simply catching a condition doesn’t mean that the program should continue, though it’s often a reasonable thing to do.
When an error condition appears, the system expects you to remove that condition and do something about it. If your program doesn’t do that, then the system will send the CPF9999 function check message up the stack to the calling program. The calling program is notified by that so it knows that an error happened that the called program didn’t catch nor handle. The calling program can take the info from a CPF9999 message and forward it to someone responsible.
Tom
BTW, MONMSG CPF0000 will catch a CPF9999 message since CPF9999 falls in the range from CPF0001 through CPFFFFF. However, it might not be very useful.
Tom