It's too long ago to remember exactly when I had to deal with this
situation. It was definitely a Transact application which used intrinsics
to manipulate a KSAM and I think it was under MPE/iX .

The bottom line was that a session could update a KSAM record, and other
sessions could then retrieve it and not see the changes.

Please precede all following statements with "I believe" :)

Unless the KSAM is open in exclusive mode, you can't update or write to it
unless you first lock it. So a locking strategy is not necessary, it's
obligatory.

The "updating" session followed an  FLOCK-FUPDATE-FUNLOCK sequence.
The reading session however already had the record in it's buffer and so
didn't go to disk to get the changes.
The solution was to regularly flush the buffers using FCONTROL and so force
a disk I/O on the next read.
In this situation, the regular flush "benefits" the reading session rather
than the writing session.

Is all this obsolete now (MPE/iX, KSAMXL, 5.5) ? I hope not :) because if
so, I really ought to do some spring cleaning on a couple of programs...

Costas Anastassiades,
Intracom SA
Athens-Greece