




BEACON File Transfer Guide






Version 0.6
May 15, 1986








Systems  Communications Group

Computing Services
School of Business Administration
University of Michigan
	The University of Michigan's School of Business Administration has developed BEACON, a terminal emulation program for the Burroughs B25 workstation.  One feature of BEACON is the ability to transfer files over an asynchonous communications line using many file transfer protocols.  The file transfer protocols supported are ASCII and BINARY (the same protocols used in Burrough's ATE), XMODEM and KERMIT.  This manual is meant to be an introduction to KERMIT file transfer between the Burroughs B25 and MTS (Michigan Terminal System).  Users interested in using any of the other file transfer protocols (other than KERMIT) should refer to Appendix A of this document.

	Now, a few words about the KERMIT file transfer protocol.  The KERMIT file transfer protocol was designed and developed at the Columbia University Center for Computing Activities by Bill Catchings and Frank da Cruz.  The initial objective of KERMIT was to provide a facility for archiving mainframe files on microcomputers.  KERMIT has quickly been adopted by many computer users because it allows any two computers to exchange files.  The KERMIT protocol was named after Kermit the Frog, star of the television series THE MUPPET SHOW.
Sending a Text File to MTS

First, we must enter MTS's versions of KERMIT.  This involves issuing the KERMIT run command.

$RUN *KERMIT <Return>

Execution begins
KERMITUM>    MTS KERMIT (UM) Version 1.17 (13:59 Aug 285)
KERMITUM>

Next, we must instruct MTS's KERMIT to get ready to accept a file.  To do this, we must issue the RECEIVE command.

KERMITUM>RECEIVE <Return>
KERMITUM>Preparing to receive file.

At this point, MTS's KERMIT is ready to receive a file.  Now we must instruct BEACON to SEND a file to MTS.  For this example, we will send a BTOS file by the name of message.

<Move> SENDFILE message <Return>

After about 10 seconds, the file transfer should begin.  The number of packets correctly transfered will constantly be updated in BEACON's Status Line.  The <Mark> key will interrupt the file transfer at any time.  

KERMITUM>File received successfully.
KERMITUM>

Now the file has been transfered.  Note that the KERMIT file transfer protocol sends the name of the file along with the file's contents.  This means that MTS's KERMIT uses the BTOS  file name as the resulting MTS file name.  (The file that was just sent to MTS is in the MTS file message.)  Note that the BEACON command SENDFILE accepts an optional second parameter which is the desired resulting MTS file name.

To exit MTS's KERMIT, issue the following commmand.

KERMITUM>STOP <Return>
Execution terminated

Receiving a Text File to MTS
First, we must enter MTS's versions of KERMIT.  This involves issuing the KERMIT run command.

$RUN *KERMIT <Return>

Execution begins
KERMITUM>    MTS KERMIT (UM) Version 1.17 (13:59 Aug 285)
KERMITUM>

Let's assume for this example that we want to transfer the MTS file SIGFILE down to the B25.  We must instruct MTS's KERMIT to get ready to send the file.  To do this, we must issue the SEND command.


KERMITUM>SEND SIGFILE <Return>
KERMITUM>Preparing to send file 'SIGFILE'.

At this point, MTS's KERMIT is ready to send the file.  Now we must instruct BEACON to RECEIVE the file from MTS.

<Move> RECEIVEFILE <Return>

After a slight delay (10 seconds), the file transfer will begin.  The user can abort the file transfer at any time by hitting the <Mark> key.

KERMITUM>File sent successfully.
KERMITUM>

Now the file has been transfered.  Note that the KERMIT file transfer protocol sends the name of the file along with the file's contents.  This means that the MTS file name is used as the file name of the new BTOS file.  Note that the BEACON command RECEIVEFILE accepts an optional parameter which is the desired resulting MTS file name.

To exit MTS's KERMIT, issue the following commmand.

KERMITUM>STOP <Return>
Execution terminated

Transfering Binary Files
First, we must enter MTS's versions of KERMIT.  This involves issuing the KERMIT run command.

$RUN *KERMIT <Return>

Execution begins
KERMITUM>    MTS KERMIT (UM) Version 1.17 (13:59 Aug 285)
KERMITUM>

First, we must specify to MTS's KERMIT that we are transfering binary files.  This is needed to inhibit ASCIIEBCDIC translation.

KERMITUM>SET FILETYPE BINARY <Return>
KERMITUM>Binary filetype set.
KERMITUM>

Next, we need to tell BEACON that we want to transfer binary files.  This involves issuing the two BEACON commands BINARYFILETYPE and SETEIGTHBITPREFIX.

<Move> BINARYFILETYPE TRUE <Return>
<Move> SETEIGTHBITPREFIX TRUE <Return>

Now file transfer can proceed as described in the above sections.  From this point onward, all files that are transfered will be binary files.  To return to transfering normal text files, the binary file commands must be undone.  This is performed as follows.


KERMITUM>SET FILETYPE TEXT <Return>
KERMITUM>Text filetype set.
KERMITUM>

<Move> BINARYFILETYPE FALSE <Return>
<Move> SETEIGTHBITPREFIX FALSE <Return>
Appendix A:  File Transfers Using NonKERMIT Protocols
	It is also possible to transfer files using the ASCII, BINARY, and XMODEM file transfer protocols.  (Note that ASCII and BINARY are the file transfer protocols available in Burroughs's Asynchronous Terminal Emulator, and XMODEM is a file transfer protocol developed for CPM and MSDOS based personal computers.)  

Sending a File Using a nonKERMIT Protocol

First, select the file transfer protocol which will be used in file transfer.  (In this example, we will use XMODEM, but ASCII and BINARY will use the same command sequence.)


<Move> SETTRANSFERTYPE XMODEM <Return>


File transfer now procedes with the same command sequence as with the KERMIT file transfer protocol.  Next, we must instruct the host to receive the file (using whatever command the host requires for receiving a file).


Receive <Return> (or whatever the host requires)


Now instruct BEACON to send the file.


<Move> SENDFILE <filename> <Return>


The file transfer will proceed similar to a KERMIT file transfer.  The <Mark> key can be used to interrupt file transfer at any time.


Receiving a File Using a nonKERMIT Protocol

First, select the file transfer protocol which will be used in file transfer.  (Again, we will use XMODEM, but ASCII and BINARY will use the same command sequence.)


<Move> SETTRANSFERTYPE XMODEM <Return>


File transfer now procedes with the same command sequence as with the KERMIT file transfer protocol.  Next, we must instruct the host to send the file (using whatever command the host requires for receiving a file).


Send <Return> (or whatever the host requires)


Now instruct BEACON to receive the file.


<Move> RECEIVEFILE <filename> <Return>


The file transfer will proceed similar to a KERMIT file transfer.  The <Mark> key can be used to interrupt file transfer at any time.

Appendix B:  BEACON File Transfers Commands
	Here is an excerpt from the BEACON reference manual which contains a description of all the KERMIT related commands.  Most of the BEACON parameters which pertain to KERMIT use the recommended KERMIT default values and should not need to be modified by the user.

BinaryFileType
	The purpose of this command is to specify that the next file being transferred is a binary file.  Specifying a file as type binary will inhibit the mapping of kermit's endofrecord specifier (<carriage return><line feed>) to BTOS's endofrecord specifier (<line feed>).  This command requires one boolean parameter (either TRUE or FALSE) and the initial value of this parameter is FALSE.  The syntax of this command is as follows:
BinaryFileType			<TRUE|FALSE>
Bye
	The purpose of this command is to terminate connection between BEACON and a KERMIT server program.  This command sends a KERMIT packet to host to instruct the host to disconnect.  This command is only useful when connect to a host which is a KERMIT server.  The syntax of this command is as follows:
Bye
Finish
	The purpose of this command is to instruct the host to exit KERMIT server mode but to remain connected.  This command sends a KERMIT packet to host to instruct the host to leave KERMIT server mode.  This command is only useful when connect to a host which is a KERMIT server.  The syntax of this command is as follows:
Finish
Get
	The purpose of this command is to instruct the host's KERMIT server to send a file from the host to the local B25.  This command is only needed when connected to a host which is a KERMIT server.  The syntax of this command is as follows:
Get	<Host filename>			[Local filename]
LogTransactions
	The purpose of this command is to initiate and terminate the logging of file transfer.  Packet content and program status appear in the log file.  This command accepts one string parameter which is the name of the log file.  Logging is terminated by using this command with no parameters.  The syntax of this command is as follows:
LogTransactions			[Log file name]
ReceiveFiles
	The purpose of this command is to place BEACON into receive file mode.  An optional string parameter may be specified which will be used as the local file name for the first incoming file.  (Note that when in receive file mode, the kermit protocol allows for the reception of more than one file.  Filenames are transferred with files.)  The syntax of this command is as follows:
ReceiveFiles			[BTOS file name]
Remote
	The purpose of this command is to send executable commands to the host KERMIT server.  This command accepts one or two parameters.  The first parameter is a valid host command (in proper syntax) and the optional second parameter is the KERMIT packet type used for transmission of the command to the host.  (The default value of the second parameter is K.)  This command is only useful when connected to a host KERMIT server.  The syntax of this command is as follows:
Remote  <valid host command>  [KERMIT packet type]
SendFiles
	The purpose of this command is place BEACON in send file mode.  This command requires one string parameter which is used as the name of the BTOS file to send.  An optional second string parameter is the desired file name on the host system.  If no second parameter is specified, then the BTOS name of the file will be used as the host's file name.  The syntax of this command is as follows:
SendFiles		<BTOS file name>			[Host file name]
Server
	The purpose of this command is place BEACON in KERMIT server mode.  This will allow the computer at the other end of the connection to send file transfer requests in KERMIT server packets.  Currently, KERMIT server mode only supports requests for file transfer and remote specification of BEACON commands.  The <Mark> key can be used to exit KERMIT server mode.  The syntax of this command is as follows:
Server
SetEigthBitPrefix
	The purpose of this command is to enable the Kermit 8th bit prefixing mechanism.  This allows for the transmission of 8 bit data through a 7 bit network.  This command requires one boolean parameter.  Of value of TRUE for this parameter enables the request for 8th bit prefixing to be performed.  (Note that both computers have to agree to perform 8th bit prefixing.)  The initial value for this command is FALSE.  The syntax of this command is as follows:
SetEigthBitPrefix				<TRUE|FALSE>
SetEigthBitPrefixChar
	The purpose of this command is establish the ASCII character used as the 8th bit prefixing character.  The default value for this character is .  The syntax of this command is as follows:
SetEigthBitPrefixChar				<Prefix character>
SetReceiveEOLChar
	The purpose of this command is to establish the EndOfLine character that BEACON requires with all incoming packets.  The default value for this parameter is ASCII 13 (Carriage Return).  The syntax of this command is as follows:
SetReceiveEOLChar				<EndOfLine character>
SetReceiveEORString
	The purpose of this command is to establish which EndOfRecord delimiter to expect when receiving text files.  Acceptable values for this parameter are CR (<Carriage Return>), LF (<Line Feed>), or CRLF (<carriage Return><Line Feed>).  The initial value for this parameter is CRLF.  The syntax of this command is as follows:
SetReceiveEORString				<CR|LF|CRLF>
SetReceivePacketLength
	The purpose of this command is to specify the maximum length of BEACON's receive packets.  Packet lengths must be between 10 and 94 characters (inclusive).  A user might want to specify shorter packets if the connection with the other computer is noisy.  The default packet length is 94 characters.  The syntax of this command is as follows:
SetReceivePacketLength				<integer>
SetReceivePadChar
	The purpose of this command is to specify which character should be sent before receiving packets from the other computer.  (The number of times this character is sent is specified by the SetReceivePadCount command.)  The default value for this character is ASCII 0 (NUL).  The syntax of this command is as follows:
SetReceivePadChar				<Pad character>
SetReceivePadCount
	The purpose of this command is to specify the number of pad characters that must be sent by the other computer before sending a packet to BEACON.  (see SetReceivePadCount)  The default value for this count is zero (which means no padding is performed).  The syntax of this command is as follows:
SetReceivePadCount				<integer>
SetReceiveStartOfPacketChar
	The purpose of this command is to specify which character to look for which designates the beginning of a receive packet.  The default value for this character is ASCII 1 (SOH).  The syntax of this command is as follows:
SetReceiveStartOfPacketChar					<Startofpacket character>
SetReceiveTimeOut
	The purpose of this command is specify the amount of time (in seconds) to wait for a packet.  The default value for this timeout is 10 seconds.  If the program does timeout, appropriate action will be taken.  (Either resending the last packet, or aborting the file transfer.)  The syntax of this command is as follows:
SetReceiveTimeOut				<integer (seconds)>
SetRepeatPrefixChar
	The purpose of this command is to specify which character will be used as the repeat prefix character.  The initial character used is  (tilde).  The syntax of this command is as follows:
SetRepeatPrefixChar				<Prefix character>
SetRetryInitialCount
	The purpose of this command is to specify the number of times to retry the first packet before aborting.  The default value for this parameter is 10.  The syntax of this command is as follows:
SetRetryInitialCount				<integer>
SetRetryPacketCount
	The purpose of this command is to specify the number of times to resend packets which are not received correctly before aborting.  The default value for this parameter is 5.  The syntax of this command is as follows:
SetRetryPacketCount				<integer>
SetSendEOLChar
	The purpose of this command is specify the EndOfLine character on outgoing packets.  This character is usually set by the other computer.  The default value for this character is ASCII 13 (Carriage Return).  The syntax of this command is as follows:
SetSendEOLChar				<EndOfLine character>				
SetSendEORString
	The purpose of this command is to establish which EndOfRecord delimiter to use when sending text files.  Acceptable values for this parameter are CR (<Carriage Return>), LF (<Line Feed>), or CRLF (<carriage Return><Line Feed>).  The initial value for this parameter is CRLF.  The syntax of this command is as follows:
SetReceiveEORString				<CR|LF|CRLF>
SetSendPause
	The purpose of this command is to specify the number of seconds to delay before sending the first packet.  The initial value of this parameter is zero (no delay).  The syntax of this command is as follows:
SetSendPause			<integer (seconds)>
SetSendQuoteChar
	The purpose of this command is to specify the character that is used for control quoting in outgoing packets.  The initial value for this character is .  The syntax of this command is as follows:
SetSendQuoteChar				<Quote character>
SetSendRecordWrap
	The purpose of this command is to enable linewrapping of outgoing files.  When this function is enabled, an SendEOLString is inserted in the record assuring lines of maximum length specified by SendRecordWrapCount (see the next command).  This initial value of this parameter is FALSE.  The syntax of this command is as follows:
SetSendRecordWrap				<TRUE|FALSE>
SetSendRecordWrapCount
	The purpose of this command is to establish the maximum line length of outgoing files.  This parameter is enabled by the SetSendRecordWrap parameter (see the previous command).  When SendRecordWrap is enabled, an SendEOLString is inserted in the record assuring lines of maximum length specified by this parameter.  This initial value of this parameter is 80.  The syntax of this command is as follows:
SetSendRecordWrap			Count	<maximum linelength>
SetSendStartOfPacketChar
	The purpose of this command is specify the first character of a send packet.  The initial value for this character is ASCII 01 (SOH).  The syntax of this command is as follows:
SetSendStartOfPacketChar					<Startofpacket character>
SetServerTimeout
	The purpose of this command is specify the timeout value (in seconds) when KERMIT is in server mode (see Server command).  The initial value of this parameter is 120.  The syntax of this command is as follows:
SetServerTimeout				<Timeout value (in seconds)>
SetTransferType
	The purpose of this command is to specify the protocol used for file transfer.  BEACON supports ASCII and BINARY (the two file transfer protocols supported by Burroughs ATE), KERMIT and XMODEM.  Note that ASCII, BINARY, and XMODEM require a serial port configuration of DATABITS=8, PARITY=N, and XONXOFF=FALSE.  The initial value for this parameter is KERMIT.  The syntax of this command is as follows:
SetTransferType  <ASCII|BINARY|KERMIT|XMODEM>
SetXModemBinaryFiletype
	The purpose of this command is to disable CRLF to LF mapping of files sent using the XModem file transfer protocol.  The initial value for this parameter is TRUE.  The syntax of this command is as follows:
SetXModemBinaryFiletype					<TRUE|FALSE>