home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Columbia Kermit
/
kermit.zip
/
archives
/
hp1000.tar.gz
/
hp1000.tar
/
hpmker.ins
< prev
next >
Wrap
Text File
|
1990-01-08
|
6KB
|
99 lines
These instructions will assist you in the installation of KERMIT-RTE
revision 1.99d on any RTE-6 or RTE-A system of revision C.83 onward.
1) If your system is at revision C.83, you must edit KERCOM.FTNI.
On line 12, change the value of the SysRev parameter to any
value less than 2440. Then re-compile and re-index (lindx!)
only KASUBS and K6SUBS. It is NOT necessary to re-compile the
main KERMIT program! If your system is at revision A.85 (2440)
or later, you may skip this step.
2) Link KERMIT using the supplied KERMIT.LOD command-file. The
choice of KASUBS or K6SUBS will be made by Link as it reads
KERMIT.LOD. If your Linker doesn't support the "if" command,
use one of the following link run-strings:
Link kermit.rel $k6subs <RTE-6> -OR-
Link kermit.rel $kAsubs <RTE-A>
3) Put put KERMIT's help file where KERMIT can find it:
/SYSTEM is where KERMIT looks first, and
/KERMIT is where KERMIT looks next. If not found,
<wd> (your working directory) is where KERMIT looks next,
and if not found there, KERMIT will look for a file
"KERMI in FMGR-space.
If for some reason, the supplied KERMIT.HLP is corrupted, or if
you need to change it, you will need to generate a new KERMIT.HLP
by running the RTE-6 utility GENIX against the editable help file
KERMIT.TEXT.
In case of trouble:
I have had a few reports of Link errors ("Illegal relocatable
records") which seem to be caused by one of two conditions found so
far:
1) Errors in reading the tape -- especially in KERMIT.REL from
the 2730 CSL.
2) Features in 5.0 or 4.1 software which are not backward-
compatible to earlier systems in the relocatable files.
The solution is the same in both cases: re-compile KERMIT.FTN and
KxSUBS.FTN as needed. If this doesn't solve the problem, call me!
Compatibility issues:
KERMIT should be runnable on any RTE-A or RTE-6 system from
revision "C.83" (the first introduction of CI) thru revision "5.1"
if the correct SysRev parameter is set.
KERMIT-RTE revision 1.99d fixes all bugs which I have had the
time to fully research:
a) Under RTE-A, a B- or C-mux will be properly identified
without memory-protecting
b) The "wizard" commands (leftovers from some research I was
doing for the RTE-6 version) have been removed
c) An error crept into the subroutine ReportFileError which
was due to the resegmenting of KERMIT; this is fixed
d) This revision >>will<< run under RTE-A/6 revision 5.1.
e) The "new" serial drivers are now supported under RTE-A and
RTE-6; use your "D" muxes and enjoy!
KERMIT-RTE revision 1.99d may still suffer from a problem which
I have not yet had the time to research and solve:
If KERMIT-RTE is operating as a server under RTE-6, on
some occasions when a logoff-type command is used from
the local host, KERMIT-RTE will fail to terminate itself
(although it does a nice job of cleaning up its session!)
It may take the services of the new Debug/1000 before I
can solve this one.
While KERMIT is now transportable, there are some good reasons why
it may not transport once in a while:
1) Different systems: Don't expect a KERMIT linked under an
RTE-A to run on an RTE-6 system. In addition to software
differences arranged at link time, the layout of type-6
files is different between RTE-A, RTE-6, and the older
RTE types.
2) Different system revision: Don't expect a KERMIT linked
under a C.83 system revision to run on a 4.1 system! The
list of transportable entry-points (in VCTR) may not be
the same.
3) Different firmware: A KERMIT version linked on an A-600
will probably run OK on an A-900, but it is possible that
the reverse is not true. Similar implications exist for
RTE-6 systems, where one machine may have Fast Fortran
and another may not. "RPL CHANGE" warnings should not be
taken lightly!
4) You have force-loaded KERMIT because there were some un-
defined references. This practice is strongly discouraged
anyway, because there is very little code that KERMIT uses
which it can do without.
For those of you with "D" firmware on their multiplexers, enjoy!!!
While revision 1.99 does not take any particular advantage of the
special features this card provides, it performs one of the better
terminal-emulation jobs I have seen and can transfer packets well.
I strongly recommend that XON/XOFF protocol be enabled where the
connected devices will support it. NOTE: "D" mux support is not
exhaustively tested yet, but please DO report problems you find!
-- WARNING -- WARNING -- WARNING -- WARNING -- WARNING --
In order to use this KERMIT revision with the D mux, you MUST be
using driver revision 4.10 and firmware revision 4.10 or later!
BETA soft/firmware WILL NOT WORK! [KERMIT will seem to work well
for a while, then the mux card(s) involved will CRASH!]