NetNews Usenet Archive 1993 #3/NN_1993_3.iso/spool/comp/org/sug/631

Internet Message Format | 1993-01-24 | 4.6 KB

Path: sparky!uunet!uunet.ca!ecicrl!clewis
From: [e-mail] (Chris Lewis)
Newsgroups: comp.org.sug
Subject: Re: IMPORTANT: POSIX threatens our use of lp/lpr and friends
Message-ID: <[e-mail]>
Date: 24 Jan 93 04:22:13 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Organization: Elegant Communications Inc., Ottawa, Canada
Lines: 83

In article <[e-mail]> [e-mail] (Craig Jackson) writes:
>In article <[e-mail]> [e-mail] (James Buster) writes:
>>My question is, why not standardize a general-purpose batch and queueing
>>mechanism that happens to work for print spooling than just specify a
>>print spooler? This seems to me much more useful and elegant than the
>>current 1003.7 effort.

>While print spooling has lots in common with batch queuing, they do have
>there differences.  Many of the differences are areas where UNIX spooling
>is weak.  Things such as printer reset strings, printer setup modes,
>and restarting partially printed jobs.

And "forms" queues.

>(I believe that Sys V spooling
>can be programmed to handle the first two, but I'm not sure.  lpr can't.)

lp can be extended to handle resets and setup modes very easily.  The fact
that the interface scripts are shell, plus generic argument passthru (-oxxx)
stuff makes this stuff simple.  Good examples of this are HP's suite of
interface scripts for PCL (HP Laserjet), or AT&T's more advanced interface
scripts with the later versions of System Vr3 which use a "printcap" (not
to be confused with lpr's) for generalized printer capabilities analogous
to termcap.  The problem usually arises when people
who don't understand the scripting mechanism screw things up.  Another
more general problem is that there aren't standard -o options, so there's
usually no consistency from one script to another.  Ie: in one filter,
"-olandscape" may do what you want, in another, it's -oL.

Lpr, from my exposure, doesn't seem to have a generalized passthru mechanism.
Which would tend to result in multiple printer definitions for what are
just options on a single printer.  Also, the serial mode bit junk in
printcap is a pain compared to explicit "stty" commands (if necessary)
in an lp script.

Forms queues (ala IBM HASP etc.) are implementable with enable/disable
and multiple virtual printers on the same physical device via lp.  I'm not
too sure about lpr, but I suppose the modern ones can do this.

Job restart could be handled by extending the interface scripts in lp,
and perhaps by specialized filters with lpr.

The principle difficulty with extending lp or lpr to HASP-style functionality
is two-fold:

    1) HASP assumes printer operators.  Whereas most UNIX systems
       run without operators, let alone printer operators.
       You can write fancy interface mechanisms all you want, but
       unless there's a well-defined (and used often enough to
       be worthwhile writing) operator interface/channel/person,
       like a HASP "console" where you expect somebody to be sitting
       and ready to enter commands in response to some event,
       it won't get used.  Say a printer jams.  Where does it send
       the acknowledgement?  The originator?  /dev/console?
       "write root"?

    2) HASP needs to be able to interpret the contents of a job
       for fine printer control.  So when that cheque run jams,
       the operator (that pesky non-UNIX person again ;-) can
       tell the spooler to back up two pages, and the spooler
       knows where the pages *are*.  Back with IBM mainframes,
       it was easy with printer-control words embedded in plain
       text (you remember the "1"'s, "+"'s etc in column 1?).
       But in UNIX, you could just as easily be dumping PCL
       rasters one moment, PostScript the next, and the spooler
       hasn't got a chance at knowing where a page starts - often
       only the printer knows.

There are some other necessary items, like job rerouting (doable
in lp if you drop the scheduler :-( etc.  Mostly fairly simple.
Page seek is the toughy, and I don't really think a IEEE standard
is going to make that any easier in the face of real-world applications.
Given today's crop of printers, I don't think you'll ever see it
except embedded into applications that know where the pages are and
bypass spoolers.

BRL's MDQS (or MQDS, I'm sure I'll get yelled at again for spelling
it wrong) does most of the above except for page seek (I would
imagine).
--
Chris Lewis; [e-mail]; Phone: Canada 613 832-0541
Psroff 3.0 info: [e-mail]
Ferret list: [e-mail]