HP OpenVMS Systems

OpenVMS Technical Journal V6

HP OpenVMS Systems

OpenVMS information

» What's new on our site
» Upcoming events
» Configuration and buying assistance
» Send us your comments

HP OpenVMS systems

» OpenVMS software
» Supported Servers
» OpenVMS virtualization
» OpenVMS solutions and partners
» OpenVMS success stories
» OpenVMS service and support
» OpenVMS resources and information
» OpenVMS documentation
» Education and training

OpenVMS software

» Operating system
» OpenVMS clusters
» OpenVMS Galaxy
» e-Business products
» Opensource tools
» Networking
» System management
» Storage management
» Security products
» Application development and integration
» Software licensing
» SPD listings
» Whitepapers
» Ask the wizard
» Training
» OpenVMS books

Evolving business value

» Business Systems Evolution
» AlphaServer systems transition planning
» Alpha RetainTrust program

Related links

» HP Integrity servers
» HP Alpha systems
» HP storage
» HP software
» HP products and services
» HP solutions
» HP support
disaster proof
HP Integrity server animation
HP Integrity server animation
Content starts here

Porting TDMS - The Gory Details

Bob Sampson, Consulting Associate


Porting any application from OpenVMS VAX; first to OpenVMS Alpha, and then to OpenVMS I64 is a challenging project. As we ported TDMS, we encountered four tricky details that we have described here to help you in your own porting efforts.

Origin of TDMS Software

VAX TDMS is an older generation character-cell terminal forms package for transaction processing environments. It is a mature product that is available for OpenVMS VAX only.

The TDMS (Terminal Data Management System) for OpenVMS VAX software product (VAX TDMS) was designed for the implementation of interactive, forms-intensive applications.

Long ago, VAX TDMS was officially superseded by DECforms, which is recommended for any and all new character-cell terminal applications that require a forms-based user interface on OpenVMS.

The VAX TDMS Software Product Description (SPD) can be viewed at: http://h18000.www1.hp.com/info/SP2571/sp2571pf.pdf. Please note that any support or availability commitments in that document (whether expressed or implied) do not apply to ported TDMS software.

As a terminal subsystem, TDMS can reduce the application development and maintenance effort by replacing application program logic specific to terminal interactions with definitions that are external to the program.

Ported TDMS Software Services

My team offers ported TDMS software, in the form of licensing and support services, for the purpose of providing a simple migration path for TDMS applications (especially those running under the ACMS environment) from OpenVMS VAX to OpenVMS Alpha (and now to OpenVMS I64 as well).

The TDMS software was ported to OpenVMS Alpha in late 2001, and field tested in mid-2002. The TDMS software was further ported to OpenVMS I64 in late 2004.

As a part of the original Alpha TDMS porting effort, the hardcopy VAX TDMS documents (Forms Manual, Installation Guide, Pocket Guide, Reference Manual, and Request & Programming Manual) were converted to HTML, and are provided with every Alpha TDMS and I64 TDMS kit, along with the current release notes.

An evaluation license, a software kit, and limited remedial support are available to customers for sixty days at no charge.

Alpha TDMS licensing and support services have been offered for sale worldwide since early 2003. As of this writing, I64 TDMS is available only for evaluation.

Further information about the ported TDMS software (Alpha TDMS and I64 TDMS) is available at: http://h71000.www7.hp.com/commercial/tdms/tdms_services.html.

Porting Challenges

Four major porting challenges were encountered. Architectural differences among OpenVMS VAX, Alpha, and I64 were the leading cause, followed by limitations of the Bliss-32 language dialect. Mistakes were made on several occasions, introducing both subtle and not-so-subtle bugs, not all of which were immediately detected during regression testing.

  • Differences in the calling standards were especially problematic, and accounted for two of the four challenges; see the first and third items below.

Using a transfer vector and fetching data from a known stack layout for VAX had to be replaced by using a bound procedure descriptor and specially-written Macro-64 transfer routine for Alpha, and by using a bound function descriptor, a new OpenVMS-provided transfer routine, and special linkage for I64.

An internal context-switching package had to be changed out to match the one used by ACMS on each of the architectures. On VAX and Alpha, this package had to be implemented in low-level assembly language, using detailed knowledge of the respective calling standards and stack layouts. On I64, the implementation was greatly simplified by making use of the new OpenVMS-provided user-mode KPS routines.

  • Differences in the object file formats accounted for another of the four challenges; see the second item below.

The Alpha object file format is somewhat different from, yet almost completely analogous to, the VAX object file format. The I64 ELF object file format is driven by a cross-platform industry standard, so it is very different from its predecessors. However, the addition of OpenVMS-specific extensions makes the new format completely suitable for building ported software.

  • Differences in 64-bit integer math implementations, combined with a lack of Bliss-32 language support for these multiply and divide operations, accounted for the last challenge; see the fourth item below.

The solution ultimately chosen was to provide these operations using routines written in a language that fully supports them; in this case, HP C.

1. Context Passing: Application Function Key (AFK) Asynchronous System Traps (ASTs)

VAX TDMS implements context passing for AFK ASTs by providing a transfer vector consisting of an entry register save mask and a jump instruction with address fix-up at the start of each context data structure. The AST routine then fetches the context from a known relative offset on the stack.

Over several months in late 2001, with some guidance from OpenVMS Engineering and the Calling Standard documentation, this context passing mechanism was ported to Alpha TDMS. The VAX transfer vector was replaced with an Alpha bound procedure descriptor at the start of each context data structure. A short Macro-64 transfer routine provides the context address (bound procedure descriptor address from R27) to the AST routine as the sixth actual argument in R21. The argument count (low byte of AI/R25) is also filled in with the value six. Names and attributes of code program sections are specified so that the linker places the transfer routine code immediately before the AST code, eliminating two instructions (load and jump). This results in an efficient implementation of AFK ASTs that is compatible with the Alpha calling standard. Please refer to section 2.2.2 of the release notes for further details.

Over about ten days in early 2003, with further guidance from OpenVMS Engineering, a similar mechanism was used for I64 TDMS, which was actually simpler to implement. The Alpha bound procedure descriptor was replaced by the I64 bound function descriptor. A transfer routine called OTS$JUMP_TO_BPV is already provided by OpenVMS I64, specifically for use with bound function descriptors. The context is passed to the AST in R9 by specifying special linkage.

Over a few days in late 2004, regression testing uncovered a problem with the bound function descriptor, which was corrected. Please refer to section 2.6.3 of the release notes for further details.

2. Object File Generation: Form Development Utility (FDU) Form Editor (FED) Memory-Resident Forms

VAX TDMS implements memory-resident forms for the FDU form editor. A utility program called FDVCDDOBJ is used to package each TDMS form from the Common Data Dictionary (CDD) into an OpenVMS VAX object file. The linker then arranges the forms into a linked list in the FDU program.

Over about one week in May 2001, FDVCDDOBJ was easily converted to generate object files in the OpenVMS Alpha format. The VAX and Alpha object formats are very similar.

Over about one month in April and May 2003, with some guidance from OpenVMS Engineering, FDVCDDOBJ was converted to generate object files in the OpenVMS I64 (ELF) format, which is very different, and considerably more complex. Also, ELF initially did not provide support for Link-Time Complex Expressions (LTCEs), and this support was not added until after the porting work on FDVCDDOBJ was completed.

The TDMS source code now compiles correctly for any of the three recognized target platforms: VAX, ALPHA, or IA64.

3. THD Component

VAX TDMS implements a simple form of "threading" (actually more like context switching using co-routines) with its THD component, which is very similar to (and very compatible with) the ACMS product's THD component on OpenVMS VAX.

From late May through late November 2001, an attempt was made (with reasonable success) to re-implement TDMS THD using POSIX threads, a.k.a. pthreads, formerly DECthreads. This also required extensive changes for thread-awareness. Not much effort was expended to investigate or test for potential thread-safety issues.

Very early during initial field test, this implementation had to be abandoned (or at least set aside), in order to provide interoperability with the ACMS product on OpenVMS Alpha. Please refer to section 3.23 of the release notes for further details.

Fortunately, ACMS Engineering kindly provided its ACMS THD OpenVMS Alpha source code. Over about one week in November 2001, this was incorporated into Alpha TDMS.

From mid-May through mid-November 2003, possible strategies were discussed with the ACMS and OpenVMS Engineering groups, for porting the THD component to OpenVMS I64. On a few occasions, attempts were made to perform some of this porting work.

As OpenVMS Engineering had advised, ACMS Engineering ported its ACMS THD to OpenVMS I64, using the newly-enhanced OpenVMS KPS routines, and again kindly provided the source code for I64 TDMS THD. Very little low-level machine language was required for this new implementation, aside from the OpenVMS KPS routines themselves.

This improves on the VAX and Alpha THD implementations, which require much more of their own Macro-32 and Macro-64 source code.

The I64 THD also appears to be highly portable to OpenVMS Alpha V8.2 or higher. In the event of any compelling need, it could most likely replace the existing Alpha THD.

Within one day in June 2004, the ACMS I64 THD was easily "dropped" into I64 TDMS.

4. 64-Bit Integer Math

The VAX TDMS source code was written almost entirely in Bliss-32, a language dialect that has no direct support for multiply and divide operations on 64-bit integers. OpenVMS date conversions make use of 64-bit integers. VAX TDMS performs divide and multiply operations on these by calling the undocumented COB$DIVQ_R8 and COB$MULQ_R8 COBOL language support run-time library routines with special JSB linkage.

These routines are not available for the use of native OpenVMS Alpha applications. The initial attempt during April 2001 to replace them with in-line Bliss-32 code did not work properly. Please refer to section 2.2.10 of the release notes for further details.

One day in January 2002, the DIVQ and MULQ replacement routines were implemented in C for Alpha, but unfortunately with coding errors that went undiscovered for about a year, even during intensive field testing.

One day in January 2003, in response to a problem report from a very alert HP employee and OpenVMS Ambassador (now an alumnus) in Ireland, these coding errors were finally corrected, along with two other software problems that had interfered with some of the date conversions. Please see section 2.2.14 of the release notes for further details.

Porting to I64 did not require any further changes to these routines


We hope that that lessons we learned from porting TDMS software will save others some time and effort in the future.

For more information

Contact the author by e-mail through OpenVMS Business Management