Switching Over to New System

[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.)