Columbia Kermit/kermit.zip/e/v12.3

Text File | 2020-01-01 | 30KB | 631 lines

28-Aug-90 20:18:09-GMT,29601;000000000001
Return-Path: <cmg>
Received: by watsun.cc.columbia.edu (5.59/FCB)
    id AA28887; Tue, 28 Aug 90 16:03:24 EDT
Date: Tue, 28 Aug 90 16:03:23 EDT
From: Christine M Gianone <[e-mail]>
To: Info-Kermit
Subject: Info-Kermit Digest V12 #3
Reply-To: [e-mail]
Queries-To: [e-mail]
Message-Id: <[e-mail]>

Info-Kermit Digest         Tue, 28 Aug 1990        Volume 12 : Number 3

Today's Topics:

         Duplicate Copies of Info-Kermit Digest V12 #1 and #2
         Proposed Kermit Extension for SET FILE TYPE
          And ANOTHER New Test Release of MS-DOS Kermit 3.02
        A New Version of Kermit for OS/2 Presentation Manager
               New Release UCPECAN Kermit V1.1
             MS-Kermit 3.0x and German telephones
                 Looking for Stories


Digest submissions may be sent to [e-mail],
requests for addition to or deletion from the Info-Kermit subscriber list to
[e-mail] or to [e-mail].

Kermit files may be obtained over networks and by mail order.  On the
Internetwork, use FTP to log in to host WATSUN.CC.COLUMBIA.EDU, a SUN-4/280
running UNIX (SUNOS 4.1), IP host number 128.59.39.2.  Login as user anonymous
(note, lower case), any password, and GET or MGET (MULTIPLE GET) the desired
files.  The Kermit files are in directories kermit/a, kermit/b, kermit/c,
kermit/d, and kermit/e.  Test versions are in kermit/test.  Binaries are in
kermit/bin (use ftp in binary mode).  You can also get Kermit files over the
BITNET/EARN network; to get started send a message with text HELP to KERMSRV,
the Kermit file server, at host CUVMA.  For detailed instructions, read the
file kermit/a/aanetw.hlp (AANETW.HLP on KERMSRV).  To order by mail, request a
complete list of Kermit versions and an order form from Kermit Distribution,
Columbia University Center for Computing Activities, 612 West 115th Street,
New York, NY 10025 USA.

----------------------------------------------------------------------

Date: Tue Aug 28 17:44:54 1990-EDT
From: Christine M Gianone <[e-mail]>
Subject: Duplicate Copies of Info-Kermit Digest V12 #1 and #2

Please disregard any duplicate copies of recent Info-Kermit
Digests.

------------------------------

Date: Thu Aug 16 17:44:54 1990-EDT
From: Christine M Gianone <[e-mail]>
Subject: Proposed Kermit Extension for SET FILE TYPE
Keywords: Kermit Protocol, Labeled File Type

Kermit programs presently differentiate between text and binary files via
the SET FILE TYPE command.  When the file type is TEXT, the Kermit program
that is sending the file converts the file's record format and character set
from its local form to a standard form, and the receiving Kermit program
converts from the standard form into its own local record format and character
set.  When the file type is BINARY, the file is sent as-is, byte for byte.

These two ways of handling files are sufficient in many cases, but fall short
when one or both computers has a complex file system, such as the Macintosh or
DEC operating systems like VAX/VMS.  The Kermit protocol includes a mechanism
for transmitting a file's attributes in a generic way, but these attributes
are of little use when the file is being received by a computer with a simple
file system, such as UNIX or MS-DOS, that can't do anything with them.  And
they are not sufficient to convey every conceivable bit of information about
about every kind of file on every kind of computer.

To allow a complicated file to be transferred, a new file type is proposed:

  SET FILE TYPE LABELED

Notice the spelling of "LABELED" (only one L between the E's).  When this
setting is in effect, the sending Kermit sends not only the file's data, but
also system-dependent structural information about the file.  Since this
information can be quite lengthy, it is sent as if it were file data, in data
packets preceding the actual file data, rather than in attribute packets.  All
of this information is sent in binary mode (no conversions).

The receiver of the file can elect whether to act upon the label information,
or simply store it.  Kermit programs for simple file systems need no changes,
and can still act as repositories for labeled files, to be sent back later to
the system of origin.  On the other hand, labeled file transfers between like
systems (e.g. two VAX/VMS computers) will result in the reception of a file
with all the correct characteristics.

There are two possible modes of operation.  The first (and safer) mode
requires human intervention on a per-file basis, but an automatic mode is also
possible.

DEFINITIONS

A "bare" file is a file stored on disk that does NOT contain, as part of
its contents, Kermit-constructed label information.

A "labeled" file is a file stored on disk whose contents include
Kermit-constructed label information.

FORMAT OF A LABELED FILE

This description applies to a labeled file as stored on disk and to a bare
file that has label information added to it by a sending Kermit.

  BANNER  The literal text string "KERMIT LABELED FILE:", just the twenty
          characters within the quotes including the trailing colon, in 7-bit
          ASCII.  ASCII is used even on non-ASCII systems (like IBM mainframes
          with EBCDIC).

  IDLEN   A 2-byte ASCII decimal numeric length field, with leading zeros if
          necessary, for example "02".

  SYSID   The system ID, one of the codes listed on pp.275-278 of the Kermit
      book.  This is a string of 1 to 99 ASCII characters (but typically
          1-3 characters), for example "D7" for VAX/VMS.  The length of the
          SYSID field is given by the preceding field (IDLEN).

  LBLEN   A 2-byte ASCII numeric length field, with leading zeros if
          necessary, for example "00", "02", "09", "99".

  LABEL   A label field, 1 to 99 ASCII characters.  The length is given by
          the preceding length field (LBLEN).  The LABEL field contains the
          name of the file descriptor data that follows.

  VALEN   An 8-byte ASCII numeric length field, with leading zeros if
          necessary, for example "00000512".  Zero ("00000000") is a
          permissible length for a value.

  VALUE   The value associated with the label, 0 to 99999999 bytes of
          information about the file in system-dependent format.  The labels
          and the format and layout of the associated values for each system
          type should be clearly defined and documented.

     The sequence (LBLEN, LABEL, VALEN, VALUE) may be repeated for as many
     labeled values are needed (if VALEN is zero, then VALUE is omitted).

  CONTENT The file's contents, encoded in whatever form that, in combination
          with the labeled values, allows for its eventual reconstruction in
          its original form.

All fields in a labeled file are subject to whatever encoding, prefixing, or
compression options have been negotiated by the two Kermit programs.

REQUIRED LABELS

The following labels (composed of ASCII uppercase letters) are reserved, and
are required in every labeled file:

  VERS    The operating system version, e.g. "5.3-1".  If there is no version
          to be specified, this label must still be present, but with a
          zero-length value.

  DATA    This is the final label.  It always has a zero-length value, which
          is followed immediately by the file's contents, as defined above.

EXAMPLE

A hypothetical example for VMS (ignore the indentation and line breaks;
the length fields are marked with L's):

                      LL  LL    LLLLLLLL     LL   LLLLLLLL
  KERMIT LABELED FILE:02D704VERS000000055.3-103FAB00000512<512 bytes here>
  03ACL00000723<723 bytes here>02DATA00000000<file's contents here>
  LL   LLLLLLLL                LL    LLLLLLLL

Note: FAB and ACL are not necessarily real labels.

EFFECTS ON THE KERMIT PROTOCOL

When SET FILE TYPE LABELED is in effect, the sending Kermit should include
the file type (") attribute, specifying a type of binary (B), if attribute
packets have been negotiated.  Otherwise, there is no effect on the protocol
at all.  In particular, a label-wise Kermit program can interoperate perfectly
well with another Kermit program that is completely ignorant of labeling, in
which case the latter program simply "archives" or "unarchives" the file,
labels and all (provided the user remembered to place it in binary mode).

This proposal does not rule out the system-independent type of file archiving,
based on file attribute packets, that is described in the Kermit book.
However, if the "system-dependent" attributes suggested by this proposal can
be worked out in a sufficiently generic fashion, this may lead to a more
effective type of transmission of complex files between unlike systems that
share similar types of file characteristics (block size, record format,
character set, carriage control, etc).

On the other hand, for the first pass at an implementation (for VMS), it might
make more sense to simply have a single system-dependent label, like "FAB",
whose value is simply the File Access Block, and perhaps another one like
"ACL" for its Access Control List.  The two approaches do not rule each other
out.

USER INTERFACE

When SENDING a file, the user should first determine whether it is a bare file
or a labeled file.  This can be done by visual inspection (looking at the
first 20 bytes), or from memory (e.g. because all labeled files have a
particular filetype, or are kept together in a certain directory).  Then:

  (a) If it is a bare file, use SET FILE TYPE LABELED if you want to send
      label information too.

  (b) If it is a labeled file, use SET FILE TYPE BINARY.

When receiving a file, use SET FILE TYPE LABELED if you want labels in the
incoming file to be interpreted and applied, and:

  (a) The other Kermit is sending a bare file from a like system using SET
      FILE TYPE LABELED, or:

  (b) The other Kermit is sending a labeled file, of the receiving system's
      system type, from any kind of system, without SET FILE TYPE LABELED.

The receiving Kermit program that has been given a SET FILE TYPE LABELED
command must inspect the incoming data.  The first 30-36 bytes of the first
packet contain the BANNER, IDLEN, SYSID, and the first LBLEN, and LABEL (which
should be "04VERS").  If these five items are in correct format, and the SYSID
matches the program's own, then the program will accept the file in labeled
mode.  Otherwise, it will treat it as a binary file and store all the data,
including BANNER, SYSID, LABELs, VALUEs, and all length fields.

If a receiving Kermit program has accepted the file in labeled mode, but then
encounters an unknown label or other inconsistency in the labeled file format,
it must interrupt the file transfer (by putting an X in the data field of the
first available ACK) and discard the file.  This is because it cannot be
expected to back up and undo whatever label interpretation it has already done.

It is also conceivable that "similar" systems -- such as the DEC operating
systems VMS and RSX-11 -- might be able to honor each other's labels.  This
eventuality should be allowed for, possibly with SET commands.

At the discretion of the programmer, a command such as SET FILE
LABEL-DETECTION { AUTOMATIC, MANUAL } could be installed.  If so, the default
must be MANUAL, that is, processing of labeled files occurs only if the user
asks for it explicitly.  For an arriving file, AUTOMATIC mode would detect the
BANNER, SYSID, and first LABEL and go into action as if the user had SET FILE
TYPE LABELED.  When sending a file, the program would avoid adding surrounding
label information if the user had already SET FILE TYPE LABELED.  This sort of
thing is obviously dangerous, and users should be cautioned about it.

POSTPROCESSING

Separate programs should be provided to translate a labeled file into a real
file, to be used in case the user forgot to SET FILE TYPE LABELED, or the file
was deposited by means other than Kermit.  Such a program might have two
options (or come in two forms): interpret the labels, and simply strip the
labels.

ACKS

Thanks to Terry Kennedy and Frank da Cruz for suggesting this idea, and to Joe
Doupnik, John Chandler, and Paul Placeway for many valuable suggestions.
Comments welcome!

------------------------------

Date: Mon, 27 Aug 90 10:13:45 EDT
From: Christine M. Gianone <[e-mail]>
Subject: And ANOTHER New Test Release of MS-DOS Kermit 3.02
Keywords: MS-DOS Kermit 3.02

>From JRD's update notes since V12 #2:

48. Add recognition of IBM PC video boards STB VGA/EM Plus (Tseng 4000)
    and Everex Viewpoint EV-678, from Terry Kennedy. The list of boards known
    to Kermit for switching between 80 and 132 columns is now:
    ATI EGA Wonder
    AT&T
    Everex Viewpoint EV-659, FVGA-673, EV-678, Micro Enhancer Deluxe
    Paradise AutoSwitch EGA Mono
    STB VGA/EM (Tseng TVGA)
    STB VGA/EM Plus (Tseng 4000), VGA/EM-16, VGA/EM-16 Plus
    Tseng Labs EVA board w/132-col kit installed
    Tseng Labs UltraPAK mono/Hercules w/132 column modes
    Video 7 Vega Deluxe w/ 132X25.COM driver installed and Video 7 VGA

49. Add a facility to the keyboard translator.  Let key definition strings
    of the form {\Kverb other material} activate an existing Macro if and
    only if the verb is not in the list of those predefined for the keyboard
    translator.  If "verb" matches the name of a regular Kermit Macro execute
    the Macro and stay on the Kermit command line; thus a CONNECT command is
    needed to return to Connect mode. If verb does not match a Macro then do
    nothing and stay in Connect mode. Be aware that searching tables for the
    name of the verb uses many cpu cycles and will reduce performance.

    Examples:
        DEFINE Accumlate Receive, Connect
        SET KEY \315 {\Kaccumulate}

    Pressing the IBM PC "F1" key (code \315 above) makes the keyboard
    translator see string {\Kaccumlate}, verb "accumlate" is not in the
    predefined tables, and hence Kermit invokes the Macro named ACCMULATE.
    That Macro puts Kermit into file receive mode and when the file, or
    file group, transfer has been completed it returns to Connect mode.

        DEFINE WP Take wp30.ini, Connect
        SET KEY \316 {\Kwp}

    This makes IBM PC key "F2" invoke macro WP which in turn reads in
    and executes the contents of file WP30.INI. Kermit then returns to
    Connect mode. Nothing happens if the user has not defined Macro WP.

    Braces around the whole key definition are required so that the search
    for the verb name is done while executing Connect mode rather than when
    defining the key. If the braces are omitted then only the predefined
    keyboard verbs are available; an error will be reported if the verb is
    not one of these.

    Text sent to the host may preceed and follow the \Kverb part. To avoid
    confusion "Kverb" itself, but not the "\", may be placed in braces too,
    such as:

    DEFINE Accumulate cd c:\junkmail,Receive,Connect
    SET KEY \315 {kermit\13\send foo.bar\13\{KAccumulate}exit\13}
    the pieces:   |_______________________||............||_____|
                  string to host          do Macro    string to host

    This sends the string "Kermit<carriage return>Send foo.bar<carriage ret>"
    to the host to invoke its Kermit and asks it to send file foo.bar. It
    then invokes local Macro Accumulate to receive the file, and finally it
    sends the string "exit<carriage return>" to the host. Braces around
    KAccumlate deliniate it from the final string text.

    There is no host command which can invoke these Macros; this protects the
    PC against stray garbage text and unauthorized commands from the host.
    Files changed are MSUIBM.asm (procedure keysv) and MSYIBM.asm.

50. Reinstate Dump screen: filename on Status display. msssho, msyibm

51. Correct a misprint in the National Replacment Character sets for Spanish.
    Apparently a DEC typist inserted one accent mark too many in the table.
        char value    was        is now
    60h \96        accent        accent        just for reference
    7bh \123    accent        degree
    7ch \124    degree        n tilde
    7dh \125    n tilde        c cedilla
    7eh \126    c cedilla    tilde
    Corrections are in file mszibm.asm

52. Embellish the VT300 character set abilities by permitting National
    Replacement Character (NRC) sets to be "designated" by the host to a
    particular Gn set table, viz:

    Designator         Mnemonic       Description of Action
    ESC ( <ident>    SCS    Designates 94 byte character set <ident> to G0
    ESC ) <ident>    SCS    Designates 94 byte character set <ident> to G1
    ESC * <ident>    SCS    Designates 94 byte character set <ident> to G2
    ESC + <ident>    SCS    Designates 94 byte character set <ident> to G3

    where <ident> is:
    NRC country  <ident>        NRC country  <ident>
    British        A        Italian        Y
    Dutch        4        Norwegian/Danish ' (hex 60) or E or 6
    Finnish        5 or C        Portuguese    %6
    French        R        Spanish        Z
    French Canadian    9 or Q        Swedish        7 or H
    German        K        Swiss        =

   Example: ESC ) A  loads the British NRC set (A) into G1 (the ")" part).
   To load Latin1 into G1 use  ESC - A  because Latin1 is a 96 character set.
   NRCs are all 94 character sets.

   This embellishment does NOT turn on NRC operation in the Digital Equipment
   Corporation sense. To follow DEC usage employ SET TERM CHARACTER-SET to
   choose the country and have the host enable or disable NRCs by sending
   CSI ? 42 h  or CSI ? 42 l, respectively.
   Changes are in file mszibm.asm.

53. Minor code corrections to parsing eight bit controls introduced by item 52.
    File mszibm.

54. Incorporate support for Novell's TELAPI TCP/IP Telnet program. This
    is selected by command

            SET PORT TELAPI nnn.nnn.nnn.nnn

    where nnn.nnn.nnn.nnn is the Internet address of the remote host, in
    decimal.

        Example: SET PORT TELAPI 129.123.1.11   (machine netlab.usu.edu)

    TELAPI is a component of the Novell package LAN WorkPlace for DOS. At
    Utah State University it was run with the Novell (ex-Excelan) EXOS 205T
    Ethernet board (a smart mutiprotocol board supporting TCP with NetWare
    IPX 802.3 style packets). Novell Utility TSU.EXE is not required.

    SET PORT TELAPI must not be confused with SET PORT NOVELL(NASI); they
    use very different communications methods.

    Notes on this new faciity:

     a) Hosts not on the local network will likely require their
        Internet address and the local gateway to be specified with utility
        ROUTE, such as
            ROUTE ADD 128.59.39.2 129.123.1.254
    The first address is watsun.cc.columbia.edu, in New York City,
    and the second is that of a local gateway box (a cisco, Inc router
    at Utah State University in Logan, Utah).

     b) The communications channel is opened as an 8-bit wide BINARY
        character at a time mode, thus Unix hosts may require Line Feed
    (Control J) as a line terminator. See also item g) below regarding
    character \255.

     c) Included in this work is sending a BREAK signal as a Telnet
        "Interrupt Process" command.

     d) A status message is shown for 3 seconds if the connection cannot
        be established.

     e) Once an Internet number has been specified with SET PORT TELAPI it
        will be retained for subsequent SET PORT TELAPI commands. Thus it
    need be stated only once. SHOW COMMUNICATIONS will display the number.

     f) The presence of the host can be checked by sending the two bytes
         \255\246  which is Telnet signal "Are You There", and to which the
    host is supposed to send back a bell or visible message. This can
    be arranged easily by command SET KEY <key's ident here> \255\246
    if SET TERMINAL CHARACTER-SET TRANSPARENT is selected.
        See TCP/IP documents RFC-854 and RFC-855 for Telnet specifications.

     g) Character \255 is special in Telnet; it introduces Options negotiation.
        To send \255 as data it must be sent twice, as \255\255 or use the
    new command SET SEND DOUBLE \255 to do this for Kermit packets.
        Please be aware of this character when sending Binary files.

     h) TELAPI version 3.5 sometimes has trouble hanging up a connection. It
        will attempt creating a new one for each new session and can exhaust
    its space (defaults to two of them) when an old one persists. The
    only cure I know is to unload the TELAPI TSR (DOS command TELAPI -u)
    or reboot the machine.

     i) TELAPI version 3.5 is also notably slow in delivering characters to
        terminal emulators. Expect an effective 2400 baud rate.

     j) TELAPI uses Interrupt 14h with high numbered function calls. Beware
        of using other Int 14h trapping programs simultaneously.

     k) Kermit uses only the Internet number form of addressing for TELAPI
        because the TCP "name resolver" (conversion of a name to a number)
    is not available directly with TELAPI. Thus, full compliance with
    TCP/IP specs is not available to Kermit or other external terminal
    emulators using the TELAPI interface. The full specs recommend using
    names and letting a separate group of machines, called Name Servers,
    provide the Internet number via TCP/IP methods.

    All the changes are confined to file msxibm.asm

55. Correct a real bug: if SET LOCAL ON and while in Connect mode Control-
    PrintScreen (copy screen to printer) are active then Kermit crashes the
    system. The reason is a stack overflow when the same function ends up
    calling itself again by roundabout means. Adequate correction required
    small revisions about what is or is not echoed locally. Now almost every
    thing except DEC status reports is echoed (my real VT320 seems to do the
    same). Affected files are msyibm.asm and mszibm.asm, done on 14 August.

56. Add Enviroment and command line SET COM1 and COM2 to the list as per
    item 4 above.

57. Significant change to \%n variables defined as macro arguments. For each
    Macro invocation first save variables \%0 through \%9, clear \%0..\%9,
    define \%0 to be the name of the macro being invoked and \%1..\%9 as
    the arguments to the macro. When the macro exits restore the previous
    \%0..\%9 variables. This process nests naturally, and ARGC still
    represents the one plus the number of macro arguments. C Kermit 5A and
    MS-DOS Kermit 3.02 are now in agreement on these items.
    Previously \%0 was not affected by macro invokation and \%1..\%9 were
    not saved and restored around the macro. The new behavior may affect
    scripts written in the past. File mssset.asm

58. Add alternative command syntax:
    SET FILE COLLISION means the same as older SET FILE WARNING
    and SET FILE COLLISION DISCARD is the same as SET FILE COLL NO-SUPERSEDE.
    Changes are in mssset.asm and msssho.asm

59. Correct problems with REM LOGIN. Is the last of problems in this area?

60. Correct problems with CTS/RTS handshake timing and half duplex. Tnx to
    Brian Holley for spotting them. msxibm.asm

61. Add DESQview support call to release the cpu timeslice when in Connect
    mode and no character is available from the serial port. msyibm.asm

62. Modify the retry procedure to send a packet character to wait 60ms rather
    than 10ms between each of five attempts. This may help situations where
    a network device may be unresponsive for about 200ms between characters.
    msscom.asm

  More changes are expected.

The mstibm.boo file and the source files are in kermit/test on watsun and in
the T: area of KERMSRV.  The binary .EXE file is available on watsun only in
kermit/bin/mstibm.exe.  There is also a test 3.02 version for the DEC Rainbow,
contributed by Robert Weiner of Cooper Union.  It is in kermit/test/mstrb1.boo
and kermit/bin/mstrb1.exe.  The latest Rainbow test version tracks the non-IBM
specific portions of MS-DOS Kermit, and adds some new character translations
for screen dump and print screen.  Thanks to Joe and Robert for their
continuing work on MS-DOS Kermit!

------------------------------

Date: Mon, 27 Aug 90 14:13:12 EDT
From: Christine M. Gianone <[e-mail]>
Subject: A New Version of Kermit for OS/2 Presentation Manager
Keywords: OS/2 Presentation Manager Kermit

Contributed by Brian R. Anderson of Burnaby, BC, Canada.  Here is the note
that accompanied Brian's submission:

"The version of Kermit contained herein is for OS/2-PM.  It was written from
scratch by the author (Brian R. Anderson) in Stony Brook Professional
Modula-2.  A two part article in the September/October 1990 issues of Dr.
Dobb's Journal describe this implementation (which is a port of an earlier
program that I wrote for DOS in Logitech Modula-2).

This program is public domain, and may be copied freely, modified/enhanced,
and distributed freely (in original or enhanced form).

Included on the disk are an executable version of the program
(PCKERMIT.EXE); 17 Modula-2 source code files (8 .DEF and 9 .MOD); icon and
resource files; make and linker response files, and the EXE definition file.
To recompile the program: M2MAKE PCKERMIT <cr>.  The program includes:

      Kermit single and multiple file transfer
      TVI950 Terminal Emulation (optimized for IBM7171/PROFS)
      Automatic renaming of files in case of name clash
      Continuous display of communications settings"

Brian indicates that this program is the starting point for a program that
will be sold commercially.  Further details are in the file O2AAAA.HLP.

The files are in the Kermit test area for now, pending reactions from the
Kermit user community:

watsun.cc.columbia.edu    BITNET KERMSRV@CUVMA    Comments
  kermit/test/o2aaaa.hlp    T:O2AAAA.HLP            "boo" encoding of program
  kermit/bin/o2aker.exe                             Executable program
  kermit/test/o2aker.boo    T:O2AKER.BOO            "boo" encoding of program
  kermit/bin/o2aker.ico                             Program icon
  kermit/test/o2aico.boo    T:O2AICO.BOO            "boo" encoding of icon
  kermit/test/o2asrc.jar    T:O2ASRC.JAR            Source code

The boo files can be decoded into the original binary files using any of the
msbpct programs available in kermit/a.  The "jar" file is a text archive of
the source files that can be picked apart with a text editor or a simple
program.  Brian's submission did not include a user manual.

Many thanks to Brian for contributing this program.

------------------------------

Date: Sat, 28 Jul 90 12:10:27 PDT
From: rochester!ames!claris!portal!cup.portal.com![e-mail]
Subject: New Release UCPECAN Kermit V1.1
Keywords: Pecan, USCD Pascal Pecan Kermit

I am submiting a minor upgrade to UCPECAN my Kermit-UCSD (Version 1.1).

You should recieve 2 files: 1) a large (about 1400 lines) one containing
the source (UCPUPD.PAS) and a very short one containing "installation
instructions" and a brief list of changes made to V1.1 by this upgrade
(UCPUPD.UPD).  The changes are

1)  Added a new Unit (DIR.FIXES) to work around problems
    encountered with SFS. This update removes Limitation #4,
    making BINARY file transfers exact in both SFS and AFS
    implementations.

2)  Fixed a bug that caused an incorrect time to be sent in
    the attribute packet if no time was specified with the
    creation date (this bug affected both AFS and SFS).

                      R. Tim Coslet

Usenet: [e-mail]
BIX:    r.tim_coslet

[Ed. - Many thanks, R. Tim!  The new files have been installed in the Kermit
Distribution C area.  Keep up the good work!]

------------------------------

Date: Tue, 07 Aug 90 02:00:41 MEZ
From: "Gisbert W.Selke" <[e-mail]>
Subject: MS-Kermit 3.0x and German telephones
Keywords: MS-DOS Kermit 3.0, German

Here's a (partial) solution to a problem no-one besides me seems to have had:
I'm running MS-DOS Kermit over a 1200 bps line in what is yet West Germany.
For some obscure reason, the German PTT transmits the signal to my phone that
can be used to record the fee due. (No, I never had such a gadget. Maybe some
former owner of this flat had.) Unfortunately, the tone used for this is
right within the range used for 1200 bps transmissions. So, if I'm lucky,
I get a corrupted packet every 8 to 12 minutes (for local calls - much more
often for trunk calls); if I'm in terminal mode, however, I get some 10
scrambled characters on the screen. So far, so annoying. But you ain't seen
nothing yet: some of the garbage obviously contained shift-in/-out sequences,
so that I was left with funny graphics characters all over the screen
henceforward, where ordinary 7-bit ASCII should have been. The solution came
with one of the 3.02 revisions of MS-Kermit: 'set term char ascii g1' takes
care of the odd shift!

Still, some of the garbage even throws me out of that; apparently, it loads
a different character set into gx, where x = 1..3. So, if anyone has a way
of doing away with the disturbances altogether, any help/hints/pointers will
be appreciated, with software solutions muchly preferred.

\Gisbert   c/o  <UPP101.DBNRHRZ1.BITNET>

------------------------------

Date: Mon Aug 27 10:19:29 1990 EDT
From: Christine M Gianone <[e-mail]>
Subject: Looking for Stories

 ... of how Kermit has been used in imaging and visualization applications,
including modelling, CAD, medical imaging, and so forth, for possible
publication.  MS-DOS Kermit graphics, Kermit protocol imbedded in imaging or
CAD systems, whatever you know about ...

------------------------------

End of Info-Kermit Digest
*************************