Hi John,
On 12/27/2011 9:28 AM, jmmckee flinthills.com wrote:
Is there any performance difference between using remote outq and a
*DEVD for printing?
I don't know why that would be? But, granted, I haven't seen the
internal code that IBM uses to do these things.
But, I do know that "remote outq" over TCP/IP uses the LPR/LPD printer
protocol from Unix, and the "*DEVD" via LAN TCP/IP uses a raw printer
port, a concept that was made popular by HP's JetDirect print servers.
LPR/LPD involves sending two files. A "control file" and a "data file".
The control file contains details like the host name, userid,
filenames, file sizes, etc. And of course, the data file contains the
actual printer data to be sent to the printer.
LPR/LPD was really designed to move a spooled file from the output queue
on one computer to the output queue on another computer -- as a result,
it sends the whole spooled file, along with meta-information about the
spooled file. Thus the control file and data file paradigm.
This is why remote outqs don't handle page range (by default). It always
sends the whole spooled file (unless you use an exit program to
workaround that), as if planning to re-queue it somewhere else. The
original Unix systems didn't have an option for "page range" in the
control file -- though, some (such as AIX) added it later... thus the
DESTOPT(XAIX) workaround.
The "raw port" paradigm basically does exactly what a parallel port used
to do. You connect to it, and anything you send goes directly to the
printer, just like it would on a parallel port. It's designed for
sendign straight to the printer (not queuing the spooled file somewhere
else) so there's really no meta-information.
Just like a directly attached printer, the print writer will only send
the pages in the page range when sending to a "raw port" -- so page
ranges work as they normally would.
Now, again, I haven't seen IBM's code... but from coding these two
network protocols myself, I know that LPR/LPD (remote outq) requires
additional data to be sent over the network. Since you have to gather
that information as well as send it, it seems logical that it'd be
slightly slower. (But, we're talking about a fraction of a second...
we're talking about a few hundred bytes at the most. On today's
networks where you can send millions of bytes in a second, it's a tiny,
tiny amount of time.)
There are complaints where I work of output taking "too long" to be
produced from the i. Another system that sends postscript data seems
to print faster. Printers are Lexmark Optra.
It's far more likely to be the host-print-transform function that's
causing this delay. (But, that would be the same whether you're using
remote outqs or *devd)
midrange.com
