- Community Home
- >
- Servers and Operating Systems
- >
- Operating System - OpenVMS
- >
- ANALYSE/SYSTEM - PRF and EXC, how do you find out ...
-
- Forums
-
Blogs
- Alliances
- Around the Storage Block
- Behind the scenes @ Labs
- HPE Careers
- HPE Storage Tech Insiders
- Infrastructure Insights
- Inspiring Progress
- Internet of Things (IoT)
- My Learning Certification
- OEM Solutions
- Servers: The Right Compute
- Shifting to Software-Defined
- Telecom IQ
- Transforming IT
- Infrastructure Solutions German
- L’Avenir de l’IT
- IT e Trasformazione Digitale
- Enterprise Topics
- ИТ для нового стиля бизнеса
- Blogs
-
Quick Links
- Community
- Getting Started
- FAQ
- Ranking Overview
- Rules of Participation
- Contact
- Email us
- Tell us what you think
- Information Libraries
- Integrated Systems
- Networking
- Servers
- Storage
- Other HPE Sites
- Support Center
- Enterprise.nxt
- Marketplace
- Aruba Airheads Community
-
Forums
-
Blogs
-
InformationEnglish
- 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
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- 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
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- 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
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- 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
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- 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
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- 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
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- 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
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- 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
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- 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
Hewlett Packard Enterprise International
- Communities
- HPE Blogs and Forum
© Copyright 2019 Hewlett Packard Enterprise Development LP