KERMIT-370 4.3 RELEASE NOTES, 2000 August 15 Kermit-370 4.3 has been tested under MVS/TSO, VM/CMS, MUSIC/SP, CICS, and ROSCOE at various sites. See the end of this file for a list of Kermit files relevant to the several variants of Kermit-370. Success has been reported with the following front ends and protocol converters. Note that some names are given with one or more lower case x's to stand for a series of similar models with various numbers replacing the x's. Name, model Type Manufacturer Notes ----------------- ---- ------------------------- ----- Amdahl 4705 T Amdahl (2) Cisco 516-CS,etc S Cisco (17) Comten 36xx T NCR Comten IPC T,F " (18,19) Cx-80 S Commtex (1,10) Datastar 4025 G AIS Systems Datalynx 3174 G Andrew Data Systems (3) Datalynx 3274 G " (3) Hydra II S JDS (1) IBM 3174 AEA A,F IBM (6,18) IBM 37x5 T " (2) IBM 3708 T,F " (18,20) IBM 4994 S " IBM 7171 S " (12) IBM 8232 T,S " (2) IBM 937x ASCII S " IBM Series/1 S " Jupiter 1000 T Intel (14) K200 T,S Fibronics (2,14) K310 T,S " (2,14) K2000 T,S " (2,14) KMW S/II 3270 G Andrew Data Systems (16) Leedata 8010 G Lee Data Corp (9,15) Leedata 8030 G " (9,15) Leedata 874 G " (9,15) Micom 7400 F Micom (7,18) PCI 1076 G Protocol Computers Inc PCI 276 G " (5) Renex PCM G Renex Corp (8) Renex RPAD G " (8) Renex RTD G " (8) Renex TMS-x G " (8) SIM3278/TCPIP S Simware (1,4) SIM3278/VM S " (1,4) SIM3278/VTAM F " (4,18) STNxx T,F STRTC (13,18) tn3270 (Unix) S,F Greg Minshall (1,2,11,18) Xyplex MAX 1000 F Xyplex, Inc. (11,18) Here is the same list of front ends by controller type: TTY ------ Amdahl 4705; IBM 37x5, 3708, or 8232; Comten 36xx; STNxx; Jupiter 1000; K200, K310, or K2000. SERIES1 -- Yale ASCII system on IBM Series/1 or 4994; IBM 7171 or 937x ASCII subsystem; Hydra II; Commtex Cx-80; SIM3278/TCPIP 2.0 or /VM 5.0; tn3270; Cisco 516-CS. GRAPHICS - Datalynx 3174 or 3274; Datastar 4025; Datastream/Leedata 8010, 8030, or 874; PCI 1076 or 276; Renex PCM, TMS-x, RPAD, or RTD; KMW S/II 3270. AEA ------ IBM 3174 AEA (B2 or higher). FULLSCREEN IBM 3174 AEA (any); IBM 3708; Micom 7400; Sim3278/VTAM; STNxx; tn3270; Xyplex TS. Kermit-370 should work with any protocol converter that supports some kind of "transparent mode" or "passthrough mode". Sometimes this goes by the name "graphics mode". At present, three types of transparency are supported: Yale ASCII ("Series1"), SAS transparency ("Graphics"), and IBM ASCII Graphics ("AEA"). The names in parentheses are the ones used by Kermit itself and correspond to the entries under "type" in the table above. Kermit-370 attempts to discover what kind of protocol converter it's going through, but the attempt may cause problems in certain environments (particularly in VTAM). In that case, the diagnostic code may have to be disabled, and one particular type can be made the default. If other types are sometimes used, the user can issue a SET CONTROLLER subcommand to Kermit-370 as needed. See the BWR files for more details. There is also a non-transparent mode supported by Kermit-370 (called FULLSCREEN), which should work with almost any kind of protocol converter, but only in combination with another Kermit that allows the Start-of-Packet character to be printable. At present, the only such Kermits are MS-Kermit (3.12 BETA before Sep 25 or 3.13 or higher) and C-Kermit (5A.180 or higher). FULLSCREEN mode is less efficient and less robust than the other modes and should not be used unless the others are not possible. Rules of thumb for deducing the controller type by reading the manual (in order of simplicity and likelihood): a) GRAPHICS or SERIES1 is implied if there is a transparent mode compatible with that of one of the devices listed above. b) SERIES1 is implied when the box runs the "Yale ASCII Communication System" or something similar. c) GRAPHICS is implied if the manual refers to the SAS Institute in connection with ASCII graphics. d) GRAPHICS is implied when transparent data may be preceded by a WCC and 70 (hex). e) SERIES1 is implied when transparent data must be preceded by a WCC and either 115D7F110005 (write-read) or 115D7F110000 (write-only). f) GRAPHICS or SERIES1 may be implied when the manufacturer is listed in the table above with only that type of controller (unless there are also counter-examples in the "failure" table below). g) FULLSCREEN may be tried for any full-screen terminal controller if all else fails. Certain models are known not to work with Kermit-370, except in FULLSCREEN mode. These include: All real 3270-type terminals (for obvious reasons). Most PC boards that attach to co-ax cable, like the Irma board or the IBM PC 3270 emulation board. However, it should be possible to write a packet driver for MS-Kermit to work in such cases. Adacom (model unknown) (18) ASM/3 w/ TS3-R 8.3.1 Cisco (17,18) DECServer 200 TS DEC Hydra/SNA JDS (18) Notes: 1) Some devices provide support for SERIES1 Kermit operation, but are seen by Kermit as GRAPHICS devices. The controller type must be set to SERIES1 by hand for transfers to work. Alternatively, if the only devices in use for file transfer are SERIES1-type, Kermit can be modified to assume SERIES1 (see the BWR file). These devices include the Cx-80, Hydra II, and tn3270. The Sim3278 family also once were like this, but that limitation has been removed for SIM3278/VM. 2) Some front ends (such as the IBM 3725) can be used for connecting other controllers to the mainframe. In such cases, the lower-level controller (typically a protocol converter) determines the setting required by Kermit. The IBM 8232 with TCP/IP software is a special example of this -- it allows TTY Kermit operation for linemode Telnet sessions from ASCII hosts and also SERIES1 or GRAPHICS (or even AEA) operation for full-screen Telnet sessions where the appropriate controller is attached to the originating host (or emulated, as in the case of tn3270). The Fibronics network boxes with KNET software are similar. 3) Reports are mixed or inconclusive. Anyone with information about these devices is urged to send it in. 4) Simware's SIM3278 product has been rumored for several years to have an upgrade in the works to correct the incompatible "simulation" of Yale ASCII transparent mode. A new product in this line, namely, SIM3278/TCPIP 2.0, has now come out and reportedly corrects the problem (it must be installed along with IBM's TCP/IP software). In addition, the latest release (5.0) of SIM3278/VM has the same fix and is also now sensed by Kermit as a SERIES1-type device automatically. SIM3278/TCPIP is not properly sensed; also, after an upload, it (but not SIM3278/VM) leaves Kermit-370 waiting for a screen interrupt, which the user must supply by hitting ENTER. Fixes for this problem have been promised. SIM3278/VTAM (as of version 5.11) still does not support the Yale ASCII transparent mode. 5) Some PCI protocol converters require the updates that were issued in November 1988 -- in particular, if attached through VTAM, the PCI 276 apparently does not respond correctly without an explicit command to "unlock the keyboard" as part of the transparent I/O request. 6) The IBM 3174 supports transparent communication only with B2 (or higher) microcode and only for terminal types specifically defined to have "graphics" capability. The built-in set of terminal types includes only two with that capability: VT241 and Tektronix 4205. However, user-defined types can be added. File transfers are not allowed for lines with Host Addressible Printers. Also, if the 3174 is owned by VTAM, and the connection is made with a logmode that forbids the Read Partition Query (such as M2SDLCNQ), Kermit cannot detect the AEA and will default to CONTROLLER GRAPHICS (and, incidentally, cannot transfer files, even with CONTROLLER set to AEA by hand). M2SDLCQ is known to allow correct operation, but other logmodes have not been tested. Basically, the PSERVIC definition must have the 80-bit set in its second byte. The 3174 supports full 8-bit transparent communication. 7) The Micom 7400 was formerly rumored to allow Kermit file transfer in GRAPHICS mode, but the rumor was unfounded. A small modification to Kermit is necessary to support the 7400 for FULLSCREEN mode. See update SC92101 in the appropriate BWR file. Typical ETOA settings required are 74-91, 79-93, and 106-124. 8) Renex protocol converters have a problem in BSC mode: they are not completely transparent and may respond to ASCII data bytes as if they were EBCDIC control characters. Reportedly, the TMS-3 has solved this problem. Generally, type-ahead must be turned off to allow Kermit to work, and graphics pass-thru must be enabled. Also, starting a transfer may hang your session if you have connected in the wrong parity. This depends on the Renex configuration. 9) Leedata is the new name for Datastream. Leedata boxes may need three separate flags set in their configurations to support Kermit: "file transfer", "transparent async", and "ASCII graphics". 10) The Cx-80 requires that all ASCII data have the high bit set on output. Early releases of the emulation software for the Cx-80 were unable to support Kermit transfers, but versions 5.04 and higher are known to work. Even so, the Cx-80 has a small input buffer, and the inbound packet size should be limited to about 128. Long outbound packets seem to be no problem. There is another problem with the Cx-80 -- it echoes inbound packets. Therefore, the start-of-packet character should be different for send and receive. 11) Warning: tn3270 seems unable to support uploads using packets longer than about 256. Also, although the original tn3270 program supports SERIES1-style file transfer, there are a growing number of other programs and communications packages that offer something called a TN3270 option, and many of these do not support SERIES1 mode. In such circumstances, FULLSCREEN mode may be the only choice, and it requires a modification to Kermit (see SC92101 in the appropriate BWR file). The supplier of any such "crippled" TN3270 application should be told that a complete TN3270 implementation includes the Yale ASCII transparency feature. 12) There is an EC, A31860, for the 7171 that is needed for transfers at high speeds (above 9600). It is extensive, so it may be difficult to convince IBM that the EC is truly necessary at your site. The symptom of failure is loss of data from the ends of incoming packets, apparently independent of packet size. 13) STRTC markets a network product which offers both full-screen and line-mode virtual terminal sessions. Input characters are normally echoed by the network, rather than locally, but echoing can be suppressed if necessary. For FULLSCREEN mode, it may be necessary to enable flow control on both the network and the micro. 14) This front end reportedly supports full 8-bit E-to-A conversion for linemode sessions, provided the appropriate software is loaded: PACKET/74 for the Intel boxes and KNET/MVS for Fibronics. 15) The Leedata 8030 (and possibly other Leedata models) may have a bug in the handling of SNA/SDLC pacing. If you are unable to get file transfers going, it may be necessary to turn off pacing both in the NCP and the Leedata box and also to configure the VTAM logmode to avoid pacing. Lee Data is reportedly working on the problem. 16) The KMW S/II 3270 requires that all ASCII data have the high bit set on output. It is possible to configure the KMW so that this MARK parity passes through to the terminal or, alternatively, is changed to SPACE parity. 256 is about the largest inbound packet size this device will accept reliably. 17) Cisco has added support for transparent mode, available in release 8.3(3.3) or higher. With 10.3 (available 1Q 95) or higher, it also permits auto-detection by Kermit of the controller type, and it allows packets up to a screenful. 18) FULLSCREEN mode is never selected automatically. It must be chosen by hand and properly set up on both Kermits. See the appropriate installation guide (file type INS) for details. Protocol converters known not to support Kermit in other modes are presumed to do so in FULLSCREEN mode, but those listed on the "failure" list above have not been confirmed. 19) Typical ETOA setting required are 74 91, 79 93, and 106 124. For FULLSCREEN mode: there may be problems in uploading without flow control, but setting the packet size to 60 in Kermit-370 seems to avoid them. Use 61 as the packet character. Also, toggle the "Display X system" switch (by typing ctrl-A V). 20) The "standard" character translation in the 3708 requires these ETOA settings: 74 91, 79 33, 90 93, and 106 124. However, there is also an "alternative" character set that requires no such translations. It may be necessary to set SEND PAUSE on the micro for FULLSCREEN mode. Models not mentioned above may or may not work with Kermit; we just have not had any feedback about them. Kermit-370 operation also depends on the system level. Success has been reported for CMS releases 3 through 14 (including 5.5 and 5.6) under the corresponding releases of VM/SP, VM/HPO, VM/IS, VM/XA/SP or VM/ESA; for MUSIC/SP releases 1.2 to 3.1; for TSO/E releases through 2.2 under MVS releases through 3.8; for CICS 1.6 to 3.3 under both MVS and VSE; and for ROSCOE through 5.7. MVS/XA, MVS/ESA, and MVS/OS390 seem to support Kermit under TSO/E just as well as MVS/SP. As each new system release comes out, Kermit is generally found to work under the new release, but that fact may not be reported immediately. In the meantime, Kermit should be presumed innocent until proven guilty. Failure has been reported under the obsolete VM/370 (pre-BSEPP) and "free" TSO, though fixes may be possible. The version for bimodal CMS under VM/XA and VM/ESA is available automatically where appropriate. In addition, operation depends on the type of connection between the front end and the terminal. Direct connection, of course, is the simplest and the least likely to have problems. VTAM, although it has a few sticky points as noted above, is also capable of carrying Kermit file transfers routinely. Troubles may arise, however, with packet- switching data networks, some of which may not support Kermit transfers at all. Reports indicate that Telenet and Datapac/Inet are both able to carry Kermit transfers between micros and protocol-converter front ends, at least. Tymnet, on the other hand, seems to have problems. Since sources are provided, users are encouraged to make fixes, add support for additional protocol converters, and send their work back to us for further distribution. Refer to IK0CON.HLP for notes on adding support for new controller types. Refer to IK0POR.HLP for notes on porting Kermit-370 to other operating systems. INSTALLATION Kermit-370 version 4.3 may be installed on CMS, MVS/TSO, MUSIC/SP, CICS (either MVS or VSE), or ROSCOE ETSO systems. Future releases may add support for other IBM 370 operating systems, such as MTS. All releases from 4.0 on are characterized by level numbers, which should be reported when describing the exact version in use. The current versions are 4.3.2 or 4.3.2 XA for CMS, 4.3.3 for TSO, 4.3.2 for MUSIC, 4.3.2 for CICS, and 4.3.3 ROS for ROSCOE. These level numbers will be found, not in the base source modules, but in the update files that accompany the sources. Kermit-370 consists of a system-independent (generic) part, common to all implementations, and a system-specific part for each system. These files are named as follows: IK0*.* The system-independent portions (all implementations). IKC*.* The CMS-specific portions. IKM*.* The MUSIC-specific portions. IKR*.* The ROSCOE-specific supplement to the TSO portions. IKT*.* The TSO-specific portions. IKX*.* The CICS-specific portions. Installation instructions may be found in the following files: CICS: IKXKER.INS and IKXKER.BWR CMS: IKCKER INS and IKCKER BWR MUSIC/SP: IKMKER.INS and IKMKER.BWR MVS/TSO: IKTKER.INS and IKTKER.BWR ROSCOE: IKTKER.INS, IKTKER.BWR, and IKRKER.BWR Please read the appropriate files before proceeding.