The READU statement has a LOCKED clause that is true if a record is locked.
You can put all your locking ha logic in there.
READU record FROM filevariable,itemID THEN
code if record exists and isn't locked (optional)
LOCKED
code to handle locked record condition (optional)
END ELSE
code
Perhaps we should apply a little Systems Analysis 101 here - ask some
questions. I'm not convinced that the original request completely
described the need.
What is the logical scenario (batch update, transaction entry, file
maintenance, etc.)?
Once a lock is removed, do you want your copy of
Sorry Mecki but I think you have the LOCKED in the wrong place. At
least in my version of Unidata. It comes before the THEN segment so the
full, proper syntax would be:
READU xxx FROM xxx, xxx ON ERROR
Xxx what to do if a hard error like file not open
END LOCKED
Xxx what to do if locked
END
Someone remind me, how to do this.
If pagination has been turned off, and for my embedded routine, I want to turn
it back on again.
How do I do this?
I've tried HEADING, and PAGE, and CRT @(0,0)
I know there's a trick but I can't quite recall what it is
BPIOCP
David A. Green
(480) 813-1725
DAG Consulting
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Wjhonson
Sent: Thursday, February 07, 2013 1:21 PM
To: u2-users@listserver.u2ug.org
Subject: [U2] Turn pagination
BPIOCP (UD)
CALL !BPIOCP (UV)
Larry Hiscock
Western Computer Services
Someone remind me, how to do this.
If pagination has been turned off, and for my embedded routine, I want to
turn it back on again.
How do I do this?
I've tried HEADING, and PAGE, and CRT @(0,0)
I know there's a trick
For pagination we setup an I-Descriptor for a CLIENT table as follows:
ROW_NUMBER I @1+1 ; INT(@1)MD0 Row Number 5R
S
The trick is the @1+1 ; INT(@1) bit.
Chris
From: dgr...@dagconsulting.com
To:
What I'm wondering is; what can I put into the 'Xxx what to do if locked'
section whereby it waits until the record lock clears, once it clears, set my
own lock, read the record, alter the record, and then write the record (which
would release my lock)?
Thank you,
Jon Wells
A WRITE automatically clears the lock, a WRITEU will keep it. If you are inside
a transaction boundary however, then the lock is kept until the transaction is
committed or abandoned.
Regards
JayJay
On 7 Feb 2013, at 20:46, Jon Wells jwaytwe...@yahoo.com wrote:
What I'm wondering is; what
With the LOCKED clause included, the READU does not pause. You can put
anything you want in that section but just realize that the statement fully
executes and proceeds to the next command. If you want to simulate wait until
I obtain the lock then you just have to create this into a small
I think it would also be useful to add some form of exit routine inside the
LOCKWAIT loop.
Something like a counter to only allow say 10 attempts at trying to obtain the
lock.
That way you don't keep looping for ever if some other process which has the
lock does not release it for whatever
On 07/02/2013 20:46, Jon Wells wrote:
What I'm wondering is; what can I put into the 'Xxx what to do if locked'
section whereby it waits until the record lock clears, once it clears, set my
own lock, read the record, alter the record, and then write the record (which
would release my lock)?
You're exactly right. The only time you REALLY need the LOCKED clause
if there is some need to change that approach. That was what I
attempted to show in my first response. I guess I was a bit terse in
that one, though.
BobW
-Original Message-
From:
For a modern though totally undocumented alternative to !BPIOCP thy this...
The code ASSIGN 1 TO SYSTEM(1005) will enable pagination.
The code ASSIGN 0 TO SYSTEM(1005) will disable it.
I think this is documented on the U2UG.org wiki.
This email and any attachments to it are confidential.
You
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
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
+1. Well stated.
On Thursday, February 7, 2013, 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
Then you're misunderstanding what I'm saying.
-Original Message-
From: Kevin King ke...@precisonline.com
To: U2 Users List u2-users@listserver.u2ug.org
Sent: Thu, Feb 7, 2013 6:48 pm
Subject: Re: [U2] Record locks (Unidata 7.2)
+1. Well stated.
On Thursday, February 7, 2013,
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
19 matches
Mail list logo
