Legacy Systems Transforming Mainframe Applications

Introduction

Today, many companies are facing the competitive pressures of providing and gathering information via the Internet. The business of doing business via the Internet has moved to the forefront. Quite often this will require access to data and the coordination with processes of existing systems and business applications. These companies have mainframes running large CICS or IMS applications delivering computerized business functions throughout their enterprise.

These companies would prefer not to make any changes to the mainframe application code and just have things magically work in the Internet environment. However, with current emulation or migration technologies, skills disparity and application design this is impractical for all but the simplest of mainframe applications. Customers are now looking at ways to minimize this effort and accelerate the process of moving to the Internet. This will require a cooperative effort of Internet and Mainframe resources.

Let's take a minute to review the business objectives for extending mainframe legacy applications to the Internet.

Please note that many of the items discussed in this document are based on the hardware and software technologies that were available when this document was created. This is a rapidly changing environment and functional improvements are expected. The intent of this document is to provide readers with various alternatives and possible issues when extending mainframe legacy applications to the Internet.

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

The Target Environment

The goal is to use the Internet to deliver new or existing business functions. This may be within an enterprise via an Intranet or extended directly to the customers of an enterprise via the World Wide Web.

Layer-1 Mainframe   DB2 VSAM IMS MVS Connectivity Services   Layer-2 Transport     Layer-3 Servers   Connectivity Services Oracle Data Base U N I X Application Server Browser Interface   Connectivity Services   Windows   Server Data Base Application Server Browser Interface   Layer-4 Transport     Layer-5 Browsers   Browser Windows   Browser Windows   Browser Windows   Browser Windows   Browser Windows   Browser Windows

Figure 1, Target Environment for Extending Legacy Applications to the Internet

Layer 1 in the preceding figure shows an example of a possible mainframe that has been configured to handle incoming request from intelligent workstations or application servers.

Layer 2 is rapidly becoming a TCP/IP connection instead of an LU-6.2 connection. In recent years more and more companies have added TCP/IP networks to their mainframes.

Layer 3 shows an example of two application server machines. Notice the possible local data bases and the connection between the two application servers. This connection between the application servers make it possible for a windows client running standard browser technology to connect to the application server for NT to access its data base or have the request routed to the application sever for UNIX to access its data base or routed on to the mainframe for processing.

Layer 4 shows the connection between the application server machines and the Windows client machines. This connection is a standard RAS connection using TCP/IP.

Layer 5 shows the client machines running Windows/98/NT/2000 with Internet Explorer or Netscape.

The Current Environment

The current environment may be a CICS or IMS application sending screen images then receiving keyboard responses to and from a fixed function terminal. The terminals are usually 3270's with the screen images being 3270 formats created from BMS (Basic Mapping Services) source members for CICS and MFS (Message Formatting Services) source members for IMS.

Layer-1 Mainframe   DB2 VSAM IMS MVS VTAM   Layer-2 Transport     Layer-3 Controllers   3270 Controller   3270 Controller   Layer-4 Transport     Layer-5 Terminals   3270 Terminal   3270 Terminal   3270 Terminal   3270 Terminal   3270 Terminal   3270 Terminal

Figure 2, Current Environment for Delivering Information within an Enterprise

Layer 1 in the preceding figure shows an example of a possible mainframe that has been configured to handle requests from "fixed function", 3270 terminals. I have not used the term "dumb terminal" for a reason. Many ASCII terminals were dumb terminals that simply scrolled a string of text from left-to-right, top-to-bottom. The 3270 terminals have quite a bit of functionality built into the hardware.

Layer 2 is usually an SSCP-PU connection. In recent years many companies have added TCP/IP networks to their mainframes.

Layer 3 shows an example of two 3270 controllers.

Layer 4 shows the connection between the 3270 controllers and the 3270 terminals. This is usually an LU-2 connection.

Layer 5 shows the 3270 terminals. Normally, these are devices that support screens of 24 lines of 80 characters. Some customers run 3270, model 5 machines that allow more lines and columns. For example, a mod-5 could display 36 lines of 132 characters.

Possibilities and Requirements

No single WEBerization process is suitable for all situations. Companies need to determine the most appropriate process (or variety of processes) based on the company's business requirements, staff competencies and current application constraints.

Let's take a look at a few of the possible approaches for WEBerizing a Legacy application.

Mainframe Screens, Convert to HTML

The first question to answer is, "When should the screens be converted?" The mainframe screens could be converted at execution timecompile time. Doing the mainframe screen conversions at execution time requires the scanning of the 3270 byte stream. Some changes may be needed to the source code to properly handle the conversion and processing of "control key" functions such as the clear, enter, PA-keys and PF-keys. This approach may offer a solution for simple applications that will be deployed within an enterprise via an Intranet. This approach by itself will not provide a solution for the more complex applications. This approach has been tried before to simply provide a GUI interface to an existing mainframe application and had limited success. The end result of this approach is to add another layer of complexity to an already complex production environment without positioning the application for the future in an expanding Internet environment.

Doing the mainframe screen conversions at compile time requires the conversion of the original BMS or MFS source members to HTML members. This approach will probably require some changes to the presentation logic prior to delivering business function directly to the customers of a company via the World Wide Web. The real value to this approach is realized when it is used as the first step in WEBerizing a legacy application by creating HTML components. This also positions the application for the future in an expanding Internet environment. When the appropriate development tools are used the screen conversions can be done quickly and will help the mainframe and Internet programmers begin to understand and leverage the best of both environments. Mainframe Express, a mainframe development tool provided by Micro Focus, has the ability to view, update or create BMS maps with its screen painter. This capability, combined with the BMS to HTML software, provides the mainframe programmer with an automated tool for converting BMS screens to HTML forms.

The mainframe screens to HTML forms conversion software should provide the following.

An additional benefit to the mainframe screen conversion is the ability to quickly model the application as it would appear in the Internet word. This model, when shared with the business users, could provide valuable feedback early in the conversion process.

Combine & Change Screens, Application Code Changes

After the initial conversion of the mainframe screens to HTML forms the WEBerization process takes on a life of its own. Individual screens are improved in appearance and some screen sets are consolidated into a single HTML form and the subsequent paging logic removed from the application program.

For example, it is quite common to find data mapped across 2 or more screens because it would not fit on a single 24x80 character screen. The application programmers typically added the necessary presentation logic to use PF7 and PF8 to scroll forward and backward among the screens. The multiple screens can now be done within a single HTML form and the scrolling from the top to the bottom of the form can be done by the browser, thus simplifying the presentation logic by removing the code for handling PF7 and PF8.

New Presentation Logic & Access to Application Server Data

New presentation logic will be needed as access to systems is provided outside a company. Providing access to business functions by individuals outside the company may require a much higher level of usability than many legacy systems provide. It should not be assumed that what can be accomplished within a company by a skilled employee can be easily mastered by a first time user that is not familiar with the application. Improved documentation or help text will be needed when an individual does not follow the business rules. Readily available help text will be a requirement when moving to the Internet.

Getting a text-based mainframe screen to look like a web page or form is only the first step. Getting the mainframe application to behave like a web application will require most of the work and require changes to the application code.

For larger networks or as network usage increases it may be advantageous to shift data from the mainframe to application server machines. Data base size, volatility and the requirement for immediate shared use by others will be three key factors that determine whether the master copy of a data set will reside on the mainframe or an application server. Many configurations will use a combination of the mainframe and the application servers. In some instances data will even reside on the client machines.

Segment the Application & Distribute the Business Logic

Returning to the mainframe for every client request may not be the most efficient way to deliver information to individuals using the Internet. Identifying segments of business logic and creating components from these segments would allow business logic to be distributed to the application server machines. This should not be viewed as simply porting the code to the application server machine. The mainframe does an excellent job of processing multiple request from multiple users and keeps the individual requests and allocated resources in synchronization with the correct user and does all this concurrently with other processing. Providing this same capability at an acceptable performance level is a minimum requirement for an application server.

An application analysis tool such as Micro Focus Enterprise Analyzer could be used to reduce the analysis time and provide a better understanding of the application. Since most of the business logic on the mainframe is COBOL, an Internet-enabling tool for COBOL could be used to build distributed components.

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.

Applications running on a mainframe are usually written in COBOL. However, some applications are not written in COBOL and many applications are dependent on non-COBOL processes such as calls to 370 assembler subroutines, embedded calls to external sort routines and dependencies on batch processes to create and update existing data bases. Additional time should be allocated to handle these situations.

Additional Topics

The need to quickly provide answers to complex questions for a growing audience is driving the transformation of mainframe applications to the Internet.

The technical challenge is to transform a centralized, predefined process based on terminal sessions to a distributed, event driven, sharing of processes based on application-to-application sessions. This is no longer an environment where a mainframe is polling and controlling a network of fixed-function terminals. This is a networked environment of machines communicating with machines on a peer to peer basis with the primary purpose of delivering information to people.

Centralized or Distributed

Let's take a closer look at this transformation process starting with the Centralized to Distributed effort. In the centralized environment all the data, programs and business logic are performed on the host machine, in this case the mainframe . The first question to answer, "Is it necessary to transform from a centralized to a distributed approach?"

The answer, "It is going to be a compromise. Initially, some success could be obtained by simply converting from the 3270 technology to HTML technology." At this point we are describing a technology swap, not the segmenting and separating of the presentation logic from the business logic and data access logic.

As the transformation process continues the first thing to be distributed will be segments of the data. Shortly thereafter, selected programs and/or program segments will be distributed in order to meet the demands of the business requirements of a company.

One definition for distributed computing is, "Put the necessary computing power in the same location as the mission critical business requirements while making shared processes and data easily available across the enterprise with the proper controls for security and data integrity."

Pre-defined or Event-Driven Processes

Many of the mainframe applications that need to be WEBerized are CICS or IMS. The initial objective was to structure the programs within these applications in such a manner that the presentation logic, business logic and data access logic were separate entities. In reality, the business logic and presentation logic became very interspersed.

The programs were designed and written to follow a predefined set of logic (i.e. sequence of events or code flow with some exception handling for data access errors. This predefined set of program logic was determined by the business rules and the requirements of CICS or IMS. The business logic and the presentation logic are so interspersed in many of today's applications that it is highly unlikely a generic solution that is capable of separating the two will be found in the time frame required to extend the application to the Internet.

There are tools available to help with the analysis of the applications but the segmentation (or componentization) of programs or parts of a program and the subsequent integration of these segments distributed across different machines will be done by the application developers.

Transform, Terminal to Logic Based Sessions

As the presentation logic transforms from 3270 format to HTML forms the purpose of the application program changes from a terminal request to an application request that is data or process oriented. This transformation requires some additional analysis. For example, in a CICS application it is possible to get the terminal ID. Since the terminal ID is unique for each user this value is quite often used when obtaining temporary storage. If this technique is used then it would need to be removed or another technique would need to be implemented.

The EBCDIC and ASCII Environments

Consideration must be given to the properties of the information being passed between the machines in a network. The mainframe works with EBCDIC information. The PC's and many Application Server machines work with ASCII information. When exchanging information between the mainframe and the application server or client machines the following items need to be considered.

JAVA Script to Complement HTML

HTML alone will not provide the necessary function to get to an acceptable conversion from mainframe screens to usable HTML forms. The use of JAVA Scripting will be needed to fine-tune the HTML. For example, the positioning of the cursor in a field on a 3270 screen must be converted to placing focus on the field within the HTML form. Another example would be the validation of digits within a numeric field.

The Mainframe Connection

Many companies want to include the mainframe as a major player functioning in its traditional roll and taking on the new roll of a very powerful server and large data base manager. The mainframe connection may be divided into two sections. One, how to connect the client (or application server) to the mainframe and two, what to do once the connection is established. The "how to connect to the mainframe" has expanded beyond the SNA environment and now includes the TCP/IP environment. Today, most mainframes have TCP/IP networks installed and the remaining few have plans in place to add TCP/IP capability based on business requirements. For the client/server environment or the PC-to-mainframe environment TCP/IP has become the primary connectivity option. The "what to do once the connection is established" are the requirements that need to be defined. These requirements are what differentiate connectivity software from middleware. These requirements will be different across companies but there are some similarities.

Let's take a closer look at each of the above items.

Access to Data or Sharing of Data

This requirement could be as simple as retrieving a single record from a data base and passing the information back to the client. However, this level of simplicity is usually the exception. The mainframe data is usually stored in EBCDIC format and may contain packed, binary or floating point data. These data formats would need to be emulated or converted for use on a PC client. In addition, the information being requested by a client may require access to multiple records within a data base or access to multiple data bases of varying type and structure. In some instances it may be desirable to download a data base or a subset of a data base to the application server or client machine.

Access to Process or Sharing of Process

The client needs to be able to submit a request for processing that may include additional data that is sent (uploaded) to a server machine. The server machine, in this case the mainframe, needs to be able to perform the processing of the collected information and return the results of the processing cycle to the client. In some instances it may be desirable to download the processing components to an application server or client machine.

Immediate Processing

When a client makes a request that requires processing (i.e. the running of an application program) and expects an answer in less than a second (or at least within seconds or minutes) then a networked systems must be able to do the processing immediately and concurrently with other system processes being performed at the time of the request.

Deferred Processing or Shifting of Processing

Sometimes a client request or part of a request may not require immediate processing. For example, a client may submit an order for merchandise and would expect the stock to be allocated immediately, the shipping to occur within 24 hours and the billing to take place within the next thirty days. The billing event needs to be posted but the actual billing process may be deferred.

Many times competitive pressures cause a shifting in processing requirements. For example, the Internet has changed the way many insurance companies respond to requests for policy quotes. It was acceptable for an insurance agent to submit a request for a policy quote that included information about an individual requesting the quote. In the past the insurance agent would submit the request and additional information. The request would be scheduled to run overnight on a regularly schedule run that processed all the requests received during the day. The insurance agent would sign-on to the system the following day and if all the information was submitted correctly they would received their policy quote. Otherwise, they would receive a message describing the reasons why the request was not processed. In today's environment insurance agents expect to be able to get a policy quote in less than five minutes. Also, as companies expand to global markets and the use of the Internet increases the availability of the mainframe's night time window of low utilization that has been used for batch processing is shrinking. It is rapidly becoming a twenty-four hour day with immediate processing requirements.

Questions

Many companies will answer "Yes" to at least four of the following questions with some larger companies answering "Yes" to six or seven.

The preceding questions and the answers provided from within a company need to be addressed prior to starting a Legacy to Internet project. Many companies will need to complement the skills and bandwidth of internal resources with contracted consulting, additional training and possible programming services.

Summary

The intent of this document is to provide readers with various alternatives and possible issues when extending mainframe legacy applications to the Internet. This document may be used 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 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

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 are beyond the scope and purpose of this document. The first group of documents may be available from a local system or via an internet connection, the second group of documents will require an internet connection.

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

Current Server or Internet Access

The following links may be to the current server or to the Internet.

Note: The latest versions of the SimoTime Documents and Program Suites are available on the Internet and may be accessed using the icon. If a user has a SimoTime Enterprise License the Documents and Program Suites may be available on a local server and accessed using the icon.

    Explore the Java and COBOL document that presents the results of a project that converted a CICS, COBOL and BMS transaction to a Java, COBOL and JSP transaction.

    Explore An Enterprise System Model that describes and demonstrates how Applications that were running on a Mainframe System and non-relational data that was located on the Mainframe System were copied and deployed in a Microsoft Windows environment with Micro Focus Enterprise Server.

    Explore the COBOL Connection for more examples of COBOL 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.

Internet Access Required

The following links will require an internet connection.

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