Columbia Kermit/kermit.zip/honeywellgcosa/hd6ker.bwr

Text File | 2020-01-01 | 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                         ***/