Massaging Message Measuring Mathematical Methods
by Mark Gambino, IBM TPF Development

What, oh what, is a message? Not a simple question is it? How about a TPF message? That is still not a simple question because like poems, sonnets, and laws, the definition of a TPF message is subject to interpretation. Some might say that a TPF message is a path information unit(PIU). Others may think that a TPF message is two PIUs; an input PIU and its corresponding output PIU. Not having a universally accepted definition of a message makes it difficult to do capacity planning and leads to confusion when trying to compare message rate claims.

Looking at the existing TPF data collection package, the high-speed (HS) message counter is updated by SNA Opzero when a data PIU marked as end chain (EC) is received from the network. If data is too large to fit in a single PIU, the data is sent as two or more chained PIUs, where the first PIU is marked as begin chain (BC) and the last PIU is marked as EC. The HS message count is only updated when an EC PIU is received because that indicates the receipt of a complete message that will be passed to the application program. This way, the HS message count is consistent across systems that have different network capabilities. For example, suppose that terminal X is sending 1024-byte messages to two TPF systems, TPFA and TPFB. The links connecting terminal X and TPFA support 1024-byte transmissions, but the links connecting terminal X and TPFB only support 256-byte transmissions. Four times as many PIUs will flow into TPFB than into TPFA, but the HS message counter value will be the same on both TPF systems.

The existing logic to update the HS message counter was designed to handle "one message in, one message out" terminals, but more and more LU 6.2 pipeline applications are being deployed. These applications use two LU 6.2 sessions; one to send data and the other to receive data. Because these sessions are unidirectional in data flow, PIUs are never marked as EC; therefore, none of these PIUs cause the HS message counter to be updated. What this means is that there can be thousands of visitors (messages) in the TPF system that the tourist office (data collection) does not know about. APAR PJ24764 changes the way that data collection counts LU 6.2 messages to give a more accurate account of work introduced into the TPF system.

A logical record (LR) is the basic unit of work passed to an LU 6.2 application program. Because of the flexibility of the LU 6.2 architecture, one PIU can contain one LR, one PIU can contain multiple LRs, or one LR can be split across several PIUs. Because of this, updating the HS message counter once for every LU 6.2 PIU received would not necessarily reflect the number of messages that were actually received. For this reason, APAR PJ24764 changed the TPF code to update the HS message counter once for every LR received rather than on a PIU basis.

The other data collection counter of interest for APAR PJ24764 is the systems services control point (SSCP) message counter. This counter is updated when a command is received on a CDRM-CDRM session because an LU-LU session is either starting or ending. In an Advanced Peer-to-Peer Networking (APPN) network, the control point (CP) provides the same function that the SSCP does in a PU 5 network. Commands to start APPN LU-LU sessions are received on CP-CP sessions. A CP-CP session is a special type of LU 6.2 session and a CP-CP session command contains one or more LRs. APAR PJ24764 also changed the way that data collection counts CP messages. The HS message counter is no longer updated because CP messages are system messages rather than application (user) messages. Instead, the SSCP message counter is updated once per CP command (PIU) received (not once per LR).

The changes made by APAR PJ24764 enable data collection to give a more accurate representation of the traffic flowing into your TPF system. Your performance and capacity planning departments that analyze the data collection/reduction reports need to be aware of the changes made by APAR PJ24764 because the HS and SSCP message counter values will likely increase if you use LU 6.2, APPN, or both. The optimists might be falsely pleased thinking that more messages are being processed even though core block and CPU utilization levels remained the same. Sorry optimists, you should know that nothing is free. The pessimists, even the mathematically challenged ones, would question the new numbers because something does not add up here. The realists will see that the new numbers make more sense. The changes made by APAR PJ24764 came from requests made by TPF customers and are good examples of how your feedback is important to us at the TPF Lab.