Are You Trigger Happy?

Because of changes with OS/400 V5R1, some trigger programs that worked perfectly prior to V5R1 will have problems after the upgrade. So this is a good time to examine your trigger programs to ensure they will still work properly after upgrading to the new release. While you're at it, you may want to update your coding techniques.

One change makes it essential to utilize the offset values passed in the trigger buffer to locate the before and after record images. In past releases, you may have been able to get away with hard-coding the starting position of the before and after images, but changes made in V5R1 to support large object data types make this technique risky. The most important thing to look for in your trigger programs is the technique that you use to locate the record images.

Before we get to the details of the offsets code, let's examine the way we should code the parameters needed for trigger programs. For explanations about the data found in the trigger buffer, refer to the "Triggering Automatic Events in Your Database" section of the Database Programming manual.

    D TrgBuffer         DS
    D  TFileName                      10
    D  TLibraryName                   10
    D  TMemberName                    10
    D  TEvent                          1
    D  TTime                           1
    D  TCommitLock                     1
    D  TFill01                         3
    D  TCCSID                         10I 0
    D  TRRN                           10I 0
    D  TFill02                        10I 0
    D  TOldOffset                     10I 0
    D  TOldLength                     10I 0
    D  TOldNullOff                    10I 0
    D  TOldNullLen                    10I 0
    D  TNewOffset                     10I 0
    D  TNewLength                     10I 0
    D  TNewNullOff                    10I 0
    D  TNewNullLen                    10I 0

    D TrgBufferLen     S              10I 0

Notice the use of the I (integer) data type in place of the older B (binary) data type for many of the trigger buffer values. The integer data type is more efficient and supports the full range of values possible, so it's a good idea to get into the habit of changing your B's to I's in RPG IV programs. You'll also need to change the length of the field-from 9 B to 10 I or 4 B to 5 I, assuming you're using length notation. The reasons are complex, and beyond the scope of this article.

Next, let's examine the old and new record image data structure definitions.

    D OldRecord      E DS        ExtName(MyFile) Prefix(O_)
    D NewRecord      E DS        ExtName(MyFile)

Here we've simplified our coding and made it more change-resilient by using two externally described data structures based on the actual physical file record format and RPG IVs prefix globally renames all of the fields brought in from MyFile by appending the characters "O_" to the beginning of each field name. This allows us to use externally described data structures in both cases while maintaining unique names.


Jon Paris is a technical editor with IBM Systems Magazine and co-owner of Partner400.

Susan Gantner is a technical editor with IBM Systems Magazine and co-owner of Partner400.

comments powered by Disqus



2019 Solutions Edition

A Comprehensive Online Buyer's Guide to Solutions, Services and Education.

New and Improved XML-INTO

Namespace support makes the opcode a viable option

Authenticating on the Web

The finer points of OpenRPGUI, Part 1

The Microphone is Open

Add your voice: Should IBM i include open-source RPG tools?

IBM Systems Magazine Subscribe Box Read Now Link Subscribe Now Link iPad App Google Play Store
IBMi News Sign Up Today! Past News Letters