|
> From: rob@xxxxxxxxx > > The problem with a trigger from an odbc job is it might be any one of the > various server jobs associated with serving odbc and probably not even > staying with the same odbc server job even though it is serving the same > odbc client. Anyone who has had to debug an exit point knows what I am > talking about. :-). So you probably do have to open the file > every time. > But maybe odbc and exit points work differently. An interesting consideration, but even if your theory is correct, here's the rub: adding a change library list to every I/O is a lot of overhead. If nothing else, the API has to check the existence of and authority to every library in the list. I would think you'd want to minimize that. Perhaps something as simple as a "last library list" used in the trigger program might allow you to do a quick compare to see if the change is needed. Second, I think the connection to an ODBC server job is fairly persistent. Obviously this needs to be tested in a real environment, but if a JDBC connection can be made to hit the right library list persistently, and JDBC is simply a wrapper over ODBC, then it stands to reason that ODBC jobs have some level of persistence. Being certain of this would require probably a combination of testing and more in-depth queries to some IBM folks, but analysis seems to indicate it's at least worth some more research. Joe
This mailing list archive is Copyright 1997-2026 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.