START/READ Anomaly ?

Let's assume we have an Indexed-Sequential file.
Further let's assume we have a known unique prime key/record.
Consider :
START file KEY = primekey INVALID ...
OK, we have a successful find.

Note that the START staement is so defined that
it does not detect, acquire or releaase locks (2002/2008).

So now another run-unit comes along, READ's direct
with LOCK and DELETE's our record.
(If the file is not in sequential access mode, we
do not even need the read)

Meanwhile our original program gets around to
doing a READ NEXT (with/without LOCK)

Our program had better check that what it gets
is really what it wanted !! (ie. returned key = key passed to START)

Problem is either :
a) Why isn't there a LOCK clause for START
or
b) Why isn't/wasn't the START syntax integrated into READ

Thoughts ?

Roger

My "programming 'style'" recommendation is to NOT to allow a DELETE of a REC
ORD
in one program - unless you have OPENed that file with
SHARING WITH READ ONLY

--
Bill Klein
wmklein <at> ix.netcom.com
"Roger While" <simrw@sim-basis.de> wrote in message
news:e97i6n$dcg$02$1@news.t-online.com...
> Let's assume we have an Indexed-Sequential file.
> Further let's assume we have a known unique prime key/record.
> Consider :
> START file KEY = primekey INVALID ...
> OK, we have a successful find.
>
> Note that the START staement is so defined that
> it does not detect, acquire or releaase locks (2002/2008).
>
> So now another run-unit comes along, READ's direct
> with LOCK and DELETE's our record.
> (If the file is not in sequential access mode, we
> do not even need the read)
>
> Meanwhile our original program gets around to
> doing a READ NEXT (with/without LOCK)
>
> Our program had better check that what it gets
> is really what it wanted !! (ie. returned key = key passed to START)
>
> Problem is either :
> a) Why isn't there a LOCK clause for START
> or
> b) Why isn't/wasn't the START syntax integrated into READ
>
> Thoughts ?
>
> Roger
>
>

Alternatively, have the file opened in DYNAMIC mode and READ the specific re
cord
WITH LOCK.

--
Bill Klein
wmklein <at> ix.netcom.com
"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:FqItg.166624$LI3.60748@fe12.news.easynews.com...
> My "programming 'style'" recommendation is to NOT to allow a DELETE of a
> RECORD in one program - unless you have OPENed that file with
>   SHARING WITH READ ONLY
>
> --
> Bill Klein
> wmklein <at> ix.netcom.com
> "Roger While" <simrw@sim-basis.de> wrote in message
> news:e97i6n$dcg$02$1@news.t-online.com... 
>
>

> a) Why isn't there a LOCK clause for START

Because LOCK is unnecessary when all you are doing is positioning the
pointer. (No access to data).

MCM

Roger While wrote:
> Let's assume we have an Indexed-Sequential file.
> Further let's assume we have a known unique prime key/record.
> Consider :
> START file KEY = primekey INVALID ...
> OK, we have a successful find.
>
> Note that the START staement is so defined that
> it does not detect, acquire or releaase locks (2002/2008).
>
> So now another run-unit comes along, READ's direct
> with LOCK and DELETE's our record.
> (If the file is not in sequential access mode, we
> do not even need the read)
>
> Meanwhile our original program gets around to
> doing a READ NEXT (with/without LOCK)
>
> Our program had better check that what it gets
> is really what it wanted !! (ie. returned key = key passed to START)
>
> Problem is either :
> a) Why isn't there a LOCK clause for START
> or
> b) Why isn't/wasn't the START syntax integrated into READ
>
> Thoughts ?

Hmmm. Never tried that. Only time I do a START is when I don't know the key.
That implies I'm going to check the record on the subsequent read. If I do
know the key, I always READ (with lock).*

There may be some performance gain in doing a START for a known key followed
by a READ (in a multi-processing environment), but, as you point out, it
opens the door for problems.

====
* All our IO routines are subroutines and all reads are WITH LOCK. If we are
referencing only (no possibility of updating), then we make a decision: if
the code implies another read is imminent (which will release the lock), we
do nothing. If a non-updating read is followed by significant processing, we
UNLOCK the record.