home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / old / ckermit4e / ckdker.bld < prev    next >
Text File  |  2020-01-01  |  10KB  |  233 lines

  1. THE DEVELOPMENT ENVIRONMENT:
  2. ----------------------------
  3.  
  4. My initial development environment forms a bias in the Kermit program, so I
  5. will describe that environment.  I started developmenmt with version 3.20 of
  6. C, under Rev 6 of AOS/VS.  I switched to version 3.21 of C under Rev 7.54 of
  7. AOS/VS, when I was midway during development.  I would expect that Kermit
  8. would compile and run under C 3.20 or 3.21, and run under Rev 6 or 7 of
  9. AOS/VS.  I do not have or even use any superuser or superprocess privelages. 
  10. The 'BE' command was disallowed, but I could create SON processes. 
  11.  
  12. The external communications interface is an IAC, which can accept commands
  13. like CHAR (or ?SECHR) to configure itself. 
  14.  
  15. I used both a Data General D460 terminal, and a Tektronics TEK 4105 terminal
  16. in ANSI mode.  The computer host is a DG MV/8000 with 8 meg or so of memory. 
  17. I made remote connections through an IAC line, which was connected to an
  18. Applitek NI/10T.  The Applitek let me connect to a VAX 8700 with VMS Kermit, a
  19. Prime 9950 with Kermit-R19, or a Micom port selector.  From the Micom, I
  20. connected to IBM hosts with CMS and TSO Kermits, Apollo hosts with C-Kermit,
  21. and an HP host with Unix C-Kermit.  I used Apollo C-Kermit and Commodore Amiga
  22. C-Kermit to verify the functionality and performance of the DG remote Kermit. 
  23.  
  24.  
  25. INSTALLATION OF KERMIT FROM THE C SOURCES:
  26. ------------------------------------------
  27.  
  28. C-Kermit can be installed from the C sources or from the binary encoded file. 
  29. See the next section for instructions on installing from the binary encoded
  30. file. 
  31.  
  32. To install C-Kermit on the Data General computers, you will need the C
  33. compiler to compile the sources.  You may also need the minimum requirements
  34. listed above for compiler and OS versions. 
  35.  
  36. The following CLI files should be either in your working directory or in your
  37. search path, namely:
  38.  
  39.      ckdcc.cli           Compiles one Kermit source module
  40.      ckdlnk.cli          Links together the Kermit object modules
  41.      ckdmak.cli          Creates ckcpro.c; compiles and links Kermit
  42.      ckdsrc.lis          List of Kermit source module names
  43.      
  44. All object modules, error listings, and program files will be placed in the
  45. working directory.  The Kermit sources, as well as ckcpro.w, must be either in
  46. the working directory or in the search path.  The ckdcc.cli macro will create
  47. at least two files for each Kermit source file:
  48.  
  49.      filename.er         List of errors and compilation statistics
  50.      filename.ob         Object module
  51.      
  52. The ckdmak.cli macro will create the following files, in addition to the
  53. various .OB and .ER files:
  54.  
  55.      kermit.pr           The Kermit program
  56.      kermit.er           Link error messages and statistics
  57.      kermit.st           Kermit symbol table file
  58.  
  59. A sample Kermit CLI is included to execute the program: ckdker.cli .  Or you
  60. may enter: xeq kermit . 
  61.  
  62. You may add any other global compilation and link switchs after any of the CLI
  63. macros, in case you want to produce listings or debug the modules with SWAT. 
  64.  
  65.  
  66. INSTALLATION OF KERMIT FROM THE BINARY ENCODED FILES:
  67. -----------------------------------------------------
  68.  
  69. Quick summary of what to do:
  70.  
  71.     rename ckdecod.c uudecode.c
  72.     cc/link uudecode
  73.     x uudecode ckdker.enc
  74.  
  75. creates the program file kermit.pr, which is the Kermit program for the DG.
  76.  
  77. For cases where ckdker.enc must be transferred over a communication line, I
  78. would recommend used a squeezed version of ckdker.enc:
  79.  
  80.     rename ckdcomp.c compress.c
  81.     cc/link compress
  82.     x compress/i=ckdker.enc.Z/o=ckdker.enc -d
  83.     rename ckdecod.c uudecode.c
  84.     cc/link uudecode 
  85.     x uudecode ckdker.enc
  86.  
  87. The compress program is compatible with Unix versions, and I have used it to
  88. send files from my Amiga to be uncompressed on the DG.  At 1200 baud, it is
  89. certainly worth the effort.  The compress program will both squeeze and
  90. unsqueeze files, and it does run quickly.  Two CLI's on the DG, compress.cli
  91. and uncompress.cli, make this easy.  If you do send compressed files, make
  92. sure to tell Kermit on each end to "set file type binary".  See compress.man
  93. for more information and options.  The standard CP/M and Unix sq and usq
  94. programs are also available on the DG, in case you happen to use those hosts. 
  95. The file, ckdker.enc.SQ, was compress by using sq, and can be unsqueezed by
  96. entering: 
  97.  
  98.     x usq ckdker.enc.SQ
  99.     
  100. See sq.man for more details.  (NOTE: the files are in a sub-directory sq.usq
  101. on my tape, and I hope these files can be distributed with the Kermit source. 
  102. I plan to return the squeeze and compress sources back to the Unix authors, as
  103. I have done with Kermit, as soon as I find out where to send them.)
  104.  
  105. The program file, kermit.pr, has been encoded from a binary into an ASCII
  106. file, so that the program image could be faithfully transmitted over any
  107. communications link.  In order to decode the file into a program, you will
  108. need to compile the uudecode.c program, by the following command:
  109.  
  110.     rename ckdecod.c uudecode.c
  111.     cc/link uudecode
  112.  
  113. I have chosen to use uudecode, instead of the standard Kermit boo-file format
  114. for several reasons.  First, I had trouble adapting the msbmkb.c and msbpct.c
  115. programs -- my attempts are in ckdkmb.c and ckdpct.c and they do not work. 
  116. Second, the boo-file programs were complex and would be hard to translate into
  117. another language.  The uudecode.c program is very simple: two routines do all
  118. the decoding of the bytes, the file in input as a standard text file, and the
  119. program is output with record type $RTUN (undefined) and file type of $FUNX
  120. (Unix file or program with type = UNX). 
  121.  
  122. Once the uudecode program is compiled, enter
  123.  
  124.     x uudecode ckdker.enc
  125.  
  126. where ckdker.enc is the encoded binary program file.  uudecode is not very
  127. swift, but I adapted the program as a seldom-used but effective utility.
  128.  
  129. If you want to use uuencode to make an encoded file, then compile the program
  130. with this command:
  131.  
  132.     rename ckdenco.c uuencode.c
  133.     cc/link uuencode
  134.  
  135. and run it with this command:
  136.  
  137.     x uuencode/o=encoded_file  input_file  name_of_remote_file
  138.  
  139. The "encoded_file" will be overwritten by this command, and this is the name
  140. of the output encoded file.  "input_file" is the file to encode, and
  141. "name_of_remote_file" is the name that the binary file will have when it is
  142. decoded. 
  143.  
  144. The uuencode and uudecode programs preserve Data General record type and file
  145. types.  Other systems will not preserve the correct record and file types, but
  146. you can edit the encoded file to force the kind of file you want.  The first
  147. line contains:
  148.  
  149. begin 05 kermit.pr 0127
  150.  
  151. The word "begin" has to be there.  "05" specified the $RTUN record-type. 
  152. "kermit.pr" is the output name for the decoded file.  "127" is the octal
  153. number for the $FUNX file type.  You may alter any of the variable parameters
  154. according to naming conventions and the symbols defined in any of the
  155. DG system include files for "paru", for example:
  156.  
  157.     paru.32.sr          /* Assembler version */
  158.     paru.h              /* C version */
  159.     pl1paru.in          /* PL/1 version */
  160.  
  161.  
  162. SETTING UP AN EXTERNAL LINE FOR USE BY KERMIT:
  163. ----------------------------------------------
  164.  
  165. Any external line must be disabled, or else Kermit will not be able to open
  166. the line (you will get a "Device already in use" error).  PID 2 must disable
  167. the line, usually when UP.CLI runs at system startup.  The external line must
  168. be sysgenned for CHAR/MOD .  Since the line is disabled, it can only be used
  169. as an outgoing line from the DG.  The baud rate at sysgen is irrevelant, since
  170. the device can be configured by Kermit, once the line is disabled.  Note that
  171. a CHAR/MOD cannot be issued by a program to configure the line. 
  172.  
  173.  
  174. USING LOCAL LINES FOR KERMIT:
  175. -----------------------------
  176.  
  177. IAC's or intelligent device interfaces should be used for local lines as well
  178. as external lines, since the device will be configured by Kermit.  The device
  179. is returned to its original configuration when Kermit ends.  I assume that the
  180. CHAR command is possible on any line. 
  181.  
  182. If you are using a non-DG device, as I often do, then issue this command:
  183.  
  184.      CHAR/ON/NAS
  185.      
  186. Then, Kermit will issue the proper on-screen delete characters.
  187.  
  188. If you are going to use the Kermit terminal emulator at higher baud rates, you
  189. may need to set your interactive console for xon/xoff protocol.  Issue this
  190. command: CHAR/ON/XIFC/XOFC.  This may help prevent loss of characters.  On a
  191. TEK 4105, you could change your terminal setup to: FLAG IN/OUT.  The TEK
  192. handles its xon/xoff protocol inside its firmware, so there is no need to set
  193. CHAR/ON/XIFC/XOFC.   Handling the protocol by the terminal is preferable.
  194.  
  195.  
  196. OTHER NOTES AND DEPENDENCIES:
  197. -----------------------------
  198.  
  199. Kermit always reads and writes from @OUTPUT as the local device, since it is
  200. available to interactive logins and batch logins. 
  201.  
  202.  
  203. INSTALLING ON SYSTEMS OTHER THAN AOS/VS:
  204. ----------------------------------------
  205.  
  206. Installing on AOS/DVS may require no changes, but I am only guessing. 
  207. AOS/RT32 may require no changes, or else just recompilation and relinking. 
  208. MV/UX may require some changes or may be inaccurate in some of the file names,
  209. I assumed that names should look like they do in AOS/VS.  But, MV/UX
  210. can run the sys_xxx() routines, and it should also need little, if any,
  211. change. 
  212.  
  213. For DG/UX, the sys_xxx() routines are not available, and some changes will
  214. have to be entered.  I left all the UNIX stuff in the source as #ifdef's, so
  215. they could be added back in as needed for DG/UX. 
  216.  
  217. I only have access to AOS/VS.  But I have attempted to include other hosts by
  218. choosing the broadest #ifdef symbol.  So, I have used "#ifdef datageneral"
  219. instead of "#ifdef aosvs".
  220.  
  221.  
  222.  
  223. Phil Julian
  224.  
  225. SAS Institute, Inc.
  226. Box 8000
  227. SAS Circle
  228. Cary NC 27512-8000
  229.  
  230. BITNET:  CCPHIL@TUCC
  231. Usenet:  rti!sas!julian
  232. Phone:   919-467-8000
  233.