TPFDF - Part III: The User's Perspective
by Waseem Majeed

This is the third article in the series on TPFDF. The focus in this issue will be on one user's business perspective of TPFDF. The statements made here should be taken in the context of the TPF industry. The opinions expressed do not represent the views of any organization or person other than the writer.

You are all too familiar with the winds of change that have been sweeping across Eastern Europe and the Soviet Union. Barriers are breaking down and stereotypes are being recast. Boundaries are being redrawn and the rules are being rewritten. In short, history is in the making! Much less publicized, but no less dramatic, changes have been taking place in the world of TPF. A quiet revolution is underway that will transform the way we design, develop and operate TPF systems.

These changes are taking place against the backdrop of developments along two broad fronts. On the business front, the undercurrents from three separate and independent business activities are converging in a North Dallas suburb. The resulting tidal wave is reshaping the TPF coastline. On the technology front, products and methods tied to these business activities are being thrown into the same cauldron producing a potent brew. If this tonic is true, it will invigorate TPF development and give it a much needed boost.

We will explore TPFDF in the context of this business environment and related technological changes. Our journey will take us to three locations. We will look at the business activity at each locale and examine the technologies at work there. Along the way, we hope to gain some insight on the key player at each site. In a future issue we will view TPFDF from a technical perspective and examine its role in database and application development.

Where In The World Is Brentford?
Our first stop is Brentford, in London, U.K. The first business factor in our equation was the International Airlines Support Center's decision to work with Swissair on TPF/DB. IASC gained the marketing and sales rights to the product, strengthened the development team and converted TPF/DB into an IBM program product. They renamed it TPFDF, but this wasn't just a paint job. In short order, IASC restructured parts of the API and internal code and rewrote the documentation from the ground up. They simplified and standardized the interfaces to TPF. They streamlined the packaging and installation procedures. Then, they added support for TPF3.1 functionality that the Swissair product did not have, for example C/370 and loosely coupled systems. The result is a product that, while it clearly shows its roots, is a significant improvement over TPF/DB. IBM's worldwide marketing presence and network of local branch offices, staffed with experienced Systems Engineers, support TPFDF. From their hub in Brentford, with links to Zurich and Danbury, they can resolve problems quickly. Customer queries get prompt attention and timely responses. Perhaps, the most significant difference is in the area of documentation. IASC discarded the Swinglish manuals and designed a completely new set. Then, they hired a staff of technical writers to develop the documentation. The end product is a comprehensive set of manuals. They are well organized, extensive in scope, slick in style, thorough in coverage and easy to comprehend. In addition, IBM has developed a broad education curriculum to meet customer needs.

And that was just the beginning! IBM felt that they had to achieve a standard baseline before making major enhancements and developing new tools and utilities. The product had to meet user requirements and expectations. It needed to follow IBM's internal guidelines for coding and interfaces and be subject to strict quality control standards and procedures. TPFDF Release 1.2 is that baseline and IASC has put its own unmistakable stamp on it. They are now in the midst of an aggressive development plan. It will include MDBF support and the propagation of TPFDF data to DB2. The person responsible for managing this evolution and the development of TPFDF is Roger Robinson, the manager of Application Enabling Development at the IASC.

Who Found Roger Rogers?
Our next stop on the tour is Danbury a place near and dear to every TPF'er. Because so few installations use it, TPF's development has historically taken a back seat to its more important siblings. Though the number of installations is small, TPF is very critical to the success of the enterprises that use it. For those that need it there are few alternatives. IBM knew this. Sensing the changes in the world business climate and the demand for TPF services, they decided to redefine TPF as a strategic product. To put this new thinking into practice, IBM reorganized its TPF development and marketing organizations. Thus, began a bold multi-year plan to enhance and upgrade the TPF operating environment. The extensions to support C/370 are the first technical byproduct of this strategy.

Many changes, some radical, are in the works. IBM is overhauling and upgrading TPF in dramatic ways. The lean mean fighting machine is being souped up and turbo-charged. The Danbury design team is extending the 16 Meg wheelbase to provide more leg room. They are removing the annoying hump in the middle. They will improve safety with extra padding and crash bars. New luxury features will provide added convenience. The next generation TPF machine will have the decided look of an MVS sedan. MVS like? Yes, but with the horse-power and performance to beat the snappy old V8, the feel will definitely be TPF. The person in the driver's seat is Roger Rogers, manager of the TPF design group at Danbury.

Like Roger Robinson, Roger Rogers is among the new generation of younger managers who have energized IBM's design, development and marketing of TPF products. Both have similar backgrounds and management styles. With strong business skills and a customer orientation, these Young Turks have brought the market-driven approach to their respective organizations and product lines. They have worked to forge mutually beneficial partnerships with their customers. They have begun wide-ranging development programs to enhance and improve their software offerings. They have shown an eagerness for change and a willingness to listen. They are quite prepared to pursue joint development where it makes business sense. They have displayed a flair for presentations with a candor to match. Roger and Roger have brought the winds of change to IBM's TPF bargain basement and a breath of fresh air to the TPF user community. Problems do exist and much remains to be done. However, they have the winner's attitude and can-do spirit. It will take such qualities to keep TPF a viable niche product in the nineties and beyond.

The Case of the Max Factor
Our final stop takes us to Carrollton, a sprawling suburb of North Dallas. If you have been following the trade and industry headlines, you will know that this is the home of CONFIRM RS. The CONFIRM Reservation System will provide comprehensive information services to the hotel and rental car industries. It is being developed by AMR Information Services for INTRICO. With a $125 million budget, INTRICO is the partnership formed by Hilton, Budget, Marriott and AMR Information Services. The partners expect to cut over to the new system by the end of 1992.

CONFIRM RS was born three years ago when major companies in the information, car rental and hospitality industries formed the partnership. The goal was to reduce the cost and risk of developing a major new system. The race was on to build the next generation of information and reservation systems. Almost from the word go, several competing groups entered the arena with their own plans. Potential customers watched from the sidelines and weighed their options. With one eye on the competition and the other on the clock, senior management took a calculated risk in their approach to the development of CONFIRM RS. They decided to throw out the traditional approach to TPF development that is tedious, error-prone and time-consuming. It results in systems that are expensive to build, difficult to maintain and not flexible enough to respond quickly to changes.

Starting with a clean slate, they asked the question: How should a system be developed in today's environment to serve tomorrow's needs. They looked beyond TPF to the computing industry for answers. CASE technology, TPFDF and C/370 figured prominently in the equation. They bought what they had to, borrowed what they could, adapted what they needed to and even developed their own tools where none existed. In developing the solutions, they took a big step forward and catapulted TPF development from the seventies into the nineties. The central figure in this drama is none other

than Max Hopper, the Senior Vice President at AMR and Vice Chairman of AMR Information Services. A person who needs no introduction, Max played a key role in defining the vision and reality of what CONFIRM RS will be.

This is not to imply that Roger and Roger or Max are the only factors in these dramatic events. Change has been underway in the TPF industry for quite some time. Innovations and developments at many TPF installations including Swissair and American Airlines have paved the way. Many individuals and other vendors have made important contributions and provided pieces of the future that CONFIRM RS represents. However, these people, with their business insight and understanding of technology, turned out to be the catalysts. They provided the fuel to ignite the incipient sparks of change into a roaring bonfire.

On the technological front, three developments connected to the these business activities, have come to fruition. TPFDF has emerged as an industry standard application interface and is maturing as a fully functional database management tool for TPF. The feasibility and viability of using the "C" language for TPF development is being established. Taken alone, the two are very powerful development tools. Put the two together and you have maximum synergy. Using TPFDF with C provides a level of productivity that approaches that in other mainframe environments.

Many die-hard, weened on assembler, TPF veterans who could not be charmed by either alone, have succumbed to the allure of the dynamic duo. Throw CASE technology into this mix and you have the framework for a comprehensive application design and development tool set. With this case hardened and double edged Excalibur, TPF can prosper and survive in the nineties.

To DB or Not To DB?
"That is the question!" as Hamlet might have remarked, had he been a prince of programmers. "Whether 'tis better in the application to chase the blocks and pointers of outrageous structures, or to take up TPFDF against a sea of entities and, by modeling, normalize them? To analyze, to design, and with TPFDF end the dumps and thousand broken chains that applications are heir to. It is a benefit devoutly to be wished (and well worth paying for)! To code and test under dreary conditions? The fear of the unknown baffles the will and makes us bear the ills we have rather than rely on something we know not of! So, enterprises, of great value and importance, make the wrong decision and lose the game of action."

The CONFIRM RS database consists of massive amounts of many different types of records. The data have complex relationships, require multiple indexes and cross- eferences, and must support flexible displays and lists. The system must provide extensive history, notes and audit trail information. To support all these requirements, while at the same time providing flexibility, ease of maintenance, and optimum access to the data, is not easy. It would have been near impossible using TPF coding. From a functional viewpoint, TPFDF has proved convincingly that the database approach, principles and practices are as valid for TPF. It allows model driven development and lends itself to automation. In a future issue we will explore these issues and look at database design and TPFDF.

Can You 'C' The Future?
C is often typecast as a mid_level language; it supports machine_level interfaces & operations while providing high_level language features. It is available for the full array of environments from the PC -> mainframes. Developed for systems programming, C is very much a problem solving tool. It is != a teaching aid. Logical && consistent, it is char acterised by a limited instruction set, data typing and block structure. Function libraries {which give C its power and portability} provide I/O, string, math and utility routines. C programs tend to be more readable, /* one can imbed comments anywhere in the text */ writable and maintainable. Testing is a big problem without the use of a source-level debugger like CMSTPF. Without it one can not reap all the productivity benefits of C.

There is a charged atmosphere around the issue of using high level languages for TPF development. Experience shows the standard arguments are null and void. If we cut through the static and examine the variables in a wider scope, the case for C is automatic. It can increment productivity and decrement maintenance costs. A few pointers are all you need to get started. The > one uses C the < one doubts that it makes perfect sense to switch to C. It would take too much space to enumerate all the benefits of C. To make a long story short, TPF and C complement each other very well. While the outlook is very encouraging for these business and technological developments, there are also hidden dangers that lurk just beyond the horizon. The danger is in trying too much too soon. Any venture into uncharted territory carries with it many risks. Each new turn confronts one with unexpected pitfalls and each summit climbed reveals a changed landscape. One can slip, make mistakes and recover. Which one might prove fatal, one can never know until it is too late. The explorer ventures on, resolute in his will and firm in his conviction that the goal is worthwhile and attainable. As Queen Elizabeth I said to Sir Walter Raleigh: "If thou fearst the fall then rise not at all".

On the business side, user expectations may be excessive! One's ability to meet those expectations in a timely and cost effective manner may be misjudged. Small requirements can sometimes result in huge drains on system resources with attendant costs. User specifications and requirements need to be in line with the system capabilities. Where these are out of balance they may have to be scaled down, redefined or withdrawn. On the technological side some questions remain unanswered. Can a TPF system sustain and support the huge demands in storage and processing costs that these new technologies entail?

Getting the technology is easy. The buyer prepares the contract and Legal clears it. Accounting cuts the check and the vendor ships the product. Assimilating it, managing it, and using it effectively is not so easy! Can businesses adjust to the new organizations, methods, culture and skill sets that are required? There are often hidden costs and lead times associated with tooling up for new technology. Underestimating these factors can be disastrous. Those who choose to sit and sulk, pause and ponder, watch and weigh will be left in the wake. In technology, the race is to the swift.

Back in the USSR, the final chapter has not yet been written. So, the script for this high drama has not yet been played out. Someday, if a history of this period is written, it might be entitled 'A Tale of three Cities, two Rogers and one Max'. It might begin 'It was the best of times and it was the worst of times. It was time to confirm the coming of the brave new world of TPF'. Whatever the outcome, one change seems certain. These events are drawing TPF into the mainstream of computing. No longer will TPF exist as a world unto itself, hidden in the shadows, bound by its own ancient code of programming and clinging to its traditional development culture. The curtain has risen and the light is shining through. CONFIRM RS has blazed the trail for others to follow.