Unbuffered printing in vpix?

[Leslie Mikesell]

In article <2502 at westmark.WESTMARK.COM> dave at westmark.WESTMARK.COM (Dave Levenson) writes:
>In article <7138 at drutx.ATT.COM>, spear at druco.ATT.COM (SpearmanS) writes:
>> Under Simultask 3.0, I get lots of complaints from users
>> that their DOS programs don't fully print out until they
>> exit DOS.

>The problem is that the system generally doesn't know when the
>MS-DOS application has ended.  Dos applications generally don't
>close the printer file, because they think it's a device. Without
>the close, your TSR wouldn't know whether the stuff that's been
>written to the printer is complete.  Even when your application
>ends, UNIX can't tell - there's no UNIX process that ends at that
>point.  Whether MS-DOS is running the command.com or your program,
>it's still one process to UNIX. 

Don't be so kind to VP/ix.  Many MS-DOS programs DO close the printer
device and reasonable network redirectors detect the close and
respond correctly by flushing to the print spooler.  Many other
programs that don't close the default printer device can be configured
to write to a file named LPT1: instead, and will then close it properly.
In any case, exiting the application should always force the close and
be detected by the redirector.

This problem and the fact that multi-user access to files is allowed
without netbios style file locking makes VP/ix unusable in a production
environment.  And, of course the fact that it won't run the most
popular DOS word processor (WP) unless everything is on a DOS partition
or virtual disk sort of indicates that no one cares if it is usable or
not.

>This is why VP/ix requires that the
>operator take some action to flush the print queue.  The operator
>knows when a complete listing is ready for printing.

On the contrary - with modern DOS programs that provide background
printing internally, the operater generally doesn't know, but
network-aware programs will close the device to inform the redirector.

>OS-Merge, as I recall (it's been a year or more) uses a timer
>algorithm.  If the MS-DOS process has written something to the
>printer, and has not written any more for N seconds (N is locally
>administerable, but I think it defaults to 10) then it flushes the
>queue.

This is reasonable as long as it can be configured per-user and disabled
if necessary.

Les Mikesell
  les at chinet.chi.il.us