I will chime in since I work with Ravi and I am dealing with this issue
along with him.

Thanks for the response Brian, PORT.STATUS should be useful for our
situation.

I'll try and be a little more specific and hopefully I know what I'm
talking about:  We have a web application which is using UniObjects and
we are randomly getting multiple (we've seen as many as 9) user sessions
in the LISTU which appear to be hung and it's causing us to reach our
user limit.  We have debugged the web application and verified that all
sessions are being closed properly so we do not believe that it's on the
web side of things.  Although, we cannot duplicate this problem in the
live application either, so we cannot say for sure it's not on the web
side.  My first thought was that the application is calling a PICK
subroutine that is stalling (possibly waiting for input or stuck in an
infinite loop or something).

So, at this point all we know is we are getting these stalled sessions
but we don't know how.  Hopefully with PORT.STATUS we can see whether is
a PICK subroutine that is stalling?

Now, to limit the severity of this problem we discovered there is a
Timeout property of the UniSession object.  However, it seems in the
past we were advised against setting this parameter by Rocket support
and that this timeout should be handled in the unirpcservices file in
the unishared directory?  Does that sound right?  UniAdmin uses the
timeout in the unirpcservices file so I don't think we would want to
shorten the timeout and be booted from UniAdmin sooner.

Thanks in advance for any responses.

-----Original Message-----
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Brian Leach
Sent: Tuesday, January 08, 2013 3:35 AM
To: 'U2 Users List'
Subject: Re: [U2] How to check which sproc is called by user

If it is a session hang you're possibly looking at locking issues so
check the lock table to see what is waiting and also check for any group
locks that persist.

If it is UniVerse, It's also a good idea to check the errlog file in the
uv
account: if that does not exist, create it as a zero length file (you
can go into the UV account and ED &UFD& errlog and just file it) and it
will log the last 100 errors.

If you can catch the session that has hung you can use the PORT.STATUS
command to see where they were and their calling stack.

Phil's idea of using the remote item security subroutine to audit calls
is good once you've managed to identify the routine concerned, but it
doesn't help you get to that point.

How is your application constructed? Is it terminal based, UniObjects,
Web?
If it is terminal based, create a COMO on the LOGIN for that user
session and see if that helps find it.

If it is UniObjects based and you can clearly identify the user (and you
have the time and space) and nothing else has worked, you can actually
watch their session using a network tracer.

I think we need to know a little more about the context of the problem.

Brian


-----Original Message-----
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Ravindranath
Wickramanayake
Sent: 07 January 2013 21:55
To: u2-users@listserver.u2ug.org
Subject: [U2] How to check which sproc is called by user

Hi U2 Guru's

 

Can I tell when a sproc was last executed or who executed it.  If so
how.
Some way to get statistics and access logs. Reason we are asking this is
we are having a session hang issue we have tracked it down to a session
user but have no clue which sproc did the call to trouble shoot.

 

Thanks in advance

_______________________________________________
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
_______________________________________________
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Reply via email to