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: [email protected] [mailto:[email protected]] 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: [email protected] [mailto:[email protected]] 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: [email protected] [mailto:[email protected]] On Behalf Of Ravindranath Wickramanayake Sent: 07 January 2013 21:55 To: [email protected] 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 [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users _______________________________________________ U2-Users mailing list [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users _______________________________________________ U2-Users mailing list [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users ************** IMPORTANT MESSAGE ***************************** This e-mail message is intended only for the addressee(s) and contains information which may be confidential. If you are not the intended recipient please advise the sender by return email, do not use or disclose the contents, and delete the message and any attachments from your system. Unless specifically indicated, this email does not constitute formal advice or commitment by the sender or the Commonwealth Bank of Australia (ABN 48 123 123 124) or its subsidiaries. We can be contacted through our web site: commbank.com.au. If you no longer wish to receive commercial electronic messages from us, please reply to this e-mail by typing Unsubscribe in the subject line. ************************************************************** _______________________________________________ U2-Users mailing list [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users
