Although the Send Program Message (SNDPGMMSG) command serves many useful purposes, one of my favorites is to use SNDPGMMSG to send a status message for update purposes from an interactive CL program to the bottom (line 24) of an interactive green-screen display. This technique is particularly valuable when you're calling a long-running job -- such as a customized CL backup program -- that must be run interactively from the system console.
The code is fairly simple and it's already a part of many OS/400 administrators' toolkits. Here's how I usually send a simple status message to the external message queue from an interactive CL program:
SNDPGMMSG MSGID(CPF9898) MSGF(QSYS/QCPFMSG)
MSGDTA('Your message here. Rates have never been cheaper') TOPGMQ(*EXT) MSGTYPE(*STATUS)
Message ID (MSGID) CPF9898 is a general escape message of 512 characters or less that can be used in application programs; some people also like to use Message ID CPF9897, which accomplishes the same function. CPF9897 and CPF9898 are contained in message file QCPFMSG in library QSYS (the MSGF parameter value). The '*EXT' value in the Call stack entry message queue parameter (TOPGMQ) tells OS/400 to send this message to the external message queue of the job. OS/400 uses the external message queue to communicate with the external requester of the job, which in this instance is a display station or a 5250-session user.
The Message type parameter (MSGTYPE) value of '*STATUS' tells OS/400 that this message describes the status of the work that is being performed by your CL program. If you were using SNDPGMMSG in conjunction with the Monitor Message (MONMSG) command, the first 28 characters of your Message data field value (MSGDTA) could be used for MONMSG comparison data. Since there isn't any message monitoring occurring in this example, control is returned back to the CL program immediately after SNDPGMMSG is called, so the message displays while the next command is running.
Finally, the MSGDTA parameter contains the character string that displays on line 24 of the screen. This parameter can either contain a text value or a variable containing the text you want to send; and MSGDTA variables can also be built in your CL program so that SNDPGMMSG displays the values of other program variables. Although MSGDTA can contain a large number of characters, the practical limit for a line 24 status message is 80 characters; the remaining characters will be truncated and -- since this SNDPGMMSG configuration doesn't write status messages to the job log -- it's not worth it to send messages with a longer length.
SNDPGMMSG can be called from either an OPM or an ILE CL program. Once the message is displayed, it usually remains on the screen until another message is displayed, the status line is cleared, or the program ends.
As I said, SNDPGMMSG is a basic element of an administrator's programming toolkit. This command can do much more than the simple status message display I discussed here, so it's worth getting familiar with it if you're creating CL programs to administer, maintain, and backup your system.
About the author: Joe Hertvik is an IT professional and freelance writer who has been working with OS/400 since the days of the System/38 in the mid-1980s. Joe can be reached at firstname.lastname@example.org.
- Reorganize physical files automatically
This tip consists of two CL programs and one RPG program. The first CL program creates a work file of the files in a given library. The RPG program reads the work file and calculates a percent of deleted records to control the file reorganization process. The second CL program reorganizes the file meeting the percentage that is coded in the RPG program. Search400 member Kellie O'Shea runs this code over several libraries on a long weekend.
- Execute a CL program
One user writes, "I am attempting to execute a CL program on system b from a CL program that resides on system a. The CL on system b has parameters that are variables. The procedure will work with SBMRMTCMD, but when I attempt to execute it with AREXEC or RUNRMTCMD, the error message that I receive states that variables are invalid. If I substitute a literal for the variable, there is not a problem. Do the later two commands actually not accept variables? I found this hard to believe and am hoping that it is user error." Search400 application development expert John Brandt offers some advice.
.PeYsaYEpcqR^6@.ee84638/1131>Run priority of a CL program
One member writes, "I understand how to manually change the run priority of a CL program after it has been called. What I would like to know is what can I put in the CL to change the run priority of the CL when it is called?" One suggestion was made. Do you have any others?
- Search400's Best Web Links on Systems Management