Topic
1 reply Latest Post - ‏2012-04-15T00:29:23Z by CRPence@vnet.ibm.com
SystemAdmin
SystemAdmin
3129 Posts
ACCEPTED ANSWER

Pinned topic ADDPFTRG TRGLIB

‏2005-06-24T15:53:40Z |
What is the trigger library (trglib) parameter of addpftrg command for?
It appears to have no affect. You can even specify the name of a
non-existent library.
Updated on 2012-04-15T00:29:23Z at 2012-04-15T00:29:23Z by CRPence@vnet.ibm.com
  • CRPence@vnet.ibm.com
    25 Posts
    ACCEPTED ANSWER

    Re: ADDPFTRG TRGLIB

    ‏2012-04-15T00:29:23Z  in response to SystemAdmin
    I was looking for a link to some documentation, in an attempt to find some worthwhile description of the TRGLIB parameter beyond the command help text. That help text does not seem to help answer the questions that are raised about the parameter. In that search, I encountered this unanswered question {which the OP posted in other fora also, receiving a reply in c.s.i.a.m from a different Chuck with a copy\paste of the help text, and an acceptable answer on the now defunct NG ibm.software.db2.os400 from Jonathan Ball}. I am not sure how this forum handles responses to such "aged" topics... I will reply regardless.

    Anyhow, in an attempt to clarify, I will just add that the TRGLIB defines the data for the TRIGGER_SCHEMA column in the SQL catalog VIEW named SYSTRIGGER. In other {even DB2} databases, what on IBM i may also be visible as "objects", are merely row data in the catalogs. The TRIGGER is similarly just an entry in the catalog, on the IBM i DB2 SQL. The TRGLIB enables giving a name to the "TRIGGER" separate from the {although possibly matching the} name of the *PGM object that implements the TRIGGER.

    The SQL request to CREATE TRIGGER T_LIB/T_TRG_AU AFTER UPDATE ON MY_LIB/MY_FILE would create a *PGM object named T_TRG_AU in T_LIB as the trigger program for the file MY_FILE in MY_LIB. The SQL request to CREATE TRIGGER T_LIB/T_TRG_BU BEFORE UPDATE ON MY_LIB/MY_FILE would create another *PGM object named T_TRG_BU in T_LIB for the file MY_FILE in MY_LIB. Notice the one-to-one correlation between *PGM object and TRIGGER name.

    The CL request to ADDPFTRG FILE(MY_LIB/MY_FILE) TRGTIME(*AFTER) TRGEVENT(*UPDATE) PGM(THE_LIB/THE_PGM) TRG(T_TRG_AU) TRGLIB(T_LIB) would associate the existing *PGM object named THE_PGM in THE_LIB as the trigger program for the file MY_FILE in MY_LIB, but the TRG() and TRGLIB() parameters in conjunction allow giving the fully qualified "trigger name" T_LIB/T_TRG_AU just as with the first CREATE TRIGGER. The CL request to ADDPFTRG FILE(MY_LIB/MY_FILE) TRGTIME(*BEFORE) TRGEVENT(*UPDATE) PGM(THE_LIB/THE_PGM) TRG(T_TRG_BU) TRGLIB(T_LIB) would associate the existing *PGM object named THE_PGM in THE_LIB as the trigger program for the file MY_FILE in MY_LIB, but the TRG() and TRGLIB() parameters in conjunction allow giving the fully qualified "trigger name" T_LIB/T_TRG_BU just as with the second CREATE TRIGGER. Notice there is no longer a one-to-one correlation between the *PGM object and the TRIGGER name. The non-SQL "native" trigger allows giving the TRIGGER name just like the CREATE TRIGGER, but allows associating that TRIGGER NAME to any existing program object; which of course should be a program coded as a functional trigger program.

    I think some of the questions asking about the intent of the TRGLIB parameter originate from the TRG() and TRGLIB() parameters being separated, instead of being the more typical "qualified name" parameter. For example, the command might have better been coded as TRG(lib-name/trigger-name) where the default for the qualified parameter would have been something like TRG(*FILELIB/*GEN) to limit the confusion; perhaps not.? When all triggers are being defined, changed, and removed using the "native" interfaces instead of via the SQL, I have never found a need to specify anything on the TRGLIB(); letting the default TRGLIB(*FILE) get used.

    Regards, Chuck