Runaway QTP process

Mike Godsey mgo@columbus.rr.com
Tue, 12 Sep 2000 21:08:24 -0400


I  have seen this happen when I link two datasets that have a many to many
relationship ( planned or accidental). The best work around is to access
only the first dataset, select the records necessary, and build a temporary
subfile that has a unique key. Then, use the subfile to link to the second
dataset. This eliminates the unnecessary many to many record clusters that
are then discarded with a choose or select and performance is greatly
enhanced. I took a 26 hour job to 17 minutes this way.
Mike Godsey
Applied Performance Technologies
Columbus, Ohio

----- 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.