Any Major Pitfalls Porting from HP Alpha OpenVMS 8.2 to HP Integrity OpenVMS 8.4

[PaulHoffrichter]

Customer has a number of applications (not all will be supported by Integrity):

FORTRAN, C, C++, COBOL, Oracle, SAS, DCL (Digital Command Language), Macro, DecSet.

I expect to likely to have conversion issues with system services, runtime library, pthreads, endianess, etc.

Question is whether the port between these two platforms and OS's has major pitfalls.

We once upgraded SCO UNIX to a later release. Here the platform remains the same. Yet, the system stopped working and crashed due to a great deal of erroneous C code. Used Parasoft Insure++ to help track down the problems. Still, it took over 9 Man Months to get a working system.

I wonder whether the customer's two month estimate is possible. Any thoughts from anyone who has made a similar port?

[abrsvc]

Without an examination of both the environment and some of the code, there is no way to provide a reasonable response to your inquiry.  In answer to your question of experience, yes I have performed conversions of this type for a number of applications.  Some of these have been trivial, others have been nore elaborate and took some time.

In short, MACRO involvement may require attention depending upon what the MACRO code does.  I have had routines work properly without modification others required extensiev changes.  Again, depending upon what the code does will dictate what changes (if any) are required.

For the most part, high level languages (eg FORTRAN) require little change as long as standards are adhered to. The biggest change will be from teh F77 compiler to the F90/95 compiler.  There are differences in the evaluation orders for IF blocks that may cause problems.  This is usually because of dependence on the evaluation order which is a standards violation.

Feel free to contact me offline to discuss details.

Dan

[H.Becker]

As others said: it depends and the reason, why you have MACRO code, may show a dependency. Usually you will not have any problem. But you may want to update your compilers on Alpha to the equivalent versions you want to use on I64 (or at least to the latest supported ones for 8.2). Generating the applications with these compilers is probably a good test whether you will see problems on I64 or not. Additionally you may want to enable full checking and warning/informational messages to find out potential problem areas. You should check for VAX-style compiler switches and floating point format and eleminate them. Other than that, simply use the compile and link command procedures or "make" commands/files from Alpha, they usually don't need any change.

If you need help or want to discuss this offline, feel free to send me mail.

[Hoff · Accepted solution]

Any Major Pitfalls?

Beyond what details are listed in the migration manual, a manual that you have hopefully already read from cover to cover?  Sure.  Here are a few.  Lost source code, irreproducable build procedures, random collections of source code, missing prerequisite products, the usual.  More or less the same as what happened with VAX to Alpha, for those that remember those ports.   There can be code that is tied directly into the particular port or the architecture (eg: device drivers), a case that can arise with any source code port.  And yes, latent bugs can occur in the application source code, as might well be related to your SCO Unix comments.

http://www.hp.com/go/openvms/doc (in general, and for the migration manual)

Two of the various multitudes of previous discussions:

http://h30499.www3.hp.com/t5/Languages-and-Scripting/porting-c-programs-from-alpha-to-IA64/td-p/5580791

http://h30499.www3.hp.com/t5/System-Management/OPEN-VMS-PORTING-FROM-6-2-TO-7-3-ALPHA/m-p/5414831#M41705

That two-month schedule could be feasible, or it could be tight, or it could be wildly off.  Given that list of products and inferring (much) from your question and inferring (much) from the phrasing of what you've posted, I'd tend to expect that schedule would be optimistic, but that is (only!) an inferrence and that depends on the quality and quantity of the particular source code involved, the availability of tests, whether all of the source code is available, and with your and your customer's particular familiarity with OpenVMS.

All OpenVMS platforms use the same endianness (little), and the OpenVMS system service and run-time library calls are highly compatible across the Alpha and Itanium architectures.  Yes, pthreads can be an issue, but that's no different than pthreads applications on any platform, and no different than pthreads in general.

And for experience, I've ported source code from OpenVMS Alpha to OpenVMS I64, including porting OpenVMS itself.

[PaulHoffrichter]

Thanks all for your inputs. The PM told me that HP did a demo of the conversion. There were some issues related to compiler flags to get the expected Integrity performance improvements, as well as to get through compiler errors. Project begins in June or July to improve performance. A sysgen was necessary to handle a system call.