HPE GreenLake Administration
- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- SHOW PROCESS/CONT shows PC=2BAD2BAD.CODE2BAD?
Operating System - OpenVMS
1829745
Members
1213
Online
109992
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
Forums
Discussions
Discussions
Discussions
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
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
02-26-2010 09:40 AM
02-26-2010 09:40 AM
Re: SHOW PROCESS/CONT shows PC=2BAD2BAD.CODE2BAD?
Michael,
maybe that file was not permanently open ?!
DEL_EXTFCB was being called 23 times per second to delete those 2000+ FCBs (one FCB per extension file header). This gives about 46000+ FILSYS acquisition and releases per seconds for each of all the 6 routines involved, giving about a total 276000+ acq/s. SPL.COM reported about 332000 acq/s, so this was pretty close...
So everything I concluded from the data you've provided seems to have been true ;-)
Nice problem and analysis,
Volker.
maybe that file was not permanently open ?!
DEL_EXTFCB was being called 23 times per second to delete those 2000+ FCBs (one FCB per extension file header). This gives about 46000+ FILSYS acquisition and releases per seconds for each of all the 6 routines involved, giving about a total 276000+ acq/s. SPL.COM reported about 332000 acq/s, so this was pretty close...
So everything I concluded from the data you've provided seems to have been true ;-)
Nice problem and analysis,
Volker.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-26-2010 12:53 PM
02-26-2010 12:53 PM
Re: SHOW PROCESS/CONT shows PC=2BAD2BAD.CODE2BAD?
From what I can tell, MQ opens, writes one line to and closes the file each time, so it appears you are correct. Perhaps the file is considered actually open for such a short period of time I never caught it with SHOW PROCESS/CHANNEL.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-27-2010 06:15 AM
02-27-2010 06:15 AM
Re: SHOW PROCESS/CONT shows PC=2BAD2BAD.CODE2BAD?
As far as I know, for deleting the extension FCBs the DEL_EXTFCB code aquires the FILSYS spinlock once. It holds it until it moved all the extension FCBs to a local queue. After releasing it, it actually deletes the FCBs from the local queue. Moving one FCB however requires to decrement a count in the VCB. To find the VCB the code always walks all the remaining extension FCBS which "end" in the VCB.
The high acquisition and release rate for FILSYS are in other routines for example MAP VBNs. The long waits are in MAP VBNs from other PIDs. It didn't only take much time to delete all the extension FCBs, it also blocked other applications "on this disk".
It very likely looks like MQ tried (still tries?!) to mimic Unix behavior on VMS, where you can always see what's just written at the end of a (log) file. At least for some situations there are better ways than to open/close.
The high acquisition and release rate for FILSYS are in other routines for example MAP VBNs. The long waits are in MAP VBNs from other PIDs. It didn't only take much time to delete all the extension FCBs, it also blocked other applications "on this disk".
It very likely looks like MQ tried (still tries?!) to mimic Unix behavior on VMS, where you can always see what's just written at the end of a (log) file. At least for some situations there are better ways than to open/close.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-28-2010 03:14 PM
02-28-2010 03:14 PM
Re: SHOW PROCESS/CONT shows PC=2BAD2BAD.CODE2BAD?
>It very likely looks like MQ tried (still
>tries?!) to mimic Unix behavior on VMS,
>where you can always see what's just written
>at the end of a (log) file. At least for
>some situations there are better ways than
>to open/close.
Not that it helps with your MQ code...
If you want to be able to see the end of a "live" file, rather than force an update of the file on every write (frequent and expensive), it's better to put the resource burden on the reader. So, every time you want to read the file, you do something to make sure the EOF is up to date. Since reading is likely to be much less frequent than writing, the overall cost is far less.
The simplest way to achieve this in OpenVMS is for the writer to open the file SHARE=READ+WRITE. A process wanting to read the file opens it for APPEND access SHARE=READ+WRITE then closes the file. This causes the existing writer to flush all buffers and update the EOF mark. You can now re-open the file READ access SHARE=READ and see recent output.
Note that even if you don't have access to the source code, you can usually trick any program into shared write using a process permanent file with a small DCL jacket:
$ CREATE/FDL="RECORD;FORMAT STREAM_LF"
$ OPEN/APPEND/SHARE=(READ,WRITE) LOG
$ DEFINE/USER SYS$OUTPUT LOG
$
$ CLOSE LOG
now the reader side:
$ OPEN/APPEND/SHARE=WRITE LOG
$ CLOSE LOG
$ TYPE/TAIL
A crucible of informative mistakes
- « 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.
Company
Events and news
Customer resources
© Copyright 2025 Hewlett Packard Enterprise Development LP