- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- MULTINET_COMMON_ROOT on shared disk, when MULTINET...
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
01-28-2012 07:19 PM
01-28-2012 07:19 PM
MULTINET_COMMON_ROOT on shared disk, when MULTINET_ROOTs are on non-shared system disks?
Greetings,
We have two clusters on which OpenVMS (v8.4) and Multinet (v5.3) are installed to per-node system disks (on BL860c i2s) that are not shared. Common OpenVMS files have been moved to a shared disk. Is there a supported way to redefine/move MULTINET_COMMON_ROOT to that shared disk as well?
I've looked through the documentation and page 3-2 (146) of the Messages manual (http://www.process.com/tcpip/mndocs53/multinet_messages.pdf)says that the logical is defined in START_MULTINET.COM and should not be modified. So far, I haven't found any postings through here, Google, or Process Software's site that address this situation exactly.
Thanks in advance for any insight,
Michelle
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-29-2012 04:10 AM
01-29-2012 04:10 AM
Re: MULTINET_COMMON_ROOT on shared disk, when MULTINET_ROOTs are on non-shared system disks?
There's no information readily obvious in the Mutinet manuals around configuring that product for heterogeneous clustering; this sharing would appear undocumented and unsupported.
Process Software has a support-related mailing list available, per the Multinet Support Web Page, and a mailing list which would be a more direct resource than asking on a third-party forum.
Or assuming that you have Multinet support, call the Process folks directly and ask.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-03-2012 10:23 AM
02-03-2012 10:23 AM
Re: MULTINET_COMMON_ROOT on shared disk, when MULTINET_ROOTs are on non-shared system disks?
Update: I just called Process Software and the answer to my question is yes, it is possible to move MULTINET_COMMON_ROOT to a disk other than the installation disk. They are sending me the instructions for doing so.
It may have been one of the fastest support calls from hello to solution that I've made to anyone.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-03-2012 02:02 PM
02-03-2012 02:02 PM
Re: MULTINET_COMMON_ROOT on shared disk, when MULTINET_ROOTs are on non-shared system disks?
I stand corrected... the instructions received were for moving the installation to another disk, not for putting the common area on a different disk than the installation disk.
So, for now at least, the answer to my original question appears to be "no", after all.