I'll echo the concept of using named common to cache file handles to avoid re-opening. I use this as a key technique in web applications. Funny enough, right before I got to this thread I wrote a paper to explain to one of my clients how it works.
The key thing is to use Named common, not regular common. I use code like this: COMMON \APP1\ FILE1,FILE2 IF UNASSIGNED(FILE1) THEN * note in D3 and maybe other MV platforms that's * IF ASSIGNED(...) ELSE or IF NOT(ASSIGNED(...)) THEN ... GOSUB OPEN.FILES ; * file1 is assigned there IF ERR THEN RETURN ; * always handle errors from file opening END ... Continue with code here, secure that at some point the files were opened It doesn't sound like this is the case, but might someone have a unique version of the code that bypasses this code? That will provoke re-opening the files. I have my code like this in a standard item that is Included by all code in a given app module. I recently accidentally made a change that didn't set "FirstTime" type flags, and I introduced recursion which had symptoms as you describe. Any similar issues? Is there some file that changed permissions so that it can't be opened, so now your open logic fails and all files are being opened every time you come into the code? David A Barrett wrote: > This just started happening. Furthermore, when we > checked our test system, we found that it also exhibited > exactly the same behaviour. This would seem to rule out > any system or hardware specific event. This is a clue to what happened - you need to find something that happened in common to these systems, some new test code that just went production, some change to flags in a control file, maybe new I-descriptors that call somewhere to reset the FilesAreOpened flag... Good luck. Tony ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
