info-kermit@ucbvax.ARPA (11/29/84)
From: Frank da Cruz <SY.FDC%CU20B@COLUMBIA.ARPA>
Info-Kermit Digest Wed, 28 Nov 1984 Volume 1 : Number 38
Departments:
UNIX KERMIT -
Unix Kermit Update
Kermit UUCP Downloading Update
USENET Distribution of Info-Kermit
MS-DOS KERMIT -
PCDOS/MSDOS Kermit suggestion
Kermits For Weird Semi-IBM Compatible Machines
Kermit bugs/inconsistencies (several messages)
VAX/VMS KERMIT -
DIAL command for VMS KERMIT
Bug Reports, Questions, Answers (several messages)
MISCELLANY -
TELENET PAD Parameters for Kermit
CMS Kermit and Non IBM Controllers?
VersaCom
ITS Binary Files vs Kermit
Kermit for Burroughs XE-520 / B25 (BTOS op sys) wanted
MacKermit connect mode
Mac Kermit initialization & other bugs
Apple 2c design flaw.
Commodore 64 Kermit V1.1 on the way
----------------------------------------------------------------------
Date: 28 Nov 84 21:15:00-EST
From: SY.FDC@CU20B
To: Info-Kermit
Subject: Unix Kermit Update
Although far from ready for release, some progress has been made on the
new (version 4) Unix Kermit. Repeated-character compression and 8th-bit
prefixing have been added, along with server mode and execution of host
commands. The program has been partially decomposed into modules. The
development has been done so far only under 4.2BSD and Pro/Venix, but the
support code that was contibuted for Sys III, Sys V, v6, etc, is on hand
and will be parcelled out into system-dependent support modules.
This program differs radically from other Kermit programs in structure;
the protocol module is an actual state table written in the input language
of the Unix lex program, with statements of the form
<current-state>input {action}
allowing the operation of the program and the protocol itself to be clearly
laid out in several pages of text. The actual release will use a similar
technique, but will not use lex because it's proprietary.
As soon as we have a version that's ready to test, it'll be announced.
------------------------------
Date: 16 Nov 84 17:50:12-CST (Fri)
From: Mark Vasoll <vasoll%okstate.csnet@csnet-relay.arpa>
To: Frank da Cruz <sy.fdc@cu20>
Subject: Kermit UUCP Downloading Update
I have created a file on our system that contains a directory of /u/kermit
(the Kermit distribution area) since many uucp users do not have a list of
the available files. The file is /u/kermit/00directory and can be uucped
from our system (it seems like a very boring thing to post...). We were
having some trouble with the wildcard transfers (they aren't working...),
so things like "uucp okstate!/u/kermit/ux* dir" were failing.
The problems with wildcard transfers to systems that are not in our L.sys
file have now been solved. The UUCP Kermit distribution should be able to
proceed without problems now.
Mark Vasoll
Oklahoma State University
------------------------------
Date: Sat, 24 Nov 84 19:31:21 pst
From: fair%ucbarpa@Berkeley (Erik E. Fair)
To: info-kermit-request@COLUMBIA-20.ARPA
Subject: USENET Distribution of Info-Kermit
Add
post-info-kermit@UCB-VAX.ARPA
and let your readers know that as of now, INFO-KERMIT is being
gatewayed to the USENET, so they don't have to (in fact, shouldn't)
directly subscribe to the digest if their host is on the USENET.
If there are any problems, please let me know.
Mr. USENET for UCBVAX,
Erik E. Fair ucbvax!fair fair@ucb-vax.ARPA
------------------------------
Date: Mon, 19 Nov 84 22:40 EST
From: Frankston.SoftArts@MIT-MULTICS.ARPA
Subject: PCDOS/MSDOS Kermit suggestion
To: info-kermit@CU20B.ARPA
In looking at how to implement support for the 8251 chip in the
DG/One, it would be simpler if the MSXIBM module attempted to
use the IBM BIOS calls whenever possible.
This would allow variations to be more easily supported.
I realize that the BIOS does not allow full initialization when
one is using interrupts, but it does allow standardization of
the baud rate setting (except for 19200 and 38400 which the
program doens't support anyway (why not?)) as well as other
basic initialization.
This would be a useful change for 2.27 if it is not too late.
[Ed. - See next two messages. There were some other problems with
the BIOS too, like not letting you choose all the common baud rates,
e.g. 1800.]
------------------------------
Date: Tue 20 Nov 84 11:09:37-EST
From: Daphne Tzoar <Sy.Daphne@CU20B.ARPA>
Subject: Re: PCDOS/MSDOS Kermit suggestion
To: SY.FDC@CU20B.ARPA
I disagree -- the whole point of the system independent modules is
to take advantage of the best way to do certain functions in each
micro. That's why we don't just use DOS for i/o -- it's too slow
to run at anything faster than 1200 and why we need system dependent
interrupt driven routine for reading in characters.
/daphne
------------------------------
Date: 20 Nov 1984 1222-EST
From: LCG.KERMIT
To: EIBEN
Subject: Kermits For Weird Semi-IBM Compatible Machines
I saw on the kermit news some queries about Kermit for DG/1. While
this isn't really very good, it'll have to do. The version of Kermit
I did for Seequa Chameleon is from an old (v1.18) pckermit, but is
super generic. It calls the ROM BIOS (int 14) to do all serial
communications. This was needed because the Seequa machine uses an
8274 multi protocol controller instead of an 8250, so is totally
different from IBM. (At the time I did the Kermit, I had no specs
on the 8274.)
Therefore I did everything via int 14h so as long as the BIOS
used emulates the IBM BIOS (which it pretty much must to allow print),
the Kermit will work. You have to use MODE first to set the port
baud rate, and then establish the connection (or fake it with Smartmodem
switches), and then run the Kermit to use same, and the Kermit assumes
ANSI.SYS is loaded. But it will work at up to 1200 baud. It will even
run on an IBM PC. But anybody with one of these near-compatibles
can use it (KER:SEEQUA.ASM) until I get around to modifying
the 2.26 version for similar operation. I've tried the generic Kermit
on the Chameleon withoug too much luck (under PC-DOS 2.0). I may try
again with 2.1, but I get easily frustrated by having to power down
and back up to continue, so I will more likely just fix the new
Kermit. I have a need VT52 initializer now for 2.26 that sets up the
whole VT52 keypad, allowing me to TECO etc.
Thanks.
Glenn Everhart
------------------------------
Date: 24 Nov 1984 1408-EST
From: LCG.KERMIT
To: EIBEN
Subject: Kermit-MS bugs
Persons:
We have several IBM ATs and XTs running Kermit-MS V2.26 connected to
a Vax 750 running Kermit-32 V3.0.052.
We are running the newest version of Kermit-MS V2.26, the one that
doesn't go from 63K to 1024K on file transfers. This was downloaded
from DEC.
We have found several bugs and inconsistencies in the Kermit-MS V2.26:
1. Take requires a full pathname even though all other references
to files (in send and get) only take filenames.
Example: Kermit-MS>take foo ; FAILS
Kermit-MS>take \usr\mth\foo ; SUCCEEDS
2. Running Kermit-MS piping from stdin works partially. Stdin gets
disconnected whenever you go into the terminal emulator or when
you get prompted for a password (REMOTE CWD).
Example: Kermit-MS>remote cwd [foo.bar]
Password:
Additionally, Kermit-MS does not quit on end of file. You must
put in a QUIT command at the end of the file, or reboot the
system.
3. REMOTE commands touch the floppy disk drive for no apparent
reason.
Example: Kermit-MS>remote dir ; spins up A:
This means that you have to have a floppy in the drive or MSDOS
gives you an "Abort, Retry, Ignore?" message.
4. If a REMOTE HOST command executes without doing any output,
Kermit-MS does a core dump to the screen and the system must
be rebooted.
Example: Kermit-MS>remote host set def [foo.bar]
Thank you,
Michael T. Howard
------------------------------
Date: Tue 27 Nov 84 16:37:00-EST
From: Daphne Tzoar <Sy.Daphne@CU20B.ARPA>
Subject: Re: MS ? KERMIT bugs/inconsistencies
To: SY.FDC@CU20B.ARPA
I think the problem with the path is that we don't check the current
directory at all if it's not in the path. That has to be fixed. And
the last problem is fixed for release 2.27. We did a "close file"
call at the end of every receive (and remote commands that write to
the screen.) Well, the PC and the XT never complained about a close
call for a file not physically on the disk and the AT does. I'm not
sure about the second problem though.
/daphne
------------------------------
Date: 27 Nov 84 18:55 +0100
From: Per_Lindberg_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
To: Info-Kermit <info-kermit@COLUMBIA-20>
Subject: Bug in MS-KERMIT?
There seems to be a bug in IBM PC Kermit ver 2.26 that makes
it bomb with "?Program error Invalid COMND call" after dumping
some garbage on the screen.
To conjure the bug, have a line like
define foo take foo.cmd
in MSKERMIT.INI (where FOO.CMD contains a couple of
SET KEY F1
DoThisCommand
SET KEY F2
DoThatCommand
etc.)
To conjure the bug, DO FOO a couple of times, and say
SHOW KEY
<f1>
after each try.
[Ed. - This is probably the SET KEY buffer overflow problem, which should
be fixed in 2.27.]
------------------------------
Date: Thu, 22 Nov 84 05:53 PST
From: NEWMAN%SAV@LLL-MFE.ARPA
Subject: DIAL command for VMS KERMIT
To: Info-Kermit@CU20B.Arpa
Frank:
Some time ago I implemented a DIAL (and REDIAL and HANGUP) command for
VMS KERMIT and the DEC DF03 modem. These commands are probably only of
marginal use to other sites, but I thought I'd share them with you.
Since I'm not directly on the ArpaNet (and thus people cannot FTP the
files) I have included the output from the VMS DIFFERENCES utility here.
I have also mailed (in a seperate message) the appropriate SLP command
files to make the changes.
If you'd like, I will mail you the updated sources.
Enjoy...
gkn
[Ed. - The files, which are too long to be included in mail, are in
KER:VMSDIAL.DIF and KER:VMSDIAL.SLP.]
------------------------------
From: lhasa!mghccc!simon@harvard.ARPA
Date: 21 Nov 84 09:57 EST
To: lhasa!harvard!info-kermit@cu20b.ARPA
Subject: BUG IN VMS KERMIT
I have found what appears to be a bug in the VMS version of KERMIT (version
3.0.051) which occurs when it is attempting to SEND a file, in my case, to the
UNIX C KERMIT (uxkermit on the distribution tape, running on a Masscomp MC500
system). The transfer proceeds to completion, the end-file packet is processed
on the receiver (and the file is OK there). The sender then runs into an RMS
problem and displays the message
KERMIT-E-RMS32, %RMS-F-IFI INVALID INTERNAL FILE IDENTIFIER. (IFI)
This is the result of a RMS $SEARCH operation just after entry point NEXT_FILE.
This occurs irrespective of whether the sending KERMIT is local or remote.
I reassembled and linked KERMIT with DEBUG (from the MACRO sources, since
we don't have BLISS) and found that the call to NEXT_FILE is not preceded by a
call to CLOSE_FILE ; since the $SEARCH operation has to be done on a FAB with
an inactive (closed) file I assume this is the cause. Oddly enough,
VMS-Kermit to VMS-Kermit works just fine (!), and there I do
see a call to CLOSE_FILE at the end of the file transfer on the sending
KERMIT, just prior to the NEXT_FILE call.
I performed file transfers with the UNIX Kermit and an earlier
version of VMS KERMIT (6/83 or so) and there are no problems there .
I guess this is a request to anyone out there using VMS KERMIT for help.
It's not easy to unravel the MACRO code that BLISS generates so I'd
appreciate any leads.
Thanks in advance,
Simon Rosenthal
Cardiac Computer Center
Massachusetts General Hospital, Boston MA
Phone: (617)-726-8226
ARPA: lhasa!mghccc!simon@harvard.arpa
USENET: harvard!lhasa!mghccc!simon
------------------------------
Date: Monday, 26 Nov 84 10:23:05 EST
From: nbush (Nicholas Bush) @ sitvxb
Subject: Re: [lhasa!mghccc!simon@harvard.ARPA: BUG IN VMS KERMIT]
To: <SY.FDC@CU20B>, lhasa!mghccc!simon%harvard @ cu20b
There is a problem in version 3.0.051 of VMS Kermit which shows up as
RMS IFI errors when talking to some other Kermits. The problem is due to
the buffer for packets being sent is too short if the maximum size packet is
in use. A simple work around is to do a SET SEND PACKET_LENGTH command before
doing a transfer. To fix the problem in the souce, the length of the buffer
SND_MSG must be increased. This can be done in the BLISS source by increasing
the value of MAX_MSG by 5. In the MACRO-32 source, the length in the .BLKB
psuedo-op for SND_MSG can be increased by 5.
This problem is fixed in the next version of VMS Kermit.
- Nick
------------------------------
Date: 26 Nov 1984 0117-EST
From: LCG.KERMIT
To: EIBEN
Subject: VMS Kermit (BLISS version)
I have run into couple of bugs in the VMS kermit. Here they are:
1. Often I set host from one machine to another over decnet and run kermit
on the latter machine because the latter has an internal modem. When I tell
kermit to CONNECT to the line that has the modem, it puts out the message
stating that it is connecting. But then instead of establishing and maintain-
ing the connection, it immediately comes back with the message "returning
back to vms kermit". If I attempt connecting again, kermit aborts with an
opcode fault and the vms runtime message "NOMSG, message number 000000".
Here's the sequence of DCL commands that illustrate the problem:
$! Assume that I am logged on machine A, I do a set host to
$! machine B. B has an internal modem.
$ SET HOST B::
$ KERMIT
kermit-32>connect txa7:
[ connecting to b::txa7: type cntl-] C to return to kermit ]
[ returning to b::tta0: ]
kermit-32>connect txa7:
KERMIT32-E-NOMSG message number 000000
<trace back shows up next>
$! back to DCL.
If I log on B directly, i.e, not through decnet, after I issue the connect
command, everything works as it is supposed to: I am able to talk to the
modem and tell it dial a specific number, and the rest. It is only when I
am going through decnet, the problem arises.
2. During file transfers, if I tell vms kermit to send a file and the file
description has some kind of an error in it, e.g,directory name that is
too long, or the file has world read permission while the directory the file
resides in does not have world read permissions, kermit aborts with a
forced exit by vms. Try the send command like:
$ kermit-32>send dra0:[guest.tomdickandharry]foo.bar
"tomdickandharry" is too long for a subdirectory name. Kermit will catch the
error in the directory name. Instead, it'll abort.
3. I sometimes log on one of our pdp's running ultrix-11 and use the unix
kermit to tranfer things between vaxes running vms. When I log on ultrix and
then log on a vax using ultrix kermit (i.e, kermit clb /dev/cua0 1200, where
/dev/cua0 is an auto-dial modem), and then tell vms kermit to send a file, the
file comes over fine, but something causes an RMS IFI (Invalid internal file
identifier error) in the vms kermit. I can ignore the error when I tranfer
one file at a time. The error however prevents me from using the wildcard
option when sending files, e.g, "send *.pas", or sending a bunch of files
as in "send prog.pas prog.dat prog.lis". The error occurs after vms kermit has
sent over "prog.pas" which then inhibits kermit from sending over the remaining
fils. The most recent version of unix kermit, and the one before it, both cause
the error. However when I send a bunch of files from ultirx to vms, everything
works fine.
Thanks,
Nancy Prohaska
KS1
[Ed. - Bob McQueen of Stevens says:
"Problems 1 and 2 should be fixed in the current field image of Kermit-32.
Problem 3 is fixed and it is my understanding that you have a work around
for it. We will work toward getting a Kermit-32 3.1 out which contains the
fix to the RMS IFI problem and also has a TAKE command."]
------------------------------
Date: Tue, 20 Nov 84 11:20:10 CST
From: Paul Milazzo <milazzo@rice.ARPA>
Subject: PAD Parameters for Kermit?
To: info-kermit@cu20b.ARPA
Can anyone tell me the exact PAD (and ITI?) parameters necessary to
make Kermit work over Telenet? I've had no luck at all with it. If it
matters, I'm connecting to a UNIX host from a CP/M system, and have the
latest Kermit for each.
Thanks,
Paul G. Milazzo <milazzo@rice.ARPA>
Dept. of Computer Science
Rice University, Houston, TX
------------------------------
Date: Tue, 20 Nov 84 13:20 EST
From: "John C. Klensin" <Klensin@MIT-MULTICS.ARPA>
Subject: Re: PAD Parameters for Kermit?
To: Paul Milazzo <milazzo@RICE.ARPA>
There are several combinations that appear to work under various
circumstances, and some Telenet PADs have historically been more fussy
than others, resulting in some confusion. Usually, if your host can
tolerate it (UNIX can, I would think), you want to set Xon/Xoff to the
PAD and in kermit. For the PAD, that is
SET 5:1,12:1
in order to get both input and output flow control.
The other little trick, which has nothing to do with PAD settings, is
that Telenet does not get on well with the transmission of binary data,
and seems to like parity=mark in many cases. For some reason, it often
also accepts even, odd, and space parity, as long as you don't try using
the high bit to pass information.
This is the sort of situation that leads to LOTS of superstitious
behavior. Good luck.
------------------------------
DATE: THURS, 15 NOV 1984
FROM: ATSBDN AT UOFT01
TO: SY.FDC AT CU20B
SUBJECT: CMS KERMIT AND NON IBM CONTROLLERS
Does anyone have any info on using CMS Kermit with a CCI controller that
emulates a 2705, except that it runs the ASCII lines in full duplex?
Also, how's the Yale IUP modifications coming along? For our system
we really need the Yale interface.
Thanks, Brian
[Ed. - As reported here, a couple sites already have Kermit working through the
Series 1, apparently using different techniques. We are looking into their
approaches, and hope to have a version of CMS Kermit that does this at some
point in the future. I don't see why the CCI controller would present any
special problem, since full duplex operation (i.e. host doesn't echo) is just
right for Kermit file transfer.]
------------------------------
Date: Wed 21 Nov 84 13:38:09-EST
From: Frank da Cruz <SY.FDC@CU20B.ARPA>
Subject: VersaCom
To: Info-Kermit@CU20B.ARPA
I've received a letter from Solution Software, which is selling a product
called VersaCom that does VT100 terminal emulation on the IBM and Sanyo
PC's, screen capture, and Kermit and Xmodem file transfer. They say they
adapted the current Unix Kermit code, added 8th bit quoting, repeat
counts, and keyword style command parsing, and they will submit the
result back to us, but without the terminal emulation. Their current
brochure gives credit to Columbia, mentions that other versions of Kermit
are available, etc etc.
Thanks to the many people who brought this product to my attention and
who evidently brought me to Solution Software's attention.
- Frank
------------------------------
Date: Wed 21 Nov 84 12:48:24-PST
From: Ted Shapin <BEC.SHAPIN@USC-ECL.ARPA>
Subject: ITS Binary Files vs Kermit
To: W8SDZ@SIMTEL20.ARPA
I have a problem with uploading files. I use KERMIT and I know
TOPS-20 KERMIT can read ITS binary files and when I use it with
KERMIT on the IBM-PC the ITS header is stripped and the file
converted to a uasable .LBR file, but I don't think KERMIT has
a way of writing an ITS binary file.
Why not use 8-bit format to store binary files on SIMTEL, which
both KERMIT and TOPS-20 modem can write?
Ted.
[Ed. - There's a program in <KERMIT-TOOLS> on CU20B called ITS. It
will create an ITS header. You can then append any 8-bit binary file
to the resulting header to produce an ITS binary file, for instance
@its ; (make the header if necessary)
@append its.hdr,foo.com (to) foo.com.-1
The result will have the same bytesize as the original, but regardless
what the bytesize is, programs that understand ITS binary format will
do 8-bit-byte input from it.
Alternatively, you can use the program 8COM at SIMTEL20, which apparently
does about the same thing.]
------------------------------
Date: Thu 22 Nov 84 01:30:36-EST
From: Mark Becker <Cent.Mbeck%MIT-OZ@MIT-MC.ARPA>
Subject: Kermit for Burroughs XE-520 / B25 (BTOS op sys) wanted
To: Info-Kermit@CU20B.ARPA
Hello -
Has anyone ported Kermit to a Burroughs XE-520 Megaframe or
B25 workstation?
Thanks in Advance -
Mark Becker
Cent.Mbeck%Mit-Oz@Mit-MC
------------------------------
Date: Wed 21 Nov 84 00:03:13-PST
From: Jyh-Jye Yeh <YEH@SU-SIERRA.ARPA>
Subject: MacKermit connect mode
To: engel@HARVARD.ARPA, info-mac@SUMEX-AIM.ARPA
I found what is wrong with MacKermit connect mode in dialing out at 1200 baud.
I have to choose 9600 baud at first and then choose 1200 baud in the control
options in order to link to Apple modem. If I don't point to 9600 baud and
click it, but fix at 1200 baud, then MacKermit won't send out commands to the
modem. This is not a major problem since I know how to get around with it
already. The other problem is that "backspace" dose not seem to work neither
when I try to dial out nor when I am talking to the host computer. Also, Emacs
can not work via MacKermit because the mode line is at the top instead of the
bottom
J.J. Yeh
yeh@su-sierra.arpa
------------------------------
Date: Fri 23 Nov 84 00:49:44-EST
From: Michael Rubin <RUBIN@CUCS20>
Subject: Mac Kermit initialization & other bugs
To: engel@HARVARD.ARPA
cc: sy.fdc@CU20B
The reason MacKermit release 2 doesn't use the remembered setup parameters
until after you call up the Control window is that the line
config=0x4c0a;
in main(), which sets default parameters, is AFTER the initial SetupControls()
call which reads the remembered values. I've also noticed a pile of other
apparent bugs, such as typos in the window size #define's which may explain
some off-by-one errors in the terminal emulator. Are you working on a release
3 or should I make a go at it?
--Mike Rubin <rubin@columbia-20>
------------------------------
Date: Mon, 26 Nov 84 16:51:13 EST
From: engel@harvard.ARPA (Stephen Engel)
To: RUBIN@COLUMBIA-20.ARPA, engel@HARVARD.ARPA
Subject: Re: Mac Kermit initialization & other bugs
Cc: sy.fdc@CU20B
You can not imagine the relief with which I read your letter. I have been
aware of the problem with configuration, and also another with sending out
padding for a while, but have not had the time to correct them. Meanwhile
unanswered mail and requests have been piling up, any university funding I
might get for working on Mackermit has dissapeared, and my lif has been
generally frantic. Please feel free to make any corrections you wish. I would
appreciate being sent a list of the bugs and fixes.
I am still willing to try to do it myself, but if you were to take it
on, I would be very grateful.
Steve
------------------------------
Date: Fri 23 Nov 84 20:44:34-EST
From: Peter G. Trei <OC.TREI@CU20B.ARPA>
Subject: Apple 2c design flaw.
To: info-kermit@CU20B.ARPA
A recent article in Creative Computing indicates that many of
Apple 2c's have a serial port problem; do to a design fault, they
transmit about 3% too slow. This is not a major problem at 300 baud,
but at 1200 many modems will not work properly. (The Apple modem DOES
work though). Apparently, if you have this problem, you can get the
dealer to swap the motherboard for you, and future 2c's will have this
problem fixed.
Maybe this is why so many people are having trouble with
Kermit on the 2c.
Peter Trei
oc.trei@cu20b.arpa
------------------------------
Date: 28 Nov 84 14:48:55 EST
From: Eric <LAVITSKY@RU-BLUE.ARPA>
Subject: Commodore 64 Kermit V1.1 on the way
To: sy.fdc@CU20B.ARPA
Well, it's finally here. I have in my posession a working version
of Kermit and sources for the Commodore 64. I am working on putting
together an initial release now (hopefully in a week). There are
some small bugs and improvements I want to make first. Later
releases will include major fixes/ improvements. This version is
very limited in what it will do as it is a pretty direct translation
of Apple V1.0 (or 1.1). The text transfer seems to be working
flawlessly though!
C-64 Kermit-65 Capabilities At A Glance:
Local operation: Yes
Remote operation: No
Transfers text files: Yes
Transfers binary files: No
Wildcard send: No
^X/^Y interruption: No
Filename collision avoidance: No
Can time out: No
8th-bit prefixing: No
Repeat count prefixing: No
Alternate block checks: No
Terminal emulation: Yes (VT52)
Communication settings: Yes; local echo, parity, baud
Transmit BREAK: Yes
IBM communication: No
Transaction logging: No
Session logging (raw download): No
Raw upload: No
Act as server: No
Talk to server: No
Advanced commands for servers: No
Local file management: Yes
Handle file attributes: No
Command/init files: No
Printer control: No
Please don't flood me with requests: the *only* way to get this will
be after its' 'official' release...
[Ed. - Note, there's also a Forth implementation of Kermit for the C64
on the way from the University of Vermont. It's either feast or famine...]
------------------------------
End of Info-Kermit Digest
*************************
-------