I work at a medium sized manufacturing company that has been using Growthpower
since 1985.  We upgraded from Growthpower 11.0 to Growthpower 2000 last October
and have been experiencing significant performance problems ever since.  I've
seen some other Growthpower users on this list and wonder if anyone else has
experienced these problems.

The symptom is that each interactive user running Growthpower is running at
3-5% CPU utilization.  Previously, no session required more than 1%, unless it
was an historical inquiry, voiding checks, or something like that.  The machine
is a 957SX, MPE/iX 6.0 PP1, 192MB Ram, 24GB disc (20-25% free), 80-100 sessions,
99% using NS/VT.  Growthpower runs in CM, and none of the programs are
OCTCOMP'd.  We're using SOS to monitor system utilization.  Prior to this
upgrade, we would see the system running at around 70%.  Now, it's usually in
excess of 95%.

We've seen this problem before, when we upgraded from 9.0 to 11.0.  After some
brainstorming, we came to suspect a new feature in that release, a configurable
terminal time out.  In Growthpower 11.0 (and perhaps 10.0), you gained the
ability to set a timeout value for terminal reads by creating a file (default
name TIMEOUT.PROG.FM) and entering the timeout interval in seconds in the file,
in plain ASCII.  At each terminal read, the timer is started, and if there is no
response from the user in the specified time, the terminal read proceeds as if
the user had just pressed the return key.  Eventually, you would back all the
way out of Growthpower.  On our system, the logon UDC will then log you off the
HP.

We placed a call to Pivotpoint support to discuss the problem, and managed to
get someone to read us the SPL code for the terminal read routine, which is in
their SL.  This routine needs to know the timeout interval you've set, and to
get it, does an FOPEN and FREAD of the disc file before every read of the
terminal, which I assume uses a call to READX.  If a timeout value has been set,
it calls FCONTROL to set the timer.

I complained about the implementation of this feature, and was told that I was
the only one having any problems with it.  Eventually, my complaints yielded me
a new SL which had the timeout code stripped out of it.  Upon installation of
the patched SL, CPU utilization immediately returned to the previous level.

Well, we upgraded to GP 2000, and the same thing occurred.  I did further
investigation and discovered that this SL routine consumes 24% more CPU time
than the previous one (I found this by running a batch job that exercised the
routine 2000 times and compared the number of CPU seconds used).  I complained
again to Pivotpoint, and provided the documentation, and was told that I can get
a new SL with the code removed for $1200, I can foot the bill for the
enhancement of the routine for $6000, or I can submit an enhancement request for
the next release.  Since my company is the only one experiencing a problem, it
would probably not be voted in.

One of the frustrating things about this problem is that the timeout value is
being captured in an extra data segment when you enter Growthpower, and is
available to the terminal read routine through an intrinsic call (DMOVIN) that
is far less expensive that a disc read.  Also, the timeout file is never closed
when it's read at startup.  I've not been able to convince Pivotpoint that this
is a fix that would be of benefit to all users, and one they should make
immediately.  Since this situation is causing us so much lost time, I have
approval from my management to spend the money to get this enhancement done and
am moving forward on it.

Are there any other Growthpower users on this list that can check their
systems for this problem.  I'm sure I'm not imagining this, but some
corroboration would help.  I suspect a lot of Growthpower sites are small shops,
and perhaps don't run performance monitoring software, and that's why there
haven't been any other complaints.  Perhaps others have just upgraded their
boxes to make up for it.  If you're interested in this problem, please feel free
to contact me for more details.

Bob Rose