Joe,
It may not seem so easy but the Receive Program Message (QMHRCVPM) API format RCV0200 has the Sending program's instruction number.
Sending program's instruction number.
The number of the program instruction that issued the command or called the API used to send the message being received.
Format RCV0300 has Sending program's statement numbers or instruction numbers, Sending program name, Sending module name and Sending procedure name.
Sending module name.
For type 1 and 2, the name of the module that contains the sending message.
Sending procedure name.
For type 1, the name of the procedure sending the message. A nested procedure name has each procedure name separated by a colon. The outermost procedure name is identified first followed by the procedures it contains. The innermost procedure is identified last in the string.
Sending program name.
The program name or ILE program name that contains the procedure sending the message. This field is blank if the sending type is 3.
Sending program's statement numbers or instruction numbers.
This field can contain up to three statement numbers or an instruction number. When the sending type is 0 or 3, this field contains an instruction number.
The instruction number is 4 characters in length of original program model (OPM) programs and 6 characters in length for System Licensed Internal Code (SLIC)
programs. For all other sending types, this field contains statement numbers. Each statement number can be up to 10 characters in length. The instruction
number is 4 characters in length. Each statement number or instruction number is left-justified in a 10-character partition of the 30-character field. The first
statement number or instruction number is in the leftmost 10 characters and the third in the rightmost 10 characters. The unused parts of this field are set to blanks.
Sending type.
The type of the sender (whether it is a program or procedure). Possible values and their meanings are as follow:
0 Sender is an original program model (OPM) program or a System Licensed Internal Code (SLIC) program with up to and including 12 characters in its name.
1 Sender is a procedure within an ILE program, and the procedure name is up to and including 256 characters in length.
2 Sender is a procedure within an ILE program, and the procedure name is from 257 characters up to and including 4096 characters in length. For this type,
the sending procedure name is blank and the name can be obtained from the long sending procedure name.
3 Sender is a SLIC program with 13 or more characters in its name. For this type, the sending program name is blank, and the name can be obtained from the
long sending program name.
So scanning back through the program's messages may get you what you are looking for. Of course I'm assuming the PSDS CPF message is the one you want to report.
Gary Monnier
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Joe Pluta
Sent: Thursday, April 05, 2012 10:25 AM
To: RPG programming on the IBM i / System i
Subject: PSDS and Monitor
I've run into a little hitch when attempting to use the program status data structure in conjuction with a monitor block.
Here's the skeleton of a standard mainline for me:
iRC = 0;
monitor;
iRC = process();
on-error;
iRC = 999;
PSDSInfo =
' (' + %char(PSDS_Status) + ')@' + PSDS_Line;
endmon;
if iRC <> 0;
dump(a);
ExceptionInfo =
'** Internal error ' + %char(iRC) + PSDSInfo;
dsply (ExceptionInfo);
endif;
*inlr = *on;
Pretty straightforward. Set error code to zero. Execute process() which returns zero or an error. On error, set iRC to 999 and get the status and failing line from the program status data structure. After the monitor block, check the return code. If it's non-zero, display the error.
The problem? By the time I hit the on-error block, the line number for the PSDS is the call to process, not the line that actually failed.
Let's assume this is a normal program with H specs and a prototype and so on. In that case, the line iRC = process() would be, say, line 18.
So every time I get an error, the line number would be 18.00.
So evidently any entry in the call stack causes the PSDS to be changed.
Is there a way to identify the actual failing line?
Joe
--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing list To post a message email: RPG400-L@xxxxxxxxxxxx<mailto:RPG400-L@xxxxxxxxxxxx> To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx<mailto:RPG400-L-request@xxxxxxxxxxxx>
Before posting, please take a moment to review the archives at
http://archive.midrange.com/rpg400-l.
midrange.com
