- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: VAX 32bit to OpenVMS Alpha
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
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
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
тАО02-16-2007 06:16 AM
тАО02-16-2007 06:16 AM
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-16-2007 06:35 AM
тАО02-16-2007 06:35 AM
Solutionas long as it is not compiled code:
JUST move it!
If you take precautions to preserve ownerships and protections, AND you make sure that SYSUAF and RIGHTSLIST are also copied, you even preserve your entire security setting.
Should you do clustering: ADD the Alpha to the cluster, "commonise" your control files (aforementioned plus queue control) and you HAVE moved! All your accesses and securities are identical from bith architectures, and your ques are accessible from both.
We did it that way.
hth
Proost.
Have one on me.
jpe
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-16-2007 06:53 AM
тАО02-16-2007 06:53 AM
Re: VAX 32bit to OpenVMS Alpha
Concur. You will want to preserve the UAF and RIGHTSLIST files, and all of the other profile information.
Be prepared to re-tune the various parameters. In some cases, you may want to write a DCL script that will adjust all user accounts, in other cases you will want to force minimum values in the the parameter file.
If you are not migrating applications code, it should be straightforward. I have done this many times for clients, without incident.
- Bob Gezelter, http://www.rlgsc.com
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-16-2007 07:16 AM
тАО02-16-2007 07:16 AM
Re: VAX 32bit to OpenVMS Alpha
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-16-2007 07:43 AM
тАО02-16-2007 07:43 AM
Re: VAX 32bit to OpenVMS Alpha
>>>
They are running VMS 5.5 and are going to VMS 7.3.
<<<
I MOST STRONGLY suggest to make that at least 7.3-2 !!!
Although prior version, THAT is still supported (and the ONLY V7.x at that).
I now I have to concur with Bob, that you probably want to adjust some UAF settings. There have been several advises to raise some (specially memory usage) settings since V5.
>>>
They are currently using MultiNet printing.
I will be building a TCP/IP stack using HP TCP/IP.
<<<
Having no direct experience with Multinet, so just a comment on TCP/IP services printing.
That is done either using LPD/LPR, or TELNETSYM. If you are using ANY que-, page, form-, or sepatation modules in you queues, then definitely go for the TELNETSYM!! LPD/LPR has no concept of job-streams, so EACH module is dealt with as a separate file, with potential intervening jobs, and device RESETs straight after your careful setup module, before the body of your document... :-(
hth
Proost.
Have one on me.
jpe
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-16-2007 07:52 AM
тАО02-16-2007 07:52 AM
Re: VAX 32bit to OpenVMS Alpha
One more time thank you for your ideas. I will be starting this upgrade on Tuesday. If I have problem I plan on using this forum as a resource.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-16-2007 07:57 AM
тАО02-16-2007 07:57 AM
Re: VAX 32bit to OpenVMS Alpha
Upon re-reading I realised one thing:
Forget the idea of moving-by-clustering: V5 Vax and V7 Alpha will simply refuse to be together in one cluster. Pity, but they are just too distant.
Proost.
Have one on me.
jpe
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-16-2007 09:25 AM
тАО02-16-2007 09:25 AM
Re: VAX 32bit to OpenVMS Alpha
With respect to the other folks here, if this is just moving application data, I'd move that. But I'd be seriously tempted to recreate the users and such and not move those pieces over. The quotas are quite different, and you may end up spending as much time fixing (or creating a tool to fix) those as recreating a new set of usernames.
The typical OpenVMS VAX username quotas tend to be inadequate. That's on OpenVMS VAX. Moved over onto OpenVMS Alpha, they're going to provide poor performance.
If you do choose to move pieces, the biggest "fun" tends to be the binary identifier values that can get attached to objects. This means you should move over the authorization giblets (if you're going that route) and then start installing and configuring stuff. I'd not move over the LP-related username pieces; I'd let the newer versions of LPs recreate these as required. There are various discussions of these around ITRC and comp.os.vms.
And a minor tweak: I'd probably rename the existing sys$node_[name] identifier with a RENAME/IDENT, if you've moving the rightslist across. This preserves the binary value.
There are manuals on the topic of migrating from VAX to Alpha in the retired or archived section of the HP OpenVMS documentation web site. These go through the migration, provide the typical checklists, and discuss command and operational-level differences. http://www.hp.com/go/openvms/doc/ -- look in the left navigation for "archived documentation".
Disclosure: HoffmanLabs provides these sorts of OpenVMS migration services. VAX to Alpha, VAX to Integrity, etc.
Stephen Hoffman
HoffmanLabs
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-17-2007 01:14 AM
тАО02-17-2007 01:14 AM
Re: VAX 32bit to OpenVMS Alpha
Like Hoff, I'd go with a clean build. Write yourself a DCL command procedure to create all the accounts, proxies, rights identifiers and so on from scratch, then move the data across. Nothing wrong with preserving all the UICs and rights identifiers - in fact I usually try very hard to do so when I'm helping people do this kind of thing.
Base the command file on listings outputs from the UAF, rightslist, proxy database, queue database etc.
Write a sensible MODPARAMS.DAT as well.
It's probably a bit more work this way, but the end result is a cleaner system without much inherited junk.
If you can then go to at least OpenVMS Alpha V8.2, failing that then V7.3-2 as an absolute minimum.
View it as a good opportunity to create all the queues and so on with DCL command procedures. That way you stand a good chance of eliminating all those unrecorded changes done on the fly. Makes life so much easier.
Cheers, Colin (www.xdelta.co.uk).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-17-2007 01:25 AM
тАО02-17-2007 01:25 AM