Re: [U2] Locks in subroutines

2007-10-09 Thread Martin Phillips
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

Re: [U2] Locks in subroutines

2007-10-09 Thread Brett Callacher
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

RE: [U2] Locks in subroutines

2007-10-09 Thread Brian Leach
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

Re: [U2] Locks in subroutines

2007-10-09 Thread Noel
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

Re: [U2] Locks in subroutines

2007-10-09 Thread Martin Phillips
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.

RE: [U2] Locks in subroutines

2007-10-09 Thread Stevenson, Charles
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

RE: [U2] Locks in subroutines

2007-10-09 Thread colin.alfke
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

[U2] Locks in subroutines

2007-10-08 Thread Noel
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). However,

Re: [U2] Locks in subroutines

2007-10-08 Thread Scott Ballinger
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

RE: [U2] Locks in subroutines

2007-10-08 Thread Bernard Lubin
@listserver.u2ug.org Subject: [U2] Locks in subroutines 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

Re: [U2] Locks in subroutines

2007-10-08 Thread Allen Egerton
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).