Porting Applications Off of OpenVMS

Porting Applications Off of OpenVMS

http://64.223.189.234/node/225

Submitted by Hoff on April 13, 2007 - 23:19.

Tagged: Business  •  Mac OS X  •  Marketeering  •  OpenVMS  •  Porting  •  Programming  •  Software  •  Unix

As discussed over in Legacy Code: Stay or Upgrade or Migrate?, application migration isn't to be undertaken lightly, nor a task to be undertaken based solely on FUD. You have looked at the costs and other factors, and are now researching moving off of OpenVMS. Here are application considerations…

Speeds and Feeds

First look at the large-scale system-level factors. Look at your application virtual address space requirements, and at your disk and memory storage requirements. At your I/O speeds and feeds. At your archival requirements, and your archival window. If your application has an archival window — applications with uptime requirements do not. These factors will help you size your target platform(s).

Target platforms include Sun Solaris on x86-64 or SPARC, Linux on the [whatever] boxes, Mac OS X Server, IBM POWER (and IBM is clearly consolidating iSeries, pSeries, and zSeries platforms, and with its POWER6 processor), or Microsoft Windows on x86-64 boxes. There are other target platform choices.

Look at what storage is involved, and what I/O rates are required. OpenVMS storage capacity tends to be constrained compared with what is on the market. Shared storage can involve SAN or NAS, and can be based on block services or on file-level services. Don't expect that the I/O rates will match or even map, given architectural differences. Do expect that if you need to load a gigabyte of data for a daily processing run, you will need to load a gigabyte of data regardless.

Application Scale
The numbers of source modules is only indirectly related to the difficulty and the effort. It is quite possible to have fewer modules and rather more porting effort, or many modules and little porting effort. Simply having more source code does mean relatively more porting effort, but the relative effort is on a continuum ranging from recompile and relink to redesign and rewrite and redebug.

Application Documentation
If you do not have application-level documentation, you will need to prepare that as part of an investigation into porting. If your application-level documentation is not current, you will need to remediate that. If you don't know what you have now and how it works, porting can easily become difficult and expensive and risky.

Source-level tools such as Doxygen can assist with creating and maintaining application-level documentation, and you can also choose to maintain documentation in parallel. And as the code is examined in detail, knowledge gained should be added back into the existing source code pool as comments, and into the application documentation. (Doxygen is useful here as it helps keep the comments and the code and the application-level documentation in synch, something which does not happen if you use either comments or outboard documentation. Doxygen can also extract the structures from uncommented code. Maintaining either comments or external documentation can be rather more problematic.)

Application Considerations
Within the OpenVMS application, look at the layered product components that are directly or indirectly involved. This includes networking and databases, as well as packages for forms management or source code management or such. Look at the various language(s) used within the applications. Management packages, archival packages, remote consoles and other such.

Look at what low-level OpenVMS mechanisms are used within the application. This includes shared file access, mailboxes, logical names, ASTs, DECnet, the distributed lock manager and other such constructs.

Look for files with the extensions .CLD, .MMS, .LSE, .TPU and other such. .M64, .M32 and .MAR assembler code, and .BLI, .B64 and .B32 and .REQ, .R32 and .R64 Bliss code. At .SDL code. Specifically look for the .COM files containing DCL command procedures, as all of these various constructs will need to be rewritten. Some of what you find will be used for the application build, some for the run-time environment, and all of it will get tossed out and replaced. (Or potentially encapsulated, should you be looking to retain native compatibility while adding portability.)

Look for printing-related calls and print queues, print symbionts (other than lpr/lpd and telnetsym) and other such. These will need to be rewritten, replaced or migrated.

If you have device drivers or kernel-mode code, all of that code is essentially a write-off. All such code will need to be rewritten.

As the effort proceeds, look at the specific system calls and system references. You'll have to find and dig out (or replace) all the sys$ calls, all the lib$ calls, all the ots$ and cli$ and str$ calls. Or jacket them with equivalent calls on your target platform. Arguably, most any token or string or symbol or filename or header file containing a dollar sign will probably have to be looked at.

Seek out device and directory and file names. These will need to be changed. Look for references to FAB and RAB and XAB blocks, and to NAM blocks and other such; to any direct references to RMS structures. Look for use of FAL — the File Access Listener — for remote file access. Look for dependencies on records, and record processing, and on shared file access.

Look for text strings containing a double colon. This can be the hallmark of DECnet, and of a DECnet node specification.

Look for references to LAT, LAD and LAST devices and related networking.

Look specifically for any sys$qio and sys$qiow calls. These are the equivalent of ioctl or other such; these are direct driver-level I/O calls.

Privileges?

Look for any references to LKSB, AST, and IOSB structures. These are non-portable.

Replacements

All DECnet code moves to IP.

LAT and LAD and LAST moves to ssh and telnet and such.

Clustering moves to NFSv4.1, or to a grid, or similar.

Record-level access and RMS calls move to file-level calls or — far more likely — to a relational database package. To ProgreSQL, MySQL, Oracle or otherwise. To the platform-native file system, such as ZFS.

All sys$qio and sys$qiow calls get rewritten. Underlying application device drivers, if any, also get replaced.

The CLD definitions, macro assembler, TPU and LSE, DCL and other such all get rewritten. The SDL structure definition language is particularly involved, as constructs originating from SDL will tend to have tendrils throughout the source pool.

X Windows calls (surprisingly) move across fairly easily — if the target platform offers X11. (HoffmanLabs would generally avoid using X on Microsoft Windows if X11 on Mac OS X, Solaris, or Linux is an available option.)

Batch queues and such will end up in cron or related, or you'll need to implement a replacement solution.

Approaches Toward Porting

You can look at exporting your data and moving into a new environment, either as part of an incremental migration or as part of an en-mass migration. An incremental migration involves moving over into newer environments, targeting specific areas of the existing application environment and interconnecting these, or exporting data and moving over pieces of the environment.

An incremental migration is likely the easiest and safest approach. Depending on your target environment, you can move across existing code, or you can replace tracts of the existing code with new. The former can be inviting, but then you have even more heinous code than you started with. New code can be rather easier to maintain, and you can take advantage of features and capabilities of the new environment.

The other choice is to toss out the idea of the migration, and to replace your system with an emulator of some sort and various are available, or with a migration to a OpenVMS I64 implementation on an Integrity box.

Migration isn't cheap, after all.

Considerations

Migration to a new platform to gain competitive or cost advantages is entirely reasonable and appropriate. Know what you will gain, and what you will save. Know how you will measure the gains and the savings. Measure this across all your options.

As part of your migration, will you use features of your new platform, or will you seek to remain relatively portable? Or will you seek to isolate non-portable constructs?

Are you migrating because of FUD? Don't. Look at what you are spending, and what you are likely to recoup. Migration solely because of fear is a wasteful expenditure — FUD is a very powerful selling tool, and accordingly widely used. Someone will profit from that fear, and that someone will most certainly not be you or your organization.

Comments?

Remember to re-read Legacy Code: Stay or Upgrade or Migrate?.

HoffmanLabs has ported various applications. Sometimes the port is easy. Sometimes it is not.

Your comments, experiences and related discussions are welcome.

Login or register to post comments  •  Printer friendly version

Exporting RMS File Data...

Submitted by Hoff on May 14, 2007 - 16:03.

RMS data can be exported through an application, creating either stream or stream LF formats. For various applications, exporting to XML-structured data can be expeditious.

RMS supports multiple sequential file formats, of which stream and stream LF are the most transportable.

RMS also supports indexed and relative formats. Indexed formats are not transportable, the closest analog being a database such as MySQL, PostgreSQL, or other similar database. Relative files are not directly transportable, but can potentially be exported into sequential structures without undue effort.

Regardless of the RMS format in use, the data within individual records can be text-format, or binary, or a mix of text and binary. Accordingly, a generic conversion tool is not something easily available. The record structures can be defined in SDL, in CDD, or in the application itself.

You'll end up writing your own converter, if you have binary data embedded. Either to stream or Stream LF, or all the way to a stream or stream LF file using XML structures.

If you have your data in text, then the OpenVMS CONVERT tool (CONVERT or CONVERT/FDL) can potentially be used to get the file from VFC or other non-portable format into a stream or stream LF format.

Login or register to post comments

Differences in Data Allocations

Submitted by Hoff on May 6, 2007 - 13:59.

If working in C, short, int and long and long long can vary in size across platforms. On OpenVMS (64-bit on Alpha and I64), these C variable declarations are words (2 bytes), longwords (4 bytes), longwords (4 bytes) and quadwords (8 bytes). On Mac OS X Leopard (another 64-bit platform), these are 2, 4, 8 and 8; long differs in size.

Various programmers will use local preprocessor declarations in their code to address (mask, isolate) this difference; where an application-local header sets up application-local names appropriate for the system-specified declarations. Something akin to int32 and int64, for instance, can be used.

Login or register to post comments