Options to Convert, Rewrite or Replace
|The SimoTime Home Page|
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 or UNIX platform (usually ASCII encoded with 32 or 64 bit addressing and little endian format) the Assembler programs create a challenge.
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 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-2017
All Rights Reserved
The Mainframe Assembler programs (HLASM or High Level Assembler) may be divided into four categories.
|Categories for Mainframe Assembler|
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.
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.
|Examples of Application Oriented Programs and Routines|
This category may be divided into two sub-categories as described in the following sections.
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.
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.
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 Challenges of Creating Non-Executable Load Members|
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.
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.
|An Example of System-Oriented Assembler programs|
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.
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.
|Source Code that may be Programmatically Converted|
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.
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.
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.
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.
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.
If the Assembler programs use CICS then a Subject Matter Expert for CICS will be needed.
If the Assembler programs use IMS then a Subject Matter Expert for IMS will be needed.
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.
|Conversion or Replacement Effort by Program Orientation or Properties|
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.
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.
The following is used to determine the number of files and the file types and characteristics.
|1.||How many mainline Assembler programs do you have to be converted?||_____|
|1.a. How many of these programs perform Application logic?||_____|
|1.b. How many of these programs are Data Oriented?||_____|
|1.c. How many of these programs perform “System Dependent” logic?||_____|
|1.d. How many of these programs perform file I/O?||_____|
|2.||How many callable Assembler routines do you have to be converted?||_____|
|2.a. How many of these routines perform Application logic?||_____|
|2.b. How many of these routines are Data Oriented?||_____|
|2.c. How many of these routines perform “System Dependent” logic?||_____|
|2.d. How many of these routines perform file I/O?||_____|
The three choices for dealing with the mainframe Assembler programs or routines is as follows.
|1.||Use a consulting and services company that has the language conversion technology and the variety of skills that are required to perform a language conversion. This will be an iterative process. The following Micro Focus Partner provides Mainframe Assembler Conversion Services - (http://www.smltd.com)|
|2.||Replace programs or routines with generally available programs or routines. This may require some adjustments to the programming interfaces.|
|3.||Rewrite the programs or routines. The major considerations for this option are as follows.|
|3.a. High Risk, High Cost|
|3.b. Time Consuming|
|3.c. Skills availability or shortage|
|3.d. Multiple Platform skills|
|3.e. Multiple programming language skills|
|3.f. This option should be used in conjunction with option-1 whenever possible.|
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.
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-2017 All Rights Reserved * //* Web Site URL: http://www.simotime.com * //* e-mail: firstname.lastname@example.org * //* ******************************************************************* //* //* 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.
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.
This rewrite approach is usually the most time consuming and prone to introducing new problems. When using this approach there are two different methods.
|Approaches to Replace or Convert Mainframe Assembler Programs|
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.
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.
|Approaches to Replace or Convert Mainframe Assembler Programs|
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.
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.
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.
|Approaches to Replace or Convert Mainframe Assembler Programs|
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 document and the links to other documents are intended to provide a greater awareness of the Data Management and Application Processing alternatives.
The 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 send an e-mail to: email@example.com or call 415 883-6565. We appreciate hearing from you.
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.
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.
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 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.
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 and services available from Micro Focus. This link requires an Internet Connection.
Explore the Glossary of Terms for a list of terms and definitions used in this suite of documents and white papers.
This document was created and is copyrighted and maintained by SimoTime Technologies.
If you have any questions, suggestions, comments or feedback please call or send an e-mail to: firstname.lastname@example.org
We appreciate hearing from you.
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
|Mainframe Assembler, Options to Convert, Rewrite or Replace|
|Copyright © 1987-2017
SimoTime Technologies and Services
All Rights Reserved
|When technology complements business|