Jon the LOCKED clause acts like a Then...else
You can only take one branch. So for the locked record, it took the LOCKED
branch and ignored the END THEN branch
Because the Locked clause is another case you see?
Like
Readu
CASE Locked: do this
CASE NotLockedANd Exists: do that
CASE NotLockedANDDoesNotExist: do a third thing
....
You understand?
This is why you MUST have a LOOPing structure around the Locking.
Which is what I sent you the other day.
-----Original Message-----
From: Jon Wells <jwaytwe...@yahoo.com>
To: U2 Users List <u2-users@listserver.u2ug.org>
Sent: Fri, Feb 8, 2013 9:57 am
Subject: Re: [U2] Record locks (Unidata 7.2)
I should add that (in our test account) I switched to the READU statement along
with a LOCKED clause ->
READU STU.REC FROM STU.FILE, STU.ID LOCKED
CRT STU.ID:" RECORD IS LOCKED"
END THEN
STU.REC<48> = INST.CRED
STU.REC<49> = INET.CRED
WRITE STU.REC ON STU.FILE, STU.ID
END
I locked one of the records in the list I was processing. When the program
was
working on that record, the CRT statement was executed, and the program moved
right along processing the rest of the list; and record I had locked was not
updated.
Looking through the 'UniBasic Commands Reference' PDF, I found 'RECORDLOCKED
(file.var, rec.id.expr)'. Perhaps this could be used within a LOOP to control
things, allowing terminal input where the user can choose what to do about the
record lock?
I've decided to write the data to a new file, so this is no longer a big issue
for me. If I had created the program using our vendor's tool kit, the
generated
code would have added all the appropriate gunk the system uses for record
locks. The responses have been interesting as I've been looking for a chance
to
better understand how Unidata shops handle locks.
Thank you,
Jon Wells
________________________________
From: Tony Gravagno <3xk547...@sneakemail.com>
To: u2-users@listserver.u2ug.org
Sent: Friday, February 8, 2013 2:30 AM
Subject: Re: [U2] Record locks (Unidata 7.2)
I think people understand exactly what you're saying, but disagree.
Most applications don't use the more rigorous coding for having a
Locked clause that provides additional information to the user,
retries, etc. That's not "wrong", it's just not necessary ...
depending on the site.
That said, when we used to have a lot of people in an office and a
dumb terminal beeping was a recognized message to everyone, it was OK
(generally) to just do the READU. These days with more alternative
UIs, thick-client, thin-client, web services, mobile, etc, there's no
one to hear that beep. So for modern development I would agree that
you really don't want an unconditional lock hanging around, you want a
Locked clause with logic to rollback the transaction and exit
gracefully, perhaps with a message sent to the site admin.
The penalty for Not having a Locked clause with a new UI is that the
port will hang, the UI will receive a timeout (which many clients
aren't prepared to process), and the DBMS port could be sitting there
indefinitely with no one aware of the condition. This can cascade to
multiple ports until suddenly everything grinds to a halt and GUI
users around the world are unable to access the app. I believe some
heads will be nodding here because I hear about this happening
occasionally.
T
> From: Wjhonson
> Then you're misunderstanding what I'm saying.
> From: Kevin King
> +1. Well stated.
>
> Woodward, Bob wrote:
> > In an active user session where users are obtaining a lock for a
> > length of time, you're right. There are lots of times, though,
that
> > lock intervention is not a benefit. It all depends on the need of
the
> > application and many situations where I would highly recommend
> > using the default locking system of READU.
> > From: Wjhonson
> > I wouldn't however *recommend* this approach to locking as the
user
> > can never tell if their terminal is waiting on a lock, or just
"hung"
> > in some other odd manner, or perhaps processing a batch of
something.
> >
> > So it's rather a nasty trick to play on the user, to just use
READU
> > without a LOCKED clause
_______________________________________________
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
_______________________________________________
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
_______________________________________________
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
