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:
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
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
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
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
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
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
: 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
, 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
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
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
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
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
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
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
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
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
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
around this problem, but not retroactively, only
proactively.
-Original Message-
From: Mecki Foerthmann mec...@gmx.net
To: u2-users u2-users@listserver.u2ug.org
Sent: Thu, Sep 8, 2011 1:28 pm
Subject: Re: [U2] Lock Status
I dare to disagree.
f you ALWAYS use a subroutine
away.
-John
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of John Hester
Sent: Thursday, September 08, 2011 1:36 PM
To: U2 Users List
Subject: Re: [U2] Lock Status
You might be able to implement this capability from
to live with them the
way they are.
There IS a way to get around this problem, but not retroactively, only
proactively.
-Original Message-
From: Mecki Foerthmannmec...@gmx.net
To: u2-usersu2-users@listserver.u2ug.org
Sent: Thu, Sep 8, 2011 1:28 pm
Subject: Re: [U2] Lock Status
I dare
36 matches
Mail list logo
