TPF/DC IN CONCERT
by Jelle Dijkstra

Stradivarius or synthesizer... a classic or an isotonic drink... It's mostly a matter of taste and upbringing, which one you prefer. In the TPF world, the choice can be between plain assembler or TPF/DC programming. What? DC...? Haven't heard about it at all? You ignore it because it has a bad rap? Lend me your ears, and I'll sing you a song. On what DC really is. About its value for a wide variety of people.

System programmers in their role of performance police will recognize one value with their eyes closed: overhead. That's a respectable opinion on one side of the spectrum, but let's look at the rest first. To designers, programmers, end users and all their managers (who want everything running by yesterday), DC will have a distinctly more positive appeal, as it is:

• A rich Application Development tool.
• A real time Dialog Control Manager.
• Object Oriented programming.
• Device Independent programming.
• A Friendlier Face on TPF.

With its many buttons, options, cables, keys and switches, it looks more like a synthesizer than a violin. And that is exactly what makes the Mozart lovers cry out in disbelief: "Can you make music with THAT THING?" My answer to this overwhelming crowd is: "YES, if you WANT to! There's a whole orchestra inside!" Tiny Swiss musicians with all kinds of instruments...

The Audience

End users will benefit in two ways. Their artists, the designers and programmers, will deliver safer and better software faster. In the area of old fashioned string input and output there were never many thrills for end users. DC can only add a prompting facility, and some other useful functions to make life easier.

The 3270 world of formatted screens is something entirely different though. For those of you who already work on such a TPF applications, it may not be entirely new what DC can bring, but certainly an extension. No black hole here. On-screen assistance, menu structure, help functions for each field, standardized but flexible function key usage, the full international character set, highlighting, invisible and inverse, blinking and blinding fields, enough to make you crazy.

Traviata, Marseillaise oder Seifenoper
"C'est le ton qui fait la musique", as the French saying goes. In DC, you select the tone of the system dialog yourself! Choose an Italian temperament, the German precision, or a charming response in French.

Playing the DC Synthesizer

In the roughly nine years of its existence, DC had evolved to a software package with functionality in almost all phases of an application's life cycle. The benefits for end users seem merely superficial, compared to the power of DC as a tool for developers. There is no need indeed to have the wheel newly defined by a dedicated Task Force in the TPF Users Group's Application Development Subcommittee... With some customization, this wheel fits anybody's cycle.

To start with the Design & Specification phase, you can use it to realize a prototype. In the offline maintenance environment, you create a framework of transactions, consisting of screen layouts, input edit rules, messages, prompting and help information, elementary file handling functions, and high level logic which directs the flow through the framework. Then, you do a build run (a kind of compilation), and load the resulting files on a real time system. You don't need to write any program for a simple prototype.

In the Development phase, you can turn a prototype into a more definitive version, by adding the detailed functionality of you programs. Note that the number of programs is much smaller than for the same application without DC.

Testing and refining of DC transactions is similar to the iterative process for programs: modify, build, load and go. There are test tools that deal with the online infrastructure of DC, also in relation with SST.

When the time has come for implementation on a live system, you finalize the framework of transactions. On that occasion, the offline part generates documentation members containing all elements of the transactions, ready to be formatted by DCF/SCRIPT. In your main application document, you write the necessary text and include the generated document members as illustration.

For the Production phase, there's a postnatal care in the online and offline area, with version control and various cross references. The offline environment forms a good basis for a data dictionary, because it is a central repository with "data about data" of DC applications.

Let's Get Physical
You maintain the DC transaction components in the offline environment. With a build run, you give them the form of TPFDF files. They are written to a General Data Set, which serves as a bridge between offline and online.

You load those files (just like you load programs) onto an online system, where they are primarily indexed by transaction name. During execution of the transactions for the end users, the online part of DC reads or copies those files, depending on their function. Somewhere along the line, your programs are entered under control of DC. They are slaves and must respect the DC environment (which does not exclude them from doing I/O's with TPFDF or FINWC macros - don't worry). They can even be written in C, while the DC macros are implemented in a C function library.

The Mysterious Device Independency
What the programs and the programmers don't need to know, is FMSG and IMG and UIO and OPMT and 3270 data stream control characters and all that boring, complicated stuff. It actually happened that programmers, who had joined the company years ago, and since then had only worked in a pure DC application, asked the question: "What is UIO?". We said: "You don't want to know!"

DC applications get their input cooked and ready to eat, stripped from device control characters, nicely formatted in TPFDF lrecs. On the output side, all they need to offer back to DC for output formatting, is TPFDF lrecs too.

So application programs are device independent; they operate solely on the upper level of any known data communications model. They set up messages with a macro, and don't care about the user's screen format. This doesn't apply to screen dialogs only; there's also support for sending data in a formatted way to ALC printers, and for processing of ARINC/SITA telex messages. A Host-TO-Host Device Driver makes our applications independent of the communication habits of dozens of tour operators. Anybody who wants to access DC applications through a device type which is not supported yet, can write a Device Driver to make the connection. That is a one-time effort, and it immediately works for all applications.

Object Orientation
Whoopee! One day we discovered that DC is Object Oriented! It may seem silly to say it this way, but DC was not designed with the OO word as inspiration. Moreover, the TPF world is not exactly the home of "user objects" that you can move around on a screen with the click of a mouse, but the inner mechanics have all the characteristics. Messages to and from Objects, Information Hiding, Device Drivers, it's all there.

Future Orientation
The trend nowadays is definitely away from explicit assembler code, in order to gain productivity. At least for software makers, that is... tools like SPM, TPFDF, CMSTPF, and C do help programmers, and only indirectly the end users. DC however, puts comfort and productivity for the end users on top of its programming advantages.

Many of these products clearly shift the work load from us to the machine. When the comfort of tools is appreciated by end users and software makers alike, a tendency toward less efficient use of resources might arise. Generations of programmers who grow up with C, TPFDF, or DC might lose contact with what is going on behind the scenes of some good looking call. Generations of end users who grow up with the fancy PC software, will expect the same from TPF.

Only as long as we maintain an everlasting awareness of TPF's properties and purpose, there will be peace between the performance police on one side, and the end users on the other side. So let's apply the proper tool for the proper function. TPF can surely handle this gradual introduction of new tools, because the hardware is getting ever more powerful. And at the same time, we shall not neglect efficiently written string entries, because they are so jolly handy for surgical strikes.

Imagine this Concerto For Stradivarius And Synthesizer. Then hear the roaring applause. No riots, and no raids by the performance police!

Jelle Dijkstra is a software engineer at Swissair, working on the TPF/DC project since 1987. He's tall, blonde, single, and has blue eyes with a touch of green.