ta2@VIRGINIA.CSNET (tom allebrandi) (02/28/86)
Kevin Carrosso says: > > pps. Oh, and another thing... Anyone else get the standard VMS 4.2 print > symbiont into a COM bound loop using PRINT/PASSALL? Stopping the queue > doesn't help, you have to nail the SYMBIONT_xxxx process. I too have infintely looped the symbiont. At least I think it was looping; the whole system was hung! After I "@CRASH"ed the current process was a symbiont. At the time I did it I figured that it was just me being a dumbshirt. I had sent a 30,000+ byte stream file with 1 end of record to the printer. (The file was all escape codes generated from a C program.) I probably should have been severely chastised for doing such a thing; on second thought maybe I was. At least I did at 3AM, instead of in the middle of prime time. While on the topic of symbionts, both of the following are confirmed problems in the VMS 4.2 print symbiont: 1) Printer width X is actually (X-1). Position X in the buffer is reserved for the carriage return. Width X means X characters on the line one of which is the return. If you want true 132 columns of output, you need to set the width to 133. 2) Under normal text mode - no printall, no PRINT/PASSALL - embedded nulls in the file being printed get placed into the output buffer. This means that they get charged against the column counter used for tab->blank expansion. We have a third party assembler that for some reason puts out a null at the beginning of each line in the listing. When the file is printed; tab stops are in the wrong place. This problem also affects end of line counting. Create yourself a file with following two lines in it: 150 *'s 150 *'s with 5 nulls embedded in the line somewhere before the page width column. When you print the file, the second line will appear to be 5 columns shorter. A quick reading of the symbiont listing in the fiche also led me to believe that any control character whose value is less than backspace (or was it return?) will exhibit this behavior. When I first called TSC about the problem, their response was "If you send such data to the print system, it will behave in a errant manner. Stop sending bad data. No DEC software produces this kind of output. Since the bad output is being generated by third party software, Digital cannot assume responsibility..." In other words, "Doctor, when I hit myself in the head it hurts." "So stop hitting yourself in the head." I had to argume with them to convince them that I should be allowed to SPR this! [This is not a flame against TSC. They have bent over backwards recently in helping me with problems where they could have easily said they can't help me. I just don't understand their attitude about the problem above.] Tom #-} ta2@edison.uucp edison!ta2%virginia@csnet-relay