Hi Alan,

Thank you for all the details you shared with me. This is an interesting construct. But why do you pass the message behind the scene in a linked list? Why don't you use the QMHRCVPM API for retrieving the last escape message? Do you want to be able to pass more than one message in a "safe" container up the line? I am just curious.

For now I do not think that your error handler helps me solving my problem. The problem I have is not handling errors. Handling errors works fine for what I need with "monitor" statements and the QMHRCVPM API.

The problem I have is that there can be programs or service programs out of my control that can cause runtime errors, such as a "division by zero". These errors are captured by a "monitor" block and the message is retrieved by the QMHRCVPM API. That works fine.

Now I had the idea to enable the user to open the source member of the failed program. For that I need the qualified module and program names (actually only the qualified program name). Then I could check the objects for source information and eventually load the source member into the LPEX editor.

Sadly the QMHRCVPM API does not return the program and module libraries. Maybe IBM just forgot to add the libraries to the "Sender Information Format".

The QGYOLJBL API does return the program library but not the module library. Only Murphy knows why the module library is missing.

Only the call stack API QWVRCSTK returns the program and the module library, but that API does not help here, because the failing call stack entry has already been removed from the stack, when the program reaches the "on-error" statement.

So at the end I almost dropped that idea and I consider displaying a little dialog similar to the "Display Message Details" screen.

Thomas.

-----Ursprüngliche Nachricht-----
Von: RPG400-L <rpg400-l-bounces@xxxxxxxxxxxxxxxxxx> Im Auftrag von Alan Campin
Gesendet: Sonntag, 31. März 2024 08:29
An: RPG programming on IBM i <rpg400-l@xxxxxxxxxxxxxxxxxx>
Betreff: Re: How to get the program library name of a program that sent a message

Thomas, glad you took a look. Let me quickly go through the design concept.

Program A calls Procedure B in Service Program C which calls Procedure D in Service Program E.

How does Procedure D, if it encounters an error, inform program A that a problem occurred and report the details. That is where the standard error handler comes in.

It throws the error which terminates the procedures but it also logs the message in a linked list. Once it gets to the top it can retrieve the details. I like the idea of adding a new optional parameter that contains the program name although you can send that information up in the message text.

If you look at different places in my source code you can see it being used.

There is one more piece of the puzzle and that is ILE Condition Handler called CEEHDLR. With API you register an error handler at startup of your program.

When an error occurs that is not monitored, it calls the procedure you have specified. With the API, you can decide to handle the error yourself or you could use XVERRH_Throw to log the error and shutdown processing. This is a link to a very old article and the code is really old using fixed format C specs but it gives the framework in the code at the end.

https://www.mcpressonline.com/programming/rpg/implementing-ile-condition-handlers

You might find further examples on line.

As to XVERRH_Rethrow, the concept is that I am in a procedure and I want to call an internal procedure to perform an action and I want to throw any errors that occur in that procedure back to the caller. With XVERRH_Rethrow I just monitor for the error in the caller and if it fails it just throws the error back up the line. Just gives me a simple way to pass errors up the line from internal procedures.

Here is an example.

Monitor;
GetFileStats(InFilePath:
FileStats );
On-Error;
XVERRH_Rethrow();
EndMon;

*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

* GetFileStats

* Get file stats.

* Input - File Path

* In/Out - Stats structure.

* Returns - None.

* - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
dcl-proc GetFileStats;
dcl-pi *N;
InFilePath VarChar(512) Value;
InStatsDataSturucture LikeDs(TD_FieStats);
end-pi;

dcl-pr StatAPI Int(10) ExtProc('stat')
PR_FilePath Pointer Options(*String) Value;
PR_PointerToStructure Pointer Value;
end-pr;

dcl-s Message Id Char(7);

If StatAPI(InFilePath :
%Addr(InStatsStructure)) < 0;
MessageId = GetErrorMessageId();
XVERRH_Throw(MessageId :
CPF_MESSAGE_FILE_NAME:
' ' );
EndIf;

Return;

end-proc;

Feel free to contact me if you want to discuss further.


On Sat, Mar 30, 2024 at 10:26 AM Thomas Raddatz <thomas.raddatz@xxxxxx>
wrote:

Hi Alan,

Thank you for jumping in. I downloaded the utility and had a brief
look at the source members you mentioned. Did I miss something or does
the utility not need (and hence retrieve) the library names of the
programs sending and receiving a message?

What I have seen is that you build a linked list of messages. The
attributes per entry are:

- Message ID
- Qualified message file name
- Message data length
- Message data
- Pointer to next entry

Next you add messages in procedures " XVERRH_Throw" and " XVERRH_Rethrow ".

But I did not find any instruction that receives a message so I assume
that you do not need to receive a message from the job log. At that
point I stopped analyzing the utility.

So I am a bit lost, because I do not have an idea how your standard
error handler could help me. What I need is the sender and the
receiver of an escape message sent anywhere from a test case. Most of
the time it is the RPG runtime that sends an escape message but of
course also the user could do that for whatever reasons.

At the end of a test suite the result is displayed in a view and
optionally the user can load the source code into the LPEX editor.
That works fine for failed assertions because in these cases I know
everything from the call stack. But in case of a unexpected error, I
miss the library names when I receive the escape message with the QMHRCVPM API.

For know I assume that I will use the QGYOLJBL API to retrieve the
received message by its message key from the job log again, so that I
can get the library names from the return value of the API. The
QGYOLJBL API returns the library names whereas the QMHRCVPM does not
return them. I do not mind reading the message twice, because that is
not part a regular process.

Anyway, thank you for jumping in. Every voice counts.

Have a nice Easter weekend,

Thomas.

-----Ursprüngliche Nachricht-----
Von: RPG400-L <rpg400-l-bounces@xxxxxxxxxxxxxxxxxx> Im Auftrag von
Alan Campin
Gesendet: Samstag, 30. März 2024 03:30
An: RPG programming on IBM i <rpg400-l@xxxxxxxxxxxxxxxxxx>
Betreff: Re: How to get the program library name of a program that
sent a message

ACHTUNG: Diese E-Mail stammt von einem externen Absender. Klicken Sie
nicht auf Links und öffnen Sie keine Anhänge, solange Sie den Absender
nicht erkennen und wissen, dass der Inhalt sicher ist.

May I suggest my standard error handler. You can get a copy by going
to www.sourceforge.net/projects/iBuild.

The source code you want to download is XVERRH, XVERRH_B, XVERRH_M01,
XVERRH_M02, XVERRH_M03 and XVERRH_PR or I would be glad to send it to you.

My standard error handler has functions that throw an error while
logging an error in a linked list. You can then catch the error at a
higher level and get the message and details.

Anyway a standard way to handle and return data to the caller.

On Fri, Mar 29, 2024 at 10:0 AM Thomas Raddatz <thomas.raddatz@xxxxxx>
wrote:

I already use the QMHRCVPM message to receive a message send by a
program.
The sender information of format RCVM0300 contains the program,
module and procedure name as well as the statement number of the
program that sent the message. But it does not contain the program library name.

However the program library name is displayed, e.g. if you do a
DSPJOBLOG, prompt a message with F1 and switch to the message
details
with F9, e.g.:

From program . . . . . . . . . : RUCALLTST
From library . . . . . . . . : RPGUNITDVP
From module . . . . . . . . : PGMMSG
From procedure . . . . . . . : PGMMSG_sndEscapeMsgAboveCtlBdy
From statement . . . . . . . : 35600

Hence the information must be available somewhere. Hopefully not
only for the operating system.

So does somebody know how to get the above information of a message
send by a program?

Thomas.
--
This is the RPG programming on IBM i (RPG400-L) mailing list To post
a message email: RPG400-L@xxxxxxxxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription
related questions.


--
This is the RPG programming on IBM i (RPG400-L) mailing list To post a
message email: RPG400-L@xxxxxxxxxxxxxxxxxx To subscribe, unsubscribe,
or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription
related questions.

--
This is the RPG programming on IBM i (RPG400-L) mailing list To post a
message email: RPG400-L@xxxxxxxxxxxxxxxxxx To subscribe, unsubscribe,
or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription
related questions.


--
This is the RPG programming on IBM i (RPG400-L) mailing list To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related questions.


As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.