TPF Performance - An Introduction
by Paul Rutti
"The very life-blood of our enterprise" - (Shakespeare, King Henry IV, Part I)
The Importance of Performance
Question - What do Olympic track stars, Indy car drivers, and thoroughbred race horses have in common with TPF programmers, analysts, technicians, managers, etc.?
Answer - All three are associated with world-class s.t.p. No, not "the racer's edge", but rather speed, throughput, and performance. Performance is the reason for TPF's very existence, it's purpose in life. The ability to handle hundreds, even thousands of transactions every second (throughput) and meet real-time resource demands with sub-second response time (speed) has given TPF its unique niche in the information processing world. Because of this, the careful monitoring and analysis of system performance is vital to the success of any enterprise utilizing TPF. A TPF system without excellent performance is like having Secretariat pulling a milk wagon.
As an introduction to the world of TPF performance, this article will discuss the importance of performance, introduce the basic tool of TPF performance monitoring and analysis (Data Collection), and finally, will invite further discussion on this topic in the future.
An introduction to TPF performance analysis would be incomplete without discussion of Data Collection, the basic tool for monitoring system performance. Data Collection is a utility which is run on demand, usually during the time of peak system workload.
Collection and analysis of this data provides much valuable information on the current system workload and resource consumption. Compilation of this data over a period of time may be used to establish performance baselines and identify changing trends. Future resource needs in terms of CPU capacity, DASD capacity, memory, etc. can then be projected and planned for accordingly.
Data collection is made up of four separate components: system, file, program, and message collectors. Within a single run of Data Collection, any one, two, three, or four of these collectors may run together in a sample mode, where they alternate taking periodic samples of the data, or one of them alone may run in a continuous mode, where the run is uninterrupted until Data Collection is complete.
The System Collector provides the following data: arrival rate of workload or message rate, CPU utilization in terms of elapsed time in various CPU wait states, length of each CPU list, working storage and ECB block allocation and utilization, shutdown levels and occurrences, and more.
The File Collector gives counts of record and program accesses by record type or program name, file macro used, by device and channel, VFA hits (by the same criteria) and misses, tape I/O information, and DASD device queues.
The Program Collector tracks program segment calls and returns (enters and backs), core or file residency of program segments, and nesting levels of program segments.
The Message Collector time stamps the arrival and the departure of messages to the system in order to determine some aspect of internal system response time. It also records the message text and number of bytes for both the input and output messages.
During the collection process, data is accumulated and written to a special JCD tape, where it will be processed offline by the Data Reduction package in an MVS environment. The Data Reduction package is essentially a report generator, written in PL/1, with the ability and the flexibility to provide summary and detailed reports, and plots of system component usage and performance.
While Data Collection answers many questions on a system-wide level, there are some questions which are left unanswered as well as many desirable functions that are left undone. What are TPF'ers to do? Well, being the innovative, creative, and adventurous sort, they improvise. Several products in the market have been developed to address some of Data Collection's shortcomings. Many shops have developed their own functions as well, which are designed in accordance with the needs and characteristics of their individual systems.
In summary, for what it was designed to do, Data Collection is a good package and a useful tool, but a lot of good ideas have resulted from the needs to address performance questions in greater depth and with greater precision. Some of these additional needs which are not completely met by Data Collection include: saving performance data into a database, monitoring system performance on a round-the-clock basis, displaying real-time performance statistics, tracking of individual messages and transactions, and measuring resource utilization by application, package, function, etc. Solutions to these are varied and may be the basis for future discussions and articles.
The Future of Performance
Speed, throughput, and performance are the characteristics of a well-designed, closely monitored, properly tuned TPF system. If these were the only issues though, this may be accomplished to a large degree by reducing functionality, adding more hardware, spending more money, etc. The real issue is value, that is delivering the greatest functionality to the end users of the system at the least possible cost. It includes not only performance, but also functionality and system availability. It involves decision making and trade-offs and maximizing the efficient use of limited (scarce) resources. In this age of fierce competition, global enterprises and streamlining in most every industry, value is the key to success, and performance is the key to achieving value.
Therefore, as the TPF world moves into the future, the need for effective, systematic approaches to achieving maximum system performance will continue to exist. The methods may change, the tools may change and evolve, but the need will always be there just the same.
Since TPF lends itself uniquely to in-house customization, many TPF sites have greatly modified, enhanced and expanded the performance monitoring and capacity planning capabilities of their TPF systems. In addition, a number of installations are moving forward into technologies new to the TPF world, many of which have been discussed in this publication, e.g., C/370, ALCS, TPF/DF, etc. New hardware technologies are also being introduced continuously. Certainly, new challenges and experiences in the areas of performance and capacity planning will result from all of these developments.
As a result, let me suggest that ACP/TPF Today may be used as a forum for the exchange of ideas, issues, and questions related to systems performance analysis, hardware and capacity planning (as it is used today in other areas). If there are any of you out there with an interest or an inclination to raise an issue, ask or answer a question, or relate an experience, please contact me (FAX: 214-387-8196) or ACP/TPF Today. In the mean time, keep those TPF systems performing!