WANTED: Application Requester with Dynamic Personality . . .
by John Tarby, IBM TPF Development

…must be able to work with various configurations and get itself out of a bind while running. Applicant must be able to talk along LU 6.2 communication lines and understand Distributed Relational Database Architecture (DRDA) level 1 in addition to a full set of Database 2 (DB2) commands. Familiarity with mixed bytes a plus. All applicants must be comfortable with the TPF operating environment.

When the preceding advertisement ran in a prominent world trade magazine, there was only one reply. It came from a product known as TPF Application Requester (TPFAR). At the time, TPFAR fell short of the requirements as stated in the ad; it did not support dynamic structured query language (SQL), all packages needed to be bound prior to execution time, the only server that it could talk to was DB2 on MVS, and you could forget about talking to any machine that represented characters in ASCII format because it just was not an option.

Well, TPFAR saw the opportunity and vowed to be the right solution for that problem. Slowly it developed its skills. First, it circumvented that stubborn problem of requiring an application to be prebound offline before it could be executed. Its skill development then focused on the ability to speak the language of the little box, namely ASCII. With that there was also this pesky little problem of the IEEE representation of numeric data cleverly disguised under the name of little-endian. Once those two problems were out of the way, the doors opened for a world of servers that supported the DRDA.

To round out its personality, TPFAR expanded its SQL knowledge to include dynamic SQL. This gave applications the flexibility that had not been allowed before. No longer was it necessary for application programmers to make up their minds about an SQL command prior to program execution. SQL statements could be constructed and executed at run time without the need to recompile. With all these new features and options, TPFAR saw the chance for application programmers to get themselves into even more trouble than before, so improvements were made to the error reporting and diagnostic tools. To help reduce the confusion of a cluttered trace table, TPFAR now allowed tracing of activity against a selected database to focus on the application in error as well as the ability to view many details of the error, not just the SQL code and state.

The end result of all this was a more versatile and improved TPFAR feature (APAR PJ23931) that met the requirements of the ad. The problems of the 4-KB program size were gone with the arrival of ISO-C. Application programmers could now take advantage of SQL without the old restrictions on size and program binding. Now, in order to load and run a program containing SQL statements on the TPF system, the application only needs to be run through an MVS DB2 precompiler and then the TPFAR postprocessor before it is compiled. It is not even necessary for the program to be precompiled on the same system that it will eventually be communicating with.

The application does not need to know what system it will be talking to, whether it is ASCII or EBCDIC, whether it is speaking international English, German, or Korean, or running on an IBM RISC System/6000 (RS/6000) system or even a PS/2 workstation. At the time that the application is written and compiled, the target database might not even exist and the server may still be sitting out on the loading dock waiting to be installed.

When the server is finally ready and the application attempts its first SQL statement requiring a bound package, the bind process is initiated. When the bind has been completed, the request that required the bind is re-driven and control returns to the application. From that point on, any time that application is run against that server, a package is out there and the bind process is not necessary. If the application was run once in a TPF test environment connected to the same database with the same collection ID, the DB2 package is already there when it is run on the TPF production system, so the bind process does not need to be repeated.

The new TPFAR offers the flexibility that is needed in today's changing environment. As data migrates from one server to another, the application does not need to be rewritten or rebound; it is all handled by the improved TPFAR.