Do I need to disconnect all users/processes before running libadd? We are running Character-based Version 9.1D07. It appears that some strange behavior is happening when we don't disconnect batch processes when running libadd.
Our human users log out every night and back in every morning. However, we keep some batch processes running sometimes for weeks at a time. These batch processes run different programs based on a database-driven schedule.
We move code live by running the libadd after-hours when all of the (human) users are logged off. However, we sometimes see strange behavior when we run the libadd without resetting(disconnecting/reconnecting to the database) the batch processes. Note that the new code going live doesn't even run on the batch processes.
Some examples of the strange behavior:
1) Mismatch parameter error. We have gotten this error message on the batch process when inspection of the code makes is clear the parameters are not mismatched. Also, neither the calling program or the called program have changed. They worked before the libadd, failed immediately after the libadd, but worked again after the batch process was reset.
2) File input too long: Again this error message occurred after libadd was run without resetting the batch processes. The programs that got moved live were NOT being run on the batch process. The input file that generated the error hasn't changed and the ABL code that is reading in the file hasn't changed. This problem was fixed just by rescheduling the code again (without resetting the batch processes) -- however it may have run on a different batch thread (we have several running).
We have two schools of thought internally:
A) There's no way that adding this new program to the library could possibly affect the batch processes since the batch processes don't even use this program -- and even if they did use this program, they would just use the previous version that was in the library when those processes started. After they were reset, they would use the new version -- no strange behavior should occur. The error are a result of something in the code that we're not seeing.
AND the other school of thought:
B) Agreed that the strange behavior shouldn't occur. But, it the empirical evidence is enough to always reset all processes when running libadd. That eliminates one variable in the equation. If we reset all processes during libadd and the error still occurs, that makes it easier to find the error.
Could anyone provide how they handle this type of situation internally and what experience you've had with running libadd without resetting all processes?
Thanks!
Is "libadd" a homegrown (or AP supplied) script surrounding prolib that adds a module to a procedure library? Or is it something else?
If you are talking about updating procedure libraries on a running system then the answer is "don't do that". It does cause problems. Whether it /should/ or not is another matter but if you are doing that then you can expect to have problems.
You might also want to consider whether or not you are running with -q (which goes to the "it's already in memory" argument) and whether or not these are memory mapped procedure libraries. Both considerations could impact how many problems you might have and what sorts.
If it were me I would look for a way to manage the batch procedures to better accommodate the situation.
BTW -- 9.1d07 is pretty old. You ought to strongly consider upgrading.
Hi Tom. Thanks for the response. Yes you are correct - I was referring to prolib when I said "libadd". This information is what I was looking for.