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 > [email protected] > To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
