Runaway QTP process

[Dave Knispel]

To all,

This same thing happened to me again on Friday.  Here's the story...

I had a job running in the EQ (lowest priority) and it began taking over the
system.  Soon no one was able to get past the logon password prompts (our
own security system).  All FTP, Telnet and ODBC connections were failing.  I
logged on as MANAGER.SYS with a PARM=-1 (I know I should close that hole,
but it's saved me re-booting several times).  I did a break job on the QTP
job and everything went back to normal.  I resumed the job, and all shut
down again.  I called HP, here's what they said...

The job we had running was missing the SET LOCK UPDATE so it was locking our
SHARED database.  Soon many of the on-line users were waiting (impeded) on
that lock.  What the OS does is this; it sees that process holding up many
other processes so it starts throwing more and more resources at it in order
to speed up that process and free the lock.  Soon that process has taken
over the system, even though it is running in the EQ.

Our solution here was simple.  Add a SET LOCK FILE UPDATE to the code.  That
way it will only lock the dataSET and not the dataBASE and it only locks it
at update time.

David Knispel
dave.knispel@frequencymarketing.com
Phone: 513-248-5029
Fax: 513-248-2672
----- Original Message -----
> From: "Abraham Zwygart" <azcognos@anodizing.com>
> To: "PowerHouse ListServer (E-mail)" <powerh-l@sphere.swau.edu>
> Sent: Wednesday, September 06, 2000 2:12 PM
> Subject: Runaway QTP process
>
>
> > Hi all,
> >
> > I have been off this list for a long time.   It is good to be back.  Im
> > on a:
> > PH3000 os ver. 6.5
> > using Power House     ver 8.19.c1
> >
> > I have the following job
> > !JOB JOBNAME,XXXX.XXX;OUTCLASS=LP14,1
> > !QTP PRI=ES
> > CAN CLE
> > SET DEF
> > ACC ACK-OPERATIONS LINK A-WORK-ORDER  TO &
> >                                 A-WORK-ORDER OF ACK-DIE-ITEM
> >
> > SELECT ACK-DIE-ITEM IF ITEM-NUM OF ACK-OPERATIONS = &
> >                        ITEM-NUM OF ACK-DIE-ITEM AND &
> >                        DELETE-CODE OF ACK-DIE-ITEM <> ' '
> >
> > OUTPUT ACK-OPERATIONS UPDATE
> > ITEM DELETE-CODE OF ACK-OPERATIONS FINAL DELETE-CODE OF ACK-DIE-ITEM
> >
> > SET PROCESS LIMIT 999999
> > GO
> > EXIT
> > !EOJ
> > files:
> > FILENAME  CODE  ------------LOGICAL RECORD-----------  ----SPACE----
> > --DAYS--
> >                   SIZE  TYP        EOF      LIMIT R/B  SECTORS #X MX
> > ACC  MOD
> >
> > ACK-DIE-ITEM
> > BIFM1   * KSAM    256B  FAK     618314     943000  16  1067008 21  *
> >
> > ACK-OPERATIONS
> > ACKOPER * KSAM     64B  FAK     727742    1247117  60   550448 32  *
> >
> > This qtp pass will take all of the cpu (95%+) it can get and do very
> > little disc IO (used sos to monitor).  The cpu usage was so bad that I
> > was not able to abort the job.  After trying for just over a half hour
> > we had to reboot the HP3000 to break it free.  Has anybody else come
> > upon a qtp the seemed to have a runaway process?
> >
> > Abraham Zwygart
> >
> > PS.  I have got the job to work by using quiz to collect the changed
> > records then  using qtp with a unique key.
> >
>
> = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
=
> Subscribe: "subscribe powerh-l" in message body to
majordomo@lists.swau.edu
> Unsubscribe: "unsubscribe powerh-l" in message to majordomo@lists.swau.edu
> This list is closed, thus to post to the list, you must be a subscriber.

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
Subscribe: "subscribe powerh-l" in message body to majordomo@lists.swau.edu
Unsubscribe: "unsubscribe powerh-l" in message to majordomo@lists.swau.edu
This list is closed, thus to post to the list, you must be a subscriber.