On 07-Jan-2014 10:38 -0800, Pascal Polverini wrote:
I get an escape message.
I/O error CPF5037 was detected in file MYDSPF(C G D F).
<<SNIP>>
The CPF5037 is almost surely sent as a /notify/ message, for which an
ILE Condition Handler likely is required to avoid that RPG run-time
handler from intercepting the condition [and sending the inquiry if
necessary error handling is not in effect for what I infer is a 1299
condition; error RNX1299 with inquiry RNQ1299]. Spool the joblog
[and\or review the actual logged CPF5037 with the F1=Help and with
F9=Details and\or output from F6=Print] to verify that is the case, and
to see the originator. Do the same for the [default] reply.
Some doc references that might help. Do not /get hung-up on/ the
references to CL in the drill-down or supporting text in my
snippets-only doc references; visit each link for complete details:
http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/topic/rbam6/enmsg.htm
IBM i 7.1 Information Center -> Programming -> Control language ->
Messages -> Commands used to send messages from a CL program
_Escape and notify messages_
"...
A notify message tells the caller about a condition under which
processing can continue. The calling program or procedure can monitor
for the arrival of the notify message and handle the condition it
describes. If the caller is an Integrated Language Environment®
procedure, it can perform the following functions:
• It can handle the condition.
• It can send a reply back to the caller.
• It can allow the sending procedure to continue processing.
If the caller is an original program model (OPM) program and is not
monitoring for the message, the sender receives a default reply. If the
caller is an ILE procedure, then the message percolates to the control
boundary. When finding no monitor, the system returns a default reply to
the sender. The sender then resumes processing.
..."
http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/topic/rzasc/sc092507345.htm
IBM i 7.1 Information Center -> Programming -> Programming languages ->
RPG -> ILE RPG Programmer's Guide -> Debugging and Exception Handling ->
Handling Exceptions
_ILE Condition Handlers_
"ILE condition handlers are exception handlers that are registered at
run time using the Register ILE Condition Handler (CEEHDLR) bindable
API. They are used to handle, percolate or promote exceptions. The
exceptions are presented to the condition handlers in the form of an ILE
condition. You can register more than one ILE condition handler. ILE
condition handlers may be unregistered by calling the Unregister ILE
Condition Handler (CEEHDLU) bindable API.
There are several reasons why you might want to use an ILE condition
handler:
• You can bypass language-specific handling by handling the exception
in your own handler.
This enables you to provide the same exception handling mechanism
in an application with modules in different ILE HLLs.
..."
http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/topic/apis/CEEHDLR.htm
_Register a User-Written Condition Handler (CEEHDLR) API_
"...
The Register a User-Written Condition Handler (CEEHDLR) API registers a
user-written condition handler for the current call stack entry.
...
_ILE Condition Handler Interface_
Following is a description of the interface that the system uses to
communicate with ILE condition handlers.
...
result_code (output)
This field contains the instructions from the condition handler to
the system regarding the actions that the system should take.
ILE condition handlers get control for all *ESCAPE, *STATUS,
*NOTIFY, and function check messages. Not all result code actions are
valid for all types of messages.
If the message is handled by the ILE condition handler, the
result-code action is not performed.
...
Valid result codes are:
Resume
This result code can be used for all exception types.
10 Resume at the resume cursor, and handle the condition, as
follows:
...
*NOTIFY The default reply is sent and the message
appears in the job log.
..."
http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/topic/rbam6/ntmsg.htm
IBM i 7.1 Information Center -> Programming -> Control language ->
Messages -> Monitoring for messages in a CL program or procedure
_Monitoring for notify messages_
"...
Notify messages are sent to tell your procedure or program of a
condition that is not typically an error. By monitoring for notify
messages, you can specify an action different from what you would
specify if the condition had not been detected. Very few IBM-supplied
commands send notify messages.
Monitoring for and handling notify messages is similar to monitoring for
and handling escape messages. The difference is in what happens if you
do not monitor for and handle notify messages. ...
..."
http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/topic/rzasc/sc092507348.htm
IBM i 7.1 Information Center -> Programming -> Programming languages ->
RPG -> ILE RPG Programmer's Guide -> Debugging and Exception Handling ->
Handling Exceptions
_Problems when ILE CL Monitors for Notify and Status Messages_
"...
... if the ILE RPG procedure writes a record to a printer file and the
actual printer file has a shorter record length that was declared in the
RPG procedure, notify message CPF4906 is sent to the RPG procedure. The
RPG exception handling percolates this message which causes the default
reply of 'I' to ignore the message. This should allow the output
operation to continue normally, and the RPG procedure should proceed to
the next instruction.
...
If you encounter this problem, you have two possible ways to avoid it:
...
2. Enable an ILE condition handler in the RPG procedure. In the
handler, if the message is one that you want to ignore, indicate that
the message should be handled. Otherwise, indicate that it should be
percolated.
...
Figure 147 shows an example of a ILE condition handler that ignores
CPF4906.
..."
midrange.com
