Columbia Kermit/kermit.zip/old/ckermit4e/ckdker.bwr

Text File | 2020-01-01 | 6KB | 127 lines

Following are the warnings and limitations of C-Kermit for the Data General
computers
==============================================================================

1.  Intelligent interface devices are needed for the terminals and
communication lines, but most DG's have such devices by default.  IAC's are
suitable, as is any device where a CHAR command or a ?SECHR call can be
issued.

2.  Kermit always reads and writes to @OUTPUT for its local, interactive
console.  Almost all remote host commands will execute on the DG Kermit
server, but I did find one command that did not execute because of a conflict
in trying to write to @OUTPUT.  You will have to look hard to find another
command like that, but I want to mention the anomaly.  In general, this is
still acceptable behaviour for a C-Kermit server.

3.  The Kermit developement evironment I used is described in ckdker.bld, and
this environment establishes my biases.  At one time in devlopment, an
external console file (e.g., @CON11) was deleted when Kermit was running in
superuser mode, but I think that bug has been fixed.  I have not retested this
bug, because I don't have system privelages; and I do not have permission to
shutdown the machine and bring it up again, in case the device file gets
deleted.

4.  External line efficiency is not that bad, but it is less than local line
efficiency at high baud rates.

5.  External lines cannot be used for logons, since they must be disabled.
See ckdker.bld .

6.  Not all the i/o redirect options have been tested, and no "PROC" command
has been tested, but these options should work.

7.  Baud rates greater than 19200 have not been tested.  Some loss of
characters can occur at 19200 for interactive connect'ed sessions.  The
interactive console should be set for xon/xoff protocol (CHAR/ON/XIFC/XOFC)
for better terminal emulation at higher baud rates.

8.  For compilation, the /EXTL switch was used, and so externals must be
defined in some source file.  This should cause no problem.

9.  A "bye" command for the DG Kermit server will not log off the DG, but will
exit the Kermit program.

10.  DIAL, and SCRIPT commands have not been implemented, and they have not
been tested either.  I guess they don't work.

11.  Timeout values cannot be less than 2 seconds.  Specifying a lower value
will get you 2 seconds anyway.

12.  Transmitting a BREAK may not work.  I can't be sure because I do not have
an environment in which I can really test this feature.

13.  Kermit must be terminated in a special way because binary reads are done
on the interactive console.  This procedure is described in ckdker.doc, and I
will reproduce it here.  To abort Kermit, enter:  BREAK control-C control-A .
Or you may enter:  BREAK control-C control-B .  BREAK takes you out of binary
mode, and the other characters are the standard program abort sequences.
Kermit ensures that this works by configuring the console to:
CHAR/BREAK=BMOB , which means that "BREAK exits binary mode i/o".

14.  Unlike most Unix Kermits, DG Kermit will execute the .kermrc when it is
invoked from a CLI command line.

15.  After a remote host command, you will always get information about the
spawned process logging off.  There is no way to avoid getting this message,
which is a side-effect of using sys_proc() to create the pipe file.

16.  You may get a error when you do a 'set line' command: "Modem discconnect
in progress".  ttopen() retries twice when this error occurs.  You should this
error, but if you do, enter the 'set line' command again.

17.  At rare times, when you exit the Kermit program, an abend error occurs in
_MAIN(), which is the system-supplied runtime routine.  This error occurs in
some _tty_close() routine, "an attempt to FREE an object on the heap that was
already freed".  If the error were constant or reproducible, I could fix it.
But, I suspect the error to be a bug in the DG runtime routines or in _MAIN()
itself.  NOTE: I think I fixed this error when I found a close for a file that
was never opened, but let me know if it occurs since it is hard to reproduce.

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

Date: Wed, 29 Jul 87 14:25:26 edt
From: xyzzy![e-mail] (Michael Meissner)
Subject: Re: DG Nova (V6 #14)
Keywords: DG Nova Kermit

In article <[e-mail]> you write:
> Date: 1-JUL-1987 10:23:05
> From: [e-mail]
> Subject: Files Needed for the DG Nova Running RDOS?
> Keywords: DG Nova Kermit
>
> It's been pointed out to us that the files for Kermit in Fortran-5 for DG
> Nova machines running RDOS (prefix RDO) are incomplete. There are include
> references to SETSETUP.FR and F5ERR.FR, and these files aren't in the set,
> and what they may contain isn't obvious.
>
> Does anyone know what's in the files, or has anyone got copies?
>
>        Alan Phillips
>
> [Ed. - These are probably DG files that come with DG Fortran.  Anyway, the
> person who contributed the Fortran version of RDOS Kermit is long gone.
> The forthcoming release of C-Kermit will support DG C environments; it has
> been tested on AOS/VS, but not RDOS, however the C environment is supposed
> to be consistent across all the DG product lines.]

Ughhh, the DG C compiler only supports the 32-bit MV/eclipse systems (RDOS
runs on the 16-bit Eclipses and Novas).  The operating systems that the
DG C compiler supports are:

    AOS/VS        propritary
    AOS/RT32    propritary real-time subset of AOS/VS
    AOS/DVS        propritary distributed AOS/VS
    MV/UX        Unix System V hosted on top of AOS/VS
    DG/UX        Native System V/BSD unix

To my knowledge, the only C compiler that supports RDOS or AOS, is from
a company called IPT.  Sorry for any confusion.

Michael Meissner, Data General.        Uucp: ...!mcnc!rti!xyzzy!meissner

[Ed. - Oh.  So we can wipe RDOS off the C-Kermit list...]

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