Switching Over to New System

[James LaRue]

How hard would it be to move an old VAX 3100 system and a VAX 4000 system over to the newer Alpha systems? Will the old VMS software run on the newer OpenVMS without any problems?

[Volker Halle · Accepted solution]

James,

welcome to the OpenVMS ITRC forum !

OpenVMS Alpha runs on the Alpha processor, whereas OpenVMS VAX runs on the VAX processor. Both have different HW architectures and instruction sets.

You would need to install the OpenVMS Alpha operating system. All your application .EXE files would typically need to be re-compiled (from source) and re-linked, although there is also a binary translator (called DECmigrate or VEST), which can translate VAX instruction in .EXE files into Alpha instructions at a noticable performance loss.

May I also point out the possibilty to run OpenVMS VAX operating systems and programs using the CHARON-VAX emulator (commercial product) or simh (freeware) ? This is a software emulation of the VAX hardware machine and runs on various host operating systems (e.g. Windows, OpenVMS Alpha and Itanium, Linux). You must see it, to believe that it works, but it does !

Volker.

[Steven Schweda]

It depends on too many things to give an
answer with so little information.

DCL command procedures will probably work.

All compiled programs would need to be
recompiled, as the VAX and Alpha instruction
sets differ. Some (most?) code works with no
changes; some needs serious effort to get it
to work.

Some HP and third-party software may be
unavailable.

Some specialized hardware may cause extra
difficulties.

There are some migration-related documents
available at:

http://h71000.www7.hp.com/doc/archived.html

Migrating an Application from OpenVMS VAX to OpenVMS Alpha

Migrating an Environment from OpenVMS VAX to OpenVMS Alpha

Migrating to an OpenVMS AXP System: Recompiling and Relinking Applications

Migrating to an OpenVMS AXP System: Planning for Migration

The fact that they're included on a page
named "archived.html" suggests that you're
not the first person to try this.

You might also skip straight to Itanium, but
almost any work you need to move to Alpha
would be useful for a later move to Itanium.

[James LaRue]

Thanks Volkre for your response.

My main question is that I have a program that is very very important that runs on the VMS operating system that I would like to be able to work on the newer hardware as I really really need to upgrade. But I am scared that there will be a lot of software reworking to get it to work. But if there is a way to get it to work without rewriting the software completely then that would be great too. Cause in reality this upgrade is just for hardware support as the current system has been working wonderfully for 20 years.

[Steven Schweda]

> All compiled programs would need to be
recompiled

Oops. I completely forgot about VEST.

[James LaRue]

Steven,

thanks for the response.

this system is vms not openvms...it is really old I think version 5.5 or something like that. I have everything written down but I am not where the information is. Basically it is a 32 bit program..so i figure it wont be transferable to the newer 64 bit system.

[Volker Halle]

James,

if this is an important application for you, I definitely would suggest the CHARON-VAX emulator. Depending on your current HW config, you may not need to change ANYTHING from the application and OpenVMS VAX perspective, if you can emulate all your hardware devices using CHARON-VAX.

I would suggest, that you try to find a CHARON-VAX reseller near you. Try

http://www.softresint.com/charon-vax/index.htm

Volker.

[Steven Schweda]

If you would like to experiment on an Alpha
(or Itanium) system at no cost, there are HP
TestDrive systems available. You could FTP
your application kit to one of the TestDrive
machines, and see how difficult it is to
build. Depending on resource requirements,
serious testing may be more difficult, but
it could be a very educational exercise.

http://www.testdrive.hp.com/

Whenever I move some VMS software to a
different hardware platform, I'm always
amazed at how much stuff just works.

[Steven Schweda]

> this system is vms not openvms

Them's fightin' words...

You need to read the [Open]VMS FAQ:

http://h71000.www7.hp.com/faq/openvms_faq.html

2.2 What is the difference between VMS and OpenVMS?

VMS and OpenVMS are two names for the same
operating system. [...]


See? It's already an educational experience,
and you've hardly started.

I've built and run the Info-ZIP Zip and UnZip
programs run on systems from VMS VAX V5.4 to
Itanium V8.2-1, so age by itself is no
guarantee of trouble. (There are some "#if"
directives in the code, of course, but not
so very many, I'd say.) You can assume that
some changes will be needed, but the number
and scope are tough to predict.

[Ian Miller.]

Read the migration documents previously mentioned. See also
http://h71000.www7.hp.com/openvms/integrity/transition/index.html
http://h71000.www7.hp.com/openvms/integrity/resources.html

It depends on the system. If it is really a unchanging application then do look at the emulated VAX option. If the application is likely to be changed in the future then do consider porting to OpenVMS Itanium. This can be remarkably straigtforward or it can be a lot of work but this very much depends on the application.

There are a multitude of considerations - you may wish to find yourself a consultant who has done this before.

[Ian Miller.]

See also the whitepaper

Making the transition from HP OpenVMS VAX to HP OpenVMS on Integrity servers
http://h71028.www7.hp.com/ERC/downloads/5983-2722EN.pdf

[James LaRue]

Yes I would like to port it over to OpenVMS Itanium 2...that way I can get the best of both worlds. Being that HP isn't gonna be upgrading the Alpha system anylonger after this current processor.

I will work on getting a copy of our software and try to run it on one of these free systems and see how well it works. I think that will be my project for the next couple of weeks.

[Arch_Muthiah]

James,

I too in the process of moving my VAX application to HP Integrity server.

Along with the link info mentioned above, you can go through this link aslo.

http://www.migrationspecialties.com/Port-VAX-Integrity.html

May I know what languages/utilities have been used in your current VAX/VMS application?


Archunan

[Allan Bowman]

The ease of migrating/porting to Alpha or Itanium depends on what your application is doing. If you are doing real-time processing and using AST's, etc., there may be a lot of reworking of your programs required.

If the application doesn't do anything too fancy, you may be able to proceed by simply recompiling on the new machine - you will probably get some errors that require minor code changes, but it should go fairly smoothly.

I came from a company where we used AST's, mailboxes, and global sections extensively in a realtime application and determined a number of years ago that it was too big a project to get the code to run properly on an Alpha (we recompiled, got rid of errors, and still had problems getting our application working properly). We ended up staying on our MicroVAX 3100-85 systems (and the application still has not migrated - we stocked up on spare machines from eBay).

Allan in Atlanta

[Ian Miller.]

Allan, I'm curious - AST's, mailboxes, and global sections - are all standard VMS constructs and available on alpha and itanium vms. What problems did you have porting your code to alpha? From my experiance alignment issues (the compilier aligning and padding structures) caused much fun with data structures in global sections. I don't recall any trouble with ASTs or mailboxes.

[Allan Bowman]

Ian,

It was how we were using them in combination. But I'm just the sys admin...

What I gathered from one of the programmers was that because of the way we were doing things, there was no guarantee that various processes would receive messages in the proper order. This was not a problem on the VAX.

Our application was a realtime telephony process where we used VMS to control a telephone switch and a number of Voice Response units. It was possible to have as many as 2,000 concurrent calls in progress and we used the global sections to store all of the control data and call records for all current calls. When testing on an Alpha with a relatively light load (48 concurrent calls), we were getting call data stuffed into the wrong records.

I'm sure the problem could have been fixed with program changes (poor programming to begin with), but we had about 1.5 million lines of code to look through.

Allan in Atlanta

[James LaRue]

well...humm...my systems control a 13m antenna system and they communcate with 6 different satellites for NOAA.

The system basically acts as a scheduling program. It has set things to do at set times and you can pause or resume the schedule either in realtime or in programming. It is really just an interface to a unix system. But what has been proposed is a bridge be installed and use current Windows XP pro for the front end workstation and have a series of Dell Poweredge servers act as a software bridge to the older VAX 4000's that run the schedule, the only problem with that is the bridge..it doesn't work to well..the software gets hung up and in my line of work..you don't get hung up. Plus all of this would only alleviate one system..the VAX 3100's. So my suggestion was to upgrade the 3100's to a single processor HP Alpha with openvms and upgrade the 4000's to duel processor HP Alpha's with OpenVMS running. And have 4 servers running we would only use two at a time that would be clustered and then the other two would be our backup system.

To be honest I don't see why this wasn't upgraded 10 years ago. I guess the old addage is if it aint broke don't fix it.

I signed up for the testservers. I am gonna try and get a copy of our software and try to upload it and run it and see if it works.

[Steven Schweda]

The obvious but unanswered question would be:

Why upgrade?

Performance problems? Worries about old,
dying, hard-to-find hardware? What?

If performance, what are the systems'
bottlenecks?

VAX 3100 and 4000 are big families with many
members. Unless you have the top- (end-?)
of-the-line models, there could easily be
faster (used) VAX systems out there.

I run old junk at home exclusively, and my
primary systems are Alphas now, so I don't
worry much about obsolete hardware, as I have
so much of it.

Do you have any exotic peripheral hardware
which might make a non-VAX replacement system
problematic?

You probably don't need to worry about the
32- versus 64-bit stuff. The compiler
defaults tend toward compatibility. Lots of
code just works. In C, for example, "int"
and "long" are still 32 bits. (I don't do
much Fortran, but I'd bet that "integer*4" is
still 32 bits.) As someone else asked, in
which language(s) is the stuff written?

[James LaRue]

Wow just wow..yea the system i have is an ageing and dieing system.

I think the vax3100 is a -35 series...

the 4000 is a A105 model

we just basically need to upgrade for our vision for the next 20 years. Cause the system is really maxed out performance wise.

[Steven Schweda]

There may not be a MicroVAX 3100 model 35,
but if it's even close, then that's pretty
lame. The 4000 105A is, as I recall, pretty
high-end among the 4000 series. (If you were
throwing one away, I'd take it, for example,
unlike (probably) the 3100). In the 3100
series, models 80 and up were among the
later/faster ones. Google can find more info
if you determine the real model.

Twenty years is a long time, so moving off
the (real) VAXes might be a timely move.
(Whether an emulated VAX would be good is a
separate question.)

[Ian Miller.]

Allan - sounds to me like a bug exposed by the change of timing on Alpha VMS but too little info to tell.

James - you will get faster performance on an emulated VAX. However if the system is to last for years then investing now to bring the system up to date with current VMS and current hardware (Itanium) would be worth it.

[James LaRue]

Do you think the Itanium would be a better investment than the Alpha's for the long run. My understanding is that the Alpha is still a better processor. But that is slowly changing.

The wave of the future...

[James LaRue]

Oh they are 3100 M76...i am sorry for the confusion.

[Steven Schweda]

I can predict the past much better than I can
the future, so I can't say whether you should
aim for Alpha or Itanium. No new Alpha chips
or systems are being designed, so the future
for Itanium looks brighter. I buy only old
junk, and there is not much Itanium hardware
in that category yet, but people who should
know claim that a new Itanium box is cheaper
and faster than a comparable new Alpha box.

In general, the software effort in moving to
either should be almost exactly the same, as
the VMS code base for Alpha and Itanium is
shared. unlike the VAX code. Accordingly,
unless you have some exotic hardware, or you
use some software product which is not
available on one system type, a move from
Alpha to Itanium (or the other way) should be
remarkably painless. (Even more so, if you
keep the possibility in mind when you move
from VAX to either one.)

A VAXstation 3100 model 76 is a step up from
my VAXsta 3100 model 38, but it's pretty old
and slow. I'd expect just about any Alpha
made in the past ten years (along with a
bunch of newer VAXstation 4000 systems) to
whip its little silicon butt. Ignoring the
software license question, for well under
$1000 you could get on Ebay a 1999-vintage
Compaq Professional Workstation XP1000 system
which might amaze you with its relative
perkiness (10-20X CPU speed, I'd guess, with
newer-faster SCSI disks, better graphics, and
so on).

For many applications, VMS is not
intrinsically slow, but it does run on
hardware which (1) often cost a small fortune
when it was new, which (2) tended to run
nearly forever, and which (3), therefore,
tended to remain in use until it appears
relatively slow (fifteen years later).

Do you have a budget, or is this project
still in the info-gathering stage?

[James LaRue]

Umm..budget...no not yet. I am only gathering alternatives to what they are suggesting now, which by the way suck.

If I can come up with an easy way and also cheaper way of doing this then it would be a good and viable option. At that point I will get much kudos. So really this is just a mad props project.