LATCP SHOW bugs? + Historically ever a SYSGEN-specific manual?

[Mark_Corcoran]

I've been updating some documentation concerning troubleshooting problems around LAT ports, and have been detailing the output of various LATCP SHOW commands (SHOW NODE /COUNTERS, SHOW LINK /COUNTERS, SHOW PORT /COUNTERS, SHOW CONNECTIONS /FULL).

Some of the counters reported by MC LATCP SHOW LINK /COUNTERS appear to mirror those reported by other (non-LATCP) commands.

For example, the "Messages Received" and "Messages Sent" reported by SHOW LINK /COUNTERS appears to be synonymous with the "Data blocks received" and "Data blocks sent" reported by both LANCP SHOW DEVICE /COUNTERS and MC NCP SHOW LINE xxx COUNTERS

Both the MC LATCP SHOW NODE /COUNTERS and MC LATCP SHOW PORT /COUNTERS commands include in their output (OpenVMS/VAX v6.2) the counters Solicitations Accepted, Solicitations Rejected, Incoming Solicits Accepted, Incoming Solicits Rejected, and MC LATCP SHOW PORT /COUNTERS also include a Password Failures counter.

From a running OpenVMS/VAX v6.2 system, here's the output of a sample MC LATCP SHOW PORT command:

Port Name:  _LTA7906:

Seconds Since Zeroed:            567100
Remote Accesses:                      0 Framing Errors:             0
Local Accesses:                       0 Parity Errors:              0
Bytes Transmitted:                 7966 Data Overruns:              0
Bytes Received:                       0 Password Failures:          0
Solicitations Accepted:               0
Solicitations Rejected:               0
Incoming Solicits Accepted:           0
Incoming Solicits Rejected:           0
Last disconnect reason code:   24544891
(%LAT-I-DISCONNECTED, session disconnected from !AS)

Pages 14-56 through 14-57 of the HP OpenVMS System Management Utilities Reference Manual: A-L (BA555-90003, JUL-2006) explains the significance of the Solicitations Accepted/Rejected and Incoming Solicits Accepted/Rejected counters (as it pertains to MC LATCP SHOW NODE /COUNTERS).

Page 14-64 of the same manual shows example usage of the MC LATCP SHOW PORT /COUNTERS command and includes non-zero values for the Solicitation Accepted and Solicitations Rejected counters, but it does not explain the significance of the Solicitations Accepted/Rejected or Incoming Solicits Accepted/Rejected (as it pertains to a PORT).

On page 5-64 of the OpenVMS I/O User's Reference Manual (AA-PV6SD-TK, APR-2001) [for v7.3 of OpenVMS/VAX & Alpha], it says "On Alpha systems, port counters information is presented as a counters subblock", and then presents 9 item codes in table 5-19 (named as Node Counters Item Codes for Port Counters Subblocks (Alpha Only):
LAT$_ITM_CTPRT_LCL, LAT$_ITM_CTPRT_SLCA, LAT$_ITM_CTPRT_SLCR, LAT$_ITM_CTPRT_ISOLA, LAT$_ITM_CTPRT_ISOLR, LAT$_ITM_CTPRT_FRAMERR, LAT$_ITM_CTPRT_PARERR, LAT$_ITM_CTPRT_OVERRUN and LAT$_ITM_PASSWORD_FAILURES

On page 232 of the HP OpenVMS I/O User's Reference Manual (AA-PV6SG-TK, JAN-2005) [for v8.2 of OpenVMS/Alpha & I64], it says "On Alpha and I64 systems, port counters information is presented as a counters subblock", and then presents the same 9 item codes as above, again in table 5-19, but now names the table as "Node Counters Item Codes", suggesting a dose of Search & Replace with litle review as to whether what was changed actually makes sense.

The 9 item codes cover all of the counters reported by MC LATCP SHOW PORT /COUNTERS with the exception of the Seconds Since Zeroed, Remote Accesses, Bytes Transmitted and Bytes Received (which although self-evident, should probably have been included in the manual).

However, in the LATDEF module in STARLET.MLB on our systems, the following relevant item codes are defined (the spacing is not exactly as it appears below - apologies, but I think most folks know how good the forums are at preserving spacing/tabs when copying & pasting):

$EQU LAT$_ITM_CTPRT_SSZ      61
$EQU LAT$_ITM_CTPRT_RMT      62
$EQU LAT$_ITM_CTPRT_BYTR     63
$EQU LAT$_ITM_CTPRT_BYTT     64
$EQU LAT$_ITM_CTPRT_LCL     122
$EQU LAT$_ITM_CTPRT_SLCA    123
$EQU LAT$_ITM_CTPRT_SLCR    124
$EQU LAT$_ITM_CTPRT_ISOLA   125
$EQU LAT$_ITM_CTPRT_ISOLR   126
$EQU LAT$_ITM_PASSWORD      127
$EQU LAT$_ITM_CTPRT_FRAMERR 159
$EQU LAT$_ITM_CTPRT_PARERR  160
$EQU LAT$_ITM_CTPRT_OVERRUN 161
$EQU LAT$_ITM_PASSWORD_FAILURES 165

The fact that there are jumps in the constant values might lead to the (possibly incorrect) assumption that some were added in later versions of LAT (and that LAT$_ITM_PASSWORD may have subsequently been "corrected" to LAT$_ITM_PASSWORD_FAILURES).

An internet search doesn't throw up any references to the LAT$_ITM_CTPRT_LCL, LAT$_ITM_CTPRT_SLCA, LAT$_ITM_CTPRT_SLCR, LAT$_ITM_CTPRT_ISOLA, LAT$_ITM_CTPRT_ISOLR, LAT$_ITM_CTPRT_FRAMERR, LAT$_ITM_CTPRT_PARERR, LAT$_ITM_CTPRT_OVERRUN and LAT$_ITM_PASSWORD_FAILURES item codes (other than in the I/O User's Reference Manual, or the DEC C/Pascal/Fortan (equivalent to) include files).

1. Does anyone have any knowledge of (or access to LAT source modules that show) whether the counters represented by these 9 item codes are - as the manual suggests - specific to Alpha (and later, I64) systems?
   
   If they are specific to Alpha and I64, it's a small oversight that they are output by LATCP on VAX (I wouldn't expect it to be fixed any time between now and the end of the universe; I'm just saying...)
   
   However, given the apparent mirroring of some counters from MC LANCP SHOW DEVICE /COUNTERS and MC NCP SHOW LINE xxx COUNTERS, it wouldn't surprise me to find that these "PORT" counters are actually being duplicated from a counter block maintained for MC LATCP SHOW NODE /COUNTERS (again, not ideal, and not expected to be fixed;  it's just that it would be useful to know whether they are only ever likely to be non-zero for a port (all ports?) if the corresponding NODE COUNTER also increments to a non-zero value)
   
   
2. The Password Failures counter in the MC LATCP SHOW PORT /COUNTERS output appears to be either an anomaly or only related to setting a LAT port /SERVICE and /DEDICATED or /LIMITED (but is stil output by MC LATCP SHOW PORT /COUNTERS irrespective of whether the port is /SERVICE and /DEDICATED or /LIMITED).
   
   [The System Management Utilities Reference Manual is somewhat devoid of useful examples of setting up LAT ports with /SERVICE, and various attempts at setting this up with a password that was incorrect never resulted in the Password Failures count being incremented]
   
   Does anyone have a suitable working example of setting up such a service (but where site-specific/identifying details can be generalised) and can demonstrate misconfiguration such that the Password Failures counter ends up with a non-zero value)?
   
   
3. If the counters represeted by the 9 item codes are specific to Alpha and I64 (or even if they aren't, and are only relevant to ports with /SERVICE and /DEDICATED or /LIMITED), under what circumstances might they be incremented to a non-zero value (as shown by the sample output in the System Management Utilities Reference Manual)?
   
   
4. On an unrelated note, a comment in some of the original source code that calculates the amount of BYTLM required for a $QIO (invariably to a LAT port) and which makes a deduction of 64, says "see SYSGEN manual on MAXBUF".
   
   I don't have many hard copy manuals any more, and the earliest soft copy manuals I can find online or on an old documentation CD from the condist, only reference SYSGEN in the System Management Utilities Reference Manual.
   
   On page D-27 of the System Parameters appendix of the HP OpenVMS System Management Utilities Reference Manual: M-Z (BA555-90004, JUL-2006), it says:
   
   "MAXBUF sets the maximum allowable size for any single buffered I/O packet.
   
   Buffered I/O packets are allocated from the permanently resident nonpaged dynamic pool. The terminal, mailbox, and printer device drivers are examples of device drivers that perform buffered I/O.
   
   The number of bytes specified in the I/O request plus the size of a driver-dependent and function-dependent header area determine the required buffered I/O packet size. The size of the header area is a minimum of 16 bytes; there is no absolute upper limit. However, this header area is usually a few hundred bytes in size."
   
   The comment possibly dates from as far back as 1986, and although my first employer had "the Gr(e|a)y wall", and an orange wall, my recollection was that the Orange wall was the RSX-11M(+) documentation (we also had PDPs at the time) - though a quick search suggest VMS manuals were originally in Orange.
   
   I've come to the conclusion that the comment probably refers to the minimum size of an IEEE 802.3 Layer-2 frame (not that this is mentioned in the System Management Utilities Reference Manual (or the I/O User's Reference Manual under the LAT Port Driver QIO Interface section)).
   
   Was there ever a manual specifically for SYSGEN (and which might have made reference to this 64 value, - either in the context of LAT specifically, or network QIO in general)?  If so, how far back was this before it got subsumed into the SMURM?

Mark