Making Emulation Serve Migration

OmniSolutions Sponsor Message

May 2002

Making Emulation Serve Migration

Call-compatible subroutines, utilities help Unix behave like the MPE/iX environment

By Charles Finley

Last in a series

In the last two issues I have discussed methods to migrate applications from HP 3000s, covering high-level strategies and the IMAGE specifics. This month I will close with a look at making subroutines and routines call-compatible, to let existing business logic work on other platforms.

A unique attribute of business legacy systems such as the HP 3000 is that they contain a vast amount of valuable business knowledge and procedures. These are elements that should be retained in the new systems that will replace them. My company believes that migration of these systems is the way to retain this value.

Various utilities and subroutines can help a migrated application run on the target system. Examples include the automated data structure mapping of KSAM files to an indexed file system of the target computer and the export and import of KSAM data. This can be accomplished, for example, using either the Informix C-ISAM or bytedesign’s D-ISAM file system.

An MPE-compatible print queue manager which also operates on Unix platforms can enhance the limited capability of printer and print job control on Unix systems. This manager can provide an emulation of the MPE spooler in addition to functionality such as:

• Printer management by forms and paper stock

• Operator control and intervention

• Multiple and partial file printing

• Post-submission modification of print job characteristics

• Print file review and display

• Physical and virtual printer support

• Dynamic modification of printer characteristics

• Application Program Interface for direct printer control

• Automatic and transparent network operation

In addition, a batch job manager can provide functionality that is otherwise very limited on a Unix system. The batch job manager presents a centralized and more powerful point of control over the batch environment and gives capabilities very similar to those on MPE.

Porting of non-COBOL applications

This series has emphasized COBOL migration, since that is the primary development language on the HP e3000. It is also possible to port Fortran, Pascal, C, SPL, RPG, and BASIC third-generation languages, as well as fourth-generation languages Powerhouse and Speedware.

Fortran 77 and Pascal porting are dependent on the capabilities of the compilers and their runtime libraries on the target platform. Both Fortran and Pascal have some hidden dependencies on the MPE file system that must be addressed prior to porting. C/iX is perhaps the most portable language on the HP e3000.

There are two versions of BASIC on MPE: Business Basic and Basic/3000. They are both somewhat of a challenge to port because they are unique dialects and also have MPE file system and intrinsic dependencies built in. SPL is surprisingly portable thanks to the SPLASH compiler from Allegro Consultants (www.allegro.com). It is capable of changing SPL to C code. RPG should be translated to either C or COBOL in order to move it to another platform. Finally, products from the fourth-generation language vendors Cognos and Speedware are perhaps among the easiest applications to port. They run on a number of different platforms and their code is quite portable.

It is sometimes desirable to move away from some of the older languages to one that can be more easily enhanced or supported. Translators either exist or can be built to translate many of the third-generation languages to C, C++, Java, or even Visual Basic. Moreover, translators could potentially be built to translate some of the more obscure discontinued languages such as Business Report Writer to C or Java. There has also been some interest expressed in translating Powerhouse or Speedware code to Java or C++.

Optimizing terminal operation and screen management

The standard migration procedure for VPlus form files is to convert them with the same character-based look and feel. Migration of VPlus forms files provides a significant opportunity for application enhancement. The block-mode look and feel of VPlus is an area in which modernization to a GUI and its capabilities can give positive benefits. Several packages are available to accomplish this on the HP e3000. Migration to Unix, however, involves:

• Automated translation of the VPlus forms files to a format readable on the target platform.

• Preservation of the editing specifications for these forms.

• A management utility to maintain and enhance these migrated forms on the target platform.

• A call-compatible library of VPlus intrinsics.

Since the goal is to achieve as close to a 100-percent automated migration as possible, all possible editing specifications and editing constructs must be supported. The call-compatible library of intrinsics must support all VPlus functionality to avoid any manual changes to the COBOL code.

Terminal support on Unix is handled by the termcap and terminfo utilities. The termcap scheme was developed to support vi, the screen-oriented visual display editor (or very interesting editor) for Unix. The termcap file contains descriptions of the features supported by the terminal (how many lines and rows, whether the terminal supports backspace, etc.) and ways to make the terminal perform certain operations (clear the screen, move the cursor to a given location, etc.).

As more and more terminal types appeared, terminfo and its associated curses library were developed. Terminal descriptions in terminfo are essentially compiled versions of a textual description and can be located faster at run time. Again, terminfo performs typical operations (clear the screen, move the cursor) on a wide variety of terminals. The curses library provides functions that give added ability, such as setting raw mode and setting echo on and off.

The limitation of curses is that it was designed for character-based terminals, while today the trend is toward pixel-based graphics terminals supporting graphical user interfaces. Curses screen performance also has some limitations in terms of unnecessary screen clearing and cursor movement.

Screen management technology has been enhanced for character-based terminals to provide high levels of performance. This involves low-level routines to use escape sequences to control cursor positioning, highlighting, graphics and line drawing, and display of data. These routines are designed to maintain logical buffering of before and after images of the screen, as well as optimization of screen attributes, screen positioning, and data display and capture.

The implementation of a GUI solution for VPlus screens can involve the use of advanced terminal emulators running in a Windows environment as a front end to the character-based IO and screen control routines. With these emulators, it is possible to incorporate capabilities such as hypertext help and copy and paste. Modernization involves the use of window objects such as message boxes, dialogue boxes, text boxes, list boxes, scroll bars, tool bars, and image displays.

The Unix COBOL vendors have integrated GUI screen developers and managers into their compiler products as front ends. This can involve a fair amount of reengineering and time to produce a solution if there are a large number of VPlus forms files to migrate and no automated tool.

Finally, solutions now exist to migrate VPlus forms files automatically to advanced GUI management systems. These are graphical PC-based client-server application development systems. Migrated forms will run as true window clients on PCs under Microsoft Windows or on X terminals and workstations under OSF/Motif. These tools clearly will give the most advanced modernization capabilities and functionality available. With their development interfaces, text/input fields can be replaced with typical graphical user elements. The front end will automatically map the appropriate GUI objects to VPlus screen elements.

Conclusions

Tools are available to migrate existing MPE COBOL II applications to Unix or Windows, as well as more modern COBOL development environments. The use of these tools presents the best opportunity for a successful migration. The suggested strategy is to migrate using automated tools and utilities. This approach minimizes risk and development and deployment time and costs.

If there is a need to enhance the application, it is best to port the entire application using the existing methods of use. This provides for an immediate test environment for the newly changed system and allows for parallelism in testing and future development.

Charles Finley (cfinley@xformix.com) is president of Transformix Computer Corporation (www.xformix.com), a company that specializes in the migration and enhancement of MPE applications to Unix and Windows using its XFORM suite of tools.