shared queue and direct printing via TCPIP DECservers

From: Rich Jordan (jordan_at_ccs4vms.com)
Date: 11/18/05 

Date: 18 Nov 2005 08:40:08 -0800

I've got a problem. An old customer (running very old code) which does
all of queued and spooled printing (to laser printers), "direct"
printing to those same lasers, and direct printing to several dot
matrix printers, is losing their MUXserver network, and therefore LAT.
The remote sites will soon only have TCPIP connectivity to the central
location.

OpenVMS V7.3, TCPIP V5.1 ECO5, DS90M+ with DNAS V3.2 via IPSec VPN
tunnels

Direct printing (where an LTA device is created and associated with the
specific MUXserver and port, but no queue or spooling is used) was set
up to provide maximum control of the printer by the program; it queries
the user for alignment and such on expensive pre-print forms before
generating print output. Mostly thats on the DMPs.

The laser queues are set up normally; LTA device created and associated
with the MUX server and port, queue aimed at the LTA device, LTA device
spooled to queue. However for check printing these old program also
stop the queue, despool the LTA device, and print direct. We are
looking at how much work it will take to switch check printing to
spooled. We don't have dedicated check printers so thats not an
option.

The DMPs in our test environment are working with the
TELNET/CREATE/RECONNECT option, though there are limitations (like the
printer going offline not being detected so jobs go to the bit bucket).
 However the lasers are an issue; we would like to run them as
telnetsym queues, but can't do that with a direct TNA port created (as
for the DMPs).

So if the queue is up, and someone needs to print checks, we
stop/queue/reset the queue, despool the (LTA device, which will likely
be retained for its name and as spool target), create the direct port
(requires privs), do the direct print job, then delete the direct port,
and restart/respool the queue.

The problems:

- the first job sent to the direct port after queue stop/reset and port
creation has spurious linefeeds added.

- If the TNA device is created without the /RECONNECT option, any
connection failure will require the port to be deleted and recreated;
you won't know there's a failure until you try to print a job.

- If the TNA device is created with /RECONNECT and the remote decserver
goes offline for any reason, the program printing to the port doesn't
get any feedback, although the data seems to somehow get buffered, at
least for small data sets we tried.

- If the queue is stopped, a direct job sent, the direct port
destroyed, and the queue restarted, we will sometimes see extended
delays before the queue 'connects' to the port again and is able to
print. It doesn't seem to correlate to idle or reconnect times, and
logging out the port from the DECserver console clears the problem.

We're testing using PRTSMB and aiming the queue at the TNA direct
port. That works so far, but the TNA port cannot be spooled to the
queue ("SET-E-INVDEV, device is invalid for requested operation"). A
file 'copied' to the TNA device while the queue is active gets sent
directly to the printer, but at least there is no long delay between
the direct copy and the queue restarting, unlike with a TELNETSYM
queue and a separate direct port.

I'm pressing for updating the code, but I don't know if that will
happen soon enough. Has anyone had good results doing the telnet
direct printing to attached serial printers? Especially in a shared
queue/direct print situation like this?

Thanks for any info.

Rich Jordan
CCS

Relevant Pages

  • Re: PRINTER GOES DOWN WHEN PRINTING LARGE FILES
    ... We have also tried printing different files. ... If I enable the queue, ... Make sure that the settings on the port for the device are ...
    (comp.unix.aix)
  • Re: print server role vs printing directly to network printers
    ... I have been using IP printing for many years with no ill effect. ... So you end up with a "first in the hole gets it" situation that print servers with a queue tend to avoid. ... I usually just point the IP port to the IP address of the print server, but I have also set the IP port to a name that is then resolvable via DNS. ...
    (microsoft.public.windows.server.general)
  • Re: Printing from Windows to a CUPS printer
    ... >> where rita is the server name and epson is the queue on that server and ... determines whether the scheduler will allow new printers ... # default IPP port of 631. ...
    (comp.os.linux.misc)
  • SUMMARY: [#2] Print to 2 queues at once
    ... Is there a way to set up a print queue in Unix so that it prints to 2 ... When we configure our printers and queues, ... Keep in mind that you can also stop the queue from printing but still allow ...
    (Tru64-UNIX-Managers)
  • Re: direct ip printing
    ... user prints from there regular desktop? ... Most printers connect without a problem. ... >> The printes that are configured via direct IP printing just won't show. ... > I'm guessing that the port name is something like IP_192.168.x.x. ...
    (microsoft.public.windows.terminal_services)