Hi all,
Very quick testing on my home machine, (Win2K and Universe PE) suggests
that if you pass the opened file pointer from the main to the cataloged
routine it works as you would expect. If however, you do the file open
within the subroutine it releases the lock when you return to the
It's interesting how one man's feature is another's bug... coming from a
Pick/AP/D3 background I was horrified to encounter this behaviour in Universe.
I am not convinced by the encapsulation argument here. If the lock is truly
local to the file variable then should a READU in the subroutine
Noel
The locks will be released when the file variable goes out of scope.
If the file variable is retained - either by passing it as an argument or using
named common - the lock will also be retained.
Regards
Brian
Hi all,
I am porting some code from D3 to Universe 10.1.11 on Windows (and
Thank you to all that responded.
Yes the file is being opened withing the subroutine and no, is not easy
to change it to open the file higher in the food chain. It seems that D3
scopes the lock table according to the user that created the lock (the
lock is released when they log off, if not
Hi Brett,
I would contend that a global RELEASE with just a file variable (or
worse none at all) is bad programming practice anyway...
Despite being the author of the previous email, I completely agree. Any well
designed program knows what locks it owns and can release them gracefully.
Responding to this part only:
Yes the file is being opened withing the subroutine and
no, is not easy to change it to open the file higher in the food
chain.
SUBROUTINE XYZ( ... )
COMMON /XYZ.ONLY/ XYZ.COMMON.INIT, FVAR
IF NOT( XYZ.COMMON.INIT ) THEN
OPEN 'whatever-file' TO
I'll second the suggestion to not use generic RELEASE statements and add
that if you do or may in the future use more than one data account to
add a path variable to your common and check if the current path is
different than the common path.
hth
Colin Alfke
Calgary Canada
-Original
Noel,
I use a generic readu subroutine most everywhere (it handles the locked
clause, sends msgs, retries, etc) and I don't have that problem:
.L RELLEVEL
RELLEVEL
001 X
002 10.1.4
003 PICK
004 PICK.FORMAT
005 10.1.4
Perhaps there is a uvconfig setting that affects it?
/Scott Ballinger
Hi Noel,
We have ported some programs from d3 to UniVerse.
What we found is that if your subroutine is re-opening the files with the
record locks, all records locks are released when the file is opened in your
subroutine. Please check to ensure that your subroutine is not reopening
the file
Noel wrote:
Hi all,
I am porting some code from D3 to Universe 10.1.11 on Windows (and then
to Linux 10.2.x)
I have a subroutine that does a READU on an item and leaves the lock set
when it returns to the calling the program (The calling program will
release the lock at a later stage).
I didnt see any response to this. Did I miss something?
john
On 5/10/07, Brutzman, Bill [EMAIL PROTECTED] wrote:
How do I rollback a U2 transaction?
Right now, all I know to do is to restore the entire data file from tape.
--Bill
---
u2-users mailing list
u2-users@listserver.u2ug.org
To
@listserver.u2ug.org
Subject: Re: [U2] Locks
I didnt see any response to this. Did I miss something?
john
On 5/10/07, Brutzman, Bill [EMAIL PROTECTED] wrote:
How do I rollback a U2 transaction?
Right now, all I know to do is to restore the entire data file from
tape.
--Bill
---
u2-users mailing
..or you could use transaction logging, but you'd have to have had it
already turned on running.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Brutzman, Bill
Sent: Friday, May 11, 2007 4:31 PM
To: 'u2-users@listserver.u2ug.org'
Subject: RE: [U2] Locks
How do I rollback a U2 transaction?
Right now, all I know to do is to restore the entire data file from tape.
--Bill
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
The order I use is to build the key by using a routine, then cut the
KEY record lock loose, followed by a RECORDLOCK on the transaction to
be written.
We do a similar function, and have not seen signficant wait times.
If you're already doing that, I'm not sure what could be occurring.
john
On
I inherited a bunch of problematic final commits. Per the following,
consider performing a Lock.And.Write as users change individual fields
within a record.
--Bill
*---
SUBROUTINE SUB.LOCK.AND.WRITE.R1 ( R.This,
Make sure that you do as little processing as possible within the actual
transaction so that the transaction is short and sweet.
Other than that, there is absolutely no way a lock should be released
before a transaction completes.
-Original Message-
REPOSTED FOR NON-MEMBER: Greg
PROTECTED] On Behalf Of Boydell, Stuart
Sent: Thursday, May 10, 2007 11:11 AM
To: u2-users@listserver.u2ug.org
Cc: [EMAIL PROTECTED]
Subject: RE: [U2] Locks in a transaction
Make sure that you do as little processing as possible within the actual
transaction so that the transaction is short and sweet
Think LIST.READU is what you are looking for. LIST.LOCKS only displays the
64 semaphore locks which I don't think are too common anymore.
Trick with LIST.READU was equating the file number to the proper data file
if you were doing it programmatically.
-Original Message-
From: [EMAIL
On Universe LIST.LOCKS shows task locks (i.e. LOCK 5 in UVBASIC )- I
have to use LIST.READU EVERY to get readu locks. Does UniData have a
LIST.READU command?
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Susan Joslyn
Sent: Thursday, April 14, 2005
Subject
RE: [U2] Locks, releases and
04/14/2005 09:47 STATU() (oh my)
AM
Please respond to
u2-users
Think LIST.READU is what you
Susan,
I think what you're looking for is LIST.READU and / or LIST.READU DETAIL.
HTH
Mark
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Susan Joslyn
Sent: Thursday, April 14, 2005 7:33 AM
To: u2-users@listserver.u2ug.org
Subject: [U2] Locks,
LIST.READU DETAIL
[EMAIL PROTECTED] 4/14/05 10:47:31 AM
Think LIST.READU is what you are looking for. LIST.LOCKS only displays the
64 semaphore locks which I don't think are too common anymore.
Trick with LIST.READU was equating the file number to the proper data file
if you were doing it
Like Mike said, you want to use LIST.READU (or LIST.QUEUE) to see the
locks. However, UniData, unlike UniVerse does have the file name and not
just the number.
The Status() after a readu gives you the UID (pid) of the process that
has the record locked. You can parse it out of the array returned
Ooops, I thing I forgot to mention. On some versions of UniData (5.2.4?)
doing a /TCL in SB+ will cause UniData to not output information with
LIST.READU. I don't recall if there is also a problem with GETREADU() -
plus it's already in an array so you don't have to trim and parse
(truncated) data
Subject: Re: [U2] Locks, releases and STATU() (oh my)
Is that DETAIL keyword for LIST.READU just for Unidata? Doesn't seem
to
work on Universe.
-Dianne
Wally Terhune wrote:
other resources include:
LIST.QUEUE and related GETQUEUE() UniBasic function - both show users
queued up for a lock
That sounds a little bizarre. Do you recall any details of why this
might have been so?
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Alfke, Colin
Sent: Thursday, April 14, 2005 10:06 AM
To: u2-users@listserver.u2ug.org
Subject: RE: [U2] Locks
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] Locks, releases and STATU() (oh my)
Is that DETAIL keyword for LIST.READU just for Unidata? Doesn't seem
to
work on Universe.
-Dianne
Wally Terhune wrote:
other resources include:
LIST.QUEUE and related GETQUEUE() UniBasic
28 matches
Mail list logo
