Switching Over to New System

[Steven Schweda]

Not knowing enough about your current
situation to be confident about anything,
it's probably reasonable to use a TestDrive
system to investigate the portability of your
application software.

Before long, you'll need to compile a real
hardware inventory, with some kind of
description of who uses what why, as
otherwise it's tough to make even a plausible
guess about what sort of replacement hardware
would make sense.

Eventually, you'd need to determine the
hardware and software product requirements
for replacement systems, and then find a
vendor who can assemble a kit. Depending on
the circumstances, the software license costs
could completely overwhelm the hardware
costs. Everything's complicated.

[Ian Miller.]

software licence costs and cost of new hardware for Itanium systems is much cheaper than alpha vms systems. e.g last time I looked - UK list price (no discount) of a rx1600 is £1500 plus £700 for VMS license (1 cpu FOE includes unlimited user, tcp etc etc).
Total £2200 for a decent VMS small system.

Of course you can get cheap alphaserver hardware but licence costs are high.

[Robert Gezelter]

James,

As a start, I would check out the possibility of using the double translation (VAX->Alpha; Alpha->IA64) as a starting point.

If things work correctly using the translated images (and they should), if nothing else you have a shell of a working system. You can iteratively replace the translated images with compiled native images, as the problems are worked out (the problems will likely be source language tweeks, the IA64 compilers are all current language levels, the VAX versions from the date you mentioned are older).

One of the nice things about this approach is that it is phased on a single machine environment. You can also cluster VAX and IA64 nodes in the same cluster.

As background, you may want to check out my presentation on IA64 porting (most recently given last May in Edmonton, see http://www.rlgsc.com/encompass-canada/edmonton/2005-05/OpenVMSonIntegrity.html )

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

[James LaRue]

I found out today that our software was written in FORTRAN.

It is a little more complicated...cause we have vax systems everywhere that control all kinds of electronic bit synchs and electronic test equipment and all kinds of stuff...we even have it setup with a matrix that downloads all the images from the satellites onto a 2 terabyte RAID that sends data over a T1 connection to another site. Its a little more complicated than what I can explain in a couple paragraphs on the internet.

But basically what I would like to do is run the main software which acts like a controller and the workstations act like operators that log into the controller.

So with that in mind...this is a lot more complicated than I probably gave off. But i feel confident that if the software is capable of being emulated on the newer system then all would be fine.

[Steven Schweda]

Fortran (formerly FORTRAN) compilers, disk
storage, and Ethernet interfaces are pretty
generally available on any modern VMS system,
including the TestDrive systems (although
you'd need to talk to someone if you really
needed that much disk space for a test, and
those systems normally have some network
restrictions, too).

VMS also has X windows, so it's not
immediately obvious why you'd need real VMS
workstations (like the VAXsta 3100-76
systems) just to display anything, but,
again, new stuff should be able to replace
the old stuff in that niche, too.

I'd still say it's worth taking the
software for a spin on a TestDrive system.

[James LaRue]

I am working on getting a copy to be able to run it on the Test Server. That way I can find out if it will work or not.

[Robert Gezelter]

James,

Straight FORTRAN code should not be much of a problem. FORTRAN is one of the easier cases. You do need to identify if any of the code does anything that is highly device dependent (read that as mapped to IO page or anything like that, this is HIGHLY unlikely on a 3100 but could be relevant if any of your systems are based on one of the standard buses and somebody did not use a standard driver, not likely, but it needs to be checked).

There is also a question of which windowing is being used. Most VMS systems for the past twenty years or so have used the X-Windows implementation. Some earlier systems used a DEC only windowing package [VWS, if memory serves).

DEC Windows should not be a problem. VWS is more or a problem.

You are correct, this can be a bit of a challenge to describe "in a couple of paragraphs on the Internet". However, as noted in my presentation (referenced earlier), the difficulty of porting from one hardware architecture to another within the same OS (VMS on VAX -> VMS on IA64) is perhaps an order of magnitude simpler than reimplementation on another hardware platform. In particular, the emulation and clustering capabilities of OpenVMS provide a options not available in the other scenarios. These options are particularly relevant when changing hardware on a system that is mission critical and has service commitments to customers.

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

[comarow]

I would consider the reward. I remember an early conversion the Oracle DBA went from a 6640 to an early Alpha, said it was faster than a pig in ****. He was amazed.

As far as licenses, HP offers generous trade ins, if you take your 4000 licenses, they are enterprise, the delta should not be significant.

Most DCL will work, except for highly specialized stuff.

Most Fortran will recompile, unless you use special features.

You'll get to move to XFC, eXtended File Cache, which will really help I/O. If you can, going to SAN disks versus SCSI is a tremendous improvement. In fact, customers say it is comparable to going from VAX to Alpha.

Alpha of course has more of a future in terms of futures and support. The road map for alpha goes well into the future. An alternative would be to make the jump to Itanium now.

You will need to either re-compile your software or use the VEST utility. Native code is much faster and cleaner. If you have the source code recompiling is the way to go.

If you have any issues, you certainly can call the support center, 1-800-633-3600 and get VAST assistance to insure your transistion. They do a lot of that, and of course have a tremendous support staff behind them.

I've never heard anyone regret going to Alpha.

The only thing faster on VAXes is compiling COBOL code.

Best of luck.

Bob