Coding Standards for Database Files › Coding Standards for Messages › Execution Messages › Destination for Messages

Destination for Messages

The following general points should be observed about the destination of execution messages:

• Escape messages should be resent to the invoking program. This will cause them to ‘cascade’ back, unless a particular program in the invocation stack monitors for them explicitly. OS/400 V2R2 provides message handling APIs that make this easy to do from HLL’s other than CL. Using the APIs, you may wish to pass an invocation number as a parameter to indicate where the message should be sent.
• A final completion message should be sent to the invoking program. It will then appear in the job log.
• Status messages are, by definition, sent to the external message queue.
• Other message types—diagnostic or informational—should normally be left on the program queue to which they were sent. They will then be available if the second level messages are displayed (for instance, by pressing F10 from the OS/400 ‘Command entry’ display (QCMD) on the IBM i).

For example, suppose a command calls a command-processing program, which in turn calls several subprograms.

Diagram of Destinations for Messages:

If the program is a request-processing program, you should ensure that a copy of the request is placed in the log so that the retrieve (F9) facility of other programs can be used to retrieve it.

Functions which process a number of items should return a count of the number of objects successfully processed as their completion message. For example:

&1 Objects moved: &2 added, &3 replaced. &4 not moved.

Long running jobs should send status messages to report the job’s progress. For instance, ‘Records being copied to file QTXTSRC’, ‘Work space is being loaded’, ‘Entire system is being backed up’. This can be done as follows: