On 19-Jul-2016 13:53 -0500, CRPence wrote:
<<SNIP>>
The Trigger Library (TRGLIB) parameter enables specification of the
qualifying identifier for the TRIGGER name; i.e. the SCHEMA for the
TRIGGER. Because the Trigger (TRG) parameter keyword for the
ADDPFTRG command was *not* defined as a Qualifier Definition (QUAL)
in the Command (CMD) source, the ability to specify the Library name
is offered separately\instead, via the _additional parameter_ keyword
TRGLIB.
The TRIGGER, and the Program (PGM) that implements that TRIGGER, are
separately named entities; albeit, only the specified PGM
is\refers-to an _object_ on the system. The TRIGGER, instead of being
an _object_ in a library, is maintained in the row-data a Database
Cross-Reference (DBXREF) physical files with naming QADBXTRIG*; IIRC,
in the file QADBXTRIGB in QSYS tracks the TRIGGER_SCHEMA [from column
DBXTBDLIB2 or DBXTBDLIB] and TRIGGER_NAME [from column DBXTBDNAME],
which together comprise the qualified identifier that would be used
to locate the trigger for SQL requests such as DROP TRIGGER.
Thus when performing Add Physical File Trigger (ADDPFTRG), the file
is being /decorated/ with two separate attributes;
• the first is a qualified name for the TRIGGER
• the second is <ed\addendum: a qualified name for> the Program
[object type *PGM] that is the run-time\executable that will
implement the actions for the specified triggered time+event,
Lacking an _object_ to which the named trigger corresponds, is likely
the basis for confusion about the TRGLIB. While there is a *PGM object
to correspond to the PGM() specification, there is no object for the
TRG(). If by implementation, there had been an external object-type of
*TRG that was created by ADDPFTRG, then likely, few would be confused by
the effect; even if they might remain confused, for why there were both
the TRG() and TRGLIB() parameters on the command vs just one TRG()
parameter for which the latter would accept a qualified name. And
following that same idea, surely even less confusion, if the command had
been Create PF Trigger (CRTPFTRG) instead of ADDPFTRG; i.e. the
implication then, being that an _object_ would be created. Anyhow...
I have thought of another way to try to elucidate [or further
muddle], for those who are familiar with SQL routines:
Imagine if the CREATE TRIGGER had a CREATE TRIGGER (EXTERNAL) that
could be used to associate a non-SQL program with a TABLE while at the
same time registering that TRIGGER in the catalog. This would be
somewhat analogous to the existing features of CREATE PROCEDURE
(EXTERNAL) and CREATE FUNCTION (EXTERNAL SCALAR or EXTERNAL TABLE).
These existing functions basically create whatever is necessary for the
SQL to invoke the ROUTINE by association of the external-object with
that catalog entry.
So we already have the following ability to register the interface to
a native object with the Object-Type *PGM [e.g. program-name MY_PGM in
the MY_LIBR library], within the SQL ecosystem, identifying the SQL
ROUTINE with a qualified name comprised of the two SQL identifiers for
Schema_Name and Procedure_Name [e.g. PROCEDURE-name MY_PROC in the
MY_SCHEMA SCHEMA]:
CREATE PROCEDURE MY_SCHEMA.MY_PROC ... EXTERNAL NAME MY_LIB/MY_PGM
Consider the following faux statement as having a similar effect:
CREATE TRIGGER MY_SCHEMA.MY_TRIG ... EXTERNAL NAME MY_LIB/MY_PGM
With this imagined capability, we would have registered the SQL
interface to a native object with the Object-Type *PGM [e.g.
program-name MY_PGM in the MY_LIBR library], within the SQL ecosystem,
identifying the effective SQL ROUTINE with a qualified name comprised of
the two SQL identifiers for Schema_Name and Trigger_Name [e.g.
TRIGGER-name MY_TRIG in the MY_SCHEMA SCHEMA].
In this fantasy scenario, the native equivalent is ADDPFTRG ...
PGM(MY_LIB/MY_PGM) TRG(MY_TRIG) TRGLIB(MY_SCHEMA)
Or, FWiW, if the ADDPFTRG command had defined the TRG() parameter
with a QUAL statement [thus eliminating the distinct TRGLIB()
parameter], then we would have specified TRG(MY_SCHEMA/MY_TRIG).
So irrespective of PROCEDURE or TRIGGER, we have a library-name that
is dedicated to the purpose of name qualification within SQL. And that
is entirely separate from the library-name that is used as qualifier for
the [external to the SQL] /native/ Program object.
midrange.com
