C-KERMIT 7.0 INSTALLATION INSTRUCTIONS FOR STRATUS VOS
Applies to: C-Kermit 7.0.197
Last update: 8 February 2000
Author: David Lane, Altanta GA
Frank da Cruz, Columbia University
Kernie Brashier, Stratosphere, Ltd
Copyright (C) 1985, 2000,
Trustees of Columbia University in the City of New York.
All rights reserved. See the C-Kermit COPYING.TXT file or the
copyright text in the ckcmai.c module for disclaimer and permissions.
Report problems, suggestions, fixes, etc, to:
The Kermit Project
Columbia University
612 West 115th Street
New York NY 10025-7799
USA
Email: kermit-support@columbia.edu
Web: http://www.columbia.edu/kermit/
News: comp.protocols.kermit.misc
DOCUMENTATION
Frank da Cruz and Christine M. Gianone, "Using C-Kermit", Second Edition,
1997, Digital Press / Butterworth-Heinemann, Woburn, MA, ISBN 1-55558-164-1
US single-copy price: $44.95; quantity discounts available. Available in
computer bookstores or directly from Columbia University:
http://www.columbia.edu/kermit/manuals.html
Features added after version 6.0 was released are documented in the text file,
ckermit2.txt (also available as a hypertext document, ckermit2.html).
OVERVIEW
This file contains VOS-specific information. For a description of general
(system-independent) configuration options for C-Kermit, please read the file
CKCCFG.TXT. For information about known limitations or bugs, and possible
workarounds, see the files CKCBWR.TXT and CKLBWR.TXT.
Once you have built C-Kermit according to the instructions in this file,
you should install it in a directory that is in the users' library paths,
but that is not likely to be overwritten when you install a new version of
the operating system. A good candidate would be >system>application_library.
It might also be a good idea to make a "Kermit library" directory for sample
files and non-man-page-style documentation. (master_disk)>kermit might be
a good place for this. Some of the files that could go there are:
ckermit.ini
The standard initialization file. Users should copy this to their home
directories.
ckermod.ini
A sample customization file. Users should copy this file to
their home directories, and make any desired modifications (user- or
site-specific customizations).
ckermit.kdd
A sample dialing directory file.
ckermit.knd
A sample network directory.
ckermit.ksd
A sample services directory.
ckermit.env
A sample "environment variable" file
ckedemo.ksc
Macro definitions from "Using C-Kermit".
ckevt.ksc
Command file to demonstrate special screen effects from "Using C-Kermit".
ckepage.ksc
A sample script for sending alphanumeric pages.
ckermit2.txt
A file listing the updates, changes, and corrections made to C-Kermit
since publication of the 2nd edition of "Using C-Kermit".
ckcbwr.txt
The general C-Kermit "beware" file.
cklbwr.txt
The VOS-specific C-Kermit beware file.
READING A C-KERMIT DISTRIBUTION TAPE
If you have received C-Kermit on tape from Columbia University, it will
most likely be written as ANSI labeled, and certainly is not VOS save
format. To read the files onto your system, do something like this,
substituting your tape device name and supplying the density written on
the tape.
create_dir kermit_tape
change_current_dir kermit_tape
attach_port tape %s1#mt1.0
mount_tape tape -tape_format ansi -density 1600 -access_rights readonly
read_tape tape *
detach_port tape
You should at this point have all the files on the tape in your kermit_tape
directory, and can procede to either build C-Kermit yourself, or use the
pre-built version on the tape.
DECODING AND INSTALLING PREBUILT C-KERMIT BINARIES
VOS binaries (executable programs) are structured objects that are not
suitable for FTP, placement on Unix or DOS disks, etc. Therefore the VOS
C-Kermit binaries are distributed in encoded form. The first encoding is
the VOS "bundle", for example:
ckl196-all-vos1333.save.evf.gz
This is a VOS SAVE (backup) image (.save), converted for import/export
with Encode VOS File (.evf), and then compressed with Gzip (.gz). The
ckl196-all-vos1333.save.evf.gz presently on the Kermit ftp site includes
C-Kermit 7.0 binaries for VOS 13.3.3 on the three Stratus architectures.
A MIME-encoded (Base-64) version of this archive is inlcuded on the
C-Kermit 7.0 CDROM.
In case you don't have the tools to unpack the .save.evf.gz file, VOS
binaries are also available separately in a special "hex" (printable ASCII)
encoding, along with decoding tools. Versions are provided for the 68k,
i860, and continuum processors. To bootstrap C-Kermit onto your system, you
only need the command macro cklxtr.cm and the hex file for C-Kermit itself;
the name of the C-Kermit hex file is in the following form:
cklnnn-arch-vosvvvv.hex
where nnn is the C-Kermit edit number (such as 196) and arch is:
7100 (Continuum, HP PA-RISC, Jetta)
i860 (Intel i860, RISC, XA/R, Atlantic, Ventnor)
m68k (Motorola mc680x0, CISC, XA2000, Fresco, Spitfire)
and vvvv is the VOS version (without periods), such as 1333 or 13.3.3.
Examples:
ckl196-7100-vos1333.hex C-Kermit 7.0.196 for Continuum with VOS 13.3.3
ckl196-7100-vos1401.hex C-Kermit 7.0.196 for Continuum with VOS 14.0.1
ckl196-7100-vos1402g.hex C-Kermit 7.0.196 for Continuum with VOS 14.0.2g
ckl196-7100-vos1410ac.hex C-Kermit 7.0.196 for Continuum with VOS 14.1.0ac
ckl196-7100-vos1420aa.hex C-Kermit 7.0.196 for Continuum with VOS 14.2.0aa
ckl196-i860-vos1333.hex C-Kermit 7.0.196 for i860 with VOS 13.3.3
ckl196-m68k-vos1333.hex C-Kermit 7.0.196 for mc68k with VOS 13.3.3
Each VOS binary is fully configured to include both TCP/IP and X.25 support.
If your VOS system does not have TCP/IP or X.25, the Kermit program should
nevertheless run normally, except without the ability to make TCP/IP or X.25
connections.
If you have a different VOS version than those for which C-Kermit binaries
are available, follow these guidelines:
. If your VOS version is later, you can run the binary. For example, if
you have VOS 14.2.0, you can run the ckl196-xxxx-vos1333 binary.
. If your VOS version is one major release earlier than the Kermit binary,
you should be able to run the binary. For example, if you have VOS 13.3.3,
can run the VOS 14.2.0 binary.
Use the cklxtr.cm macro to convert the appropriate hex file into an executable
binary for your VOS platform.
Also included are hex versions of a compiled extraction program, which runs
much faster than the command macro version:
cklxtr-7100.hex - Extraction program for Continuum
cklxtr-i860.hex - Extraction program for i860
cklxtr-m68k.hex - Extraction program for m68k
Use the cklxtr.cm to convert the extraction program to .pm format, e.g.
cklxtr-7100.pm, and then use the executable extraction program to extract
the main C-Kermit program.
Both the command macro and the program take two positional parameters, the
input file, and the output file. The input file is the hex coded version of
the program and the output file is resulting program module. The C source for
the hexifying program is included in the source-code archive.
After unloading all the necessary files into a directory, presumably using
read_tape, convert the compiled conversion program, making certain to pick
the appropriate architecture:
cklxtr cklxtr-i860.hex extract.pm
Then extract C-Kermit:
extract.pm ckl196-i860-vos1333.hex kermit.pm
The file formats used by the command macro and by the program are identical,
so you can simply extract C-Kermit directly, but the two-step process can
save a great deal of time.
The C-Kermit versions that are included in hex format are built without
symbol tables, with optimization, and include support for X.25 and TCP/IP
networking.
BUILDING C-KERMIT FOR VOS
VOS C-Kermit is built with a command macro called cklmak.cm. This macro
recompiles and binds ALL the modules involved. It allows you to build
into a different directory than the one containing the sources, so you can
build for different machines into different directories if you need to.
If you want to define a system-wide initialization file for C-Kermit, rather
than making each user have her/his own copy, define the symbol CK_SYSINI to be
the full pathname of the file, in the -kermit_options add:
'CK_SYSINI %s1#m1_d01>kermit>ckermit.ini'
It is important that the string above get quoted properly, so if you are using
a command line to do this it would come out something like:
cklmak -kermit_options 'STRATUS DYNAMIC DCMDBUF CLSOPEN STRATUSX25 &+
''CK_SYSINI %s1#m1_d01>kermit>ckermit.ini'''
Note: if you build Kermit to execute a system-wide initialization file, this
file can (and probably should) (be modified to) "chain" to the user's own
initialization file (if any) by ending (or starting, depending on the desired
precedence) with a command like:
if exist \v(home)ckermit.ini take \v(home)ckermit.ini
After you have built and tested the C-Kermit program successfully, you can
discard the object (ck*.obj) files, which are no longer needed. Then you
can copy the program modules to an application directory.
There are several utility programs that come with C-Kermit you may or may
not want. Most of them have documentation files (*.txt) that come along that
explain what they are for. None of them is vital to using C-Kermit, though
some are required to build it; these are built by cklmak.cm whether you ask
for them or not. You can have cklmak delete the required files and not build
the others by specifying -no_tools, but generally they are helpful programs
to have.
ADDITIONAL NOTES ON BUILDING FROM SOURCE
The latest working source code for VOS C-Kermit is at:
ftp://kermit.columbia.edu/kermit/test/special/vos.zip
This is a DOS-format ZIP file. The builder ftps it (in binary mode of
course) to a Windows system, unzips it there, and then transfers the
individual files (in text mode) to the VOS system for building.
Here are updated and hopefully up-to-date and accurate building instructions:
Create a directory under the source location of kermit called build_dir. This
name is not specific; however the original macros run only if the source is
built in a separate lib. The cklmak.cm macro is the 'make' file for kermit
and the default build directory name is build_lib. Hence, if you change the
name make sure you pass the full pathname to the cklmak macro. Issue a start
process command to start cklmak and you are on your way. (This will throw an
error if the build_dir is the same as the source_dir.)
These are the files that are VOS-specific:
cklcon.c C-Kermit code modules
cklcvt.cm Conversion command macro, stream to fixed
ckldef.c Utilty program used in build process
cklfio.c
cklins.doc Installation document
cklker.bwr Beware file
cklker.doc VOS-specific documentation for C-Kermit
cklmak.cm Build command macro, makes kermit.pm
cklnet.c
cklpro.c
ckltio.c
ckltxt.c Hex-ify program
ckltxt.doc Note about hex format used by ckltxt and cklxtr
cklvos.hlp This file
cklxtr.c Un-hex program
cklxtr.cm Un-hex command macro
cklcvt.cm shouldn't be required anymore, now that there is a
cvt_stream_to_fixed.pm command...
Assuming that the ckl*.* files go on a tape with the rest of the C-Kermit
sources, that's all you need. The files that C-Kermit uses are all mentioned
in cklmak.cm, other than the header files. VOS C-Kermit uses the regular
C-Kermit command processor (ckucmd, ckuu*, etc.), the script (ckuscr.c), DIAL
(ckudia.c) and charset (ckuxla.c) packages, Wart (ckwart.c), and the Kermit
protocol interpreter (ckcpro.w) and routines (ckcfn*.c).
The VOS-specific notes are scattered among the ckl*.txt files (all the files
whose names start with "ckl" are VOS-specific).
If you get compilation or linking errors, just send the logs back to:
kermit-support@columbia.edu
(The most common cause of errors is "drift" between ckcnet.c and cklnet.c.
At some point in the past this module was split off into separate VOS and
non-VOS versions. Of course all development goes into the non-VOS file,
so every new feature must also be copied & adapted to the VOS file. It would
be highly beneficial if somebody could merge the two back together.)
Once the binaries have been generated and hexified, we use the following
naming convention for them:
ckl<editnumber>-<arch>-vos<vosreleasenumber>.hex
You can also package up all four in their own save.evf.gz files using the
tools on the "unsupported VOS tools FTP site" that Paul Green administers.
Each package contained the .pm files that are made by cklmak.pm, and the
.txt, .hlp, .ksc, and .ini files.
It is possible to build binaries for all three platforms on a single machine,
but this requires the Stratus cross-compiler product, which must be purchased
separately from the regular C compiler.
VOS differs from platforms like VMS and UNIX in that it is often possible to
run binaries built on a newer system on older systems. For example, a binary
build on VOS 13.3 or 14.1 might well run on 12.4 on the same kind of hardware
(RISC, CISC, etc). According to Stratus, 12.4 is the oldest release they
support, but only on platforms that are not supported by newer releases;
13.3.3 is the oldest release supported on Continuum.
APPENDIX: VOS HEX FILE FORMAT
David Lane, 1994: "The format I came up with is almost only hexifying,
except that if the line is all 0000...000, count it. as you count up and get
to something that isn't nulls, output that as Znn where nn is the hex number
of null lines. Also, don't split an output record boundary within a Z
record. A line is 32 bytes, or 64 hex digits. It works, but it takes
several minutes to use the command macro un-hexifier on the cklxtr.vos file,
but the cklxtr.pm will run it in just a second or two. These really aren't
"distributable quality" yet, but they do give us a basis for looking at file
formats and converters. The hex format only processes program modules
correctly, not any of the other file types."
(End)