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--vos.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)