In the part 1 and part 2 of this series, we discussed the basics of trigger programs. We also discussed the restrictions the system places on trigger programs, as well as the things trigger programs must not and/or should not do. Now we'll begin a tour of three unique trigger programs that solve real-world problems (not to be confused with "world problems" for which a different type of trigger is often deployed). As we discuss these three trigger programs over the next few weeks, keep in mind the possibilities are virtually unlimited; these examples are just a starting point to give you an idea of just how versatile triggers can be.
Example trigger 1: How to turn an off-line process into a real-time process
Problem:
An inventory system has many applications updating the raw materials inventory file throughout the day. You currently have a program that runs at night that checks the stock levels and transmits an EDI order if necessary. However, because order confirmations cannot be checked until the following day, order lag time can be more than 24 hours. Minimum time to arrival is two days.
Solution:
Make a version of the nightly program that accepts trigger parameters. That will become an after update trigger. Each time an inventory record is updated, the trigger program INVTRIG.RPG is called. It checks if the inventory level has fallen below the reorder point and, if so, calls the program that does the EDI ordering.
Although the code is fairly simple and contains many explanatory comments, let's run through it in detail since it is our first look at a trigger program. The first thing that is done is an externally-defined data structure is declared based on the same inventory file to which the trigger program will be attached (the DDS source code for the INVNTRY file is shown here INVNTRY.DDS). If you are going to be accessing either the before or after record image in the buffer that is passed to your trigger, you will be doing that often.
Since the locations of the before and after images in the buffer are not predetermined, the data structure is based on a pointer (pInvRec). The first thing the program does is set that pointer to the beginning of the after image (i.e., the newly updated record). It does that using the Offset to new record field that is located in bytes 65-68 of the buffer. Once that pointer is set, the subfields in the data structure can be accessed.
The program then checks the new inventory level (InvLvl) in the after image against the reorder point for that inventory item (OrdPnt), which is also in the after image. If the inventory level is at or below the reorder point, the EDI ordering program EDIPGM (not shown) is called to place the order, sending the entire inventory record data structure (i.e., the after image) as a parameter.
When the EDI ordering program returns control to the trigger program, the trigger program returns without setting the LR indicator on so the program stays loaded in memory. If the inventory file is frequently updated (which is the presumption here), leaving the trigger program loaded in memory will increase performance.
Once the program is compiled, it can be added as a trigger using the following command:
ADDPFTRG FILE(UCG/INVNTRY) TRGTIME(*AFTER) TRGEVENT(*UPDATE) PGM(UCG/INVTRIG)
Benefit:
Orders are instantaneous and take place during the day. Order confirmations are usually received back within the hour and any problems can be taken care of the same day. Minimum time to arrival is less than 24 hours.
-----------------------------------
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.
