Live Long and Prosper
Growing up in the sixties, one couldn't help being influenced by Star Trek. As entertaining as each weekly offering was, it also left us with a lesson learned. Certainly, "good" will triumph over "evil". All beings everywhere entertain a unique "human" quality. And never laugh at a guy with pointed ears.
In the last several weeks, I've had the opportunity to attend the TPF Users Group Conference, and have also met with many IBM and non-IBM types. Inevitably, the topic of conversation turns to NBR. For those of you unfamiliar with the acronym, consider the following options:
a) Nothing Beats Revenue
b) Never Been Run
c) Nikes Beat Reeboks
d) Next Big Release
Congratulations to those of you that chose letter "d". The rest of you report to Engineering and have your dilithium crystals recharged. There's just no getting around it kids, the Next Big Release of TPF is coming. Whether it's a 3.? or a 4.1, it's out there just beyond the range of our scanners. So what's the point?
For years, IBM has listened to the customer, and molded TPF in the customer's image. The problem we have here, is that historically it's been the large customers that have been the driving force in the way TPF has evolved. The reason being that the large users often had the need (as well as the manpower and money) to tailor TPF to satisfy their own business requirements. As a result the rest of the world has been able to benefit from things like VFA, ETIM, and Loosely-Coupled processing, but there has been a hidden cost involved.
Looking at TPF today, one has to wonder why we are still faced with some very basic problems. Why is there still a 16 megabyte working storage constraint? Is there really a valid reason for restricting program size to 4K? How will C/370 make a difference in my development cycle? Now whether these items will be addressed with NBR or not really isn't the issue here. The real issue here is whether IBM is catering to the business needs of a few large and powerful customers, or is moving in a direction that will benefit all of its customers, both current and future.
When a change to TPF would more closely align the product with other technologies, one customer should not be able to veto that change because of the subsequent work effort that particular customer would face. When a gain in throughput can be achieved with modifications to the way programs are called and executed, one customer should not be able to reject those modifications based on personal financial impact. When one or two customers perceive financial advantage in the promotion of a high level language in TPF, the remaining customers should not be forced to accept that decision out of hand.
IBM has stated that TPF is its strategic product in the Transaction Processing arena. The direction is to enhance the product, and to broaden the customer base. Nothing would make this person happier, and this publication is prepared to support IBM in that effort. There is one thing IBM should honestly consider when looking toward the future of TPF.
"The needs of the many outweigh the needs of the few, or the one." - Spock - Star Trek II