1 0 Ref. B7 - NCP : EXPERIMENTAL FULL SCREEN TERMINAL SUPPORT (Ref. B7) + ___ ____________ ____ ______ ________ _______ ___ __ 0 Version 3 + _______ _ 0 8 March 1982 + _ _____ ____ 0 P M Girard + _ _ ______ 0 1. VMNCP experimentally supports 3270 protocol (as used for the 3277 model 2) via X29. Only minor further changes should be needed to make it work over TS29 also. Only two or three calls are provided for. If more are attempted, the calls are likely to delay one another as only four 4K buffers are incorporated in the program at present. 0 2. The characters 'XXXF' (in IA5) must appear starting at the 6th byte of the CUDF. The setting of the Identifier byte in the CUDF should be X'01'. 0 3. The software deals with PAD parameters as for the ASCII terminal interface. In practice, neither end at present needs to take any notice of the PAD parameter settings: transparent mode is assumed. 0 4. The unit of data across the CP/CMS to NCP interface may be called a "message". A message may be from 1 to 4096 bytes long. When shipped across the network, the end of a message is indicated by a zero M-bit in the final packet of the message. 0 5. Messages of zero length should not occur, and will be ignored if they do occur. 0 6. The final packet of a message may be of zero length so long as the message as a whole is not of zero length. VMNCP does not in practice send out zero-length packets. 0 7. ASCII is used for shipping messages, in preference to EBCDIC, as the former is likely to be more acceptable if the protocol is to be used eventually in non-IBM environments. 0 8. For an outgoing message from CP/CMS, VMNCP will 'OR' X'30' into the first byte. It will translate the rest of the message into even-parity ASCII using RAL standard table E0AP, except that X'4A' translates to X'FF' and X'6A' translates to X'9F'. 0 9. For an incoming message from the network, VMNCP will translate the whole message to EBCDIC using RAL standard table A2E0, except that X'7F' and X'FF' translate to X'4A', and X'1F' and X'9F' translate to X'6A'. - NCP : EXPERIMENTAL FULL SCREEN TERMINAL SUPPORT PAGE 1 1 0 Ref. B7 0 10. If CP/CMS has a READ BUFFER pending, a message from the network is assumed to be the expected 'buffer', and the data bit is set in the appropriate register. If no READ BUFFER is pending, the message is assumed to be appropriate for a READ MODIFIED. 0 11. If CP rejects an incoming message with cc=2, rc=3 or 4 (i.e: wrong type of input), the message is discarded. 0 12. If CP rejects an incoming message with cc=2, rc=1, VMNCP will try to input the message again as soon as a successful ACCEPT from CP has occurred. 0 13. If CP rejects an incoming message with cc=2, rc=2, VMNCP will try again when CP sends a READ BUFFER or READ MODIFIED interrupt signal. 0 14. The network call will be cleared 5 seconds after the user inputs a LOGOFF or DISCONNECT message, or if it times out. - - - - - - - - - - - - 0 NCP : EXPERIMENTAL FULL SCREEN TERMINAL SUPPORT PAGE 2