Open Server 5.0.5 spooler vs hot printer
Dbush3054
spooler AND a hot printer (direct access from application). Our application
creates a lock file in /tmp similar to this: /tmp/lp.lck to indicate that the
printer is being used and blocks other users from accessing the printer until
the lock file is remove by the application. In the past we have successfully
modified the 'lp' script to check for the existence of this file and wait if
necessary. The script I modified is in /usr/spool/lp/admins/lp/interfaces
(linked to /var/spool/lp/admins/lp/interfaces). The 'lp' script was created
when we created the spool printer 'lp' from /usr/spool/lp/model/standard).
Does not work in Open Server 5.0.5. After putting several echo statements in
the script, I have determined that the script file is properly waiting if the
/tmp/lp.lck file exists. I can watch it loop endlessly until the lock file is
removed by the application. This works when testing because while testing I
was not actually printing from my application, I was just selecting the printer
to create the lock file and then the application is waiting for operator input
(the application hasn't actually sent anything to the printer after creating
the lock file). When I exit the application, it removes the lock file and the
spooler then begins to print. All is well, right ? WRONG !!!
If the application attempts to print after the spooler script is 'looping', the
application IMMEDIATELY gets logged off, which removes the lock file in /tmp
and allows the spooled job to print. I think something before the spooler
script is closing the port, which causes my application to be logged when it
attempts to print.
Any suggestions ???
Thanks in Advance - Dan
Jean-Pierre Radley
Since the spooler usually works just fine, why are you attempting to
bypass it?
--
Jean-Pierre Radley <j...@jpr.com> XC/XT Custodian Sysop, CompuServe SCOForum
Bob Bailin
> Thanks in Advance - Dan
--
Bob Bailin
72027...@compuserve.com
LJ
writing checks. The check numbers have to match the check, if you assign the
numbers and spool, then what happens if you get a paper jam.
Jean-Pierre Radley wrote:
> Dbush3054 averred (on Thu, Jun 10, 1999 at 05:10:23PM +0000):
>
Tom Parsons
| JP, I can think of one app where you cannot spool a printout and that is when
| writing checks. The check numbers have to match the check, if you assign the
| numbers and spool, then what happens if you get a paper jam.
And what happens if you get a printer jam when you are printing direct?
The same thing as when you get one with a spooler.
This insistance that printing direct is a necessity is getting wearisome.
Just remove the trailing formfeed from the interface file......and if you
want to restrict access to the printer, well, the OS has provisions for
that also.
--tom
--
==========================================================================
Tom Parsons t...@tegan.com Sysop, SCOForum-CompuServe
==========================================================================
Brian K. White
> LJ enscribed:
> | JP, I can think of one app where you cannot spool a printout and that is when
> | writing checks. The check numbers have to match the check, if you assign the
> | numbers and spool, then what happens if you get a paper jam.
>
> And what happens if you get a printer jam when you are printing direct?
> The same thing as when you get one with a spooler.
>
> This insistance that printing direct is a necessity is getting wearisome.
> Just remove the trailing formfeed from the interface file......and if you
> want to restrict access to the printer, well, the OS has provisions for
> that also.
>
> --tom
What happens is the application knows or at least has a greater chance
of knowing that check #xxxx did not succeed in printing, accounts do not
get updated falsly, people do not call you next month asking hard
questions. true the print can still fail without the printer and thus
the os or app knowing about it, but this at least decreases the app's
overall ignorance. of course the app *should* know how to verify the
status of critical print jobs by querying the os's own very handy answer
for this very need (lpstat, lpq, maybe even system calls or ioctls I
don't know that deeply) but of *course* a lot of people are
non-negotiably stuck with 'black box' binaries that cost so much way
back when the system was purchased, and years of use meaning years of
accumulated data in xyzapp's proprietary datafiles, that using something
more current, that has more polished such details as printing, is just
not even slightly in the cards. At least according to the guy with the
checkbook.
On the other hand, if your app doesn't allow you the flexability to
teach it how to ask the spooler if the print suceeded, but only knows if
you are printing direct and it gets one of the control flags, and you
are worried about something like failed print resulting in the app
updating itself wrongly, and no paperwork to match it. Use the spooler
to *garuntee* eventual printout, even if the paper does jam. Have a copy
of the spooler files go into a fifo que somewhere, keep a constant weeks
worth say, and hack up some simple scripts to reprint any job you want
easily. You com in in the morning, the ribbon broke or the ink ran out,
and the printer happily printed a five inch stack of blank paper and the
app happily irreversably updated all AR AP & GL files for the month, and
you have 0 reports, 0 statements, 0 checks? no problem, fix the printer
use your script, reprint anything you want from any printer, to any
(possibly other) printer, from anytime in the past week, including
friday nights end-of-month, on monday morning, and no need to hold up
the show either, people can resume using the app immediately as if
nothing happened, since as far as it's concerned, nothing did.
I just thought of printing on pre-printed pre-numbered forms, where the
ability to re-print does not help you when the app beleives that check
#xxx was written but #xxx is irretreivably damaged in a jam and there is
no provision in the app for going back in time and changing the check
number, regenerating all documents that would be affected...
I would have to say in the end that No one can presume to tell anyone
else what they don't need unless they know a lot more details than were
stated so far.
Tony Lawrence
> I would have to say in the end that No one can presume to tell anyone
> else what they don't need unless they know a lot more details than were
> stated so far.
I'll second that.
While it is true that direct printing is sometimes
implemented both poorly and with little reason, there *are*
good reasons not to use the spooler, and it is incredible
presumption to insist otherwise.
--
Tony Lawrence (to...@aplawrence.com)
SCO articles, help, book reviews, tests,
job listings and more : http://www.aplawrence.com
Joel Williams
form, for that matter) should include a message after sending the checks to
the printer (be it spooled or not) like 'Did the checks print correctly?'
If the checks jammed, user answers no and reprints. This ain't rocket
science.
LJ wrote in message <3767FA0C...@checkstop.com>...
>JP, I can think of one app where you cannot spool a printout and that is
when
>writing checks. The check numbers have to match the check, if you assign
the
>numbers and spool, then what happens if you get a paper jam.
>