Replatform Primer

©Copyright T3 Technologies 2011 All Rights Reserved

Replatform Primer

Getting the Facts Straight

Replatform Primer ©Copyright T3 Technologies 2011 All Rights Reserved ii

Table of Contents

TRANSITION STRATEGIES .............................................................................................................................. 1

PATH OF LEAST RESISTANCE ................................................................................................................................... 1

TRANSITION PATH .......................................................................................................................................................... 2

MAINFRAME TRANSFORMATION OPTIONS ................................................................................................ 3

EMULATION................................................................................................................................................................ 3

RENEW ...................................................................................................................................................................... 3

REARCHITECT ........................................................................................................................................................... 3

REWRITE ................................................................................................................................................................... 3

REFACTOR................................................................................................................................................................. 4

REPLACE ................................................................................................................................................................... 4

REPLATFORM ............................................................................................................................................................ 4

REPLATFORM STACK ...................................................................................................................................... 5

REPLATFORM THE SOFTWARE STACK ...................................................................................................................... 5

Batch .................................................................................................................................................................... 5

Online Transaction Processing (OLTP) .......................................................................................................... 6

Software Replatform Summary ........................................................................................................................ 6

CODE REPLATFORM .................................................................................................................................................. 6

Replatform: Avoiding Temptations .................................................................................................................. 7

DATA REPLATFORM .................................................................................................................................................. 7

DataMover ........................................................................................................................................................... 7

PROCESS REPLATFORM ........................................................................................................................................... 8

REPLATFORM PREPARATION ....................................................................................................................... 9

REPLATFORM ASSESSMENT AND SUPPORT MATERIALS ....................................................................................... 10

REPLATFORM RESPONSIBILITIES .............................................................................................................. 11

ACCEPTANCE CERTIFICATION (TEST) .................................................................................................................... 11

PERFORMANCE TEST .............................................................................................................................................. 11

T3 TECHNOLOGIES LIBERTY 2.0 ................................................................................................................. 13

HARDWARE STACK POTENTIAL CONFIGURATIONS ................................................................................................ 13

Small Workloads .............................................................................................................................................. 13

Larger Workloads ............................................................................................................................................. 14

REPLATFORM PROJECT - GETTING STARTED ........................................................................................ 16

REVIEWING THE ASSESSMENT ............................................................................................................................... 16

MAKING THE DECISION AND GETTING STARTED .................................................................................................... 16

VALIDATING THE RESULTS ...................................................................................................................................... 16

GO LIVE! .................................................................................................................................................................. 16

Replatform Primer ©Copyright T3 Technologies 2011 All Rights Reserved 1

Transition Strategies

The accumulated intellectual assets of the IT Business Software Systems are valuable and in

many ways define and characterize each unique business. Sustaining a competitive stance and

advantage in the market requires that business IT maintain the mainframe ethic (reliability,

maintainability, sustainability) yet add that ability to nimbly respond to changing market

demands.

IT Dynamics require that businesses reduce the total cost of ownership (TCO), and along the

way deliver a compelling return on investment (ROI) as part of any actions selected. Oftentimes,

one of the most significant cost factors of an IBM mainframe environment is the cost of the data

center, application maintenance and the supporting tools. These factors alone should cause an

organization to analyze the cost and return (value) of the overall environment.

Path of Least Resistance

Transitioning from the mainframe, one should consider the ease of effort along with the scope of

the applications and the implication of change. Minimizing change can permit reaching the goal

with minimal disruption and reduced effort. Net: Finding the transformation option with least cost

and quickest transformation is an important consideration.

Figure 1 − Mainframe Migration Alternatives

Legacy Application & Resources

Change

Evolutionary

Changes/Support

Mainframe Migration/Modernization Paths

Faithful Replication

Transformation

Consistency

No Changes/

Full Support

Sa

me

Fu

nctio

ns

Matc

hin

g

Layo

ut

Layo

ut

Fu

nctio

ns m

ap

ped

to

new

para

dig

m

Co

nv

erte

d

Syn

tax

Sa

me

S

yn

tax

Process Execution

Data Representation

Code


Transition Path

The transition path from the mainframe will ideally offer a solution with the same characteristics

and capabilities as those one would find on the mainframe. A mainframe alternative should

allow for lateral or “like” capabilities which aligns to functions already in place in the existing

system. It is of utmost importance that these areas are equivalent or improved upon in a

transition from the mainframe:

Consistency – deliver equivalent functionality and capability so that the end user may not

notice any changes.

Maintainability – transform the applications and subsystems that deliver “like” functions.

Systems are maintainable using familiar technologies which are consistent with existing

systems and services. One should be able to make changes to and extend the applications

using similar functions.

Reliability, Availability and Serviceability (RAS) – Up-time is crucial to all business

applications and Service Level Commitments should be able to be maintained within the

same criteria as was expected on the mainframe.

Security – Application and Data Security as supported by RACF or ACF2 must be

maintained. Applications and Data are the lifeblood of the business, and nothing should

permit exposure of business assets to possible threats or unrestricted access. Data must be

secure!

Extensibility and Scalability – the solution must permit ease of expanding systems and

applications in size and scope to meet the demands of an evolving enterprise.

It is extremely important to choose the right transition path; one that allows for equivalent or

improved function in of all of the above areas. Choosing the wrong path can lead to changing

mission critical, long standing business processes.


Mainframe Transformation Options

Emulation

Before discussing the various “Re…” options, Emulation should be reflected upon. There is a

little confusion about emulation. Emulation means that the environment is reproduced in such a

way that the current set of applications can be run in the same manner without any changes. It

means that the base operating environment is available in the emulated environment, along with

any subsystems and runtime environments that will cause those applications to operate just as

they did in the mainframe environment. The operative words here are: “no changes,” “no

recompile,” and “an emulated system.”

Emulation of the IBM mainframe does not exist as a commercial option. IBM does not currently

license the operating environment independent of the hardware, and therefore, removes

emulation as an option.

Renew

Expand the technology mix on the mainframe by connecting a Client/Server environment to a

mainframe system and provisioning. A layer of services is added to drive further effectiveness of

mainframe applications. It is also possible to refresh the user interface with SOA. With the

Renew option minimal function is added without improving the underlying technology.

Rearchitect

The Rearchitect option can use the existing application as a design starting point, and from that

point re-design the application adding and subtracting functions as necessary to produce the

desired function. This option is normally applied at an application level with an understanding of

the target environment upon which the application will execute. This option is very risky because

it requires that the application being replaced is well understood and that all dependent

functions and interfaces are implemented. Re-architected options normally take longer to

implement and have the greatest potential to be cancelled or delayed.

Rewrite

The rewrite option will use the program design from a previous version of the application as a

basis for implementing the follow-on application in a new programming language. An example of

this might be rewriting a PL/I application in COBOL, or a COBOL application in Java. The risk

with this option is that the capabilities of the different programming language are not the same

and that the resulting application may not be consistent with the original. The rewrite option has

many of the same characteristics as the Rearchitect option and the risk is that the project will

take longer, and not all environmental issues will be implemented in a consistent way with the

previous version, resulting in breakage.


Refactor

To refactor is to transform mainframe source artifacts and redeploy the applications to a

different operating environment.

The refactor option is in many ways like the rewrite, but changes a component of the application

to use a modern technology and removes a dependency of an obsolete or costly technology.

The example of this might be removing a dependency on CA-Datacom or CA-IDMS and

replacing the data store with one of the popular SQL databases such as SQLServer. This is less

risky than the rewrite, but may carry with it a large number of code changes along with the

associated data migration effort.

Replace

The replace option is dependent on finding a software package or offering that delivers

equivalent function. It could be a commercial off the shelf (COTS) package that delivers most to

all of the function of the previous option. The challenge with this option is that it is unlikely that

all the capabilities required will be part of the replacement option. Risk is associated with the

missing capabilities or missing interfaces that must be added to the software package and the

complexities associated with making these additions.

Replatform

The replatform option is like all the others, application specific. In most instances, this option is

the easiest course of action and has the least risk. The best way to describe this option is that it

is a “like-like” option; where the application written in COBOL is compiled by a COBOL compiler

with the same capability. Data stored in VSAM, PDS/E or GDG’s is moved to the same file

format on an “Open” platform (Microsoft Windows). DB2 (SQL data) is moved to a like database

such as SQL Server. OLTP Online systems such as CICS and IMS use the same function and

Batch processes use the same capability on an alternate platform.

To replatform is to reuse the mainframe source artifacts and redeploy the applications onto a

different operating environment.

Table 1 −Emulation and Replatform Comparison

Emulation Replatform

Binary level emulation Source level recompilation

Requires IBM stack (no longer available) Eliminates (replaced by Windows)

Requires 3rd party stack (requires OS) Eliminates (replaced with equivalent technology)

Hardware specific Hardware neutral

Disaster Recovery challenged Disaster Recovery friendly

Agility unchanged Staged for modernization


Replatform Stack

The T3 Technologies’ replatform stack is comprised of elements that, in most instances,

replicate both the capabilities and characteristics of those features used within the mainframe

environment. The “secret sauce” in the T3 Technologies (T3) solution, Liberty 2.0, is that it

brings together decades of experience with both the mainframe and also the target platform.

The result is a highly compatible solution permitting a smooth transition from the mainframe to

the replatformed alternative.

Replatform the Software Stack

The traditional mainframe software stack can be replaced with a stack offering the same

functionality while residing on the mainframe alternative.

Batch

The applications, jobs, and procedures are replicated in the replatformed solution. These

continue to execute in the new environment just as they did on the mainframe. T3 Technologies

has perfected the technology over the years and has developed a repeatable process, and has

proven processes that can assure clients that replatformed batch continues to deliver and meet

expectations of our clients.

MVS, OS390, Z/OS, VSE, VM

Applications

Batch Online

Zeke, AutoSys,

TidalE

TSO, RJE,

INTRDR CICS, IMS/TM,

ADS/O JCL, REXX, CLIST, TSO/ISPF

COBOL,

PLI, ASMT SORT,

IDCAMSA

SCCM, DR, Performance

3270, BMS, MFS, ISPFe

DB2, IMS, VSAM, SAMFe/ISPFizatio

RACF, ACF2, Top SecretI

Mainframe

Windows Server, Virtualization

Applications

Batch Online

Active Batch, AutoSys, Tidal…

RJE.NET,

INTRDR Micro Focus

CICS, IMS/TM, WS Micro Focus Enterprise Server Batch

COBOL,

PLI SORT,

IDCAMSE

VSTS, DR, PerfMon, SCOM

3270, ASP.NET, WPF

SQL Server, VSAM, SAMOMServer Batc

Active Directory

Liberty 2.0 Mainframe Alternative


Online Transaction Processing (OLTP)

Applications and associated transactions which either execute in IBM CICS or IBM IMS are

supported through T3 Technologies’ replatform solution. The interplay between transaction

screens (IMS MFS Maps, CICS BMS Maps) and data (either in a Database or stored in Data

Sets) continue to function as they did on the mainframe. The 3270 “green screen” interfaces is

brought forward while maintaining all the function keys and entry short cuts that the end user is

familiar with using.

Software Replatform Summary

The bottom line is that the quickest and most efficient method for decommissioning a mainframe

system is to move to a like environment with like tools and like capabilities. Inasmuch as a

mainframe decommissioning project can stay on target, with controlled software and data

assets, locking-out project creep; the project has the best opportunity for success with minimal

cost and least time. Of all the transformation options, the replatform option carries the least risk

and the least amount of time with the minimal cost and fastest return on investment.

Code Replatform

Following the path of least resistance, the application software is moved and recompiled as-is.

There is no attempt to make any changes to the code except to remediate the few things that

need to be modified in order for the application to execute properly in the new environment.

Things that may need to be changed are EBCDIC to ASCII issues; remember the mainframe is

EBCDIC and ASCII is used in Windows and other non-mainframe systems. Also, areas where

“coding tricks” may have been used that checked a “hexadecimal” value may need to be

changed. The majority of the software is used without changes.

T3 Technologies experience is a valuable resource. T3 has seen, been exposed to and

resolved the issues that could impact a successful replatforming project. The “secret sauce” is

not only having the right tools but, the experience that catches the issues which could impact a

successful outcome.

Table 2 −Mainframe Artifact Replatform Illustrations

Artifact Technique

COBOL Reused with minimal change

BMS Reused with no changes

Assembler Refactored

Focus (and other 3.5 GL languages) Refactored

SQL Reused with minimal change

As noted in the previous table, T3 Technologies will transition forward applications written in

various programming languages and technologies. In an area where a “like” solution does not


exist, T3 has, in most instances, provided a proven alternative that can be used to refactor away

from these technologies (tools).

Replatform: Avoiding Temptations

Many times, analysis of a project identifies an application or module which would be good to

rewrite, restructure or optimize. While on the outset this seems like a very good idea, it could

lead to increasing the size of the replatform effort and, as a result, increase both the cost and

the time to complete the project. These temptations should be avoided and be addressed as a

secondary effort.

T3 Technologies’ experience can be valuable, and help maintain discipline that will keep the

project on-track, on-time and in-budget.

Data Replatform

The application data is, in most instances, one of the most valuable business assets. The

present resource is leveraged for the future of the business. The keys to the data are in many

instances locked in the application. When the data is moved, both the application and the data

must be replatformed in lock-step. The path of least resistance means in the case of the data

that data formats are not changed, data access methods are unchanged and database

capabilities are maintained.

The discipline used in all other facets of the replatform efforts are maintained and applied to

data. The data is not changed, but migrated and used as-is; this offers the least risk and the

quickest path away from the mainframe.

DataMover

T3 Technologies’ DataMover provides support for moving traditional mainframe data sources to

SQL file formats. The following chart describes the technique applied for each of the data set

types normally found on a mainframe, and this chart can be used as a reference:

Table 3 −Data Replatform Techniques with DataMover

Artifact Technique

Sequential files Migrated, no change

GDG’s Migrated, no change, behavior supported

Partitioned Migrated, folder structures

VSAM Migrated, no change

Tables Migrated to SQL Server, no schema changes

* All data becomes ASCII

There may be slight changes required to RDBMS data due to application dependent functions

used within the database. Some areas that are part of a replatform project and may require

effort might be differences in capabilities between stored procedures, or perhaps security.


Here again, T3 Technologies’ experience is valuable; having seen most, if not all scenarios

results in the experience necessary to determine the best alternatives.

Process Replatform

The traditional mainframe processes are the lifeblood of the business. Business processes flow

based upon a fixed set of activities needed to provide information necessary for various

segments of the business to function and maintain necessary controls. A replatform effort

replicates these processes and their associated dependencies, so that workflow continues

without making changes to the way things are accomplished.

The systems environment; meaning overall process, security, operations, backup and disaster

recovery, etc. must remain in place. Some of these elements of the systems environment may

be refactored as needed to maintain consistent characteristics within target environment.

Table 4 −Process Transformation Techniques

Artifact Technique

Batch job streams / PROC’s Migrated, no change

Other scripting Migrated / Refactored

Job Schedules Migrated, minimal changes with tTime Job Scheduler

Security / Access Control Refactored to Active Directory

Ops / Systems Management Refactored to SCOM

Backup / Restore Virtualized

Disaster Recovery Virtualized

Experience is valuable. T3 has experience in evaluating the big picture. Delivering complete

solutions is extremely important in producing successful replatform outcomes. One wants to be

able to transition from one platform to another with a minimal risk. The result is one where all

areas of the IT infrastructure continue to function and deliver the required results.


Replatform Preparation

A successful replatform project begins with assessing and validating the current system,

applications and jobs. The analysis that must be performed is that which should be done by any

organization that desires to maintain control of the IT business; both its assets and operations.

Solutions Lifecycle

DiscoveryEnvisioning & Planning

Developing Stabilizing Deploying Operating Optimizing

• Source Code Assessment

• Gap Analysis

• Operations Review

• Service Level Commitments/

Performance Requirement

• Infrastructure Design

• Process Design

• Governance Model

• Project Plan

Figure 2 −Assessment to create a Project Plan

T3 Technologies will help develop a sizing and detailed analysis of systems, applications and

jobs. A successful outcome is everyone’s responsibility and therefore, the following should be

available:

Source code for all applications – this means that the current version of the source must

be identified along with all its dependencies. Source code can mean source for every

module, screen map, macro, etc.

Table Layout (schemas) for every database table.

All interfaces and dependencies identified for data and application flow.

Transaction flow sufficient to define, for example CICS transactions, as a CICS system

programmer would perform.

Test cases which will be used to verify application function points and interfaces.

Design and/or User Documentation; the later may be used to verify rudimentary

functionality of the application after it has been replatformed.

Service Level Commitments/Performance Criteria – this is used to validate that the

replatformed environment meets expected performance results.


Replatform Assessment and Support Materials

An assessment prior to a replatform project normally will try to identify required criteria as part of

the project.

To support the assessment and the replatform project it is important to have a copy of the

Backup Plan, Disaster Recovery Plan and other operational criteria which are required

resources to assembling the detailed replatform project plan.

Security is another major component of the replatform project. Knowing the security level

definition and how these definitions are implemented for the IT environment is very important.

Therefore, one should be prepared to provide access groups and other definitions that define

access to applications and data. Please note that ACF2 or RACF will not be used going forward,

and definitions currently in place will be applied to Windows security so that the business assets

are protected at an equal to or greater than extent to that available on the mainframe.

Solution Lifecycle



• Data Migration

• Code Migration

• Process Migration

• Configuration Management

• User Acceptance Testing

• Performance Testing

• Problem Determination

Procedures

• Escalation Procedures• Training

• Operational Planning

• Go Live!

Figure 3 −Migration to Go Live


Replatform Responsibilities

It is always the application owner’s responsibility to be able to validate applications, and it is the

business process owner’s responsibility to verify that all business processes function as part of

the replatform effort. This obligation cannot be delegated and must be assumed through all

phases of a successful replatform effort.

Acceptance Certification (Test)

The application and systems “Acceptance Test” must be executed and verified as accurate by

the application owner. It is of prime importance that as each element of the replatform effort

comes online, dependencies are in place to ensure a seamless transformation from the

mainframe can be facilitated and assured.

Solution Lifecycle

• Monitoring

• Operational Health

• Performance Management

• Capacity Planning

• Production Support• Performance Tuning

• Sustained Engineering

• Disaster Recovery

• Modernization



Figure 4 − Continuing Responsibilities

Performance Test

Establishing a performance baseline is an excellent first task as the applications are brought

back on line. Hopefully, as part of the preparation for replatforming the mainframe application,

there was a prior baseline established upon which the new performance standard can be

compared.

Database performance might need to be tuned to take advantage of new capabilities which may

not have been present in the mainframe database. Also, stored procedures which may have

changed during the replatform process might need to be monitored to enable leveraging new

through-put (performance) opportunities.


A simplified network might also provide opportunities to increase performance. Having a

baseline and measuring against this baseline will permit increasing access and availability of

intranet and extranet processes.


T3 Technologies Liberty 2.0

T3 Technologies’ Liberty 2.0 solution meets the computing needs of businesses. Liberty 2.0 a

scalable solution that delivers the capabilities of the mainframe it replaces, providing superior

performance. No compromises.

Hardware Stack Potential Configurations

T3’s Liberty 2.0 is extremely configurable and can be tailored for specific business

requirements. A range of scalable options is available that maps to mainframe requirements and

delivers compatible power and performance.

Two options are discussed in this primer to illustrate possibilities:

Figure 5 −Hardware stack (<100 MIPS)

Small Workloads

The typical Liberty 2.0 hardware configuration for small workloads of less than 100 MIPS is

based on a “scale-out” architecture which distinguishes it from the “scale-up” mainframe

architecture. The value and design of Liberty 2.0 is that it will fit within existing infrastructure and

use traditional TCP/IP connectivity to users. In most instances, Liberty 2.0 will reuse the same

network connectivity and user access.

The solution is expandable with the server typically virtualized. The server (as illustrated above)

hosts the applications, security domain controller and management tools. The Database Server

is an optional component which is physically isolated from the application server; thus ensuring

recoverability and scalability which is independent of application servers. A bonus is that the

separation of servers can help manage the software licensing costs; reducing costs.


Looking further at the T3 solution, failover clustering is optional but is recommended for high

availability applications. The storage system is typically a SAN or a similar high performance,

high capacity RAID type disk. It provides for database storage, file systems and rotational

backups. Optional tape can be configured for offsite backups.

Again, exact configurations will depend on specific application requirements which will be

determined as part of the T3 Technologies assessment.

Larger Workloads

T3’s “scale-out” architecture permits growth and expansion to meet the changing needs of the

business. One could start with the previous configuration and expand as needed, or, if larger

more robust workloads are present, it may be wise to opt for a more sophisticated heavy duty

solution. T3 Technologies can provide input and assist in deciding on the appropriate

alternative.

Figure 6 −Hardware stack (100 MIPS >)

Remembering the scale-out capability, servers can be configured into multiple servers delivering

disaster recovery, failover and redundancy. User and workload demands will factor into the

design of the system configuration for the mainframe system replatform solution.

T3 Technologies recommends that Database Servers be physically isolated from servers

running applications. The architecture separates important components of the replatformed


system and ensures recoverability and scalability. Failover clustering is optional but for high

availability systems it is highly recommended.

As in the smaller volume system configuration, the Storage System is typically SAN or similar

high performance, high capacity, RAID type disk. The system provides for database storage, file

systems and rotational backups. Optional tape system is required for offsite backups.

Security Domain Controllers isolate Active Directory security to a single forest (domain

controller) for ease of management.

Management and monitoring is provided through the Systems Center Operations Manager and

performance monitoring. Although job scheduling might be ideal on its own server, to reduce

costs the job scheduler could reside on this server.

Print Management is normally configured onto an optional server so that printer services are

isolated from application servers. The configuration is recommended when online report

distribution and remote printing is not possible.

The exact configuration will depend on the application requirements, which will be determined

during the assessment phase.


Replatform Project - Getting Started

Scheduling a T3 Technologies Assessment is an important first step, and a T3 Sales Executives

can help with this important first step.

Reviewing the Assessment

T3 Technologies will provide the results of the assessment and review the results. Normally the

cost of a replatform event will be returned in savings from decommissioning the mainframe. T3

is available to discuss options and the most cost effective and risk adverse course of action.

Making the Decision and Getting Started

Having the facts and knowing the applications is the first step is making the decision and

scheduling the replatform project. This step requires that IT teams are aligned, preparation work

is underway and resources are available. The business is a part of the effort it will own the

results. T3 Technologies is the partner to build a custom replatform solution.

Validating the Results

During the preparation step an “Acceptance Test” was created. As replatformed applications are

returned, it is the business’s responsibility to test the results and immediately report any

inconsistencies. These inconsistencies will be addressed and resolved and revalidated.

Before “Go Live” all systems are tested, the IT team is educated by T3 Technologies, backup

and disaster recovery plans are verified, operations and run books are updated and all involved

parties give a “thumbs up”.

Go Live!

Documents

Replatform Primer