Conference 7.286::ansi_printing

2256.0. "Second+ jobs print ONE line below TOP" by TAV02::CHAIM (Semper ubi Sub ubi .....) Tue Mar 25 1997 01:32

OpenVMS V6.0 - LATSYM - PrintTronix printer (serial)

Customer describes the following problem:

He makse sure that print head of the printer is at the TOP and issues a manual
FF to make sure it remains at TOP.

He prints a small file which contains only ASCII text; no escape and/or control
characters. The file prints correctly and the printer FFs to the TOP. He prints
the same file again. This time the output starts ONE line below the TOP and the
printer FFs to TOP. This behavior will continue (output starting ONE line below
the TOP) until he either stop/starts the queue or manually FFs the printer
again.

Since he is working in a one computer environment, he tried defining the queue
with PRTSMB (i.e. init the que with no /process) and then it prints fine.

The LTA term is et to LA75 or LA100 and is FORM.

I have suggested that he upgrade to at least V6.2 and then see what happens.

But in the meantime has anyone ever encountered a problem like this. I recall
problem descriptions whereby each subsequent print job would advance line by
line, but this was due to the LTA term having been defined as NO FORM, and
setting the LTA to FORM would solve the problem. But in this problem the
printer does position itself at TOP but after the first job will skip ONE line
before starting the output.


Thanks,

Cb. 

I just spoke with the customer and he has tried printing from VMS V6.2 and
gets the same results.

I requested that he try placing a different printer in place of the PrinTronix
and he connected an LA310 printer using the same TS port and same queue etc.
and low and behold it does NOT have this problem. So it appears to be a
specific problem with this particular PrinTronix via LATSYM.

I also asked him to set the LTA terminal to PASTHRU instead of NOPASTHRU, but
this didn't help (which is really what I had expected since his problem
description didn't fit the types of problems that required PASTHRU).

So, before I throw the customer to the PrinTronix people perhaps someone has
some idea which might help.

Thanks,

Cb.

I have discovered the problem:

I requested the customer to place the printer in HEX mode.

Following the <FF> at the end of the first job is a <DC1> character which is an
XON character. On the one hand this really shouldn't cause a printer to do a
LF, but on the other hand there is also no reason why the printer should be
RECEIVING an XON. 

I had the customer set/def the terminal server port to disable input flow
control and lo and behold the undesirable behaviour disappeared.

Thanks,

Cb.