Runaway QTP process

[Pickering, John (NORBORD)]

A couple of things ...

- if nothing else is running then, sure, Qtp will consume as much of the
machine as possible [and what's wrong with this?]
- has your ES queue been fiddled to give it a higher than default priority?
- on a 3k with only one process using most of the machine, I have found it
much harder to get the machine's attention
- those look like CM ksam files and you're using an NM Qtp -- lots of
switching going on
- how random is the ack-die-item ksam? i.e. if records for the same work
order are all over the file then you'll force a lot of disc head movement
- you don't say what model of 3k you have but half an hour to read 600k
records and link to who knows how many other records doesn't seem over the
top to me
- is it possible that something else had one of the files locked? Qtp would
just sit there trying to lock both files

And how long did it take Quiz to find the records?

Regards,
JWP


> -----Original Message-----
> From:	Abraham Zwygart [SMTP:azcognos@anodizing.com]
> Sent:	Wednesday, September 06, 2000 2:12 PM
> To:	PowerHouse ListServer (E-mail)
> 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. << File: Card for Abraham
> Zwygart >> 
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
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.