Your named COMMON "trick", especially with the "second step" of
avoiding the file reopen is not a work-around. It is considered by
most to be the "correct" way to code one of these subroutines.
Avoiding reopening files on every call to a subroutine, whether
called from an I-descriptor or from another program, is a very
important performance issue.
--
Regards,
Clif
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
W. Clifton Oliver, CCP
CLIFTON OLIVER & ASSOCIATES
Tel: +1 619 460 5678 Web: www.oliver.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
On Sep 1, 2005, at 6:52 AM, David A Barrett wrote:
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
[email protected]
To unsubscribe please visit http://listserver.u2ug.org/
-------
u2-users mailing list
[email protected]
To unsubscribe please visit http://listserver.u2ug.org/
