386ix and Parallel Printers

[Bob Monio]

In article <1990May6.152012.14804 at ddsw1.MCS.COM> karl at mcs.MCS.COM (Karl Denninger) writes:
>In article <1990May3.111446.2879 at oct1.UUCP> mason at oct1.UUCP (David M. Mason) writes:
>>In article <15427 at bfmny0.UU.NET> tneff at bfmny0.UU.NET (Tom Neff) writes:
>>>My advice: If you're not really running multi-user, ditch the spooler.
>>>It's a pain in the caboose.  Just pump to /dev/lp and have a nice day.
>>
>>There is also a signifiacant saving in main memory if you don't use the
>>spooler.  On ISC 2.0.2 it takes 181k every time you type "lp".  On
>>straight AT&T 3.2 it's about 244k.
>>
>>On the other hand, I have never had more support hassles than from
>>packages that try to get smart and talk straight to a SERIAL printer
>>port.  Try explaining "stty -a" to an accountant.

Not to be picky, guys, but Tom's message above referred to /dev/lp,
not a tty.  Unless Tom has his /dev/lp linked to a tty I doubt that
he's referring to a serial printer, but rather a parallel port.  

>Yeah, no kidding.
>
>Put about 3/4 of the accounting packages in the WORLD in that basket.  They
>deserve it.  Then shoot the programmers -- they deserve it too.

It's not just accounting.  The company I do some work for has a
wholesale distribution package that does both; write directly to the
serial printer and also use the spooler.  I'm not sure why it was
originally done this way, but we are in the process of changing it.

>MCBA is an offender.  They try to talk direct to serial printers.  It
>doesn't work much of the time, since they aren't smart enough to do an
>ioctl() once they open the port!
>
>Guess what?  You end up with a few processes "holding open" the port, which
>can cause other problems.  That REALLY sucks, folks.
>
>What they should do is use the "class" features of the spooler if they're
>worried about special forms, or use the "forms" features in the SVR3
>spooler.  But no, they have to be "cute" and write direct.

Perhaps.  When I asked the program's designer why he used a mixture of
both, he responded by saying that there was no such capability
available with the old spooler under SVR2.  Modifying it now to
support SVR3 would be a help, yes, but it would limit portability
across versions of UNIX that do not have the same spooler
capabilities.  From what we've seen of AIX, it's even more different.

>If I had a dollar for everytime I saw this........

It's caused a few headaches for me also.  But lately it's been more of
a problem with poor integration on the part of hardware/OS
combinations that have hurt more than anything else.

>And they wonder why people don't take Unix seriously in the business
>marketplace?  It has nothing to do with the operating system, and everything
>to do with the monkeys who program the applications for it.

Agreed.  But remember that it's a rather rough job to provide
portability in a program across different versions of spoolers on
different flavors of UNIX.  It's made harder in case of the above
mentioned program when the 4GL that is being used doesn't support
spooling of output at all...  (ie: PROGRESS)

-- 
 Robert A. Monio                     "I've learned all my heroes and wanted
 Level I Systems, Inc.                the same/To try out my hand at the
 pnessutt at dmshq.mn.org                Patriot Game..."
 ..amdahl!bungia!dmshq!pnessutt            -- Robby Jackson, 'Patriot Games'