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.
