IK0423.HLP                                            92/10/29
 
                Notes for Kermit-370 4.2.3 and 4.2.4
 
Changes in the installation procedure for version 4.2.3:
 
- For CMS only - two new CNTRL files are available (KERMCMS6 and
  KERMESA) for conveniently including SFS support.  Also, there is a
  new all-in-one installation EXEC -- see IKCKER INS.
 
- In general - (this is optional).  Kermit-370 now is able to translate
  between Japanese EUC and three proprietary storage formats for Kanji
  text (Fujitsu, Hitachi, and IBM).  The translation, however, requires
  a large table which now becomes the tenth component of the Kermit
  source (to be inserted just before IK0PRO).  The code has been
  arranged so that it can still be assembled without the new IK0KAN.ASM
  component.  If you wish to be able to transfer Kanji text files, you
  must obtain IK0KAN.ASM and include it in the base Kermit source (2nd
  from the end).  The various installation guides IK*.INS have been
  updated appropriately.
 
- Note: for some of the new features in Kermit-370 version 4.2.3, it is
  necessary to have a corresponding upgrade of the other Kermit.  In
  particular, support for Kanji text files, the new locking shift
  protocol, and the new FULLSCREEN mode depend on such an upgrade.
  Currently, the sufficient implementations are MS-Kermit 3.12 BETA and
  C-Kermit 5A(180) or higher.  Any of the beta releases of MS-Kermit
  3.12 with dates between March 15 and September 20 will serve "as is",
  but later versions, including the production version, do not support
  FULLSCREEN mode.
 
                   KERMAIL, KERMPRT, and KERMSUB
 
The syntax of the first call to these auxilliary commands has been
changed to include a "dummy" filespec consisting of a period instead
of none at all.  Sample commands are now included with the CMS and TSO
distribution (ikcaux.cmd and iktaux.cmd, respectively).
 
                     Kanji text file support
 
Kanji text differs from other kinds of text files in that it has *two*
different character sets associated with it, one single-byte (SBCS) and
one double-byte (DBCS).  Thus, it may be necessary to specify the
subcommand SET FILE CHARACTER-SET twice, once for the SBCS and once for
the DBCS.  For example, SET FILE CHAR CP290 and SET FILE CHAR FUJITSU
would select one possible SBCS (CP290) along with the Fujitsu DBCS.
Other possible SBCS's are CP281, CP500, and H-EBCDIK-DASH.  Plain
"EBCDIC" is not currently allowed in combination with Kanji.  It is
important to specify the SBCS first; a SBCS can be used alone and always
overrides whatever character set was previously selected, but a DBCS
must always be used with a SBCS and so "merges," if possible, with the
SBCS already in effect.  Note: the chosen SBCS may result in EBCDIC/
ASCII translations that differ from those performed by the front end
(for non-transparent modes) -- in that case, it is necessary to SET
TTABLE ON in order to transfer files.
 
The choices for DBCS are IBM-KANJI, FUJITSU-KANJI, HITACHI-KANJI, and
KANJI.  The latter is taken to be a synonym for one of the others (by
default, IBM, but it is simple to change that default -- see the BWR
files).  When a text file is uploaded using the Japanese EUC encoding,
or when the user types SET TRANSFER CHAR JAPAN-EUC, if none of the three
Kanji character sets is already selected, the default KANJI DBCS is
chosen along with an appropriate (but not necessarily the "correct")
SBCS.
 
                  The new FULLSCREEN transfer mode
 
In the past, Kermit was not usable with certain communications front
ends, such as SIM3278/VTAM, the IBM 3708 in full-screen mode, and the
MICOM 7400, all of which lack a working transparent mode suitable for
Kermit protocol.  However, the new FULLSCREEN mode for Kermit-370 allows
file transfers without control characters and, therefore, without a
transparent mode.  The new mode entails one protocol change to allow
printable characters to synchronize packets and another to avoid strings
of repeated blanks; thus, only a suitably upgraded micro Kermit can be
used (currently, only MS-Kermit 3.12 and C-Kermit 5A.180).  The C-based
micro Kermits have not all been upgraded to level 5A.180.  In principle,
FULLSCREEN mode could be used with almost any protocol converter, but
the printable packet characters and other restrictions on this mode make
it less robust and slower than a transparent mode would be; so,
FULLSCREEN mode is recommended primarily as a last resort.
 
The basic setup consists of the following Kermit subcommands:
 
     -----Mainframe-----             ----------PC--------
     SET CONTROLLER FULL             SET SEND START 62
     SET RECEIVE START 62            SET RECEIVE START 62
     SET SEND START 62               SET BLOCK B
     SET BLOCK B                     SET HANDSHAKE NONE
     SET HANDSHAKE 0
 
Possible variations:
 
- The choice of 62 (Greater-than sign) for the start-of-packet character
  is arbitrary, and it can be changed, as long as you change all four of
  them.  For best results, choose a character that seldom appears in the
  files you will be transferring.
 
- Packet sizes are automatically restricted by Kermit-370 in this mode,
  so they need not be set explicitly unless conditions require packets
  shorter than the default (77).
 
- Flow control is probably immaterial for locally connected terminals,
  but some protocol converters may require it to keep up with the data
  rate on uploads.
 
- The parity settings in the mainframe Kermit are ignored in this mode,
  and those in MS-Kermit should be the usual.
 
- Setting the block check to "B" (yes, "B") is important on certain
  protocol converters because it avoids problems with "optimization" of
  outbound strings of repeated blanks.  However, it is not generally
  necessary, and a setting of "1" will normally suffice and will avoid
  certain other problems that can occur when an inbound initialization
  packet has a blank checksum.
 
Warnings:
 
FULLSCREEN mode depends on the ability of the protocol converter to
buffer the traffic on the line, since there is no universal method of
synchronization between sending and receiving.  Problems may occur if
this buffering is inadequate.
 
- If the protocol converter has a buffer significantly shorter than 80
  bytes, it will be necessary to shorten inbound packets accordingly (by
  issuing a SET REC PACK to K-370).  The symptoms of a short buffer are
  fairly obvious -- the log of packets on the mainframe side will show an
  inbound packet that has been truncated and concatenated with a second
  copy of the same packet; the micro log will show a truncated echo of
  the inbound packet and then a timeout.
 
- It may be possible to avoid shortening the packets if the protocol
  converter can do flow control.  Just turn on flow control in the micro
  Kermit as well as the controller.
 
- If the mainframe packet log shows inbound packets losing the leading,
  rather than trailing, characters, and the micro shows the same problem
  with echoed packets, the trouble may be a "dead" time in the protocol
  converter between send and receive states -- the solution may be to set
  a pause in the micro Kermit before sending each packet.
 
- See the Kermit distribution file ik0aaa.hlp for details about specific
  protocol converters.
 
                          Other Features
 
See the respective announcement files (ik*.ann) for further details.
