Home > AS/400 Tips > iSeries administrator tips > Advanced trigger applications -- part 3

	iSeries 400 Tips:	EMAIL THIS

	TIPS & NEWSLETTERS TOPICS

	ISERIES ADMINISTRATOR TIPS Advanced trigger applications -- part 3 Ron Turull 04.25.2006 Rating: -4.00- (out of 5) Digg This!     StumbleUpon     Del.icio.us    [TABLE] 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. [TABLE]			[IMAGE]

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 inven

Digg This!     StumbleUpon     Del.icio.us

RELATED CONTENT iSeries administrator tips Translating Linux for IBM i admins: Using GUI to make it easy Translating Linux for IBM i admins: Working with jobs and networking OpenOffice: What to know before making the transition from Microsoft Office OpenOffice: An enterprise open source solution Database performance comparisons on IBM i Translating Linux for IBM i admins: User profile commands Modern System i reports using Client Access Tips for installing Lotus Domino server on a System i partition The iSeries Blog has a new home on IT Knowledge Exchange Virtualization for IBM i: Backups

RELATED RESOURCES 2020software.com, trial software downloads for accounting software, ERP software, CRM software and business software systems Search Bitpipe.com for the latest white papers and business webcasts Whatis.com, the online computer dictionary

tory 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.

Rate this Tip To rate tips, you must be a member of Search400.com. Register now to start rating these tips. Log in if you are already a member. Submit a Tip DISCLAIMER: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.