[Info-vax] Only first page prints on telnetsym queue

[Rich Jordan]

On Mar 6, 10:27 pm, David J Dachtera <djesys... at spam.comcast.net>
wrote:
> 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
> > characteristics.
>
> 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.
>
> D.J.D.

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
$TELNETSYM.

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...

Rich