Re: IBM i messages

On 11/3/2023 4:50 PM, Patrik Schindler wrote:

I'm seeking out once more to grok IBM i messages, especially QMHSNDPM/QMHRCVPM. There are a lot of examples to be found by Google but those examples always assume context with some actual program implementation. Also, there is documentation from IBM, which largely assumes being born in the OS/400 world.

Is anyone aware of some writeup, shedding light on the topic from another angle: When someone has UNIX programming experience? This is not necessarily about C but also about ILE RPG. In the end, the programming language shouldn't matter for better understanding. I'm writing to this group because I assume that people programming in C might have a background from other operating systems.

I'm still thinking that IBM i messages are a bit like UNIX signals, but much more extensive. Opinions are welcome.

I'd say the nearest analogue would be Java Throw/Catch.

IBM i is message driven. If a command encounters an issue, it throws (SNDMSG) *INFO or *DIAG message(s), followed by a *ESCAPE message. That escape message interrupts the caller, forcing it to handle the exception.

In *nix, a utility sets a return code, which the caller needs specifically to check to find out how it went.

Also, the description of real world use cases for exchanging messages between applications might help to understand. Things I've found with Google also were rather complex and way too theoretical for my brain to digest. ;-)

I made special note that the OS throws escape messages, because there's not a lot of user-land code that does that. But all IBM i OS code behaves this way.

That said, there is at least one user-land use for messages: Subfile message queues. You make a display file that has a SFLMSGQ, and messages sent to it are automatically displayed there. These messages have full IBM i functionality - the Help key shows second-level text, the messages are translated, etc.

I myself use *INFO messages occasionally for logging/debugging purposes. Messages like this are sent to the job log, and can serve in the place of a separate printer file or stream file type of log.