×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
On 19-Jul-2016 12:59 -0500, James H. H. Lampert wrote:
First, I could have sworn that doing a CHGPFTRG STATE(*DISABLE) had
less extreme file locking requirements than a RMVPFTRG, and yet I'm
getting a "File FOO in library BAR in use" message. Was I mistaken?
An exclusive lock for Change Physical File Trigger (CHGPFTRG) had
always been the requirement; though I do recall both some requests made
for, and talk of, a reduction in the locking requirement, I can not
recall any specific actions ever taken to effect any change.
[
http://archive.midrange.com/rpg400-l/201208/msg00220.html] "Trigger
blocking"
[
http://archive.midrange.com/midrange-l/201210/msg00693.html] "Triggers
- enabling and disabling"
Second, can somebody explain TRGLIB? So far, all I have been able to
find is something from 2012, in an IBM DeveloperWorks forum, that
sheds some light on this, but not a whole lot.
Forum Directory -> Information Management -> Forum: DB2 for i
-> Topic: ADDPFTRG TRGLIB
[
https://www.ibm.com/developerworks/community/forums/html/topic?id=77777777-0000-0000-0000-000013727020]
I am unsure how much better the following will be than my reply in
the above forum, as an attempt to explain, but offered here nonetheless:
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 the Program [object type *PGM] that is the
run-time\executable that will implement the actions for the specified
triggered time+event,
midrange.com
