Adding or updating records in a memory file could potentially fail with error 42 when other connections were reading and deleting records from the same shared memory file. Error 123 could also be seen under similar circumstances when reading memory records from variable-length data files. These errors were only seen in circumstances where a sufficient volume of data and users generated the specific timing necessary for these errors to occur. To resolve this issue, a more stringent internal tracking mechanism is now used to ensure this timing hole cannot occur.
FairCom has fully exercised this new code in our lab and it has passed all of our quality assurance tests. We recommend thorough application testing with this new code line to ensure proper application execution, in addition to watching for any memory growth over time (which could indicate a memory leak).
While addressing errors 42 and 123, error 160 was occasionally seen due to multi-user interference if ITIM_RETRY_LIMIT was too low. To avoid error 160, the choice of value to use for the ITIM_RETRY_LIMIT keyword should be on the order of the number of concurrent connections that are reading and updating the memory file.