HP3000-L Archives

May 1996, Week 1

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
"Paul H. Christidis" <[log in to unmask]>
Reply To:
Date:
Wed, 1 May 1996 15:00:02 PST
Content-Type:
text/plain
Parts/Attachments:
text/plain (39 lines)
Bob wrote:
 
>Yesterday we had a batch process that was running Powerhouse QTP
>that took over the system for multiple minutes. QTP was in the DS
>queue but still managed to allow nothing else any CPU time.  It
>was processing one request controlling the queue and completed
>allowing others some CPU time but again took over a couple minutes
>later in the next request statement in the job.
 
>Just curious if anyone has experienced something like this or has
>any ideas on what happened?  We are running SOS in batch and know
>that this process used over 80% of the cpu for the 10 minute
>interval.
 
I've seen a similar situation in our environment and I've
determined that the following was occurring.
 
1. The QTP process, a batch job, had applied a lock on a dataset.
2. A number of on-line user processes were being impeded in
posting their transaction because of the locked 'resource'.
3. The dispatcher detecting that the QTP process was in possession
of a 'resource' that was in 'high' demand kept increasing its
priority in an attempt to 'free' up that resource.
 
The solution was to modify the QTP process to only apply its lock
around the update and not during the execution of the entire
request.
 
>Out of curiosity, does Cognos have a problem with compatibility KSAM
>files?  The first request was writing to a Comp. KSAM file.
 
There is additional overhead due to the constant NM to CM switching
since the CM KSAM code in still in CM
 
 
Regards
 
Paul H. Christidis

ATOM RSS1 RSS2