×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
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
This mailing list archive is Copyright 1997-2025 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact
[javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
