- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: ANALYSE/SYSTEM - PRF and EXC, how do you find ...
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-11-2012 01:23 AM
10-11-2012 01:23 AM
Folks,
Just a quick question regarding the exception information available from **bleep**/SYS. I have a system consisting of a number of processes, the majority written in Pascal with some modules in C and C++.
We're using OpenVMS 8-4, patched to the hilt running on RX2800s.
One of the processes was taking an inordinate amount of time to perform its processing, most of the CPU time was spent outside of user mode. **bleep**/SYS revealed that the process seemed to be doing nothing but exception processing. Finding a user mode PC address was quite a challenge (used PCS, EXC and FLT under **bleep**/SYS) but seemed to point to an old function using LIB$MOVC3 to perform string conversions. The code was reorganised to reduce the reliance on the problematic function, performance was improved by 95%. The process spent 1 second in COM rather than 20 seconds.
The process is still showing a large number of exceptions. The questions I have are:
1) What is an acceptable exception rate?
2) How do I find out the root cause of the exception?
I've attached some samples output from **bleep**/SYS . If the output from the PRF tool is to believed the process spends most of its time processing exceptions.
Anyway, hope it makes sense.
Cheers
Brian Reiter
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-11-2012 02:31 AM
10-11-2012 02:31 AM
Re: ANALYSE/SYSTEM - PRF and EXC, how do you find out what the exception is?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-11-2012 02:56 AM
10-11-2012 02:56 AM
Re: ANALYSE/SYSTEM - PRF and EXC, how do you find out what the exception is?
Hmmm,
The output from EXC was less than helpful to be honest. How do I map an exception to a given process ID? Where is the root cause?
As far as I know our developers didn't rely on the exception handlers, my best guess is that these exceptions are in the PASCAL RTL or elsewhere.
cheers
Brian
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-11-2012 03:33 AM
10-11-2012 03:33 AM
Solution>>> The output from EXC was less than helpful to be honest. How do I map an exception to a given process ID? Where is the root cause?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-11-2012 05:44 AM
10-11-2012 05:44 AM
Re: ANALYSE/SYSTEM - PRF and EXC, how do you find out what the exception is?
OK, that helps a lot. In the space of 1 second (or less) for the process I'm interested I got 2294 exceptions all with the same basic arguments.
All I need to do now is map the sig (address I assume) into the process address space and then find it in the source. Running the offending exe in debug and examining the value that came back gives me an address in a comman library, presumably data as the debugger didn't show anything resembling source, just an offsett into one of our libraries. The offset being SHARE$NMCS2_APP_RWDATA0+0E477C which looks to be a linker construct.
So the question now becomes, how do I find out which module caused the aggravation.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-11-2012 07:58 AM
10-11-2012 07:58 AM
Re: ANALYSE/SYSTEM - PRF and EXC, how do you find out what the exception is?
OK, so a bit of digging around seems to point the blame at the PASCAL builtin READV. The function calling READV is being called incorrectly anyway so its kind of blind luck that this has worked at all, at this point in the application the READV function is being passed a binary array (its expecting a deliniated numeric string), and hence causing the PASCAL exception handler to fire. We're using ERROR:=CONTINUE which forces contination after the event.
Something to try tomorrow.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-11-2012 08:07 AM
10-11-2012 08:07 AM
Re: ANALYSE/SYSTEM - PRF and EXC, how do you find out what the exception is?
>>> All I need to do now is map the sig (address I assume) into the process address space and then find it in the source.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-12-2012 12:09 AM
10-12-2012 12:09 AM
Re: ANALYSE/SYSTEM - PRF and EXC, how do you find out what the exception is?
Hi,
Thanks for the clarifications and your help it has been much appreciated.
Anyway I've corrected he calls around the READV.Uultimately they weren't required any more, binary data was being passed in which caused an exception in the Pascal READV. This binary data had already been correctly converted earlier.
The problem had probably been in existance for over a decade, possibily two. We had noticed on the Alphas that this process spent too much time in COM but assumed it was normal behaviour. When we ported to Itanium the process spent even more time in COM which set the alarms bell ringing. We have plans for various extensions to the system which this problem would have badly affected. However, now we the processing down to well under a second and we're in a position now to consider the extensions.
cheers
Brian