.PAGE SIZE 60,73 .LEFT MARGIN 3.RIGHT MARGIN 74. .DATE .TITLE ##########Preventing spurious characters .SUBTITLE ##########B.#Z.#Lederman .CENTER ^&Preventing spurious characters in documents\& .BLANK.CENTER ^&printed through a terminal printer port\& .BLANK.CENTER ^&using ALL-IN-1\& .BLANK 2.CENTER Bart Z.#Lederman .BLANK .CENTER 2572 E. 22nd St. .CENTER Brooklyn, NY 11235-2504 .BLANK .PARAGRAPH We are using WPS-PLUS within ALL-IN-1 (V2.0): we also happened to have an electronic typewriter which has an RS-232 interface that allows it to act as a printer, and a terminal (VT220) with a printer port. It appeared reasonable to connect them all together, as one of the destinations to which AI1 will print is a printer port on a terminal: AI1 is supposed to send the proper escape sequence to turn the printer port on and off to direct the text to the printer. We soon discovered, however, that spurious characters (always the same characters) would print at the beginning and end of every document. .PARAGRAPH I examined the script files for this function (they are in the directory OA$DO and have names like WPPPORT.SCP, WPPORTLA5.SCP, etc.), and found they sent escape sequences after turning on the printer port, and contained escape sequences that I could not find in any terminal manual, so I edited them: I made the sequence that turned on the printer port ([5i) the last characters before the document is sent, and the sequence that turned off the printer port ([4i) the first characters after the document is sent. For example, the relevant portion of the script file might look like this: .BLANK.TEST PAGE 5.NO JUSTIFY.NO FILL .TEXT 23,1,"[6i[5i" GET OA$FUNCTION="COPY#" _#PRINT__OUTFILE " TT:" .TEXT "[4i[7i" GET _#PRINT__OPERATION__FAILED="" .BLANK.JUSTIFY.FILL This should have solved the problem; but although it got rid of the spurious characters at the beginning, it did not eliminate them at the end of the document. [For the benefit of those who have never edited a document with non-printing characters: the and are not text as you see them here but one single character that EDT represents in this way. You can insert these characters in a file using the SPCINS key: press GOLD, the number of the character (27 for an and 12 for a ), GOLD, and SPCINS (the "3" key on the keypad if it hasn't been redefined). WPS-PLUS does not identify special characters, displaying all of them as "#". .BLANK.TEST PAGE 5.CENTER The true cause of the problem. .PARAGRAPH At this point, I made several calls to the TSC in Atlanta. At first they said that they had heard of this problem, and suggested changes in the script files similar to my own. They then said that this solved the problem, and that they could not reproduce my reported problem. I persisted, however, and after several false starts I was eventually contacted by the local office. By the time this happened, I had run several experiments of my own using a Rainbow in terminal emulation: first as the printer to a VT220 printer port, then as the terminal itself. By capturing the text, I found that AI1 was indeed sending extra escape sequences at the end of the document before shutting off the printer port, and that there did not seem to be any way to make AI1 stop doing this. The escape sequences sent include such things as save and restore cursor position, which obviously have no relevance for a hard copy device. Atlanta probably tested only with DEC printers that were capable of ignoring these spurious escape sequences, but we were using a non-DEC printer. I should point out that the printer profile specified an LP11 type printer: this DEC device does not recognize escape sequences, so it too would have printed spurious characters, as would some other DEC devices, so the problem is not confined to those people using non-DEC devices. .BLANK.TEST PAGE 5.CENTER Finally, a solution. .PARAGRAPH I now had proof that AI1 was faulty (so what else is new?), but that didn't help me to make my printer function properly. Since I had continued to pester the TSC, they eventually referred it to the local (New York City) office, and I received a call from Warren Archer. He suggested the essentials of the alternative procedure given here; the details were worked out with me on my system and him on the other end of the telephone. The first step is to modify the printer port script or create a new one with the following change: the supplied scripts do a 'GET#OA$FUNCTION="COPY#"----' and will either have a '.TEXT "[5i"' before it and another text sequence after it as shown in the above example or will use the AI1 commands 'PORT__ON' and 'PORT__OFF'. All of these commands will be replaced with a single command to invoke a DCL procedure which will turn the printer port on, send the text, and turn the printer port off. For example, the relevant portion of the script file might look like this: .BLANK.TEST PAGE 4.NO JUSTIFY.NO FILL DISPLAY Printing document . . . GET OA$DCL= "@OA$LIB:PORT__C#" _#PRINT__OUTFILE GET _#PRINT__OPERATION__FAILED="" .BLANK.JUSTIFY.FILL You may put in whatever command file specification you wish, but OA$LIB is a reasonable place to put it. Note that there must be one blank space after the file specification and before the closing double quotes ("). You must now also create the corresponding command file, which in this example is PORT__C.COM: .BLANK.TEST PAGE 10.NO JUSTIFY.NO FILL $SET TERMINAL/FORM/NOWRAP $WRITE SYS$OUTPUT "[5i" $TYPE/OUTPUT='F$LOGICAL( "SYS$OUTPUT") 'P1 $WRITE SYS$OUTPUT "[4i" $SET TERMINAL/NOFORM/WRAP $EXIT $! $! Run output to AI1 terminal in lieu of WPP script $! B. Z. Lederman as recommended by local office. .BLANK.JUSTIFY.FILL The terminal should be set for "/FORM" and "/NOWRAP" so it will pass along all text without interpreting it. The next line turns on the printer port. The third uses VMS to send the document directly to the terminal rather than having AI1 do it: this avoids the problem of AI1 inserting spurious escape sequences. Note the logical function: when you are in AI1, output goes to a mailbox and not directly to your terminal, hence you must translate the logical assignment for SYS$OUTPUT. The name of the file will be passed to the procedure as the first parameter P1. There is no need to check to see if the document exists as AI1 has already done this. Once the document is sent, the printer port is turned off and the terminal is reset. .PARAGRAPH All that remains is to enter AI1 from the system manager's account and select the PRINTER profile. You can then either change your definition of PORT to use your new script, or define a new printer type such as PORT__C to use the new script without changing the supplied scripts. .BLANK.TEST PAGE 5.CENTER Unexpected benefits! .PARAGRAPH Even if you have DEC printers you may wish to use this type of script anyway as it has one big advantage: you can cancel a document being printed to your port with a Control-C. When the print buffer runs down the procedure will exit and return you to AI1. With the scripts supplied with AI1, once you start to print a document on a printer port there is no way out except for a privileged account to stop your process. .PAGE SIZE 60, 73 .LEFT MARGIN 3.RIGHT MARGIN 74. .DATE .TITLE Re-installing the TXL .SUBTITLE B. Z. Lederman .PAGE .CENTER ^&Re-Installing the TXL\& .BLANK.CENTER ^&for ALL-IN-1 V2.0\& .BLANK 2.CENTER Bart Z.#Lederman .BLANK .CENTER 2572 E. 22nd St. .CENTER Brooklyn, NY 11235-2504 .BLANK.PARAGRAPH When trying a new script such as the printer port replacement previously described, you may simply place it in OA$LIB, and AI1 will find it. Once it is working, however, there is a performance advantage to have it in the TXL. During my testing I though everything had to be in the TXL so I was doing a number of TXL re-installations, but found that the script files didn't change. I also pursued this with the TSC, and found that the manuals are wrong. .PARAGRAPH The correct command to remove a TXL while AI1 is active is OA$TXL__REMOVE. You will not find this command in the manuals: they tell you to do an OA$TXL__CLOSE. It may be a good idea to close the TXL before removing it, but the close does not remove it. You may then compile and install the TXL with the commands shown on page 6-21 of the System Manager's Guide. You should move your new scripts into OA$DO so they are all where AI1 expects them to be before compiling the TXL. .PAGE SIZE 60, 73 .LEFT MARGIN 3.RIGHT MARGIN 74. .DATE .TITLE Backwards output from ALL-IN-1 (WPS-Plus) ? .SUBTITLE B.#Z.#Lederman .PAGE .CENTER ^&Backwards output from ALL-IN-1 (WPS-Plus)?\& .BLANK 2.CENTER Bart Z.#Lederman .BLANK .CENTER 2572 E. 22nd St. .CENTER Brooklyn, NY 11235-2504 .FLAGS BOLD.ENABLE BOLD .BLANK.PARAGRAPH In researching the printer port problem I came across a very peculiar situation that I would like to pass on to the user community for further research. .PARAGRAPH When text is sent to a device such as a terminal, each line must be terminated with a carriage return (to move the print head or cursor back to the left hand edge of the screen or paper) and a line feed to move to the next line. With very, VERY, ^&VERY, ^*VERY\*\& few exceptions, terminals used on DEC systems expect both characters to be sent. (A DEC terminal would be set otherwise only if it was connected to a non-DEC system.)# Because the print head on early mechanical printers (such as telex machines) took some time to move back across the page, it became the custom many decades ago to send the carriage return first, then the line feed: that way, the print head could be moving across the page while the paper moved up, and that gave the print head time to return to the left hand edge before the first character on the new line had to be printed. These early printers had no buffers, so if the next character arrived too soon it printed wherever the print head happened to be as it moved back across the paper. .PARAGRAPH This sequence is heavily embedded in DEC hardware and software: for example, most text files do not even have the C (carriage return) and L (line feed) characters in them: instead, the file is marked with the "Carriage Control" attribute, and a CL pair is assumed to exist between records: the operating system then inserts the C and L when needed, such as when a TYPE or PRINT operation is performed. Most DEC editors will operate properly only on this type of file: EDT, for example, will reject most files without this attribute as the records will be 512 bytes (one block) long and EDT has a limit of 255 characters. .PARAGRAPH I mention all of this because the text sent out to the printer port by WPS-Plus under AI1 has the sequence backwards: it sends one or more line feeds followed by a single carriage return. I have since discovered that WPS-Plus/VMS V2.0 does this as well as V1.0 under ALL-IN-1, and not just to printer ports: it does it to all devices and files. When I sent this text file up to the VAX to edit and print it (and find out what was going wrong with the printer port operation), I had a great deal of difficulty with it as none of the DEC software would really handle it properly. All of the software which would normally convert from one type of text file to another expects a record to be terminated by CL and not by LC: even TECO would not do the conversion properly! I had to edit the file using the EDT script for TPU in order to get the records down under 255 characters and replace the internal LC to implied CL, then edit with EDT to see the actual embedded characters (TPU doesn't make the non-printing characters visible as EDT does). .PARAGRAPH I'm not sure how much of a problem this is. I can certainly think of quite a few instances where outputting a document to a terminal and capturing it on a system like a Rainbow, or PRO, or anything else emulating a terminal, would be a very handy way to transfer a document, especially to systems that don't have other communications packages, or can't read WPS files, or where trying to get Kermit or one of the commercial communications packages to read a WPS document out of an AI1 folder would be too difficult. In addition, I can think of times where I would want WPS to output a document to a file and then be able to edit it (as opposed to exporting the source file to VMS: WPS will do this but it will not have gone through the formatting stage). Unfortunately, if AI1/WPS persists in sending the carriage control sequence incorrectly, the resulting document will not be usable. .PARAGRAPH I would be interested to know what the rest of the user community thinks about this. If AI1/WPS is in fact sending the carriage control sequence out in the wrong order, I believe it should be corrected, at least to be consistent with every other piece of DEC hardware and software I've ever seen in the last 10 years; and so the output can be captured and processed. What do you think?