Migration

[Clayton_12]

We are in the preliminary phases of migrating a 6.2 openvms system on an Alpha 2100 to a 7.3 Openvms system on an ES45.

Anyone know any good roadmap documents for such a move?

What is the best way of migrating the user and rights database?

What is the best way of transferring files, data, and associated security?

Thx
Clayton

[Robert Brooks_1]

My suggestion would be to upgrade to the current version of OpenVMS Alpha, which is V8.2. If that is not possible, please consider
upgrading to V7.3-2.

-- Rob

[Uwe Zessin]

- there is a separate manual that deals with operating system upgrades. It's been some time that I looked into it, but I was postive surprised about its quality!

- if the upgrade is not time critical, I would do a full backup on the AS2100 and do the upgrade there (I don't think the ES45 can boot OpenVMS V6.2 ;-) This will keep UAF, RIGHTSLIST and so on intact.

- again, it depends on hardware (do you have compatible tape technology?) and time...

Do you have clustering licenses or can organize some just for the time during the transfer? How about booting the ES45 as a satellite to the AS2100 and then moving all data with BACKUP? If you can do 1:1 disk backups with BACKUP/IMAGE you will even retain all file and directory dates.

[Jan van den Ende · Accepted solution]

Clayton,

good answers given already!

First:
Can you find ANY reason NOT to go to 7.3-2?
Soooo much preferable over 7.3 (you know that one is already no longer on support).

8.2 might be a good plan, _IF_ all your apps run unadapted. No real guarantee there.

Personally, I much like Uwe's temporary cluster idea!

A temporary license should be ABSOLUTELY no problem (if policies have not changed, you get any 60-day license FREE). AFAIK it is not uncommon to get such for migration purposes, for the duration of said migration.

a. configure the ES45 to be a single-node cluster, and a BOOTSERVER.
Make sure to have all your disk labels unique over your entire site.
You might use one disk to build a 7.3-2, and another to build a 8.2 environment. Now you can evaluate BOTH!

A1. Look at the new INIT qualifiers. INIT all disks with /SIZE = 2G blocks( 1 Tbyte )/CLUS=8 (and any other params you wish)

b. upgrade your system to the latest patches (just do _NOT_ use 732 SYS 600 !! Stop at 500, or check if 700 already there.
The home page of www.openvms.org has a direct pointer.)

c. configure the 2100 as a satellite of the ES45 (we had EXACTLY that during our migration!)
Define SYSUAF and RIGHTSLIST /EXEC/SYSTEM to the filespecs of those on your 2100.

d. NOW is the time to check ALL your applics, still on the old environment, on the 2100, running under 7.3-2 (& 8.2)

e. supposing there are any issues, NOW is the time to deal with those.
You MAY run into the need to re-link the odd applic.

f. based upon e.), choose 7.3-2 or 8.2.

g. Shut down all applics, and do
$ BACKUP olddisk:[*...] newdisk:[*...]/OWN=ORIG/TRUNC
As long as your topdir names are not the same, you might put various 'olddisk's onto the same 'newdisk'.

h. This one depends on the neatness of your config:
If yours is 'very well-set up' environment (ie, NO direct disk references, but everything organised in concealed devices), then all you got to do is redefine those.
If you use a lot of direct references, then you may re-define your old device names to point to the new ones.
$ DEFI/SYST/TRAN=CONC/EXEC 'olddev': 'newdev':
Only THEN, you have to make #$%^&* (censored) sure that _NEVER EVER_ will _ANY_ new device spec coincide with an old one !!!!!!!!!!!!!!!!!!!!!!!


This should get you going, I guess.

Any unclear parts? _ASK_ !! before going wrong.

All in all, you picked by far the easiest OS for the trick.
It really _IS_ simple, if you stick to these guidelines.


SUCCESS!!

Again, any question or doubt, ASK.

And if you are done, please report back.

Proost.

Have one on me.

jpe

[Clayton_12]

I will ask before going on.
The responses are great, I like the cluster Idea . I was sort of thinking that would be a good approach, but a little concern about implementing it. It is a operational system for our science sector that corporate IT has inherited. We don't want any down time

We are on a learning curve for supporting this system. It'll take me a while to reguritate this advice. But I would appreciate if you guys would stay tune for further advice once I learn what to ask.
Hopefully late next week.

Thx so much
Clayton

[Robert Gezelter]

Clayton,

I second the advice that has been mentioned.

It is possible to do this evolution with insignificant downtime, I have done it. A word to the wise is to make sure that you work on a clone of the production system disk.

You will be installing updated layered products, which can take some elapsed time.

The best way to make this smooth is:
- ensure that there are no user files on the system disk
- clone (use BACKUP to perform and /IMAGE copy of the system device)
- do the updates on the clone of the disk.
- switch the disks (and copy over the latest SYSUAF and RIGHTSLIST files). You may need to do a merge if any of the products created accounts or identifiers.

In this way, you always have (for the users at least) a zero-impact way to fallback to the prior state if a problem is discovered.

Also, I would recommend 7.3-2. 7.3 is no longer supported.

I hope that this is helpful. I have followed these procedures when I upgrade clients and it is almost always a smooth cutover.

- Bob Gezelter, http://www.rlgsc.com

[Robert Gezelter]

Clayton,

I just noticed that your profile shows that you are in Canada.

If you will be in the Edmonton area on May 19th, please accept an invitation to my lunch presentation on "OpenVMS on Integrity Servers: Migrating From Alpha", hosted by Encompass Canada/EARLUG. The meeting announcement can be found at http://www.rlgsc.com/encompass-canada/edmonton/2005-05/announce.html

- Bob Gezelter, http://www.rlgsc.com

[Clayton_12]

Still out here. Slowly delving into the VMS world.
Looks like we have a change. We will now be installing to a DS-20 box. instead of ES45.
Looks like a couple of weeks before I get my hands on the box.

Anyway not entirely comfortable with clustering idea. Basically we don't what to fool with operational system until new system is up and rolling.

After new install 0f 7.3.2 or 8.2 on the DS-20:

WHat is the best way of migrating the UAF and rightlist files to new system?

What is the best way of copying datafiles while preserving associatied ACLS?

Thanks
Clayton

[Jan van den Ende]

Clayton,

the best way (the only good one?) is BACKUP.
Let us look at SYSUAF & RIGHTSLIST first.
If you can be very sure your source system is not in use, you can simply copy them.
Any doubt on that:
$ ANALYSE/RMS/FDL/OUT=SYSUAF.FDL
$ CONVERT/SHARE SYSUAF SYSUAF.COP /FDL=SYSUAF.FDL
(If you have defined LNM SYSUAF, else convert SYSUAF.DAT. Mind, if defined, the /FDL file type will not be able to default to .FDL )
Repeat for RIGHTSLIST.
Move results to new system (any way convenient).
Now, easiest is to REBOOT, which will add the new system info to your RIGHTSLIST file (if you want full control over that, can be done, but stuff for its own thread)

Depending on your diskconfigs, you MAY be able to simply restore each old disk to a new disk, in which case BACKUP/IMAGE is all you really need. But you will want to INIT your disks first with /CLUSTER=8/LIMIT=20000000000 (that is, enable your disks to grow to 1 TB ) and add /NOINIT to the backup command. ALL file security settings will be preserved.
If you merge some old small disks onto a bigger one (which is probable) then you can use /IMAGE (to a foreign MOUNTed disk) for the first, but following source disks can not use /IMAGE without destroying previous work. Now you have the target MOUNTed, and use [*...] as output spec. To preserve security info you now need to specify /OWN=ORIG as well!!

And that should be really all there is to it.

Been there, done that.

Success

Proost.

Have one on me.

jpe

[Lawrence Czlapinski]

Clayton,
CLUSTER: I would cluster the new system on a separate cluster available system disk if you have a cluster license. You would need additional temporary licenses though. That is the easiest way. That way after the application groups are successfully tested on the new OS, you can change that application group over to the new system. Then you can change the application groups over by shutting the application down on the old system and redefining the relevant directory logicals from test to new production.
OS: Since your migrating, you would be better off migrating to 7.3-2. You should check how long your vendors will support 7.3-2. They probably no longer support 7.3 under standard maintanence. So I also recommend upgrading the new system to 7.3-2 first. We have 4 standalone production alphas that have been running on 7.3-2. Install latest TCPIP, that you use, on the new system disk.
System Files: The best way to copy active system files is to use CONVERT. It was discussed in this forum in a discussion of how to BACKUP system files that are always open. Adding of accounts and password changes should be done on the old system. The old system's SYSUAF file should be copied over daily until you switch to using the new system's SYSUAF file. This is the first thing I would switch over. Then try it from the old systems. Otherwise you would have to reboot the new system periodically to pick up the new SYSUAF.
QUEUE MANAGER: Separate queue files in a cluster can cause problems unless you're using multiple queue managers which we haven't tried.
MODPARAMS.DAT and SYSGEN: Adjust the SYSGEN QUORUM and VOTES as needed.
RECOMPILES: For a major version change, 6.x to 7.x, you will need to recompile and relink, to ensure compatiblity.
VENDOR APPLICATION VERSIONS: The biggest problems will be with applications. You will need vendor applications which will work on the new operating system. You will have to see if your vendors support 7.x.
TEST DIRECTORIES: The best way of transferring files, data and associated security is by using logicals to switch between test and production. Test your applications on the new system. You could switch the applications over as you verify that they work after making a backup of the application databases, if any, with the application shutdown. That way you have a database to fall back to if a problem occurs. The advantage is that you can reduce downtime related to switching over to the new system. You should use test directory logicals till you verify that they are working with the new hardware and OS.
Lawrence

[Lawrence Czlapinski]

Clayton, the last time we switched a cluster over to new hardware we had started to develop on a non-clustered system. We wound up clustering so the applications developers could phase the applications over to the new hardware. You do need separate directories for your new compiles and links.
Lawrence

[Bojan Nemec]

Clayton,

I agree with all others. Upgrade to 8.3 or 7.3-2. But you are running 6.2 so the first thing is to upgrade to 7.3 because there is no direct upgrade path from 6.2 to 7.3-2 or 8.2.
For 8.2 you need 7.3-1 or 7.3-2.
For 7.3-2 you need one of this 7.3-1,7.3, 7.2-2, 7.2-1, 7.2-1H1, 7.2.

So you must do a 2 or 3 step upgrade to get 7.3-2 or 8.2.

The minimal required operating system for DS20 is 7.1-2 or 7.2 (see http://h71000.www7.hp.com/openvms/hw_supportchart.html
)

One way to upgrade and test to the new system is:

Do image backup off your system disk. Boot the new DS20 from the CD (probably 7.3) and restore this backup on the new system disk. Dont try to boot from this system disk the VMS version is too low! Now still running VMS from the CD upgrade the operating system. Now you can boot, because the operating system is enough high. Backup data disks on the old system and restore them on the new system. Test all applications.

The good thing of this method is that you have the old system untouched in the testing peiod. Users can normal work on the old system. (you will need to repeat the whole operation once more after the testing period).

Be shure to not have both systems attached to the same network. The best way is to unplug the network cable of the new system. You can change network settings after the upgrade and then you can plug in the cable.

Bojan

[Doug Phillips]

Clayton,

It sounds like you won't be using the temporary cluster method.

One little point that's probably obvious: Don't add any users to the new system and don't change anything via AUTHORIZE before you copy over the sysuaf.dat, rightslist.dat,(etc). Do all of your new system work under the SYSTEM login prior to that.

Look in the SYS$STARTUP:SYLOGICALS.COM file for a list of other files you might need to take to the new system (the new system's sylogicals will have a more complete list).

Also, how do your users connect? Will they need to have anything changed? There have been pretty good discussions about this here before.

Anyway, Backup will retain your data file acl's and ownerships. Copy the SYSUAF and other files to the new system, then when you restore the data to the new system use the output file qualifier /BY_OWNER=ORIGINAL (/by=orig).

-Doug

[comarow]

PPlease go to a supported version, such as 7.3-2. It has many advantages, like a dedicated lock manager, moving areas of memory our of s0 so they don't conflict.
And you can do an engineering update.

Make sure your software runs at the new version or get new versions.

1: Backup. Backup after each phase.

2: The best thing is to have a shadow set,
take one out and you can always go back.

3: SAVE GOOD RECENT FEEDBACK. Upgrades run autogen, and the feedback must be within 30 days and for at least 24 hours old. Don't save feedback during the upgrade process, it will be meaningless.

Make sure your system is autogenable before the upgrade (often people make changes in sysgen and forget to put it in modparams.dat), then blame autogen.

4:Preserve will maintain your settings.

5:Upgrade to the latest firmware. First.

6:It will take stages, you can't go to 7,3-2 in one stage. First 6,2-X to 7.2-1 is supported.

7: Backup after the upgrade.

8: Install the latest ECOs for your new version.

9: Autogen with feedback several days after the upgrade.

Bob

[comarow]

I thought I should ask the obvious, do you have a software contract for HP. If you do,
we maintain updated articals called the
Upgrade Checklist. I would be very pleased to send them to you.

It will require two steps.

Don't be afraid of clustering. In the long run it greatly reduces system's management time and improves reliability. It also offers ways of fixing one system from another system.

[Wim Van den Wyngaert]

I would go for a complete clean build cluster (or node).

Starting from zero and migrating the sysuaf records that are needed. Otherwise you take all the dirt that was accumulated on 6.2 (and even older versions) with you to the new system.

This way you have the quotas, identifiers, uic codes etc as needed by the new VMS version.

We have found no application programs compiled on 6.2 that gave problems on 7.3 (but they might exist).

When moving programs to 8.2 there were a few problems (e.g. with freeware mmk, replaced it by new version).

fwiw

Wim

[Clayton_12]

Lot's of goood info in this thread. I certainly appreciate the feedback. I'm learning by leaps and bounds.

Bob : Yes we do maintain a software support agreement?
What is two step process?
and where are the Articles?


Looks like the way I'll try the upgrdae is by backing up system disk from existing 2100 and try upgrading to 7.3 on the DS20.
Then to 7.3.2 and maybe upto 8.2.

Is there a good way of getting all these media versions?

I have my hands on the 6.2 CD, but apparently there was an UPgrdae to 6.2 1-3h at one time.

Is it possible to run those backup prodeures on 6.2-13H from the 6.2 CD?

[Jan van den Ende]

Clayton,

about the "effort" of clustering:

Let the necessary effort for one system be 1.

Obviously, two systems require 2, n require n.

If there is need for some coordination, n gets raised to some power m > 1 (typically, 1.1 to 2, depending on the value of "some")

A fully heterogenous cluster (NOTHING shared) comes close to that.
ANY sharing you add lowers m.
If you reach full homogenity, m can get as low as 0.1
That means, as soon as you start to get some integration, you start to profit.
A fully homogeneous cluster really requires only very little more effort than a single system does.
Add bonusses such as maintenance without downtime (at the cost of some extra planning!)

Proost.

Have one on me.

jpe

[Ian Miller.]

V6.2-1h3 was a limited hardware release and its not necessary to upgrade to that from V6.2.

As you can't go from V8.2 to V8.2 in one step hence the mention of two step process. You have to upgrade to an intermeditate version. See
section 5.10
http://h71000.www7.hp.com/faq/vmsfaq_007.html

I guess V6.2->V7.2-1 -> V7.3-2 -> V8.2

[Doug Phillips]

>>>
...by backing up system disk from existing 2100 and try upgrading to 7.3 on the DS20.
<<<

Clayton,

Please see the link provided by Bojan. The DS20 will *NOT* run v6.2x. You need to either: upgrade to 7.x on the 2100 first; do a fresh install on the DS20 and copy files to that system; use the cluster method.

-Doug

[Doug Phillips]

Please see the link provided by Bojan.


Rereading Bojan's post, I see that he told you not to try to boot the DS20 with v6.2. That method will work fine and is no doubt what you were saying you will do. Sorry for the mis-post.

-Doug

[Jan van den Ende]

Clayton,

a word of warning, if you go Wim's route of fresh SYSUAF & RIGHTSLIST (his reasons are worth thinking about!)

_IF_ you are going clean, then I remember you said wishing to maintain Identifier-security.

For that you need a printout from UAF> sho iden */full

Then you will need to enter each identifier you want to keep _WITH_ its /VALUE and its /ATTRIB qualifier.

If not, the named IDs get created with the next-higher value, which previously had a totally different meaning! As long as you stick to pure-numeric use (but who does do that) that will do, but your named access to them will be an unpleasant surprise!

Proost.

Have one on me.

jpe

[Wim Van den Wyngaert]

If you don't go for a clean system, compare the quotas of the system account and all related tcp and decnet stuff with the quotas of the clean system.

I noticed that under 8.2 e.g. anal/dis/rep is using a lot more memory and quotas of 6.2 might be too low.

Also : I have systems on which the identifier database is a complete mess (someone merged several systems errorneous). Migrating such a mess is not healthy ...

Wim

[Clayton_12]

I'm closing this thread. Lots of sage advice. I have learned a lot.


However I haven't had the opportunity to check them all out yet.

I now have a test box so I will eventually get to further checking out these suggestions. However first I have ti get aan install working:-)


The responses have been very helpful in analysing options for moving forward.

I look forward to continuing advice from the forum as I climb the OPenVMS learning curve.

Thank You all