> 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 thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.