Mainframe Assembler Options to Convert, Rewrite or Replace

Introduction

IBM Mainframe applications that are created using the COBOL programming language are referred to as "COBOL-oriented applications" in this document. Batch jobs require the use of JCL (Job Control Language) and on-line programs usually interface with a transaction system (for example CICS, Customer Information Control System) and screen handlers such as BMS (Basic Mapping Support). Therefore, a mainframe application may be predominately COBOL but will have other source members such as JCL or BMS (hence COBOL-oriented).

In addition, when performing a migration of an application from the mainframe (EBCDIC encoded with base, displacement addressing in 24 or 31 bit mode using the big endian format) to a Windows, UNIX or Linux platform (usually ASCII encoded with 32 or 64 bit addressing and little endian format) the Assembler programs create a challenge.

The IBM Mainframe Assembler programs or callable routines will need to be replaced with programs or callable routines that are written in a higher-level, portable language that provides platform independence. This effort usually requires a language conversion, a rewrite or a replacement process for the targeted Windows, UNIX or Linux platform.

We have made a significant effort to ensure the documents and software technologies are correct and accurate. We reserve the right to make changes without notice at any time. The function delivered in this version is based upon the enhancement requests from a specific group of users. The intent is to provide changes as the need arises and in a timeframe that is dependent upon the availability of resources.

Copyright © 1987-2025
SimoTime Technologies and Services
All Rights Reserved

Categories for Mainframe Assembler

The Mainframe Assembler programs (HLASM or High Level Assembler) may be divided into four categories.

It would be convenient if the assembler programs were all singular in purpose but that is usually not the case. A single assembler program may fall into 1 or more of the preceding categories. Allowances will need to be made during the planning and migration effort.

Addressing mode (i.e. 24-bit or 31-bit) may need additional attention. The use of the high-order bit to indicate the end of an address list that is being passed as an application function would need to be reviewed and changed. Micro Focus COBOL does have a compiler option of AMODE(31) or AMODE(24) to support this type of addressing but there will be a performance overhead. The amount of overhead will depend on the applications usage and would need to be evaluated as a separate task.

Also, doing pointer arithmetic in COBOL using a redefinition of the pointer item to a binary item will need to be reviewed and possibly changed. On a Mainframe System a pointer is big endian format and can be redefined as a binary or comp field. On a Linux, UNIX or Windows System a pointer item will most likely be in little endian format and the redefined format would need to be changed.

The following sections describe each of these categories (and possible migration considerations and possibilities) in more detail.

Application Oriented Routines

This category lends itself to a high-percentage of programmatic conversion that produces source code in a higher-level language such as COBOL or "C". The members may be compiled and executed on the target platform and produce the same business results as the original Assembler programs.

The following is an example of Application-Oriented Assembler programs or callable routines.

This category may be divided into two sub-categories as described in the following sections.

Application Oriented, Support Service Routines

This sub-category of programs or routines typically performs a technical service for the business processing programs. The challenge with this sub-category is to produce source code in a higher-level language such as COBOL that is ANSI/85 compliant and will run on a Mainframe System and a Distributed System. For example, creating a COBOL program that looks at the bits in a single byte and expands the bit settings to eight bytes of zeroes and ones and runs on multiple systems of different architecture may be a bit of a challenge.

Application Oriented, Business Process

This category lends itself to a programmatic conversion that produces source code in a higher-level language such as COBOL or "C". The members may be compiled and executed on the target platform and produce the same business results as the original Assembler programs.

Data Oriented & non-Executable Members

This category lends itself to programmatic conversion that produces source code in a COBOL Working Storage format (i.e. possible COBOL Copy File) by reading and converting the DS and DC statements in the Assembler program.

This category of assembler usually defines a data structure, table structure or a record layout. The members that define table structures may have code to do the table look-ups. The members that define record layouts may be Assembler Copy Files with individual DSECT's.

With Assembler it is possible to create a non-executable load member from source code that only defines data. This technique is used in the CICS environment to load a table using a single "EXEC CICS LOAD" command rather than having to read multiple records from a data file. The challenges presented by this technique are as follows.

The technology to Generate Non-Executable Load Members for use with Micro Focus Enterprise Server on a Windows System is available. This technology has the ability to generate a non-executable member for the EBCDIC or ASCII encoded environment.

System Oriented Routines

This category does not lend itself to programmatic conversion. A programmatic approach may produce source code in a higher-level language such as COBOL or "C". However, when the members are compiled and executed on the target platform they will not produce the same results as the original Assembler programs and may abnormally terminate.

The following is an example of System-Oriented Assembler programs or callable routines.

The use of mainframe Assembler members that fit into this category needs to be eliminated. In some cases a program or callable routine may be replaced with an existing program. For example, the call to an assembler module to collect information during an unexpected condition or abnormal termination may be replaced with a module from Micro Focus that dumps the call stack and terminates the program (or JOB) execution.

I/O Routines

This category "may" or "may not" lend itself to programmatic conversion depending on how the Assembler member is attempting to process a file.

A programmatic approach to produce source code in a higher-level language such as COBOL should be considered and has value for converting the following parts of the I/O-oriented Assembler program or routine.

Some parts of the programs or routines may need to be rewritten but having the record definitions and business logic automatically converted can be quite useful.

Additional Considerations

Years ago the high-level languages (COBOL, Fortran, PL/I, JCL and others) available on a mainframe system did not have the functionality or performance to meet some of the programming requirements needed to meet the business demands. For example, the COBOL Compilers did not generate executable members that were small and fast enough to meet the performance required. To solve these problems Mainframe Assembler programs and callable routines were written and many are still in use today.

In today's world maintaining support for High-Level Assembler (HLASM) or attempting to port an application with HLASM programs can present a challenge. The following sections provide some insight into these challenges and describe some additional considerations.

Languages and Systems

With the release of the ANSI/85 Standard for COBOL (with reference modification) and IBM's release of COBOL/2 the capability and efficiency of COBOL programs were greatly enhanced and many of the "application-oriented" assembler programs could be converted or rewritten using COBOL.

However, it is important to emphasize that assembler generates executable code that is very close to the system level (both operating system and hardware) while higher level languages try to isolate the user from being system dependent.

Dependencies and Diffusion

HLASM has the capability to interface with the operating system, file systems, communications systems and other subsystems. If a program does any of these functions it is considered a "system or file oriented" program. In other words, the program becomes an extension of the system itself and the line between the two becomes diffused by the nature and dependency of the interface.

A single assembler program of this type may take a number of replacement programs written in a number of different languages. For example, a program that does file I/O with dynamic allocation may take a couple of COBOL programs and a JCL member and require a significant shift in application design.

Macro Processing

HLASM is actually two languages, an Assembler Language and a Macro Language. The Assembler Language translates assembler statements into machine code that is usually executed on an IBM Mainframe System. The Macro Language interprets and executes macro statements (with its unique set of variables, symbols and substitution capability) at assemble time. A macro may be inline in the source member or it may be a separate source member. Macro members are supplied by IBM to performed specific system or file I/O functions. A user may write a macro to perform a specialized or repetitive function.

During assemble time a macro will expand into assembler source code that is then processed by the assembler. This could be analogous to a preprocessor but has considerably more capability. It is also important to note that a macro may generate a variety of different code based on an external substitution parameter. Therefore, a single assembler source member may need to be replaced by a number of programs written in a higher level language.

CICS Interface

If the Assembler programs use CICS then a Subject Matter Expert for CICS will be needed.

IMS Interface

If the Assembler programs use IMS then a Subject Matter Expert for IMS will be needed.

Attitude and Approach

Start by thinking this is not a good thing to continue to support and it may get worse before it gets better but we are going to make it better. The first assumption should be that all the assembler programs will need to be re-written, replaced, converted or eliminated.

This process usually requires a significant redesign of the application or parts of the application being considered for migration to a non-mainframe system. The redesign effort is usually under estimated and/or not considered in the initial assessment. Quite often it is assumed to be included as a minor task within the rewrite effort. The redesign requirements need to be a separate line item to be explicitly addressed in the initial stages of an application migration assessment with due diligence given to the analysis and estimation of the scope of effort.

Next, create an inventory of the application assets (i.e. source code and control card information) on a Windows platform. Create a project with Micro Focus Mainframe Express, Enterprise Edition (MFE/EE) and compile the assembler programs. Analyze the assembler members and categorize by member type (or member orientation) based on function delivered.

Note:  Since a programmatic conversion tool may not be able to deal with macro or copy files it may be necessary to provide an expanded version of the source member or a listing. Micro Focus MFE/EE can provide the expanded source code or a listing.

The following table is provided for estimating and planning purposes and results are very dependent on the quality and structure of the assembler programs. There will be a manual effort required to any programmatic conversion effort and extensive testing will be required.

At one extreme it is possible to have an assembler program that will need to be completely re-designed and re-written. At the other end of the spectrum some assembler programs may be replaced by readily available programs written in a higher level language and only require minor modifications to the application programming interface.

Conversion Methodologies

The following provides an overview of the HLASM to COBOL conversion methodologies used by SimoTime Professional Services.

Plan-A, Programmatic Conversion

This approach is intended for larger, "Application-Oriented" programs or segments within a program. This can be very helpful in converting data definitions from HLASM DSECT's to COBOL Working Storage Definitions.

Note: Note: The converted data structures definitions should get 90-100% conversion. The converted program logic may get 60% or better. The generated COBOL Code may be "System-Oriented" based on the coding style from the HLASM input. It may look a little strange to a COBOL, "Application Oriented" programmer.

Plan-B, Rewrite

This approach is intended for smaller, "Application-Oriented" programs or segments within a larger program.

Plan-C, Hybrid of A and B

This approach is intended for HLASM programs or segments within a program.

Plan-D, Replace

This approach is intended for HLASM programs or segments within a program.

Plan-E, Eliminate

This approach is intended for HLASM programs or segments within a program.

Estimates and Requirements

This section provides a list of questions that will aid in determining the scope of effort for creating the process to do the replacement of the Mainframe Assembler modules. The following questions should be answered at the beginning of the process to migrate an application and its associated data.

Assembler Inventory and Types

The following is used to determine the number of files and the file types and characteristics.

Convert, Replace or Rewrite

The three choices for dealing with the mainframe Assembler programs or routines is as follows.

The Possibilities

The Mainframe Assembler programs or callable routines will need to be replaced with programs or callable routines that are written in a higher-level, portable language that provides platform independence. This effort usually requires a language conversion, a replacement process or a program rewrite for the targeted Windows or UNIX platform.

Conversion Services & Technologies

This approach should be the default. The technology and services provided by SML (http://www.smltd.com) is used in many of our program language conversion projects. This approach is an iterative process that leverages the SML technology and the skills of the SML staff.

The program language conversion process starts on the mainframe. It will be necessary to create source code listings using the user's normal compiler options and additional compiler options that will produce the information for the conversion process.

The following JCL Member ASMCMPJ1.jcl is used to compile an HLASM Program on a Mainframe System with ZOS.

//ASMCMPJ1 JOB CSI01,LAS,CLASS=1,MSGCLASS=O,NOTIFY=CSIP1,COND=(0,LT)
//* *******************************************************************
//*       ASMCMPJ1.JCL - a JCL Member for Batch Job Processing        *
//*       This JCL Member is provided by SimoTime Technologies        *
//*           (C) Copyright 1987-2019 All Rights Reserved             *
//*             Web Site URL:   http://www.simotime.com               *
//*                   e-mail:   helpdesk@simotime.com                 *
//* *******************************************************************
//*
//* Text   - Compile an HLASM Source Member on ZOS Mainframe System
//* Author - SimoTime Technologies
//* Date   - January 24, 1996
//*
//* This JCL Member is used on a SimoTime Test System. Adjustments
//* will need to be made when used in a different mainframe system
//* environment.
//*
//* *******************************************************************
//* Step 1 of 1, Execute the program...
//*              Note: the 'PC(GEN,MCALL,ON)' option is used for the
//*                    Language Conversion Project  This option is in
//*                    addition to the user options.
//*
//         SET MBRNAME=ASMR14A1
//ASM      EXEC PGM=ASMA90,REGION=4M,PARM=('NORENT,DECK,NOOBJ,LIST',
//             'PC(GEN,MCALL,ON)')
//SYSLIB   DD  DISP=SHR,DSN=CSI01.LAS4ADS.ASM
//         DD  DISP=SHR,DSN=SYS1.MACLIB
//         DD  DISP=SHR,DSN=SYS1.MODGEN
//         DD  DISP=SHR,DSN=CSI01.LAS4ADS.ASMMAC1
//SYSIN    DD  DISP=SHR,DSN=CSI01.LAS4ADS.ASM(&MBRNAME)
//SYSUT1   DD  UNIT=SYSALLDA,SPACE=(CYL,(5,5))
//SYSPRINT DD  DISP=SHR,DSN=CSI01.LAS4ADS.LIST(&MBRNAME)
//SYSPUNCH DD  DISP=SHR,DSN=CSI01.LAS4ADS.WORK(&MBRNAME)
//SYSLIN   DD  DISP=SHR,DSN=CSI01.LAS4ADS.OBJS(&MBRNAME)
//SYSTERM  DD  SYSOUT=*
//

Note: The preceding JCL Member is used on a SimoTime Test System. Adjustments will need to be made when used in a different mainframe system environment.

Generally Available Programs

This approach may be used for programs or routines that provide common functions such as date routines. There are a number of third party vendors that supply date routines in Mainframe Assembler, COBOL or "C". For the Micro Focus environment the best choice is usually a replacement with a COBOL version. This reduces the number of languages and program skills required. This also simplifies the debugging effort and programming skills required.

The system-oriented programs or routines such as those used when a user ABEND is required may be replaced with a member that is available from Micro Focus. This member will provide the call stack to show the programs that were executing at the time of the call to the routine.

Rewrite into a Portable Language

This rewrite approach is usually the most time consuming and prone to introducing new problems. When using this approach there are two different methods.

EBCDIC and ASCII Encoding

The conversion of data from EBCDIC to ASCII is usually a primary requirement when doing a migration of an application from the Mainframe to a Windows or UNIX environment. Assembler programs that do data conversions between EBCDIC and ASCII are usually not a problem since they are aware of the two different environments. However, Assembler programs that parse and edit data strings that are assumed to be in EBCDIC format can cause problems in an automated conversion process and may require some manual tuning of the conversion technology or manual changes to the converted programs.

It is important to note that Micro Focus supports both EBCDIC-encoded and ASCII-encoded environments.

Mixed Language or Single Language

This approach requires a compromise. Trying to maintain a single program environment is a very good objective. It is also a good idea to use the proper tool for the proper job. If attempting to maintain a single programming environment requires stretching the capabilities of a language then this approach may create a program that is more difficult to support.

Having said this it is important to note that COBOL has been traditionally underestimated in what it can do. The combination of the functions introduced in ANSI/85 COBOL and the Micro Focus extensions have allowed programmers to push the use of COBOL and maintain language integrity and understanding. In addition, the performance of COBOL compilers has been greatly improved over the years. Today, the COBOL generated code (on the mainframe, Windows, UNIX or Linux) is very compact and efficient.

The following is the recommended approach.

Addressing Memory

When attempting to migrate a mainframe application (EBCDIC encoded with base, displacement addressing in 24 or 31 bit mode using the big endian format) to a Windows or UNIX platform (usually Intel, ASCII encoded with 32 or 64 bit addressing and little endian format) the Assembler conversion or replacement gets both complicated and confusing.

Micro Focus has an option to support mainframe addressing formats (MainFrame Pointer Manager or MFPM) and this allows the use of linear addresses with the high order bit reserved as a flag bit.

Allowances must be made to properly process, convert and/or support the different addressing modes across the different platforms.

The technique of converting a Mainframe Assembler program and having the converted program call "C" subroutines to perform finite tasks will require these "C" subroutines to have an awareness of the various addressing capabilities.

Functions that Require Extra Handling

Assembler coding techniques (and mainframe machine language instructions) that do bit processing or bit shifting may not be easily converted to a higher-level language or a different encoding scheme. For example, a program that edits the units position of a zoned-decimal, numeric field and forces a printable character by setting all the bits in the high-order nibble to an "on" condition will produce the correct results in an EBCDIC environment but fail in an ASCII environment. This coding technique that views the task as a logical function may need to be replaced using a coding technique that views the task as an arithmetic function.

Summary

The following is the preferred approach for dealing with 370 Assembler programs during an application migration from a Mainframe to a Windows or UNIX environment.

The purpose of this document is to assist as a tutorial for new programmers or as a quick reference for experienced programmers. In the world of programming there are many ways to solve a problem. This documents and the links to other documents are intended to provide a choice of alternatives.

In the world of programming there are many ways to solve a problem. This documentation and software were developed and tested on systems that are configured for a SIMOTIME environment based on the hardware, operating systems, user requirements and security requirements. Therefore, adjustments may be needed to execute the jobs and programs when transferred to a system of a different architecture or configuration.

SIMOTIME Services has experience in moving or sharing data or application processing across a variety of systems. For additional information about SIMOTIME Services or Technologies please contact us using the information in the  Contact or Feedback  section of this document.

Software Agreement and Disclaimer

We have made a significant effort to ensure this document is correct and accurate. We reserve the right to make changes without notice at any time at the sole discretion of the author.

The function delivered in this version is based on a set of requirements of a specific group of customers. The intent is to add function as the need arises and in a timeframe that is dependent upon the availability of resources.

Permission to use, copy, modify and distribute this software, documentation or training material for any purpose requires a fee to be paid to SimoTime Technologies. Once the fee is received by SimoTime the latest version of the software, documentation or training material will be delivered and a license will be granted for use within an enterprise, provided the SimoTime copyright notice appear on all copies of the software. The SimoTime name or Logo may not be used in any advertising or publicity pertaining to the use of the software without the written permission of SimoTime Technologies.

SimoTime Technologies makes no warranty or representations about the suitability of the software, documentation or learning material for any purpose. It is provided "AS IS" without any expressed or implied warranty, including the implied warranties of merchantability, fitness for a particular purpose and non-infringement. SimoTime Technologies shall not be liable for any direct, indirect, special or consequential damages resulting from the loss of use, data or projects, whether in an action of contract or tort, arising out of or in connection with the use or performance of this software, documentation or training material.

Downloads and Links

This section includes links to documents with additional information that is beyond the scope and purpose of this document. The first sub-section requires an internet connection, the second sub-section references locally available documents.

Note: A SimoTime License is required for the items to be made available on a local server.

Current Server or Internet Access

    Explore the Assembler Connection for more examples of mainframe Assembler programming techniques and sample code.

    Explore The ASCII and EBCDIC Translation Tables. These tables are provided for individuals that need to better understand the bit structures and differences of the encoding formats.

    Explore The File Status Return Codes that are used to interpret the results of accessing VSAM data sets and/or QSAM files.

    Explore The technology to Generate Non-Executable Load Members from Mainframe Assembler Source Code for use with Micro Focus Enterprise Server on a Windows, Linux or UNIX System. This technology has the ability to generate a non-executable member for the EBCDIC or ASCII encoded environment.

    Explore a complete list of the SimoTime Callable Routines or Utility Programs. This includes the callable routines and utility programs for the Micro Focus environment.

Internet Connection Required

The following links will require an internet connect.

A good place to start is The SimoTime Home Page for access to white papers, program examples and product information. This link requires an Internet Connection

Explore The Micro Focus Web Site for more information about products (including Micro Focus COBOL) and services available from Micro Focus. This link requires an Internet Connection.

Glossary of Terms

    Explore the Glossary of Terms for a list of terms and definitions used in this suite of documents and white papers.

Contact or Feedback

This document was created and is maintained by SimoTime Technologies. If you have any questions, suggestions, comments or feedback please use the following contact information.

We appreciate hearing from you.

Company Overview

SimoTime Technologies was founded in 1987 and is a privately owned company. We specialize in the creation and deployment of business applications using new or existing technologies and services. We have a team of individuals that understand the broad range of technologies being used in today's environments. Our customers include small businesses using Internet technologies to corporations using very large mainframe systems.

Quite often, to reach larger markets or provide a higher level of service to existing customers it requires the newer Internet technologies to work in a complementary manner with existing corporate mainframe systems. We specialize in preparing applications and the associated data that are currently residing on a single platform to be distributed across a variety of platforms.

Preparing the application programs will require the transfer of source members that will be compiled and deployed on the target platform. The data will need to be transferred between the systems and may need to be converted and validated at various stages within the process. SimoTime has the technology, services and experience to assist in the application and data management tasks involved with doing business in a multi-system environment.

Whether you want to use the Internet to expand into new market segments or as a delivery vehicle for existing business functions simply give us a call or check the web site at http://www.simotime.com