RE: DB/2 index updates

[CWilt@xxxxxxxxxxxx]

Tom,

You'll notice that in John's post, the help specifically states hat while
the file is open all access path changes are immediately maintained.

The effects of *IMMED, *DLY, and *REBUILD only come into play for access
paths _not_ currently open.

So, if you had a LF over your physical and you ran you test program you get
the following:

LF has *IMMED: writes to PF that effect the LF access path take "longer"
since the LF has to be maintained.
LF has *DLY or *REBUILD: writes to PF take the "same" amount, but when you
try to open the LF it will take "longer".


Note that you opposite is also true.  You could instead be using the LF for
I/O, then the setting of the physical would matter but the setting of the
logical wouldn't.


Now as far as why the next record was read instead of the updated record.
Remember you're reading sequentially in key order as opposed to randomly by
key.  From your code, I'd say that changing the key value by one isn't going
to effect the order.  Thus what you see makes sense to me.

A more interesting test would be to add 5 or something so that if you had
keys of 1, 4, 6 to start when you updated 1, the key would then be between 4
& 6.  Now the question is, will you get 4 then the new 5 or 4 then the old
6?

To be honest, I don't know.  I'd think you may get 4 then the new 5 which of
course means you'll be in an endless loop!  :-)

HTH,
Charles

> -----Original Message-----
> From: qsrvbas@xxxxxxxxxxxx [mailto:qsrvbas@xxxxxxxxxxxx]
> Sent: Thursday, June 10, 2004 8:46 PM
> To: midrange-l@xxxxxxxxxxxx
> Subject: DB/2 index updates
> 
> 
> In trying to get a clearer understanding of some details 
> about updating index fields in a PF, I created the following 
> test PF and test program:
> 
> --------------- Begin paste
> PF:
> 
>      A          R TESTPFF
>      A*
>      A            PSATFG         1A
>      A            PSSTCD         3P 0
>      A          K PSSTCD
> 
> Program:
> 
> FTESTPF    uf   e           k disk
> 
> C                   read      TESTPF
> 
> C                   dow       not %eof
> 
> C                   add       1             PSSTCD
> 
> C                   update    TESTPFF             
> C                   read      TESTPF
> 
> C                   enddo
> --------------- Begin paste
> 
> Both created with basic defaults on the CRTxxx commands on a 
> fairly stable V5R1 system. There's nothing fancy about 
> either; they're just pieces of stuff I had. In short, the PF 
> itself has a key field that's 3-digits packed. The program 
> reads in key sequence, adds 1 to the key field, updates the 
> record and reads the next.
> 
> I ran it multiple times, watching for differences between 
> *IMMED, *DLY and *REBLD access path maintenance and then 
> differences between FRCRATIO() values of 1, 2, 10 and *NONE.
> 
> The file had three records with the key values 1, 4 and 6.
> 
> So far, so good.
> 
> The surprise was that _every_ combination gave the same 
> result -- every record key had been changed to 0 (zero). I'm 
> pretty sure I understand both the *IMMED and *DLY results, 
> but I'm not certain I understand what happened for 
> MAINT(*REBLD). I suppose the _good_ news is that the results 
> were consistent.
> 
> Should the program have seen the changed index so that 
> reading the next key would get the changed record?
> 
> Tom Liotta
> 
> -- 
> Tom Liotta
> The PowerTech Group, Inc.
> 19426 68th Avenue South
> Kent, WA 98032
> Phone  253-872-7788 x313
> Fax    253-872-7904
> http://www.powertech.com
> 
> 
> __________________________________________________________________
> Introducing the New Netscape Internet Service. 
> Only $9.95 a month -- Sign up today at 
> http://isp.netscape.com/register
> 
> Netscape. Just the Net You Need. 
> 
> New! Netscape Toolbar for Internet Explorer
> Search from anywhere on the Web and block those annoying pop-ups.
> Download now at http://channels.netscape.com/ns/search/install.jsp
> --
> 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.
>