A Novel Use for CMSTPF
by Cliff B. Adams

Those of us who use CMSTPF know it as a powerful test tool, but there is another use for it - live system coverage. Once an installation that already has CMSTPF starts using this facility, programmers will think it remarkable that no one ever though of it before, and will come to depend on it. For installations that do not use CMSTPF, this might in some cases be sufficient reason alone to acquire it. It certainly weighs heavily as another good reason for adding it.

CMSTPF is a simulation of TPF under VM, and can therefore make use of all of the facilities available under VM, such as CMS editing. Using XFIL, for instance, a CMSTPF version of XEDIT, one can do full screen editing of file records. This cuts down on the time of altering and is more error-free than the usual ZAFIL's or other alteration entries that exist on a native TPF system, or on VPARS. Similar entries exist in CMSTPF for editing other data, including core locations, ECB's globals and programs, and with customized panels to make the data easier to read. Trace facilities and other ways of manipulating what is happening during the processing of a TPF transaction are also way beyond the capabilities of any other type of test system.

One of the greatest advantages of CMSTPF is the ability to affect only the user's database, and to be able to clear it, save it, and restore it, without affecting any other programmer. While records can be read from regular TPF Mods, a VPARS disk, or one's own or another's A-Disk, all records are written to the user's A-Disk. That means that the only user that is affected by the programs being loaded, or changes to the database, is the individual CMS id. One can even simulate situations that cause the system to "crash" without affecting any other programmer or user. And on top of all that, CMSTPF will check for error conditions that may slip past normal live or test system processing, such as core clobbers, or using RDA after executing a macro.

In most installations that use CMSTPF, the data is read from the test system packs and from the CMSTPF shared data areas. One day someone asked, "Why can't CMSTPF read from the live system packs?" There is no reason why it can't. Installation is extremely simple- simply create another SYSCON, which reads from the live instead of the test system. Once this is in place you bring up CMSTPF on your own id or from a special id, and you have exactly the same facilities you have when you are testing, except that you are now looking at what happened five minutes ago, instead of what happened five weeks ago.

The advantages of this are obvious. Instead of looking at records on coverage terminals or posting dumps, you are looking at the live system database with all of the editing and testing capabilities that you have available while you are testing. Suppose you get a coverage call in the middle of the night. You log onto your PC at home, dial into CMS, and bring up your live system database, with full screen edit of all TPF data, but you can also test possible solutions to the problem before making a commitment to implementing one. If there is tape output involved you can even have that go to your own CMS file.

Suppose some entry is generating a CTL-3 out of program WXYZ. You have never heard of program WXYZ, and have no listing available. You pull down the listing from the library, create a SourceView file, make the entry that created the problem and you're stepping line by line through the code where the problem is occurring.

Now suppose you find that the problem is being caused by bad data in a record. so you edit the record(s) using XFIL, file it and make the entry again. Voila! The entry goes through. Now that you know for certain that your ZAFIL is going to work, you call it in and go back to bed. Or perhaps there is an error in the program itself. so you trace until you find out what is wrong with the program, and wither create a patch, test it using the CMSTPF fullscreen program edit capability, or you create a new version of the program and load it to your local database and test it. If it doesn't work, make another change and test that (try doing that on the live system!). You can even go on to other entries that might be affected, to make sure will be no further complications. Now you can call in a solution that you already know is going to work.

The above scenario certainly must sound better to most coverage programmers than the usual groping - in - the - dark and you'd - better - come - in routine that most on-call coverage programmers go through. Even when the programmer is on site, there is the usual ritual of educated guessing, posting a dump, waiting for the dump to be posted, interpreting the dump, and then writing the ZAFIL and praying that you didn't make a mistake. Yes, there's always VPARS, but the VPARS test system does not have the situation that is causing the problem, it takes time to set it up, and you are never guaranteed of re-creating it exactly.

Coverage questions that normally can take hours to answer, even when it's merely for information, very often take only a few minutes when using the facilities of CMSTPF. And it can be done with a degree of safety not available to TPF in any other way.

Some DP managers may feel uneasy about programmers having such easy access to the live system database. But considering that the access is read-only, that is considerably reduces the risk of making errors when altering the live system database, and speeds up the time of fixing problems, such hesitation is unfounded. Objections based on proprietary information being on the live system is also besides the point, since most programmers have such access anyway., through the test system, or coverage terminals.

The only objection, from a live system maintenance point of view, that has some legitimacy is that reading a record from CMSTPF will involve file access that, while it cannot damage the database, could under a very unlike scenario, cause pack contention. One would have to work very hard to create this problem , however, since you would have to access the same pack over and over again in a loop in order to cause a problem. This could not be done even by accessing the same record over and over again, because CMSTPF has it's own VFA - like buffer. If you read the same record repeatedly you would simply be reading it from your own VFA buffer, and would have nothing to do with the live system packs. In order to create this problem, you would have to fill up the 256 record VFA buffer on CMSTPF and THEN access another record over and over again. Even this extraordinarily unlikely scenario can be prevented simply by limiting the number of records that can be accessed once the VFA buffer has been filled. This can be done through VM itself, or from within CMSTPF. The extraordinary unlikelihood of causing a problem of this type (and even that would only cause a minor slowdown) is far outweighed by the advantages.

There is one caution to keep in mind, however. The live system database is obviously not static. A second after you bring up CMSTPF the database has changed and you may be looking at a record that is out of date. The address directory that is created when you initialize the CMSTPF database may be obsolete within seconds, and your program could be reading the wrong record. This is something to be alert for than an impediment to using the facility, however. The file directory usually does not shift dramatically in a short period of time, and if you're ever in doubt about the results of a transaction you can always reinitialize the database and bring up CMSTPF again, which will give access to the latest live system data.

I can almost guarantee, once you start using this you will wonder how you ever got along without it.

Cliff Adams has worked in both Systems and Applications at Pan American World Airways, and is currently an Applications programmer for a major financial company.