Sometimes you want to see messages that tell you things went right instead of wrong.

Written by Bruce Vining

In the previous article, "More On Sending Messages from an Application Program", the Send Program Message (QMHSNDPM) API was used to send a user error message indicating that a severe error had been encountered and, if appropriate, diagnostic messages explaining the cause of the error. But not all programs encounter problems—at least I hope not all of your programs do! In this article, the QMHSNDPM API will also be used, but now to send a variety of non-error related messages.

Learn how to send program messages based on an API error code structure.

Written by Bruce Vining

In the previous article, "Inform Users of Problems by Sending Error Messages from Application Programs," the Send Program Message (QMHSNDPM) API was used to send a user error message indicating that a severe error had been encountered. In this article, the QMHSNDPM API will also be used, but now to send a system-related error message followed by a user error message.

As a review, back in "What to Do with Messages in the Application Program," we saw how to call a system API with the sending of error messages disabled. The scenario used was determining if an object existed by calling the Retrieve Object Description (QUSROBJD) API  and, if an error was returned in the API error code data structure, handling the error in an appropriate way. The code shown at that time was this:

Learn how to take advantage of the Send Program Message (QMHSNDPM) API to alert users to problems.

Written by Bruce Vining

In a previous article, "What to Do with Messages in the Application Program," we looked at how to detect error conditions in a program. These conditions might be the result of an API call or an error in the application program itself. Today, we will look at one approach to informing the user that a problem has been encountered.

Let's explore detecting and handling API application-related error messages.

Written by Bruce Vining

The past several articles in this column have been related to detecting and managing messages that have been sent to other jobs on the system. We looked at handling message watches, validating inquiry message responses, and providing responses to inquiry messages. Today, we will continue looking at messages but turn inward. This article will review some of the approaches available to handle message conditions that exist within the current application program.

Learn how to write an inquiry-handling exit program.

Written by Bruce Vining

This is the third in a series of articles related to inquiry messages. The first two articles, "Beyond Watches" and "Validating Inquiry Message Responses," introduced the use of the reply-handling exit point QIBM_QMH_REPLY_INQ. With this exit point, you are able to validate the reply and, if you want, change the reply after the end user responds to an inquiry message. The current article introduces another exit point in the system. This exit point, QIBM_QMH_HDL_INQEXT, allows you to intercept an inquiry message before the end user is involved. That is, your exit program can directly provide the appropriate response without any operator involvement.

Learn how to write a reply-handling exit program.

Written by Bruce Vining

This is the second in a series of articles related to detecting when an inquiry message has been sent on your system and then making processing decisions based on the inquiry message. The underlying technology being used is known as the reply-handling exit program and has been available since V5R2.

Learn how to handle specific inquiry messages.

Written by Bruce Vining

The recent series of articles on watches prompted quite a bit more email than I have received on any previous topic. Several of these notes were related to watching for a specific set of messages and have prompted this column.

While the earlier articles gave examples of automating certain application processing--managing daylight saving time transitions, re-enabling disabled user profiles, purging deleted records--several of you have implemented watches in order to determine when program failures occur. That is, you are watching for messages such as these:

Find out the rest of the story about PRGDLTRCDS and Watch considerations.

By Bruce Vining

This is the sixth in a series of articles on detecting that certain messages have been sent on your system and then making processing decisions based on those messages. The underlying technology, known as Watch support, became available with V5R4.