New functionality added to RPG's SND-MSG op code

Two years ago the Send Message, SND-MSG, operation code was added to RPG. In the latest round of Technology Refreshes a number of new options have been added to SND-MSG and the Target, %TARGET, built in function.

To oversimplify it SND_MSG consists to three parts:

1. Type of message to send
2. Message text or variable
3. The target for the message, which is the %TARGET built in function, BiF. This is optional

For example:

SND-MSG *INFO 'Message text goes here' %TARGET(*SELF)

As I said this is an oversimplification for the way I am sure most of us use this op code. For the details on the way to use it with messages from a message file I give examples in my previous post.

There are now six values for the first operand.

• *INFO:  An informational message is sent. This is the default if not first operand is given. Available in the original version of this op code.
• *ESCAPE:  An escape message is sent. This was also in the original version of the op code.
• *COMP:  A completion message is sent. New
• *DIAG:  A diagnostic message is sent. New
• *NOTIFY:  A notification message is sent. RPG does not monitor for this type of messages. New
• *STATUS:  A status message is sent. Status messages are not written to the job log. They are written at the bottom of the display when used in the way I will explain below. New

The number of values allowed for the %TARGET has also been increased.

• *SELF:  Message is sent to the current procedure. This is the default for an *INFO message. Available in the original version of the BiF.
• *CALLER:  Message is sent to the current procedure. This is the default for *ESCAPE, *COMP, *DIAG, *NOTIFY, and *STATUS messages. Available in the original version of the BiF.
• *CTLBDY:  This is for the ILE control boundary. Message is sent to the earliest part of the call stack that is in the same activation group as the procedure where SND-MSG was executed. New
• *EXT:  Represents the external message queue. For *STATUS messages this will display the message at the bottom of the display. New
• *PGMBDY:  This is for the program boundary, which is the most recent procedure on the call stack that is the in the same program or service program as the procedure that executed the SND-MSG.

And now an example of how to use these new operands:

01 **free 02 ctl-opt dftactgrp(*no) ; 03 snd-msg *DIAG 'My diagnostic message' %TARGET(*EXT) ; 04 snd-msg *STATUS 'My status message' %TARGET(*EXT) ; 05 Pause() ; 06 snd-msg *NOTIFY 'My notification message' %TARGET(*EXT) ; 07 *inlr = *on ; 08 snd-msg *COMP 'Program has completed' %TARGET(*PGMBDY:1) ; 10 dcl-proc Pause ; 11 dcl-pr sleep extproc('sleep') ; 12 second uns(10) value ; 13 end-pr ; 14 sleep(2) ; 15 end-proc ;

Before I describe what this program does I just want to say that you do not have to use upper case with the SND-MSG op code or the %TARGET BiF. I have done so make it easier to notice within the source code. If I were doing it for myself it would be all lower case.

Line 1: You know my code is going to be modern RPG.

Line 2: As this program calls a subprocedure I need it not to run in the default activation group.

Line 3: This is my line to send a diagnostic message to the external message queue.

Line 4: When I send my status message to the external target it will display at the bottom of the display until the next message. Which is why…

Line 5: I pause the program for a couple of seconds to allow me to notice the message. The pause is achieved using the Sleep C procedure. I have placed the procedure prototype and the statement to delay the program for two seconds in the subprocedure Pause, lines 10 - 13. Status messages are not written to the job log.

Line 6: I have to admit that I have not seen notification in RPG programs before. Here I send one.

Line 8: I am sending a completion message using the *PGMBDY target. The "1" in the %TARGET means that the message is issued to the previous program in the call stack. My preference that if any processing is done at the end of the program I always place it after the line to set on the LR indicator, line 7. There is no reason you have to do that in your programs.

What is seen when the program is called?

When the status message is sent it will be seen at the bottom of the screen for two seconds.

When the notification message is sent the Display Program Message screen is displayed and I am asked to end a reply to the message:

Display Program Messages My diagnostic message My notification message. Type reply, press Enter. Reply . . .

I did not enter any value. I just pressed the Enter key so the program would continue.

When the program has completed the completion message is shown at the bottom of the display. If I look in the job log, using the DSPJOBLOG command, I see the following.

My diagnostic message My notification message. *N My notification message. *N Program has completed

The "*N" denotes a null reply, which is true as I just pressed the Enter key.

This is a good example of when using SQL gives better results than just using CL commands. The job log gives me limited information unless I drill into each command's line. Using SQL I can get more information from the initial results of the JOBLOG_INFO View:

01 SELECT MESSAGE_TEXT,MESSAGE_TYPE,MESSAGE_ID 02 FROM TABLE(QSYS2.JOBLOG_INFO('080072/RPGPGM/QPADEV0001'))

These are the messages the program sent:

MESSAGE_TEXT MESSAGE_TYPE MESSAGE_ID ------------------------ ------------- ---------- My diagnostic message DIAGNOSTIC <NULL> My notification message. SENDER CPF9898 *N REPLY <NULL> My notification message. NOTIFY CPF9898 *N REPLY <NULL> Program has completed COMPLETION <NULL> Program has completed INFORMATIONAL <NULL>

These results show the message types of the messages I sent, and if the operating system used a message id to show them.

You can learn more about this from the IBM website:

• SND-MSG op code
• %TARGET BiF

 

This article was written for IBM i 7.5 TR4 and 7.4 TR10.