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

Text File | 2020-01-01 | 26KB | 552 lines

Info-Kermit Digest         Mon, 17 Sep 1990        Volume 12 : Number 5

Today's Topics:

       Announcing IBM Mainframe VM/CMS Kermit-370 Version 4.2.1
           Selecting CONTROLLER type in Kermit-370
              Announcing  KERMIT-12 Version 10g
            Kermit Proposal SET FILE TYPE
               Prime8 Help for Dividing Source
      Re: A New Version of Kermit for OS/2 Presentation Manager
            Re: Info-Kermit Digest V12 #2
            Kermit incapatability with LSE
            Kermit 3.01 Arrow Key Problem
            132 column mode in MS-Kermit?
                  Kermit & Telebits

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: Wed, 1990 Sep 12   18:30 EDT
From: "John F. Chandler" <[e-mail]>
Subject: Announcing IBM Mainframe VM/CMS Kermit-370 Version 4.2.1
Keywords: IBM 370 Kermit, VM/CMS Kermit
Xref: CMS Kermit, See VM/CMS Kermit, IBM 370 Kermit

This is to announce the release of Kermit-370 version 4.2.1 for CMS.  As
usual, the new version comes in VM/SP and VM/XA/SP flavors, but the
changes are the same for both.

Version 4.2.1 has several improvements over 4.2.0, the most important
being:

 1. Spurious flow-control "packets" from MS-DOS Kermit are now ignored.

 2. Overflow of the fullscreen buffer is now avoided when the receiving
    Kermit asks for 2K packets.

 3. Kermit-370 now supports transfers in LATIN2 and LATIN3 and file
    storage in CP870, CP880, and CP905.  In addition, L1, L2, and L3 are
    recognized as aliases for the three LATIN sets, and two-character
    abbreviations are accepted for the other transfer sets as well.  The
    new sets add support for Afrikaans, Albanian, Catalan, Croatian,
    Czech, Esperanto, Galician, Hungarian, Maltese, Polish, Romanian,
    Slovak, Slovene, and Turkish.

 4. Kermit-370 supports file transfers through the IBM 3174 AEA with B2
    microcode.  The support is restricted to terminals with the ASCII
    Graphics capability in three ways:

    a) The terminal type must be defined in the 3174 to support graphics
       (only the built-in VT241 and Tektronix 4205 types plus suitable
       user-defined terminal types).

    b) The line must be defined without an associated Host Addressable
       Printer.

    c) If the 3174 is owned by VTAM, the connection must be made with a
       logmode that allows the Read Partition Query (such as M2SDLCNQ).

    Kermit-370 automatically detects the B2 AEA and sets CONTROLLER
    accordingly (to AEA if graphics is allowed, to NONE if not, or to
    GRAPHICS if Query is denied).  Since the 3174 supports full 8-bit
    communication, it may be useful to configure the ports for 8-bit
    data and to set both SEND and RECEIVE PARITY to NONE in Kermit-370.

 5. Kermit-370 now uses the FILE COLLISION settings for all files in a
    group rather than just the first.

 6. Kermit-370 has three new subcommands: REMOTE MAIL, REMOTE PRINT, and
    REMOTE SUBMIT.  They transmit a file (or group of files via wild
    cards) tagged for mailing, printing, and submitting as job,
    respectively.

The new release is in the form of updates to be applied to the 4.2.0
source.  The new files are IKCKER.UPD, IKCKER.BWR, IK0AAA.HLP, and
IK0KER.UPD (the latter is only a catalog of all the updates, not the
updates themselves).  The new code has been tested on most known types
of protocol converter (many thanks to the beta testers!) to make sure
the 3174 support does not harm the existing support for Kermit file
transfer, but problems may still turn up.  Bug reports are welcome, as
usual.

A similar release 4.2.1 will soon be available for TSO and MUSIC.

                                         John

[Ed. - Thanks, John!  The new files are installed in kermit/b on watsun
and are also available from KERMSRV@CUVMA on BITNET.  This program is truly
amazing in its adaptability to the infinitely varied 3270 emulation
communications environment, and it is a groundbreaker in character set
conversion.  Let's hope that the other Kermit programs catch up in the latter
department soon.  For that to happen, we need examples and listings of the
PC, UNIX, Macintosh, etc, character sets used for all the language supported
by Latin Alphabets 1 through 5, Latin/Cyrillic, and others.  If you have them,
please send them in and we'll do our best to support them.]

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

Date: Thu, 1990 Sep 13   11:50 EDT
From: "John F. Chandler"   <[e-mail]>
Subject: Selecting CONTROLLER type in Kermit-370
Keywords: IBM 370 Kermit

One of the improvements in release 4.2.1 is a more thorough DEBUG output
that proved very useful in bringing the support for the IBM 3174 to
completion.  This enhancement makes no difference to routine file transfer,
but it raises the possibility of determining easily the exact response of
any kind of protocol converter to the efforts of Kermit to decide which
CONTROLLER type to use.  To this end, I ask all installers of release 4.2.1
to take a few minutes and create a debug log for each (fullscreen)
environment where Kermit-370 might be used, provided, that is, that you do
not apply the optional update SC89058.  Even if you have applied SC89058 in
the past, it might be worthwhile to omit it as an experiment.  The desired
debug log is created by starting Kermit-370 and entering the subcommands SET
DEBUG I/O LONG, SET LINE, and QUIT.  I would be grateful if you would send
the resulting KER LOG along with the following information: level of VTAM
(if any) driving the session, model of front-end processor (if any) and
software, model of protocol converter (if any) and software.  These results
would be interesting even for real IBM 3270-type terminals or protocol
converters unable to support Kermit file transfers.  It is possible that the
information collected will enable Kermit to distinguish certain environments
that currently fail to trigger the correct default CONTROLLER type.

                                    John

P.S. My e-mail address is:

 Internet:    [e-mail]
 BITNET:      PEPMNT@CFAAMP

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

Date: Thu Sep 6 1990 11:00:00 EDT
From: Charles Lasner <[e-mail]>
Subject: Announcing  KERMIT-12 Version 10g
Keywords: PDP-8, PDP-12, VT-78, DECmate, OS/8
Xref: DEC PDP, See PDP

This is a maintenance release of KERMIT-12.  A minor problem relating to
incorrect CPU identification messages has been fixed.  The problem only
appeared when the CPU was a KK-8A single-board CPU; this configuration was
previously untested.  Thanks to Johnny Billquist of Sweden for his
assistance in pinning down the problem.

KERMIT-12 operation was not affected in any other way, as only the
DECmate-specific identification is crucial; earlier PDP-8 family members
are treated in a generic fashion except for the "frill" of model
identification (all PDP-8, PDP-12, VT-78 models use software-compatible
port hardware;  all DECmates are incompatible and must be handled
individually).  We are still looking for volunteers to test the various
DECmate III and DECmate III+ configurations.

The rest of the release concerns the encoding of files into the
"ASCII-fied" format.  The format has been modified to be more robust, since
the original method has proven itself to be problematic in certain
practical circumstances (as reported in K12MIT.BWR).

The new ENCODing format is based on five-bit encoding with repeat
compression.  As much as 256 repeated 12-bit words will be expressed in a
five character field.  Any repeated 12-bit value can be compressed, as
opposed to simple zero compression, as in other common encoding schemes.
(PDP-8 files often have repeated strings of the value 7402 octal, which is
the HLT instruction.)

The only printing characters required to pass through any distribution
"path" are 0-9, A-V, X, and Z. The alphabetic characters can also be
lower-case.  All command lines are framed by ( and );  all data lines are
framed by < and >.  These characters can be changed if required, as they
are not part of the data; they could be replaced by W (w) and Y (y) if
necessary.  (Changing the framing characters requires slight modification
of the ENCODing and DECODing programs.)

The new format supports a 60-bit file checksum to ensure proper decoding at
the other end.  The former 12-bit checksum could be compromised on long
files.

The new ENCODing programs creates internal (REMARK commands stating the
ENCODed file's creation date, and the original file's creation date.  This
will aid in distribution of PDP-8 files where the user wishes to maintain
proper file dates.  The date algoritm used is the one proscribed by the
OS/8 DIRECT program. (OS/8 systems only OPTIONALLY support file dates, and
there is an eight-year "anomaly" associated with identifying the year; the
user must determine the credibility of the year portion of the date.  The
value provided by the ENCODE program for the original file creation date is
always today's year or the previous seven years as necessary; this field
will not be provided if the system doesn't support the required AIW
feature.)

Overall file size is theoretically as much as 6/5 of the original encoding
format (as the earlier format was based on six-bit encoding), but actual
size varies downward due to slightly less file overhead (wider lines mean
less CR LF; there is now less automatically generated verbiage), and the
random improvement afforded by simple repeat compression.

Virtually all K12MIT-related files are re-released at this time.  There are
several new files.  Due to the "fragile" nature of TECO macro files, the
file K12GLB.TEC is no longer being distributed directly; the file K12GLB.ENC
is the same file in the new ENCODE format.

The new files have been installed in the regular places:

BITNET/EARN       Internet
KERMSRV@CUVMA     watsun.cc.columbia.edu     Description

 K12MIT   ENC      kermit/d/k12mit.enc        Encoded binary of KERMIT-12
 K12MIT   DOC      kermit/d/k12mit.doc        Documentation file
 K12MIT   BWR      kermit/d/k12mit.bwr        Updated "beware" file
 K12MIT   DSK      kermit/d/k12mit.dsk        Description of RX02 diskettes
 K12MIT   ANN      kermit/d/k12mit.ann        Announcement of KERMIT-12
 K12MIT   UPD      kermit/d/k12mit.upd        Release update file
 K12DEC   PAL      kermit/d/k12dec.pal        Decoding program
 K12ENC   PAL      kermit/d/k12enc.pal        Encoding program
 K12PL8   ENC      kermit/d/k12pl8.enc        Encoded binary of PAL8 Ver B0
 K12CRF   ENC      kermit/d/k12crf.enc        Encoded binary of CREF Ver B0
 K12MIT   PAL      kermit/d/k12mit.pal        Main source file of KERMIT-12
 K12PCH   PAL      kermit/d/k12pch.pal        KERMIT-12 source patch file
 K12CLR   PAL      kermit/d/k12clr.pal        Memory clearing file
 K12MIT   LST      kermit/d/k12mit.lst        Symbols-only listing file
 K12PRM   PAL      kermit/d/k12prm.pal        Sample VT-78 config file
 K12GLB   ENC      kermit/d/k12glb.enc        Encoded TECO file macro
 K12ENC   DOC      kermit/d/k12enc.doc        Encoding format description

[Ed. - Many thanks, Charles.  Believe it or not, there are still quite a
few PDP-8 based systems out there, and even some PDP-12s.  You won't find
very many other new software packages that support them!]

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

Date: Thu, 6 Sep 90 08:47 CST
From: <[e-mail]>
Subject: Kermit Proposal SET FILE TYPE
Keywords: Kermit Protocol

Please accept these remarks regarding the proposed SET FILE TYPE extension
to Kermit.

1.  The labels are transmitted in normal Data packets.  Therefore an
ignorant Kermit receiver will write them into the file as data.  This is a
MAJOR change to the protocol, which has always provided transparent file
exchange.  When reading such a file, how is a program to know that labels
have already been included?  Will these files cause problems for other
file-transfer protocols such as Xmodem?

[Ed. - No, it won't cause problems with Xmodem.  Xmodem or any other file
transfer protocol, including a Kermit program that does not know about labeled
files, will store or send a labeled file just like any other file, without
interpreting the label information.]

2.  Stored-in-File labels are incompatible with the MacBinary protocol in
    standard use on Macintosh computers.

[Ed. - That's true.  But MacBinary format cannot be adapted to other kinds
of file systems such as VAX/VMS.  Kermit can still be used to transfer
MacBinary files, and a MacBinary option will be added to Macintosh Kermit
before its next release.]

3.  The sending operator must now decide whether to send with labels or not.
    Previously, the sender had no choices to make.  We should not be adding
    complexity to the process if we can help it.

[Ed. - This is true.  However, without labels it is impossible to transfer a
complex file and retain all of its features.  Therefore this proposal
addresses only computers with complex file systems, like VAX/VMS, IBM
mainframes, etc, and does not affect other computers.  Users can continue to
use Kermit on these systems in the normal way, but now they will also have
an additional tool to let them successfully transfer files that they could
not transfer before.]

4.  Perhaps a better approach would be to use:

        SET FILE TYPE system type

    Where 'system' identifies the receiving file management system,
    (RMS, VSAM, etc.) and 'type' identifies the appropriate attributes.
    Example:

        SET FILE TYPE RMS INDEXED

    where RMS represents Vax RMS file management, and INDEXED identifies
    the incoming file as an indexed file.

    This approach requires that the sending and receiving routines be
    similarly intelligent about the information required to successfully
    transmit and write the file, but allows unintelligent intermediary
    programs (repositories, bulletin boards, etc.) to receive and send
    the files without any special settings (other than SET FILE TYPE BINARY).

[Ed. - It is a cardinal principle of Kermit or any other well-designed file
transfer protocol that any particular computer must not be required to have
knowledge about the formats and conventions of any other kind of computer.
Rather, each Kermit implementation knows only the data formats of its own
computer and those defined for the "standard intermediate representation" on
the wire.  Otherwise, hundreds of different programs would require
modifications to know about hundreds of different computers.  Not only is
this a waste of computing and human resources, but it's a moving target.]

    It also allows the following sequence to take place:

      machine 1 Kermit send  -> machine 2 Kermit receive (FILE TYPE BINARY)
      machine 2 BrandX send  -> machine 3 BrandX receive
      machine 3 Kermit send  -> machine 4 Kermit receive (FILE TYPE xxx ttt)

    Machine 1 sends the file BELIEVING that the receiver knows how to handle
    it, but only the machine 4 program needs to know.  However, machine 3
    can also use the file, if it recognizes, or is told to recognize, the
    file type.

[Ed. - The Labeled File proposal works the same way.]

    A simplification of this approach would be to use SET FILE TYPE AUTO
    which would cause the receiver to perform some recognition process
    before writing the file.

[Ed. - The labeled file proposal includes this possibility too.]

We have recently developed a Macintosh VT100 terminal emulator which
incorporates Kermit file exchange, and automatically distinguishes TEXT
documents from applications and formatted documents.  The users need only
tell the Vax to SET FILE TYPE ASCII/BINARY depending on whether they intend
to edit it on the Vax, or transfer it to another Mac.  The program pre-pends
the Macbinary header for non-text documents when sending, and recognizes it
when receiving.  I think you'll agree that the LABELED proposal only adds
complexity to our situation, and requires users to make unnecessary
decisions about the process.

[Ed. - Your application seems to be Macintosh-centered, in the sense that
you regard the VAX as a repository for Macintosh applications, which you
encode in MacBinary, but you make no provision for storing VAX applications
or complex binary VAX files on the Mac.  For your purposes, MacBinary will
do just fine.]

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

Date: Tue, 28 Aug 90 17:27:31 EDT
From: John M. Crawford <[e-mail]>
Subject: Prime8 Help for Dividing Source
Keywords: Prime Kermit

Enclosed is a short file which provides the necessary Primos editor (ED)
tricks to divide (and then build) Kermit 8.12 for Primos. You might consider
appending it to the PRIME8.ANN file (or another) for general distribution to
Prime kermit users.

John M. Crawford      [phone]                Computing Services Center
                                                    College of Business
[e-mail]                                     1775 College Road
[e-mail]                     The Ohio State University
[e-mail]               Columbus, Ohio 43210

[Ed. - Many thanks!  Your ED file is now enshrined in PRIME8.ANN.]

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

Date: Wed, 29 Aug 90 10:23:11 PLT
From: Wim Bonner <[e-mail]>
Subject: Re: A New Version of Kermit for OS/2 Presentation Manager
Keywords: OS/2 Kermit

The message said that the Kermit files were in the OS/2 test area pending
comments from the user community.  Is this where I make comments?

I tried the Kermit program just now.  It has an annoying habit of going full
screen.  I have a 1024x768 screen, so an 80,25 screen will fit in less than
a quarter of the screen, and leave room for much more on the screen.

I am running OS/2 1.2, and was not able to get the lights on my modem to
blink when I typed characters after Connecting.  That is normally a good
indication something is wrong.  All of the other communication programs that
I've tried work fine.

Wim Bonner - [e-mail] - V(509)335-4436

[Ed. - Thanks.  We'll collect all such comments and put them in an envelope
and send them back to the contributor.  Meanwhile, has anyone else gotten
the program to work?]

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

Date: Sat 25 Aug 90 11:51:37-CDT
From: Rob Pettengill <[e-mail]>
Subject: Re: Info-Kermit Digest V12 #2
Keywords: MS-DOS Kermit 3.02, Macros, Variables, Scripts

The behavior of the macro positional parameters has changed in the new test
release of MSKermit 3.02.  Previously when a take script was taken in a
macro the \%n positional arguments were defined in the take script - with
this version they are undefined.

The previous behavior was reasonable for a script.  Are you tring to make
take files behave more like macros?  If so then it should be possible to
pass positional arguments to the take files explicitly.  In any case the
behavior in the current 3.02 does not seem desirable.

;rob

[Ed. - That was a mistake, which has been corrected in the latest 3.02
release.  Macro parameters are now on a call stack so if macro A calls macro
B, A's parameters are still intact when B returns.  The mistake was indeed
that a TAKE file was being treated like a macro.  In the latest edit, it is
not: if macro A TAKEs a command file, A's parameters are available to the
TAKE file, as before.]

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

Date: 29 Jul 90 23:18:00 CDT
From: "COLLINS, STERRETT" <[e-mail]>
Subject: Kermit incapatability with LSE
Keywords: MS-DOS Kermit 3.0, LSE, VAX/VMS, Terminal Emulation

I am using MS-Kermit v3.0 on a Kaypro 286 operating MS-DOS v3.21, connecting
to a VaxCluster operating VMS v5.3 .  I have tried using the language
sensitive editor (LSE v3.0), but Kermit fails to emulate the terminal that
LSE expects.  I have tried setting terminal/nodec_crt3, which partially
corrects the problem, but still not satisfactorily.  I am not sure that LSE
does not think that every member of the VT300_Family of terminals is a Regis
terminal.  I have access to a Regis_Emulating communications software
package, which I do not normally use for licensing considerations, but
which, if I switch to that after having entered LSE using Kermit, is able to
emulate the terminal properly.

The possible answers would seem to be:

"The operating system does not successfully detect the correct terminal
characteristics."

"The Operating system does successfully detect the correct terminal
characteristics, but this information is not propperly transferred to LSE."
I only know that SHOW TERMINAL reveals that it does not have the REGIS
characteristic, but does have the SIXEL charactersitic, and the DECCRT_3
characteristic.

                                        sterrett collins
                                        physics department
                                        texas tech university

[From jrd - Another case where Kermit command SET DISPLAY 8 needs be done
to avoid clobbering the 8-bit control sequences sent by the host.]

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

Date: Mon, 23 Jul 90 19:44:42 GMT
From: [e-mail] (Greg Seminara)
Subject: Kermit 3.01 Arrow Key Problem
Keywords: MS-DOS Kermit, Arrow Keys

Arrow keys work only sporadically when connected to a UNIX host from a DOS
PC running Kermit 3.01 if you are using a full-screen "curses" application.
Seems to be sending either the wrong ansi sequence or is sending the
sequence too fast.  If you press arrow keys with a significant pause between
each press, keys usually work OK.  Emulation is vt102 for kermit and TERM is
set to "kermit" or "vt100".  Kermit 2.32a and before work fine under
identical conditions.  - HELP!

[From jrd - your Unix host has a problem with communications.  If characters
in a control sequence are NOT sent in rapid succession then EMACS reacts
differently than expected.  In addition, some host machines apparently have
intrinsic difficulties running in true full duplex.  Unix loves to echo
arriving characters willy nilly.  So when Unix is sending a control sequence
while one is arriving from Kermit and Unix is also echoing it then Kermit
receives both sets of information with characters intermingled.  If the
sequences arrived separately then Kermit could cope.  This is pretty silly
behavior by Unix; the application should attempt supressing echos.  There is
nothing that Kermit (nor a real terminal) can do about it.]

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

Date: Thu, 30 Aug 90 14:28:57 CDT
From: [e-mail] (Moore)
Subject: 132 column mode in MS-Kermit?
Keywords: MS-DOS Kermit, 132 Columns, Screen Settings

Greetings.

I have a very persistent user here who wants the word directly from the
horse's mouth regarding a feature of MS-Kermit:

I've always thought that EGAs cannot do 132-column mode (except by simulating
it in graphics mode).  MS-Kermit doesn't change that, right?  Isn't it the
"responsibility" of the hardware to switch modes, and then Kermit just detects
and uses that mode?

[Ed. - True.  Except that in version 3.0 and later it also supports automatic
switching between 80 and 132 column mode via the COLS80.BAT and COLS132.BAT
mechanism.  That is, if Kermit gets the escape sequence telling it to switch
modes, it will try to run the appropriate BAT file that does the PC- or
adapter-specific things required to switch modes.]

Can Kermit simulate 132-column mode by letting the user pan an 80-column
window left and right?

[Ed. - No.]

Thanks for any help.

Jim
[e-mail]

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

Date: 27 Aug 90 11:42:05 GMT
From: mrsvr![e-mail] (Tom Shaw ct58 Ex 5084)
Subject: Kermit & Telebits
Keywords: Modems

I'm looking for anyone who has/is doing something similar to this: I am
transferring binary and ASCII files across dial-up phone lines using Telebit
Trailblazer Plus modems and kermit.  The transfers are between 2 Suns, one
running Sun OS 3.5 and the other running Sun OS 4.01.  The size of the files
range from 2500 bytes to 800kbytes.  Does anyone have any tips, traps to
avoid, benchmarks of what kind of rate I should be expecting for ASCII and
binary files or any hands on advice.  I am using kermit version 4E(72).

In the past few weeks, I've heard stories about using Telebits in Germany,
what kind of problem is there and are there any other countries I might have
a problem connecting and transfering to?

Any help would be appreciated.  Thanks

Tom

[Ed. - As you may know, Telebits have Kermit built inside them.  If you
activate this feature, Computer A actually talks Kermit protocol to Modem A,
Modem A talks high-speed error-correcting PEP protocol to Modem B and Modem B
talks Kermit protocol to Computer B.  This is all done transparently to the
Kermit programs, but you have to put the originating Telebit into "Kermit
spoof" mode.  See your Telebit manual.]

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

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