Re: Triggers 101

Midrange-l perhaps?

SOP's are great.  However hard and fast rules are often inhibitors, not 
productivity enhancements.  What may work for one is terribly complex for 
another.

IBM has published papers, redbooks, etc on handling record locks since the 
first ISAM file was created.  Yet there are still developers that refuse 
to follow any guidelines in coding applications. Most people choke on
Read header file record with lock
  Update a myriad of line files, etc.
  Finally update header file releasing lock.
Instead of 
Read header file without lock
  Update a myriad of line files, etc.
  Update the header file
So my suggestion is to fix the first application.  However most won't 
because the pig came from a vendor and touching a pig is unholy and 
therefore they'll use bolt ons.

Let me understand.  You are using a trigger on a file.  This file could, 
theoretically, be updated from any number of different applications, like 
UPDDTA or this new batch interface you are trying.  If they use something 
else than the vendor supplied program then you want to fire off the 
trigger and perform the appropriate updates.  If this is a close 
approximation then search the archives for evaluating your call stack. 
Have your trigger program check the call stack.  If the vendor supplied 
program is ruling the roost, ignore the update.

Rob Berendt