RE: System slow-down - disk usage?

Roger: It's not multi-format.

Both the input file and the previous file have no logicals.

"as the file seems to grow and then get smaller."
I think there's a misunderstanding there. The Previous file always gets bigger. We do purge data from that file, but as far as the job is concerned, the Previous file will grow (unless every record being processed was previously processed, which isn't likely). For my testing, I clear the previous file. And to compare, I copied in 17 million records and ran the same test. Huge difference in time.

Thanks for the link. Now I'm left wanting an opcode that acts like chain "not %found" and like setll %equal.

I'll do some testing with this information.

Thanks,
Kurt

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Crispin Bates
Sent: Tuesday, June 15, 2010 1:04 PM
To: Midrange Systems Technical Discussion
Subject: Re: System slow-down - disk usage?

Is CHAIN always faster? If the large majority of the data access is failing
(the records are not found), then CHAIN is going to be quicker, because
SETLL has to position the file pointer to EOF, and with 20 Million Records,
that might slow things down slightly.

At least that's what Barbara Morris seemed to think here -
http://forums.systeminetwork.com/isnetforums/showthread.php?t=49800

Not sure if that's what is happening in this case, or if there is anything
OP can do, as the file seems to grow and then get smaller, based on the
description...

----- Original Message -----
From: "Charles Wilt" <charles.wilt@xxxxxxxxx>
To: "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
Sent: Tuesday, June 15, 2010 1:42 PM
Subject: Re: System slow-down - disk usage?


SETLL does keyed access, and is faster than a chain if all you want to
know is does the record exist.

Charles