home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Columbia Kermit
/
kermit.zip
/
old
/
misc
/
prime
/
prime814.bwr
< prev
next >
Wrap
Internet Message Format
|
2020-01-01
|
11KB
From C20211@UK.AC.POLY-SOUTH-WEST.PRIME-A Fri Feb 7 09:44:37 1992
Via: uk.ac.poly-south-west; Fri, 7 Feb 92 09:44:31 GMT
Date: Fri, 07 Feb 92 09:42:45
From: John Horne <C20211@UK.AC.POLY-SOUTH-WEST.PRIME-A>
Subject: Prime Kermit version 8.14 - PRIME.BWR file
To: pdjayne
Status: OR
From : John Horne, Computing Service, Polytechnic South West.
Email : C20211 @ UK.AC.PSW.PA
The following is a list of known bugs and potential problems in the current
version of Prime Kermit. It is possible for some of the problems to be
resolved at each individual site by the person responsible for installing
Kermit, although this may require some minor code changes.
This version has been tested at PRIMOS revisions 21.0.5q and 22.1.1b.
(It has also been run, but not 'rigorously' tested, at Primos rev 23.2.0b).
1) Odd file lengths are indicated by setting the read/write lock of the file
to NONE. This will fail (with no warning) if the user does not have P or
O rights to the directory. The consequence of this is simply a final
control-Z in the file. Also if the file initially has a read/write lock
of NONE, then the final character may be lost. I know of no other way of
"marking" the file as being of odd length. Any ideas?
2) TAKE files try to dynamically obtain a file unit to use. However, it is
not known what range of file units a user is allowed. So the range from
7 to 127 is used. Some sites may have limited this range, and so a change
to the code may be necessary if this is a problem.
3) The Date/Time file created (DTC) attribute can only be set if the user
has P or O rights. No warning is given if this cannot be set from the
received attribute packet.
4) Some of the code uses the Primos subroutine T$AMLC to transfer data along
an AMLC line. Unfortunately this subroutine only returns a zero for
success, or a one for failure. In the case of a failure Kermit will abort
the operation, since it cannot correct the problem without knowing what
it is! It will then display a brief, although possibly vague, message.
5) The end-of-line characters expected in text files must be either a single
line-feed (LF), a single carriage-return (CR), or a carriage-return (CR)
followed by a line-feed (CRLF). However, the sequence LFCR will not be
handled correctly. It is not expected that this will cause any problems!
6) The command "SET BAUD baud_rate" allows only 8 speeds to be specified.
The first four are 110, 134.5, 300, and 1200, these are fixed within
Primos. The next value is the programmable clock speed specified by the
CONFIG directive AMLCLK for the computer. Its default value is 9600, but
may be changed by the system administrator. The final three values are set
by hardware jumpers within the computer, the default values are 75, 150,
and 1800. These may also have been changed at the request of the system
administrator by Prime. It would be nice to be able to ask Primos what
these values are, but this is not possible. So it is up to the user to
ask the system administrator if none of the other values are suitable.
Also note that 110 baud will use 2 stop bits, but 75 baud will only use
1. This is because we cannot guarantee that JUMPER_1 is actually 75 baud!
HOWEVER, at PRIMOS revision 22.1 it is possible to ask the computer what
baud rates are supported on AMLC lines. It is also possible to set any of
about 20 speeds for ICS lines. So Kermit version 8.14 now only checks on
the validity of the speed, and lets Primos sort out whether the hardware
actually supports it. The supported baud rates are not shown at all by
Kermit, except for those computers using pre-rev 22 Primos when the
default values of CLOCK, JUMPER_1, JUMPER_2, and JUMPER_3 will be shown.
7) The "SET TIMEOUT" command can only set the local send packet timeout, the
receive packet timeout has to be set from the "other" Kermit program.
The "SHOW TIMEOUT" command will show a value for the receive packet
timeout, but this will be either an initial default value supplied by the
local Kermit program or the last value received by Kermit from a file
transfer.
8) The MS-DOS pound conversion facility may seem to switch from OFF to ON
occasionally. This occurs because the conversion is turned ON or OFF
depending on the information Kermit receives - either from the user or
from the remote Kermit during a transfer. E.g. Setting the file type to
binary will set it OFF, a SHOW command will verify this; if a file is
now received from an MS-DOS machine (and the attributes packet is sent)
then the conversion is set ON since Prime Kermit detects that it is
coming from a DOS machine. Again a SHOW command will verify this.
This is not harmful since the pound conversion is only actually performed
when files are sent, not received. At that time the deciding factors are
whether the conversion has been explicitly set by the user (either ON or
OFF), or whether it is a binary file (setting it OFF).
The Prime Kermit code has been written to assume that the pound conversion
is always ON unless either of the two deciding factors above is true. So
after sending a file (or receiving one from an MS-DOS machine), the pound
conversion is set back to the default of ON; hence the conversion seems to
switch from OFF to ON.
9) The acknowledgment received to the file name may have the file name
encoded with repeat characters. E.g. the file "X0000001" may be
acknowledged as "X~$01". This will be treated by Prime Kermit as a
different file name and reported as such. The code for repeat character
processing is somewhat long-winded, and so has not been included in the
file name acknowledgment section. This should not give users any real
problems since it is possible to still work out the correct file name.
10) Bug fix 44 in the PRIME.HLP file should be corrected by having a
SET SERVER TIMEOUT n command. This will be done later.
11) Sliding windows do not work when the Prime is dialing into a C-Kermit or
MS-Kermit machine.
12) The code for sizing ASCII files is at the moment inefficient, due to the
first part of the file being scanned twice. The first scan determines the
file type, and the second then actually sizes it if it is an ASCII file.
This could be recoded to only parse the file once, and if a binary file
then only the first part needs to be examined.
13) Some commands, e.g. SERVER, SEND, and RECEIVE, do not work from within
a TAKE file. These commands expect to receive packets from the current
'input stream' which would normally be the 'other side' e.g. a PC, but
TAKE files get their input from the file itself.
------------------------------
Date: Mon, 12 Oct 92 12:17:22
From: John Horne <C20211@PRIME-A.PLYMOUTH.AC.UK>
Subject: Re : Prime Kermit and Primos rev 21.
> Sharon Torregrossa, of Parker-Gull Inc., (516)231-6551, is trying
> to build Kermit under PrimeOS v. 21.0.6. She's using John Crawford's
> installation script which has: ...
> error:condition "LINKAGE_FAULT$" raised at 2022(3)153170 entry name
> "F$MA11" not found
The segemnt 2022 refers to the PLP compiler. And it is trying to locate the
library F$MA11. This is in the library SYSTEM_LIB$PRG.RUN found in the
directory LIBRARIES*. HOWEVER, this is true at PRIMOS revisions 22 and 23.
At rev 21 it will be in either PRIMOS_LIBRARY.RUN or SYSTEM_LIBRARY.RUN.
The problem is not in J. Crawford's script, nor in Prime Kermit.
I received a later message from John Crawford about this :
> Actually, Sharon is not using my installation script, as it was not
> updated for the newest version of the kermit distribution for Primos.
> Rather, she painfully hand edited the large file and finds herself
> with problems that go beyond the Kermit distribution. Namely,
> the version of the compiler (PLP) she is using is not functioning
> under the version of the operating system she currently has.
> (The plp compiler is for a more recent version of Primos).
Having received this message I would say the problem is caused by using an
incompatible version of the PLP compiler with the libraries. The libraries
form a standard part of Primos. The PLP compiler should be using the search
rules to locate any routines required. In this respect it shouldn't matter
which library they are in, so long as the compiler can find them. I would
suggest checking the search rules, but, since I assume everything else is
working okay, the library must be present in the search rule.
Prime have been a bit 'sticky' about installing the correct version of
languages with the correct OS libraries during the past few revisions. It
would seem that this is one of the reasons why.
As said above the problem is not in Kermit since it doesn't, as it were,
get that far. The problem is with the compiler. This sort of remote
diagnostics is difficult, and without a look around their system I can't
suggest much more. Typing LLENT -EN F$MA11 at the command level, should
show which library the routine is in. If it is not in the search rules,
then it won't find it. So then try ATTACH LIBRARIES*; LLENT *>@@ -EN F$MA11
this will look in all the libraries regardless of the search rules.
> As for the Kermit distribution for Primos, I would suggest that an
> easy unpacking mechanism is needed (as evident by the calls I have
> received from Prime sites). Since my script is out-of-date and not
> updated by John Horne and friends, I suggest it (and my name) be removed
> from the prime.ann file.
I received some mail from John about this a long time ago. I contacted my
colleague, Matt Sutter, in the USA about this at that time. Neither he nor
I have had any requests for such a file to be included in the distribution
of Prime Kermit. So it was decided to not support it for the moment, but will
do so if there were sufficient requests for it. I still have had no-one ask
for this sort of thing at all. I shall, however, look into producing a
'build' file to be included for distribution, although this may take a little
time due to current work. (Re-reading above, we did obviously get one request
for it - from John himself).
If you want any further info, or suggestions the let me know,
good luck,
John Horne,
University of Plymouth, UK.
------------------------------