× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.

Back in the dark ages, in the time of 4800 baud modems, store polling, and data queues having yet to be invented, a co-worker wrote a polling suite that used messages to drive it. Tables of stores, lines, devices, etc. We had a pool of modems and, when a line became available, and a store needed to be polled, the driver would pair them up and launch a job.

Nowadays, you'd use data queues but just think of messages as a means of inter/intra process communications.

Buck's use for logging is a good example. I've done that myself.

Roger Harman
COMMON Certified Application Developer - ILE RPG on IBM i on Power

-----Original Message-----
From: C400-L <c400-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Buck Calabro
Sent: Tuesday, November 7, 2023 8:10 AM
To: C400-L@xxxxxxxxxxxxxxxxxx
Subject: Re: [C400-L] 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.


Your updates make it better!

This is the Bare Metal Programming IBM i (AS/400 and iSeries) (C400-L) mailing list
To post a message email: C400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/c400-l
or email: C400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/c400-l.

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-2023 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.