Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

VAX 32bit to OpenVMS Alpha

SOLVED
Go to solution
GElkins
Advisor

VAX 32bit to OpenVMS Alpha

I have an opportunity to migrate a 32 bit VMS to OpenVMS/Alpha system. I believe I know for the most part what I need to know. I am curious is there a general checklist or rule of thumb that might simplify the task. I'll be migrating user accounts print Queues and networking. But no applications, and probably user files.
10 REPLIES
Jan van den Ende
Honored Contributor
Solution

Re: VAX 32bit to OpenVMS Alpha

gelkins,

as 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
Don't rust yours pelled jacker to fine doll missed aches.
Robert Gezelter
Honored Contributor

Re: VAX 32bit to OpenVMS Alpha

gelkins,

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
GElkins
Advisor

Re: VAX 32bit to OpenVMS Alpha

Thanks for the replies. I just finished a conference call with Sales and the Customer. The task is quite small. They are running VMS 5.5 and are going to VMS 7.3. There are only 15 users. They are currently using MultiNet printing. I will be building a TCP/IP stack using HP TCP/IP. I don't see any problem copying print queue settings as well; do you?
Jan van den Ende
Honored Contributor

Re: VAX 32bit to OpenVMS Alpha

gelkins

>>>
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
Don't rust yours pelled jacker to fine doll missed aches.
GElkins
Advisor

Re: VAX 32bit to OpenVMS Alpha

The version of OpenVMS will be 7.3.2.
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.
Jan van den Ende
Honored Contributor

Re: VAX 32bit to OpenVMS Alpha

gelkins,

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
Don't rust yours pelled jacker to fine doll missed aches.
Hoff
Honored Contributor

Re: VAX 32bit to OpenVMS Alpha

V7.3-2 is the lowest I'd suggest here, and I'd most definitely go newer if you can at all manage it. The current release, OpenVMS Alpha V8.3, will give you current ECOs or prior version ECOs through sometime around 2009 or so. And current bits and capabilities and tools.

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
Colin Butcher
Esteemed Contributor

Re: VAX 32bit to OpenVMS Alpha

Hello gelkins,

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).
Entia non sunt multiplicanda praeter necessitatem (Occam's razor).
Stanley F Quayle
Valued Contributor

Re: VAX 32bit to OpenVMS Alpha

If you're not bound to a particular application, or have all the source, why not go to Itanium? You can get a server for $3k through the porting classes, and migrate your environment while VMS engineers are present.
http://www.stanq.com/charon-vax.html
GElkins
Advisor

Re: VAX 32bit to OpenVMS Alpha

Hello,
Sorry about the point thing I did not know how important it was.
There have been updates I am going to OPENVMS 8.3 and found out that I only have less then 10 users. I plan to just recreate them on the new systems. As for print queues I only need two and I have all of te setting.

I will finnish this project next week and will update the forum.