Date: Thu, 27 Apr 89 15:17 EST From: Roger Wallace <22315@res2.ray.com> Subject: HP-9000 Kermit Bootstraping Methods Keywords: HP-9000, Bootstrapping Alternative Methods for Bootstrapping KERMIT-RMB to HP-9000 series Workstations. We have now successfully bootstrapped Kermit-RMB to several HP-9000 series workstations, and are in the process of gathering user feedback on the performance of this new version. This particular Kermit fills a long- standing need for reliable file transfer to hosts outside of the HP family. The basic terminal emulation and file transfer facilities seem to work as they should; we will forward any bug reports from our user community both to the Digest and to Andy Campagnola. In the meantime, I thought I would pass along, as alternatives, the methods we tried for getting the appropriate files into HP-LIF disks. 1). Raw Capture: One of our groups tried simple raw capture of the HPBKER.BAS file from a local VAX host to the HP-9000 workstation. The interpreted BASIC program appeared to load and start properly, but no external communications could be established. The particular workstation involved was running a pre-5.0 BASIC and lacked the BASIC compiler. Kermit-RMB apparently makes system calls not supported under older BASIC versions, so a working Kermit was not produced (no surprise!). With the proper revision level of HP-BASIC, and the BASIC compiler for generating the compiled subroutines, we believe (from the "partial" success) that raw capture over "clean" local lines is a viable approach for bootstrapping the program from a mainframe. 2). Decode .HEX files: This approach provided our first successful installation, although circumstances forced us to use a technique different from that suggested in HPBAAA.HLP. We had an MS-DOS PC on which the DOS/HPW to LIF conversion could be run, but no C-compiler for the "UNHEX.C" program, and no alternative PC "unhex" program. However, I did have in my lab several PDP-11's running TSX+, and happened to recall that Brian Nelson had included a hex-dehex program in the Kermit-11 distribution. Brian's K11HEX.FTN was pulled from our library and hastily adapted to the problem at hand; the HEX decodes were run on a PDP-11, and the resulting "binaries" were shipped to the PC (Kermit-11 in binary mode to Kermit-MS). Once the binaries were on the PC, HPWUTIL.EXE was run on the PC both to format LIF diskettes, 5.25-inch in our case, and to write all of the LIF files needed to build Kermit-RMB. Success of this approach depends on the fact that both RT-11/TSX+ and MS-DOS store binary files as simple, undelimited byte strings; The two Kermits provided the required eight-bit data path between the two machines. To aid anyone interested in this eccentric, but functional, method for generating Kermit-RMB, I have appended the FORTRAN source for our modified version of K11HEX.FTN, called HPBDEH.F77, to this message. A few points must be noted about our decoding scheme. First, the original K11HEX program used a very robust coding scheme in which the HEX files consisted of a 64-byte "data" field, together with a checksum field, on each line. Our bare-bones adapta- tion omits the checksum routine, since HPB*.HEX files are simple HEX-encodes, and as a result it requires HEX-source files with 64 characters per line. We reformatted the HEX files in the distribution to accommodate this requirement. (This reformatting would be transparent to "UNHEX.C" which ignores end-of-line codes anyway.) Second, in writing the decoded output file, both K11HEX and HPBDEH conform to the "integral number of blocks" file-length requirement of the RT-11 and TSX+ operating systems. As luck would have it, most of the decoded files met this requirement -- LIF files are an integral number of 256-byte sectors ("half-blocks" to RT-11) long. In three cases, however, it was necessary to pad the distributed HEX files so the decodes would come out "even". The following "pads" were added at the ends of the HEX files listed: HPBINI.HEX -- 8 lines of 64 'F' characters each (continued the pattern for "empty" space in the distribution file) HPBMIS.HEX -- 8 lines of 64 '0' (zero) characters each HPBWUT.HEX -- 334 '0' (zero) characters; 14 completed the final line of the distributed file which was "short" after the con- version to 64-character-per-line format; an additional 5 lines of 64 zeros each completed the pad to the end of the block in the decoded file. Apparently, when HPWUTIL.EXE does the conversion to LIF-format files, it makes use of the file length information in HPWLIF.DIR, and the padded DOS files are truncated to produce LIF files of the correct length. The first two files would probably have worked regardless of the "pad" character used. The NUL padding of HPWUTIL.EXE produced by adding the zeros at the end of HPBWUT.HEX seemed to have no effect on the operation of the DOS-executable program. Good luck again! We can supply the reformatted and padded HEX files if there is any real interest, but bootstrapping method (3) below will probably render the hex-dehex method obsolete in the future. Also, our HPBDEH program offers very little protection against corrupted HEX files. It will abort if it hits a "hard" read error (defective medium), but it will produce output files from HEX sources that contain "illegal" HEX characters, have short or long lines, i.e. missing or superfluous characters, or even have missing or excess lines. 3). "De-BOO" the .BOO files: Our final bootstrapping method, which has also been successful, really represents a suggestion for the method of dis- tributing Kermit-RMB. The reasoning behind this approach is as follows: for the time being, the use of an MS-DOS machine as an "intermediary" at some point in the building of Kermit-RMB will be required for the DOS/HPW to LIF format conversion. Since most sites using the HP-9000 series machines would probably have access to an IBM PC or clone, why not use the utilities in the Kermit-MS distribution for the encode-decode required to eliminate the "funny" characters in the DOS/HPW files. Specifically, use MSBMKB.EXE to encode the DOS/HPW files to ".BOO" form, and MSBPCT.EXE to decode the *.BOO files after network transmission and download. An added bonus is that the .BOO files are shorter than the .HEX files. Utilities MSBMKB.EXE and MSBPCT.EXE can be assembled from the Kermit-MS distribution. The HPB*.HEX distribution can be retained for use by those sites which must receive files over EBCDIC links, where problems in handling .BOO files sometimes arise. To test the BOO -- DE-BOO sequence, we took our set of "reference" Kermit-RMB LIF-format files and used HPWUTIL.EXE to convert these back to DOS/HPW format on the PC. These were BOO-encoded and decoded in the MS-DOS environment. The DOS/HPW files so treated grew by three bytes (NUL-NUL-SUB) each; i.e., they acquired an explicit MS-DOS end-of-file mark. This small "tail" was lopped off by HPWUTIL.EXE when encoded-decoded files were trans- formed back to LIF format. Viewed at the HP-LIF file level, the complete set of conversions (LIF->DOS->BOO->DOS->LIF) caused no change in the files. As for HPWUTIL.EXE, which must actually live and work at the DOS level, the extra bytes seem to cause no difficulty. Our BOO - DE-BOO'ed version runs just like the "original" HEX-decoded version. A couple of additional notes about the HPWUTIL.EXE program: First, there seems to be no direct way to convert a single DOS/HPW file to LIF format. The utility works on complete DOS/HPW file subsystems. This causes no problem if you are writing the Kermit-RMB files to a 3.5" LIF-formatted floppy; the whole distribution fits on one diskette, and a single command sequence accomplishes the entire conversion. For 5.25" floppies, where two diskettes are required to hold the complete distribution, we resorted to the following "game": start with all of the DOS/HPW files, including HPWLIF.DIR, in a DOS sub-directory, and a blank LIF-formatted floppy in the destination drive. Give the copy com- mands as described in the HPBAAA.HLP file. The conversion will run until insufficient space remains on the floppy. Note which files were successfully converted. Delete the corresponding DOS/HPW files from the DOS subdirectory. Place the second blank LIF-formatted diskette in the drive and re-run the conversion procedure. This time, HPWUTIL.EXE will note that it can't find all of the files, specifically the ones successfully converted on the first pass and subsequently deleted, but will convert the remaining DOS/HPW files to LIF-format on the second floppy. The second note: if you run a LIF-to-DOS/HPW conversion as we did in the course of checking the BOO -- DE-BOO sequence, be aware that the DOS file HPWLIF.DIR will be created in "Read-Only" mode. It will be necessary to issue the DOS command "ATTRIB -R HPWLIF.DIR" before the file can be deleted with the usual "DEL" command. And finally, our thanks again to Andy Campagnola and his associates at HP for making a much-needed Kermit implementation available. Roger Wallace Research Division Raytheon Co. Lexington, MA ------------------------------