> Tracy Pierce wrote:
>  > I'm not convinced that FSPACE(fn,-1) really does work reliably with
>  > CM KSAM: How can it?  All the docs I've read (ie not all of them!)
>  > indicate that the indices are single-threaded, leaving reliable
>  > backspace theoretically impossible: there is no backward
> pointer like
>  > there is on Image paths. Please tell me I'm wrong?

Jeff replied,
> Originally in CM KSAM there was only one record pointer, period.  If you
> wanted to manipulate the record pointer, you were supposed to flock()
> before, do your things, and funlock() afterward.  If you fpoint() or
> freadbykey(), the record pointer can be changed by a similar operation
> in another process, and the pointer no longer points to the record that
> you think you are.  The same would apply to fspace().  You had to lock
> the file around accesses which were dependent on the record pointer.
>
> I think this still applies to KSAMXL but I am not confident of this.
> Jeff

agreed; you're sharing the index pointer and buffer with other processes,
and they'll lose your place.

but what about the backspace bit?  If we have only forward-pointing links,
how is backward possible or even seemingly possible?  Only one answer comes
to mind: if you load the file in the same sequence as the key you're using,
the physical backspace appears to work.  but what about a different key?

I'd sure love to be wrong about this: it would be just great to really
backspace, even if locks are required.

Tracy Pierce

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *