Re: Trigger Name and Library missing on DSPFD

On 23 Aug 2013 14:34, Jeff Young wrote:

I have a physical file that has 2 triggers attached.
When I use the DSPFD command with the type *TRG, I see blanks for
the trigger name and library, but see all other information:
<<SNIP>>

Does anyone know what could cause this and are my triggers active or
not?

The TRG() and TRGLIB() are really of little import with regard to the
functionality of the trigger program. The qualified Trigger name [i.e.
Library name and Trigger name combined, although separate parameters in
contrast to the typical /QSYS.LIB object name parameters] is merely
something to place in the catalog. A true lack of those attributes
could however, present potential difficulties for /change/ or /remove/
actions; e.g. RMVPFTRG might be limited to either removing by-type or
removing *ALL, and CHGPFTRG for any but *ALL might prove problematic,
given the qualified name can not be located within the definitional
attributes of the file.

There may be a problem with DSPFD [i.e. merely a presentation issue
with that interface] or a problem with the /trigger/ portion of the
definitional details of the database *FILE object. Less likely, or as a
side effect of the latter of those possible problems, there may be a
problem with the data in the catalog; i.e. the *DBXREF files QADBXTRIGB
[and friends]. Both querying the trigger-related data in the System
Database Cross Reference [possibly via the SYSTRIGGER and perhaps any
related SQL catalog VIEW] may be informative [intuitively, the selection
must be on the /file name/ vs either the trigger_schema or
trigger_name], as well the results of RCLDBXREF *CHECK [perhaps again
limited to the specific library name that was originally specified or
resolved for the TRGLIB parameter on the original ADDPFTRG request].

A DMPOBJ or using the QDBRTVFD API to get the trigger details of the
database *FILE could reveal if the problem is most likely or even surely
is with the DSPFD or with the database *FILE object. The output from
the Dump Object would be most clear in comparison to /the same/ file and
trigger definitions established in another library is of great help to
locate and contrast available [trigger] definitional details in the
*FILE space object. Such a file could be created from source, or a
restored copy; restored from a save presumed prior to the issue or even
also the current file saved\restored just to see if the effect is
identical or if the restored copy gets /cured/ of the problem.

--
Regards, Chuck
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.