Problem solve Get help with specific problems with your technologies, process and projects.

Clean up programs and procedures to increase data and application integrity -- part 1

Ron Turull explains how to clean up programs and procedures to increase data and application integrity.

Ron Turull
How many times have you had an application fail and, as a result, been faced with not only trying to figure out what went wrong with the application, but also trying to piece together data that had been left incomplete by the program crash? If your shop is like most, the answer is probably more times than you care to remember.

RPG with Integrated Language Environment (ILE) provides new ways to trap errors and perform program clean-up during unexpected program endings. These new methods are another example of why it is called the Integrated Language Environment -- they are language independent.

What's wrong with the "old" way?

Most Original program model (OPM) languages do have some sort of mechanism for trapping errors and controlling abnormal program ending. And, commitment control, when properly used, does provide a good degree of data integrity. However, both of these approaches have some serious drawbacks.

First, inherent mechanisms for trapping errors are not very robust and are fairly clumsy. Plus, since the mechanisms are language dependent, you must learn and use a different method for each language. Second, using commitment control is complicated at best for most shops. It also slows the system and can eat disk space if not properly managed.

Benefits of the ILE clean-up method

It should be made clear that you can write the code that performs the actual clean-up in any (ILE) language. It is the mechanism you use to connect your clean-up code to a program that involves the use of language-independent ILE features. Once you make the connection between the application program and the "clean-up" procedure, the system will call the "clean-up" procedure any time the associated program ends for any reason other than a normal return to caller. This includes the following events:

  • The program receives an error and the user chooses "cancel."

  • The program does not handle an ILE condition and ends as a result (condition is a generic ILE term for the AS/400-iSeries term exception.

  • The activation group in which the program is running is ended abnormally or manually in a controlled manner.

  • The job in which the program is running is ended by someone using the ENDJOB command.

  • The job in which the program is running is ended by a system or subsystem shutdown.

  • How to set up a clean-up procedure

    In ILE, clean-up procedures are called termination exit procedures. They may be associated with any call stack entry, which means they are associated with a procedure and not an entire program. You use the CEERTX API (Register Call Stack Entry Termination User Exit Procedure ) to associate a clean-up procedure to a particular call stack entry. The clean-up procedure is associated with the call stack entry (i.e., the procedure) that calls the CEERTX API. The API accepts the following three parameters:

  • Exit procedure (procedure pointer). A pointer to the clean-up procedure. The system calls your clean-up procedure via this pointer.

  • Token (data pointer). A pointer to any data item you want passed to your clean-up procedure when it is called. The clean-up procedure receives this pointer so it can then access the data item, which should be part of the associated application procedure. You can use this data item to transmit any information you want to the clean-up procedure. This is an omissible parameter.

  • Feedback code (character). The standard ILE 12-byte feedback code data structure. This is an omissible parameter; if omitted, the CEERTX API will send exceptions to the caller.

  • In the next installment, you'll see this API in action, and we'll discuss a couple of example cleanup procedures that you will be able to use as templates.

    About the author: Ron Turull is editor of Inside Version 5. He has more than 20 years' experience programming for and managing AS/400-iSeries systems.

    Dig Deeper on iSeries system performance and monitoring

    Start the conversation

    Send me notifications when other members comment.

    Please create a username to comment.