GT.M - Migrating Off Alpha/AXP OpenVMS

Table of Contents

  1. GT.M - Migrating Off Alpha/AXP OpenVMS
    1. Table of Contents
    2. Overview
    3. Why GT.M?
    4. Migrating off Alpha/AXP OpenVMS
      1. Migrate from another M to GT.M on Alpha/AXP OpenVMS
        1. Migrate routines
        2. Migrating the global variables
        3. Transitioning production environments to GT.M
          1. Use of DDP
        4. Summary of Migrating from another M to GT.M on Alpha/AXP OpenVMS
      2. Migrate from GT.M on Alpha/AXP OpenVMS to GT.M on x86 GNU/Linux
        1. Introduction to GT.M Database Replication
        2. Migrate routines
    5. Summary
    6. Platforms other than x86 GNU/Linux

Overview

For years, the Hewlett Packard Alpha/AXP OpenVMS platform has hosted major M (MUMPS) implementations, including GT.M from Fidelity Information Services, as well as DSM, MSM and Caché from InterSystems.  With the sunset of the Alpha/AXP OpenVMS platform looming and no longer over the horizon, GT.M on x86 GNU/Linux provides an economical replacement platform.  A low-risk migration approach consisting of reversible small steps eliminates the risk of traditional “big bang” conversions.


This document shows you how.

Why GT.M?

GT.M is a mature – in production since 1986 – highly robust and scalable implementation of M.  It currently runs large production systems on Alpha/AXP OpenVMS & x86 GNU/Linux, as well as on other platforms, including what is, to the best of our knowledge, the largest real time core processing system that is in daily live production at any bank anywhere in the world today.  Individual database files of hundreds of GB, with aggregate database sizes in the TB range are in use by multiple customers.


GT.M has unique functionality for deploying mission critical applications that require 24x365 continuity of business, applications that must remain available not only in the face of unplanned events but also in the face of planned events, and even planned events such as application software upgrades that require a change to the organization of the data in the database (i.e., the application schema).  This functionality is mature and has been in production since 1999.  It is this functionality that facilitates the migration from Alpha/AXP OpenVMS to x86 Linux.


GT.M on several platforms, including both Alpha/AXP OpenVMS and x86 GNU/Linux, is released as free / open source software (FOSS).  There are no artificial barriers restricting its use.  At the same time, for production use, support with service levels is available on a commercial basis.


There exist many successful ports to GT.M from other M implementations – on multiple platforms, including Alpha/AXP OpenVMS. Many are private (references can be provided – e-mail ks.bhaskar@fnis.com to discuss your use of GT.M).  One very visible and public port is that of the VistA healthcare information system, developed by the US Department of Veterans Affairs (VA) and used by the VA on other M implementations on the Alpha/AXP OpenVMS platform – ported to GT.M on x86 GNU/Linux by the community, VistA now runs on GT.M on x86 GNU/Linux at clinics and hospitals in the US and internationally.

Migrating off Alpha/AXP OpenVMS

At a conceptual level, migrating your M application from Alpha/AXP OpenVMS to x86 GNU/Linux involves two steps:


Migrate from another M to GT.M on Alpha/AXP OpenVMS

Migrating to GT.M from another M implementation requires migrating the routines, migrating the global variables, and bringing up your application in production on GT.M.

Migrate routines

With the following exceptions, GT.M supports the M standard (ISO/IEC 11756:1999):



As provided for by the standard, GT.M implements extensions that begin with “Z” – some of these are compatible with other popular M implementations and some are different.  To facilitate the migration, depending on the complexity of your application, George James Software has well-regarded tools (RE/parser and RE/data).


Since you will be running your application on GT.M on both Alpha/AXP OpenVMS and on x86 GNU/Linux, you may need some minor refactoring of the application to reflect differences between the platforms.  For example, GT.M on Alpha/AXP comes packaged with calls to OpenVMS services that are not necessarily meaningful on Linux; on Linux, you can use the external call mechanism to access standard libraries via POSIX APIs.  As another example, your application may have logic that assumes an OpenVMS directory structure; this will have to be modified for a Linux directory structure


Migrating your application to GT.M and testing it can be performed while you continue running your application on your existing M.

Migrating the global variables

For development and testing purposes, it is a straightforward matter to extract a snapshot of the application's global variables from a backup and load them into GT.M databases.  A program to extract all of them into a text file that GT.M will load directly is a few lines of standard M code, and a program for Caché is available for download.


Multiple extracts can be run in parallel, depending on available CPU and IO bandwidth, and multiple loads can likewise be performed in parallel.

Transitioning production environments to GT.M

There are several approaches to achieving this goal.  The simplest conceptually, is to bring down the application on your prior M, extract the data, load it into GT.M and bring the application up on GT.M. Depending on the size of your database, and the capacity of your server, this may take from minutes to hours.


A more complex approach, but one that minimizes switching time is:



Both approaches are low risk in that you will have the routines and database from your prior M implementation.  In the event you want to revert temporarily for whatever reason, you can run a mupip journal extract command on GT.M to extract the journal output in a text file that you can easily use to apply the updates on your prior M database with a small program of perhaps a half dozen lines of code.  In fact, depending on your needs, you can do this process periodically, say every hour or every day.  By managing the gap between your new GT.M application on Alpha/AXP OpenVMS and that on your prior M implementation, you can bound the maximum time that it will take you to switch back, in the event you ever need to.

Use of DDP

Many popular M implementations on Alpha/AXP OpenVMS support a protocol called DDP, a bare Ethernet protocol.  You may also be able to run a hybrid application during the transition, where some processes run their application logic on your prior M, some run on GT.M, and they all use a common database.  This allows the switchover of the database to be decoupled from the switchover of the routines at the cost of a little additional complexity during the transition.

Summary of Migrating from another M to GT.M on Alpha/AXP OpenVMS

The transition from running your application on your prior M, to running it on GT.M, on the Alpha/AXP OpenVMS platform is a manageable effort, low risk, and with the ability to mitigate even that low risk.  Once your application is running to your satisfaction on GT.M on Alpha/AXP OpenVMS, you can migrate to GT.M on x86 GNU/Linux.

Migrate from GT.M on Alpha/AXP OpenVMS to GT.M on x86 GNU/Linux

Once you are on GT.M on Alpha/AXP OpenVMS, database replication facilitates a straightforward migration to GT.M on x86 GNU/Linux.  Skip the Introduction to GT.M Database Replication if you are familiar with GT.M database replication.

Introduction to GT.M Database Replication

In GT.M database replication, an “originating instance” executes business logic and commits updates to its database.  As long as an instance exists that can operate in its primary role, the application is available (in this regard, an application on GT.M is no different from an application on any other platform).  GT.M database replication adds the ability to stream database updates in real time to a “replicating instance” operating in a secondary role.  This replication occurs over a TCP/IP connection.  There is no distance restriction between instances – as of this date, we are aware of at least one customer with over one thousand miles between instances.  Pictorially, it looks like this:




If either the replicating instance (Site B) or the network fail, the originating instance (Site A) operates unaffected; when the replicating instance and/or network recover, the replicating instance catches up with database updates performed by the originating primary.  If Site A fails in an unplanned event, or must come down for a planned event, within seconds Site B can take over as the originating instance.  When Site A is recovered, it becomes the new replicating instance:




GT.M provides hooks that an application can use to recover from more complicated failure scenarios.  Furthermore, GT.M database replication also has functionality that an application can exploit to provide continuity of business through planned events such as application and system upgrades, and even many application and system upgrades that involve changes to the organization of data in the database.


In migrating from GT.M on Alpha/AXP OpenVMS to GT.M on x86 GNU/Linux, you will use GT.M's database replication across heterogeneous systems.1 

Migrate routines

The first step is to migrate any routines.  With the exception of a few calls to OpenVMS that are prepackaged functions on GT.M on OpenVMS, and which must be replaced with equivalent calls to library functions on GNU/Linux using GT.M's call-out mechanism, the M language functionality on GNU/Linux is a superset of that on OpenVMS.2  IO device parameters can differ.  Of course, if you have code that assumes OpenVMS device and file names, that will have to be migrated to GNU/Linux.  One operational difference is that GT.M on GNU/Linux does not support DDP.


Before migrating the database, ensure that your OpenVMS instance is operating with a Source Server in passive mode.  Migrating the database is a simple matter of using Mupip Extract to export the global variables from a backup on OpenVMS and using Mupip Load on GNU/Linux to populate freshly created database files.  One additional step to facilitate replication is to find the Region Seqno from the database files on OpenVMS, and to set the database files on GNU/Linux to the maximum value found on OpenVMS.  The Linux instance is now ready.  The last part of the migration consists of the following steps:



Having accomplished the migration, FIS recommends that you bring up a second instance on GNU/Linux so that your application can continue to be available when the production instance goes down in an unplanned or planned event.  On GNU/Linux, GT.M permits an unlimited number of additional instances for whatever level of redundancy you need.

Summary

While platform migration is not always trivial, the process of migrating from any M implementation on Alpha/AXP OpenVMS to GT.M on x86 GNU/Linux virtually eliminates risk by breaking down the process into a series of straightforward, manageable steps, each of which can be rapidly reversed in the event unforeseen behavior occurs when that step is taken.


The fact that GT.M on x86 GNU/Linux is FOSS is simply an added bonus that makes it a cost effective target platform with 24x7 support available on commercial terms.

Platforms other than x86 GNU/Linux

The techniques described here also apply to GT.M on Linux on Itanium based servers.  While GT.M is not FOSS on that platform, it is competitively priced.


As of this date, GT.M is also available on AIX on IBM pSeries, z/OS on IBM zSeries, Solaris on Sun SPARC, and HP-UX on Itanium (as with GNU/Linux on Itanium, GT.M on these platforms, it is competitively priced even though it is not FOSS).  Although an originating instance on OpenVMS on Alpha/AXP can replicate to a replicating instance on these platforms, an originating instance on these platforms cannot replicate to a replicating instance on OpenVMS on Alpha/AXP.  To effect a migration from M on OpenVMS Alpha/AXP to GT.M on one of these platforms in a series of small, reversible steps, first migrate to GT.M on x86 GNU/Linux, and then to your preferred final destination platform.



  1. An originating instance on GT.M on Alpha/AXP OpenVMS can replicate to exactly one other instance which must be GT.M on one of OpenVMS or Tru64 UNIX on Alpha/AXP, or Linux on x86 or Itanium.  An originating instance on GT.M on UNIX/Linux platforms can replicate to either one Alpha/AXP OpenVMS instance or to as many as sixteen instances of GT.M on other UNIX/Linux platforms.
  2. Major GT.M functionality on GNU/Linux but not on OpenVMS is support for the Unicode (ISO/IEC-10646).