The TPF Applications Programmer of the Future
by Jim Tison

Given that the face of TPF is changing, programmers and managers alike often ask: "What should the TPF programmer of the future look like? What kinds of skills will be needed to program TPF in the 21st century?" This article is an attempt to project recent TPF system model changes onto the programmer skill set. Current TPF professionals should be examining this set of skills with an eye opened towards education they might need to advance their careers.

How is the current TPF system model changing? TPF has been evolving throughout its 30-year lifetime, with most of the visible changes appearing in the last 3 years. There are three major categories of change: applications programming interfaces (API), compiled language support, and load module support.

For the last decade, an association of operating system and hardware manufacturers have been examining the common services that should exist in a portable operating system, and specifying how those services should be obtained. These standards are collectively known as the Portable Operating System Interface for Computer Environments, or POSIX; and were adopted several years ago as the standard API to many operating systems -- OS/390 Open Edition, AIX, and many flavors of Unix among them. There are several excellent references describing the POSIX API, an example of which is POSIX Programmer’s Guide., available in your favorite mass-market bookstore. The subtitle of this book, "Writing Portable Unix Programs", is a good hint as to what the TPF programmer of the future will look like.

The POSIX API itself is no earth-shaking technological advance – C programmers are already familiar with most of it, which they know as the standard C runtime library. In addition to these, there are also some POSIX functions that obtain system services – starting with file I/O and extending into multiprocessing and interprocess communications – TPF is enabled for some of these as well, with more work ongoing in this arena right now.

TPF is also capable of supporting full versions of C and C++ -- these are good choices of fully portable high-level languages (HLL) that provide versatility and commonality.

The ability to generate indefinite amounts of object code quickly via HLLs meant that the 4Kb program segment size limit was a major impediment, so the concept of load modules (DLMs/DLLs) of theoretically unlimited size was implemented. These can consist of multiple object modules, tied together by a method that the rest of the industry understands: linkage editing.

If we step back and look at the past few years of evolution, we’ll see that a common programming model now exists in TPF.

Is TPF becoming Unix? Absolutely not -- Unix and TPF serve two completely different purposes. Unix doesn’t handle high volume OLTP (online transaction processing) well and TPF doesn’t perform certain general-purpose operating system tasks well. TPF’s OLTP mission will always make it unique to some degree – we will always be able to think of the POSIX functions as a subset of the total TPF API.

Why is the current TPF system model changing? The answer is that we, as TPF users and professionals, will want to reap the benefits of a common programming model.

The first of these benefits is that we can port more code from other platforms with greater ease: ports of established software like the Apache Web Server and the X/Open Transaction Manager API onto TPF have been performed based on these model changes, and other port projects are taking place as I write this. Using the common programming model allows us to implement more function into TPF without the intimidating lead time and expense involved in reinventing the wheel.

The second benefit is that this common programming model is a more productive development environment than that employed by the typical TPF installation. Even the most ardent BAL fans among us will concede that coding in assembly language takes a lot of time – there are many minute BAL-unique details that the programmer must pay attention to. Compiled languages remove a significant part of the mechanical details from the programming task, allowing the programmer to focus more on the business problem at hand.

The next benefit is in skills transfer. Yes, non-TPF skill sets now become more transferable to TPF, but TPF implementation skills also become transferable to the enterprise at large. TPF professionals are skilled in what the rest of the industry calls "server-side" systems, and possess a very cherished and rare set of skills in creating and implementing robust multitasked networked applications. These skills now become enterprise skills, available for use on multiple platforms, not just in TPF. Your experience and skills now become more – not less – valuable. The only hitch is that you’ll have to learn how to express them in a common API set and programming language(s).

Are assembly language and TPF native API skills obsolete? Definitely not; however, expect that they will become less necessary in the future. In today’s TPF shop, Assembler and the native API. are the lingua franca. As the cost and lead times of this kind of development continue to grow, expect considerable pressure to develop in HLL and use the portable API. Looking into a crystal ball, it isn’t too hard to visualize that high-performance, "hotspot", and library function code will continue to be written at low levels, which means BAL and the native API; whereas mainline applications code will tend toward C and C++ using the POSIX API. Knowledge of how to design and implement well-behaved TPF applications will continue to be a precious skill, no matter the development and implementation methods used.

What should my skill set look like? I suggest starting with C language and the POSIX API, which are likely to be requirements in the immediate future. Exposure to both of these subjects can be gained at most any community college with an introductory level C course. Also, several excellent "self-teaching" interactive programs and texts exist for C language. Chances are you can also find C expertise among your colleagues, and some employers actually arrange for training courses. Any way you approach it, remember that the best way to learn any programming language is to read it and write in it – repeatedly.

To adapt to the longer-term future, you should also have some working familiarity with C++, which arrived in TPF back in PUT06. Like C as opposed to Assembler, C++ relative to C is a more powerful development tool that can be used to develop better applications more quickly. The issue with C++, however, is that it is an object-oriented programming (OOP) language. Using OOP principles and techniques represents a serious departure from the so-called "top-down" techniques the clear majority of us are versed in.

Is Object-Oriented Programming just another passing fad? Not any more so than Structured Programming, which most of us have been operating under for the last 20 years or so. OOP is definitely a different way of thinking about software engineering, or if you prefer, applying the mechanics of programming at a different level. Learning C will give you a leg up on C++; but still expect a substantial learning curve – many of the new concepts you’ll learn will seem almost extraterrestrial until you realize the advantages they provide. OOP application systems tend to have high degrees of reusability and maintainability since they’re designed and implemented based on interoperable components. Current TPF professionals should consider giving these subjects some very careful study. Avant-garde TPF applications designers are already (yes, now) considering C++ solutions to real-world problems. You are likely to have to at least understand OOP code at sometime in the future to perform effective analysis.

Which other trends should we pay attention to? In order to survive, TPF must evolve with the rest of the data processing industry, and be able to participate in corporate missions that eclipse the traditional model of a standalone system. Applications must become accessible from (and interoperable with) many diverse platforms, and be much more easily modified than they are today. With all this said, look to the Internet and see where the rest of the industry is headed. Here’s a short list of subjects for exploration:

The TPF programmer of the future will likely be of the same mold universities are turning out today: exposure to Unix, programming in C++ and/or Java during his or her education, leading to intimacy with the POSIX API and object-oriented software design principles. An understanding of S/390 assembly language will be desirable but should not be necessary.

I realize that the preceding paragraph might describe only 5 - 10% of the existing community of TPF professionals – that’s one of the reasons I was asked to write this article. If you’re one of the 90% in the other category, I strongly recommend investing some time in some basic education – leaning on your BAL skills alone may prove to be a poor career decision. The rest of the industry is not standing still, and neither should you.