home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Columbia Kermit
/
kermit.zip
/
archives
/
honeywellgcosa.tar.gz
/
honeywellgcosa.tar
/
hd6ker.bwr
< prev
next >
Wrap
Text File
|
1990-10-03
|
10KB
|
204 lines
HD6KER.BWR
This file contains information about Superkermit idiosyncrancies and
known problems up to Version 2.00. Honeywell 3.1 support is still
provided (only in conjunction with MSKermit 3.02!) however, the
increased size of Superkermit may impact 3.1 applications. MSKermit
3.02 provides limited support for Honeywell terminals (TTY line-mode
only) with 3 special commands to support the Honeywell DPS-6:
set terminal honey ; give proper term resp; both 3.1 and 4.0 op. systems.
set rec ignore 10 ; ignore LF in long packets; both 3.1 & 4.0 op. systems.
set sen double 92 ; send 2 '\' chars out; 3.1 op. system only!.
o Superkermit can now do wildcard 'sends' and process micro Kermit
wildcard 'gets'. Only files matching the wildcard parameter AND
conforming to the file type (ASCII or binary) given on the Super-
kermit command line will be downloaded. For instance, if you enter
the following Honeywell DPS-6 command:
SUPERKERM SA *.C <c/r>
You will (S)end all (A)scii files with a 'C' filename extension
to the receiving Kermit. As usual, the Honeywell DPS-6 has an
idiosyncracy...to receive ALL files of a given type you must use an
'**' wildcard in the 'send' or 'get' command and not the '*.*'
wildcard of MSDOS fame. This routine makes use of the Honeywell
'C' compiler heap, therefore the new batch compilation file that I
have included MUST be used to build executable Superkermit. A limit
of 100 files may be transferred using a wildcard. Since this new
routine checks for correct file types even in non-wildcard file
transfers, only host files of the proper type are 'visible' to
the get or send command.
o By popular demand, Superkermit now has the ability to change
working directories on Honeywell host systems while in server mode.
Unfortunately, the directory delimiter on the DPS-6 is the '>'
(greater than) symbol. For some reason MSKermit does not correctly send
a directory name with three or more '>' characters such as:
'remote cd >UDD>DREANO>TEST (c/r)'
Packet logging reveals the above directory name is truncated to
'>UDD>DREANO' by MSKermit. Therefore, I have allowed users the
option of substituting the '/' character in Honeywell directory
names, a la UNIX:
'remote cd /UDD/DREANO/TEST (c/r)' Go to regular directory
'remote cd ^PACK/UDD/DREANO (c/r)' Go to a specific pack
'remote cd .. (c/r)' Go to parent directory
'remote cd (c/r)' Go to home directory
(It wouldn't suprise me if the '>' problem didn't have some kind of
conflict with MSDOS I/O redirection which uses the same character;
I have hit this kind of snag before.)
o Superkermit can now accept an MSKermit command to change the type of
files (TEXT or BINARY) that Superkermit will 'get' while in host
server mode; once this process is performed the server STAYS in the
new mode until it either exits or a new file type is asked for:
'remote set file type text (c/r)'
'remote set file type binary (c/r)'
CAUTION: This also changes the mode for files RECEIVED by the
Superkermit server. Therefore, either 1) never change modes from the
original server command invocation or 2) always perform the above
'remote set file type' command appropriate for the file(s) you are
preparing to upload. Failure to do this will result in the WRONG
type file being created on the Honeywell. If you ever get an MSKermit
error like: 'No valid names in GET request', and you KNOW that the
file is on the host, it is a good bet that Superkermit is NOT set
for the proper file type.
o There is now an extra file type in Superkermit for the transfer of foreign
file types (e.g. MSDOS: *.EXE, *.COM, *.WKS, etc.). It may be invoked
from the Superkermit command line with an 'F' argument. This option
allows MSDOS executable files to be stored on the Honeywell and then
retreived correctly on a PC. Since the 'remote set file type' command
only has 'text' and 'binary' arguments (see paragraph above), I have
implemented a special Superkermit server command to handle these files:
'remote kermit foreign (c/r)'
This was a conscious design decision which allows Superkermit to store
a foreign file's attributes within the file itself on the Honeywell and
they are then sent to a receiving Kermit during downloads.
If you use Kermit file attribute packets MSDOS, UNIX, etc. files will be
EXACTLY reproduced on the original hardware with correct creation
dates, file access rights, etc.. Without file attributes host system
defaults will be used. Also, the fsize() routine is used to locate DPS6
'foreign' files and may prove to be operating system version specific
(it is the only Superkermit code that is not regular 'ole 'C' routines).
ASCII files uploaded in foreign mode will NOT be formatted for perusal.
If you want to look at a text file on the DPS-6 upload it in text, not
foreign mode. I strongly encourage the use of a Public Domain MSDOS file
archival/compression program such as PKZIP to cut down on file transfer
times both ways. The 'foreign' file ability also works with the VIP-3
terminal emulator/file transfer package but is considerably slower than
with MSKermit.
o To support both 8th-bit prefixed and image mode binary file transfers
two new Kermit commands are available. If no mode is ever specified
the default is 8th-bit prefixed:
'remote kermit image (c/r)'
'remote kermit prefix (c/r)'
NOTE: The Superkermit server will automatically switch to ASCII file mode
temporarily in order to do the following 'remote' commands and then
switch back to the previous mode (FOREIGN, ASCII, BINARY).
o Superkermit will now respond to MSKermit commands to type a file
from the host WORKING directory to the microcomputer screen. If the
file to be typed is not ASCII the command returns the same error as
a 'get' of a non-existant host file:
'remote type myfile (c/r)'
o Re-implemented the server ability to do a Honeywell host system
command. It is much cleaner, less exotic, and sends the results
of the command (for better or worse) directly to the PC screen
for instant gratification. These results could probably be re-
directed from MSKermit to a disk file or interpreted through a
MSKermit script to do many useful functions such as checking the
available space on a pack prior to a file upload or verifying
the success of a 'remote cd' command. NEVER execute an interactive
host command (such as the Honeywell line editor) with this facility
since it is implemented using I/O redirection to files and not human
interaction!.
'remote host STS -ALL (c/r)'
'remote host LWD (c/r)'
o The 'remote dir' command works and is really a DPS-6 'LS' command:
'remote dir *.c (c/r)'
o The 'remote delete' command is really a DPS-6 'DL' command
'remote delete *.c (c/r)'
o The 'remote message' command is really a DPS-6 'MSG' command
which sends the string to the operator's console:
'remote mess How are you? (c/r)'
o The 'remote who' command is really a DPS-6 'VIDEO' command and
any arguments are ignored:
'remote who (c/r)'
o Avoid the 'remote space' command; it seems to send a misformed packet.
Use instead: 'remote host STS -ALL (c/r)'.
o The server 'logout' command works but is not very pretty since it
causes a Superkermit 'C' signal trap...but it gets you off the DPS-6.
If you are NOT running in a Honeywell 'swappool/pagepool' you can spawn
a task to do the 'bye' with a time argument and the 'C' trap will not
occur. Replace the 'byenow' string in HD6KER.H with:
>SYSLIB2>ST 0 -EFN >SYSLIB2>BYE -DFR MS=3000 -ARG -BF
o Performed a much-needed clean up of code placing all compiler pre-
processor code along with global/external variables and function
prototypes in a separate file. In addition, I have adopted the
Columbia University naming conventions for the source files:
HD6KER.BWR - 'Beware' file of Superkermit bugs.
HD6KER.DOC - Version 2.00 documentation.
HD6KER.H - New include file described above.
HD6KER.C - Kermit state switchers and heuristics.
HD6PRI.C - Kermit protocol primitives.
HD6COMP.EC - New Kermit batch compilation JCL.
o If Superkermit is run as a server on a dedicated line and a
direct connect microcomputer is turned off, it is the same as
an interactive Honeywell user hitting the 'break' key and the
Superkermit server is suspended. To avoid this Superkermit
should be started from an EC that performs the '>SYSLIB2>BRKF'
command to disable 'break' processing - this may NOT be desirable
in every case.
I believe the above improvements have resulted in a much more
useful Superkermit 'server' mode as well as more manageable source code.
My thanks to Tim Ewing of Honeywell Federal Systems Incorporated (HFSI)
in McLean, Virginia for suggesting and testing some of the above changes.
If I had it to do over again I think I would have made all of the debug
file output code dependent on a compiler switch (e.g. #ifdef DEBUG) so
it would only be compiled in if you needed it. I feel that the code
reorganization and additional server functionality have made this a
major release and I am calling it Version 2.00. The work done by
Joe R. Doupnik of Utah State University on MSKermit 3.02 to make it usable
with the Honeywell DPS-6 is greatly appreciated.
Frank Dreano Jr.
/*** End of HD6KER.BWR ***/