This also creates the "gotcha" that when you duplicate a file into a test library, for example, it also duplicates the hard-coded qualified trigger call. Then running test data through it in your test library fires your production trigger. Be careful out there. -----Original Message----- From: Douglas Handy <firstname.lastname@example.org> To: MIDRANGE-L@midrange.com <MIDRANGE-L@midrange.com> Date: Thursday, October 28, 1999 2:24 PM Subject: Re: triggered file list problem >John/Booth, > >>You can qualify the trigger program to a particular library. However this >>is not your problem, > >Trigger programs never use the library list except during the actual >ADDPFTRG command. When you add a trigger and specify *LIBL for the >program library, it gets resolved based on the then current library >list and the resolved library name is stored with the file >description. In effect, triggers always get called as a qualified >name. > >You can verify this by using ADDPFTRG with *LIBL, then using DSPFD to >look at the trigger information. The library name will be a specific >library, not *LIBL. > >According to IBM, this is by design and won't be changed. They did it >this way to avoid security exposures by people inserting their own >trigger programs higher in the library list. +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to MIDRANGE-L@midrange.com. | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: email@example.com +---
As an Amazon Associate we earn from qualifying purchases.
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.