Constraints on interaction

1. The general picture. The following diagram depicts the relationship between the various BCOM parameters (MAXBLK and WINDCNT) and SNA control blocks (BIUs and PIUs). In this example, the Windows Count is set at 4.
   
   
   
2. BCOM and Chaining. BCOM uses Chaining to implement its own window protocol. This Chaining scheme is different from IBM's native LU 6.2 Chaining scheme but uses the same Chaining indicators in the RH. To prevent interference between BCOM Chaining and LU 6.2 Chaining, a basic rule has to be followed:
   
   "THE BCOM BUFFER SIZE (MAXBLK) MUST ALWAYS BE LESS THAN OR EQUAL TO THE RU SIZE"
   
   The size of the Request Unit (RUSIZE) is governed by the Mode Table used in the BIND when the session is established. The Mode Table specifies both the maximum Send RU Size and the Receive RU Size.
   
   On MVS platforms, the BIND Image is built dynamically by BCOM and has precedence over the value in the Mode Table. BCOM for MVS takes care of ensuring that the RU Sizes are set properly according to the MAXBLK parameter.
3. BCOM and Segmentation. Segmentation is transparent to BCOM's operation. Segmentation takes place at the PIU level. In the above diagram, the mention fs, ms and ls refer to first segment, middle segment and last segment, respectively.
4. BCOM and Pacing. BCOM's operation is independent of the setting of the PACING VPACING parameters in terms of functionality. But there are performance impacts. It is important that SNA's pacing and BCOM's windowing, which are both windowing protocols do not interfere one with another. We thus recommend that both PACING and VPACING be set to zero (0).
5. BCOM and the GDS. BCOM is a LU 6.2 application and as such uses Generalized Data Stream (GDS) variables to carry data from one BCOM node to the other. The block size you specify in the MAXBLK parameter includes a 4-byte header (2 bytes length indicator, followed by the GDS Id X'12FF', which means "Application Data"). You should never worry about GDS except when you connect either MVS or NSK Guardian to Windows NT through Microsoft SNA Server. Because SNA Server performs GDS Segmentation, 2 bytes of overhead (additional length indicators) must be accounted for each 4K of data. The following diagram shows the format for each 4K of data. The following diagram shows the format:
   
   

When the high bit of the LL field is on, it is an indication that the GDS data is segmented and that additional LL field(s) will follow.