RE: CRTDUPOBJ of file with trigger renders trigger inoperative

Charles, 

I would press IBM on the case where all referenced files are already in the
target library as documentation suggests that case is supported by
CRTDUPOBJ.  

IBM makes a valid point on not knowing if referenced files are valid for
trigger action, but perhaps they can address that with a prompt of some sort
(i.e. Are you sure you want to do that?) or another parm on the CRTDUPOBJ
that says "Assume referenced files are valid" with default of *NO.  
Another method could be to mandate user to DUP all referenced files at the
same time, thus ensuring referenced files are valid. But then you run into
other issues.
Not sure, it's ugly anyway you look at it.  I'm sure IBM development team
has discussed these pros and cons in great length.  It would be interesting
to see something like RFCs for this kind of decision :)

On a separate matter, I have used QDBRTVFD and fully agree with you on its
user (un)friendliness.  If you're going to roll your own CRTDUPOBJ, you
might find querying system catalogues or underlying system cross-reference
files friendlier for this purpose.

Elvis


-----Original Message-----
Subject: RE: CRTDUPOBJ of file with trigger renders trigger inoperative

Well the only appropriate action is to drop and recreate the trigger.

But at the very least you could use the Retrieve Database File
Description (QDBRTVFD) API to get all the information needed to recreate
the trigger.  But holy crap, have you looked at that sucker?  I'm not
sure I'm paid enough to tackle that puppy. <grin>

I got a new reply from IBM:
I discuessed this more with the developer.  The short of it is, it will 
always be inoperative.  This is for your protection.  There is no way of
knowing if the files referenced in the trigger program are still        
accurate or not.  Therefore, to prevent possible unwanted actions (i.e. 
test file trigging a program that updates production files), they set it
to inoperative.                                                         
                                                                        
If you do an OPNDBF *ALL for the file, you will see message CPD502B that
lists the trigger as inoperative nd show the cause as:                  
                                                                        
A trigger can be inoperative when a create duplicate object of a file   
with any triggers or restore object of a file with any triggers is to a 
library other than the original library.                                
                                                                        
Thanks for using the IBM Rochester Support Center!!                     


Ok that's fine mom, but how about an easy way to turn the trigger back
on rather than dropping and recreating it?  Not to mention that
according to the docs, if every referenced object is in the new library
the trigger is supposed to use those instead of the originals..but that
didn't happen.

Part of my problem is that I don't have the source on the same system
where I'm running the CRTDUPOBJ.  Even if I did, the source I have is
written to work with our CMS and includes a replacement variable for the
library where the object is to be created.  I really don't want to have
to try an maintain two separate copies of the source for any triggers
whose files I may want to run a CRTDUPOBJ on.

Looking at IBM's reply and the QDBRTVFD API, it would probably be easier
to write an MI program that flips the *OPERATIVE/*INOPERATIVE bit on the
stupid trigger(file?). 



Charles Wilt