Change Management For The TPF Environment
by Frank Fannon

The TPF environment at AMTRAK has always been considered sacrosanct. There has invariably been a mystical aura about what "those people" do over in that group. They talk in secret codes like FACE Tables, SALs, LIMBO libraries, and General Files. Getting affairs arranged in order to be able to properly conduct testing was something of an ordeal that seemed as though it required witchcraft to complete.

The process of implementing program changes into the Production libraries was yet another set of trials and tribulations. This procedure required the coordination and timing of a major military offensive. There were a great number of steps to be followed in an exact sequence, with no deviations. It also involved many iterations of library backups, testing, and even backing changes out of the "LIMBO" libraries. These were intended as interim libraries for the duration of user testing. As the users conduct testing, any number of program changes can be rejected, so the programs must be backed out of the library. The remaining programs and macros finally get to be implemented into the production libraries.

It is important to note that all of these manipulations were carried out, for the most part, by two Change Management staff members. One of the continuing issues with program maintenance in the TPF environment was the existence of a semi-automated program versioning facility. A mechanism was established that maintained a rather manual version number for each program and macro.

A Solution
At AMTRAK, we have acquired a Change Management tool called Endevor. It is marketed by Legent Corporation. Initially, it was scoffed at because TPF was "too special" to be grouped together with anything in the MVS world. After all, we have always conducted business this way, and it works, so why even consider changing? Why waste the time to analyze the process? We decided that, that it remained to be seen, since no one had done any type of analysis of the existing procedures.

We performed an indepth analysis of the entire testing and implementation process. After many information gathering sessions and subsequent analysis of the data, we determined that, lo and behold, TPF wasn't really all that different from MVS. It has source code, macro, and load libraries. The fact that the Operating System is also stored in the same library as the application programs, while somewhat different, was surely no "show-stopper." In fact, once we updated the related manual procedures and timing issues, the overall process turned out to be quite efficient. The revised TPF environment turned out to be so "clean" that we opted to use it for the inaugural migration into Endevor.

Why Endevor?
One of the "selling points" for Endevor was that it will perform automatic versioning and release control. Using Base and Delta technology, Endevor can maintain up to 99 discreet versions of each element under its control.

It has a "lock-out" facility that will not allow Programmer - B to retrieve a program that Programmer - A is working on. There is however, an override capability, for emergency situations. Programmer - B could retrieve a program, make modifications, and then re-install in Production before Programmer - A is ready for implementation. However, when Programmer - A finally opts to implement his/her programs, Endevor will not let the move occur until the changes made by Programmer - B are included. This is a very important safeguard that helps to avoid situations where one programmers' changes overlay the changes made by another.

Another very powerful feature is Automatic Configuration Manager (ACM). It gives the user the ability to query across all of the libraries. For instance, if someone is changing a macro, lit is very important that every program that uses that macro be modified if appropriate, and/or reassembled. ACM permits the programmer to identify every program that uses the particular macro. That is just one of many types of configuration reports that are available to the user.

If a situation arises wherein two programmers have to modify the same program at the same time, Endevor will keep track of who is working with which program. Depending upon the sequence of which programmer attempts to replace the program in Production, Endevor will prompt him/her to run Parallel Development Manager (PDM). This facility will perform a line by line comparison of code. It will provide a comprehensive report that includes suggestions of how it will combine the differences. Ultimately, of course, the programmer has the final say.

The tool also has an electronic approval process that is very flexible. Before any of the elements can be promoted, there can be a requirement for a certain number of approvers, some of which may be required, by defining a quorum.

The Migration
The actual migration was accomplished in four passes or phases. The migration process required handling roughly 5,200 programs and seventeen hundred macros. The first pass consisted of the entire set of macros since they are used through-out the system. The second pass included the offline support programs. The tertiary phase consisted of migrating the actual ARROW Reservation Application itself. The last phase culminated in the migration of the Control Program or Operating System.

Lessons Learned
Part and parcel of the entire process was the training of both the technical staff and the first line managers. We determined that the most effective method of training was to hold a four-hour, hands-on familiarization and overview session. This was followed by more detailed advanced session that lasted from two to three hours. Since there is a certain amount of new terminology associated with the tool, as well as some novel concepts, we discovered that for maximum retention, the training was best delivered in two sessions. Members of the project team were assigned to act as a "help desk" for several weeks in order to ease the growing pains associated with learning the new tool.

As far as we have been able to ascertain, we are the first Endevor user to successfully automate the management of the TPF environment with Endevor. The documentation of the old procedures so that the analysis could be performed, and the reaching of consensus on the new procedures, were the hardest obstacles to cross. The new procedures as well as the actual migration, were successfully completed due to the persistent efforts of John Studt, a member of the TPF technical staff.

In summary, we feel that Endevor has afforded the means for us to further our Corporate Quality Improvement program by providing an automated change management facility that not only protects our software assets, but assists the technical staff in completing some of the more laborious research type tasks via the use of ACM.