Re: Trigger techniques

[Vern Hamberg <vhamberg@xxxxxxxxxxx>]

Hi Mark

This is what Alan Campin has written and has offered freely - I've not 
looked at it yet, but he does have some driver program, I think, that is 
the trigger program, which then calls the program that does the real 
work for a given file.

Vern

Mark S. Waterbury wrote:
> Hi, Jon:
>
> "Any problem in computer science can be solved by adding one more level 
> of indirection."
>
> This seems a natural fit for a small CL "wrapper" program that accepts 
> the trigger parameters, and the CL *PGM is "attached" to the *FILE (with 
> ADDPFTRG), and then it CALLs the "actual" trigger program for that file, 
> passing those same parameters.  You might even be able to get away with 
> issuing a TFRCTL to the trigger program, so long as the wrapper CL 
> program is an OPM CL *PGM. 
>
> The "big idea" is that this CL program, once written, will never change, 
> so who cares if OS/400 data management places a *SHRRD lock on it? It is 
> the program that it calls that we care about.
>
> All the best,
>
> Mark S. Waterbury
>
>  > Jon Paris wrote:
>   
> > Anyone care to share what they do to facilitate being able to bring a  
> > new version of a trigger program into use.
> >
> > For performance reasons we don't want to set on LR on each call - but  
> > how do you make sure that it gets refreshed when a new version is  
> > available? I can think of a number of options but each one I come up  
> > seems to have its own issues.
> >
> >
> > Jon Paris
> >
> > www.Partner400.com
> > www.SystemiDeveloper.com
> >
> >
> >
> >   
> >