Title

2006-01: Networking User Program Agent Interface Changed Without Warning

Note: This was resolved without having to raise it as a formal requirement and Unisys should be commended for taking the proper action without requiring UNITE to resort to the Requirement process.

Background

MCP Performance monitoring software (like our SightLine software product) requires a programmatic interface to collect performance data for the network connections installed o! n a given MCP system. This is particularly important, since the implementation of CNA devices and IEA-IOPs, as this is the only way to acquire performance statistics on these devices. The MCP provides a facility called the Network User Program Agent interface which is documented in the "Networking User Program Agent Programming Guide" (3787 5135003). This interface allows monitoring software to submit encoded commands programmatically and receive encoded responses. With the release of MCP 11 (SSR 52.1), the program agent interface no longer supports the "NW TCPIP TCPIPIDENTITY" encoded command "38039" and replaces it with the "38047" encoded command. This was done without prior warning. Prior MCP releases did not issue a de-implementation warning. There was no MCP release available where the old and new encoded commands were both supported. The abrupt nature of the de-implementation impacts our user community because an MCP upgrade now results in our network performance monitoring module being disabled. While we can fix this on a going-forward basis, we cannot make the transition transparent for our customers.

Requirement

We would require that when Unisys de-implements a Networking User Program Agent Interface encoded command, that support for the de-implemented command be continued for three future MCP releases and that the pending de-implementation be documented and de-implementation warnings be issued during the three MCP release phase-out.

Unisys Response

When MCP 8.0 was released, we included a feature called Classless Inter-Domain Routing (CIDR) and Variable Length Subnet Masking (VLSM). The TCP/IP Identity command and inquiry, as well as some other commands had to change to support the new feature. As part of our new command implementation procedure, we planned that the obsolete command be de-implemented in release 10.0 (51.1). This request meant that TCP/IP would emit a warning on Networking releases 8.0 and 9.0 if it encountered the obsolete command, warning our customers that they needed to move to the newer version of the command. Unfortunately, this warning was issued in the form of a Sumlog warning message, not a waiting entry or even a "DISPLAY". This was incorrect on our part as we should have implemented it as a DISPLAY or WAITING ENTRY, for better visibility. With MCP 11.0 (52.1) we de-implemented the command within the TCP/IP Support Library.

However, we broke our desired precedent when we de-implemented the command in 52.1. Normally, encoded (programmatic) Operations Interface commands are maintained "forever.", if possible. It is only English (Textual) Operations Interface commands that get de-implemented. In this case, we de-implemented the command through the TCPIPSUPPORT library. The TCPIPSUPPORT library receives only encoded commands and inquiries. It has no way of telling whether the command that was issues was originally English or encoded. As a result, both the English and the encoded form of the inquiry in question were de-implemented.

When we received the RCC, we recognized our error and have since implemented a fix. Networking flash level 52.121.0000 moves the de-implementation code from the TCPIPSUPPORT library to the Translator, where we are able to tell if the inquiry was issued as English or as encoded. Following installation of Networking flash level 52.121.0000, the affected encoded requests from a program agent will again function correctly.

UNITE Response

UNITE accepts the Unisys response. Note that this was resolved without having to raise it as a formal requirement and Unisys should be commended for taking the proper action without requiring UNITE to resort to the Requirement process.