|
> 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
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 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.