Here's some troubleshooting tips we use for our applications using the U2 APIs
in background non-interactive processes.
We have a common interfacing subroutine our API clients must use to sign-on
and initialise their UV environment. In that code, we turn on COMO output, to
capture any output that BASIC code or any other UV command may output. We tend
to generate unique COMO filenames, with the OS user ID, process-ID, UV User No.
and a date stamp - as typically you're executing multiple instances under the
same user ID. With this, we can see what unexpected input or output is
captured. Otherwise, you never really know what's going on.
For further debugging we have a debug subroutine we can put into a code to log
messages to a sequential file with details of what step or data is being
processed. We use to as a non-invasive way to capture detail information. It is
really just something of a glorified PRINT statement you'd have in BASIC
program you'd place to debug it when running from a terminal session...but
written to a unique log file for each background process. We've found it
valuable in the past - especially in the development stage to do this. Then
remove it or disable it later.
You don't mention if your UniObjects code is designed to interact with
interactive UV BASIC or UV commands. This could be an issue regardless, if
someone changes code that expects terminal input and none is forthcoming.
If you don't already, have a ON.ABORT and ON.EXIT paragraph setup to log the
fact that your API process has triggered that. Just simply outputting the fact
it got executed should be sufficient. This you know if aborted or cleanly
exited UV - something which isn't always easy to determine due to lack of
decent session event logging in UV.
We also have a protocol that API processes must sign-off so we can tell if
they cleanly exited from the application. This is useful as well. Likewise, the
application has a transaction log which flags when the update transaction
starts. That isn't cleared, if abnormal termination of the application occurs.
Further nor future transactions aren't possible for the user ID until it is
cleaned/investigated - but that's then logged.
Cheers,
David
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Andy Krause
Sent: Wednesday, 9 January 2013 1:44 AM
To: U2 Users List
Subject: Re: [U2] How to check which sproc is called by user
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
