Home > Archive > Cobol > June 2007 > Clarification of LOCK clauses in 2002
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Clarification of LOCK clauses in 2002
|
|
| Roger While 2007-06-14, 7:55 am |
| 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
| |
| HeyBub 2007-06-14, 7:55 am |
| 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...
| |
| William M. Klein 2007-06-14, 9:55 pm |
| 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).
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 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...
>
| |
| William M. Klein 2007-06-14, 9:55 pm |
| 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...
> 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).
>
> 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 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 2007-06-15, 7:55 am |
| 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...
>
>
| |
| William M. Klein 2007-06-15, 7:55 am |
|
--
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...
>
>
| |
| William M. Klein 2007-06-15, 7:55 am |
| 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...
>
>
| |
| William M. Klein 2007-06-15, 7:55 am |
| 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 record
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 automatically
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 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...
>
>
| |
| HeyBub 2007-06-15, 9:55 pm |
| 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)
| |
| William M. Klein 2007-06-15, 9:55 pm |
| 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 known
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)
>
| |
| Pete Dashwood 2007-06-15, 9:55 pm |
|
"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:raFci.11281$KM6.3866@fe01.news.easynews.com...
> 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 known to happen)
>
Kinda makes me wonder why anybody would NOT use a relational database for
mission critical master data... :-)
(This thread, to me, is like discussing the relative merits of the Swiss
Army 16 nail horseshoe over the standard 8 nail model or whether size 5 city
nails are better than size 5 regular for horses on gravel roads... if you
never rode a horse in your life...)
Record locking? :-)
It's about as relevant in today's world as goose feather fletching... :-)
Pete.
<snip>
| |
| don_fitzgerald@web.de 2007-06-16, 7:55 am |
| On 16 Jun., 03:05, "Pete Dashwood"
<dashw...@removethis.enternet.co.nz> wrote:
> "William M. Klein" <wmkl...@nospam.netcom.com> wrote in messagenews:raFci.11281$KM6.3866@fe01.news.easynews.com...> And if another program does this in the order of "file 2 then file 1" -
>
> Kinda makes me wonder why anybody would NOT use a relational database for
> mission critical master data... :-)
>
> (This thread, to me, is like discussing the relative merits of the Swiss
> Army 16 nail horseshoe over the standard 8 nail model or whether size 5 city
> nails are better than size 5 regular for horses on gravel roads... if you
> never rode a horse in your life...)
>
> Record locking? :-)
>
> It's about as relevant in today's world as goose feather fletching... :-)
>
> Pete.
> <snip>
Hey Pete,
was that comment meant to help Roger or simply to irritate ?
:-)
Don
P.S: Saw the Rugby score. Good game for the Canadians - scoring a try
against you guys....
| |
|
|
| HeyBub 2007-06-17, 6:55 pm |
| William M. Klein wrote:[color=darkred]
> 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 known to happen)
>
You make a good point. Even in this 4-line prototype, if the programmer did
not take steps to guarantee file 1 and file 2 exist, the whole thing could
fail rather spectacularly. Heck, if the program were painted in the wrong
color - say purple (because I like purple) - things might not work either!
Then, too, if the programmer spent his development time teaching himself how
to hum...
| |
| Pete Dashwood 2007-06-17, 6:55 pm |
|
<don_fitzgerald@web.de> wrote in message
news:1181993069.061174.272080@k79g2000hse.googlegroups.com...
> On 16 Jun., 03:05, "Pete Dashwood"
> <dashw...@removethis.enternet.co.nz> wrote:
>
> Hey Pete,
>
> was that comment meant to help Roger or simply to irritate ?
> :-)
Roger doesn't need help. He's one of the brightest people here. :-)
The comment was intended to try and get some perspective on the topic, in
case people who don't know better think that record locking and ISAM is the
"way to go"... Roger has little choice as he's writing a compiler; others
have plenty of choice.
As for being irritating... well, sometimes it is necessary...:-) (Besides, I
need to have some fun occasionally...there's little enough of it here...:-)
>
> Don
>
> P.S: Saw the Rugby score. Good game for the Canadians - scoring a try
> against you guys....
>
It was outstanding. A pass was intercepted beautifully, and a VERY tall
Canadian (6'6") ran more than 70 yards with an AB winger in hot pursuit. The
crowd went berserk and cheered the Canadians... :-) All-in-all it looked
like a very good-natured game with a capacity crowd.
I didn't get to the game in the end but, from what I have seen of it, Canada
acquitted themselves with honour. I'll watch the whole thing tomorrow.
Pete.
| |
| Pete Dashwood 2007-06-17, 6:55 pm |
|
"HeyBub" <heybubNOSPAM@gmail.com> wrote in message
news:1377pivq4i434fa@news.supernews.com...
> William M. Klein wrote:
>
> You make a good point. Even in this 4-line prototype, if the programmer
> did not take steps to guarantee file 1 and file 2 exist, the whole thing
> could fail rather spectacularly. Heck, if the program were painted in the
> wrong color - say purple (because I like purple) - things might not work
> either!
>
> Then, too, if the programmer spent his development time teaching himself
> how to hum...
>
..... or even make arrows...:-)
Pete.
| |
|
| In article <5dibcoF32sgd7U1@mid.individual.net>,
Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote:
[snip]
>The comment was intended to try and get some perspective on the topic, in
>case people who don't know better think that record locking and ISAM is the
>"way to go"... Roger has little choice as he's writing a compiler; others
>have plenty of choice.
'I'm not stating my own petty prejudices, hopes observations and
desires as fact... just trying to get some perspective on the topic.'
Sounds downright... Managerial, doesn't it?
DD
| |
| William M. Klein 2007-06-17, 6:55 pm |
| "Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
news:5dibcoF32sgd7U1@mid.individual.net...
>
<snip>
> Roger doesn't need help. He's one of the brightest people here. :-)
>
> The comment was intended to try and get some perspective on the topic, in case
> people who don't know better think that record locking and ISAM is the "way to
> go"... Roger has little choice as he's writing a compiler; others have plenty
> of choice.
>
Actually, when it comes to "file-sharing/record-locking" and the '02 Standard
(it isn't in the '85 Standard at all), Roger DOES have a choice. This is a
"processor dependent" feature which means that a conforming implementation is
NOT required to implement it, if they don't want to.
--
Bill Klein
wmklein <at> ix.netcom.com
| |
| Pete Dashwood 2007-06-17, 6:55 pm |
|
<docdwarf@panix.com> wrote in message news:f50udd$fh5$1@reader2.panix.com...
> In article <5dibcoF32sgd7U1@mid.individual.net>,
> Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote:
>
> [snip]
>
>
> 'I'm not stating my own petty prejudices, hopes observations and
> desires as fact... just trying to get some perspective on the topic.'
"Hopes observations and desires"? !!
It's computer programming for Chrissake! I couldn't really give a shit what
people choose, I just enjoy winding up the dinosaurs :-) (especially a
certain Dwarf...)
Besides, visitors here really shouldn't go away thinking that 1960s
technology is all COBOL has to offer.
>
> Sounds downright... Managerial, doesn't it?
Depends on the Manager, I guess.
Get a life.
Pete.
| |
| Pete Dashwood 2007-06-17, 6:55 pm |
|
"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:e8Uci.177162$d22.176412@fe03.news.easynews.com...
> "Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
> news:5dibcoF32sgd7U1@mid.individual.net...
> <snip>
>
> Actually, when it comes to "file-sharing/record-locking" and the '02
> Standard (it isn't in the '85 Standard at all), Roger DOES have a choice.
> This is a "processor dependent" feature which means that a conforming
> implementation is NOT required to implement it, if they don't want to.
>
Roger's original post was to get clarification on the wording of the
standard. When I said he has no choice, I was referring to his need to
interpret the standard. Once he's done that, he cartainly has some choice as
to what he decides to implement, although I suspect he will make it as full
an implementation as possible. I wish him luck.
Pete.
| |
|
| In article <5djfsdF35c6tlU1@mid.individual.net>,
Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote:
>
><docdwarf@panix.com> wrote in message news:f50udd$fh5$1@reader2.panix.com...
>
>"Hopes observations and desires"? !!
Pardon the comma-key glitch, that should have been '... petty prejudices,
hopes, obsertations and desires...'.
>
>It's computer programming for Chrissake! I couldn't really give a shit what
>people choose, I just enjoy winding up the dinosaurs :-) (especially a
>certain Dwarf...)
Of *course* you do, Mr Dashwood... but if that is truly the case then it
might do you well to learn how to do what you want... rather than do what
you demonstrate here.
>
>Besides, visitors here really shouldn't go away thinking that 1960s
>technology is all COBOL has to offer.
>
>Depends on the Manager, I guess.
>
>Get a life.
Already have one, thanks, and by some standards a moderately pleasant
existence it is.
DD
| |
| Pete Dashwood 2007-06-17, 6:55 pm |
|
<docdwarf@panix.com> wrote in message news:f539q1$akv$1@reader2.panix.com...
> In article <5djfsdF35c6tlU1@mid.individual.net>,
> Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote:
>
> Pardon the comma-key glitch, that should have been '... petty prejudices,
> hopes, obsertations and desires...'.
"...obsertations..."
Well, of course, if you think it's OK to belittle my personal obsertations,
and lump them in with my prejudices (not much in that collection), hopes and
desires, I guess that's entirely a matter for you.
I've always considered a person's obsertations to be private and sacrosanct,
but maybe in Dwarfland things are different.
You wouldn't catch me discussing YOUR obsertations (or any other
sensitivities) in a public unmoderated forum, but then, I was raised on the
playing fields of Eton (we couldn't afford a house...) and therefore do
things differently.
OK, that's all right, then.
>
>
> Of *course* you do, Mr Dashwood... but if that is truly the case then it
> might do you well to learn how to do what you want... rather than do what
> you demonstrate here.
>
>
> Already have one, thanks, and by some standards a moderately pleasant
> existence it is.
Glad to hear it. So you won't be concerned about my hopes, obsertations,
desires and such in the future? I'm really working far too hard at the
moment and am therefore pretty fragile and easily crushed... Even thinking
about my hopes and desires (let alone my... obsertations <choke> ) brings me
to the point of tears...
It's more than I can bear...Oh, the pain... the pain....
Pete.
| |
|
| In article <5dkvasF34covkU1@mid.individual.net>,
Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote:
>
><docdwarf@panix.com> wrote in message news:f539q1$akv$1@reader2.panix.com...
>
>"...obsertations..."
>
>Well, of course, if you think it's OK to belittle my personal obsertations,
>and lump them in with my prejudices (not much in that collection), hopes and
>desires, I guess that's entirely a matter for you.
I'd be most interested, Mr Dashwood, to know what statements I have made
which you consider to be 'belittling'.
[snip]
>
>Glad to hear it. So you won't be concerned about my hopes, obsertations,
>desires and such in the future?
Leaving aside the shift from the earlier 'belittling' to the abovenoted
'concern'... if you do not wish to attract the attentions of others, Mr
Dashwood, then you might not wish to post such things on the UseNet...
your choice, nobody else's.
DD
| |
| Pete Dashwood 2007-06-18, 3:55 am |
|
<docdwarf@panix.com> wrote in message news:f54hng$jed$1@reader2.panix.com...
> In article <5dkvasF34covkU1@mid.individual.net>,
> Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote:
>
> I'd be most interested, Mr Dashwood, to know what statements I have made
> which you consider to be 'belittling'.
Good Heavens man, have you NO sensitivity?
You said my "petty prejudices, hopes, obsertations and desires..." were
nothing more than ...."Managerial".... Oh the pain... To have such things
minimised (that's belittling...) to the level of some Corner Office Idiot.
(Especially the obsertations...that hurt the most...)
A lifetime of petty prejudice, hope, desire and... <choke> obsertations,
trivialised and dismissed in one fell statement...<sob>
I need to go and lie down in a darkened room. I hope some day you realise
the enormity of this cruelty and it rebounds upon you...
Pete.
| |
|
| In article <5dm43uF355niqU1@mid.individual.net>,
Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote:
>
><docdwarf@panix.com> wrote in message news:f54hng$jed$1@reader2.panix.com...
>
>Good Heavens man, have you NO sensitivity?
The answer to that, Mr Dashwood, might depend on whom one asks. Insofar
as I've found myself aware of the occasional pebble in my shoe then it
might be said that yes, I have SOME (caps reflecting original use)
sensitivity.
Come to think of it... there's something here which might be reminiscent
of one... except, of course, for the fact that a pebble in my shoe is, to
me, a matter of a bit of consequence.
DD
| |
| Pete Dashwood 2007-06-18, 9:56 pm |
|
<docdwarf@panix.com> wrote in message news:f55ius$a3v$1@reader2.panix.com...
> In article <5dm43uF355niqU1@mid.individual.net>,
> Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote:
>
> The answer to that, Mr Dashwood, might depend on whom one asks. Insofar
> as I've found myself aware of the occasional pebble in my shoe then it
> might be said that yes, I have SOME (caps reflecting original use)
> sensitivity.
>
> Come to think of it... there's something here which might be reminiscent
> of one... except, of course, for the fact that a pebble in my shoe is, to
> me, a matter of a bit of consequence.
And this critically important correspondence is of less consequence than a
pebble in your shoe?
Nice try, but I know that isn't true.
If it were, you wouldn't be wasting time responding to it.
I'm bored with it now, so consider the pebble expelled.
No more from me on this.
Pete.
| |
|
| In article <5dnbn0F360f20U1@mid.individual.net>,
Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote:
>
><docdwarf@panix.com> wrote in message news:f55ius$a3v$1@reader2.panix.com...
[snip]
[color=darkred]
>
>And this critically important correspondence is of less consequence than a
>pebble in your shoe?
I don't recall having made such a statement, Mr Dashwood.
>
>Nice try, but I know that isn't true.
Mr Dashwood, you ask a question about a statement I never made... and then
you address that question as being false.
No need for me to take much space in this conversation, it seems.
>
>If it were, you wouldn't be wasting time responding to it.
>
>I'm bored with it now, so consider the pebble expelled.
Mr Dashwood, if the conversations you have with yourself bore you then
there might be a bit more involved than meets my eye, certainly.
DD
| |
| Roger While 2007-06-18, 9:56 pm |
|
"Pete Dashwood" <dashwood@removethis.enternet.co.nz> schrieb im Newsbeitrag
news:5dibcoF32sgd7U1@mid.individual.net...
>
> <don_fitzgerald@web.de> wrote in message
> news:1181993069.061174.272080@k79g2000hse.googlegroups.com...
>
> Roger doesn't need help. He's one of the brightest people here. :-)
>
Wow, polishes up halo having got through the MOT/TUF (whatever)
after x million lines of code (or is that n years slogging).
Ready for another few lines of code :-)
Should get old-timer status anytime soon :-)
> The comment was intended to try and get some perspective on the topic, in
> case people who don't know better think that record locking and ISAM is
> the "way to go"... Roger has little choice as he's writing a compiler;
> others have plenty of choice.
>
Indeed, to a certain extent.
As regards the original topic, Bill supplied
me with the documents.
It is apparent that the INTENT was correct.
ie. Locks would be done automatically for
[RE]WRITE.
Therefore the banning of LOCK clauses on
ALL I/O statements. Quite correct.
HOWEVER, the phraseology in the LOCK
MODE clause remains which is either -
a) misleading
b) wrong
Incidentally, OC has (in the 0.33 prelease, ISAM) support
for the (current - with this discrepancy, ie. no locks
for [re]write on automatic) for
LOCK MODE and LOCK on I/O.
Which, for me, is obviously wrong.
Why I said "to a certain extent" is that other compiler
producers appear to do things differently.
How do you say it, I am between a brick
and a hard place.
Users require a certain compatibility.
A lot of what I do is providing MF/ACU/Mainframe features
because that is how the Cobol code has been developed.
This locking question was promoted from me because there
is a significant difference between eg. MF and ACU as regards
locking on ISAM files.
I will be conversing with Bill on a possible amendment to
the standard.
(Note that the misplaced LOCK statement in format 1
of the WRITE staement is on the committees agenda,
subject of previous posts)
Roger
| |
| Howard Brazee 2007-06-18, 9:56 pm |
| On Fri, 15 Jun 2007 23:22:00 GMT, "William M. Klein"
<wmklein@nospam.netcom.com> wrote:
>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 known
>to happen)
Historically, a deadlock was the result. But things have improved
since those days.
| |
| Howard Brazee 2007-06-18, 9:56 pm |
| On Sat, 16 Jun 2007 13:05:17 +1200, "Pete Dashwood"
<dashwood@removethis.enternet.co.nz> wrote:
>Kinda makes me wonder why anybody would NOT use a relational database for
>mission critical master data... :-)
>
>(This thread, to me, is like discussing the relative merits of the Swiss
>Army 16 nail horseshoe over the standard 8 nail model or whether size 5 city
>nails are better than size 5 regular for horses on gravel roads... if you
>never rode a horse in your life...)
>
>Record locking? :-)
>
>It's about as relevant in today's world as goose feather fletching... :-)
There's still record locking, it is just a step further removed from
our programming.
| |
| William M. Klein 2007-06-18, 9:56 pm |
| <all previous posts snipped>
1) Neither MF nor Acu (nor RM or anyone else that I know of) claim to meet the
'02 Standard definition of Record-Locking/File-sharing. They *do* claim to meet
the X/Open definition. (I think I previously posted the URL for getting the
"free CAE" version of that specification.
2) I can find ZERO evidence that J4/WG4 or anyone else ever inteded WRITE or
REWRITE with AUTOMATIC specified to *GET* a lock. Rather (as I previously
posted) they SHOULD *release* a lock (if single rather than multiple record
locking is in effect)
***
If you (Roger - or anyone else) can point me to someplace that indicates to the
contrary, please let me know.
***
In addition to what I previously posted, I would poin to:
9.1.15 Record locking
"For automatic single-record locking, the runtime system controls the setting
and releasing of locks. For automatic
multiple-record locking, the runtime system controls the setting of locks, and
the application controls the releasing
of locks by the execution of an explicit UNLOCK statement."
And
Rewrite GR(11)
Write GR(7)
***
I think that all of this is "clear" and consistent (and what was inteded)
--
Bill Klein
wmklein <at> ix.netcom.com
| |
| Roger While 2007-06-18, 9:56 pm |
|
"William M. Klein" <wmklein@nospam.netcom.com> schrieb im Newsbeitrag
news:J6ydi.74096$AX2.12198@fe04.news.easynews.com...
> <all previous posts snipped>
> REWRITE with AUTOMATIC specified to *GET* a lock. Rather (as I previously
> posted) they SHOULD *release* a lock (if single rather than multiple
> record locking is in effect)
>
Then this does not make sense.
I will implement the classic locking for [RE]WRITE
(AUTOMATIC) as I need this for OC.
Further to Bill off forum.
Roger
> ***
>
> If you (Roger - or anyone else) can point me to someplace that indicates
> to the contrary, please let me know.
>
> ***
>
> In addition to what I previously posted, I would poin to:
>
> 9.1.15 Record locking
>
> "For automatic single-record locking, the runtime system controls the
> setting and releasing of locks. For automatic
> multiple-record locking, the runtime system controls the setting of locks,
> and the application controls the releasing
> of locks by the execution of an explicit UNLOCK statement."
>
> And
>
> Rewrite GR(11)
>
> Write GR(7)
>
> ***
>
> I think that all of this is "clear" and consistent (and what was inteded)
>
> --
> Bill Klein
> wmklein <at> ix.netcom.com
>
| |
| Pete Dashwood 2007-06-19, 7:55 am |
|
"Howard Brazee" <howard@brazee.net> wrote in message
news:it7d73590irjkg3f79b9kubpajifie2a0j@
4ax.com...
> On Sat, 16 Jun 2007 13:05:17 +1200, "Pete Dashwood"
> <dashwood@removethis.enternet.co.nz> wrote:
>
>
> There's still record locking, it is just a step further removed from
> our programming.
Yep. And there's still archery. It's just a step further removed from
Agincourt... :-)
Pete.
| |
| HeyBub 2007-06-19, 9:55 pm |
| Pete Dashwood wrote:
> "Howard Brazee" <howard@brazee.net> wrote in message
> news:it7d73590irjkg3f79b9kubpajifie2a0j@
4ax.com...
>
> Yep. And there's still archery. It's just a step further removed from
> Agincourt... :-)
>
As the English say, "Pluck Yew"
| |
| Pete Dashwood 2007-06-19, 9:55 pm |
|
"HeyBub" <heybubNOSPAM@gmail.com> wrote in message
news:137fuv8k6uvku1d@news.supernews.com...
> Pete Dashwood wrote:
>
> As the English say, "Pluck Yew"
Oh, very good, Jerry :-)
Made my day... :-)
Pete.
| |
|
|
|
|
|