5 [File VMSMIT.DOC, Chapter 7 of the Kermit User Guide] 7.

5 [File VMSMIT.DOC, Chapter 7 of the Kermit User Guide] 7.

5 [File VMSMIT.DOC, Chapter 7 of the Kermit User Guide] 7.

VAX/VMS KERMIT I Authors: Robert C. McQueen, Nick Bush, Stevens

Institute of Technology Language: BLISS-32 Version: 3.3 Date:

April 2, 1986 + VAX/VMS Kermit-32 Capabilities At a Glance: (

Local operation: Yes( Remote operation:

Yes( Transfers text files: Yes( Transfers binary files:

Yes( Wildcard send: Yes( ^X/^Y interruption:

Yes( Filename collision avoidance: Yes( Timeouts:

Yes( 8th-bit prefixing: Yes( Repeat character compression: Yes( Alternate block check types: Yes(

Communication settings: Yes' Transmit BREAK:

No ( IBM mainframe communication: Yes( Transaction logging:

Yes( Session logging (raw capture): Yes( Debug logging:

Yes( Raw transmit: Yes' Login scripts:

No ( Act as server: Yes( Talk to server:

Yes( Advanced commands for servers: Yes( Local file management:

Yes( Command/init files: Yes' Attribute packets:

No O Kermit-32 is a program that implements the Kermit file transfer protocol for O the Digital Equipment Corporation VAX series computers under the VAX/VMS O operating system. It is written in BLISS-32 and

MACRO-32, with sources for all O BLISS modules also available as MACRO-32 sources. Kermit-32 should run on any O VAX/VMS system from version

4.0 on (Version 3.1 of Kermit-32 is the last ver- . sion that runs under pre-4.0 releases of VMS). O The first section of this chapter will describe the things you need to know O about the VAX/VMS file system and how Kermit-32 uses it. The second section O describes the special features of Kermit-32. The final section contains infor-

F mation of interest to those who need to install Kermit-32 on a system. 7.1. The VAX/VMS File System O The two main items of interest of the VAX/VMS file system (for the Kermit user) K are the format of file specifications and the types of files and file data. VAX/VMS File Specifications , VAX/VMS file specifications are of the form -


NAME may be up to 9 characters, TYPE may be up to 3 O characters and each item in DIRECTORY may be up to 9 character long. Only al-

> phanumeric characters may be used in DIRECTORY, NAME and

TYPE. O Under version 4.0 (and later) of VMS, NAME, TYPE and each item in DIRECTORY may O be up to 39 characters long, and may contain alphanumeric characters plus un- derscore. O VERSION is a decimal number indicating the version of the file (generation). O DEVICE may be either a physical or logical device name. If it is a logical O name, it may be up to 63 characters long and may contain alphanumeric charac- O ters plus dollar signs and underscores.

NODE may be either a logical name O which translates to a DECnet node name or a physical DECnet node name. In ei- O ther case, access information can be included (see the DECnet-VMS User's guide O for more information). The node name is not normally present, since most files O are accessed on the same node where the user's job is running. The version O number is not normally given (in fact, should not normally be given). When O device and/or directory are not supplied, they default to the user's current O default device and directory. Therefore, NAME.TYPE is normally all that is O needed to specify a file on the user's default device and directory. This

is O also all the Kermit-32 will normally send as the name of a file being trans- ferred. O The node field specifies the name (and access information) for the DECnet node O where the file is located.

Kermit-32 does not transmit the node field to the O target system, but will attempt to honor a node field in an incoming file name. O The device field specifies a physical or "logical" device upon which the file O is resident. The directory field indicates the area on the device, for in- O stance the area belonging to the owner of the file. Kermit-32 does not nor- O mally transmit the device or directory fields to the target system, but will O attempt to honor device or directory fields that may appear in incoming file O names. It will not create new directories, however, so any directory must al-

ready exist. O The name is the primary identifier for the file.

The type, also called the O "extension", is an indicator which, by convention, tells what kind of file we O have. For instance

FOO.FOR is the source of a Fortran program named FOO; O FOO.OBJ might be the relocatable object module produced by compiling

FOO.FOR; N FOO.EXE could an executable program produced by LINKing

FOO.REL, and so forth. O VAX/VMS allows a group of files to be specified in a single file specification O by including the special

"wildcard" characters, "*" and "%". A "*" matches any O string of characters, including no characters at all; a "%" matches any single # character. Here are some examples: O *.FOR All files of type FOR (all Fortran source files) in the default direc-

tory. ) FOO.* Files of all types with name FOO. + F*.*

All files whose names start with F. F F*X*.* All files whose names start with F and contain at least one X. = %.* All files whose names are exactly one character long. ? *.%%* All files whose types are at least two characters long. O Wildcard notation is used on many computer systems in similar ways, and it is M the mechanism most commonly used to instruct Kermit to send a group of files. 5

TEXT FILES AND BINARY FILES O The file system used by VAX/VMS provides for a large number of attributes to be O associated with each file.

These attributes provide some indication of whether O the file is a text file, or is some other type of non-text data. The two major O attributes that affect Pro/Kermit are the record type and record attribute. O The record type describes how logical records are stored in the file.

Records O may be of some fixed length (specified by another attribute), or variable O length (specified within each record), or stream (implying no real record O divisions). The record attributes describe how the breaks between records are O to be treated. For example, a record attribute of implied carriage return O means that any program reading the file with intentions of printing it out O should add a carriage return/line feed sequence between each record. Other at- @ tributes include FORTRAN carriage control and print file format. O The "standard" method of storing text in a file under

VAX/VMS is to store one O line of text per record (variable length records), with a carriage return/line O feed sequence implied by the end of the record (implied carriage return). This O is the method Kermit-32 uses to store files it receives when using FILE TYPE O TEXT. Note that there are other formats which are used to store text under O VAX/VMS, however, the one used be Kermit-32 is the only one which is handled O correctly by all known utility programs under

VAX/VMS. Also, most programs O which work with text files (the editor

EDT, for example) place some limit on O the length of the lines which can be handled. Typically this is 255. O Kermit-32 can write files with up to 4095 characters on a line, which means a O text file from another system may be transferred and stored correctly by A Kermit-32, but may still be unusable by certain VAX/VMS programs. O There is no standard format for storing binary files.

Basically, any record O format with no record attributes are used for binary files. Since programs O which work with binary files under

VAX/VMS expect to see some particular for- O mat, more information is needed for transfer of binary files than for transfer O of text files.

The current version of Kermit-32 is not capable of transferring O all types of binary files which were created on a VAX/VMS system to

another O system and retrieving them intact, nor is it capable of transferring all of O types binary files created on a VAX/VMS system to another VAX/VMS, P/OS, or O RSX-11M/M+ system intact. However, certain formats of binary files can be O transferred, and binary files from some other systems may be transferred to a VAX and recovered intact. O Binary files which are created on a VAX (or other Files-11 systems) with fixed O 512 byte records (a fairly common format) can be transferred using Kermit-32. O The only required action is to set the file type to "fixed" in the receiving

Kermit-32. O Using two programs supplied with Kermit-32, it is possible to transfer almost O any type of sequential file between VAXen, or between a VAX and a P/OS or O RSX-11M/M+ system. These two programs (VMSHEX and VMSDEH) will convert the bi- O nary files to text

(using a variation on Intel hex format). The resulting text O file can be transferred like any other, and finally "dehexified" reproducing O the original file, with the major attributes intact.

Unfortunately, the text O files tend to be about twice the size of the original binary files, so the O transfers take a bit longer than regular text files. On the plus side, the O text versions of the files can be transferred to any system with a Kermit and O still retrieved intact. They can also be transferred over 7-bit data paths O without any problems. The bootstrap procedure (described below), makes use of > hexified versions of the binary file which makes up Kermit-32. = USING THE VAX TO ARCHIVE

MICROCOMPUTER FILES O You can use Kermit to send textual files from a microcomputer or any 8-bit sys- O tem to a VAX/VMS system with no special provisions, since Kermit-32 stores in- O coming files as text files (variable length records with implied carriage O returns) unless it is explicitly told otherwise. But Kermit-32 has no O automatic way of distinguishing an incoming binary file from an incoming text O file. It turns out that because of the method used by Kermit-32 for storing O text files, a binary file can be stored like a text file so long as it does not O contain a string of more than 4095 characters between carriage return, line O feed sequences, and ends with a carriage return line feed. Since most binary O files do not have these characteristics, you must inform Kermit-32 that a file O it is about to receive is to be stored as a binary file. This is done using O the SET FILE TYPE BINARY command. This instructs Kermit-32 to store the data O it receives in the file without checking for carriage return, line feed se- O quences. The file it creates will be variable record length, with no record O attributes. Each record will contain 510 bytes of data, except the last, which O will contain whatever amount is left before the end of the file. This allows O Kermit-32 to correctly return exactly the data it was sent when the file is returned to the original system. O Note that because of the need to use a different file type for binary files, it O is not possible to use a "wildcard send" command to send a mixture of text and O binary files to a VAX system unless the text files are not intended for use on O the VAX; rather, you must send all text files with

Kermit-32's file type set to < text, and all binary files with the file type set to binary. O Once you get the foreign file into the VAX system, stored with the correct file O type, you need take no special measures to send it back to its system of O origin. This is because Kermit-32 honors the record type and attributes of the O file as it is stored on

the VAX. In fact, SET FILE TYPE BINARY or TEXT only O affects how

Kermit-32 receives files - it does not affect how Kermit-32 trans-

mits files. 6 FILES KERMIT-32 CANNOT

HANDLE O The Kermit protocol can only accommodate transfer of sequential files, files 0 which are a linear sequence of bytes (or words). O Some files on a VAX/VMS system are not sequential, and cannot be successfully O sent or received by Kermit-32. These are mainly indexed data files, but can O also include other files which require more than just the data in the file to O be completely reconstructed.

External control information and file attributes are not transmitted. 7.2. Program Operation O Kermit-32's prompt is normally "Kermit-32>". If a foreign command is defined O to run Kermit-

32 (eg. KERMIT := $KERMIT), Kermit-32 will accept a single com- $ mand on the command line, like this: $ $ Kermit send foo.bar the file is sent $ $ MCR Kermit send foo.bar the file is sent $ K You can run the program interactively to issue several commands, like this: $ $ Run SYS$SYSTEM:Kermit

VMS Kermit-32 version 3.3 - Default terminal for transfers is:

_TTA1: Kermit-32>send foo.* files are sent

Kermit-32>statistics ( performance statistics are printed

Kermit-32>receive files are received Kermit-32>exit

$ O Command keywords may be abbreviated to their shortest prefix that sets them 1 apart from any other keyword valid in that field. O Kermit-32 provides most of the commands possible for an

"ideal" Kermit program, O as described in the main part of the Kermit

User Guide. The following sections : will concentrate on systemdependent aspects of Kermit-32. % 7.3. Conditioning Your Job for

Kermit O Kermit-32 does as much as it can to condition your line for file transfer. It O saves all your terminal settings, and restores them after use. However, there O are some sources of interference over which Kermit-32 has no control. In par- O ticular, messages issued by other processes in your job could become mingled O with Kermit packets and slow things down or stop them entirely. This is a O fairly rare occurence and can be easily avoided by not running any other O process which wishes to perform I/O to your terminal while you are running

Kermit-32. O Normally, when Kermit-32 is run, it assumes you wish to use it in remote mode O and perform file transfers over the terminal line which controls your job. O This can be overridden, however, by defining a logical name which equates to O some other terminal line in the system. The default terminal line to be used O for file transfers is determined by the first of the following logical names O which translates to a terminal line which is available for use by your process: O KER$COMM, SYS$INPUT, SYS$OUTPUT, and SYS$COMMAND. If none of these logical O names translate to an available terminal line, there is no default terminal O line and a SET LINE command must be used before any transfer command is per- ; formed. Note that this is the typical case in a batch job. O Kermit-32 will also default the type of parity to be used on the communication O line to that which is set on its default terminal line when it is started. O This means that if all communication at a site is normally done using even : parity (for example), Kermit-32 will also use even parity. O There are two things to keep in mind when using Kermit-32 in local mode (where O the file transfers are done over a different terminal line from where commands

are typed): J - Under VAX/VMS, every terminal line has an owner

UIC and protectionJ code associated with it. This UIC and protection is used to deter-J mine who can allocate (and therefore use) the terminal line when theyJ are not logged in on that line.

Therefore, in order for Kermit-32 toJ be able to perform file transfers over a terminal line other than theJ one on which you are logged in, the field of the protection code forJ the terminal which applies to your job (based on your UIC and theJ owner UIC of the terminal) must allow your job access to the ter-J minal.

You may need to request your system manager to change theJ protection for a terminal line to allow you to use it with Kermit-32 in local mode. J - Terminal lines which have been declared as modem control lines willJ have the phone "hung up" whenever the terminal line becomes freeJ (deallocated). This means that if you do not use the DCL ALLOCATEJ command to allocate the terminal line to your job before enteringJ Kermit-32, exiting Kermit-32 will cause the terminal line to "hangJ up" the modem. If you do wish to get to DCL after having usedJ Kermit-32 to connect a modem control line which you do not have al-J located, you can use the PUSH command to spawn a subprocess running DCL. 7.4.

Kermit-32 Commands O This section describes the Kermit-32 commands -

- in detail where they differ O from the "ideal" Kermit, briefly where they coincide. Kermit-32 has the fol- lowing commands:"

@ synonym for "take". BYE to remote server., CONNECT as terminal to remote system.- EXIT from Kermit-32.'

FINISH Shut down remote server. ( GET remote files from server.- HELP with Kermit-32.9 LOCAL prefix for local file management commands. ' LOG remote terminal session.

LOGOUT remote server. $ PUSH to DCL command level.-

QUIT from Kermit-32.( RECEIVE files from remote Kermit.:

REMOTE prefix for remote file management commands.& SEND files to remote Kermit.( SERVER mode of remote operation."

SET various parameters." SHOW various parameters./

STATUS about most recent file transfer. ? TRANSMIT Transmit

(upload) a file with no error checking. . TAKE Kermit-32 commands from a file. ! 7.4.1. Commands for File Transfer O Kermit-

32 provides the standard SEND, RECEIVE, and GET commands for transfer-

% ring files using the Kermit protocol. /

THE SEND COMMAND Syntax: Sending a file or files: SEND filespec O The SEND command causes a file or file group to be sent from the VAX to the O other system. If filespec contains wildcard characters then all matching files O will be sent, in alphabetical order

(according to the ASCII collating sequence) O by name. If filespec does not contain any wildcard characters, then the single ( file specified by filespec will be sent. ! SEND Command General Operation: O Files will be sent with at least their VAX/VMS file name and type (for instance O FOO.BAR). If a SET FILE NAMING FULL command has been given, Kermit-32 will O also send the device name, directory name and version number (for instance O USER$DISK:[JOE]FOO.BAR;25). If a SET

FILE NAMING UNTRANSLATED command has been O given, Kermit-32 will send the file name, type and version number (for instance O FOO.BAR;25). If a SET FILE NAMING NORMAL_FORM command has been given (this is F the initial default), Kermit-32 will only send the file name and type. O Each file will be sent according to the record type and

attributes recorded in O its file descriptor. Kermit-32 attempts to translate all formats of text file O (including those with FORTRAN or print carriage control) to a format usable on O any system. Note that there is no need to set the FILE TYPE parameter for O sending files, since Kermit-32 always uses the information from the file -

descriptor to determine how to send the file. O If communication line parity is being used (see SET PARITY), Kermit-32 will re- O quest that the other Kermit accept a special kind of prefix notation for binary O files. This is an advanced feature, and not all Kermits have it; if the other O Kermit does not agree to use this feature, binary files cannot be sent cor- O rectly. This includes executable programs (like .EXE files, CP/M .COM files), O relocatable object modules

(.OBJ files), as well as any text file containing " characters with the eighth bit on. O Kermit-32 will also ask the other Kermit whether it can handle a special prefix O encoding for repeated characters. If it can, then files with long strings of O repeated characters will be transmitted very efficiently. Columnar data, O highly indented text, and binary files are the major beneficiaries of this

technique. O If you're running Kermit-32 locally, for instance dialing out from a VAX to O another system using an autodialer, you should have already run Kermit on the O remote system and issued either a RECEIVE or a SERVER command. Once you give O Kermit-32 the SEND command, the name of each file will be displayed on your O screen as the transfer begins. If the file is successfully transferred, you : will see "[OK]", otherwise there will be an error message. O During local operation, you can type Control-A at any point during the transfer O to get a brief status report. You may also type

Control-X or Control-Z to in- ' terrupt the current file or file group. 1 THE RECEIVE

COMMAND Syntax: RECEIVE [filespec] O The RECEIVE command tells

Kermit-32 to receive a file or file group from the O other system. If only one file is being received, you may include the optional O filespec as the name to store the incoming file under; otherwise, the name is O taken from the incoming file header. If the name in the header is not a legal O VAX/VMS file name, Kermit-32 will normally replace the illegal characters with & "X" (see SET FILE NAMING NORMAL_FORM). O If an incoming file has the same name as an existing file, Kermit-32 just O creates a new version of the same name and type, for instance FOO.BAR;3,

FOO.BAR;4. O Incoming files will all be stored with the prevailing file type, ASCII by O default, which is appropriate for text files. If you are asking Kermit-32 to O receive binary files from a microcomputer or other 8-bit system, you must first O type SET FILE TYPE

BINARY. Otherwise, an error may occur when receiving the O file, or a carriage return, line feed will be added to the end of the file and @ the file will be useless when sent back to the system of origin. O If parity is being used on the communications line, then 8thbit prefixing will O be requested. If the other side cannot do this, binary files cannot be trans- ferred correctly. O If an incoming file does not arrive in its entirety, Kermit-32 will normally O discard it; it will not appear in your directory. You may change this behavior O by using the command SET INCOMPLETE KEEP, which will cause as much of the file ) as arrived to be saved in your directory. O If you are running Kermit-32 locally, you should already have issued a

SEND O command (not SERVER -- use the GET command to receive files from a Kermit O server.) to the remote Kermit, and then escaped back to Kermit-32. As files O arrive, their names will be displayed on your screen. You can type Control-A . during the transfer for a brief status report. O If a file arrives that you don't really want, you can attempt to cancel it by O typing Control-X; this sends a cancellation request to the remote Kermit. If O the remote Kermit understands this request (not all implementations of Kermit O support this feature), it will comply; otherwise it will continue to send. If O a file group is being sent, you can request the entire group be cancelled by typing

Control-Z. / THE GET

COMMAND Syntax: GET [remote-filespec] O The GET command requests a remote Kermit server to send the file or file group O specified by remote-filespec. This command can be used only when Kermit-32 is O local, with a Kermit server on the other end of the line specified by SET LINE. O This means that you must have CONNECTed to the other system, logged in, run E Kermit there, issued the SERVER command, and escaped back to the VAX. O The remote filespec is any string that can be a legal file specification for O the remote system; it is not parsed or validated locally. Any leading spaces O before the remote filespec are stripped, and lower case characters are raised

to upper case. O As files arrive, their names will be displayed on your screen. As in the O RECEIVE command, you may type Control-A to get a brief status report, ^X to re- O quest that the current incoming file be cancelled, ^Z to request that the en- ! tire incoming batch be cancelled. O If the remote Kermit is not capable of server functions, then you will probably O get an error message back from it like

"Illegal packet type". In this case, O you must connect to the other

Kermit, give a SEND command, escape back, and give a RECEIVE command. 0 THE STATUS COMMAND 4 Give statistics about the most recent file transfer. /


Syntax: TAKE O Invoke an inferior DCL command processor, to which you may issue any DCL com- + mands. Type LOGOUT to return to Kermit-

32. / THE TAKE COMMAND # Syntax:

TAKE file-spec [ /DISPLAY ] O Where 'file-spec' is any normal VAX/VMS file specification. If file-spec does O not specify a file-type

Kermit-32 will supply a default of .COM. The /DISPLAY O option causes the commands read from the file to be displayed on the user's

terminal. O The TAKE command tells Kermit-32 to execute commands from the specified file. O You may also use the VAX/VMS notation

"@" instead of Take to specify a command file. 7.4.2. Server


SERVER command puts a remote Kermit-32 in "server mode", so that it O receives all further commands in packets from the local Kermit. The

Kermit-32 O server is capable (as of this writing) of executing the following remote server O commands: SEND, GET, FINISH, BYE, REMOTE



WHO, and REMOTE HOST. O Any nonstandard parameters should be selected with SET commands before putting O Kermit-32 into server mode, in particular the file type. The Kermit-32 server O can send all files in the correct manner automatically. However, if you need O to ask

Kermit-32 to receive binary files you must issue the SET FILE TYPE BI-

O NARY command before putting it into server mode, and then you must only send O binary files. You cannot send a mixture of text files and

8-bit binary files B to a Kermit-32 server unless the files are not for use on the VAX. 1 COMMANDS FOR

SERVERS O When running in local mode, Kermit-32 allows you to give a wide range of com- O mands to a remote Kermit server, with no guarantee the that the remote server O can process them, since they are all optional features of the protocol. Com- O mands for servers include the standard SEND, GET, BYE, LOGOUT and FINISH com- % mands, as well as the REMOTE command. Syntax: REMOTE command O Send the specified command to the remote server. If the server does not under-

O stand the command (all of these commands are optional features of the Kermit O protocol), it will reply with a message like "Unknown Kermit server command". O If does understand, it will send the results back, and they will be displayed ( on the screen. The REMOTE commands are: O COPY filespec Copy file. The server is asked to make a copy of the specified O file. Kermit-32 will prompt for the new file name on a O separate line. Both filespecs must be in the correct format O for the remote system. Kermit-32 does not parse or validate O the file specifications. Any leading spaces will be stripped O and lower case characters converted to upper case. Note that O this command simply provides for copying a file within the M server's system - it does not cause a file to be transferred. O CWD

[directory] Change Working Directory. If no directory name is provided, O the server will change to the default or home directory. O Otherwise, you will be prompted for a password, and the server O will attempt to change to the specified directory. The O password is entered on a separate line, and does not echo as O you type it.

If access is not granted, the server will provide O a message to that effect. Note that while not all server Ker- O

mits require (or accept) a password to change the working O directory, Kermit-32 will always ask for one when a directory ! name is provided. O DELETE filespec Delete the specified file or files.

The names of the files < that are deleted will appear on your screen. DIRECTORY [filespec]O The names of the files that match the given file specification O will be displayed on your screen, perhaps along with size and O date information for each file. If no file specification is K given, all files from the current directory will be listed. DISK_USAGE [directory]O Display information about disk usage in the given directory (or O by the given user). If no directory is provided, disk usage O information is provided for the current working directory (or E user). This is the same as the REMOTE SPACE command. O EXIT

Requests the server to leave Kermit, allowing the terminal to , be used for normal commands. O FINISH Requests the server to return to the Kermit prompt, allowing > statistics to be obtained about the transfers. O HELP [topic] Provide information about the given topic. If no topic is O given, provide a list of the functions that are available from O the server. Some servers may ignore the topic and always dis- * play the same information. O HOST [command] Pass the given command to the server's host command processor, @ and display the resulting output on your screen. O LOGIN user-id Supply information to the server Kermit to indicate what O user-id, account and password are to be used. The server Ker- O mit may use this to validate the user's access to the system as O well as for billing purposes. It may also use this information G to provide the user with access to files on its system. O LOGOUT

Request the server to exit Kermit and logout its job (or K process). This command is identical to the LOGOUT command. O RENAME filespec Change the name on the specified file (or files). Kermit-

32 O will prompt for the new file specification on the next line. O Both file specifications must be valid for the server's system. SEND_MESSAGE destination-addressO

Request the server to send a single line message to the O specified destination address (which might be a user-id, ter- O minal designator, or some other item, depending upon the server O

Kermit). Kermit-32 will prompt for the single line message on - the next line. SPACE [directory] O Display information about disk usage in the given directory (or O by the given user). If no directory is provided, disk usage O information is provided for the current working directory (or J user). This is the same as the REMOTE DISK_USAGE command. C STATUS

Display information about the status of the server. J TYPE filespec

Display the contents of the specified file on your screen. O WHO [userid] Display information about the given user. If no user-id is O given, display information about the currently active users. O

Kermit-32 will prompt for options for selecting what infor- O mation to display and/or formatting parameters. The format of O both the user-id and the options are dependent upon the server

Kermit. ) 7.4.3. Commands for Local File Management Syntax: LOCAL

[command] O Execute the specified command on the local system -- on the VAX/VMS system O where Kermit-32 is running. These commands

provide some local file management O capability without having to leave the Kermit-32 program. These commands are O very similar to the

REMOTE commands in function and syntax. They are all ex- O ecuted locally, and are available when Kermit-32 is either local or remote. O The arguments to these commands are the same as the arguments expected from the B user Kermit when Kermit-32 is processing a command in server mode. O COPY filespec Make a copy of the given file (or files). Kermit-32 will O prompt for the new file specification. The command is actually O performed by using the DCL COPY command (COPY/LOG old-file O newfile), and any options which are valid on the DCL COPY com- % mand may be included. O CWD [directory] Change working directory, or, in VAX/VMS terminology, change O the default device/directory. This command takes the same ar- O guments as the DCL SET DEFAULT command (i.e., a device and O directory, only a directory, or only a device). If no argument O is given, the default device and directory are reset to that in O effect when Kermit-32 was run. The new default device and , directory will be typed out. O DELETE filespec Delete the specified file or files. This command is performed O by using the DCL

DELETE command (DELETE/LOG filespec). There- O fore, any options which are valid on the DCL DELETE command may be included. DIRECTORY [filespec]O Provide a directory listing of the specified files. This com- O mand is performed by using the DCL DIRECTORY command (DIRECTORY O filespec), so any options valid for the DCL DIRECTORY command may be included. DISK_USAGE [uic]O Display disk usage information for the given UIC. If no UIC is O given, display disk usage information for the process UIC. O

This command is performed by using the DCL SHOW QUOTA command 4

(SHOW QUOTA or SHOW QUOTA/USER=uic). O HELP Display the help message describing the server commands which - are available. HOST DCL commandO Perform the given DCL command. The command should not perform O any action which will require more input. Any output resulting ? from the command will be typed on the terminal. O RENAME filespec

Change the name of the specified file. Kermit-32 will prompt O for the new name on the next line. This command is performed O by using the DCL RENAME command (RENAME/LOG old-file new-file), O so any options which are valid on the DCL RENAME command may be included. SEND_MESSAGE terminal-nameO Send a single line message to the given terminal. Kermit-32 O will prompt for the message on the next line. Since this com- > mand is performed using the DCL REPLY command :

REPLY/TERMINAL=terminal-name "message" 9 OPER privileges are needed to perform it. O TYPE filespec Display the contents of the specified file or files at your O terminal. Each file will be preceded by its name in angle brackets. 7.4.4. The CONNECT Command Syntax: CONNECT [terminalname] O Establish a terminal connection to the system connected to the terminal line O specified here or in the most recent SET LINE command, using full duplex echo- O ing and no parity unless otherwise specified in previous SET commands. Get O back to Kermit-32 by typing the escape character followed by the letter C. The O escape character is Control-

Close-Square-Bracket (^]) by default. When you J type the escape character, several single-character commands are possible: 3 C Close the connection and return to Kermit-32. ; Q If a session log is active, temporarily Quit logging. ( R Resume logging to the session log.$ S Show status of the connection. 0 Send a null character.7 ? List all the possible single-character arguments. ;

^] (or whatever you have set the escape character to be): O Typing the escape character twice sends one copy of it to the connected

host. O You can use the SET ESCAPE command to define a different escape character, and O SET PARITY, and SET LOCAL_ECHO to change those communication-line-oriented O parameters. Type the SHOW

LINE command for information about your current com- munication settings. O Kermit-32 does not have any special autodialer interface.

It assumes that the 7 connection has already been made and the line assigned. 7.4.5. The SET and SHOW Commands /

THE SET COMMAND & Syntax: SET parameter [option [value]] O Establish or modify various parameters for file transfer or terminal connec-

O tion. You can examine their values with the SHOW command. The following parameters may be SET:@ BLOCK_CHECK Packet transmission error detection methodD DEBUGGING Record or display state transitions or packets> DELAY How long to wait before starting to send7 ESCAPE Character for terminal connection @ FILE For setting file parameters like file typeL HANDSHAKE For establishing half duplex line turnaround handshake= IBM_MODE For communicating with an IBM mainframe 8 INCOMPLETE_FILE What to do with an incomplete fileG

LINE Terminal line to use for file transfer or CONNECT 8

LOCAL_ECHO For terminal connection, ON or OFFE MESSAGE The type of typeout to be done during transfers - PARITY

Character parity to use 9 PROMPT Change the program's command prompt < RECEIVE Various parameters for receiving files< REPEAT_QUOTE Character to use for repeat compressionG

RETRY How many times to retry a packet before giving up :

SEND Various parameters for sending files= TRANSMIT Control

TRANSMIT command echo and delay O Those SET commands which differ from the "ideal" Kermit are now described in detail.

SET DEBUGGING Syntax: SET DEBUGGING options O Record the packet traffic, either on your terminal or in a file. Some reasons O for doing this would be to debug a version of Kermit that you are working on, O to record a transaction in which an error occurred for evidence when reporting O bugs, or simply to vary the display you get when running Kermit-32 in local mode. Options are: D ON

Display each incoming and outgoing packet (lengthy). O OFF

Don't display or record debugging information (this is the nor- D mal mode). If debugging was in effect, turn it off. O The debugging information is recorded in the file specified by the most recent LOG

DEBUGGING command.

SET ESCAPE SET ESCAPE octal-number O Specify the control character you want to use to "escape" from remote connec- O tions back to Kermit-

32. The default is 35 (Control-]). The number is the oc- O tal value of the ASCII control character, 1 to 37 (or 177), for instance 2 is O Control-B. After you type the escape character, you must follow it by a one of L the single-character "arguments" described under the

CONNECT command, above. SET FILE " Syntax: SET FILE parameter keyword " Establish file-related parameters:

TYPE keywordO Type of file for VAX/VMS file output. The choices are ASCII, BINARY, or FIXED. O ASCII Store the file as a standard VAX/VMS text file. Any file O received is stored as variable length records with carriage O return, line feed sequences implied between records. This is O the format preferred by most utility programs under VAX/VMS. O

An error will occur if any line is more than 4096 characters O long. Note that lines are only terminated by carriage return, O line feed sequences. A carriage return that is not followed by O a line feed or a line feed that is not preceded by a carriage O return is not considered the end of a line, and is included , within the body of a record. O BINARY Store the file as a binary file. Any file received is stored O as variable length records with no record attributes. O

Kermit-32 actually will write 510 bytes in each record except O the last. This makes each record take up one disk block (510 O data bytes plus two bytes of record length). The last record O is written containing only as much data is left to the end of O the file. Any file which is just a stream of bytes can be O stored as a BINARY file, and recovered intact later. This is C the preferred file type for use in archiving files. O FIXED

Store the file as a fixed length binary file. Any file O received is stored as fixed length 512 byte records with no O record attributes. This is the format used for binary files O such as VAX/VMS "EXE" files and RSX-11M/M+ "TSK" files. Since O even the last record of the file is written with 512 bytes O

(even if it is not filled), this format does not necessarily O maintain the correct length of a file. It should normally only O be used for files which are coming from a VAX/VMS system which ? are currently stored in fixed 512 byte records.

NAMING keywordO Determine the form of names to be sent with outgoing files and deter- O mine the translation performed on incoming file names. The choices are + FULL, NORMAL_FORM and

UNTRANSLATED. O FULL Kermit-32 will send full file names

(including device, direc- O tory, file name, file type and version number). When receiving O a file, Kermit-32 will perform no translation of the file name M (which must therefore be a legal VAX/VMS file specification).

NORMAL_FORM O Kermit-32 will send only the file name and file type. When O receiving a file, Kermit-32 will convert the file specification O received to contain only uppercase letters, digits, and at most O one period.

Any other characters will be translated to "X". O There will be at most 9 characters before the period (if any), O and at most 3 characters afterwards. This forces the file name O to be a valid VAX/VMS file specification. Note that standard O

VAX/VMS file names and types are already normal form, and H therefore do not need translation. This is the default.

UNTRANSLATEDO Kermit-32 will send only the file name and file type. When O receiving a file, Kermit-32 will not perform any conversions on O the file specification, which therefore must be a legal VAX/VMS # file specification.

SET HANDSHAKE Syntax: SET HANDSHAKE o O Sets the half duplex line turnaround handshake character to the ASCII character O whose octal value is o. Normally required for communication with half duplex systems like IBM mainframes.

SET IBM_MODE - Syntax: SET IBM_MODE ON or OFF O When IBM_MODE is set to ON, Kermit-32 will override the parity and local echo O settings and use odd parity, local echo on, and also enable a handshake charac- O ter of XON (control-Q, ASCII 021 octal). This feature allows Kermit-32 to talk O with certain systems (notably some IBM mainframes), which require waiting for a XON before sending data. O The various features selected by this command can be overridden subsequently by 7 SET PARITY, SET


LINE [terminal-name] O Specify the terminal name to use for file transfer or CONNECT; the O terminal-name can be up to 16 characters long. If you issue this command using O other than your job's controlling terminal, you will be running Kermit-32 O locally, and you must log in to the remote system and run Kermit on that side O in order to transfer a file. If you don't issue this command,

Kermit-32 deter- O mines whether it is to run locally or remotely based on the default terminal O line found when Kermit-32 is started.

Kermit-32 uses a list of logical names O to determine which terminal should be the default terminal line. The first of O these names which translates to a terminal which is available (i.e., not al- O located by some other process) is used. The logical names Kermit-32 tries are O KER$COMM, SYS$INPUT, SYS$$OUTPUT, and SYS$COMMAND. If none of these translate O to an available terminal, Kermit-32 is running detached, and a terminal must be O specified by the SET LINE command before any actions can be performed. If a O terminal is found, Kermit-32 is running locally if this is a terminal other O than the one controlling the job (i.e., different from SYS$COMMAND), otherwise O Kermit-32 is running remotely. You can also select the line directly in the CONNECT command; the command CONNECT

TTA0 is equivalent to SET LINE TTA0

CONNECT O If you type SET LINE with no argument, you will deassign any previous assigned line and revert to remote mode. SET

SERVER_TIMEOUT ! Syntax: SET SERVER_TIMEOUT number O This specifies the number of seconds between timeouts during server command O wait,

0 specifies that no timeouts should occur during server command wait. O When a Kermit server times out, it sends a NAK packet. Some systems cannot O clear piled-up NAKs from their input buffers; if you're using such a system to O communicate with a Kermit-32 server, and you expect to be leaving the server O idle for long periods of time, you should use this command to turn off server command-wait timeouts.


ON/OFF O It is possible to set a few parameters associated with the raw

TRANSMIT command O that vary both what the user sees on the screen as well as the speed of the transmit. SET TRANSMIT DELAY O This parameter is the amount of time to delay after each carriage return is O transmitted. Valid delay values range between 0 (the default) and

9 tenths of O a second. The format of the command is: SET TRANSMIT DELAY d Where d is a 5 single decimal digit representing tenths of a second. O Some remote hosts may not be able to receive the characters as fast as O Kermit-32 can send them. The TRANSMIT DELAY can be used to slow up the trans- 5 fer by adding a slight delay after each line is sent. O The transfer also runs slower if the transmit echo is on, and the remote system O is echoing the characters as it receives them. If the transmit delay is set to O 9 tenths of a second, the remote system is echoing characters, the transmit O echo is on, and the remote system still cannot keep up, then the connection % should be made at a slower baud rate. O Conversely, the file transfer speed can be increased by: setting the delay to 0 O and the echo off, stopping the remote system from echoing the characters it . receives, and connecting at higher baud rates. SET TRANSMIT ECHO O This command controls what the user sees on the screen during the file trans- ? fer.

The format of the command is SET TRANSMIT ECHO ON or OFF. O By default, the transmit echo is left off and the user sees the number of each O line after it has been transmitted. With transmit echo on, the user sees O whatever the remote system would normally echo back to him while he is typing O in a file. Note that turning the echo on typically slows the file transfer down. /

THE SHOW COMMAND Syntax: SHOW [option] . The SHOW command displays various information: ALL All parameters. BLOCK_CHECK_TYPE5 The block check type being requested. O COMMUNICATIONS Parameters affecting the terminal line being used for com- munication. 1 DEBUGGING

Debugging mode in effect, if any. O DELAY The number of seconds Kermit-32 will delay before starting a < SEND or RECEIVE command when in remote mode. H ESCAPE The current escape character for the CONNECT processing. H FILE_PARAMETERS File type, file naming, and incomplete file disposition. INCOMPLETE_FILE_DISPOSITION > The action to take when a transfer is aborted. % LINE Terminal line in use. K LOCAL_ECHO Whether characters should be echoed locally when

CONNECTed. 2 PACKET For incoming and outbound packets. ' PARITY The parity type in use. $ RECEIVE

For inbound packets. @ RETRY The number of retries to be done on bad packets. % SEND For outbound packets. 0 TRANSMIT

Parameters for TRANSMIT command. 8 VERSION The program version number of Kermit-32. " 7.4.6. Program Management Commands /

THE HELP COMMAND Syntax: HELP [topic {subtopic}] O Typing HELP alone prints a brief summary of Kermit-20 and its commands. You

can also type HELP command O for any Kermit-20 command, e.g.

"help send" or "help set parity" to get more . detailed information about a specific command. 4 THE EXIT AND QUIT


Syntax: EXIT O Exit from Kermit-32. You can also exit from the Kermit-

32 when it is waiting O for a command by typing a control-Z. When

Kermit-32 is running remotely, two O control-Y's will abort the transfer, bringing Kermit-32 back to command mode. O The two control-Y's must be typed together, as if a timeout occurs between them O the first is ignored. When Kermit-32 is running locally, two control-Y's will O stop

Kermit-32 and return you to DCL. You will be able to CONTINUE if you do O not perform any command which runs a program. However, after continuing, J control-A, control-X and control-Z will no longer be accepted as commands. QUIT is a synonym for EXIT. /

THE LOG COMMAND Syntax: LOG [option [filespec]] / Log the specified option to the specified file: O SESSION During CONNECT log all characters that appear on the screen to O the specified file. During CONNECT, the session log can be O temporarily turned off during the remote session by typing the O escape character followed by Q (for Quit logging), and turned O on again by typing the escape character followed by R (for Re- - sume logging). O TRANSACTIONS During file transfer, log the progress of each file. Trans- O action logging is recommended for long or unattended file O transfers, so that you don't have to watch the screen. The log O may be inspected after the transfer is complete to see what I files were transferred and what errors may have occurred. O DEBUGGING

Log debugging info to the specified file. If no SET DEBUGGING O command was previously issued, the file will be opened and no O information written. If DEBUGGING is turned on (either via the O

SET DEBUGGING command or by typed control-D during a local O transfer), the packet debugging information will be written to O the file. Packet format is described in the Kermit Protocol

Manual. O Any log files are closed when you EXIT or QUIT from Kermit.

You may explicitly O close a log file and terminate logging by using the

LOG command without a file

specification. 0 THE STATUS COMMAND

Syntax: STATUS O The current status of Kermit-32 will be displayed.

This includes the number of O characters that have been sent and received from the remote Kermit. Also in- O cluded is an estimate of the effective baud rate of the transfer. This number O is not intended to be exact, but only an indication of what range of throughput has been provided. 7.5. Raw Upload and Download 1

THE TRANSMIT COMMAND Syntax: TRANSMIT file-spec O The TRANSMIT command allows you to upload files "raw" to systems that don't O have a Kermit program available. Note that there is no error checking or pack- - ets involved in this method of file transfer. O This command does a raw transmit of an ASCII file, one character at a time, O with carriage returns (no line-feeds) at the end of each line. It is used with O Kermit-32 in local mode. The user must first prepare the remote host to O receive the file by starting an edit session in input mode. Then the user can O escape back to Kermit-32 and issue the

TRANSMIT command. After the transmit is O finished, the user then

CONNECTs back to the remote host again and ends the

edit session. O During a file transmit, the following control characters can be used to affect the transfer in progress: " CTRL-C

Abort the transmit : CTRL-X Abort the file currently being transmitted @ CTRL-Z Abort the file group currently being transmitted C See SET TRANSMIT for information about controlling echo and delays. 3 THE LOG SESSION

COMMAND Syntax: LOG SESSION file-spec O "Raw Download" is the term commonly used to describe the capture of a remote O file on the local system, without any kind of error detection or correction. O This allows you to obtain files from remote systems that do not have Kermit, 0 but with the risk of loss or corruption of data. O Kermit-32 provides raw downloading via the LOG SESSION command during CONNECT O to a remote system. The session log is described above. To use session log- ging to capture a file: ' 1. Run

Kermit on the VAX/VMS system. J 2. SET LINE to the terminal line through which you will be connected to the remote system. J 3.

Perform any required SET commands to condition Kermit for communica-" tion with the remote system. . 4. CONNECT to the remote system and log in. J 5. Condition your job on the remote system not to pause at the end of aJ screenful of text, and give whatever commands may be necessary toJ achieve a "clean" terminal listing -- for instance, disable messages% from the system or other users. J

6. Type the appropriate command to have the desired file displayed atJ the terminal, but do not type the terminating carriage return. OnD most systems, the command would be "type", on Unix it's "cat". J 7.

Escape back to Kermit-32 and give the LOG SESSION command with the: file specification where you wish to store the data. J 8. CONNECT back to the remote system and type a carriage return. TheJ file will be displayed on your screen and recorded in the session log file. J 9. Escape back to Kermit-32 and give the LOG SESSION command without a file specification. O The file you specified will contain everything that was typed on your screen. O You will probably find that some editing necessary to remove extraneous O prompts, messages, padding characters, or terminal escape sequences, or to fill - in lost or garbled characters. + Use the TRANSMIT command for raw uploading. 7.6. Control Characters - 7.7. Installation of

Kermit-32 O Kermit-32 may be installed either by rebuilding the entire

program from the O sources, or by making use of the distributed copy of the program. When being O built from sources, it may be built using either a BLISS-32 compiler or just the MACRO-32 assembler. *

FILES O Kermit-32 is built from a number of BLISS-32 sources and one

MACRO-32 source. O In order to make it possible for sites without

BLISS-32 to build, MACRO-32 O sources generated by BLISS-32 are also included for all of the BLISS modules. O In the normal distribution of

Kermit-32, all of the files start with the prefix O "VMS". This will need to be changed to "KER" in order to build the program D properly.

The following files are distributed as part of Kermit-32: I VMSTT.BLI

Common BLISS source for the terminal text output support. J VMSGLB.BLI

Common BLISS source for the global storage for VMSMSG.BLI. E VMSMSG.BLI

Common BLISS source for the protocol handling module. O VMSCOM.REQ

Common BLISS require file which defines various common O parameters. This is required by VMSMSG.BLI. This file must be & renamed to KERCOM.REQ. 7 VMSMIT.BWR "Beware File" for Kermit-32

(read it!). O VMSMIT.BLI BLISS-32 source for the command parser, and some basic support routines. 1 VMSFIL.BLI

BLISS-32 source for the file I/O. O VMSTRM.BLI BLISS-32 source for the terminal processing. This handles the O driving of the terminal line for the transfers and the connect # command processing. O VMSSYS.BLI System interface routines for the Kermit generic command processing. O VMSGEN.MAR Macro-32 source file that contains the

REMOTE command text that O is given to VMS. Sites desiring to change what DCL commands O are used to process the various generic server commands can O make those changes in this source. This also contains the text O of the help message returned in response to the server generic help command. I VMSERR.MSG MESSAGE source for error messages used by VAX/VMS Kermit. O VMSERR.REQ BLISS-32 require file which defines the error codes. This is 1 REQUIREd by the BLISS-

32 sources. B VMSMIT.MSS SCRIBE source file for VMSMIT.DOC (this document). O VMSMIT.RNH RUNOFF source for the help files for

VAX/VMS Kermit. When this O is run through RUNOFF with

/VARIANT=SYSTEM, it produces a .HLP O (VMSSYS.HLP) file suitable for inserting into the system help O library

(SYS$HELP:HELPLIB.HLB) to provide a KERMIT topic for O the system HELP command. When run through RUNOFF without the O

/VARIANT=SYSTEM, it produces a .HLP file (VMSUSR.HLP) to be G stored on SYS$HELP: for use by the Kermit HELP command. ? VMSSYS.HLP

RUNOFF output file for system wide Kermit HELP. = VMSUSR.HLP

RUNOFF output file for Kermit's HELP command. A VMSINS.COM Command file to build and install VAX/VMS Kermit. O VMSMIT.EXE The executable (binary) file of VAX/VMS Kermit. Note that this O is only included when it is possible. This may be either a O copy of the .EXE file which was transferred to a TOPS-10 or O

TOPS-20 system using Kermit with Kermit-10 (or -20) using FILE O

BYTE-SIZE 8-BIT, or a direct copy of the .EXE file (if the file O is either on a native VAX/VMS tape or is residing on a VAX/VMS system). O VMSMIT.HEX A hexified version of .EXE file for VMS

Kermit. This file can O be dehexified using the supplied program. In the hexified O form, the file should be transferable over any medium which O

handles normal text. This is the most reliable copy of the ex- / ecutable version of VMS Kermit. O VMSHEX.MAR Source for the hexification program. This is the program which O was used to produce VMSMIT.HEX. It can also be used to produce O hexified version of any (or at least almost any) Files-11 file. O

The dehexification program should then be able to reproduce a O copy of the original file with the file parameters correctly O set. Note that the format used for the hexified files is basi- O cally Intel hex format. There are some additional records used O to store the record format, etc. Also, the file name as typed O to the prompt from VMSHEX is stored in the hexified version of O the file for use by the dehexification program. By doing this, O it is possible to store more than one binary file with a single - hexified file. 6 VMSDEH.MAR Source for the dehexification program. O VMSV31.*Version 3.1 of VMS Kermit, the last version that will run under release O 3.x of VMS. Versions 3.2 and later require VMS release 4.0 or later. O VMSV3x.MEM

Documentation on the changes between releases 3.1 and 3.1, and O

3.2 and 3.3 of Kermit-32, and additional installation infor- mation. O As distributed, Kermit-32 should work on any VAX/VMS system (version 4.0 and O later). Customization is possible with or without a BLISS-32 compiler. O Default parameter values may be changed by changing the appropriate LITERALs in O the BLISS-32 source for VMSMSG, or the actual values which are stored in the 3 routine MSG_INIT in the

MACRO-32 source for VMSMSG. O Sites can also easily change the commands which are used for processing the O generic server functions

(REMOTE commands when running as a server). The text O which makes up these commands is in the file VMSGEN.MAR, along with the text of O the

REMOTE HELP message. This allows a site to make use of local programs for O performing some of the commands (perhaps using FINGER to perform the WHO com-

mand, etc.). 7 BUILDING KERMIT-32 FROM

SOURCES O A command file is included which will build Kermit-32 from either the BLISS-32 O or MACRO-32 sources and optionally install

Kermit-32 on the system. This file O (VMSINS.COM) has not been extensively tested, however it should work on most O systems. It is also a good example of what needs to be done to compile each O file and load the entire program. It also contains the commands necessary to O install a version of Kermit-32 on the system once the .EXE and

.HLP files are


OF ITSELF O If you already have a version of Kermit-32 running on a

VAX/VMS system, you can O use it to transfer a new version of itself from another system. If you have no O need to build Kermit-32 from sources

(because you have no local modifications), O you can just transfer the new VMSMIT.EXE (or VMSMIT.HEX), and the new help fileC

VMSMIT.RNH.f O If you have access to a system which has a copy of

VMSMIT.EXE, you can transferNO it simply by setting the FILE TYPE to

FIXED on the receiving Kermit. Make sure O that the sending Kermit is willing to send the file as a binary file. If the O sending Kermit is another copy of Kermit-32, you don't need to do anything. IfsO the sending Kermit is Kermit-10 or Kermit-20, make sure the file will be sentYO as an eight-bit binary file by using SET FILE BYTE-SIZE EIGHT.

If some other O Kermit is sending the file, make sure to give it whatever command is necessary O to ensure that it sends eight-bit binary data from the file. Also, if the O originating system is not a VAX/VMS,

TOPS-10 or TOPS-20 system, make sure that O the file was stored on that system correctly to start out with. Normally, theoO file VMSMIT.EXE will only be available from a VAX/VMS, TOPS-10 or TOPS-20 sys-p tem. O If you only have access to a copy of VMSMIT.HEX, you will need to transfer that O file (as a normal ASCII text file). You will also need a copy of

VMSDEH.MAR. O After you have obtained both files, you can produce a copy of the .EXE file asvO follows. First compile VMSDEH by using the command

MACRO VMSDEH. Then load it O by LINK VMSDEH. Now run VMSDEH and when it asks for a file name, typegM VMSMIT.HEX. The program will run for a short time and produce the .EXE file.n O The system wide and user help files are produced from VMSMIT.RNH by RUNOFF. To L produce the user help file (the one used by Kermit-32's HELP command), type: ) $


SYS$HELP:KERMIT.HLB KERUSR.HLP O To produce the system wide help file and install it in the system help libraryV type: 8 $ RUNOFF


SYS$HELP:HELPLIB.HLB KERSYS.HLP E This allows the DCL HELP command to provide information on Kermit-32.s [End of VMSMIT.DOC]a

Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF