Allan Feldman, IBM TPF Development

It used to be simple . . . you wrote an application in assembler language. Assembler has been around since the beginning of time; no problem. You coded to a simple file application programming interface: FINDC, FILEC, FACS, and even the more sophisticated FINHC. It might not have had as much functionality as you would have liked, but it worked.

But, you say, productivity is lacking somewhat and recent college graduates, incredulously, do not think that writing TPF assembler programs is very interesting.

So you try a higher-level language: C, and even C++. All of a sudden you need a compiler, prelinker, and linker. Maybe some of the code that you ship to your customers is ported, and the owner considers it proprietary. So you ship only object modules for some of it without the source code. Now your customers have to be with you on this because some load modules contain objects compiled by you and some compiled by your customers. This means that your customers need a compatible compiler level. Perhaps things just got a little more complicated.

But, you say, your customers cannot wait for the new application that you are writing.

So you use a database manager called TPF collection support (TPFCS) instead of FINDC/FILEC. TPFCS creates structures for you, organizes data and provides search capability, and it has consistency. These are all the things you would have implemented yourself using FINDC/FILEC.

OK, you are getting there. Productivity is improving. There are people around with C and C++ skills. You are more dependent on system services than you used to be, but that's OK.

But, you say that you still have to worry about inconsistent database updates. You have to write a lot of code to handle partial database updates if the system IPLs suddenly and you have to back out some of the updates.

So, you say, "We will create a system with enough redundancy that we will never go down." Then, after your colleagues stop laughing, you say that you will create a resource manager and use the TPF Transaction Manager to ensure that all database updates occur, or none occur. All of a sudden, you don't have to write all that code to recover from partial database updates.

But, you say . . . .

Welcome to MQSeries Development

So I say, "It's a brave new world!" Yes, life is more complicated, but so is today's business environment, which requires new functions delivered faster than ever before. TPF MQSeries, I am proud to say, is based on a lot of the new technologies that the TPF product has shipped in recent years. While MQSeries is officially called middleware, to a large extent it is very similar to applications developed by customers. It is almost all ECB based, it has very few control program changes, and it is mostly written in C and C++. Using new technology available on TPF has enabled TPF development to deliver MQSeries functionality and performance more quickly than we might have been able to do previously.

Yes, it can be frustrating. Compiler levels need to be compatible; you need to figure out how much recovery log you need; you need a C language environment and TPF collections. All of these "things," which are complex on their own, need to be running smoothly in order to run turbo enhancements for TPF MQSeries; and, yes, turbo enhancements for TPF MQSeries is very complex too. Resources are different: system work block (SWB) size and allocations have changed, and recovery log requirements are vastly different. The TPF restart logic to recover TPF MQSeries queue updates is among the most complex logic in the TPF system.

We have tried to make life easier. For instance, we now ship complete executable load modules for all DLMs and DLLs, including the MQSeries DLMs and DLLS. We also moved all of the user exit segments out of the main MQSeries DLL (CMS) so that you could use our shipped executable load modules and also code user exits. The intent is to help you avoid the complex task of compiling programs and linking DLMs and DLLs. The problem was especially difficult for MQSeries because our DLLs contain object code only (OCO). This means that you must compile non-OCO MQSeries modules using a compiler that is compatible to the one that IBM TPF used to compile the OCO modules; and because the IBM compiler needs to be upgraded from time to time, you need to stay current with compiler releases. So, if you do not need to modify our code, you can avoid the hassle of compiling and linking MQSeries modules by simply loading the executables that we ship.

MQSeries has provided trace functions to help diagnose problems. We have the ability to trace communication flows and function calls. This has proved invaluable in diagnosing problems. And we have plans to enhance our displays. Several of you have asked for more information in the channel and queue displays to help manage your MQSeries system. These enhancements are on the way.

And TPF MQSeries behaves itself . . . in transactions that is. MQPUTs and MQGETs participate in transaction scopes. Applications can include database updates (for example, FILEC) and MQSeries queue updates within a transaction, and the TPF transaction manager will ensure that all of the updates (including MQPUT and MQGET) occur or none of the database updates occur. This greatly simplifies error handling for applications. Previously, applications had to handle partial database updates if TPF IPLed before all of the updates made it to the database. No more; that's our job now. We wrote a TPF MQSeries resource manager to handle the MQSeries portion of the transaction, and we wrote the very complex restart logic to restore the MQSeries queues to a consistent state at the time prior to the IPL. All of this was done to make life easier for applications!

Get Current

My advice for those of you who plan to use MQSeries on TPF is to get current. We shipped the TPF MQSeries client on PUT 5, local queue manager support on PUT 9, and we are now at PUT15+. When a product such as MQSeries has had rapid growth with customers, we continually provide new functionality and fixes to problems found by those customers. There are key fixes to turbo enhancements for TPF MQSeries and to some of the system services used by turbo enhancements for TPF MQSeries (for example, transaction manager and the C language environment) on PUT 13, PUT 14, and PUT 15 that are important for production environments. MQSeries proudly uses many of the new technologies made available on the TPF platform. It is especially important that as new technology rolls out of the TPF lab, you stay current with the latest PUTs.

There are also important enhancements on these PUTs to improve the efficiency of MQSeries sweeper, checkpointing, and restart; not to mention enhancements to provide new functions such as support for MQGET with Wait, support for a fast-path trigger monitor when every message arrives on a queue, and enhancements to the channels to improve buffering and I-stream balancing.

Staying current can be a significant challenge for many customers. Fortunately, IBM can help. Do not be shy about contacting your TPF client support representative, who can discuss your needs and help you find solutions. IBM TPF Services offers education, consulting services, and technical support to help get your system up to current maintenance levels and to implement MQSeries effectively.

MQSeries is one of the hottest products in the marketplace. So far, TPF development has delivered basic MQSeries functionality and we have provided a product infrastructure that will be the base for the future. Turbo enhancements for TPF MQSeries is the base product, which has memory queues, a queue sweeper to free memory resources when necessary, an MQSeries resource manager for database consistency, persistence and recovery, and sender and receiver channels for message delivery. The focus now shifts to providing more MQSeries functions to enable application growth. Customers, especially those members of the TPF Users Group MQSeries Task Force, have prioritized requirements. Customers want an MQSeries server, MQGET with correlation/message/group ID, message browsing, and other functions. These functions, and more, are all in the future.

IBM TPF is committed to delivering new MQSeries functions to you as fast as possible. We will continue to make use of whatever technology makes sense and we will continue to work with you to ensure the highest quality deliverable possible.

Return to the Newsletter table of contents