markr@seqp4.ORG (Mark Roddy) (06/02/91)
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. Please mail me a clue. 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.) -- -Mark Roddy Sequoia Systems, Inc. (508) 480-0800 x1284 markr@seqp4.sequoia.com m2c!seqp4!markr
hank@bitnic.BITNET (06/02/91)
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. Please mail me a clue. 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.) -- -Mark Roddy Sequoia Systems, Inc. (508) 480-0800 x1284 markr@seqp4.sequoia.com m2c!seqp4!markr
GILBERT@YALEVM.BITNET (Howard Gilbert) (06/03/91)
>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.
dls@achilleus.austin.ibm.com (David Skeen) (06/04/91)
Between the Type 2.1 Node Reference and Network Product Formats, you probably have all the available info for type 2.1 local channel protocol. In general, type 2.1 nodes "discover" each other by XID3 exchange. VTAM system definition for the PU will say "TYPE=2,XID=YES". VTAM will send a null XID; if it sees in response XID0 or XID1, it assumes the node is type 2.0; if it sees in response null XID or XID3, it assumes the node is type 2.1. > the IBM publication "Network Product Formats" > rather clearly states that a channel 2.1 link uses XID format two (2). I don't see this in my June '89 copy. If you look near the end of the description of XID3, you'll see that there are two DLC-dependent sections defined--one for SDLC (also used for Token Ring and X.25), the other for Channel DLC. My copy says this CDLC section is for communication "between T4 and T2.1 nodes", but that's not terribly accurate. In fact, when NCP or VTAM communicates with a T2.1 node, they assume the identity of a T2.1 node. There is no T4-T2.1 nor T5-T2.1 protocol defined, only T2.1-T2.1. -- Dave Skeen IBM Internal: dls@achilleus.austin.ibm.com D61/803 Zip 2603 IBM VNET: SKEEN at AUSTIN Austin, TX 78758 Internet: dls@dce.austin.ibm.com
hank@bitnic.BITNET (06/04/91)
Between the Type 2.1 Node Reference and Network Product Formats, you probably have all the available info for type 2.1 local channel protocol. In general, type 2.1 nodes "discover" each other by XID3 exchange. VTAM system definition for the PU will say "TYPE=2,XID=YES". VTAM will send a null XID; if it sees in response XID0 or XID1, it assumes the node is type 2.0; if it sees in response null XID or XID3, it assumes the node is type 2.1. > the IBM publication "Network Product Formats" > rather clearly states that a channel 2.1 link uses XID format two (2). I don't see this in my June '89 copy. If you look near the end of the description of XID3, you'll see that there are two DLC-dependent sections defined--one for SDLC (also used for Token Ring and X.25), the other for Channel DLC. My copy says this CDLC section is for communication "between T4 and T2.1 nodes", but that's not terribly accurate. In fact, when NCP or VTAM communicates with a T2.1 node, they assume the identity of a T2.1 node. There is no T4-T2.1 nor T5-T2.1 protocol defined, only T2.1-T2.1. -- Dave Skeen IBM Internal: dls@achilleus.austin.ibm.com D61/803 Zip 2603 IBM VNET: SKEEN at AUSTIN Austin, TX 78758 Internet: dls@dce.austin.ibm.com
lstowell@pyrnova.pyramid.com (Lon Stowell) (06/05/91)
In article <9106041523.AA03448@lilac.berkeley.edu> BITNIC IBM-NETS List <IBM-NETS%BITNIC.BITNET@lilac.berkeley.edu> writes: > >I don't see this in my June '89 copy. If you look near the end of the >description of XID3, you'll see that there are two DLC-dependent >sections defined--one for SDLC (also used for Token Ring and X.25), the >other for Channel DLC. My copy says this CDLC section is for >communication "between T4 and T2.1 nodes", but that's not terribly >accurate. In fact, when NCP or VTAM communicates with a T2.1 node, they >assume the identity of a T2.1 node. There is no T4-T2.1 nor T5-T2.1 >protocol defined, only T2.1-T2.1. What revision of VTAM is required in order for it to support 2.1 Node (XID-3) attachment on the channel? Is this available with V3R2 or must one upgrade? (I have seen claims that even with V3R2 channel attached LU 6.2's must still be dependent...i.e. the node is a 2.0...)
dls@achilleus.austin.ibm.com (David Skeen) (06/05/91)
I know this is available in VM/VTAM V3R3; the corresponding VSE release may be V4R1, I can't remember now. I don't believe you can get direct VTAM attachment to type 2.1 without V3R3, but you should ask your marketing rep for the official word. -- Dave Skeen IBM Internal: dls@achilleus.austin.ibm.com D61/803 Zip 2603 IBM VNET: SKEEN at AUSTIN Austin, TX 78758 Internet: dls@dce.austin.ibm.com