|
Send C400-L mailing list submissions to
c400-l@xxxxxxxxxxxx
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.midrange.com/mailman/listinfo/c400-l
or, via email, send a message with subject or body 'help' to
c400-l-request@xxxxxxxxxxxx
You can reach the person managing the list at
c400-l-owner@xxxxxxxxxxxx
When replying, please edit your Subject line so it is more specific
than "Re: Contents of C400-L digest..."
Today's Topics:
1. Re: _Rreadnc() and _Rwrited() from RPG (Scott Klement)
2. Re: _Rreadnc() and _Rwrited() from RPG (Pascal Polverini)
3. Re: _Rreadnc() and _Rwrited() from RPG (Mark S Waterbury)
4. Re: _Rreadnc() and _Rwrited() from RPG (Mark S Waterbury)
5. Re: _Rreadnc() and _Rwrited() from RPG (CRPence)
----------------------------------------------------------------------
message: 1
date: Tue, 07 Jan 2014 13:22:08 -0600
from: Scott Klement <c400-l@xxxxxxxxxxxxxxxx>
subject: Re: [C400-L] _Rreadnc() and _Rwrited() from RPG
Pascal,
signals are, as far as I can tell, unrelated to what you're doing.
Signals are usually used for asynchronous notifications, for example,
your program might be running along processing things when another job
wants to interrupt it and tell it to quit. A signal would be ideal here.
SIGIO is usually used in sockets programming when you want your program
to be notified of data arriving on the socket, while it's doing
something else.
There are a few cases in unix programming where signals are used for
errors (those that are normally fatal) but, it's not the normal means of
error handling -- and the _Ropen/_Rread/etc functions are not Unix
functions, they are for IBM i only -- so it would not make sense for
them to use signals for error handling.
Anyway...
There is a parameter to _Ropen() that controls whether programs are sent
escape messages or not. Take a look at the 'rtncode' parameter, here:
http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/topic/rtref/ropen.htm
Not 100% sure how it interacts with Rreadnc() since I've never used the
recio functions with subfiles, personally.
-SK
On 1/7/2014 12:38 PM, Pascal Polverini wrote:
Hi Buck,is
I get an escape message.
I/O error CPF5037 was detected in file MYDSPF(C G D F).
I have attached all the prototypes used for RPG (Rxxx_H.txt).
I have also tried to add a signal() on my code but I don't know if this
relevant or coded properly. This (or the way it is coded) doesn't changepgm
anything
Line added at the very beginning of the code:
signal(SIGIO : %paddr(SignalHandler));
Here the procedure:
P signalHandler b
D signalHandler pi
D sig 10i 0 Value
/free
dsply ('signalHandler called');
return;
/end-free
P signalHandler e
To test it, you simply need to run a READC without having any record
changed in your subfile (Normally a simple Enter on a SFL display to a
that uses / checks for readc).
Pascal
------------------------------
message: 2
date: Tue, 7 Jan 2014 20:37:33 +0100
from: Pascal Polverini <pascal@xxxxxxxxxxxxxxxxxxx>
subject: Re: [C400-L] _Rreadnc() and _Rwrited() from RPG
Hi Mark,
I have tried with
on-error *ALL;
but still have the same result.
I have the feeling that the C function _Rreadnc() can throw an escape msg
directly and out of the RPG "monitor" instruction control...
Pascal
------------------------------
message: 3
date: Tue, 07 Jan 2014 14:50:02 -0500
from: Mark S Waterbury <mark.s.waterbury@xxxxxxxxxxxxx>
subject: Re: [C400-L] _Rreadnc() and _Rwrited() from RPG
Hi, Pascal:
See Scott Klement's recent reply. I think all of these C _Rxxxx
functions have the ability to use a "return code" versus issuing an
*ESCAPE message, so you really need to research that approach.
Hope that helps,
Mark S. Waterbury
> On 1/7/2014 2:37 PM, Pascal Polverini wrote:
Hi Mark,
I have tried with
on-error *ALL;
but still have the same result.
I have the feeling that the C function _Rreadnc() can throw an escape msg
directly and out of the RPG "monitor" instruction control...
Pascal
------------------------------
message: 4
date: Tue, 07 Jan 2014 14:57:50 -0500
from: Mark S Waterbury <mark.s.waterbury@xxxxxxxxxxxxx>
subject: Re: [C400-L] _Rreadnc() and _Rwrited() from RPG
Hi, again, Pascal:
Also, I just noticed that this was posted in the C400-L list -- but this
topic should really be posted in the RPG400-L list, since you are trying
to do this using ILE RPG IV ... you might get more people over there
who have used some of these APIs, who can respond with better answers ...
By the way, since you are using ILE RPG IV, why not just use regular ILE
RPG IV I/O statements, rather than using the C _Rxxx APIs? =-O
All the best,
Mark S. Waterbury
> On 1/7/2014 2:37 PM, Pascal Polverini wrote:
Hi Mark,
I have tried with
on-error *ALL;
but still have the same result.
I have the feeling that the C function _Rreadnc() can throw an escape msg
directly and out of the RPG "monitor" instruction control...
Pascal
------------------------------
message: 5
date: Wed, 08 Jan 2014 01:53:22 -0800
from: CRPence <CRPbottle@xxxxxxxxx>
subject: Re: [C400-L] _Rreadnc() and _Rwrited() from RPG
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.
..."
--
Regards, Chuck
------------------------------
--
This is the Bare Metal Programming IBM i (AS/400 and iSeries) (C400-L)
digest list
To post a message email: C400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/c400-l
or email: C400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/c400-l.
End of C400-L Digest, Vol 12, Issue 5
*************************************
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
