subject:"Re\: \[U2\] Lock Status"

I don't see anything in the LIST.QUEUE output, but I can see how that would be 
useful.

If you have control of the source code for all of the file i/o operations you 
could write your own wrapper routines for the commands that set record locks, 
get the information from SYSTEM(49) (the program stack), and write it to a file 
somewhere, keyed by file name and record key.

-Original Message-
From: u2-users-boun...@listserver.u2ug.org 
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Kevin King
Sent: Thursday, September 08, 2011 11:06 AM
To: U2 Users List
Subject: [U2] Lock Status

Is there anything in Unidata that would report the line of code that set a
particular record lock?

-Kevin
http://www.PrecisOnline.com
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
html
body
 Dave Davis Team Lead, Ramp;D P: 614-875-4910 
x108 F: 614-875-4088 E: dda...@harriscomputer.com 
[http://www.harriscomputer.com/images/signatures/HarrisSchools.gif] 
[http://www.harriscomputer.com/images/signatures/DivisionofHarris.gif]
 6110 Enterprise Parkway Grove City, OH 43123 www.harris-schoolsolutions.com 
This message is intended exclusively for the individual or entity to which it 
is addressed. This communication may contain information that is proprietary, 
privileged or confidential
 or otherwise legally exempt from disclosure. If you are not the named 
addressee, you are not authorized to read, print, retain, copy or disseminate 
this message or any part of it. If you have received this message in error, 
please notify the sender immediately
 by e-mail and delete all copies of the message.
/body
/html
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] Lock Status

That's useful for determining where that port is, but we have a process
leaving rogue locks lying around.  Anything that tells what updated the lock
table?

On Thu, Sep 8, 2011 at 9:10 AM, Daniel McGrath
dmcgr...@rocketsoftware.comwrote:

 Once you know the pid of the program with the lock, you can use PORT.STATUS
 to determine this. You just need to use the CALL.STACK option. IIRC (It's
 been a few months) it would be like:

 PORT.STATUS PID the progs pid here CALL.STACK

 Regards,
 Dan

 -Original Message-
 From: u2-users-boun...@listserver.u2ug.org [mailto:
 u2-users-boun...@listserver.u2ug.org] On Behalf Of Kevin King
 Sent: Thursday, September 08, 2011 9:06 AM
 To: U2 Users List
 Subject: [U2] Lock Status

 Is there anything in Unidata that would report the line of code that set a
 particular record lock?

 -Kevin
 http://www.PrecisOnline.com
 ___
 U2-Users mailing list
 U2-Users@listserver.u2ug.org
 http://listserver.u2ug.org/mailman/listinfo/u2-users
 ___
 U2-Users mailing list
 U2-Users@listserver.u2ug.org
 http://listserver.u2ug.org/mailman/listinfo/u2-users




-- 
-Kevin
http://www.PrecisOnline.com
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] Lock Status

Dave: Two Words: Vendor App.  Good idea, but not possible in this case.
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] Lock Status

2011-09-08 Thread John Thompson

This is probably no help...

In Universe there is a LIST.READU EVERY.

That will show every lock in the system.  Maybe if Unidata has an
equivalent, you can get some useful info there...



On Thu, Sep 8, 2011 at 11:15 AM, Kevin King precisonl...@gmail.com wrote:

 That's useful for determining where that port is, but we have a process
 leaving rogue locks lying around.  Anything that tells what updated the
 lock
 table?

 On Thu, Sep 8, 2011 at 9:10 AM, Daniel McGrath
 dmcgr...@rocketsoftware.comwrote:

  Once you know the pid of the program with the lock, you can use
 PORT.STATUS
  to determine this. You just need to use the CALL.STACK option. IIRC (It's
  been a few months) it would be like:
 
  PORT.STATUS PID the progs pid here CALL.STACK
 
  Regards,
  Dan
 
  -Original Message-
  From: u2-users-boun...@listserver.u2ug.org [mailto:
  u2-users-boun...@listserver.u2ug.org] On Behalf Of Kevin King
  Sent: Thursday, September 08, 2011 9:06 AM
  To: U2 Users List
  Subject: [U2] Lock Status
 
  Is there anything in Unidata that would report the line of code that set
 a
  particular record lock?
 
  -Kevin
  http://www.PrecisOnline.com
  ___
  U2-Users mailing list
  U2-Users@listserver.u2ug.org
  http://listserver.u2ug.org/mailman/listinfo/u2-users
  ___
  U2-Users mailing list
  U2-Users@listserver.u2ug.org
  http://listserver.u2ug.org/mailman/listinfo/u2-users
 



 --
 -Kevin
 http://www.PrecisOnline.com
 ___
 U2-Users mailing list
 U2-Users@listserver.u2ug.org
 http://listserver.u2ug.org/mailman/listinfo/u2-users




-- 
John Thompson
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] Lock Status

Unfortunately, no love there either John.  I even went to the GETREADU( .. )
function in BASIC.. nothing there.
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] Lock Status

2011-09-08 Thread Daniel McGrath

LIST.READU will tell you what program owns the lock (as long as the program is 
still running). The UNO column is the UniData Number, which will relate to a 
user/process in the PORT.STATUS (no options) command's list.

Aside from that, I don't know if you can catch the actual line number unless 
you catch the program in the act when it does it with PORT.STATUS CALL.STACK.

You know roughly what file/record it will effect, you could try locking the 
record yourself (with say, ED) and waiting until the rogue program hits it. 
Using PORT.STATUS CALL.STACK then should tell you the line number issuing the 
lock.

Regards,
Dan

-Original Message-
From: u2-users-boun...@listserver.u2ug.org 
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Kevin King
Sent: Thursday, September 08, 2011 9:15 AM
To: U2 Users List
Subject: Re: [U2] Lock Status

That's useful for determining where that port is, but we have a process leaving 
rogue locks lying around.  Anything that tells what updated the lock table?

On Thu, Sep 8, 2011 at 9:10 AM, Daniel McGrath
dmcgr...@rocketsoftware.comwrote:

 Once you know the pid of the program with the lock, you can use 
 PORT.STATUS to determine this. You just need to use the CALL.STACK 
 option. IIRC (It's been a few months) it would be like:

 PORT.STATUS PID the progs pid here CALL.STACK

 Regards,
 Dan

 -Original Message-
 From: u2-users-boun...@listserver.u2ug.org [mailto:
 u2-users-boun...@listserver.u2ug.org] On Behalf Of Kevin King
 Sent: Thursday, September 08, 2011 9:06 AM
 To: U2 Users List
 Subject: [U2] Lock Status

 Is there anything in Unidata that would report the line of code that 
 set a particular record lock?

 -Kevin
 http://www.PrecisOnline.com
 ___
 U2-Users mailing list
 U2-Users@listserver.u2ug.org
 http://listserver.u2ug.org/mailman/listinfo/u2-users
 ___
 U2-Users mailing list
 U2-Users@listserver.u2ug.org
 http://listserver.u2ug.org/mailman/listinfo/u2-users




--
-Kevin
http://www.PrecisOnline.com
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] Lock Status

It's a shame there isn't a file trigger operation on locking reads, just 
updates and deletes.  That way you could just add it to the file in question.

-Original Message-
From: u2-users-boun...@listserver.u2ug.org 
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Kevin King
Sent: Thursday, September 08, 2011 11:16 AM
To: U2 Users List
Subject: Re: [U2] Lock Status

Dave: Two Words: Vendor App.  Good idea, but not possible in this case.
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
html
body
 Dave Davis Team Lead, Ramp;D P: 614-875-4910 
x108 F: 614-875-4088 E: dda...@harriscomputer.com 
[http://www.harriscomputer.com/images/signatures/HarrisSchools.gif] 
[http://www.harriscomputer.com/images/signatures/DivisionofHarris.gif]
 6110 Enterprise Parkway Grove City, OH 43123 www.harris-schoolsolutions.com 
This message is intended exclusively for the individual or entity to which it 
is addressed. This communication may contain information that is proprietary, 
privileged or confidential
 or otherwise legally exempt from disclosure. If you are not the named 
addressee, you are not authorized to read, print, retain, copy or disseminate 
this message or any part of it. If you have received this message in error, 
please notify the sender immediately
 by e-mail and delete all copies of the message.
/body
/html
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] Lock Status

2011-09-08 Thread Steve Romanow

On Thu, Sep 8, 2011 at 11:23 AM, Daniel McGrath
dmcgr...@rocketsoftware.com wrote:
 LIST.READU will tell you what program owns the lock (as long as the program 
 is still running). The UNO column is the UniData Number, which will relate to 
 a user/process in the PORT.STATUS (no options) command's list.


Aren't the locks released when the program stops?
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] Lock Status

Kudos for the novel ideas Dan!  However, in this case we're trying to track
down a program that left a lock.  And being an SB+ application, a lot of
stuff runs under the same PID.
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] Lock Status

2011-09-08 Thread Steve Romanow

On Thu, Sep 8, 2011 at 11:26 AM, Dave Davis dda...@harriscomputer.com wrote:
 It's a shame there isn't a file trigger operation on locking reads, just 
 updates and deletes.  That way you could just add it to the file in question.


The update trigger might be useful.  Most ppl would lock the record
before updating it.
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] Lock Status

Yes, Steve, but being an SB+ application... the program never stops
completely until the person logs off.  Meanwhile, they end up dragging
mines..
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] Lock Status

2011-09-08 Thread Daniel McGrath

Yes, they should be.

-Original Message-
From: u2-users-boun...@listserver.u2ug.org 
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Steve Romanow
Sent: Thursday, September 08, 2011 9:27 AM
To: U2 Users List
Subject: Re: [U2] Lock Status

On Thu, Sep 8, 2011 at 11:23 AM, Daniel McGrath dmcgr...@rocketsoftware.com 
wrote:
 LIST.READU will tell you what program owns the lock (as long as the program 
 is still running). The UNO column is the UniData Number, which will relate to 
 a user/process in the PORT.STATUS (no options) command's list.

Aren't the locks released when the program stops?
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] Lock Status

It would be useful, except that the problem is the locker causing the problem 
probably hasn't updated the record yet, which most likely would release the 
lock (this being an SB+ application) and end the problem.  Retaining the lock 
after an update is something that would likely be coded in unibasic.

-Original Message-
From: u2-users-boun...@listserver.u2ug.org 
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Steve Romanow
Sent: Thursday, September 08, 2011 11:28 AM
To: U2 Users List
Subject: Re: [U2] Lock Status

On Thu, Sep 8, 2011 at 11:26 AM, Dave Davis dda...@harriscomputer.com wrote:
 It's a shame there isn't a file trigger operation on locking reads, just 
 updates and deletes.  That way you could just add it to the file in question.

The update trigger might be useful.  Most ppl would lock the record
before updating it.
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
html
body
 Dave Davis Team Lead, Ramp;D P: 614-875-4910 
x108 F: 614-875-4088 E: dda...@harriscomputer.com 
[http://www.harriscomputer.com/images/signatures/HarrisSchools.gif] 
[http://www.harriscomputer.com/images/signatures/DivisionofHarris.gif]
 6110 Enterprise Parkway Grove City, OH 43123 www.harris-schoolsolutions.com 
This message is intended exclusively for the individual or entity to which it 
is addressed. This communication may contain information that is proprietary, 
privileged or confidential
 or otherwise legally exempt from disclosure. If you are not the named 
addressee, you are not authorized to read, print, retain, copy or disseminate 
this message or any part of it. If you have received this message in error, 
please notify the sender immediately
 by e-mail and delete all copies of the message.
/body
/html
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] Lock Status

We do suspect it is from a custom BASIC subroutine, recently installed.  So
knowing the file we're looking back through any code that was compiled
within the past 2 weeks and manually searching for READU's that don't WRITE,
DELETE, or RELEASE.  Sure would be nice if the lock table would report the
line of code that set the lock.  Just sayin'.
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] Lock Status

2011-09-08 Thread Jeff Schasny


Kevin,

I think that the closest you are going to be able to get is the program 
in question using LIST.READU to determine the PID and PORT.STATUS to 
then find the program. I don't know of any way to dynamically get to the 
program line number from there. You could, of course, just look through 
the program source and the READUs then make an educated guess from there.


Kevin King wrote:

Unfortunately, no love there either John.  I even went to the GETREADU( .. )
function in BASIC.. nothing there.
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

  


--

Jeff Schasny - Denver, Co, USA
jschasny at gmail dot com

___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] Lock Status

2011-09-08 Thread Steve Romanow

On Thu, Sep 8, 2011 at 11:34 AM, Kevin King precisonl...@gmail.com wrote:
 We do suspect it is from a custom BASIC subroutine, recently installed.  So
 knowing the file we're looking back through any code that was compiled
 within the past 2 weeks and manually searching for READU's that don't WRITE,
 DELETE, or RELEASE.  Sure would be nice if the lock table would report the
 line of code that set the lock.  Just sayin'.
 ___
 U2-Users mailing list
 U2-Users@listserver.u2ug.org
 http://listserver.u2ug.org/mailman/listinfo/u2-users


That does seem like it would be a trivial and cool addition.  Maybe
just on an option switch.
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] Lock Status

2011-09-08 Thread John Thompson

Yeah PORT.STATUS on Universe will tell you the last command run by the
floating user number of the user...

So if you were able to get the UserNo from LIST.READU EVERY output, and then
cross reference that with the PORT.STATUS output, perhaps you could at least
narrow it down.

Of course that would require you knowing the program name that you were
looking for...

So if you knew the program name you were looking for, maybe you could in a
BASIC program:

1) Execute and Capture LIST.READU EVERY output.
2) Execute and Capture PORT.STATUS output.
3) Then look through PORT.STATUS and find the program you were looking for
or the UserNo you were looking for and display just that line...

-Or if you new a series of Unix user names that might be setting you could
look at only those...

Just thinking out loud...

On Thu, Sep 8, 2011 at 11:34 AM, Jeff Schasny jscha...@gmail.com wrote:

Kevin,

I think that the closest you are going to be able to get is the program in
question using LIST.READU to determine the PID and PORT.STATUS to then find
the program. I don't know of any way to dynamically get to the program line
number from there. You could, of course, just look through the program
source and the READUs then make an educated guess from there.

Kevin King wrote:

Unfortunately, no love there either John. I even went to the GETREADU( ..
)
function in BASIC.. nothing there.
__**_
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/**mailman/listinfo/u2-usershttp://listserver.u2ug.org/mailman/listinfo/u2-users

--
--**--**

Jeff Schasny - Denver, Co, USA
jschasny at gmail dot com
--**--**

__**_
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/**mailman/listinfo/u2-usershttp://listserver.u2ug.org/mailman/listinfo/u2-users

--
John Thompson
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] Lock Status

If only the lock table was an actual hashed file that you could place an update 
trigger on.

-Original Message-
From: u2-users-boun...@listserver.u2ug.org 
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Kevin King
Sent: Thursday, September 08, 2011 11:15 AM
To: U2 Users List
Subject: Re: [U2] Lock Status

That's useful for determining where that port is, but we have a process
leaving rogue locks lying around.  Anything that tells what updated the lock
table?

On Thu, Sep 8, 2011 at 9:10 AM, Daniel McGrath
dmcgr...@rocketsoftware.comwrote:

 Once you know the pid of the program with the lock, you can use PORT.STATUS
 to determine this. You just need to use the CALL.STACK option. IIRC (It's
 been a few months) it would be like:

 PORT.STATUS PID the progs pid here CALL.STACK

 Regards,
 Dan

 -Original Message-
 From: u2-users-boun...@listserver.u2ug.org [mailto:
 u2-users-boun...@listserver.u2ug.org] On Behalf Of Kevin King
 Sent: Thursday, September 08, 2011 9:06 AM
 To: U2 Users List
 Subject: [U2] Lock Status

 Is there anything in Unidata that would report the line of code that set a
 particular record lock?

 -Kevin
 http://www.PrecisOnline.com
 ___
 U2-Users mailing list
 U2-Users@listserver.u2ug.org
 http://listserver.u2ug.org/mailman/listinfo/u2-users
 ___
 U2-Users mailing list
 U2-Users@listserver.u2ug.org
 http://listserver.u2ug.org/mailman/listinfo/u2-users




--
-Kevin
http://www.PrecisOnline.com
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
html
body
 Dave Davis Team Lead, Ramp;D P: 614-875-4910 
x108 F: 614-875-4088 E: dda...@harriscomputer.com 
[http://www.harriscomputer.com/images/signatures/HarrisSchools.gif] 
[http://www.harriscomputer.com/images/signatures/DivisionofHarris.gif]
 6110 Enterprise Parkway Grove City, OH 43123 www.harris-schoolsolutions.com 
This message is intended exclusively for the individual or entity to which it 
is addressed. This communication may contain information that is proprietary, 
privileged or confidential
 or otherwise legally exempt from disclosure. If you are not the named 
addressee, you are not authorized to read, print, retain, copy or disseminate 
this message or any part of it. If you have received this message in error, 
please notify the sender immediately
 by e-mail and delete all copies of the message.
/body
/html
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] Lock Status

2011-09-08 Thread Colin Alfke

Just don't do what one of my old bosses did (he was having trouble with SB+
holding locks) - he found one of our main processes and put in RELEASE.
Our system relied heavily on pessimistic locking so this caused quite a bit
of data loss. Of course, I was the one that had to clean it all up (he
didn't like the names I called him after that one). Of course, this was the
same genius that taught an entire site to use ctrlq to stop their PC's
from beeping... but didn't bother to explain that you shouldn't reboot and
try the same thing again.

Good luck

Colin

-Original Message-
From: Kevin King

We do suspect it is from a custom BASIC subroutine, recently installed.  So
knowing the file we're looking back through any code that was compiled
within the past 2 weeks and manually searching for READU's that don't WRITE,
DELETE, or RELEASE.  Sure would be nice if the lock table would report the
line of code that set the lock.  Just sayin'.


___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] Lock Status


Kevin sorry but no.
There is no function that will tell you the line of code or even the program 
which set a lock.

You could however, as others have suggested determine the PID which set it, AND 
(not OR) write a routine which wakes up every five minutes and copies the 
current lock table into a history item, compare and contrast so you can get a 
running map of exactly WHEN and by WHOM the nasty lock is being set.

Then after you run that for a week, send the results to the Vendor and say, OK 
now fix it bozo!
Optionally you can leave off bozo.





-Original Message-
From: Kevin King precisonl...@gmail.com
To: U2 Users List u2-users@listserver.u2ug.org
Sent: Thu, Sep 8, 2011 8:20 am
Subject: Re: [U2] Lock Status


Unfortunately, no love there either John.  I even went to the GETREADU( .. )
unction in BASIC.. nothing there.
__
2-Users mailing list
2-us...@listserver.u2ug.org
ttp://listserver.u2ug.org/mailman/listinfo/u2-users

___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] Lock Status

2011-09-08 Thread Charlie Noah


I think I worked for him once!  ;^)

Charlie Noah

On 09-08-2011 11:11 AM, Colin Alfke wrote:

Just don't do what one of my old bosses did (he was having trouble with SB+
holding locks) - he found one of our main processes and put in RELEASE.
Our system relied heavily on pessimistic locking so this caused quite a bit
of data loss. Of course, I was the one that had to clean it all up (he
didn't like the names I called him after that one). Of course, this was the
same genius that taught an entire site to usectrlq to stop their PC's
from beeping... but didn't bother to explain that you shouldn't reboot and
try the same thing again.

Good luck

Colin

-Original Message-
From: Kevin King

We do suspect it is from a custom BASIC subroutine, recently installed.  So
knowing the file we're looking back through any code that was compiled
within the past 2 weeks and manually searching for READU's that don't WRITE,
DELETE, or RELEASE.  Sure would be nice if the lock table would report the
line of code that set the lock.  Just sayin'.


___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users


___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] Lock Status


This won't work unless the program is halted-waiting.
Most likely it's moved on to do a hundred other things since the lock in 
question, but left it hanging because the pid is still living.
If the pid dies it would release the lock, but for example, even on non-SB 
systems, phantoms which run constantly can leave locks hanging forever.





-Original Message-
From: Jeff Schasny jscha...@gmail.com
To: U2 Users List u2-users@listserver.u2ug.org
Sent: Thu, Sep 8, 2011 8:34 am
Subject: Re: [U2] Lock Status


Kevin,
I think that the closest you are going to be able to get is the program 
n question using LIST.READU to determine the PID and PORT.STATUS to 
hen find the program. I don't know of any way to dynamically get to the 
rogram line number from there. You could, of course, just look through 
he program source and the READUs then make an educated guess from there.
Kevin King wrote:
 Unfortunately, no love there either John.  I even went to the GETREADU( .. )
 function in BASIC.. nothing there.
 ___
 U2-Users mailing list
 U2-Users@listserver.u2ug.org
 http://listserver.u2ug.org/mailman/listinfo/u2-users

   
-- 
---
eff Schasny - Denver, Co, USA
schasny at gmail dot com
---
__
2-Users mailing list
2-us...@listserver.u2ug.org
ttp://listserver.u2ug.org/mailman/listinfo/u2-users

___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] Lock Status

2011-09-08 Thread Jeff Schasny

I believe that if the program ended the lock would be released, so by 
finding the PID via LIST.READU and then determining the program name 
associated with the PID via PORT.STATUS you are identifying the program 
which currently holds the lock unless the program ends between the 
LIST.READU and PORT.STATUS.


At least in my Unix/Universe world.

Wjhonson wrote:

This won't work unless the program is halted-waiting.
Most likely it's moved on to do a hundred other things since the lock in 
question, but left it hanging because the pid is still living.
If the pid dies it would release the lock, but for example, even on non-SB 
systems, phantoms which run constantly can leave locks hanging forever.





-Original Message-
From: Jeff Schasny jscha...@gmail.com
To: U2 Users List u2-users@listserver.u2ug.org
Sent: Thu, Sep 8, 2011 8:34 am
Subject: Re: [U2] Lock Status


Kevin,
I think that the closest you are going to be able to get is the program 
n question using LIST.READU to determine the PID and PORT.STATUS to 
hen find the program. I don't know of any way to dynamically get to the 
rogram line number from there. You could, of course, just look through 
he program source and the READUs then make an educated guess from there.

Kevin King wrote:
 Unfortunately, no love there either John.  I even went to the GETREADU( .. )
 function in BASIC.. nothing there.
 ___
 U2-Users mailing list
 U2-Users@listserver.u2ug.org
 http://listserver.u2ug.org/mailman/listinfo/u2-users

   
  


--

Jeff Schasny - Denver, Co, USA
jschasny at gmail dot com

___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] Lock Status


That's not the case.
PORT.STATUS shows you what that PID is currently doing when you run it.
Not what it was doing an hour ago for example.
Not what it was doing when it set the lock.
Just what it's doing now.
In Unix/Universe world.

If you are so lucky to know about the lock *right when* it's being set, then 
you are right.
But in my experience that is a very rare occurence.
And in this particular example, he already stated that it was a lock left set 
some time earlier.
You can only know the program being run by that PID if that program is in some 
sort of waiting condition and had been waiting since it set the lock.







-Original Message-
From: Jeff Schasny jscha...@gmail.com
To: U2 Users List u2-users@listserver.u2ug.org
Sent: Thu, Sep 8, 2011 10:30 am
Subject: Re: [U2] Lock Status


I believe that if the program ended the lock would be released, so by 
inding the PID via LIST.READU and then determining the program name 
ssociated with the PID via PORT.STATUS you are identifying the program 
hich currently holds the lock unless the program ends between the 
IST.READU and PORT.STATUS.
At least in my Unix/Universe world.
Wjhonson wrote:
 This won't work unless the program is halted-waiting.
 Most likely it's moved on to do a hundred other things since the lock in 
uestion, but left it hanging because the pid is still living.
 If the pid dies it would release the lock, but for example, even on non-SB 
ystems, phantoms which run constantly can leave locks hanging forever.





 -Original Message-
 From: Jeff Schasny jscha...@gmail.com
 To: U2 Users List u2-users@listserver.u2ug.org
 Sent: Thu, Sep 8, 2011 8:34 am
 Subject: Re: [U2] Lock Status


 Kevin,
 I think that the closest you are going to be able to get is the program 
 n question using LIST.READU to determine the PID and PORT.STATUS to 
 hen find the program. I don't know of any way to dynamically get to the 
 rogram line number from there. You could, of course, just look through 
 he program source and the READUs then make an educated guess from there.
 Kevin King wrote:
  Unfortunately, no love there either John.  I even went to the GETREADU( .. )
  function in BASIC.. nothing there.
  ___
  U2-Users mailing list
  U2-Users@listserver.u2ug.org
  http://listserver.u2ug.org/mailman/listinfo/u2-users


   
-- 
---
eff Schasny - Denver, Co, USA
schasny at gmail dot com
---
__
2-Users mailing list
2-us...@listserver.u2ug.org
ttp://listserver.u2ug.org/mailman/listinfo/u2-users

___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] Lock Status

2011-09-08 Thread Wally Terhune

Not exactly trivial. Would require a new structure to be added to the table and 
changes to all associated routines that access and maintain this shared memory 
table.

Also - UniData record locks are tied to a file variable. So even if the 
'program ends', if the file variable is in COMMON and therefore not closed 
(local variables closed when program ends), the lock would persist.

Wally Terhune
U2 Support Architect
Rocket Software
4600 South Ulster Street, Suite 1100 ..Denver, CO 80237 ..USA
Tel: +1.720.475.8055
Email: wterh...@rs.com
Web: www.rocketsoftware.com/u2




-Original Message-
From: u2-users-boun...@listserver.u2ug.org 
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Steve Romanow
Sent: Thursday, September 08, 2011 9:39 AM
To: U2 Users List
Subject: Re: [U2] Lock Status

On Thu, Sep 8, 2011 at 11:34 AM, Kevin King precisonl...@gmail.com wrote:
 We do suspect it is from a custom BASIC subroutine, recently installed.  So
 knowing the file we're looking back through any code that was compiled
 within the past 2 weeks and manually searching for READU's that don't WRITE,
 DELETE, or RELEASE.  Sure would be nice if the lock table would report the
 line of code that set the lock.  Just sayin'.
 ___
 U2-Users mailing list
 U2-Users@listserver.u2ug.org
 http://listserver.u2ug.org/mailman/listinfo/u2-users


That does seem like it would be a trivial and cool addition.  Maybe
just on an option switch.
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] Lock Status

2011-09-08 Thread Jeff Schasny


I disagree.

If I run LIST.READU and note the PID of a process holding a lock on an 
item then run PORT.STATUS on that PID the only way that the program 
shown by PORT.STATUS as currently running is not the process holding the 
lock would be if the program ended (thus dropping the lock) before I ran 
the PORT.STATUS.


Wjhonson wrote:

That's not the case.
PORT.STATUS shows you what that PID is currently doing when you run it.
Not what it was doing an hour ago for example.
Not what it was doing when it set the lock.
Just what it's doing now.
In Unix/Universe world.

If you are so lucky to know about the lock *right when* it's being set, then 
you are right.
But in my experience that is a very rare occurence.
And in this particular example, he already stated that it was a lock left set 
some time earlier.
You can only know the program being run by that PID if that program is in some 
sort of waiting condition and had been waiting since it set the lock.







-Original Message-
From: Jeff Schasny jscha...@gmail.com
To: U2 Users List u2-users@listserver.u2ug.org
Sent: Thu, Sep 8, 2011 10:30 am
Subject: Re: [U2] Lock Status


I believe that if the program ended the lock would be released, so by 
inding the PID via LIST.READU and then determining the program name 
ssociated with the PID via PORT.STATUS you are identifying the program 
hich currently holds the lock unless the program ends between the 
IST.READU and PORT.STATUS.

At least in my Unix/Universe world.
Wjhonson wrote:
 This won't work unless the program is halted-waiting.
 Most likely it's moved on to do a hundred other things since the lock in 
uestion, but left it hanging because the pid is still living.
 If the pid dies it would release the lock, but for example, even on non-SB 
ystems, phantoms which run constantly can leave locks hanging forever.






 -Original Message-
 From: Jeff Schasny jscha...@gmail.com
 To: U2 Users List u2-users@listserver.u2ug.org
 Sent: Thu, Sep 8, 2011 8:34 am
 Subject: Re: [U2] Lock Status


 Kevin,
 I think that the closest you are going to be able to get is the program 
 n question using LIST.READU to determine the PID and PORT.STATUS to 
 hen find the program. I don't know of any way to dynamically get to the 
 rogram line number from there. You could, of course, just look through 
 he program source and the READUs then make an educated guess from there.

 Kevin King wrote:
  Unfortunately, no love there either John.  I even went to the GETREADU( .. )
  function in BASIC.. nothing there.
  ___
  U2-Users mailing list
  U2-Users@listserver.u2ug.org
  http://listserver.u2ug.org/mailman/listinfo/u2-users


   
  


--

Jeff Schasny - Denver, Co, USA
jschasny at gmail dot com

___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] Lock Status


Port.status shows what is currently running on that PID
Not what was running when the lock was set.

The process is not the program.  You are using the words interchangebly 
when they are not.
A process can run a long stack up and down adding and pruning.  The call stack 
only shows the current stack of the stack, not what the state was when the lock 
was set.

If a member of the old call stack had set a lock, that lock persists until the 
entire call stack is completely depleted.
Which could be 20 routines later.





-Original Message-
From: Jeff Schasny jscha...@gmail.com
To: U2 Users List u2-users@listserver.u2ug.org
Sent: Thu, Sep 8, 2011 11:30 am
Subject: Re: [U2] Lock Status


I disagree.
If I run LIST.READU and note the PID of a process holding a lock on an 
tem then run PORT.STATUS on that PID the only way that the program 
hown by PORT.STATUS as currently running is not the process holding the 
ock would be if the program ended (thus dropping the lock) before I ran 
he PORT.STATUS.
Wjhonson wrote:
 That's not the case.
 PORT.STATUS shows you what that PID is currently doing when you run it.
 Not what it was doing an hour ago for example.
 Not what it was doing when it set the lock.
 Just what it's doing now.
 In Unix/Universe world.

 If you are so lucky to know about the lock *right when* it's being set, then 
ou are right.
 But in my experience that is a very rare occurence.
 And in this particular example, he already stated that it was a lock left set 
ome time earlier.
 You can only know the program being run by that PID if that program is in some 
ort of waiting condition and had been waiting since it set the lock.

___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] Lock Status

2011-09-08 Thread George Hammerle


Even if the program ended that locked the item, the lock could still be 
maintained if the file variable was passed.

I know this is after the fact but, one option going forward would be to write a 
wrapper program for READU's and call it LOCK.RECORD. I use this approach 
extensively.

CALL *LOCK.RECORD( R.RECORD, KEY.TO.RECORD, FILE.VARIABLE )

1. If it is a phantom, perform a READU
2. If it is a real user, use the LOCKED clause 
2a. If it is locked, display whom has it locked followed by an INPUT ( if it is 
SB+, use a DISP ).
2b. If it is not locked, lock it.
* This allows them to see who has them locked and contact the guilty party
3. NEW OPTION : Once locked, you could get the call stack and record to a file 
which program locked it ( excluding this sub - LOCK.RECORD ). Or you could add 
an additional parameter to this sub and pass in the program name. 


We already do 1 and 2, but 3 would be an interesting option. 


We also have a sub called LOCK.RECORD.ESCAPE that gives the user the option to 
escape if the record is locked and it also displays who has them locked. We 
only use this option when it is safe to escape and it sends back ESCAPED 1 or 
0 so we can handle the escape properly.





This e-mail and any files transmitted with it are confidential and intended
solely for the use of the individual or company to whom they are addressed. If
you have received this e-mail in error, please notify the sender immediately and
delete this e-mail including all attachments from your system. Thank you
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] Lock Status


This still would not be accurate for the reasons already stated.
The call stack only shows you what routine is on the stack.  If the lock had 
been set for hours, who knows what routine was there previously?
As you yourself stated, locks can persist, after the routine which created them 
has gone away.

The only viable solution is to record the lock at the time it is set.






-Original Message-
From: George Hammerle zhamme...@hubert.com
To: u2-users u2-users@listserver.u2ug.org
Sent: Thu, Sep 8, 2011 12:36 pm
Subject: Re: [U2] Lock Status



ven if the program ended that locked the item, the lock could still be 
aintained if the file variable was passed.
I know this is after the fact but, one option going forward would be to write a 
rapper program for READU's and call it LOCK.RECORD. I use this approach 
xtensively.
CALL *LOCK.RECORD( R.RECORD, KEY.TO.RECORD, FILE.VARIABLE )
1. If it is a phantom, perform a READU
. If it is a real user, use the LOCKED clause 
a. If it is locked, display whom has it locked followed by an INPUT ( if it is 
B+, use a DISP ).
b. If it is not locked, lock it.
 This allows them to see who has them locked and contact the guilty party
. NEW OPTION : Once locked, you could get the call stack and record to a file 
hich program locked it ( excluding this sub - LOCK.RECORD ). Or you could add 
n additional parameter to this sub and pass in the program name. 

e already do 1 and 2, but 3 would be an interesting option. 

e also have a sub called LOCK.RECORD.ESCAPE that gives the user the option to 
scape if the record is locked and it also displays who has them locked. We only 
se this option when it is safe to escape and it sends back ESCAPED 1 or 0 so 
e can handle the escape properly.


This e-mail and any files transmitted with it are confidential and intended
olely for the use of the individual or company to whom they are addressed. If
ou have received this e-mail in error, please notify the sender immediately and
elete this e-mail including all attachments from your system. Thank you
__
2-Users mailing list
2-us...@listserver.u2ug.org
ttp://listserver.u2ug.org/mailman/listinfo/u2-users

___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] Lock Status

Thank you goes out to everyone for the input.  We were able to identify (and
as of this moment it would appear correct) a couple of suspects by looking
at the code that had been compiled within the last 2 weeks and evaluating
each routine separately.  I still think it'd be cool to be able to see which
program set which locks retrospectively, though I completely understand
Wally's perspective about the effort involved to make that happen.

-K
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] Lock Status

2011-09-08 Thread Mecki Foerthmann


I dare to disagree.
If you ALWAYS use a subroutine that records the pid, the file, item Id 
and program on a logfile when you want to read and lock a record and 
ALWAYS use a subroutine that removes the info from the logfile to write 
or release this could work.

Otherwise it won't.

On 08/09/2011 20:39, Wjhonson wrote:

This still would not be accurate for the reasons already stated.
The call stack only shows you what routine is on the stack.  If the lock had 
been set for hours, who knows what routine was there previously?
As you yourself stated, locks can persist, after the routine which created them 
has gone away.

The only viable solution is to record the lock at the time it is set.






-Original Message-
From: George Hammerlezhamme...@hubert.com
To: u2-usersu2-users@listserver.u2ug.org
Sent: Thu, Sep 8, 2011 12:36 pm
Subject: Re: [U2] Lock Status



ven if the program ended that locked the item, the lock could still be
aintained if the file variable was passed.
I know this is after the fact but, one option going forward would be to write a
rapper program for READU's and call it LOCK.RECORD. I use this approach
xtensively.
CALL *LOCK.RECORD( R.RECORD, KEY.TO.RECORD, FILE.VARIABLE )
1. If it is a phantom, perform a READU
. If it is a real user, use the LOCKED clause
a. If it is locked, display whom has it locked followed by an INPUT ( if it is
B+, use a DISP ).
b. If it is not locked, lock it.
  This allows them to see who has them locked and contact the guilty party
. NEW OPTION : Once locked, you could get the call stack and record to a file
hich program locked it ( excluding this sub - LOCK.RECORD ). Or you could add
n additional parameter to this sub and pass in the program name.

e already do 1 and 2, but 3 would be an interesting option.

e also have a sub called LOCK.RECORD.ESCAPE that gives the user the option to
scape if the record is locked and it also displays who has them locked. We only
se this option when it is safe to escape and it sends back ESCAPED 1 or 0 so
e can handle the escape properly.


This e-mail and any files transmitted with it are confidential and intended
olely for the use of the individual or company to whom they are addressed. If
ou have received this e-mail in error, please notify the sender immediately and
elete this e-mail including all attachments from your system. Thank you
__
2-Users mailing list
2-us...@listserver.u2ug.org
ttp://listserver.u2ug.org/mailman/listinfo/u2-users

___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] Lock Status

2011-09-08 Thread John Hester

You might be able to implement this capability from within the programs
themselves without a huge amount of effort.  We have a small program
tracking subroutine and a companion utility that automatically installs
a call to it from every program.  The original purpose was to determine
which code was still in use for our initial conversion from Ultimate to
UV 15 years ago, but it's come in handy for isolating anomolies over the
years.  The call statement is simply:

CALL TRACKER('THIS.PROGRAM')

The utility goes through all programs on a weekly basis during nightly
batch processing, adds that line at the top if it doesn't exist
(following the SUBROUTINE line), and recompiles the program.  The
tracker program writes a log record where the ID is the user and the
data is a sequential list of programs as well as a record where the ID
is the program and the data is a sequential list of users.  For your
lock issue, you could take this a step further and:

1) Check to see if this session is still hanging onto locks from the
previously called subroutine
2) Figure out what subroutine was previously called from the log record
and log the locks still being held

You will also have to come up with a method of insuring you only log the
initial instance, but I think that should be do-able.

-John

-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Kevin King
Sent: Thursday, September 08, 2011 1:01 PM
To: U2 Users List
Subject: Re: [U2] Lock Status

Thank you goes out to everyone for the input.  We were able to identify
(and
as of this moment it would appear correct) a couple of suspects by
looking
at the code that had been compiled within the last 2 weeks and
evaluating
each routine separately.  I still think it'd be cool to be able to see
which
program set which locks retrospectively, though I completely understand
Wally's perspective about the effort involved to make that happen.

-K
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] Lock Status