Because messages are not displayed the moment they are sent, there can be a delay (of unknown length) between the time you send a message and the time the recipient reads it. If your message is urgent, you should consider sending your message as a break message. Break messages interrupt the recipient's interactive job and display the message immediately.
To send a break message, use the Send Break Message (SNDBRKMSG) command. The SNDBRKMSG command is similar to SNDMSG, except that it has a few restrictions. You cannot send a break message to a user's message queue. You can only send it to a display station message queue, which means that if you want to send a break message to user FRANNIE, you must first find out where FRANNIE is signed on. For example:
WRKUSRJOB USER(FRANNIE) STATUS(*ACTIVE)
Using the Work with User Jobs (WRKUSRJOB) command, you can find the names of the active jobs that user FRANNIE is running. You could omit the STATUS parameter, but in that case you would get all of FRANNIE's jobs (she may have dozens of jobs that are either completed or waiting in a job queue, and you are not interested in those).
When the system shows you the list of jobs, you can visually scan it for interactive jobs (type INT). The job name is always equal to the display station name.
With this knowledge, you now can run the SNDBRKMSG command to send Frannie a break message. For example:
SNDBRKMSG MSG('Hey, let's do lunch.') TOMSGQ(INVDSP03)
Like SNDMSG, you can send the same break message to more than one place. The TOMSGQ parameter accepts a list of display station names (to send the same break message to several specific display stations) or even *ALLWS, which sends the message to all workstations, whether they are in use or not. IBM does not, however, provide an *ALLACT value ("all active"), as it does for the SNDMSG command.
Break messages can be annoying because they interrupt whatever the recipient is doing at the display station. Break messages are disruptive; just as when two people are engaged in a conversation and someone else breaks in without waiting for a pause in the conversation. Therefore, you should send as few break messages as possible.
On the other hand, you might prefer break messages and wish there was a way you could force the system to treat all your incoming messages as break messages. Then you would not miss any messages at all.
You can do that using the Change Message Queue (CHGMSGQ) command, as follows:
CHGMSGQ MSGQ(…) DLVRY(*BREAK) PGM(*DSPMSG)
DLVRY(*BREAK) changes the way the system handles your incoming messages; now they will break into your job. When this happens, the system runs a program named in the PGM parameter. In this case, the special value *DSPMSG means that the system will run the DSPMSG command. The result is that when someone sends you a message (with SNDMSG or SNDBRKMSG), you will receive the message in break mode and the system will run the DSPMSG command for you automatically.
You can create your own break-handling program and put its name in the PGM parameter instead of *DSPMSG. This way, you can "monitor" your message queue and invoke your break-handling program automatically every time a new message arrives.
One good way to take advantage of this feature is to change break messages into status messages. A break message interrupts your interactive job, but a status message unobtrusively appears at the bottom of the display while you are working.
Figure 8.2 shows an example of a break-handling program that converts break messages to status messages.
Figure 8.2: Break message handling program.
To compile, use the following command:
CRTCLPGM PGM(xxx/MSG2LIN24) SRCFILE(xxx/QCLSRC)
Key the program into source physical file QCLSRC in one of your libraries (represented by xxx), then compile the program by executing the CRTCLPGM as indicated. Now run the following command:
CHGMSGQ MSGQ(…) DLVRY(*BREAK) PGM(xxx/MSG2LIN24)
Because you are instructing the system to run MSG2LIN24 as your breakhandling program, MSG2LIN24 will run whenever a new message arrives to your message queue. MSG2LIN24 receives the message from your message queue and sends it again as a status message that appears at the bottom of your screen.