 | |
#1
 
| |||
| |||
|
Re: revised readu example -
05-26-2010
, 12:59 AM
|
Years ago I wrote here in CDP Also , here's an example of READU three-clause usage; READU * *myfile, *"george" * *LOCKED * *CRT * 'name george is locked by someone else;': * *CRT * ' *item may or may not exist' END THEN * *CRT * 'george did exist, and we now own a lock on that name' END ELSE * CRT * 'george *does not exist, but we now own a lock on the name' END But I'm advised that the LOCKED clause really should have a line * * * RELEASE *myfile, "george" since historically some licensee companies have had a Basic that created a secondary lock if the item was found locked by another. *So in a loopthis little-regarded lock might eventually give the 'Maximum number of item locks exceeded' *message... Also, would anybody care to hazard a guess how generously that limit is allocated on d3/linux and/or d3/nt? * I've never happened to run afoul of it yet, but stuff happens, they say... Frank |
#2
| |||
| |||
|
|
Also , here's an example of READU three-clause usage; READU myfile, "george" LOCKED CRT 'name george is locked by someone else;': CRT ' item may or may not exist' END THEN CRT 'george did exist, and we now own a lock on that name' END ELSE CRT 'george does not exist, but we now own a lock on the name' END |
RELEASE myfile, "george"
since historically some licensee companies have had a Basic that created
a secondary lock if the item was found locked by another. So in a loop this
little-regarded lock might eventually give the
'Maximum number of item locks exceeded' message...
Also, would anybody care to hazard a guess how generously that limit is allocated on
d3/linux
and/or d3/nt? I've never happened to run afoul of it yet, but stuff happens, they say...
Frank
#3
| |||
| |||
|
#4
| |||
| |||
|
|
(At times I have to wonder if I'm the ONLY person who writes little test programs to try & figure out how/why things work the way they do. I'm sure I'm not, but some of the questions posed at times make me wonder ...) |
have a SCRATCH.VME and SCRATCH.FSI account that I use for test ditties
like that.
For Frank - I've never heard of a secondary lock. Without a Locked
clause, code will simply hang and wait for access to a record. As
soon as the record is available and the lock is released, one of the
processes attempting to get the record will lock it. There's no need
for a secondary lock. D3 does have a queuing mechanism for
first-come-first-serve access to records, the list-lockq verb shows
the queue of processes waiting on any given record. I don't know if
or how this is implemented in other platforms.
Rather than working around a problem that you may (or may not)
encounter on some as-yet-unidentified system, I recommend that you
simply code to spec, and if there is a bug, then file a report with
the vendor and adjust as required.
With regard to RELEASE, it can be a double-edged sword. I believe
that like GOTO, a RELEASE with no arguments is usually a lazy
programmer's escape hatch out of bad code. RELEASE with arguments
should only be used if the code is saying "I really thought I needed
exclusive access to this record but I explicitly decided that I do
not". I would not add RELEASE because some platform "might" have a
double-lock bug.
HTH
T
#5
| |||
| |||
|
|
Ross Ferris wrote: (At times I have to wonder if I'm the ONLY person who writes little test programs to try & figure out how/why things work the way they do. I'm sure I'm not, but some of the questions posed at times make me wonder ...) You're not. *If I think a question can easily be answered with code *I have a SCRATCH.VME and SCRATCH.FSI account that I use for test ditties like that. For Frank - I've never heard of a secondary lock. *Without a Locked clause, code will simply hang and wait for access to a record. *As soon as the record is available and the lock is released, one of the processes attempting to get the record will lock it. *There's no need for a secondary lock. *D3 does have a queuing mechanism for first-come-first-serve access to records, the list-lockq verb shows the queue of processes waiting on any given record. *I don't know if or how this is implemented in other platforms. Rather than working around a problem that you may (or may not) encounter on some as-yet-unidentified system, I recommend that you simply code to spec, and if there is a bug, then file a report with the vendor and adjust as required. With regard to RELEASE, it can be a double-edged sword. *I believe that like GOTO, a RELEASE with no arguments is usually a lazy programmer's escape hatch out of bad code. *RELEASE with arguments should only be used if the code is saying "I really thought I needed exclusive access to this record but I explicitly decided that I do not". *I would not add RELEASE because some platform "might" have a double-lock bug. HTH T |
why pick is obscure and unnessary
#6
| |||
| |||
|
|
Ross Ferris wrote: (At times I have to wonder if I'm the ONLY person who writes little test programs to try & figure out how/why things work the way they do. I'm sure I'm not, but some of the questions posed at times make me wonder ...) You're not. If I think a question can easily be answered with code I have a SCRATCH.VME and SCRATCH.FSI account that I use for test ditties like that. For Frank - I've never heard of a secondary lock. Without a Locked clause, code will simply hang and wait for access to a record. As soon as the record is available and the lock is released, one of the processes attempting to get the record will lock it. There's no need for a secondary lock. D3 does have a queuing mechanism for first-come-first-serve access to records, the list-lockq verb shows the queue of processes waiting on any given record. I don't know if or how this is implemented in other platforms. Rather than working around a problem that you may (or may not) encounter on some as-yet-unidentified system, I recommend that you simply code to spec, and if there is a bug, then file a report with the vendor and adjust as required. With regard to RELEASE, it can be a double-edged sword. I believe that like GOTO, a RELEASE with no arguments is usually a lazy programmer's escape hatch out of bad code. RELEASE with arguments should only be used if the code is saying "I really thought I needed exclusive access to this record but I explicitly decided that I do not". I would not add RELEASE because some platform "might" have a double-lock bug. HTH T |
our clients on D3 or MVBase, I'd certainly forgo the paranoid programming.
If I was writing a small routine or code snippet for widespread {esp. free}
distribution, I'd tend to add lots of armor... I have contact with a large old
commercial package that was written to survive porting to a bewildering array
of vendor platforms, so maybe I've just gotten a little bent from reading that code...
About the test-instead-of-post_a_question, I was 2 parts too lazy to backup
before, and restore after, such testing and couldn't justify even the slight risk
that this would have odd side effects on our system. But I was 3 parts curious
if historically or on other flavors of pick there were modestly interesting limits
on how many item locks you could maintain at once, or if the systems handled
exceeding that rather badly.
This all started when I saw a post by one
Michael M Mason entered on Dec 19, 1997
about his non-D3 experience;
Quote:
|
A gotcha that I've come across on the Pick I'm using (Open Architecture) arises with the LOCKED clause. If you try to do something like this:- 100 READU rec FROM wherever,id LOCKED RQM GOTO 100 END THEN .... |
Quote:
|
...it turns out that the READU sets a new lock each time it executes and eventually the lock table fills up with the usual dire consequences. You have to do a RELEASE wherever,id straight after the LOCKED clause. |
Perhaps calling it a 'secondary lock' was a poor move on my part...
Frank
#7
| |||
| |||
|
|
This all started when I saw a post by one Michael M Mason entered on Dec 19, 1997 about his non-D3 experience; A gotcha that I've come across on the Pick I'm using (Open Architecture) arises with the LOCKED clause. If you try to do something like this:- 100 READU rec FROM wherever,id LOCKED RQM GOTO 100 END THEN .... ...it turns out that the READU sets a new lock each time it executes and eventually the lock table fills up with the usual dire consequences. You have to do a RELEASE wherever,id straight after the LOCKED clause. |
literally talking about a release-specific problem in a new platform
(v1 or v2, there was no OA v3) from almost 20 years ago. Since then,
Sequoia, mvEnterprise, Advanced Pick, and now D3 have derived from
that base and chances are virtually nil that this issue remains.
About the concept of READU/LOCKED, the process should not have created
an entry in the lock-queue table (if there was one at the time!) when
the LOCKED clause was taken. The locked clause explicitly says "don't
assert a lock or wait for the record, I'm outta here!" (Makes me
wonder if some platforms have implemented a WAITFOR clause that allows
a process to wait for some number of milliseconds before giving up.)
I'm all in favor of cautious programming but lines must be drawn. Any
number of disasters can be accommodated in code, but within
(subjective) reason. Coding against old bugs and possible failures in
the underlying platform seems like paranoia at best, and yields
seriously bloated, non-performant, and difficult to maintain code at
worst.
Has this thread outlived its potential usefulness?
T
 |
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.