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 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 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. ------------------------------