🚀 go-pugleaf

>Okay, I give up. Is there an IBM publication, formal or otherwise,
>that actually defines the PU2.1 <- (NOT PU2.0!!!) local channel
>protocol, including ___XID___ negotiation?
>
>I have enough references, mostly contradictory, that such a protocol
>exists and that it is different from the PU2.0 (AKA 3274-1a) protocol.
>
>And while we are on the subject. The IBM publication "Type 2.1 Node
>Reference" rather clearly states that all 2.1 nodes support XID
>format three (3) while the IBM publication "Network Product Formats"
>rather clearly states that a channel 2.1 link uses XID format two (2).
>(But then again consistency is the hallmark of little minds.)

There is one "SNA Channel Protocol" consisting of specific channel
commands (READ START 0, READ START 1) used by 3174 and 37x5 devices.
This defines a physical link layer.  There is no specific PU type
interaction with this protocol.  Clearly the NCP sends along all sorts
of PU and LU traffic over the one channel address.

The 3174 gateway has traditionally provided only PU 2.0 services and
gateway function.  This has been based on the limitation that it did
not use a Format 3 XID when it contacted the host.  The most important
effect of this is that LU 6.2 applications in nodes running through
a 3174-xxL gateway must be dependent logical units.

RPQ 8Q0800 overcomes this limitation and allows the local gateway to
generate a Format 3 XID.  This allows downstream PUs to be PU 2.1 and
to have independent logical units.  Nothing other than the XID format
changes.  The channel protocol remains the same in all other regards.

PU 2.0 function is a subset of PU 2.1 function.  At XID time the two
nodes determine each others capability and software level.  The
PC may have PU 2.1 capability, but if it connects to an upstream
node that does not support it (3174 gateway without the RPQ, NCP at
a software level earlier than that for VTAM 3.2) then it falls back on
PU 2.0 subset behavior.