The Inca people of sixteenth-century South America had only one way to send messages. They encoded messages by tying knots in a colored string called a quipu. The quipu was relayed from one runner to another until it reached its destination.
Unlike the Incas, you must make a decision when you wish to send a message on the AS/400. There are several message-sending commands, and each one has its own purpose. Let's take a quick look at them.
SNDMSG
Send Message (SNDMSG) is the command to use when you want to communicate with another user on the system. You'd use this command to notify Sue in Payroll that you noticed the check stock is getting low or to ask Bob in Accounting when he expects to have the month closed out. While you can send a message to a specific terminal, you'd probably send it to a specific user instead. The user would get the message, regardless of which terminal he was signed on to.
The message has to be an immediate (impromptu) message; you can't refer to a message stored in a message file. If you want a reply, specify MSGTYPE(*INQ), which makes the message an inquiry message.
SNDBRKMSG
The Send Break Message (SNDBRKMSG) command was designed for system operator use, but others can use it as well. It differs from SNDMSG in two significant ways. First, you can't send messages to user profiles. Instead, you must send them to specific workstations. Second, when the message reaches its destination, it interrupts the job by presenting the Display Message (DSPMSG) screen.
You can use the Change Job (CHG-JOB) command to disable the interruptions. Change the BRKMSG parameter of the job receiving the messages to *NOTIFY or *HOLD.
SNDNETMSG
If your AS/400 participates in a network, you can use the Send Network Message (SNDNETMSG) command to communicate with users of other systems. SNDNETMSG sends an informational message to the users and distribution lists you specify. You can send network messages to local users as well if they are enrolled in the system directory.
SNDUSRMSG
Send User Message (SNDUSRMSG) is not a command you'd use to send a message from your terminal. It's one of two commands that CL programs use to send messages. Its usual function is to request information from a human user. One interesting difference between SNDUSRMSG and other message-sending commands is that, by default, SNDUSR-MSG sends an inquiry message, not an informational message. SNDUSRMSG can translate replies with a translation table, verify replies against a list of accepted values, and fill in a default reply.
You might use SNDUSRMSG to ask a user to fill in some parameter values before submitting a job to batch. This is fine for rarely used jobs and "one-shot" jobs, but for regular production work, it's better to use a more elegant technique, such as prompting a command or presenting a display file for the user to key the requested information into.
SNDPGMMSG
The other command that CL programs use to send messages is Send Program Message (SNDPGMMSG). While you can use SNDPGMMSG to send messages to workstations, it's best used for sending messages from one program to another. For instance, if a CL program can't find an object it needs, it can send a message to the program that called it.
SNDPGMMSG can send more than informational and inquiry messages. It can send status messages, which report on the progress of a job; diagnostic messages, which tell of problems or errors; completion messages, which say that a program ended normally; escape messages, which tell that a program ended abnormally; notify messages, which ask for corrective action so the program can continue; and request messages, which contain commands.
SNDNWSMSG
If you're running a LAN Server/400 network, you have yet another command to master. The Send Network Server Message (SNDNWSMSG) command lets you send an immediate message to users currently logged into the network. Send the message to a single user, or use the special value *DOMAIN (in the USER parameter) to send it to everybody who is currently logged on.
Parting Comments
Trying to remember what each command does can be tedious. I hope 1 (see page 116) will be of benefit to you. It shows at a glance the similarities and differences of the OS/400 messaging commands. Once you've mastered these commands, you might want to take a look at the System API Reference manual. Quite a few APIs handle messaging.
Trying to remember what each command does can be tedious. I hope Figure 1 (see page 116) will be of benefit to you. It shows at a glance the similarities and differences of the OS/400 messaging commands. Once you've mastered these commands, you might want to take a look at the System API Reference manual. Quite a few APIs handle messaging.
OS/400 offers all the tools you need to be sure that your message has been properly communicated to the appropriate party; it's up to you to use them.
To quote the movie Cool Hand Luke,"What we've got here is failure to communicate." These commands will ensure that you don't fail to communicate your message on the AS/400.
Ted Holt is an associate technical editor for Midrange Computing.
References
AS/400 CL Reference V3R1 (SC41-3722, CD-ROM QBKAUP00).
OS/400 CL Programming V3R1 (SC41-3721, CD-ROM QBKAUO00).
OS/400 System API Reference V3R1 (SC41-3801, CD-ROM QBKAVD00).
Getting the Message Across
Figure 1: Message-sending Commands at a Glance
SNDMSG SNDBRKMSG SNDPGMMSG SNDUSRMSG SNDNETMSG SNDNWSMSG Impromptu message allowed Yes Yes Yes1 Yes Yes Yes Predefined message allowed No No Yes Yes No No Valid in CL program only No No Yes Yes No No Valid from command line Yes Yes No No Yes Yes *INQ (allow reply) Yes Yes Yes Yes No No Translation table allowed for reply No No No Yes N/A N/A Validity checking of replies permitted No No No Yes N/A N/A *INFO Yes Yes Yes Yes Yes N/A *COMP No No Yes No No N/A *DIAG *NOTIFY *ESCAPE *RQS *STATUS Default message type *INFO *INFO *INFO *INQ *INFO N/A May be sent to workstation message queue Yes Yes Yes Yes No No in directory) Default message queue None None The program The external The message N/A message queue message queue queue defined of the caller (interactive) or for the QSYSOPR message recipient queue (batch) Allow distribution list No No No No Yes No 1*INFO, *INQ, *COMP, *DIAG, *RQS message types only
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online