Migrating VAX to Integrity

[Petran Bisschops]

Dear all,

We are currently looking into upgrading/migrating from VAX hardware running VMS 6.2 to Integrity, probably RX2620 under VMS 8

I have a few questions where I hope you would share your experience with me:

a) We want to use a raid-5 hardware configuration. According the spec, this is shown to VMS as one physical device meaning we cannot configure/partition the device to make VMS believe we have multiple disk drives. Some of our applications require multiple disk devices.
Is there any solution for this?
I found out of the possibility to use the "logical disk utility" to generate more logical disk devices implemented as VMS container files. Is there anybody who can share some expiriences - reliability, perfomance etc.

b) we have to migrate all our Fortran based applications to this platform as well. Are there any issues to concider. Is this simular to migrating to Alpha?

c) Any other issues about itanium?

Your comments are as always greatly appriciated.

Petran.

[Volker Halle]

Petran,

there is a whitepaper for OpenVMS VAX to Integrity migrations:

http://h71000.www7.hp.com/news/vax_to_integrity.html

a) if you cannot find a Raid-5 controller, which makes multiple disks available to OpenVMS I64, you could use

- concealed devices (using logicals), if your application allows this
- use LDDRIVER to create LDAx: devices mapped to container files, see:

http://h71000.www7.hp.com/openvms/journal/v6/disk_partitioning_with_lddriver.html

b) migrating FORTRAN applications should be very easy. Re-compile and re-link.

c) access to un-aligned data could cause performance problems (more than on Alpha).

Volker.

[Volker Halle]

Petran,

what RAID 5 contoller do you have in mind ? Would it not support multiple logical drives ?

Volker.

[Petran Bisschops]

Volker,

Thanks for your reply.

The raid 5 controler we are opting for is of type A7173A - HP Dual Channel Ultra320 SCSI -5.

According the sales rep:
1) it can only be configured as RAID5
2) it is hot pluggable
3) The raid5 is shown as one disk device in VMS.

Thanks,

Petran

[Vladimir Fabecic]

Hello
Long time ago I had to migrate some applications from vax to alpha. Also had to have "multiple disk drives", but had just two raid disks (one RAID0 and one RAID5). I fixed that problem using concealed devices (using logicals). It is still working.
Something like:
DEFINE/TRANS=(CONC,TERM) disk1 dra1:[disk1...]
Not sure if it is correct sintax.

[Petran Bisschops]

Hello,

I did concider concealed devices but that won't work in all cases because I found DCL F$DEVICE calls and coresponding system service calls in the Fortran code - they won't return concealed devices.

Petran.

[Robert Gezelter]

Petran,

My first general recommendations are to:
- establish a set of qualification procedures that establish that the migrated (or new version) of the code functions at an acceptable level.
- secondly, I would recommend checking the FORTRAN sources for issues/incompatibilities BEFORE working on the IA64 platform.

The reasoning behind the above is straightforward: in the migration process, you will need to re-qualify the application more than once. An automated (or at least a scripted) process is more likely to give the assurance that your application is working than is an informal one.

There are also three sets of issues that you may encounter when moving the code: 64 bit issues, IEEE floating point issues, and IA64 specific issues.

Of those three, the IEEE Float issues are relevant if you have code that is VERY VERY floating point dependant. For example, if your application is a fluid dynamics simulation or other scientific application. These are not difficult to resolve, but I have seen cases where scientific/engineering codes depended on the details of the floating point format.

If your code is 100% classic FORTRAN, you should not encounter any 64 bit problems. I would also not expect IA64-specific problems.

A summary of the major issues can be found in my presentation on "The Third Porting", which was most recently presented for the Edmonton, Alberta (Canada) LUG in May 1995 (see
http://www.rlgsc.com/encompass-canada/edmonton/2005-05/OpenVMSonIntegrity.html for a copy of the slides).

As to the disk question, I have encountered the "multiple disk requirement" many times. The use of concealed logical names, and the OpenVMS logical name facility allows you to create a reasonable facsimile of a multiple disk environment, at least good enough in general for normal FORTRAN applications. As a first approximation, there is probably no need to bother with Logical Disks. I have written a series of columns on the the use of Logical Names (they can be accessed through my publications page at http://www.rlgsc.com/publications.html ).

I hope that the above is helpful.

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

[Robert Gezelter]

Petran,

I was writing my posting when you made your most recent posting about "F$DEVICE and corresponding other system service calls".

These may or may not be a problem, depending on what the information is used for.

Without looking at the code, it is hard (and for that matter, reckless) to speculate on what the application is doing with that type of information about a disk drive. It was not uncommon in days long past for applications to check the amount of free space on the drive and other details, in an attempt to optimize their operation. Hardware resources have long eclipsed this need (the resources available on a rx2600-class system dwarf even the larger members of the VAX family).

I would recommend a careful look at what the "F$DEVICE and corresponding system services" are precisely doing and how that information is used. The surface appearance of your application may be leading you into some unneeded configuration choices.

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

[Petran Bisschops]

Robert,

Thanks for your reply.

I will have a closer look at the code and see what it does.

One of the goals of my posting was also to find out about possible options so I can decide later on whats best (read: most cost effective?!)in our situation.

To all:

I would still appreciate some comments/experiences about the "logical disk utility"

Petran.

[Volker Halle]

Petran,

LDDRIVER is supported with OpenVMS I64, e.g. it's being used in @SYS$MANAGER:CDRECORD to create the image of the CD to be burned.

You can create container files and present them to OpenVMS as LD devices (like disks). You can then INIT and MOUNT those disks copy your files to those disks.

Also check the Smart Array adapters (A9890A and A9891A), which should be supported very soon on OpenVMS I64 V8.2-1, they may also allow multiple logical drives to be configured.

Volker.

[Ian Miller.]

Note general migration documentation is at
http://h71000.www7.hp.com/openvms/integrity/resources.html

and some background reading
http://www.didiermorandi.com/doc/vaxvms2itanium_200310en.pdf
http://www.didiermorandi.com/doc/vaxvms2itanium_200311en.pdf
http://www.didiermorandi.com/doc/vaxvms2itanium_200312en.pdf

[David Jones_21]

I use the LD driver on Alpha to store online images of CDs and retired disk arrays. If they are writable, you have to back them up as separate devices, which can be good or bad.

I keep all my container files in a single directory and name them label.LDnnn and then use a procedure at startup to scan the directory and automatically connect and mount them.

VMS has a 1 TB limit on volume sizes which is easily exceeded by modern RAID configurations. Your RAID controller must be able to partition the raidsets into logical drives that VMS can deal with regardless of whether you use the LD driver.

[Gary Hansford]

Petran,

I know this may be a bit off topic but have you considered using a VAX emulator ?

This would allow you to run your existing VAX/VMS system on an Intel box without any rewriting etc.

Basically the software emulates a VAX chip. You just have to configure storage, and networking and then restore your existing OS onto the emulator (boot VAX standalone BACKUP !!).

We did this last year, works a treat and involves little effort - saves a bundle on maintenance costs of VAX hardware and the Intel box is so much faster than the original VAX, the users were impressed with the upgrade (even though its an emulator !!).

The software we are using is called Charon. It's a thought....

Cheers

Gary

PS: I am not a salesman, just a VMS guy who thought - thats an easy way of getting round the problem...!!

[Petran Bisschops]

Gary,

We did concider Charon - in fact we have Charon emulations running for a project we could not migrate to Alpha or Itanium because some of the packages this project was using could not be ported.

For the remaining projects, we actually have the possibility to port to Itanium because all the software can be build/will run on Itanium.

A few drives as to why not use Charon are:

1) Costs. The licenses for Charon are extravagantly expensive. We conservatively calculated a cost saving of about 35% in the first three years if we use a Itanium solution as oppose to a Charon solution.

2) VAX/VMS does not or hardly supports anything to do with J2EE and that is where our company seems to be going in the future.

3) Although a Charon solution is more powerfull than the corresponding native VAX hardware, judging from the specs, a Itanium solution is far more powerfull than a Charon solution (for a third of the price!).

4) The highest supported VMS version for VAX and therefore Charon VAX is 7.2 I believe. I don't know for how long this version will be supported by HP.

5) Another interesting angle is disaster recovery. Most of our applications are 24*7 critical production applications. I believe that in case of a major incident, we will have an Integrity box up and running much faster then a Windows PC-server running a CHARON-VAX emulation. The later one will almost always need a re-installation of Windows from scratch because it is very unlikely that you get the same server hardware back after a year or so which means that you cannot use image backups.

6) Why settle for an emulation if you can get the real thing....

Petran.

[Robert Gezelter]

Petran,

A note on your last posting. I believe that the highest version for OpenVMS VAX is 7.2, not 7.2.

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

[Robert Brooks_1]

A note on your last posting. I believe that the highest version for OpenVMS VAX is 7.2, not 7.2.

---

Bob, of course, meant to type that the highest version of OpenVMS VAX is V7.3.


-- Rob

[Arch_Muthiah]

Petron,

From HP integrity Server FAQ section.....

11. My application runs on a VAX system today. How do I get to HP Integrity servers?
Porting applications from VAX systems to HP Integrity servers will involve work similar to what would have been done to port applications from VAX systems to AlphaServer systems. Although the port of most VAX system applications to AlphaServer systems and now to HP Integrity servers is fairly straightforward, there are certain architectural differences in the platforms that require changes to the applications.

The key areas with differences are data alignment, H_FLOAT data types, data granularity, page sizes, and exception handling. HP recommends that you refer to the Migrating an application from OpenVMS VAX systems to OpenVMS AlphaServer systems book and apply the recommendations from that book as you port your applications from VAX systems to HP Integrity servers. In addition, HP recommends that you review the white paper, Making the transition from HP OpenVMS VAX systems to OpenVMS on HP Integrity servers.

HP Services will assist you in this endeavor.

Note that mixed architecture clusters of AlphaServer systems and HP Integrity servers are supported. HP also continues to support mixed VAX and AlphaServer systems environments. However, our current plans do not include support for VAX systems and HP Integrity servers.

In addition, please refer to FAQ#33 for information on clustering VAX systems with HP Integrity servers for development purposes only.

Archunan

[Ian Miller.]

"clustering VAX systems with HP Integrity servers" - works for me - VAX, Alpha, Itanium in the same cluster :-)

[Arch_Muthiah]

Petran,

http://www.migrationspecialties.com/Porting.html
They are specialist in VAX-ALPHA-Itanium migration, you can find more usefull info in this site.

Earlier I started a thread in this forum titled with "Are there any big changes between Alpha/OpenVMS and I64/OpenVMS"
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=970463

Archunan

[Robert Gezelter]

Rob,

You are correct, I was in a bit of a hurry, and missed the typo -- the correct version for VAX is 7.3.

Petran,

Clustering is a good tool, and extremely useful in this context as part of a strategy for a clean, low-risk cutover.

As I noted earlier, the image translator is also a good tool to help manage the transition.

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

[Paul Jerrom]

Howdy,

We are currently migrating our Alpha software to Itanium, big issue we found was that the Itanium Fortran compiler is F90 only, NOT F77. Has made a HUGE impact on our migration.

Have fun,

PJ

[Stanley F Quayle]

With complete source and no dependencies on layered products that weren't ported to Itanium, CHARON-VAX is probably not the right solution for you. Migrate it to Itanium, and then you'll be set for years to come (and ready for VMS on Xeon when it's available, haha).

I expect that HP will continue supporting VMS for VAX for many years to come. And you can get support for V5.5-2 and V6.2 as well. But sure, get on V8.3 (coming soon) and stay current. And you get Java and all the other goodies.

And heck, I am a CHARON-VAX reseller. But it's not for everyone.

[Lars Funck Jensen_1]

>>According the sales rep:
>>1) it can only be configured as RAID5

I don't think so on OpenVMS, unless you use host based shadowing and I don't think this complication is what you want.
I think you at least need a A9890A ( 6402 ) RAID controller or you may look into the new MSA1500 G2 SAN.

If support is not documented in writing, it does NOT work on production class OpenVMS!

Fortran
If you do not need to share any floating point data with VAX systems after the conversion, I would convert all floating point in datafiles to IEEE and compile all programs /float=IEEE ( check syntax).
It is much better to use standards ( and faster on Integrity)

[Antoniov.]

Hi Petran,

a) nothing to add; many people posted.
b) HP engineers say: convert your application from F77 to F90 on your VAX then recompile e relink on Itanium.
c) Your analysis about Itanium and Charon is right. John Smith of HP published some TCO/ROI analysis for OpenVMS customers. You can pay back migration.
However, if you don't have specific VAX cards you can consider HP OMSAIS for application without source. See http://it.openvms.org/stories.php?story=05/11/06/9595530 (sorry, that's in Italian).

Antonio
http://it.openvms.org

[Ian Miller.]

HP OpenVMS migration software for HP AlphaServer systems to HP Integrity Servers (OMSAIS)

http://h71000.www7.hp.com/openvms/products/omsva/omsais.html

However in your case making the changes to move to F90 and migration to Itanium is the way to go.