Re: Only first page prints on telnetsym queue

On Mar 6, 10:27 pm, David J Dachtera <djesys...@xxxxxxxxxxxxxxxx>
Rich Jordan wrote:

And only for a few documents.  This is on a three node LAVC cluster,
no shared storage.

We just transferred (FTP of ZIPped backup saveset) and restored a
large batch of program source code from a customer.  Its all BASIC
source, and all in normal VMS variable length record, implied carriage
control format.

We've got two printers, one HP5 with Emulex NetJet card using LAT, and
one LJ4000 with Jetdirect running TELNETSYM.  Both queues are on an
Alpha running VMS V7.3-2, ECOs up to date as of January, and TCPIP
V5.4 eco 7.  The node where the files are stored is an Itanium running
V8.2-1, ECO'd up to November 2008, TCPIP V5.6 eco 3, and the last node
(unsupported, I know) is a MicroVAX 3100-30 running V7.3 up to date
ECOs, and TCPware V5.6 (which should not be involved).

A few program files will only print the first page when sent to the
Telnetsym LJ4000.  They print perfectly to the LAT queue.  Most files
print fine.  There is no difference in file attributes other than
size, FID, and maximum record size (and no correlation between the
record size and good/bad files).

We're pretty certain its something in the contents of the bad files,
but it could be that something is interacting with a bug in the
LaserJet.  Any node that prints a bad file gets the same result.  Copy
the file to another node and print from any node, same result.  We set
up a Telnet queue on the VAX using TCPware and had the same results
with the bad file; only the first page prints, so its not likely a
TCPIP Services bug.

Append a 'good' file to the 'bad' file, and on the LJ4000 only the
first page prints.

Append the bad file to a good one and print and you get the entire
first document, then the first page of the bad one, then nothing
(again all work perfectly on the LAT queue LaserJet 5).

I tried doing a type/output and printing the resultant file; same
results.  Edit the file and save a modified copy (just text changes)
same result.

Review of the bad files show no control codes other than TAB
characters (remember, implied carriage control).  Turning on DEBUG in
the Telnetsym log files to display all the codes being sent shows
nothing but TAB, CR, and LF are sent to the print queue until the
reset module.  We disabled the reset module which sends the escape-E
PCL reset, no change.  The print form we are using is generic with no
setup modules.

We did a cold reset on the printer and Jet Direct and reconfigured
them.  No change.

Now the fun part.  I edited the file and changed every tab to be 4
spaces (global substitution) and the file then prints properly on the
Telnetsym queue.  A review of the Telnetsym log with this modified
file shows the only control characters being sent are CR and LF, but
outside of that its the same as the earlier log.

Anyone aware of issues sending repeating TABs to a LaserJet via
Telnetsym?  I can't imagine what else it might be.  There's no
terminal device/spool device involved that might impose changes due to

This going to have something to do with timeouts and such, I think.
Until others chime in, Google this group for keywords associated with
the symptoms. This HAS been discussed here many times.


I did quite a bit of searching but I'll dig some more. I haven't had
any time to work on this due to other unscheduled work that popped up.

These queues have been in use, unchanged, for years. We've printed
files generated from many systems with issues, if any, limited to
minor formatting problems and page ejects. I've never seen this
behavior before, especially when its confined to certain text files
and it completely repeatable with those text files. And even more
especially when the problem occurs on a TCPWARE TSSYM queue and
continues to happen when the queue is moved to an Alpha with TCPIP

It has to be some kind of interaction between file data and the
printer, or a problem in the printer.

If I have time I'll plug the printer into our LAT decserver and see
what happens with a LAT queue...