TPFQL - Function or Fiction
by Salvador VilIasenor
Here is a proposal for a middleware-resident online query tool. Via this middleware, TPF would provide information dynamically which is currently produced via batch reports. Since its inception, ACP/TPF has evolved in purpose and dimension. The system originally supported only airline applications, but now supports applications in any number of industries. These applications require either reliable realtime processing of I/O bound transactions, or the routing of message switching transactions.
The architectural constraints necessary to make a racehorse out of an IBM 360/65 have been somewhat mitigated by today's loosely coupled CPC configurations, improved peripheral devices and more efficient system software. More applications have become candidates for TPF development due to the number of application development tools currently available. These have increased programmer productivity, reducing expense to the company.
SABRETALK, as an example was developed to increase programmer productivity. It was patterned after PL/I. It takes the programmer less time to become proficient in the language, and fewer statements are required to complete a program. While SABRETALK is not as efficient as IBM BAL/ALC, system performance is not unacceptably impacted since an entry spends approximately 70% of its life within the control program. Other tools such as CMS/TPF, VPARS and VTAPE optimize the use of system resources in a development environment by shortening the amount of time it takes to test an application program.
No tool exists today that facilitates the development of complex TPF transactions. The next evolutionary step for TPF may be the development of a tool that enables real-time inquiries to obtain information that today is produced via batch reports. A possible course for this step is described below.
A TPF query function would make it economically and technically feasible for many batch applications to be performed completely within TPF. Both the requirements of high programmer productivity and minimal system impact would be satisfied. Corporate executives need to respond to the needs of the market place dynamically in order to maintain a competitive advantage. As a functional benefit, TPFQL would provide the company with dynamic access to data instead of receiving scheduled reports. Executives could then quickly gauge a company's performance in critical areas.
To ensure high programmer productivity, TPFQL would be designed as a middleware tool. It would use unique file types and would incorporate parameters to be used for internal calls to TPFDF. IBM's TPFDF product minimizes a programmer's direct contact with the database by providing powerful macros to perform data base services, significantly reducing coding. TPFDF further increases productivity by enabling the programmer to bypass testing of functions performed by TPFDF. TPFDF also allows the database to be defined so as to minimize response time.
Under traditional TPF a programmer needs to know the structure and location of the data before it can be accessed. Use of a query language would allow access to the data based on its content rather than its address, using TPFDF file types. Detailed knowledge of the data structure would not be required, and access to the information would be possible for a wider group of Users. An application developed through TPFQL would most likely be easily ported to another TPF installation. (Over 30 TPF installations already use TPFDF)
Today, information produced in nightly batch reports is written to tape throughout the day as events occur. By executing the TPFQL macro, the information would be placed on its own file for subsequent inquiry. To minimize response time impact, a deferred entry could be created to write the information to file. By using the TPFQL function, the programmer would be able to implement any number of inquiries with minimal expense to the company. For example:
Today the Advanced Booking Report includes the number of bookings, by specified date ranges, for each desired city Pair (board and off points). Booking information is written to tape when a reservation is made. Each day at midnight, the current day's information is merged with a master file. The merged file and report parameters are input to the report writing process.
The TPFQL query would replace batch reporting. TPFDF would be used to install the desired information, as it is created, into the TPFQL database. The TPFDF data base definition would support the most detailed report requirements. To capture data it may be necessary to create a deferred entry. This will ensure agent response time is not impacted. Capturing query data as a separate file type will further reduce system impact. TPFQL would process online queries that could provide information at the logical record or higher. In this example, the User would input either a specific value or a range of hours, classes of service, dates and city pairs via an online entry. The User would receive a response indicating that the completed report would be returned as an unsolicited message. The information received will enable the User to make decisions dynamically rather than via a daily report. If the information requested were smaller in scope, it would be returned as a real-time response.
TPFQL is easily implemented with today's technology, and TPFDF provides the framework within which it can operate. TPFQL would enable more applications to be implemented online in less time with reduced effort. The concert is flexible, portable and enhances productivity. Perhaps at the next ACP/TPF Users Group meeting this proposal can be fully discussed and evaluated.