RE: [U2] Locks in subroutines
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 Message- From: 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 FVAR ELSE ... Abort ? ... XYZ.COMMON.INIT = @TRUE END READU rec FROM FVAR, 'some-id' ELSE ... RETURN ;* readu lock ON whatever-file some-id is retained ;* and file remains open in /XYZ.ONLY/ common. END The calling program can later release that lock via: OPEN 'whatever-file' TO LOCAL.FVAR ... RELEASE LOCAL.FVAR, 'some-id' BUT !!!NOT!!! By this: OPEN 'whatever-file' TO LOCAL.FVAR ... RELEASE LOCAL.FVAR Yet these 2, within the calling program, WILL cause the record lock on 'some-id' to be released: RELEASE Or: STOP I'm just describing what IS (10.0.16), not whether good or bad. cds --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Locks in subroutines
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 FVAR ELSE ... Abort ? ... XYZ.COMMON.INIT = @TRUE END READU rec FROM FVAR, 'some-id' ELSE ... RETURN ;* readu lock ON whatever-file some-id is retained ;* and file remains open in /XYZ.ONLY/ common. END The calling program can later release that lock via: OPEN 'whatever-file' TO LOCAL.FVAR ... RELEASE LOCAL.FVAR, 'some-id' BUT !!!NOT!!! By this: OPEN 'whatever-file' TO LOCAL.FVAR ... RELEASE LOCAL.FVAR Yet these 2, within the calling program, WILL cause the record lock on 'some-id' to be released: RELEASE Or: STOP I'm just describing what IS (10.0.16), not whether good or bad. cds --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Locks in subroutines
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. Martin Phillips Ladybridge Systems Ltd 17b Coldstream Lane, Hardingstone, Northampton, NN4 6DB +44-(0)1604-709200 --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Locks in subroutines
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 explicitly released beforehand), whereas Universe scopes the lock at the life of the file variable used (as Brian and others suggested). Just another issue to work around when porting code from AP/D3. This piece of code was an add-on for a tacked-on extension to a system many years ago by persons unknown. It may be easier to open most of the files in the system at logon time and put them in a named common. Cheers, Noel 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). However, Universe is releasing the lock when it returns from subroutine. Is this a known feature and is there an option to turn off this behaviour? Cheers, Noel --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Locks in subroutines
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 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, Universe is releasing the lock when it returns from subroutine. Is this a known feature and is there an option to turn off this behaviour? Cheers, Noel --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Locks in subroutines
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 be respected by other instances elsewhere? Of course it should and so should the release. I would contend that a global RELEASE with just a file variable (or worse none at all) is bad programming practice anyway... My tuppence. Brett "Martin Phillips" <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... > 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 calling > > program. > > > > -- > > Allen Egerton > > > Although most programmers think of the lock as being related to the file, it > is actually related to a particular instance of opening the file via the > associated file variable. The behaviour described by Allen above is what you > should expect. > > This is an essential feature of the language. If I open a file in a > subroutine and either explicitly release all my locks using the variant of > RELEASE with only a file variable or I simply close the file while I have > locks in place, this should not (must not) affect other parts of my > application that may have locks in the same file. > > This all comes down to the programming theory concept of "encapsulation" > where one part of an application should not need to know anything about what > it happening elsewhere. > > Note that if I copy the file variable, these are both references to the same > file instance and locks are "shared" between the two file variables. > > > Martin Phillips > Ladybridge Systems Ltd > 17b Coldstream Lane, Hardingstone, Northampton, NN4 6DB > +44-(0)1604-709200 > --- > u2-users mailing list > u2-users@listserver.u2ug.org > To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Locks in subroutines
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 calling program. -- Allen Egerton Although most programmers think of the lock as being related to the file, it is actually related to a particular instance of opening the file via the associated file variable. The behaviour described by Allen above is what you should expect. This is an essential feature of the language. If I open a file in a subroutine and either explicitly release all my locks using the variant of RELEASE with only a file variable or I simply close the file while I have locks in place, this should not (must not) affect other parts of my application that may have locks in the same file. This all comes down to the programming theory concept of "encapsulation" where one part of an application should not need to know anything about what it happening elsewhere. Note that if I copy the file variable, these are both references to the same file instance and locks are "shared" between the two file variables. Martin Phillips Ladybridge Systems Ltd 17b Coldstream Lane, Hardingstone, Northampton, NN4 6DB +44-(0)1604-709200 --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Locks in subroutines
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). However, Universe is releasing the lock when it returns from subroutine. Is this a known feature and is there an option to turn off this behaviour? 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 calling program. -- Allen Egerton aegerton at pobox dot com --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Locks in subroutines
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 concerned. We also found that if you "EXECUTE" another program and locks the same item in your executed program, the lock will be released when the executed program is terminated. I just did a quick test of your scenario and got the same results that you experienced. However, if I have the file variable defined in either a labelled or unlabelled common, the lock stays. Rgds Bernard Lubin Development Department Reynolds and Reynolds -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Noel Sent: Tuesday, 9 October 2007 9:02 AM To: u2-users@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 the lock at a later stage). However, Universe is releasing the lock when it returns from subroutine. Is this a known feature and is there an option to turn off this behaviour? Cheers, Noel --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Locks in subroutines
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 Pareto Corporation Edmonds WA USA 206 713 6006 --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
[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 the lock at a later stage). However, Universe is releasing the lock when it returns from subroutine. Is this a known feature and is there an option to turn off this behaviour? Cheers, Noel --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
