Re: System slow-down - disk usage? -- MIDRANGE-L

Ay Ay Ay!! The whole key is available from just the index portion, too, it seems. Oh well, what do I know?

Of course, we are discouraged from ever using read triggers, right?

Thanks for the heads up!

Vern

On 6/17/2010 6:31 PM, Kevin Wright wrote:

Vern et al,

FYI SETLL (SETGT, _Rlocate, etc) will cause the physical data of the
physical file to be touched under one condition - if the file has an after
read trigger. In this situation the after read trigger will be executed,
with the physical data passed to it. Yes, I had robust discussions with IBM
about it when I found this to be the case. I maintained that an actual read
had not taken place. They justified it by saying that the whole key to the
file *could* become available to the program issuing the SETLL in the file
I/O feedback area if used.

Regards,

Kevin Wright

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx]On Behalf Of Vern Hamberg
Sent: Friday, 18 June 2010 8:06 AM
To: Midrange Systems Technical Discussion
Subject: Re: System slow-down - disk usage?

Kurt

I don't believe that SETLL ever touches the physical data of the
physical file - it only works on the index - that index might be another
MI object within the compound object that is a physical file. Or it
could be an LF over the PF. Seems to me that CHAIN - not found will be
very much the same as SETLL - except for positioning EOF, which'd be an
extra instruction.

SETLL is not moving data from the physical data part to main storage -
it IS moving data from the index - actually pages for the binary tree
that comprises an index, whether self-contained in the PF or elsewhere.

Years ago, in Bob Cozzi's RPG reference - he's had that around over 20
years now, BTW! In there he spoke of setting the file pointer - that
that is what SETLL did. As far as I can see, that means it found the RRN
to use for the key values specified. He says clearly that the physical
data has not yet been touched, IIRC.

I'm inclined to always use SETLL with the %equal test - but I rarely
have a mass write operation going on, just onesies for the most part.

Vern

On 6/17/2010 2:05 PM, Kurt Anderson wrote:

I also have an interest in understanding SETLL under the covers.

I decided to go with Write vs SetLL/Write and catch the duplicate key

error. However, I'm still trying to wrap my head around what the system is
doing when I SETLL on such a big file (even though I'm no longer doing it).
It's not actually moving data to main storage, right? And if it is, how is
it different than a READ? So, if it's not moving data into main storage, is
the bottleneck simply the system attempting to position the file cursor?

In our current situation, our file is 40 million records. File input&

previous file (for duplicate checking) are keyed the same. So on the 40
millionth record being processed, when the program issues a SETLL, it will
move to the beginning of the file and go through the whole file, not find a
match, and position to EOF?

Also: Crispin, your test seems to match what Barbara Morris had said in

another forum (link provided earlier in thread).

Thanks,
Kurt

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx

[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Luis Rodriguez

Sent: Thursday, June 17, 2010 1:05 PM
To: Midrange Systems Technical Discussion
Subject: Re: System slow-down - disk usage?

Crispin,

Check this, I think it could be of help.

http://www-03.ibm.com/systems/resources/systems_i_software_db2_pdf_Performan
ce_DDS_SQL.pdf

<http://www-03.ibm.com/systems/resources/systems_i_software_db2_pdf_Performa
nce_DDS_SQL.pdf>

Regards,

Luis Rodriguez
IBM Certified Systems Expert - eServer i5 iSeries

On Thu, Jun 17, 2010 at 12:50 PM, Crispin Bates<cbates@xxxxxxxxxxx>

wrote:

----- Original Message ----->

----- Original Message -----
From: "Charles Wilt"<charles.wilt@xxxxxxxxx>

Crispin,

Slight correction, chain is faster only if the key being searched for
doesn't exist AND the key is greater than anything else in the file.

Otherwise SETLL is faster.

Charles

Charles,

Forgive me for being dumb. Isn't what you said more likely to result in
SETLL being faster?

"If the key being searched for doesn't exist AND the key is greater than
anything else in the file"

Surely that would mean that SETLL would not have to reposition because it
was already at end of file? Or am I completely missing what you are

saying

(quite likely)?

But that is just anecdotal, as I don't know if SETLL still has to

position

to end of file even if there is no key higher.

FWIW, I took a file with 15 Million records, and ran a test of CHAIN vs.
SETLL to determine if the record existed in the target file. I read the
input file in Primary Key sequence, and effectively wrote every record
found. The target file started off with 0 records, and had the same

Primary

Key.

For CHAIN, it took 10:33
For SETLL it took 11:31

This system is our QA system, nothing else was running. It's a partition

on

a 570 with 6GB of ram and 1.5 TB of DASD (44% utilization), running i
6.1.1.

Based on that, using a CHAIN produced almost 1000 more writes/sec. But,

it

matches your statement of there being no record with a greater key. I'm
just
not sure I understand why...

Of course, it could be completely different on another system.

I decided to take the WRITE out, and do the same READ/CHAIN vs.

READ/SETLL

when the data existed in the to file for every record. I wanted to see

the

impact of the CHAIN reading in the data.

I don't think anyone will be surprised at...

CHAIN 8:45
SETLL 7:15

Personally, I always thought that a SETLL would be better performing,
because no data is read into the buffer, the pointer is just moved. But

it

seems that is not always the case, if there is no record to be found,

CHAIN

appears to be slightly quicker...

Crispin.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing

list

To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.