Clarification of LOCK clauses in 2002

In 12.3.4.8.3 (LOCK MODE) we have -
4) If the AUTOMATIC phrase is specified, the lock mode is automatic. Records
are locked when any READ
statement is executed.

In the synatx for the REWRITE/WRITE clauses, we have that
no LOCK clause is valid when LOCK MODE is AUTOMATIC.

Does this mean that, with LOCK MODE AUTOMATIC,
it is not possible to obtain a lock on REWRITE/WRITE?

Seems contraindicative to me.
I would either -
a) Allow the LOCK clause on the REWRITE/WRITE
or
b) Imply a lock on REWRITE/WRITE

Comments?

Roger

Roger While wrote:
> In 12.3.4.8.3 (LOCK MODE) we have -
> 4) If the AUTOMATIC phrase is specified, the lock mode is automatic.
> Records are locked when any READ
> statement is executed.
>
> In the synatx for the REWRITE/WRITE clauses, we have that
> no LOCK clause is valid when LOCK MODE is AUTOMATIC.
>
> Does this mean that, with LOCK MODE AUTOMATIC,
> it is not possible to obtain a lock on REWRITE/WRITE?
>
> Seems contraindicative to me.
> I would either -
> a) Allow the LOCK clause on the REWRITE/WRITE
> or
> b) Imply a lock on REWRITE/WRITE
>
> Comments?
>
Perhaps if you could tell us why you'd want a LOCK on a write...

Roger had asked me about this "off-list" and I just don't really understand 
the
(processor-dependent - i.s. optional) File-sharing/record-locking feature we
ll
enough to be an expert.  I can, HOWEVER, think of one situation where you mi
ght
want a LOCK on a WRITE/REWRITE.

If you have 2 files that contain "control records" and more than one program
that can update them.  Then I *think* you might want to "lock" the control
record in the 1st file until you have successfully written/re-written the
control record in the 2nd file (to keep them in sync).

Having said that, I would think you would be using manual rather than automa
tic
locking in such a case.

Again, I don't understand this feature well enough to "speak to it"
authoritatively.  Furthermore, I don't know of any commercial implementation
that has done file-sharing/record-locking the way it is in the '02 Standard 
-
even though there are several that have it as defined in X/Open.

--
Bill Klein
wmklein <at> ix.netcom.com
"HeyBub" <heybubNOSPAM@gmail.com> wrote in message
news:1372cm8sfc12m45@news.supernews.com...
> Roger While wrote: 
> Perhaps if you could tell us why you'd want a LOCK on a write...
>

I have sent a separate note to Roger off-list.  However, for anyone who CARE
S, I
did some more research and the restriction against "explicit" locking was do
ne
intentionally by J4.  The papers that discuss this are the J4 documents
99-0512
and
99-00576

If anyone else really wants to read these, email me off-list and I can send 
you
copies of them.

I do NOT claim that I understand all of this - or that I agree with the
decision, but did want the list to know that there WERE reasons for doing it
 (no
matter whether they were or were not GOOD reasons <G> )

--
Bill Klein
wmklein <at> ix.netcom.com
"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:eufci.158195$dg3.28636@fe10.news.easynews.com...
> Roger had asked me about this "off-list" and I just don't really understan
d
> the (processor-dependent - i.s. optional) File-sharing/record-locking feat
ure
> well enough to be an expert.  I can, HOWEVER, think of one situation where
 you
> might want a LOCK on a WRITE/REWRITE.
>
> If you have 2 files that contain "control records" and more than one progr
am
> that can update them.  Then I *think* you might want to "lock" the control
> record in the 1st file until you have successfully written/re-written the
> control record in the 2nd file (to keep them in sync).
>
> Having said that, I would think you would be using manual rather than
> automatic locking in such a case.
>
> Again, I don't understand this feature well enough to "speak to it"
> authoritatively.  Furthermore, I don't know of any commercial implementati
on
> that has done file-sharing/record-locking the way it is in the '02 Standar
d -
> even though there are several that have it as defined in X/Open.
>
> --
> Bill Klein
> wmklein <at> ix.netcom.com
> "HeyBub" <heybubNOSPAM@gmail.com> wrote in message
> news:1372cm8sfc12m45@news.supernews.com... 
>
>

Looking at these papers, it is clear what the intent is/was.
That is, with AUTOMATIC, the runtime automatically locks
on READ/REWRITE/WRITE and therefore the LOCK clause
is invalid on any of these statements.
HOWEVER, then paragraph 4 of 12.3.4.8.3 is misleading/wrong -
4) If the AUTOMATIC phrase is specified, the lock mode is automatic.
Records are locked when any READ
statement is executed.

This last statement should either be deleted or amended to state
... when any READ/REWRITE/WRITE ..
or maybe .. when any I/O ...

Roger

"William M. Klein" <wmklein@nospam.netcom.com> schrieb im Newsbeitrag
news:lkgci.232142$3h2.86223@fe08.news.easynews.com...
>I have sent a separate note to Roger off-list.  However, for anyone who
>CARES, I did some more research and the restriction against "explicit"
>locking was done intentionally by J4.  The papers that discuss this are the
>J4 documents
>  99-0512
>    and
>  99-00576
>
> If anyone else really wants to read these, email me off-list and I can
> send you copies of them.
>
> I do NOT claim that I understand all of this - or that I agree with the
> decision, but did want the list to know that there WERE reasons for doing
> it (no matter whether they were or were not GOOD reasons <G> )
>
> --
> Bill Klein
> wmklein <at> ix.netcom.com
> "William M. Klein" <wmklein@nospam.netcom.com> wrote in message
> news:eufci.158195$dg3.28636@fe10.news.easynews.com... 
>
>

--
Bill Klein
wmklein <at> ix.netcom.com
"Roger While" <simrw@sim-basis.de> wrote in message
news:f4tan3$due$01$1@news.t-online.com...
> Looking at these papers, it is clear what the intent is/was.
> That is, with AUTOMATIC, the runtime automatically locks
> on READ/REWRITE/WRITE and therefore the LOCK clause
> is invalid on any of these statements.
> HOWEVER, then paragraph 4 of 12.3.4.8.3 is misleading/wrong -
> 4) If the AUTOMATIC phrase is specified, the lock mode is automatic.
>    Records are locked when any READ
>    statement is executed.
>
> This last statement should either be deleted or amended to state
> ... when any READ/REWRITE/WRITE ..
> or maybe .. when any I/O ...
>
> Roger
>
> "William M. Klein" <wmklein@nospam.netcom.com> schrieb im Newsbeitrag
> news:lkgci.232142$3h2.86223@fe08.news.easynews.com... 
>
>

Roger,
I may have to go back to them, but I think that when AUTOMATIC is specified,
then READ places a LOCK, but that WRITE and REWRITE *UNLOCK" the record. So 
the
statement you quote is correct.

--
Bill Klein
wmklein <at> ix.netcom.com
"Roger While" <simrw@sim-basis.de> wrote in message
news:f4tan3$due$01$1@news.t-online.com...
> Looking at these papers, it is clear what the intent is/was.
> That is, with AUTOMATIC, the runtime automatically locks
> on READ/REWRITE/WRITE and therefore the LOCK clause
> is invalid on any of these statements.
> HOWEVER, then paragraph 4 of 12.3.4.8.3 is misleading/wrong -
> 4) If the AUTOMATIC phrase is specified, the lock mode is automatic.
>    Records are locked when any READ
>    statement is executed.
>
> This last statement should either be deleted or amended to state
> ... when any READ/REWRITE/WRITE ..
> or maybe .. when any I/O ...
>
> Roger
>
> "William M. Klein" <wmklein@nospam.netcom.com> schrieb im Newsbeitrag
> news:lkgci.232142$3h2.86223@fe08.news.easynews.com... 
>
>

After a blank post and replying to myself <G>, I just went and read the
"Concepts" section to get this correct.  On page 711 (under the topic "E.1.3
.2.1
Automatic locking"

It states,

"With single record automatic locking, a logical file has a lock on one reco
rd
at a time. The successful execution of
a READ statement establishes a lock on the newly read record. The execution 
of a
READ, REWRITE, WRITE,
DELETE, UNLOCK, or CLOSE statement releases a lock on a previously-locked
record.

With multiple record automatic locking, all newly read records are automatic
ally
locked and the lock for a record is
retained until the record is deleted, or an UNLOCK statement is executed for
 the
logical file, or the logical file is
closed."

--
Bill Klein
wmklein <at> ix.netcom.com
"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:gLvci.141158$d22.69306@fe03.news.easynews.com...
> Roger,
>  I may have to go back to them, but I think that when AUTOMATIC is specifi
ed,
> then READ places a LOCK, but that WRITE and REWRITE *UNLOCK" the record. S
o
> the statement you quote is correct.
>
> --
> Bill Klein
> wmklein <at> ix.netcom.com
> "Roger While" <simrw@sim-basis.de> wrote in message
> news:f4tan3$due$01$1@news.t-online.com... 
>
>

William M. Klein wrote:
> Roger had asked me about this "off-list" and I just don't really
> understand the (processor-dependent - i.s. optional)
> File-sharing/record-locking feature well enough to be an expert.  I
> can, HOWEVER, think of one situation where you might want a LOCK on a
> WRITE/REWRITE.
> If you have 2 files that contain "control records" and more than one
> program that can update them.  Then I *think* you might want to
> "lock" the control record in the 1st file until you have successfully
> written/re-written the control record in the 2nd file (to keep them
> in sync).

Nah.
Consider:

READ file 1 (locks)
READ file 2 (locks)
UPDATE file 1 (unlock) But notice, File 2 is still locked!
UPDATE file 2 (unlock)

And if another program does this in the order of "file 2 then file 1" - what
happens?  (This is historically known as "bad programming" when not all
applications access "critical" records in the same order - but it is also kn
own
to happen)

--
Bill Klein
wmklein <at> ix.netcom.com
"HeyBub" <heybubNOSPAM@gmail.com> wrote in message
news:13767e4dnv5gm36@news.supernews.com...
> William M. Klein wrote: 
>
> Nah.
> Consider:
>
> READ file 1 (locks)
> READ file 2 (locks)
> UPDATE file 1 (unlock) But notice, File 2 is still locked!
> UPDATE file 2 (unlock)
>