Hello all,
We are running Universe 10.1 on AIX with about 500 users. We have a problem
with users opening up a record which puts a lock on it and just letting it sit
at the INPUT statement for a long time.
Most of the locking within the application does not use the LOCKED clause so
when a
Check INPUTIF, this will return a value if the input buffer has
something. If after 2 minutes of checking INPUTIF you have nothing it's
because the user isn't active. If you do a LOOP with INPUTIF inside be
careful to put an RQM or something similar in the loop.
On Tue, 27 Mar 2012 06:26:38
Its strange to me that Universe does not have this feature built in to the
INPUT statement...
Something like:
INPUT user_input TIMEOUT 30
Maybe I have missed something in the UV docs, but, I never could find
anything built in. If I remember correctly other flavors of MV have had
this for a
Don, I don't know about Universe but Unidata has the INPUT - FOR statement to
do this. It looks like this... INPUT VAR,5_: FOR 1200 ELSE IF
@SYSTEM.RETURN.CODE = -1 THEN VAR = '*'. It waits at the input prompt for 30
minutes, the @SYSTEM.RETURN.CODE is set to -1 to indicate a time out
Any solution is going to require modifying your system, as far as I know, other
than educating your users. The best solution would be to add the LOCKED clause
so you can find out who is the offending user and concentrate on increasing
their knowledge.
-Original Message-
From:
*Timed* activity on a *line* is controlled by the O/S not within Universe per
se. Or at least you shouldn't expect Universe to keep you informed when lines
are idle, natively.
So (being on AIX a type of Unix) you are going to need to write a
constantly-running background task which queries
I guess you would need to merge this with the routine to detect who has locks
open (except running every two mins, not five)
To determine who is sitting at an input prompt at a menu (which might be
ok), vs someone who is sitting at an input
Prompt and hogging the locks!
George
Right, you don't care if they are at input exactly.
You care if they are squatting on a lock.
So your periodic lock checker thingie, has to be combined with a nasty
email-o-gram campaign
Until the users are well edumacated.
-Original Message-
From: George Gallen
Thanks to all who responded.
At the point in the programs where this is a problem for us, we know the user
has a lock, we just want to release the lock. This will be done where they
already have the option of aborting so no problem with partial updates, etc.
The only gotcha on this is if
You could have a phantom utility launched by cron that steps through the lock
table, attempts to acquire a lock on the each locked item, and loops while
keeping track of elapsed time. If the lock is released within the time limit,
exit and do nothing. If the time is exceeded, send something
We have had at times, the telnet session gets lost somehow, and the process
becomes zombied,
And the lock never gets released. We have to go in and manually kill the
process which
Then releases the lock (or clear the locks through UV - but the process is
still zombied).
-Original
I know the OP wanted to know how long a user session has been idle,
but real problem is the second person waiting for the lock to be
released.
The best practice is to always have LOCKED clauses on your READU's,
and never to block on a lock, i.e. a user input process should hit
the locked clause
Although you are right in a grounds-up approach, the problem is that, most code
is old.
Many managers are adverse to *fixing* code that is working, because if you keep
opening the oven door the souffle will fall.
Even if you just stomp around a lot
So the approach of monitor from the
Is this real? Or did I get spammed by a bot scraping the U2 archives?
I couldn't figure out what anything in my post that would have triggered it.
Anyone else getting these?
George
-Original Message-
From: Administrator [mailto:sme...@omnicare.com]
Sent: Tuesday, March 27, 2012 1:44 PM
You're probably not allowed to kill the zombie. It's discrimination. On the
other hand, you *can* create a honeypot of brains and trap them. Much more
humane! :)
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of
Don,
You should at least optimize the code by just checking a counter and not
messing with TIME(). Your NAP command automatically takes care of the
amount of time spent in each loop. You just need to count how many NAPs it
takes to equal the amount of wait time you wish to have.
David A. Green
It was on my other post - which did make it to the list. I thought maybe it was
triggered by HOGGING
George
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Robert Houben
Sent: Tuesday, March 27, 2012 2:31 PM
To:
It was because I said bitch :) OmniCare decided I was cussin
Hahaha I mean Jimminy Cricket people
Some email admins have nothing to do
-Original Message-
From: George Gallen ggal...@wyanokegroup.com
To: U2 Users u2-users@listserver.u2ug.org
Sent: Tue, Mar 27, 2012 11:28 am
Subject:
Not me.
Nancy Fisher
Peninsula Truck Lines, Inc
Federal Way, Washington
253/929-2040
Visit our Website www.peninsulatruck.com
nan...@peninsulatruck.com
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of George Gallen
Ahhh, yes, that would explain it.
That's as bad as grade school, where you get in trouble when someone
Else was talking! (sorry, visions of nuns just went through my mind).
George
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
It does not matter if a system is old or not, you gotta keep it up to
date. Maintenance programming means adding LOCKED clauses that
should have been there in the first place. I doubt it would take more
than a few hours; probably less time than writing and debugging some
off-the-wall input timer
On your system, as you said, versus in the rest of the programming world,
where a programmer works for a manager, who works for another manager, who
reports to a committee, who reports to the CEO, who gets funded by sometimes
not so understanding money guys.
Rex we don't have the luxury of
The OP's system probably doesn't have three thousand READU statements;
I'm willing to guess a few hundred. And out of that few hundred,
maybe a dozen of those READU's block user access during normal
day-to-day operation. And yet a CEO, manager, whatever wouldn't have
a problem implementing some
I believe he was discussing putting that on a *single* program, not every
program.
I would strongly advise against putting a creature like that on every program.
That's the sort of change that can bring a fast machine to its knees.
-Original Message-
From: Rex Gozar rgo...@gmail.com
The tough part isn't so much the qty of but knowing which ones are the important
Ones that will most likely be affected. Depending on the turnover of staff, the
Current staff might not know the code that well, and pinpointing the top
programs
That should be converted first could be a shot in the
He already has the use-case; someone in some specific screen/program
is getting locked out. That's where you start.
On Tue, Mar 27, 2012 at 3:54 PM, George Gallen ggal...@wyanokegroup.com wrote:
The tough part isn't so much the qty of but knowing which ones are the
important
Ones that will
David,
Good idea.
Revised code.
* Don Robinson
* Testing the INPUTIF statement.
*
PROMPT ''
*
ZZ = ''
FOR X = 1 TO 100 ;* Loop for 10 seconds.
INPUTIF ZZ THEN EXIT
NAP 100
NEXT X
*
IF ZZ = '' THEN
CRT 'The user is sleeping'
STOP ;* Do whatever you want here.
END ELSE
*
*
Wj,
You are right, I'm a hired gun and try to do what the *boss* wants.
As far as adding LOCKED clauses, that would only solve a part of it. The second
user would know why they can't update a record but would still have to call
support to kick the first person out.
The goal is to reduce user
If anyone DOES want the equivalent of Unidata's INPUT... WAITING for Universe...
http://www.pickwiki.com/cgi-bin/wiki.pl?InputWait
Regards, Keith
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
Along with the LOCKED you need a call to the STATUS() function to return the
port number/pid
And then a *table* updating (and crushed) by the Login/Logout routines (Yes you
can have a logout routine) which matches the pid to the user
And THEN a table of telephone extensions matched to the
Nicholas ( any newbies listening in),
Just to make sure all bases are covered:
1. LIST.READU's EVERY keyword.
Besides showing group locks, it will also, at the very end, show who is
waiting on a lock.
If there are 2 lines where waiter lock-holder are reversed on the 2nd
line, you have a
31 matches
Mail list logo
