Alpha to Itanium - Dummies Guide & How was it for you?

[Andrew Moody_1]

Dear All

We are making the first steps in porting from Alpha to Itanium. Before we commision work, speak to consultants and the rest, I'd like to, in the first instance, know what peoples experience was, what help is out there (specifically UK based), any useful resources.

Some details, currently using OpenVMS 7.2-1 on ES40.

We are presuming that the proposed route will first involve upgrading our Alpha environment to a level where software versions and levels are certified against both hardware platforms. So this OpenVMS 8.2/8.3 and to do the same with applications, cobol, pascal etc. Only when we have all the software at this level of commonality would we then look to do the actual porting exercise itself.

Hints tips and pitfalls please contribute

[Jefferson Humber]

Andrew,

This guide is very good !

http://h71000.www7.hp.com/doc/82final/6673/ba442-90001.PDF

Upgrading to newer versions on the AXP will certainly ease the migration (no massive version jumps when making the switch), compilers especially. I'd probably consider turning up the warning levels on the compilers too prior to migration to IA64 too, may find dormant bugs.

I'm sure I had some other URL's too which would help, highlighting main differences when porting code especially..... will see if I can dig these out if you'd like ?

Hope this helps,

Jeff

[Andrew Moody_1]

Thanks Jeff

I'd just found that document in another tab when I got the mail to tell me about your reply.

I've also downloaded http://h71028.www7.hp.com/ERC/downloads/4AA0-1647ENW.pdf

[Steven Schweda]

Most of my "development" involves porting
various pieces of freeware to VMS, so there's
not much fancy VMS-specific code, and my IA64
access is generally limited to TestDrive
systems, but it's all been relatively
painless.

Bzip2 exposed an optimization bug in "HP C
V7.2-001 on OpenVMS IA64 V8.2-1" (and "HP C
S7.1-013 on OpenVMS IA64 V8.2").

A colleague found a quirk in the SCSI driver
which affected cdrecord.

Otherwise, it was easier than going from VAX
to Alpha. (Alpha and IA64 both are 64-bit,
and the OS code has more in common.)

> We are presuming [...]

That sounds to me like a good path.

Expect to do some testing, however.

[Ian Miller.]

Start here
http://h71000.www7.hp.com/openvms/integrity/resources.html

lots of things to read :-)

Your approach is correct. Get up to current on OpenVMS Alpha and compilers and fix any warnings then look at porting. Mostly things rebuild and work fine. One thing that has caught people is that accessing unaligned data is much much worse on I64 than it is on alpha. There are tools to find these.
Floating point format - default for the compilers on alpha is not the same as the default for the compilers on I64. Preferably use IEEE format which works well on alpha and I64 but do explictly specify which in your build procedures.

[Robert Gezelter]

Andrew,

The guide is correct, often the most significant problems are old sources that have not been re-compiled for years and are not compatible with the current generations of compilers.

Otherwise, it is quite often difficult to remember which platform that you are working on (unless you are in the debugger -- or equivalent -- at the instruction level).

The have been quite a few presentations on the issues, by myself and others. For convenience, I have added links to my Alpha/Itanium presentations to my original July 2001 musings on the transition, at http://www.rlgsc.com/alphaitanium.html

Just last week, I spoke at the HP Technology Forum in Houston on some options for the transition that are suitable when "re-compile, re-link, and re-qualify" are not an option (I agree with Gaitan D'Antoni and the rest of OpenVMS Engineering that re-compilation etc. is the best strategy, as has been presented often enough). That presentation is available at
http://www.rlgsc.com/hptechnologyforum/2006/1504.html

One issue that is often underemphasized is a good understanding of how interconnected the different parts of your environment are. It is often difficult to test one part of the system, and often the scaffolding and tests used originally to construct the applications environments have fallen into disuse.

I hope that the above is helpful.

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

[Andrew Moody_1]

Thanks everyone so far, I can see another batch of de-forestation just to deal with printing of the various documents!

If I was given access to a consultant, at a pre-planning stage, what's the 3 questions you'd have me asking him?

[Kelly Cox]

I agree with everyone. We got our first Itanium a more than a year before the first commercial release of VMS. We were told that motif did not work yet, beware of this and that.

We had no trouble AT ALL. It was VMS. Motif even worked out of the box. It took longer to copy all of our source and test environment over than to compile/link and start testing. About 15 minutes of copy, less than 5 minutes to compile/link 100,000+ lines of C code.
Tons of warnings, we needed to clean up a LOT of sloppy/old code that was not ansi compliant.

I would ask a consultant:
1. for a concise step by step listing of how
to use the new console.
2. training on the new console.
3. CONCISE listing of how to boot a CD/DVD
from console and update VMS and/or
firmware.

This is the biggest difference we have seen from alpha. The last few versions have gotten better, but it still seems strange. You better have an old VT terminal or a laptop with a serial port for console work.

I WOULD HIGHLY RECOMMEND THE 3 DAY PORTING CLASS. THEY GO OVER THE CONSOLE USAGE ALSO.

[Robert Gezelter]

Andrew,

It is hard to comment on this without being self-serving (not to mention giving away the question to anybody who Googles your name).

As a starting point, I would say that any comments about the scope of the effort without a full, thorough review of your sources is not providing a safe answer. Done seriously, this will take time and effort and may be the most significant part of the project.

One of the reasons that I consider the use of the translators as a serious approach is that it prevents having to scope out a full source migration in one step.

I have also observed that performance projections, without firm, site specific data and full details, are not reliable guides to future hardware purchases. My recommendation is to do the transition, at least for test purposes, on the smallest box that is feasible and then do "hard science" on what performance is. It is amazing what a rx2600-class machine can accomplish. It also prevents the situation of over-buying hardware, which has always been a rapidly depreciating asset.

I hope that the above is helpful.

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

[Andrew Moody_1]

All information is helpful Bob thanks.

Hopefully it leads to better decisions. As for our environment, we've 8 Alpha nodes to deal with, which I guess is small scale for many of you. However, it does mean our skills sets as a group are of the jack of all trades (OpenVMS, HP-UX, Windows, Linux, Cisco) master of none variety.

[Troodon]

I have to say my migration was very easy with few challenges and no pitfalls. The HP OpenVMS people were _very_ helpful.

My only disappointment is that the dual cpu rx2620 IA64 machine we purchased this year has about the same performance of the last Alpha DS10 667 single CPU system we bought a few years ago, Hopefully the new multicore chips will improve things.

In retrospect, the Alphacide was a mistake, We switched from the state of the art to something short of this and lost an entire generation of performance.

[B Claremont]

As many others have suggested, review all of the relevant porting guides. They are very good. You'll find my porting experience at this link: http://h71000.www7.hp.com/openvms/journal/v6/porting_rpg_to_integrity.html

Since you are UK based, I suggest checking in with Colin Butcher at XDelta: http://www.xdelta.co.uk/

[Jan van den Ende]

Andrew,

the one option I have not seen mentioned yet, is the possibility of GRADUAL migration.

I have yet very little IA64 experience, but in the Vax->Alpha migration we have had (for YEARS) a mixed hardware cluster.

Main purpose: use IA64 to run the stuff that is qualified, but anything that is not yet available ( think about 3rd party packages etc ) can just as well be used from Alpha, operating on the same data.
Organise things well, and only System Management will be able to tell the difference, and even THEY won't care 90% of the time.

Back then we had one version of a package (DecEDI) that was never ported to Alpha. We (and our communication partners) could perhaps have done a major redefinition of our business protocols, but as it was already slated for replacement, budgets allocation was hard to get. And communication using Vax _WAS_ still working. Until the replacement was fully operational, our cluster has had one (small) Vax doing DecEDI, where all other activity was performed on Alphas.

Of course I do not know if you will run into similar issues, but if so, do not let that stop you: mixed clusters are just VMS clusters!

hth

Proost.

Have one on me.

jpe

[Colin Butcher]

That's very nice of you Bruce. Thanks.

On the whole I've found migration to be reasonably straightforward under most circumstances. From a system management perspective VMS is VMS (with a few changes if you're still on old versions such as V5.5-2 or V6.2). You'll probably need to make some radical changes to quotas and some system parameters if you're moving from a VAX or a small-memory Alpha. The EFI based console is however really quite different to anything you've seen before.

Things tend to get interesting with your porting efforts if you have any demanding and non-mainstream IO requirements, especially in real-time systems. Things also get interesting (from a floating point performance viewpoint) if you have a lot of mathematical work with large data sets that you need to access from different kinds of systems.

On the whole Itanium as an architecture is designed around plentiful memory with a lot of on-chip cache and a relatively simple CPU. Most of the cleverness is in the way that the compilers generate the instruction and data streams. Data alignment is also important for performance, so moving old VAX FORTRAN style code with large common blocks and things packed into as little memory as possible can get interesting, especially if that code has to work with old data sets, disc backed global sections and so on.

It all depends of what your systems are used for and what underlying products you rely on. In general things are usually pretty straightforward, but not always.

You might find some of the session notes here useful: http://www.xdelta.co.uk/seminars.html

Good luck.

Cheers, Colin.

[Andrew Moody_1]

Thanks everyone, for your comments so far. EFI I think I'll be ok with as I've seen it from a HP-UX perspective (which is where my experience lies).

I'm collecting papers and advice, I guess from a pure sys admin perspective it should be straight forwardish for me, it's the application developers that will have a bit more to think about.

Thanks again everyone, all your words help greatly.