Moving from HP OpenVMS on HP AlphaServer (or VAX) to HP Integrity

1. Moving from HP OpenVMS on HP AlphaServer (or VAX) to HP Integrity Brad McCusker Transition Engineering and Consulting HP

2. Agenda • Migration Overview • Recommendations • Porting Applications

3. Agenda • Migration Overview • Porting Applications • Recommendations

4. OpenVMS Alpha to Integrity:Porting Goals Provide an operating system environment, development tools, and documentation to make porting as easy as possible Full port of the Operating System, Runtime Libraries, development tools and most layered products Recompile, relink, requalify Use our experiences porting the operating system to make it easier for others to port their applications Provide training, presentation, white papers, documentation, etc… 4 1 April 2014

5. What have we learned? • Most customers / partners expect the work to be more and harder than it really is. • Applications originally written for Alpha port more easily than those migrated from VAX to Alpha • Most ports are “straight” ports vs. application “refresh” while porting • Most time spent in getting ready for port and the post-port regression / QA testing

6. How hard is it to migrate from Alpha to Integrity? • Its easy for most customers!!! • Most ports are done in days / weeks • Not months / quarters / years like porting from VAX to Alpha • OpenVMS on Integrity is same as OpenVMS on Alpha Its Easy!

7. What’s being ported…….and how ? Easy???? Tell me what changed

8. What did we port and How? • Single source code base to produce the Alpha and Intel® Itanium® architecture variants • About 95% of the code is common • Support for Itanium® architecture added to OpenVMS AlphaServer code base • Releases created from the same sources for both architectures • All non-hardware dependent and performance improvements to be incorporated into both versions without multiple changes to the source code and to minimize the time required to perform qualification testing. • The first Itanium® architecture release reflects on-going OpenVMS development work • OpenVMS is made more portable and maintainable by replacing VAX assembler • OpenVMS is made more open to exchanging code with other systems by using new standards

9. No Alpha Console Booting Device Discovery Interrupts TLB miss handler No Alpha PALcode VAX Queue Instructions VAX Registers IPL and modechange Different primitives in CPU Register Conventions Exception Handling Atomic Instructions Process Context Plus, we decided to change calling standard object language image format Major Changes to the Base OS

10. Agenda • Migration Overview • Porting Applications • Recommendations

11. Porting Goals • Provide an operating system environment, development tools, and documentation to make porting as easy as possible • Full port of the Operating System, Runtime Libraries, development tools and most layered products • Recompile, relink, requalify • Use our experiences porting the operating system to make it easier for others to port their applications • Provide training, presentation, white papers, documentation, etc…

12. Infrastructure changes in OpenVMS V8.2 • We made changes to some system level data structures in OpenVMS V8.2 (Alpha and I64) • Benefits • Laying the foundation for scalability and performance improvements in future releases of OpenVMS • Impact to applications • Non-privileged applications are not affected • Applications that access the modified data structures in non-standard ways may need to be modified • Examples: hard-coded data structure sizes and assumptions about the relative locations of fields within a data structure

13. Infrastructure changes in OpenVMS V8.2 • Impact to applications (continued) • Some privileged applications (such as device drivers) will need to be recompiled and relinked • Privileged applications in this case are images linked against the system using the /SYSEXE qualifier and reference the changed data structures or related structures and routines • Attempting to execute or load such an image that has not been rebuilt will result in an error during image activation of SYSVERDIF – “System Version Mismatch”.

14. Major Porting Considerations • New Calling Standard • Publicly available today at http://www.hp.com/products1/evolution/alpha_retaintrust/openvms/resources.html • Intel® calling standard with OpenVMS modifications • No frame pointer (FP) • Multiple stacks • only 4 preserved registers across calls • Register numbers you’re familiar with will change • All OpenVMS provided tools “know” about these changes • Most user applications are not affected • Your code that “knows” about the Alpha standard will almost certainly need to change

15. Major Porting Considerations • Object file format • ELF/DWARF industry standards plus our extensions • ELF - Executable and Linkable Format, Itanium® architecture object code, images, etc. • DWARF - Debugging and traceback information (embedded in ELF). • All OpenVMS provided tools “know” about these changes • Most user applications are not affected • User written code that “knows” the object file format may have to change • Specifications are available on the WEB

16. Major Porting Considerations • Floating point data types • Itanium® architecture supports IEEE float only; Alpha supports IEEE and VAX Float • All compilers that currently support F, D, G, S, T, and X (S and T are native IEEE formats) will continue to do so on Itanium architecture • IEEE is the default • We have updated the appropriate Runtime Libraries to add IEEE interfaces where needed • White Paper with technical details about the differences between VAX Float and IEEE Float is available at http://www.hp.com/products1/evolution/alpha_retaintrust/openvms/resources.html

17. Major Porting Considerations Source Code that May Need to Change • Architecture Specific code • All Alpha assembler code must be rewritten • Conditionalized code • Build command files • $ if .not. Alpha ! Assumes VAX • Application source code • #ifndef (alpha) // Assumes VAX • C asm code • SYS$GOTO_UNWIND system service must be replaced by SYS$GOTO_UNWIND_64 • OpenVMS I64 requires a 64-bit invocation context • SYS$GOTO_UNWIND_64 can be used on Alpha to maintain common source code

18. Major Porting Considerations Source Code that May Need to Change • SYS$LKWSET and SYS$LKWSET_64 system services runtime behavior has been modified • The entire image, not the specified range of pages, is locked • This change had been made on Alpha but is “undone” in an ECO kit for V8.2 Alpha and in an upcoming ECO kit for V8.3 Alpha • Consider using LIB$LOCK_IMAGE and LIB$UNLOCK_IMAGE for simplicity • SS$_HPARITH (high performance arithmetic trap) is replaced by SS$_FLTINV (floating point invalid)and SS$_FLTDIV (floating divide by zero) • To maintain common code use:if ((sigargs[1] == SS$_HPARITH) || (sigargs[1] == SS$_FLTINV) || (sigargs[1] == SS$_FLTDIV)) • Mechanism Array data structure has been changed • Standard calling interfaces have not changed • The Porting Guide contains all of the details

19. Major Porting Considerations • Improperly declared functions and data • C function declarations that points to objects that are not functions, may work on Alpha but these declarations will not work on IA64 • Also seen with the Bliss compiler • This problem may manifest itself in many ways • For whatever reason, the most common symptom is routine CLI$DCL_PARSE failing with CLI-E-INVTAB • In case of a failure the command table is usually defined as - int master_cmd();Change to extern master_cmd;and change the way the parameter is passed to cli$dcl_parse from master_cmd to &master_cmd

20. Linker • base-address parameter on the CLUSTER= option must be null • The image activator is free to ignore any linker-assigned starting address. • New /BASE_ADDRESS qualifier assigns a virtual address for images that are not activated by the image activator. This qualifier is used primarily by system developers. • New SHORT_DATA option • Allows you to combine read-only and read-write short data sections into a single segment • Eliminates unused space (up to 65,535 bytes) between two (read-only and read-write) segments • New Alignments for PSECT_ATTRIBUTE option • Integer values of 5, 6, 7, and 8 representing the byte alignment indicated as a power of 2. e.g. 2**6 = 64-bit alignment • It is highly recommended that data reduced object libraries are not referenced in Link command on Itanium® architecture • It is necessary for the linker to expand the entire module in memory which can result in BYTLM or PGFLQUOTA issues

21. Performance Considerations • Once the port of the application has been completed you should look at alignment faults • Alignment faults are expensive on Alpha but are 100 times more expensive on Integrity Servers • You can detect alignment faults using: • FLT extension in SDA • SET BREAK/UNALIGN option in the debugger • Compiler Alignment features • SYS$EXAMPLES:SET_ALIGN_REPORT.C • $ MONITOR ALIGN • Some alignment faults are easy to fix, some are very hard and some are close to impossible. • setjmp/longjmp • Significant performance gains by using __FAST_SETJMP or __UNIX_SETJMP • Exception handling – more expensive on Integrity than Alpha

22. General Development Notes • Applications should be built on OpenVMS Alpha using the latest versions of the compilers before they’re ported to OpenVMS I64 • Object file and image file sizes are larger on OpenVMS I64 than on OpenVMS Alpha • Alignment faults are more costly on I64 than on Alpha • Runtime behavior may be different on I64 if you’re relying on “undefined” results • For example: COBOL divide by zero • Pay attention to floating point format – Integrity supports IEEE only in hardware; Alpha supports IEEE and VAX Float in hardware • Consult each compiler’s Release Notes for a list of fixes, problems and restrictions

23. Compiler Migration at a glance 23 1 April 2014

24. Compiler Differences

25. C • HP C V7.2 for OpenVMS I64 • Language features and command line options are the same as HP C V6.5 for OpenVMS Alpha • Compiler is installed using PRODUCT INSTALL • Alpha compiler installed using VMSINSTAL • /ARCH and /OPTIMIZE=TUNE qualifiers are accepted but Alpha-only arguments are ignored • Allows existing command files to continue to work • Inline assembly language code is not supported • #pragma linkage maps the Alpha registers to their corresponding I64 registers • #pragma linkage_alpha and #pragma linkage_ia64 have been added • Used to specify the platform specific register names to use

26. C • Most existing Alpha builtins should continue to work but the compiler will issue a diagnostic message where a different builtin would be preferable • A significant number of __PAL builtins are implemented as system services • The compiler generates the code to call the appropriate system service • Builtins that take a retry count provoke a warning and are ignored • Due to absence of the load-locked/store-conditional sequences on Integrity systems • __LOCK_LONG_RETRY and __ACQUIRE_SEM_LONG_RETRY do still work the same • __CMP_STORE_LONG and __CMP_STORE_QUAD produce either a warning or an error depending on whether or not the source and destination addresses are identical • Consult builtins.h and pal_builtins.h for details

27. C • Use /FLOAT= qualifier to use VAX floating point format • /FLOAT=IEEE_FLOAT and IEEE_MODE= DENORM_RESULTSare the floating point defaults • Compiler predefined macros: __ia64 and __ia64__ • Defining the macro __ALPHA as a quick “hack” to deal with conditional code will cause problems with the CRTL and OpenVMS headers on OpenVMS I64. Do not attempt to use this trick

28. C++ • HP C++ V7.2 for OpenVMS I64 • This is new compiler technology that differs substantially from HPC++ and HPC for OpenVMS Alpha • Mostly source compatible with HP C++ V6.5 but there are some differences • Compiler is installed using PRODUCT INSTALL • Alpha compiler installed using VMSINSTAL • Inline assembly language code is not supported • /STANDARD=CFRONT is not supported • The object model and name mangling scheme are different than on Alpha

29. C++ • Command line differences • Comma lists are not supported • /INSTRUCTION_SET=NOFLOATING_POINT is not supported, =FLOATING_POINT • /L_DOUBLE_SIZE=64 is not supported; /L_DOUBLE_SIZE=128 is used • /POINTER_SIZE=(LONG,64) is now supported • Use /WARN=ENABLE=QUALCHANGE and =QUALNA to identify/fix qualifier problems • /FLOAT=IEEE_FLOAT and IEEE_MODE= DENORM_RESULTSare the floating point defaults

30. C++ • New Features • cname header support • 18 <cname> headers from the C++ standard • /[NO]FIRST_INCLUDE qualifier • Corresponds to the Tru64 UNIX –FI switch • #pragma include_directory • New front end improves conformance to the C++ International Standard

31. C++ • Most existing Alpha builtins should continue to work but the compiler will issue a diagnostic message where a different builtin would be preferable • A significant number of __PAL builtins are implemented as system services • The compiler generates the code to call the appropriate system service • Builtins that take a retry count provoke a warning and are ignored • Due to absence of the load-locked/store-conditional sequences on Integrity systems • __LOCK_LONG_RETRY and __ACQUIRE_SEM_LONG_RETRY do still work the same • __CMP_STORE_LONG and __CMP_STORE_QUAD produce either a warning or an error depending on whether or not the source and destination addresses are identical • Consult builtins.h and pal_builtins.h for details

32. C++ • Template instantiation • Alpha had numerous models – I64 only uses COMDAT section groups • Similar to /TEMPLATE=LOCAL on Alpha except that the linker removes duplicate copies, resulting in a reduction in the image size • This model eliminates distinct data in each section • You’ll see little differences if you’re using /TEMPLATE=LOCAL or /TEMPLATE=IMPLICIT_LOCAL on Alpha • No repository is needed. Builds that manipulate objects in the repository will need to be changed

33. FORTRAN • HP FORTRAN V8.1 for OpenVMS I64 • Language features and command line options are the same as HP FORTRAN for OpenVMS Alpha • Use /FLOAT qualifier to use VAX floating point format • /FLOAT=IEEE_FLOAT and IEEE_MODE= DENORM_RESULTS are the floating point defaults • /OLD_F77 switch is no longer supported • FDML and CDD support from the F77 compiler has been added to this compiler • /ARCH and /TUNE qualifiers are accepted and ignored • Allows existing command files to continue to work

34. COBOL • HP COBOL V2.8 for OpenVMS I64 • Language features and command line options are the same as HP COBOL V2.8 for OpenVMS Alpha

35. Pascal • HP Pascal V6.0 for OpenVMS I64 • Designed to be 100% source compatible with HP Pascal for OpenVMS Alpha • Use /FLOAT=G_FLOAT or /FLOAT=D_FLOAT qualifiers or [FLOAT] module-level attribute to use VAX floating point format • Limited 64-bit pointer support has been added to the latest version of the compiler on both Alpha and I64

36. BASIC • HP BASIC V1.6 for OpenVMS I64 • Designed to be 100% source compatible with HP BASIC for OpenVMS Alpha • Use /REAL_SIZE=(SINGLE | DOUBLE | GFLOAT) qualifier or the OPTION SIZE=REAL (SINGLE | DOUBLE | GFLOAT) statement to use VAX floating point format

37. DIBOL • Synergex Synergy/DE is DIBOL compiler on OpenVMS, both Alpha and I64 • Designed to be 100% source code compatible • Millions and millions of lines of code ported with no changes required

38. MACRO • HP MACRO Compiler for OpenVMS I64 • The HP MACRO Compiler performs several transformations to allow most existing code to compile unmodified on OpenVMS I64 • The compiler deals with differences in the calling standard and register usage • Programs that use nonstandard return values or programs that use the JSB instruction to call routines written in other languages must use some new directives in the MACRO source code • See the HP OpenVMS MACRO Compiler Porting and User’s Guide for porting details

39. BLISS • HP BLISS V1.01 for OpenVMS I64 • Builtins, PALcode builtins, and register naming are significantly different on I64 than on Alpha • Consult the Release Notes for details • /ANNOTATIONS command line qualifier will provide information in the listings about compiler optimizations • GRANULARITY support is being added to control the granularity of stores and fetches • Implemented as a command line qualifier, switch, and data attribute • Short Data Sections are supported using the PSECT attributes GP_RELATIVE and SHORT

40. Ada • GNAT Pro 5.04 for OpenVMS on HP Integrity Servers • Based on gcc technology • Handles Ada 83, Ada 95, and many Ada 2005 language features • Has optional HP Ada predefined library interface • Supports 64-bit addresses • “Source based” compilation model • eliminates the Ada 83 style program library • Debug using OpenVMS debugger • Available from and supported by AdaCore – http://www.adacore.com

41. Binary Translator • Translates Alpha OpenVMS binary images and libraries linked under all OpenVMS versions from 6.2 to current version • Translates a VESTed image that was translated by DECmigrate from a VAX binary image • Translates images written in C, C++, FORTRAN, COBOL, or Pascal (as of OpenVMS V8.3) • Does not translate applications written BASIC, PL/1, or Ada • Restrictions: • Alpha binary code • Only user-mode apps • No privileged instruction • No self-modifying code • No sys. Memory space reference • No user-written system services

42. Agenda • Migration Overview • Porting Applications • Recommendations

43. Recommendations • Evaluate your applications • What version are you running? • What version is current and supported? • What version on Integrity? • Check the application database (see next slide) • Identify Dependencies • Don’t forget ancillary applications • System management tools • Performance tools • Helper applications • Used once a year applications • Used by just one person applications

44. Application Database http://h71000.www7.hp.com/solutions/matrix/i64partner_A.html

45. Partner Integrity Porting Status • Total number of OpenVMS partners committed to Integrity: 541 • Total number of OpenVMS solutionscommitted to Integrity: 1116 • Total number of OpenVMS solutions available NOW: 711 • Total number of OpenVMS applications available: 584 • Total number of OpenVMS service offerings available: 127 100% 50% 0% Progress Bar Note: As of 01-Sep-2006

46. More Recommendations • Start planning early • “Most people don’t plan to fail, they fail to plan.” • Documents • Porting Guide • New Features Manual • Release Notes • Planning tools (see next slides) • Transition Modules • searchall.com

47. searchall.com tool • We’ve created a simple DCL tool that will allow you to search all your source and build files for a list of “things to take a look at”. It is easily tailored so you can optimize it for your needs. • To request the tool, send mail to john.egolf@hp.com and request searchall.com • Or, give me your business card today and I’ll get it to you.

48. SEARCHALL.COM • Searches all files in a directory tree • Looks for C, C++, Cobol, Pascal, Basic, Fortran, Macro, Map files • Uses a "companion" file called searchall.lis • contains a list of key words and items that should be looked at • Example from searchall.lis: • SS$_HPARITH • LIB$WAIT • __Alpha • __VAX • .... • Using it for OpenVMS VAX requires editing to add VAX specific keywords 51 1 April 2014

49. OpenVMS Alpha to OpenVMS Integrity Transition Modules (TMs) • Provides planning information, situation analyses and recommendations to help customers assess their expected transition effort • Includes tools, guides, advice, checklists, best practices, etc that address the full transition life-cycle from the customers’ perspective • Subdivided into 4 major areas of a complete IT solution: • Platform • Packaged Application Software from ISVs • Databases • Custom Source Code Applications • http://h71000.www7.hp.com/openvms/integrity/resources.html

50. OpenVMS Alpha to OpenVMS Integrity Transition Modules