KERMIT-370 4.2 RELEASE NOTES, 1993 May 10
 
Kermit-370 4.2 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                     (11,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
assumed.  If that doesn't work, the user can issue a SET CONTROLLER
subcommand to Kermit-370 as needed.  See the BWR file 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 earlier than September 25) and C-Kermit
(5A.180 or higher).  FULLSCREEN mode is less efficient and 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.  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 setting
   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 informed that a complete tn3270 implementation should
    include 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.  Like other tn3270-based products, however, it
    does not permit auto-detection by Kermit of the controller type, and
    it imposes a restriction on packet size.  There is an effort under
    way to add support for auto-detection.
 
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 8 (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 2.3; for TSO/E releases through 2.1 under MVS
releases through 3.1; for CICS 1.6 to 2.1 under both MVS and VSE; and
for ROSCOE through 5.7.  MVS/XA and MVS/ESA 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 for
VM/370 (pre-BSEPP) and "free" TSO, but fixes may be possible.  The only
other known likely failure is under CICS 3, which is not yet widely
used.  The version for bimodal CMS under VM/XA and VM/ESA is available
in the form of an extra update file to be applied with the normal CMS
Kermit updates.
 
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.2 may be installed on CMS, MVS/TSO, MUSIC/SP, CICS
(either MVS or VSE), or ROSCOE ETSO systems.  Future releases may
include support for other IBM 370 operating systems such as DOS-4, MTS,
etc.  Release 4.2 is characterized by edit or level numbers, which
should be reported when describing the exact version in use.  The
current versions are 4.2.5 or 4.2.5 XA for CMS, 4.2.4 for TSO, 4.2.3 for
MUSIC, 4.2.4 for CICS, and 4.2.4 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.
