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.