Yes, reading a KSAM while other users are writing or updating can prove
tricky. Obviously FLOCKing ensures you are reading what is there because
no-one can write or update the file while you have it locked. However,
FLOCK actually does 2 things I believe. It locks the file AND it flushes
the buffer and it's the flush which actually ensures you get any records
added by other users as it forces the next read to perform a physical
IO. So instead of FLOCKing we regularly flush the buffers (FCONTROL 7).

Costas Anastassiades,
Intracom SA
Athens-Greece

-----Original Message-----
From: Tony Summers <[log in to unmask]>
To: [log in to unmask] <[log in to unmask]>
Date: Thursday, November 04, 1999 12:44 PM
Subject: Re: KSAMXL question


Read next record restriction.

I agree with Costas - if you're planning to use Ksam in any big way and
need this restriction then do what we do - we've canned all our Ksam
calls into a database handler and we have a several flavours of "read
next record".

Whilst I'm replying - please be aware of the following gotcha in Ksam
which was
true for CM ksam (and I believe still applies to NM ksam).

If you're reading down a ksam file whilst someone else is updating that
file
then it is quite possible for the reading application to either miss
records or even get
several records twice.  The problem lies in how ksam manages its key
pointers - the
manual blandly warns you to FLOCK around all your FREADS - but in
reality this isn't
possible - for example you might want to read and display 30 records to
your user, then
pause and then show another 30 records.

Again, to get round this problem we've used our Ksam database handler.

P.S. Can anyone remind me whether this is the same as a broken chain in
Image ?