VAX to Alpha Migrations

For organizations using applications under OpenVMS on VAX, and planning to move to Alpha family based processors, there are basically three options: A binary translation, a native migration, or a VAX Emulator running on Alpha and creating a "Virtual VAX". In cases where the application's source code is not available, a binary translation using "OMSVA" (former DECmigrate) must be executed, or the VAX virtualization must be used. In cases where the source code is still available, a native migration is the more preferable option, allowing for future expansion of the application and ease of maintenance. Given the high degree of application level compatibility of OpenVMS on different platforms, a native migration should be relatively inexpensive and simple. However, a migration will need some other factors to be taken into consideration.

	BINARY TRANSLATION	NATIVE MIGRATION	VIRTUALIZATION
General	Allows the translation of executable images and sharable images from OpenVMS/VAX to OpenVMS/Alpha.	The original application is completely ported to the target platform and becomes a native application on OpenVMS/Alpha. Partial redesign, optimization, language conversion, middleware replacement, etc. can be applied as needed.	CHARON-VAX/AXP for OpenVMS/Alpha and CHARON-VAX/66x0 for OpenVMS/Alpha are virtualization products that create a virtual VAX systems on Alpha. The application remains as-is and is executed under OpenVMS/VAX running on the "Virtual VAX" created by CHARON-VAX.

Requirements and Limitations

	BINARY TRANSLATION	NATIVE MIGRATION	VIRTUALIZATION
Application's source code	Not needed.	Required.	Not needed.
Application's Programming Language	Must be supported by the binary translator on the target platform.	Can be automatically converted into a modern programming language. Please see SRI's programming language conversion services	Irrelevant
Layered products and Middleware used by the application	Must be present on the target platform.	A partial re-design can be applied to modernize the application.	Irrelevant
Special hardware used by the application	Must be present on the target platform.	Partial re-design can be applied to eliminate the necessity of special hardware.	The special HW must either be supported on the target platform, or some programming will be needed using CHARON-VAX's Application Programming Interface (CHAPI).
Application's mode of code	Must contain User Mode code, only.	Irrelevant.	Irrelevant.
Other requirements and limitations	Please see the documentations of OMSVA (former DECmigrate)	None	Will depend on individual case. Please contact SRI.

Migration Process / Duration / Cost

	BINARY TRANSLATION	NATIVE MIGRATION	VIRTUALIZATION
Migration process organization	The application owner with experience in OpenVMS and DEC/HP's layered products should be able to perform the binary translation. Support or Consulting by SRI is available upon request.	Software Resources International will be able to extend a fixed price, fixed delivery date quotation for application migration. Please see SRI's Application Migration Services.	Please contact Software Resources International or the nearest Value Added Reseller of SRI.
Migration process duration	Each executable or shareable image may take 1 to 2 days to be translated.	Project duration and schedule will depend on the size and complexity of the application. Will be defined during the project assessment phase.	The installation and configuration of CHARON-VAX can be performed on-site during 1 to 2 calendar weeks by one of SRI's or SRI's certified VAR's specialists.
Efforts & Cost	OMSVA (former DECmigrate) is available for free. Support or Consulting by SRI is available upon request.	Project cost will depend on the size and complexity of the application. Will be defined during the project assessment phase.	Various product variations are available depending on the application's needs. Please contact Software Resources International or the nearest Value Added Reseller of SRI.

Conclusions

	BINARY TRANSLATION	NATIVE MIGRATION	VIRTUALIZATION
Pro	Fastest and most inexpensive solution Does not need the source code	Produces native application on the target platform Minimum limitations. Almost every application can be migrated. Partial redesign during migration allows for replacing the programming language, middleware, user interface and design. Extends the life cycle of the application. Further development and maintenance on modern target platform. Gives a performance boost	Retains the original application development environment "as is" Doesn't need the source code Inexpensive. Does not need significant migration efforts Usually increases performance
Contra	Some serious limitations apply, like availability of older languages on the target platform User-mode applications, only Does not allow for future enhancements on target platform Might impact performance DECmigrate does not work in some cases	May take longer to implement Source code needed	Maintenance of the application requires retaining OpenVMS/VAX knowledge Future development of application must be performed under OpenVMS/VAX running on CHARON-VAX. Any special HW used must either be supported on the target platform, or the Application Programming Interface CHAPI must be used.
Suitable for	Stand-alone, user-mode applications	Large and complex applications, developed in more than one programming language, and using layered products	Systems, where only a hardware upgrade is required Applications created using proprietary programming tools which are too expensive for a native migration