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 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

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 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

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 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

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 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

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.



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

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 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

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 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

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
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/


RE: [U2] Locks in subroutines

2007-10-08 Thread Bernard Lubin
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

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). 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

2007-05-11 Thread john reid

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 unsubscribe please visit http://listserver.u2ug.org/




--
john
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/


RE: [U2] Locks

2007-05-11 Thread Brutzman, Bill
I suppose that it was a rhetorical tease question.

Roll-back functionality could be (brute force) built into a U2 application.

--Bill  


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of john reid
Sent: Friday, May 11, 2007 3:04 PM
To: u2-users@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 list
 u2-users@listserver.u2ug.org
 To unsubscribe please visit http://listserver.u2ug.org/



-- 
john
---
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

2007-05-11 Thread Dan Fitzgerald
..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

I suppose that it was a rhetorical tease question.

Roll-back functionality could be (brute force) built into a U2 application.

--Bill  


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of john reid
Sent: Friday, May 11, 2007 3:04 PM
To: u2-users@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 list
 u2-users@listserver.u2ug.org
 To unsubscribe please visit http://listserver.u2ug.org/



-- 
john
---
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/
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/


RE: [U2] Locks

2007-05-10 Thread Brutzman, Bill
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/


Re: [U2] Locks in a transaction

2007-05-09 Thread john reid

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 5/9/07, Moderator [EMAIL PROTECTED] wrote:

REPOSTED FOR NON-MEMBER: Greg Livingston [EMAIL PROTECTED]

I have a routine that runs in a transaction. Within the transaction I call a 
routine that generates the next sequential number for the record key.  The 
problem I'm having is that one of my customer records has so many transaction 
to process that it holds the lock on the key generation program and my other 
users then hang as they are waiting for the record to unlock.  Does anyone know 
a way of releasing the lock on a record with in a transaction before the final 
commit?
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/




--
john
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/


RE: [U2] Locks in a transaction

2007-05-09 Thread Brutzman, Bill
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, This.File, Record.ID )

  prompt ''

  open This.File to F.This.File  else  gosub  Error.Opening.File

  gosub Lock.And.Write
  goThe.End

*---
--
*---
--
Lock.And.Write:

  Lock.Test = recordlocked (F.This.File, Record.ID) 

  begin case
case Lock.Test =  0   ;recordlocku F.This.File,
Record.ID   
  write R.This  on F.This.File,
Record.ID 
   release F.This.File,
Record.ID

case 1;  gosub Error.Record.Locking 
  end   case

return

*---
---
Error.Opening.File:

  crt @(-1)
  crt @(-5)

  crt
  crt
  crt
  crt
  crt
  crt
  crt
  crt
  crt
  crt
  crt
  crt '  Big Problem...' : @(-6)
  crt
  crt ' _  '
  crt ' \\  ' : This.File
  crt '  \   Error Opening File   \'
  crt '   \\Contact HK.IT  '
  crt '   [X]  ' 
  crt ''   :

  input Ans, 1
Ans  = upcase(Ans)

  begin case
case Ans = 'X'  ;  null
case 1  ;  go Error.Opening.File   
  end   case
  
return to The.End

*---
---
Error.Record.Locking:

  crt @(-1)
  crt @(-5)

  crt
  crt
  crt
  crt
  crt
  crt
  crt
  crt
  crt
  crt '  Big Problem...' : @(-6)
  crt
  crt ' _  '
  crt ' \\  ' : This.File
  crt '  \   Error, Record Lock   \'
  crt '   \\Contact HK.IT  '
  crt 
  crt ' Open New Gull Session, Try UNLOCK.ME
'   
  crt '
[X]  ' 
  crt '
'   :

  input Ans, 1
Ans  = upcase(Ans)

  begin case
case Ans = 'X'  ;  null
case 1  ;  go Error.Record.Locking
  end   case
  
return to The.End

*---
---
The.End:

  RETURN
  END

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Moderator
Sent: Wednesday, May 09, 2007 6:10 AM
To: u2-users@listserver.u2ug.org
Subject: [U2] Locks in a transaction


REPOSTED FOR NON-MEMBER: Greg Livingston [EMAIL PROTECTED]

I have a routine that runs in a transaction. Within the transaction I call a
routine that generates the next sequential number for the record key.  The
problem I'm having is that one of my customer records has so many
transaction to process that it holds the lock on the key generation program
and my other users then hang as they are waiting for the record to unlock.
Does anyone know a way of releasing the lock on a record with in a
transaction before the final commit?
---
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 a transaction

2007-05-09 Thread Boydell, Stuart
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 Livingston [EMAIL PROTECTED]



I have a routine that runs in a transaction. Within the transaction I
call a routine that

generates the next sequential number for the record key.  The problem
I'm having is

that one of my customer records has so many transaction to process that
it holds the

lock on the key generation program and my other users then hang as they
are waiting

for the record to unlock.  Does anyone know a way of releasing the lock
on a record

with in a transaction before the final commit?



**
This email message and any files transmitted with it are confidential and
intended solely for the use of addressed recipient(s). If you have received
this communication in error, please reply to this e-mail to notify the sender
of its incorrect delivery and then delete it and your reply.  It is your
responsibility to check this email and any attachments for viruses and defects
before opening or sending them on. Spotless collects information about you to
provide and market our services. For information about use, disclosure and
access, see our privacy policy at http://www.spotless.com.au
Please consider our environment before printing this email.
**
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/


RE: [U2] Locks in a transaction

2007-05-09 Thread Hona, David S
It would defeat the entire purpose of a transactions to allow a lock to
be released during a transaction. 

Specifically, as the purpose is keep all related updates within the same
transaction. 

If this next key update function does not need or *should* not to be
rolled back, then this shouldn't be part of the transaction at all. I'm
guessing a rollback of this key would cause serious implications. :-)

As Stuart suggests...a redesign of update process to make the
transaction smaller maybe your only course of action.


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL 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.

Other than that, there is absolutely no way a lock should be released
before a transaction completes.
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/


RE: [U2] Locks, releases and STATU() (oh my)

2005-04-14 Thread Mike Randall
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 PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Susan Joslyn
Sent: Thursday, April 14, 2005 10:33 AM
To: u2-users@listserver.u2ug.org
Subject: [U2] Locks, releases and STATU() (oh my)

Hello wizards,

I've read what I can find on the subject, but I'm not finding what I need.
As usual, anyone who knows where the info is, I would not be the least bit
offended if you just point.  Or if you know off-hand ...

(Presently grappling with Unidata):

When I hit a lock with a:
READU this FROM that,ID LOCKED locked clause ELSE whatever 

LIST.LOCKS from TCL has always been worse than useless for me.  For example
at this exact moment I'm holding locks on 3 sessions, yet if I run
LIST.LOCKS on a 4th session it displays ABSOLUTELY NOTHING.  

I don't see much on offer in the LOCKED clause, although the online help
suggests that STATUS() will return the user number of the lock it ran into.
Can't understand its output... I have a very short program that displays
STATUS(), opens the file and displays STATUS() then does a READU against an
item I purposefully have locked on another session and I display STATUS()  a
third time.  What do you suppose its giving me, and what can I do with it?

1 STATUS = 0 -- beginning of program
2 STATUS = 1 -- after the open
3 STATUS = 197613 -- this is what it gives me after the READU against a
locked item

What I want to do is determine who/what has the lock, tell the user, I also
want to be able to carry on under my own conditions when ud 46 flag is set
which will by default allow edits to items I've locked against my own
session.  Which is too loose -- I want to check to make sure I'm in the
exact right condition to do that and I'm not sure how I can (by seeing what
is holding the lock) but ... does anyone know how to get ANY information out
of a lock?

Susan
---
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, releases and STATU() (oh my)

2005-04-14 Thread Lance Jahnke
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 10:33 AM
To: u2-users@listserver.u2ug.org
Subject: [U2] Locks, releases and STATU() (oh my)

Hello wizards,

I've read what I can find on the subject, but I'm not finding what I
need.
As usual, anyone who knows where the info is, I would not be the least
bit
offended if you just point.  Or if you know off-hand ...

(Presently grappling with Unidata):

When I hit a lock with a:
READU this FROM that,ID LOCKED locked clause ELSE whatever 

LIST.LOCKS from TCL has always been worse than useless for me.  For
example
at this exact moment I'm holding locks on 3 sessions, yet if I run
LIST.LOCKS on a 4th session it displays ABSOLUTELY NOTHING.  

I don't see much on offer in the LOCKED clause, although the online help
suggests that STATUS() will return the user number of the lock it ran
into.
Can't understand its output... I have a very short program that displays
STATUS(), opens the file and displays STATUS() then does a READU against
an
item I purposefully have locked on another session and I display
STATUS()  a
third time.  What do you suppose its giving me, and what can I do with
it?

1 STATUS = 0 -- beginning of program
2 STATUS = 1 -- after the open
3 STATUS = 197613 -- this is what it gives me after the READU against a
locked item

What I want to do is determine who/what has the lock, tell the user, I
also
want to be able to carry on under my own conditions when ud 46 flag is
set
which will by default allow edits to items I've locked against my own
session.  Which is too loose -- I want to check to make sure I'm in the
exact right condition to do that and I'm not sure how I can (by seeing
what
is holding the lock) but ... does anyone know how to get ANY information
out
of a lock?

Susan
---
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, releases and STATU() (oh my)

2005-04-14 Thread Wally Terhune
other resources include:
LIST.QUEUE and related GETQUEUE() UniBasic function - both show users
queued up for a lock (those users would not be using the LOCKED clause).
LIST.READU (noted) and GETREADU() function.
Don't forget the DETAIL keyword on LIST.READU and LIST.QUEUE to show full
data - not truncated to fit in 80 column display.

Wally Terhune
Manager - U2 Advanced Technical Services
IBM Information Management Solutions
Tel: 303.294.4866 Fax: 303.294.4832
[EMAIL PROTECTED]

www.ibm.com/software/data/u2/support - Open, Query, Update, Search -
Online!



 Mike Randall
 [EMAIL PROTECTED]
 cast.net  To
 Sent by:  u2-users@listserver.u2ug.org
 [EMAIL PROTECTED]  cc
 stserver.u2ug.org
   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 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 PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Susan Joslyn
Sent: Thursday, April 14, 2005 10:33 AM
To: u2-users@listserver.u2ug.org
Subject: [U2] Locks, releases and STATU() (oh my)

Hello wizards,

I've read what I can find on the subject, but I'm not finding what I need.
As usual, anyone who knows where the info is, I would not be the least bit
offended if you just point.  Or if you know off-hand ...

(Presently grappling with Unidata):

When I hit a lock with a:
READU this FROM that,ID LOCKED locked clause ELSE whatever

LIST.LOCKS from TCL has always been worse than useless for me.  For example
at this exact moment I'm holding locks on 3 sessions, yet if I run
LIST.LOCKS on a 4th session it displays ABSOLUTELY NOTHING.

I don't see much on offer in the LOCKED clause, although the online help
suggests that STATUS() will return the user number of the lock it ran into.
Can't understand its output... I have a very short program that displays
STATUS(), opens the file and displays STATUS() then does a READU against an
item I purposefully have locked on another session and I display STATUS()
a
third time.  What do you suppose its giving me, and what can I do with it?

1 STATUS = 0 -- beginning of program
2 STATUS = 1 -- after the open
3 STATUS = 197613 -- this is what it gives me after the READU against a
locked item

What I want to do is determine who/what has the lock, tell the user, I also
want to be able to carry on under my own conditions when ud 46 flag is set
which will by default allow edits to items I've locked against my own
session.  Which is too loose -- I want to check to make sure I'm in the
exact right condition to do that and I'm not sure how I can (by seeing what
is holding the lock) but ... does anyone know how to get ANY information
out
of a lock?

Susan
---
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/

[demime 1.01d removed an attachment of type image/gif which had a name of 
graycol.gif]

[demime 1.01d removed an attachment of type image/gif which had a name of 
pic05147.gif]

[demime 1.01d removed an attachment of type image/gif which had a name of 
ecblank.gif]
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/


RE: [U2] Locks, releases and STATU() (oh my)

2005-04-14 Thread Mark Olarte
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, releases and STATU() (oh my)
 
 What I want to do is determine who/what has the lock, tell 
 the user, I also
 want to be able to carry on under my own conditions when ud 
 46 flag is set
 which will by default allow edits to items I've locked against my own
 session.  Which is too loose -- I want to check to make sure 
 I'm in the
 exact right condition to do that and I'm not sure how I can 
 (by seeing what
 is holding the lock) but ... does anyone know how to get ANY 
 information out
 of a lock?
 
 Susan
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/


RE: [U2] Locks, releases and STATU() (oh my)

2005-04-14 Thread John Cassidy
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 programmatically.


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Susan Joslyn
Sent: Thursday, April 14, 2005 10:33 AM
To: u2-users@listserver.u2ug.org
Subject: [U2] Locks, releases and STATU() (oh my)

Hello wizards,

I've read what I can find on the subject, but I'm not finding what I need.
As usual, anyone who knows where the info is, I would not be the least bit
offended if you just point.  Or if you know off-hand ...

(Presently grappling with Unidata):

When I hit a lock with a:
READU this FROM that,ID LOCKED locked clause ELSE whatever

LIST.LOCKS from TCL has always been worse than useless for me.  For example
at this exact moment I'm holding locks on 3 sessions, yet if I run
LIST.LOCKS on a 4th session it displays ABSOLUTELY NOTHING.

I don't see much on offer in the LOCKED clause, although the online help
suggests that STATUS() will return the user number of the lock it ran into.
Can't understand its output... I have a very short program that displays
STATUS(), opens the file and displays STATUS() then does a READU against an
item I purposefully have locked on another session and I display STATUS()  a
third time.  What do you suppose its giving me, and what can I do with it?

1 STATUS = 0 -- beginning of program
2 STATUS = 1 -- after the open
3 STATUS = 197613 -- this is what it gives me after the READU against a
locked item

What I want to do is determine who/what has the lock, tell the user, I also
want to be able to carry on under my own conditions when ud 46 flag is set
which will by default allow edits to items I've locked against my own
session.  Which is too loose -- I want to check to make sure I'm in the
exact right condition to do that and I'm not sure how I can (by seeing what
is holding the lock) but ... does anyone know how to get ANY information out
of a lock?

Susan
---
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/
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/


RE: [U2] Locks, releases and STATU() (oh my)

2005-04-14 Thread Alfke, Colin
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 with
GETREADU(). This is like capturing the LIST.READU output. You can get
the user

You may also find RECORDLOCKED handy.

The TCL HELP should give you what you need for these.

Hth
Colin Alfke
Calgary - I can't believe it snowed this morning - Canada

-Original Message-
From: Susan Joslyn

Hello wizards,

I've read what I can find on the subject, but I'm not finding 
what I need.
As usual, anyone who knows where the info is, I would not be 
the least bit offended if you just point.  Or if you know off-hand ...

(Presently grappling with Unidata):

When I hit a lock with a:
READU this FROM that,ID LOCKED locked clause ELSE whatever 

LIST.LOCKS from TCL has always been worse than useless for me. 
 For example at this exact moment I'm holding locks on 3 
sessions, yet if I run LIST.LOCKS on a 4th session it displays 
ABSOLUTELY NOTHING.  

I don't see much on offer in the LOCKED clause, although the 
online help suggests that STATUS() will return the user number 
of the lock it ran into.
Can't understand its output... I have a very short program 
that displays STATUS(), opens the file and displays STATUS() 
then does a READU against an item I purposefully have locked 
on another session and I display STATUS()  a third time.  What 
do you suppose its giving me, and what can I do with it?

1 STATUS = 0 -- beginning of program
2 STATUS = 1 -- after the open
3 STATUS = 197613 -- this is what it gives me after the READU 
against a locked item

What I want to do is determine who/what has the lock, tell the 
user, I also want to be able to carry on under my own 
conditions when ud 46 flag is set which will by default allow 
edits to items I've locked against my own session.  Which is 
too loose -- I want to check to make sure I'm in the exact 
right condition to do that and I'm not sure how I can (by 
seeing what is holding the lock) but ... does anyone know how 
to get ANY information out of a lock?

Susan
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/


RE: [U2] Locks, releases and STATU() (oh my)

2005-04-14 Thread Alfke, Colin
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 (unless you use the DETAIL modifier)..

This was corrected in 6.0.2.

Hth
Colin Alfke
Calgary, Canada 

-Original Message-
From: Kevin King

The 197613 is the ID of the user session.  The trick is to 
translate this to a user ID.  SB+ appears to be doing this 
with the SB.DISP.LOCK routine, though I'm not certain how 
they're doing that translation.

Oh, here's a thought.  From BASIC, EXECUTE a LIST.READU, 
capture the output, and then trim each line of the response.  
Once a line is trimmed, field out the process ID in the third 
position; if it's the process ID returned by STATUS() then get 
the port number from the first position.  You could then use 
that to read the $PASSport record which will tell you who is 
logged in on that port (in 7) and a whole bunch of other stuff.

-Kevin
[EMAIL PROTECTED]
http://www.PrecisOnline.com
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/


RE: [U2] Locks, releases and STATU() (oh my)

2005-04-14 Thread Bob Woodward
LIST.READU DETAIL works in our 10.1 version of Universe.  What version
are you on, Dianne?

Bob W


 -Original Message-
 From: [EMAIL PROTECTED] [mailto:owner-u2-
 [EMAIL PROTECTED] On Behalf Of Dianne Ackerman
 Sent: Thursday, April 14, 2005 10:25 AM
 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 function - both show users
 queued up for a lock (those users would not be using the LOCKED
clause).
 LIST.READU (noted) and GETREADU() function.
 Don't forget the DETAIL keyword on LIST.READU and LIST.QUEUE to show
full
 data - not truncated to fit in 80 column display.
 
 Wally Terhune
 Manager - U2 Advanced Technical Services
 IBM Information Management Solutions
 Tel: 303.294.4866 Fax: 303.294.4832
 [EMAIL PROTECTED]
 
 www.ibm.com/software/data/u2/support - Open, Query, Update, Search -
 Online!
 
 
 
  Mike Randall
  [EMAIL PROTECTED]
  cast.net
 To
  Sent by:  u2-users@listserver.u2ug.org
  [EMAIL PROTECTED]
 cc
  stserver.u2ug.org
 
 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 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 PROTECTED]
 [mailto:[EMAIL PROTECTED] On Behalf Of Susan Joslyn
 Sent: Thursday, April 14, 2005 10:33 AM
 To: u2-users@listserver.u2ug.org
 Subject: [U2] Locks, releases and STATU() (oh my)
 
 Hello wizards,
 
 I've read what I can find on the subject, but I'm not finding what I
 need.
 As usual, anyone who knows where the info is, I would not be the
least
 bit
 offended if you just point.  Or if you know off-hand ...
 
 (Presently grappling with Unidata):
 
 When I hit a lock with a:
 READU this FROM that,ID LOCKED locked clause ELSE whatever
 
 LIST.LOCKS from TCL has always been worse than useless for me.  For
 example
 at this exact moment I'm holding locks on 3 sessions, yet if I run
 LIST.LOCKS on a 4th session it displays ABSOLUTELY NOTHING.
 
 I don't see much on offer in the LOCKED clause, although the online
help
 suggests that STATUS() will return the user number of the lock it ran
 into.
 Can't understand its output... I have a very short program that
displays
 STATUS(), opens the file and displays STATUS() then does a READU
against
 an
 item I purposefully have locked on another session and I display
STATUS()
 a
 third time.  What do you suppose its giving me, and what can I do
with
 it?
 
 1 STATUS = 0 -- beginning of program
 2 STATUS = 1 -- after the open
 3 STATUS = 197613 -- this is what it gives me after the READU
against a
 locked item
 
 What I want to do is determine who/what has the lock, tell the user,
I
 also
 want to be able to carry on under my own conditions when ud 46 flag
is
 set
 which will by default allow edits to items I've locked against my own
 session.  Which is too loose -- I want to check to make sure I'm in
the
 exact right condition to do that and I'm not sure how I can (by
seeing
 what
 is holding the lock) but ... does anyone know how to get ANY
information
 out
 of a lock?
 
 Susan
 --
 ---
 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, releases and STATU() (oh my)

2005-04-14 Thread Kevin King
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, releases and STATU() (oh my)

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 (unless you use the DETAIL modifier)..

This was corrected in 6.0.2.

Hth
Colin Alfke
Calgary, Canada 

-Original Message-
From: Kevin King

The 197613 is the ID of the user session.  The trick is to translate 
this to a user ID.  SB+ appears to be doing this with the
SB.DISP.LOCK 
routine, though I'm not certain how they're doing that translation.

Oh, here's a thought.  From BASIC, EXECUTE a LIST.READU, capture the 
output, and then trim each line of the response.
Once a line is trimmed, field out the process ID in the third
position; 
if it's the process ID returned by STATUS() then get the port number 
from the first position.  You could then use that to read the
$PASSport 
record which will tell you who is logged in on that port (in 7) and
a 
whole bunch of other stuff.

-Kevin
[EMAIL PROTECTED]
http://www.PrecisOnline.com
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/


--
No virus found in this incoming message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.9.10 - Release Date: 4/14/2005
 

-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.9.10 - Release Date: 4/14/2005
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/


Re: [U2] Locks, releases and STATU() (oh my)

2005-04-14 Thread Dianne Ackerman
I'm on 9.6.1.4

Bob Woodward wrote:

LIST.READU DETAIL works in our 10.1 version of Universe.  What version
are you on, Dianne?

Bob W


  

-Original Message-
From: [EMAIL PROTECTED] [mailto:owner-u2-
[EMAIL PROTECTED] On Behalf Of Dianne Ackerman
Sent: Thursday, April 14, 2005 10:25 AM
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 function - both show users
queued up for a lock (those users would not be using the LOCKED
  

clause).
  

LIST.READU (noted) and GETREADU() function.
Don't forget the DETAIL keyword on LIST.READU and LIST.QUEUE to show
  

full
  

data - not truncated to fit in 80 column display.

Wally Terhune
Manager - U2 Advanced Technical Services
IBM Information Management Solutions
Tel: 303.294.4866 Fax: 303.294.4832
[EMAIL PROTECTED]

www.ibm.com/software/data/u2/support - Open, Query, Update, Search -
Online!



Mike Randall
[EMAIL PROTECTED]
cast.net
  

To


Sent by:  u2-users@listserver.u2ug.org
[EMAIL PROTECTED]
  

cc


stserver.u2ug.org

  

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 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 PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Susan Joslyn
Sent: Thursday, April 14, 2005 10:33 AM
To: u2-users@listserver.u2ug.org
Subject: [U2] Locks, releases and STATU() (oh my)

Hello wizards,

I've read what I can find on the subject, but I'm not finding what I
  

need.


As usual, anyone who knows where the info is, I would not be the
  

least
  

bit


offended if you just point.  Or if you know off-hand ...

(Presently grappling with Unidata):

When I hit a lock with a:
READU this FROM that,ID LOCKED locked clause ELSE whatever

LIST.LOCKS from TCL has always been worse than useless for me.  For
  

example


at this exact moment I'm holding locks on 3 sessions, yet if I run
LIST.LOCKS on a 4th session it displays ABSOLUTELY NOTHING.

I don't see much on offer in the LOCKED clause, although the online
  

help
  

suggests that STATUS() will return the user number of the lock it ran
  

into.


Can't understand its output... I have a very short program that
  

displays
  

STATUS(), opens the file and displays STATUS() then does a READU
  

against
  

an


item I purposefully have locked on another session and I display
  

STATUS()
  

a
third time.  What do you suppose its giving me, and what can I do
  

with
  

it?


1 STATUS = 0 -- beginning of program
2 STATUS = 1 -- after the open
3 STATUS = 197613 -- this is what it gives me after the READU
  

against a
  

locked item

What I want to do is determine who/what has the lock, tell the user,
  

I
  

also


want to be able to carry on under my own conditions when ud 46 flag
  

is
  

set


which will by default allow edits to items I've locked against my own
session.  Which is too loose -- I want to check to make sure I'm in
  

the
  

exact right condition to do that and I'm not sure how I can (by
  

seeing
  

what


is holding the lock) but ... does anyone know how to get ANY
  

information
  

out
of a lock?

Susan
--
  

---
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/