Survival guide toPACBASE ™ end-of-life

Business white paper

Pacbase™: How to survive the end of support ?Pacbase™ is a CASE tool used to develop core applications for about 40 years. It was initially developed by a French IT service company, CGI, to avoid the need to develop in COBOL and to allow programmers to benefit of several features such as the data dictionary, aimed at becoming the central data reference for the company’s IS.

It quickly became popular with major accounts in France and was also quite successful abroad, especially but not only in French speaking countries.

IBM acquired CGI in the early 90’s and Pacbase™ was integrated in their Visual Age product range.

After the turmoil of the 90’s, most of the companies still using Pacbase™ pertain to the Finance sector, but it is estimated that there are about 1.5 Millions Pacbase™ programs in production, most of them consisting of critical applications. Although the Pacbase™-savvy populations are in their fifties, the language is still intensively used.

But IBM, after a suspended attempt in 2005, has announced the final retirement of Pacbase™ for the end of 2015, leaving these major companies with an urgent need to find an alternate solution, for instance following the evolution path proposed by IBM and a conversion and move into the Rational tool set.

What Pacbase™ providesThrough the years, Pacbase™ has become an integrated developing environment able to generate COBOL compatible with many operating systems (e.g. IBM Z/OS, Bull GCOS, Unix…).

Beyond an integrated environment that allows collaboration, administration… the key feature of Pacbase™ for most of its users is its referential or data dictionary: the central hierarchical repository of all the data pertaining to design, development and administration. It includes for instance data structures, screen maps, documentation, cross-reference…

Since the dictionary manages the objects and their relationships, it traces the link from analysis to development (and vice-versa) and provides an impact analysis capability.

This ensures a strong consistency of the development cycle and of the application structure, where for instance redundancy is prevented and standards are enforced through the use of macro-structures.

Pacbase™ generates the compilable code from this reference, thus emphasizing the design aspects and minimizing the technological dimension of application development.

What alternatives can be sought?These automatically generated COBOL programs are nevertheless hardly workable by a programmer, which is not an issue in a full Pacbase™ programming environment – since no COBOL editing is required – but prevents any efficient maintenance of the COBOL programs. This is a major issue for those companies who need to continue using and maintaining their formerly Pacbase™ applications: not only have they lost the spine of their applications (the dictionary), but they cripple their maintenance operations.

This is not acceptable in many cases, especially in the finance market, where, for instance, changing laws require the capability to quickly implement evolutions.

Thus Pacbase™ users are now faced with little more than 3 years to implement an alternate solution for each of their applications.

ReplaceAs with any ageing application, the replacement must be considered. This would indeed allow the company to rely on a packaged application, and thus decrease its exposure to technology changes and rigidity to evolutions. Nevertheless, moving to a packaged application always involves business change to converge towards the package software standard features as much as possible. This represents an effort that cannot be neglected, and it can be very extensive: it involves whole chunks of the company business, requires a project spanning across several months and result in temporary losses in productivity. The bright side is that the company business will be using a standard tool at a “standard” price on a standard platform, thus in a position to minimize its costs and quite seamlessly leverage on oncoming innovations.

RedoFor those companies who cannot adopt a packaged application, it is yet possible to develop a replacement in a state-of-the-art architecture. This indeed would allow keeping all the specific features and secure the technology aspects, whilst reducing the cost of operation. Unfortunately, candidate applications are most often quite old and represent a significant development investment over the years. Thus the redesign may have to start from scratch (e.g. business requirement workshops) and the amount of development might be important without preventing a significant business change. Even with very mature project governance, the time, cost and risk aspects may be unbearable.

TransformTransforming the application from generated COBOL to native COBOL can be the only possible approach: it avoids functional impact, leverages on existing skills (most of the Pacbase™ developers belong to the COBOL culture), dramatically decrease technical impacts (e.g. interfaces with other systems, architecture…). Meanwhile, as it avoids some cost elements, it does not provide some savings such as can be brought by the preceding options (ex: moving out of the mainframe). But this approach secures an application as it works for its users in its current environment, handled by its current team. This alleviates most of the risks and gives the time to initiate the move to a better optimized delivery model, or a true Application Modernization strategy, safely progressing towards one of the previous options.

To be complete a code transformation must also transform Pacbase™ goodies. The dictionary, for instance, is a, if not the, key tool in Pacbase™. This element that ensures the consistency of data and programs must be provided after the migration. I.e. a dictionary available from COBOL must be generated from the Pacbase™ source.

Another example is the documentation which must be extracted from Pacbase™ to be transformed depending on the size, either in documents or comments inserted at the right place in the programs.

DecisionMany Pacbase™ applications have been in-house developed due to specific requirements and, over the years, have included more and more of these specifics. They are either highly tailored or critical to the company… or both, any impact on features, availability, quality, is a direct hit to the company’s business. Such applications are also immersed into the company architecture and interface with a series of other applications. Any technology change on one end may well induce changes on the other. Last but not least, the team maintaining such applications is usually highly skilled with a good functional knowledge, showing efficiency and reliability.

These points conflict when a “transform, re-do or buy” decision is at stake. Consequently, the choice is linked to the strategy of the company, where the revolution (re-do or buy) involves business reengineering and significant technical aspects, whilst the evolution (transform) bears less benefits but also much less impacts.

And last but not least, the whole transformation plan need be completed by the end of 2015.

The above considerations must be consistently applied to the (Pacbase™ and else) application portfolio, integrating all the considerations from business to technology and complexity. Then, there might not be one option that fits all the company’s Pacbase™ applications.

Key success factors for the transformationNow that the transformation cannot be avoided, the scene remains to be set. Its main components are: business impact, risk, speed, quality, flexibility and budget.

Let’s focus on a company wanting to minimize the business impact: the present applications address the business needs and cover a series of mandatory specifics. Consequently, the “Buy” option is disregarded, and at the same time, there will not be any business impact in term of functionalities.

But yet, the company’s business can still be impacted by other factors such as application adaptability and reliability, which must be secured by the code transformation approach. This is where we come back to risk, speed, quality and flexibility … within a controlled economic rationale.

RiskIn IT, the two main risk factors are discovery and human operations. Obviously, implementing a well proven automated process will always be safer than manually introducing a new technology, which pertains to application development. And indirect risks such as ageing technology cannot balance the former in the transformation of this type of application.

To minimize risks, then, the transformation process must rely as much as possible on a set of tools that will automate the biggest part of the tasks.

SpeedSpeed addresses two challenges: the transformation must be completed by the end of 2015 and an application must not remain frozen too long so that necessary evolutions (e.g. regulatory) cannot be implemented on time.

The transformation project must be tightly managed and its different phases kept in line with the company’s schedule. The definition of sets will reduce system freeze and maintenance reports.

Quality and testsNo functional regression can be allowed in such a transformation, which must embed sufficient testing especially where manual operations have taken place. But as testing reduces the risk, it mustn’t impact speed and here again automation must be sought. The best option being to design test scenarios, run them on the current application in a shell that allows capturing the outgoing flows, then automatically replay the scenarios on the transformed application and compare the flows. This will allow the quick identification – and then correction – of any discrepancy.

Another dimension of quality is the intrinsic quality of the transformed code: beyond performing iso-functionally, it must allow the proper level of maintenance operations and thus must perform at iso-productivity.

FlexibilityAs already said, one size does not fit all, and the level of transformation must adapt to the company’s targets for each application, from the highly stable or short life-spanned applications, to the intensively evolving business critical application.

The approach must provide different levels of transformation, obviously from light-fully automated to high-semi automated, with the possibility to upgrade an application between levels if the need arises.

BudgetThe transformation of thousands of programs cannot be transparent, but all of the above contribute in minimizing the costs in conjunction with meeting the business objectives and address Pacbase™ end of life.

The operation can nevertheless lead to savings due to potential optimization of the future mode of operation as we’ll see hereunder.

And afterOnce the transformed application is developed, the simplest – and safest – path lies with the code-transformation option, where automation and regression testing, as well as continuing architecture, warrant a smooth implementation, and a smooth transition to maintenance operations.

As we’ve seen the complexity of maintenance operations is not the same for all applications, and the transformation level has prepared the code consequently. But in any case, maintenance productivity and reactivity must be secured, and an equivalent to the Pacbase™ dictionary must be provided.

DictionaryThe dictionary enables the development team to continue leveraging a single data reference, impact analysis and pre-coded COPYs.

It can also be used in further developments to encompass the new elements created with evolutions.

Maintenance and delivery modelAs seen, as soon as some manual edits of the code are required, regression testing must be performed. Once this stage is automated via an ad-hoc tool, it creates (since it rarely already exists) a set of test scenarios with a density proportional to the criticality of the code – since non critical or stable code will not necessitate regression testing. These scenarios become an asset that will be re-used whenever needed along maintenance operations.

The other indirect benefit is that – again depending on criticality, thus only when justified – the application has been technically re-learned. This paves the path to tuning the delivery model towards a more optimized configuration.

We at HP HP Enterprise Services leverage on their skills, methodologies and offers to assist their clients in addressing all the challenges of the application lifecycle.

In the case of Pacbase™, we can provide our Application Transformation services to define and implement the company’s transformation roadmap, but more specifically, we have developed an offer, which allows expediting and de-risking at a low cost the code transformation. Our Program Transformation Factory SM meets all the hurdles and enables the client to safely move out of Pacbase™ without losing productivity or experiencing business impacts.

Our approach consists in a tailored methodology favoring automation and based on two sets of tools: a code transformer to generate a high added value on the resulting source code (including a Pacbase™-like dictionary), and a regression testing utility to ensure the iso-functionality of the migration, thus the absence of business impact.

An initial discovery phase scopes out the project, assess the portfolio to be migrated and sets the targets and processing levels required. As part of this study, HP can assess the business value of the applications to refine the targeted migration level, adding the possibility to ignore and decommission an application, with the necessary associated operations (e.g. data archival), or to replace it with a packaged software as seen above. This allows synchronizing the migration – a technical operation – with the company’s business strategy.

The discovery phase will thus define the level of transformation to be undertaken for each candidate application:

Level 1 (fully automated) enhances the source code at no impact to the executable:

• Extracts from Pacbase™ dictionary to generate a new dictionary that can be used from COBOL

• Segment descriptions are replaced by copy clauses

• Insertion of comments from Pacbase™ dictionary

• Common processes (i.e. Pacbase™ Macro Structures) replaced by copy codes

• File management instructions replaced by copy codes

• Renaming of Pacbase™-generated variables

Since this level does not impact the executable, it is very quick and inexpensive and requires no testing. But the sources, although independent from Pacbase™ and associated with a dictionary, do not allow a productive maintenance. Thus this level should be reserved to very stable applications or applications with a short life-span.

Level 3 (mostly automated) adds to level 1 operations a full restructuring of the source code with an impact on executable. These operations ease further code modifications and include:

• ‘VALUE’ copy initialization are replaced by ‘INITIALIZE’

• ‘NEXT SENTENCE ELSE GO TO’ structures are replaced by inverting conditions

• Copy codes are moved at the end of the programs

When necessary, a manual operation can be performed to further enhance the structure of the transformed code. The outcome of this level provides a pattern programing-enabled application. In consequence, the resulting code guarantees maintenance productivity and quality.

At least 90 % of the programs are migrated without human interaction, but this extensive modification implies a full regression testing to ensure a seamless migration.

Level 2 operations are limited to what can be automatically performed at level 3. This full automation leads to perform sample-based only regression testing.

The resulting source code is not fully industrialized, but provides good maintainability.

The high automation allowed by the use of transforming and testing tools speeds up (the freeze period is dramatically shortened), de-costs and de-risks the end-to-end migration. Again, two cornerstones of the operation are:

• The maintenance assistance tools such as the Pacbase™-like dictionary, centralizing the data physical definition (format, tables, communication zones, file structure…), including a cross-reference with the programs allowing throughout impact analysis, data description; and access COPYs, code models and generators… the dictionary can also be fed by native COBOL programs, e.g. in the case of applications including native Cobol along Pacbase™, but also in post-migration developments.

• The quality assurance provided by the right level of automated regression testing guarantying a real iso-functionality operation, thus securing end-user satisfaction.

This leveled approach enables the company to define its migration pace and to tune the level of effort in relation with the criticality of each application.

HP can then propose further services such as Application Modernization, Application Management and Application Testing. Both of the latter leverage the knowledge and the testing scenarios developed along the transformation, which positions HP in a unique position to commit on high quality and productivity levels.

In conclusion, HP is the only service provider able to expedite, de-risk and de-cost the consequences of Pacbase™ end of life. And then HP can continue working with its client, ensuring the successful life of the application, in a service-oriented way, i.e. without freezing their IT strategy on a single provider’s solution.

Get connectedhp.com/go/getconnected

Get the insider view on tech trends, support alerts, and HP solutions.

© Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice. The only warranties for HP products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. HP shall not be liable for technical or editorial errors or omissions contained herein.

Created October 2012