replatform primer 050812 - t3t.comt3t.com/docs/replatform_primer.pdf · table 1 −emulation and...

©Copyright T3 Technologies 2011 w All Rights Reserved

Replatform Primer Getting the Facts Straight

Replatform Primer ©Copyright T3 Technologies 2011 w 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) .......................................................................................................... 5 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 SERVER ..................................................................................................... 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 w 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

Same

Functions

Matching

Layout Layout

Functions mapped

to new paradigm

Converted

Syntax

Same

Syntax

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 Server, 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 developed technology over the years and has repeatable proven processes that can assure clients that replatformed batch continues to deliver and meet expectations of our clients.

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 interaction between transaction

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 Liberty Server

CICS Liberty Server Batch

COBOL, PLI

SORT, IDCAMSE

VSTS, DR, PerfMon, SCOM

3270, ASP.NET, WPF

SQL Server, VSAM, SAMOMServer Batc

Active Directory

Liberty Server


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

Discovery Envisioning & 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 Server

T3 Technologies’ Liberty Server solution meets the computing needs of businesses. Liberty Server a scalable solution that delivers the capabilities of the mainframe it replaces, providing superior performance. No compromises.

Hardware Stack Potential Configurations T3’s Liberty Server 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 Server 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 Server is that it will fit within existing infrastructure and use traditional TCP/IP connectivity to users. In most instances, Liberty Server 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!

replatform primer 050812 - t3t.comt3t.com/docs/replatform_primer.pdf · table 1 −emulation and...

Documents