Here's the situation. We noticed this first with a subroutine intended to be used as part of an I-descriptor in Universe. It's a program that we use all over the place because it looks into a number of places and comes up with the status of a policyholder on a particular date. It needs to open a number of files to do this.
We did a SELECT using a dictionary item calling this routine, and noticed that it was taking forever. This was unusual. We killed it and started it again, and when it didn't improve we did some more investigation. What we found was that the LIST or SELECT started off very fast, but then got slower and slower over time. If we stopped the LIST/SELECT and restarted it right away it would start off very slow. If we stopped the LIST/SELECT, then QUITted out of UV, and then went back in and restarted it, it would start up fast but then eventually slow down. We scratched our heads over this for quite a while. Eventually, we put a named COMMON statement in the program and listed all of the file variables as part of it. Then we put some code to check if the files were already open in front of the OPEN statements, to avoid re-opening. I'm not sure if this second step was really necessary. When we restested, we found that the LIST/SELECTs really flew, and set new speed records for completing. Something about file handling was the issue. This system has been in place for 10 years. We haven't upgraded Universe for several years (we're on version 10). 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. I consider the named common trick to be a work-around. Has anyone else noticed the same thing? If so, does anyone know any other way to stop this from happening? thanks, Dave Barrett, Lawyers' Professional Indemnity Company ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
