TPFDF - Part I: From the Vendor's Perspective
by David Young

Introduction
TPF Database Facility (TPFDF) is the database product from IBM for the TPF and ALCS environments. It is the result of a development partnership between IBM's International Airline Support Centre in the UK and Swissair. The UK is already the home of some successful IBM products - including ALCS and CICS - and TPFDF aims to continue this success story.

Rather than provide just an IBM or Swissair view of the product, I thought it would be more interesting to view the product from three different perspectives - a product developer, a database consultant, and a database administrator. (These articles will span several issues of ACP/TPF Today.)

David Young, team leader on the IBM development project, has written about TPFDF's release 1.2 content (shipped April '91) and also paints a picture of the product's future direction.

Peter Fischer, a database consultant in the TPF/ALCS environment, gives his views on the directions customers want their high volume transaction processing databases to move in the future. Peter originally worked for Swissair on the development of TPFDF's predecessor product - TPFDB. He provides TPFDF services ranging from an electronic bulletin board to database design and tuning customer generated designs.

Waseem Majeed, a database designer/administrator on AMR's CONFIRM project, gives a user's perspective of what TPFDF can do for you today. Waseem is leading the design and implementation of a database which has over 500 different logical record types and has been using the IBM product for approximately one year. He also has a lot of experience with TPFDF at American Airlines and so is a good judge of what has changed.

If you have any questions resulting from the articles, then I can always be contacted via your local IBM account team.

Roger Robinson
Application Enabling Development Manager
International Airline Support Centre
IBM Brentford, UK

Although I work for IBM, the ideas, comments and particularly any errors contained in this article are my own.

Regular readers of ACP/TPF Today will have seen numerous references to a product called TPFDF, but on my travels around the TPF/ALCS community, I find that many people have no real knowledge of what it is. So - let me start from the basics .....

WHAT IS IT?

1. TPFDF is a database manager designed to provide:

• Significant increases in application programmer productivity
• Improved application program performance
• Improved database integrity

2. TPFDF provides a set of high level macros and C/370 functions for database reads, writes, searches, etc. For example, to ad a alogical record to a TPFDF database is very simple:

In assembler with TPFDF:

DBADD REF=zzzzzz,NEWLREC=EBW000

In C/370 with TPFDF:

dfadd(zzzzzz,DFADD_NEWLREC,0,&lrec);

With traditional processing

As can be clearly seen from the diagram, conventional programming is a little more involved.

3. TPFDF also provides a comprehensive set of maintenance tools which include:

• File initialization
• File display and modification
• Performance measurement
• User authorization

4. And specifically for the TPF environment are:

• Capture and restore utilities
• An extension to TPF Recoup which removes the need to code Recoup descriptors for TPFDF files

WHERE ARE WE NOW?
IBM has just shipped TPFDF Release 1.2. The main enhancements are:

C/370 Language Support
This feature provides the application programmer with the necessary functions, macros and headers to code TPFDF programs in "C". TPFDF, coupled with the C/370 feature of TPF or the SAA "C" support of ALCS V2, provides a true high level language for the first time in the TPF/ALCS environment. Early feedback on productivity is extremely encouraging; other advantages include easier code maintenance and improved portability of applications.

Documentation
The TPFDF library now comprises ten books. The Release 1.0 manuals have been updated and the library has been extended to include six new manuals.

• Structured Programming Macros
• C/370 Application Programming Guide
• C/370 Implementation Manual
• C/370 Macro Reference Summary
• Command Macro Reference Summary
• Database Design Guide (available Sept.'91)

Easier Installation
In response to customer feedback, significant improvements have been made in the installation process. Some recent pleasing comments on the installation of TPFDF include:

• "A non-event" (large TPF customer)
• "We did it over lunch" (ALCS customer using SMP/E)

Extensions to the TPFDF application programming interface
We've added several new parameters, even a new macro DBSPA, but there isn't really time or space to go into a lot of detail. So briefly, the following list summarizes the extensions:

• Most parameters now support A/ format
• DBDEL now supports EXCLUDE=
• KEYLIST= was added to DBSRT, DBMRG, DBRED, DBADD, and DBDEL
• PATH= was added to DBSRT, DBTLG, DBCPY, DBTLD
• DBFRL now supports REF=ALL
• STACKREF= parameter
• PARTITN=ALL, INTERLV=ALL
• and so on ...

Education
Five new TPFDF classes are now available:

1. Application Programmer Workshop (Assembler)
2. Application Programmer Workshop (C/370)
3. Application Programmer Workshop (ASM to C)
4. Database Administration and Design Workshop
5. Experienced Users Workshop

If anyone can think of any other educational requirements, then please let us know.

AND TOMORROW?
Is there life after TPFDF Release 1.2? The Multiple Database Facility (MDBF) feature of TPF still has to be addressed, and as TPF and ALCS continue to provide more functionality, TPFDF will be enhanced accordingly. ALCS V2 has announced the ability to issue dynamic SQL statements from an ALCS application to a DB2 database, which raises numerous possibilities. TPFDF removes from the application programmer the need for detailed knowledge of the physical layout of the data - why should the programmer even care where the data is stored? Be it an ALCS database or a DB2 database, its location isn't important. Why shouldn't TPF/ALCS finally fit into the corporate data warehouse ideal?

Additionally, the combination of increased programmer productivity and the use of "data sharing" across all platforms will result in more applications of increasing complexity. Sounds far fetched, maybe, but one day when true database engines are no longer the sole preserve of specialist publications, PHD theses and development laboratories, performance concerns will take second place. In the TPF/ALCS arena we are already beginning to see companies taking a different perspective. It's very competitive out there in the CRS/Airline world, and the provision of more function and better yield management tools coupled with the ability to react rapidly to the marketplace are becoming as important as system performance.

As these databases evolve, the complexity of database administration will increase considerably, and the need to centralize the function around a "repository" will become increasingly important. With the increased development and use of application enabling tools - "C", TPFDF, CASE and code generators - the role of the database administrator will be crucial. Artificial intelligence could be used, for example, to analyze data collection and TPFDF Recoup statistics and produce reports on database optimization. Database design, and the relevant coding of DSECTs, "C" headers and DBDEFs (database definitions) could easily be automated around a PS/2 workstation running a Graphical Users Interface (GUI) program, again linked to an expert system so that designs would automatically benefit from the latest optimization techniques.

And this is where TPFDF should fit in, continuing to offer more and more flexibility for companies to react to an ever-changing market. Delivering the promise lies not in extensions to the API (although it will have to be expanded in the short term) but in delivering tools that will allow companies and individuals to concentrate on providing solutions in an increasingly competitive world.

Fantasy perhaps but then, five years ago how many of you would have believed that anyone would develop a complete reservations system from scratch in a TPF environment using "C" and a database manager (TPFDF 1.2), and having designed the system top-down using CASE tools? For those who don't know, it's called CONFIRM and is presently being developed in Dallas Texas.