User feedback is an important part of any application design, and program messages provide a powerful, flexible tool to communicate with your users.

Program message support is a powerful feature woven into the very fabric of i5/OS. Nearly all facets of programming on the platform can make use of these messages, and the more you use them the more powerful they become. They can provide for everything from error handling to user notification to customization to internationalization. Usually such flexibility can be achieved only through a relatively complex set of APIs, and the program message APIs are no exception. Fear not; this article starts you on the path of enlightenment with an example that's easy to understand.

Welcome to Program Messages

The simplest way to view a program message is as a notification from one program to another. A program message starts with a message description, which is identified by a seven-character message ID. Most i5/OS developers are familiar with the message ID concept, with CPF0001 being a common message received when a program is not found. The message notifies the caller of some sort of condition. The condition doesn't even have to be an error; program messages are often used to indicate successful completion of a task.

The primary component of a message is the message text. Note that messages actually support two different text values: the first-level and second-level text. Typically, only the first-level text is shown, and usually in a single line on the screen, so for messages meant to be read by users, keep the first-level text concise. The second-level text is seen only in the joblog or when a user presses the Help key on a standard message. The moral is to keep your message short.

Besides literal text, messages can also have substitution variables as shown in Figure 1. I'm showing a simple user-defined message rather than one of the system-supplied messages. I wanted to showcase the capability of creating user messages; you really start taking advantage of program messages when you have your own message files and messages.

Figure 1: This is how a message description is structured and used. (Click image to enlarge.)

In this case, I have a message file with just a couple of messages in it, MSG0001 and MSG0002. Of these, I'm only showing MSG0001, which has text of "Customer &1 not found." The &1 indicates a substitution variable, and if we look at the command that creates it, we can see how that variable is expected to look.

 ADDMSGD    MSGID(MSG0001) MSGF(MYLIB/MYMSGF) +

            MSG('Customer &1 not found.') +

            FMT((*CHAR 10)) 

There you go, a simple message. I had to have previously created a message file named MYMSGF in MYLIB, and then I execute this command to add the MSG0001 message description. The FMT keyword defines the size and type of the substitution variables, while the MSG field shows where they go in the message.

In a more robust environment, I might also specify a second-level text that would provide more information, typically more complete cause information and suggested recovery options. The second-level text shares the substitution variables with the first-level text.

Using the Program Message

I noted before that the underlying API is relatively complex. That's true; the i5/OS APIs used to directly support program messages include QMHSNDPM, QMHRCVPM, and QMHRMVPM, which take up to 15 parameters. The good news is that, especially for this example, you don't need them, because IBM kindly wrappered those APIs in some relatively easy to use commands. The SNDPGMMSG in particular allows you to send a program message without having to worry about most of the complexity of the QMHSNDPM API.

In this very simple example, I'm going to send a program message from a called program (PMISND) back to the calling test program (PMISNDT1). I'll be calling the test program from the command line, so the message will appear in the job log for the job.

Here are the two programs:

 PMISND:  PGM        PARM(&MSGID &MSGDTA)

          DCL        VAR(&MSGID) TYPE(*CHAR) LEN(7)

          DCL        VAR(&MSGDTA) TYPE(*CHAR) LEN(80)

          DCL        VAR(&MSGFNAM) TYPE(*CHAR) LEN(10) +

                       VALUE('MYMSGF')

          DCL        VAR(&MSGFLIB) TYPE(*CHAR) LEN(10) +

                       VALUE('*LIBL')

          SNDPGMMSG  MSGID(&MSGID) MSGF(&MSGFLIB/&MSGFNAM) +

                       MSGDTA(&MSGDTA) TOPGMQ(*PRV) MSGTYPE(*INFO)

          ENDPGM 

This message program is quite simple. It takes a message ID and some message data and sends the message. What isn't immediately obvious is the TOPGMQ parameter, which allows me to specify the target of the message. The default as shown here just sends the message to the calling program, but other options allow you to send the value to other places in the stack or even to the external message queue (this is good for sending status messages).

This default is also used by the majority of interactive programs because it will automatically send the message to the calling program, which in turn can display all program messages by using a special feature of the 5250 display file, the program message subfile. I'll deal with that in another article.

OK, let me show you the calling program:

 h option(*srcstmt: *nodebugio)

 d PMISND          pr                  extpgm('PMISND')

 d   msgid                        7    const

 d   msgdta                      80    const

  /free

   PMISND('CUS9999':' ');

   *inlr = *on;

   return;

  /end-free

The program is hard-coded to send message CUS9999. This might be the case if, for example, you have yet to actually write the underlying logic and this is just a placeholder routine.

 ADDMSGD    MSGID(CUS9999) MSGF(MYLIB/MYMSGF) +

            MSG('Function not implemented.')

If I compile both programs and call PMISNDT1, I get this:

   > call pmisndt1             

Type command, press Enter.    

===>   __________________________

_________________________________

You'll note that you don't see the message. That's because the message was sent to the PMISNDT1 program, not to the command-line processor. The message is in the job log, but not available at this level. To see the CUS9999 message, just hit F10 (Include Detailed Messages). This will appear:

 4 > call pmisndt1             

 Feature not yet implemented.

Type command, press Enter.

===>   __________________________

_________________________________

You can make the message appear a couple of other ways, either hard-coding the target to be QCMD instead of *PRV or else using the QMHSNDPM API to do a little more sophisticated work.

A Brief Look at Message Data

So what about the message data parameter? Let me show you a final example, with a little modification to the test program. First, let me add a new message.

  ADDMSGD    MSGID(CUS0001) MSGF(MCP/MYMSGF) +

             MSG('Customer &1, name &2.') +

             FMT((*DEC  6 0) (*CHAR 30))

In this command, I've identified two parameters, one a 6.0 packed-decimal field and one a 30-byte character field. I've also identified where in the message the substitution variables should appear. Now, to use this new message, I wrote a new program that takes a parameter and then sends the new message along with the appropriate message data.

 h option(*srcstmt: *nodebugio)

 d PMISND          pr                  extpgm('PMISND')

 d   msgid                        7    const

 d   msgdta                      80    const

 d PMISNDT2        pr

 d   Customer                     6S 0

 d PMISNDT2        pi

 d   Customer                     6S 0

 d dsMsgdta        ds                   qualified

 d  Customer                      6P 0

 d  Name                         30

  /free

   dsMsgdta.Customer = Customer;

   dsMsgdta.Name = 'Customer Name';

   PMISND('CUS0001':dsMsgdta);

   *inlr = *on;

   return;

  /end-free

This program accepts a single six-digit zoned decimal number and then puts that customer number along with a dummy customer name into the dsMsgdta data structure. You can see that dsMsgdta has two fields, one for the 6.0 packed customer number and one for the 30-byte customer name value. That data structure is passed to the PMISND program and is then used as the MSGDTA parameter on the SNDPGMMSG command. And here is what happens:

 4 > call pmisndt2 '123456'

 Customer 123456, name Customer Name.

Type command, press Enter.

===>   __________________________

_________________________________

That's it! The messaging software takes care of formatting the message properly. Of course, this is a very trivial example, but it gives you an idea of how the technique can be used. Rather than just a generic message, you can provide specific information to help the user better understand the situation. I hope this was intriguing, and perhaps I can write more articles on this subject.