Mainframe Assembler
Options to Convert, Rewrite or Replace
  Table of Contents  v-16.01.01 - asmalt01.htm 
  Introduction
  Categories for Mainframe Assembler
  Application Oriented Routines
  Application Oriented, Support Service Routines
  Application Oriented, Business Process
  Data Oriented & non-Executable Members
  System Oriented Routines
  I/O Routines
  Additional Considerations
  Languages and Systems
  Dependencies and Diffusion
  Macro Processing
  CICS Interface
  IMS Interface
  Attitude and Approach
  Estimates and Requirements
  Assembler Inventory and Types
  Convert, Replace or Rewrite
  The Possibilities
  Conversion Services & Technologies
  Generally Available Programs
  Rewrite into a Portable Language
  EBCDIC and ASCII Encoding
  Mixed Language or Single Language
  Addressing Memory
  Functions that Require Extra Handling
  Summary
  Software Agreement and Disclaimer
  Downloads and Links
  Current Server or Internet Access
  Internet Connection Required
  Glossary of Terms
  Comments or Feedback
  Company Overview
The SimoTime Home Page 

Table of Contents Previous Section Next Section Introduction

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
SimoTime Technologies
All Rights Reserved

Table of Contents Previous Section Next Section Categories for Mainframe Assembler

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

1 Application Oriented (business logic and support services)
2 Data Oriented (includes Data Tables & non-Executable Load Members)
3 System Oriented
4 File I/O Oriented
  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.

Table of Contents Previous Section Next Section 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.

1 Business Logic programs
2 Business Function routines
3 Date and Time routines
4 Actuarial routines
5 Parsing routines
6 Table processing routines
7 Compute intensive routines
  Examples of Application Oriented Programs and Routines

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

Table of Contents Previous Section Next Section 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.

Table of Contents Previous Section Next Section 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.

Table of Contents Previous Section Next Section 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.

1 Creating a non-executable member in a non-assembler environment
2 EBCDIC to ASCII Conversion
3 Difference in collating sequence for alpha-numeric search arguments and binary search algorithms.
  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.

Table of Contents Previous Section Next Section 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.

1 Accessing or Chasing MVS Control Blocks
2 Dynamic Allocation of DSN’s
3 ABEND and Save Area Chains
  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.

Table of Contents Previous Section Next Section 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.

1 Convert the record definitions
2 Convert the business functions
  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.

Table of Contents Previous Section Next Section 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.

Table of Contents Previous Section Next Section 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.

Table of Contents Previous Section Next Section 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.

Table of Contents Previous Section Next Section 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.

Table of Contents Previous Section Next Section CICS Interface

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

Table of Contents Previous Section Next Section IMS Interface

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

Table of Contents Previous Section Next Section 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.

Orientation Expectation
Application These are good candidates for programmatic conversion and may obtain a conversion rate exceeding 90%. Plan on this being an iterative process and may require tweaking and tuning of the programmatic conversion tool.
Data May get a conversion rate that varies from 50-80% depending on complexity of data structures. Depending on the complexity of the data structures (i.e. field level, tables, arrays and data types) this will require various levels of manual adjustment and conversion.
File I/O May be able to obtain a 40-60% programmatic conversion rate. This will require the involvement of an individual with an understanding of assembler programming, the target language and data file structures and access methods (both the Mainframe and Micro Focus).
System Expect a zero conversion rate for a programmatic effort. The code may appear to convert but system interfaces will fail at execution time.
  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.

Table of Contents Previous Section Next Section 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.

Table of Contents Previous Section Next Section Assembler Inventory and Types

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? _____

Table of Contents Previous Section Next Section Convert, Replace or Rewrite

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.

Table of Contents Previous Section Next Section 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.

Table of Contents Previous Section Next Section 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-2017 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.

Table of Contents Previous Section Next Section 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.

Table of Contents Previous Section Next Section 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.

1 Reverse engineer the Assembler members by analyzing the code and writing a new program that performs the same functions using the same techniques as the original program. This approach needs to consider the following.
1a.The programmer must have a working knowledge of Mainframe Assembler and the new target language.
1b.A line-for-line interpretation usually results in a “force-fit” of techniques that look strange in the new language and may not be easily understood by support programmers.
2 Analyze the Business requirements and the current API (Application Programming Interface) and write a new program based on the current API and requirements. This is usually the better alternative for re-writing because of the following.
2a.This does not require the programmer to understand the Mainframe Assembler.
2b.The new program will be written using the techniques of the newer, high-level language.
  Approaches to Replace or Convert Mainframe Assembler Programs

Table of Contents Previous Section Next Section 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.

Table of Contents Previous Section Next Section 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.

1 Converting the mainframe Assembler programs to COBOL should be the first choice for a targeted Micro Focus environment on a Windows or UNIX platform.
2 Converting the mainframe Assembler programs to “C” or another language other than COBOL should be done on an exception basis.
  Approaches to Replace or Convert Mainframe Assembler Programs

Table of Contents Previous Section Next Section 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.

Table of Contents Previous Section Next Section 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.

Table of Contents Previous Section Next Section 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.

1 Programmatically convert (or reverse engineer) the programs from Mainframe Assembler to Micro Focus COBOL.
2 Replace with generally available programs that are written in a portable (or platform independent) language.
3 Rewrite into a portable (or platform) independent language.
  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: helpdesk@simotime.com or call 415 883-6565. We appreciate hearing from you.

Table of Contents Previous Section Next Section 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.

Table of Contents Previous Section Next Section 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.

Table of Contents Previous Section Next Section Current Server or Internet Access

Link to Internet   Link to 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.

Link to Internet   Link to Server   Explore The File Status Return Codes to interpret the results of accessing VSAM data sets and/or QSAM files.

Link to Internet   Link to Server   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.

Link to Internet   Link to Server   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.

Table of Contents Previous Section Next Section 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 and services available from Micro Focus. This link requires an Internet Connection.

Table of Contents Previous Section Next Section Glossary of Terms

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

Table of Contents Previous Section Next Section Comments or Feedback

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: helpdesk@simotime.com

We appreciate hearing from you.

Table of Contents Previous Section Next Section 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


Return-to-Top
Mainframe Assembler, Options to Convert, Rewrite or Replace
Copyright © 1987-2017
SimoTime Technologies and Services
All Rights Reserved
When technology complements business
http://www.simotime.com