The Wrath of CONN
by Mark Gambino, IBM TPF Development

All applications that reside in the TPF system are defined in the routing control application table (RCAT). Scientists who have studied the TPF system discovered that the creation of an application starts when an MSGRTA statement is coded in the system initialization program (SIP). The output of SIP includes the RCAT initialization records (RCIT). During system restart, when the online TPF system is brought up for the first time, segment CONN uses the RCIT to create the RCAT. After the system is up and running, the question becomes how to define new TPF applications. Until now, the answer was to go back to SIP and start over, which meant down time and required a network restart.

Scientists working in a remote space lab (in Poughkeepsie, New York) saw the potential in the TPF 4.1 system to overcome the obstacles that currently prevent applications from being added "on the fly”. E-type loader support provides the ability to load the new application program (real-time segments) while the TPF system is up. The second and more difficult problem is how to define the new application because, in addition to the RCAT, there are several other tables in core memory and on file that must be updated: the resource vector table (RVT), application name table (ANT), node control block (NCB), and network address table (NAT). Failure to update all of these tables results in what the scientific community calls "an unstable isotope" rather than a usable new application.

Major breakthroughs came from dynamic LU support because it gives us the ability to change RVT entries on the fly and removed the restriction that the LU section of the RVT must be kept in alphabetic order. Using this knowledge, our scientists embarked on the project code named Genesis, whose mission was to create life (an application) from lifelessness. The result is a new driver (to be shipped on PUT 6) that gives you the ability to define a new TPF application while in NORM state by simply entering a functional message.

To use the driver, first define spare or dummy application names during SIP when you generate your TPF system. For example, code an MSGRTA statement with APLIC=DUM1. This will cause an entry for DUM1 to be created in the necessary tables (RCAT, RVT, ANT, and so on). After your TPF system is brought up, you want to define a new real application whose name is ABCD. To do this you enter the driver functional message, telling the TPF system to change DUM1 to ABCD. Besides changing the application name in the appropriate tables, the driver also allows you to change the following:

• The CPU ID of the processor where the application resides
• The subsystem user (SSU) name where the application resides
• The name of the real-time program to be activated when data is received for this application
• The NCB number that dynamic LUs logging on to this application will use
• The value of the RCATIND, RCATIND1, RCATIND2, and RCATUA bytes in the RCAT entry.

In addition to changing the primary logical unit (PLU) name of the application, the driver changes the SLU thread RVT entries for this application if any exist. In the previous example, if APPL=(S,2) was coded on the MSGRTA statement for DUM1, two secondary logical unit (SLU) thread RVT entries would be created. Assuming the CPU ID of the TPF system is A, the SLU thread names would be DUM1A001 and DUM1A002. The driver would change these to ABCDA001 and ABCDA002.

Note: A user's guide explaining the installation process and operational procedures will accompany the driver code on PUT 6. Read the installation and operating procedures carefully--incorrect use of the driver can cause inconsistencies between tables in core and on file resulting in dumps, session initiation failures, or both. The secret of the Genesis project is out; CONN is no longer the only one with the ability to create TPF applications.