HPE GreenLake Administration
- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- DECW$SERVER computable
Operating System - OpenVMS
1828047
Members
2310
Online
109973
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
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
01-31-2007 08:15 PM
01-31-2007 08:15 PM
DECW$SERVER computable
We have two Itanium rx2620 with OVMS 8.2-1. We sometimes find both of them blocked: no access from the console is possible. With a network login (set host or telnet) we have found CPU load al 100% and DECW$SERVER computable. The uptime seems to be one month. The console is the unique graphic port on the management card and it is used only few hours a week with DECterm. DECW$STARTUP RESTART is not useful and seems to get a worse situation (access via network is no more possible).
1 REPLY 1
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-01-2007 01:53 AM
02-01-2007 01:53 AM
Re: DECW$SERVER computable
That's likely a bug. Somewhere.
Check the firmware revisions for the various boards involved -- MP, etc -- and check the patch level for OpenVMS, and then ring up HP support and ask.
There have been MP firmware revisions for various Integrity servers, and there have also been mandatory OpenVMS ECOs and ECOs for various DECwindows components over the years. Any of which could conceivably remediate a problem (somewhere) that triggers a loop (somewhere else) that causes some piece of DECwindows to go computable.
PCSI and UPDATE ECOs would be a start; the master ECO list and the released ECO kits are available at ftp://ftp.itrc.hp.com/openvms_patches/i64/V8.2-1/
After the mandatory and the relevant ECOs, the next step would involve doing some PC tracing, to figure out where the looping is occurring within the particular components, and working backwards from there to sort out why this is arising. (This is where HP services generally gets involved.)
I'd probably apply ECOs and any new firmware when scheduling permitted, leave the box to loop again, then -- if the loop arises anew -- try to use SHOW PROCESS/CONTINUOUS to capture some PC addresses in the looping process (to get an idea where in the code the loop is occurring), and I'd then force a crash and write out a crashdump for HP to look at.
As a potential work-around pending ECOs and any response from HP, disable DECwindows (there's a logical name used for this in SYLOGICALS.COM or such, DECW$IGNORE_WORKSTATION) and use a serial or MP connection into the box.
Check the firmware revisions for the various boards involved -- MP, etc -- and check the patch level for OpenVMS, and then ring up HP support and ask.
There have been MP firmware revisions for various Integrity servers, and there have also been mandatory OpenVMS ECOs and ECOs for various DECwindows components over the years. Any of which could conceivably remediate a problem (somewhere) that triggers a loop (somewhere else) that causes some piece of DECwindows to go computable.
PCSI and UPDATE ECOs would be a start; the master ECO list and the released ECO kits are available at ftp://ftp.itrc.hp.com/openvms_patches/i64/V8.2-1/
After the mandatory and the relevant ECOs, the next step would involve doing some PC tracing, to figure out where the looping is occurring within the particular components, and working backwards from there to sort out why this is arising. (This is where HP services generally gets involved.)
I'd probably apply ECOs and any new firmware when scheduling permitted, leave the box to loop again, then -- if the loop arises anew -- try to use SHOW PROCESS/CONTINUOUS to capture some PC addresses in the looping process (to get an idea where in the code the loop is occurring), and I'd then force a crash and write out a crashdump for HP to look at.
As a potential work-around pending ECOs and any response from HP, disable DECwindows (there's a logical name used for this in SYLOGICALS.COM or such, DECW$IGNORE_WORKSTATION) and use a serial or MP connection into the box.
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
Support
Events and news
Customer resources
© Copyright 2025 Hewlett Packard Enterprise Development LP