Transmission of documents on Magnetic tape with FLX B. Z. Lederman I.T.T. World Communications When preparing documents for trasmission by magnetic tape in DOS format (such as with FLX) it is important that the file have the "implicit" or "list" carriage control attribute; that is, the type of file normally produced by the various editors on RSX systems where a carriage-return line-feed pair is "implied" to exist between records, but where there are normally no such characters actually in the file. The reason for this is that FLX converts such files to files with the carriage-return / line-feed present when placing the file on tape, and does the reverse when restoring the file to disk. This is done only when the file is determined to be "formatted ASCII", which is a file which does not have an extension of ".TSK", ".OBJ", ".SAV", or other extension which would flag the use of other than "formatted ASCII" file type. If the file is of the type with "no" carriage control (which is a file which has all of the carriage-return and line-feed characters within the file) it may be garbled when transmitted by tape unless an image transfer is done every time the file is placed on or removed from the tape. During processes such as the Symposium tape collection, not every file can receive this individualized treatment, and when transmitting other tapes the receiver may not know that an individual file requires special treatment, so it is better to convert the file to a form which will be correctly treated by default. Simalarly, FLX can handle files with the "Fortran" carriage control attribute (where the first byte in each record determines the carriage control for that record), but will only do so correctly if the appropriate switch is used on every transfer. Note that this switch would apply only to files created by a Fortran task, not the Fortran source created by the editor. The greatest source of trouble is the output of RUNOFF, as the ".DOC" files have internal carriage control, and there are other such files as well (task builder maps and such). The carriage control type for any particular file is most easily determined with the RMS DSP utility, which is supplied with RSX (you need not have RMS-11K, plain RMS will suffice). When invoked, the 5th line displayed is "RECORD ATTRIBUTES:": if this is followed by "CARRIAGE RETURN", the file has the desired carriage control type. If the attribute is blank, then the file has internal carriage control, and "FORTRAN" is of course Fortran carriage control. The easiest way to get around the problem is to use TECO to convert the file to one with "implied" or "list" carriage control. It does not matter if you have never used TECO before, and do not expect to use it for anything else. I have never been able to do any normal editing with TECO regardles of which manual I read, but I can convert from one file type to another and have it work every time. The clue was in one of the RUNOFF manuals, and is very simple. First invoke TECO by the appropriate command for your system, which may be: TEC (if installed under the normal name TEC) RUN $TEC or RUN $TECO (if not installed) EDIT/TECO (if installed and you use DCL) or such command as is appropriate. You should receive an asetrisk prompt "*". There is a possibility that a video-teco is installed in your system, in which case you may receive a screen display showing the keypad layout: ignore it and enter two "control-Z"s and you should receive the astrisk prompt. When you have Transmission of documents on Magnetic tape with FLX PAGE 2 B. Z. Lederman I.T.T. World Communications the asterisk, enter the single command: *ERinfile/-CR$EWoutfile/CR$EX$$ where the "*" is the prompt on the screen, ER means read this file, infile is the file which is going to be converted (a normal RSX file specification with name and extension), /-CR means the file has no carriage control, the dollar sign is an ESCAPE character created by pressing the ESCAPE or ESC key on your terminal which will echo as "$", EW means write this file, the file specification to which the converted file is written (again a normal RSX file spec.), /CR means use implied carriage control, another escape, EX means write all of the infile to the outfile and leave, and two escapes, which signify the end of the command screen. TECO will now go to work. You may see a message such as [14K bytes] [15K bytes] [16K bytes] and so on, which is an indication of how much memory TECO is using. It will eventually exit, and send you back to the MCR prompt level ">" (or DCL, or whatever). In most cases, the converted file is ready to go, but there are still a few precautions. One is that underlining may not come through properly, especially if you use the "/UL:L" switch in RUNOFF, as this generates a very long record. I reccomend you try to get along without underlining if the file is to be distributed widely, but if you must have it, the "/UL:B" attribute is better, and the simulated underlining "/UL:S" is probably safer still. If you have any tables or illustrations, they should be checked, and if neccessary, "touched up" with an editor before placing the file on tape. If you have received a file which is already garbled, all is not lost. You may be able to retrieve it with TECO. If some of the lines are garbled, or you cannot edit the file because the records are too long, look at the file with DMP or the RMS DSP utility. If you have all 512 byte records, the file was probably transferred incorrectly. You may be able to recover by using the following two commands. First, write it back to a file with internal carrage control by reversing the command given before: *ERinfile/CR$EWtemporaryfile/-CR$EX$$ and then try to put it back with the original sequence *ERtemporaryfile/-CR$EWoutfile/CR$EX$$ You might now have a file which is mostly correct, but there are still two problems you may encounter. First, the last record may be very long, too long to be accepted by editors, BASIC, etc. which will give a message such as "illegal record length", or "record too long". This is usually due to the remains of a 512 byte tape block being appended to the last record as nulls. The solution (if you have a recent version of RSX) is to find the last record with DMP: first list the file directory with PIP to find the last block, then Transmission of documents on Magnetic tape with FLX PAGE 3 B. Z. Lederman I.T.T. World Communications examine that block with: DMP TI:=filespec/AS/BL:block:block to see the last block in ASCII. You should see text seperated by one or two strange bytes (these are the record length indicators). If the block is all nulls ("@") move back through the file one block at a time until you find the last block with data. Once you have found the last good byte, set the end of the file to the next byte using the PIP /EOF switch: PIP filespec/EOF:block:byte remembering that in MCR decimal numbers must be followed by a ".". This will terminate the file at the proper location, so it can be "digested" normally. The next problem is that a few lines may be truncated and continued on the next line: I believe that this happens where a line crossed a block boundry on tape. The easiest way around this is to use the EDT editor in "change" or keypad mode. When a truncated line is found, simply press the "EOL" key to put the cursor at the end of that line, and then "DELCHR" to remove the carriage-return (which is not visible), and the remainder of the line will move up from the line below. Doubtless other editors could be used also, but I happen to like EDT, and it is supposed to be standard accross operating systems. This last technique is also useful in transferring files from RT-11 to RSX. I have read a number of tapes with BASIC and other programs which were on RT-11 tapes by mounting them as ANSI tapes (the headers are 512 bytes vice 80, but RSX will usually take them anyway), PIPing the files over, then using the above technique to correct any garbled lines.