Re: [U2] UV UOJ hung sessions
I useful thing I have found for any connectivity made via U2 APIs (be it UOJ, UCI, etc) is to get your subroutine to establish a COMO/DIVERT.OUT to log errors that made not get logged anywhere but output to 'standard output'. It's surprising the number of errors you get before your main UV programs get initiated Regards, David -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of John Hester Sent: Wednesday, 1 July 2009 7:11 AM To: U2 Users List Subject: Re: [U2] UV UOJ hung sessions Thanks for the replies. I don't have either of the suggested trace tools and the UV errlog has no useful info, but I was able to find another method. We call a subroutine at the beginning of all of our UV BASIC programs that records user and execution time. I was able to add code there that executes a dummy VOC entry (just a proc that does nothing) followed by the program name whenever @TTY = uvcs. Now PORT.STATUS displays the name of the last subroutine executed by the hung sessions. -John ** 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 U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] UV UOJ hung sessions
On Tue, Jun 30, 2009 at 7:15 AM, Baakkonen, Rodney A (Rod) 46K wrote: > Do you have truss or a trace command at UNIX that can track what the > PID is doing. I think on redhat/linux strace is the equivalent routine. Also lsof might be useful. - Robert ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] UV UOJ hung sessions
Thanks for the replies. I don't have either of the suggested trace tools and the UV errlog has no useful info, but I was able to find another method. We call a subroutine at the beginning of all of our UV BASIC programs that records user and execution time. I was able to add code there that executes a dummy VOC entry (just a proc that does nothing) followed by the program name whenever @TTY = uvcs. Now PORT.STATUS displays the name of the last subroutine executed by the hung sessions. -John ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] UV UOJ hung sessions
Do you have truss or a trace command at UNIX that can track what the PID is doing. It is pretty low level stuff, but if it is doing any file IO, you can see that and maybe see what is going on. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of John Hester Sent: Monday, June 29, 2009 3:46 PM To: U2 Users List Subject: [U2] UV UOJ hung sessions We have an issue where UOJ sessions initiated by our web app server occasionally get hung. This is a rare occurrance, but when it does happen the end user on the site usually repeats the action that causes it enough times to chew up a large number of UV licenses. The sessions remain until killed via "kill -9" at the linux OS level. We had this problem once in the past and were able to track down the offending UV BASIC subroutine via PORT.STATUS because of a unique "EXECUTE 'SELECT ...'" within the program. We're not so lucky this time and PORT.STATUS is not providing any useful info that would point to what subroutine was called. Is there any way to know what the hung session is doing aside from adding code to write out logging info within every subroutine called by UOJ? Maybe something in the /proc filesystem? We're running UV 10.2.7 on RedHat ES 5.1. Thanks, John ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users -- CONFIDENTIALITY NOTICE: If you have received this email in error, please immediately notify the sender by e-mail at the address shown. This email transmission may contain confidential information. This information is intended only for the use of the individual(s) or entity to whom it is intended even if addressed incorrectly. Please delete it from your files if you are not the intended recipient. Thank you for your compliance. Copyright 2009 CIGNA == ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] UV UOJ hung sessions
I am going from memory, so my info may be out of date. IIRC, UV has a log called errlog that is a circular queue of like the last 100 errors returned by UV. If it is a syntax error with a pcperform or a read to an unopened file handle it may show itself there. John Hester wrote: We have an issue where UOJ sessions initiated by our web app server occasionally get hung. This is a rare occurrance, but when it does happen the end user on the site usually repeats the action that causes it enough times to chew up a large number of UV licenses. The sessions remain until killed via "kill -9" at the linux OS level. We had this problem once in the past and were able to track down the offending UV BASIC subroutine via PORT.STATUS because of a unique "EXECUTE 'SELECT ...'" within the program. We're not so lucky this time and PORT.STATUS is not providing any useful info that would point to what subroutine was called. Is there any way to know what the hung session is doing aside from adding code to write out logging info within every subroutine called by UOJ? Maybe something in the /proc filesystem? We're running UV 10.2.7 on RedHat ES 5.1. Thanks, John ___ 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] UV UOJ hung sessions
We have an issue where UOJ sessions initiated by our web app server occasionally get hung. This is a rare occurrance, but when it does happen the end user on the site usually repeats the action that causes it enough times to chew up a large number of UV licenses. The sessions remain until killed via "kill -9" at the linux OS level. We had this problem once in the past and were able to track down the offending UV BASIC subroutine via PORT.STATUS because of a unique "EXECUTE 'SELECT ...'" within the program. We're not so lucky this time and PORT.STATUS is not providing any useful info that would point to what subroutine was called. Is there any way to know what the hung session is doing aside from adding code to write out logging info within every subroutine called by UOJ? Maybe something in the /proc filesystem? We're running UV 10.2.7 on RedHat ES 5.1. Thanks, John ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
