Extend Legacy to the Internet  Transforming Mainframe Applications http://www.simotime.com

Introduction
(Next) (Previous) (Table-of-Contents)

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.

The Target Environment
(Next) (Previous) (Table-of-Contents)

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

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

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

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

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.

Possibilities and Requirements
Mainframe Screen Conversions to HTML
(Next) (Previous) (Table-of-Contents)

The first question to answer is, "When should the screens be converted?" The mainframe screens could be converted at execution time or at compile 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.

Possibilities and Requirements
Consolidate and Change Screens, Application Code Changes
(Next) (Previous) (Table-of-Contents)

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.

Possibilities and Requirements
New Presentation Logic and Access to Application Server Data
(Next) (Previous) (Table-of-Contents)

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.

Possibilities and Requirements
Segmenting the Application and Distributing the Business Logic
(Next) (Previous) (Table-of-Contents)

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 Revolve (refer to http:www.microfocus.com) 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 such as Net Express (refer to http:www.microfocus.com) could be used to build distributed components.

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.

Possibilities and Requirements
Additional Topics
(Next) (Previous) (Table-of-Contents)

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.

Possibilities and Requirements, Additional Topics
Centralized or Distributed
(Next) (Previous) (Table-of-Contents)

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."

Possibilities and Requirements, Additional Topics
Pre-defined or Event-Driven Sharing of Process
(Next) (Previous) (Table-of-Contents)

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.

Possibilities and Requirements, Additional Topics
Transforming from Terminal to Application Based Sessions
(Next) (Previous) (Table-of-Contents)

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.

Possibilities and Requirements, Additional Topics
The EBCDIC and ASCII Environments
(Next) (Previous) (Table-of-Contents)

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.

Possibilities and Requirements, Additional Topics
JAVA Scripting to Complement the HTML Environment
(Next) (Previous) (Table-of-Contents)

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.

Possibilities and Requirements, Additional Topics
The Mainframe Connection
(Next) (Previous) (Table-of-Contents)

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.

The Mainframe Connection
Access to Data or Sharing of Data
(Next) (Previous) (Table-of-Contents)

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.

The Mainframe Connection
Access to Process or Sharing of Process
(Next) (Previous) (Table-of-Contents)

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.

The Mainframe Connection
Immediate Processing
(Next) (Previous) (Table-of-Contents)

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.

The Mainframe Connection,
Deferred Processing or Shifting of Processing
(Next) (Previous) (Table-of-Contents)

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

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

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.

Generally speaking, companies looking to use the Internet as a delivery vehicle for existing business function should consider the BMS or MFS to HTML conversion approach with minimum changes to the application code. This could also be done as the first step in preparing legacy applications to be used as components. This approach offers a solid transformation step to a strategy using component based development methodologies. Companies that are delivering new business functions should consider segmenting existing legacy applications (or copies of existing legacy applications) to gain reuse of business logic as a primary option.

If you have any questions, suggestions or comments please call or send an e-mail to: helpdesk@simotime.com

Links to Similar Pages of Interest
(Next) (Previous) (Table-of-Contents)

A fifteen (15) day "Discovery-Session and Proof-of-Concept" project was completed by SimoTime Enterprises during December, 2001. The objective of this project was to determine the practicality of using existing COBOL programs or parts of programs to backend an Internet frontend written in Java. This project used the Java Developer's Kit (JDK) from Sun Microsystems, Micro Focus Net Express for the COBOL and a Lite Web Server from Gefion Software. The Java and COBOL document presents the results of the SimoTime December Project.

About the Author
(Next) (Previous) (Table-of-Contents)

Larry Simmons, Mr. Simmons is currently a Systems Engineering Manager at Micro Focus, Inc. with the North American Sales Team. For the past ten years he has managed and participated in the development, marketing, sales and deployment of various Micro Focus products, services and customer solutions. Prior to joining Micro Focus he and his wife established SimoTime Enterprises, LLC, a family owned business providing consulting and programming services.

Mr. Simmons started his career in the computing industry with IBM as a Systems Engineer in 1968 and served in various positions at IBM for twenty-one years. He was responsible for customers with IBM mainframes and networked systems of fixed-function terminals, mini-computers, and intelligent workstations. He spent nine years working in the Banking and Insurance Industry specializing in systems communications, on-line banking systems, and interactive claims processing systems. He then spent seven years working in the Distribution Industry specializing in on-line order entry systems, warehouse automation, and inventory control systems. This effort involved the deployment of large central mainframe systems and networked mini-computers doing centralized buying with local inventory control and warehouse management.

His Professional experience in the computer industry spans 30 years working with mainframes, mini-computers and PC's in both stand-alone and distributed computing environments. He enjoys jazz music, Cajun cooking and gardening. He and his wife have two children and maintain a home in Novato, California. He may be reached at:

larry.simmons@simotime.com

About SimoTime Enterprises
(Next) (Previous) (Table-of-Contents)

Founded in 1987, SimoTime Enterprises 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. This includes the smallest thin client using the Internet and the very large mainframe systems. There is more to making the Internet work for your company's business than just having a nice looking WEB site. It is about combining the latest technologies and existing technologies with practical business experience. It's about the business of doing business and looking good in the process. 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. 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