Printing Problems with Optio

[Srivathsan]

Hi,

I have Optio DCS installed on one of my DS20 box running Tru64 5.1 and the Optio virtual printer is configured in an ES40 pointing to the DS20 as the print server.

After the data to be printed is formatted by Optio, it is directed to the actual network printer .

In the virtual printer spool directory in ES40 when the sequence number in .seq file reaches 128 , the queue gets blocked and i get the message

No space on remote , waiting for queue to drain.

Infact there is no space problem in the spool directory ( as the message would mean literally ) . The only way out is to reinitialize the sequence number in .seq to 001 and restart the queue with lpc restart .

Any pointers please..!!

[Ralf Puchner]

please post the /etc/printcap, guessing is hard......

PS: Have you installed the printer by the setup program or manually? What does lpr.log tell us?

[Srivathsan]

# cat /etc/printcap | grep optio

#Optio queue to Virtual printer (14 May 1) . (:optio_tr:)

optio_tr:\
:lf=/var/adm/lpd/optio_tr.err:\
:sd=/usr/spool/lpd/optio_tr:\
:rp=optio_tr:\
:lp=:ct=remote:sh:mx#0:

Also, when the queue gets blocked ,

/usr/spool/lpd/optio_tr # ls
.daemon_running_on_tarifa
lock
.seq cfA129tarifa
dfA001tarifa
status
dfA129tarifa
tfA001tarifa

tarifa(ES40):/usr/spool/lpd/optio_tr # lpc status optio_tr

optio_tr:
printer is on remote host tarifa2.gva.europe.firmenich.com with name optio_tr
queuing is enabled
printing is enabled
1 entry in spool area
Mon May 10 12:52:02 2004: no space on remote; waiting for queue to drain


The lpr.log says :

May 10 12:51:32 tarifa lpd[86582]: ERROR -- close_trace: close(6) failed -- print queue may hang, error: Connection reset by peer

Any pointers on this would be of great help.

Not sure what the magic sequence number 128 is all about .

TIA
Srivathsan

[Ralf Puchner]

As given from lpr.log: connection reset by peer, means the destination machine closed the connection due to a timeout in communication.

there seems to be no space on the remote device, which means the virtual printer. Have you checked if the printer supports the remote printing method specified?

[Srivathsan]

Hi,

Thanks for the prompt reply.

The printer queue name is optio_tr and it is a virtual print queue which does the job of formatting the df file in a specific format and then forwarding it to the actual network printer.

This works fine for another machine and not for this machine only when the print sequence number reaches 128.

And there is no network connection issues between the two machines as the lpr.log file is cribbing about.

Thanks
Srivathsan A

[Ralf Puchner]

Type is "remote" which always works without filtering. Second the rm= is still missing.

If this is a "virtual printer" does it mean a software captured the output and forward it to another printer? If so why not using tcpip printing which does filtering? Have you traced the "virtual filter script"?

lpd will fork a lpd process and start the filter, after filtering is complete the job will be forwarded to the remote printer and after transfer lpd child will be terminated. If it will hang it seems to be a "filter" problem, check with the ps command.

[Srivathsan]

Sorryâ ¦I forgot to include the rm= stuff in my post. It is actually there in the real setup in the /etc/printcap entries.

The setup is something like this :

M1 ---- M2 ( Optio DCS Software)--- Actual Network Printer.

Optio DCS is a Document Customization Server Software.

Users login to M1 , and from the ERP screen fire a print to the network printer requesting the job to be processed via a Virtual Print Queue named optio_tr and defined in M1 as a remote print queue.

The cf and df files generated by this request get transferred to the spooling directory of the Virtual Print Queue ( which is configured as /tmp in M2 ).

And from /tmp in M2 , the Optio Software takes itâ s input ( a flat file ) and delivers a formatted output file ( Still in soft copy ) to the actual network printer as chosen by the user in the first instance.

Then on , the formatted request goes to the spool directory of the real network printer ( eg., /usr/spool/lpd/scj00v0 ) and from there it gets printed.

This is during normal operations.


But, when the .seq file in M1 reaches a sequence number of 127 , the next request i.e., the 128th request is sure to block the queue . The behaviour at this point in time is

CfA129* and dfA129* files remain in the /usr/spool/lpd/optio_tr ( The virtual print queue spool directory ) in M1.

CfA128* and dfA128* remains in /tmp in M2 .

The subsequent request remain queued in M1 in /usr/spool/lpd/optio_tr as cfA130 / dfA130..and soâ ¦on..and so forthâ ¦

And M1 reports â No space on remote , waiting for queue to drain.

Where as both /usr/spool/lpd/optio_tr in M1 and /tmp in M2 have plenty of free space.

Hope this gives you a better idea of the setup.

Please let me know what process and how to monitor

[Ralf Puchner · Accepted solution]

maybe a locking or script problem. Problem depend not on the Tru64 part due to the explained flow of the data.

So it is important to analyze the dataflow within the script. Use "ps" to check what is going on and increase debugging information of lpd (see man-page).

If a lot of print jobs waits for execution try the JJ parameter within the printcap (see man page of printcap for information)

[Srivathsan]

Hi,

Thanks so much for the pointer about the printcap parameter.

After changing the mj parameter i am able to work fine with a higher than default value for mj.

But there seems to be some unpredictable behavior with the lpd.

With the default mj value of 1000 , the sequence number in .seq file should reset to 000 after 999 ideally ( which happens fine in other servers ). But this server's lpd behaves very unpredictably.

Anyways... thanks very much.

Regards,
Srivathsan