- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Name of the invoking funtion
Operating System - OpenVMS
1753706
Members
4797
Online
108799
Solutions
Forums
Categories
Company
Local Language
юдл
back
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
юдл
back
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
Discussion Boards
Discussion Boards
Discussion Boards
Blogs
Information
Community
Resources
Community Language
Language
Forums
Blogs
Go to solution
Topic Options
- 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-05-2010 11:20 AM
тАО10-05-2010 11:20 AM
Re: Name of the invoking funtion
Thanks Hein, Dan and Hoff.
Sorry I expressed myself wrongly about the ACCVIO. Let me correct it.
Actually, because of the writing routine pre checks, no ACCVIO error does really occur. So, we do not have the stack info to go over.
What happens is that those pre checks throw up a pretty generic 'locked file error' that blocks other modules to access the file.
Hein, your idea is to identify the file holder only when somebody else tries to access it, right? Sounds nice.
Using Just knowing the process name does not really help, because our entire system is compiled as only one executable.
That's why it'd be necessary to identify the calling function name.
Another solution would be to pass the calling function name as an argument to the writing routine, but this would mean thousands of changes to be made throughout the code.
PS.: Hoff, we are using logging and embedded print statements for debugging.
Sorry I expressed myself wrongly about the ACCVIO. Let me correct it.
Actually, because of the writing routine pre checks, no ACCVIO error does really occur. So, we do not have the stack info to go over.
What happens is that those pre checks throw up a pretty generic 'locked file error' that blocks other modules to access the file.
Hein, your idea is to identify the file holder only when somebody else tries to access it, right? Sounds nice.
Using Just knowing the process name does not really help, because our entire system is compiled as only one executable.
That's why it'd be necessary to identify the calling function name.
Another solution would be to pass the calling function name as an argument to the writing routine, but this would mean thousands of changes to be made throughout the code.
PS.: Hoff, we are using logging and embedded print statements for debugging.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-05-2010 11:35 AM
тАО10-05-2010 11:35 AM
Re: Name of the invoking funtion
Since you have the checking for the ACCVIO already in place, why not call LIB$SIGNAL with a success code. That should produce a stack dump (I think) but allow for the program to continue. Worse case scenerio, let the ACCVIO occur in a test case and use that stackdump to locate the problem area. Once located, additional print statements can be added to trace the behavior.
Where are you located? Perhaps a direct connection (if allowed) would be more helpful to track this down.
Dan
Where are you located? Perhaps a direct connection (if allowed) would be more helpful to track this down.
Dan
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-05-2010 12:26 PM
тАО10-05-2010 12:26 PM
Re: Name of the invoking funtion
Oh boy, there is a lot of opportunity here to improve the language used / communication, and English is NOT the problem. :-)
>> Actually, because of the writing routine pre checks.
What are 'pre-checks', what is a 'write'.
I assume the write is the Fortran language write IO statement.
Are we typically taking about an new record ( RMS $PUT ) or update/re-write ( RMS $UPDATE).
Is the pre-check a Fortran Read to see if the record can be locked.
Hopefully that is done with generating a lock to make sure no other process sneaks in between the check and the actual act ?!
>> no ACCVIO error does really occur.
ACCVIO is NOT normal in OpenVMS applications.
It means that the application, and specifically the error handling, is broken. So you don't program a check to avoid it, you fix it!
>> What happens is that those pre checks throw up a pretty generic 'locked file error' that blocks other modules to access the file.
So _that_ should be you first order of business and may well make everything else go away. Improve that 'pre-check' to identify the file, key, possibly program image name, possibly calling module name(s).
>> Hein, your idea is to identify the file holder only when somebody else tries to access it, right? Sounds nice.
Correct. Like magic :-).
>> Using Just knowing the process name does not really help, because our entire system is compiled as only one executable.
There is that communication problem.
Be careful keep to modules, images, processes and threads well identified.
When you write process-name, I suspect you meant program name = image name
When I see process-name I think PROCESS-ID
= PID = unique process identifier in OpenVMS
= something to kill ( FORCE_EXIT ) to relase a lock.
It could be that the whole application is written as a single process juggling lots of (AST) threads to work for all users, but frankly I highly doubt that. Surprise me!
>> That's why it'd be necessary to identify the calling function name.
For the programs creating the locks (in the past) or for the programs running into a lock?
>> Another solution would be to pass the calling function name as an argument to the writing routine, but this would mean thousands of changes to be made throughout the code.
That's why we learned to write TPU MACROS, DCL or PERL scripts. :-).
>> PS.: Hoff, we are using logging and embedded print statements for debugging
Right. Hoff suggests that there are more often effective methods: debuggers!
But those would only work in the here and now. That is the program/process/thread running into the lock. It is 'tricky' to go back in time and start debugging a lock which should have been released.
btw... there is a trick to activate the debugger 'just in time'. Instead of printing 'help file is locked' call LIB$SIGNAL with SS$_DEBUG as argument. Of course you may want to have DBG$INPUT and DBG$OUTPUT redirected to a (virtual) terminal instead of the screen for some innocent end user.
Speaking of which.. what kind of application is this? interactive - Green Screen' (SMG? FMS? DecFORMS?..), Web-services, Decnet tasks? ACMS...
Good luck!
Hein
>> Actually, because of the writing routine pre checks.
What are 'pre-checks', what is a 'write'.
I assume the write is the Fortran language write IO statement.
Are we typically taking about an new record ( RMS $PUT ) or update/re-write ( RMS $UPDATE).
Is the pre-check a Fortran Read to see if the record can be locked.
Hopefully that is done with generating a lock to make sure no other process sneaks in between the check and the actual act ?!
>> no ACCVIO error does really occur.
ACCVIO is NOT normal in OpenVMS applications.
It means that the application, and specifically the error handling, is broken. So you don't program a check to avoid it, you fix it!
>> What happens is that those pre checks throw up a pretty generic 'locked file error' that blocks other modules to access the file.
So _that_ should be you first order of business and may well make everything else go away. Improve that 'pre-check' to identify the file, key, possibly program image name, possibly calling module name(s).
>> Hein, your idea is to identify the file holder only when somebody else tries to access it, right? Sounds nice.
Correct. Like magic :-).
>> Using Just knowing the process name does not really help, because our entire system is compiled as only one executable.
There is that communication problem.
Be careful keep to modules, images, processes and threads well identified.
When you write process-name, I suspect you meant program name = image name
When I see process-name I think PROCESS-ID
= PID = unique process identifier in OpenVMS
= something to kill ( FORCE_EXIT ) to relase a lock.
It could be that the whole application is written as a single process juggling lots of (AST) threads to work for all users, but frankly I highly doubt that. Surprise me!
>> That's why it'd be necessary to identify the calling function name.
For the programs creating the locks (in the past) or for the programs running into a lock?
>> Another solution would be to pass the calling function name as an argument to the writing routine, but this would mean thousands of changes to be made throughout the code.
That's why we learned to write TPU MACROS, DCL or PERL scripts. :-).
>> PS.: Hoff, we are using logging and embedded print statements for debugging
Right. Hoff suggests that there are more often effective methods: debuggers!
But those would only work in the here and now. That is the program/process/thread running into the lock. It is 'tricky' to go back in time and start debugging a lock which should have been released.
btw... there is a trick to activate the debugger 'just in time'. Instead of printing 'help file is locked' call LIB$SIGNAL with SS$_DEBUG as argument. Of course you may want to have DBG$INPUT and DBG$OUTPUT redirected to a (virtual) terminal instead of the screen for some innocent end user.
Speaking of which.. what kind of application is this? interactive - Green Screen' (SMG? FMS? DecFORMS?..), Web-services, Decnet tasks? ACMS...
Good luck!
Hein
- « Previous
-
- 1
- 2
- Next »
The opinions expressed above are the personal opinions of the authors, not of Hewlett Packard Enterprise. By using this site, you accept the Terms of Use and Rules of Participation.
News and Events
Support
© Copyright 2024 Hewlett Packard Enterprise Development LP