Movable VIPA Monitor

TPFUG_Req_Number: C06001S
Contact Originator Id: billy.carter@worldspan.com
Abstract: A monitor is required to monitor and manage movable vipa addresses in the loosely coupled TPF complex. We also need a utility that can be used to determine if a cpu has an active OSA network running on it
Description: A movable VIPA address can be defined on any and all processors in the loosely coupled complex, but there currently is no way to automatically manage which processor they are running on at any given time. Experience has shown that just using the information in the PIDT is not enough to determine if a CPU is really in a condition to take IP traffic.

The monitor needs to determine when a movable vipa address is running on a cpu that is not usable for the movable vipa address. Some examples of this are
1) Not in Norm
2) Cycling
3) No active OSA Network on the processor
4) CPU is dying, dead, in input list shutdown, dumping, etc.
5) CPU is not in the complex or invalid



To determine if there is an active OSA Network available, a utility needs to be built that can be used to find out if an OSA network is up and active on the processor. This utility should be available for this monitor and for any other processes that needs to know this information. The input parameter for this utility would be the IP address.

A database of movable vipa addresses to be monitored needs to be built that would give the ability to define the movable vipa addresses two different ways:
1) enter a program and have the program return the cpuid for the mvipa address to run on. Whenever the monitor runs, always enter the program to find out what cpuid the mvipa should run on. The program that is being entered can use the utility previously described to determine if IP/OSA is available on the processor before it returns the cpuid to the monitor. The program name to enter should reside in the data base.

2) have a preference list of cpuid's that the mvipa will run on. Only use this list if the processor that a mvipa is running on is determined to be not usable by the mvipa. An example would be if the MVIPA had a preference list that showed cpu's a, b, and c in that order. MVIPA is running on CPUA. CPUA has some kind of problem, so the monitor would move the vipa to CPUB. After CPUA comes back up, the MVIPA would be left on CPUB until CPUB had some kind of failure, then it would move back to CPUA assuming that CPUA was available at the time of the failure of CPUB. The cpuid preference list should reside in the data base. At least one cpuid in the preference list should be required.

3) have a preference list of cpuid's that the vipa will run on. Always
try to move the mvipa to the most preferred cpu. An example would be if the MVIPA had a preference list that showed cpu's a, b, and c in that order. MVIPA is running on CPUA. CPUA has some kind of problem, so the monitor would move the mvipa to CPUB. After CPUA comes back up, the monitor would move the mvipa back to CPUA. The cpuid preference list should reside in the data base. At least one cpuid in the preference list should be required.
Critical Success Factors: This monitor should not impact RIP processing.

The ability to add, change, modify, and delete items in this table should be able to be made via functional message in any system state during high traffic periods.
Solution Considerations: This information could be added to the OSIT using the ZVIPA functional messages. This information should be optional to use by Movable VIPA address.

How often this monitor gets activated should be a user configurable parameter at the second level i.e. ability to run every 10 seconds.