You have made it into the ifhp 'bug hunters' list.
See below.
> From [EMAIL PROTECTED] Wed Oct 25 14:52:05 2000
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: lprng user survey
> Date: Wed, 25 Oct 2000 17:51:55 -0400
> From: Scott Schwartz <[EMAIL PROTECTED]>
>
> Site Identification:
> Penn State University
> Dept. of Computer Science and Engineering
> Bioinformatics group
> Number of SysAdmins:
> 1 Unix wizard, 1 other admin
> Number and type of Printers:
> 2 HP 4M plus
> 1 Tek740 color
> 1 Deskjet 1600CM
> Number of Print Servers:
> 1 LPRng
> 1 lpr
> 1 Solaris
> Comments on LPRng:
> See enclosed.
> Do you want or need commercial support for printing?
> No.
>
> Comments (and questions):
>
> We just installed lprng for the first time recently, and after running
> it for a few days, here are our impressions. Basically, we're a bit
> disappointed. It seems fragile and klunky (compared to classic lpd;
> we don't like Solaris lp very much.) At the same time, we're grateful
> for the work you've done, and hope we can give you constructive feedback.
>
> Our setting: one HP 4M plus on a 9600 baud serial line, using hardware
> flow control, talking to a Sun Ultra-5 running Solaris 7. A second HP
> 4M plus with an ethernet card. One of our main reasons for installing
> lprng was to gain improved flexibility (vs. Solaris lp) in the addressing
> of email notifications for cancelled jobs.
>
> We've read the HOWTO, looked over the source, and read up on the mailing
> list archives.
>
> * The length and organization of the HOWTO make it read more like
> reference documentation than a true "how-to-do-it" guide. For
> example, it explains what a filter is in section 16.1, long after
> numerous references to ifhp and how to install it. A newbie trying
> to read the HOWTO from the beginning is left in the dust. Perhaps
> you could come up with a "lite" version of the HOWTO that paints the
> big picture and gives a summary of typical installation, so non-expert
> readers can orient themselves before plunging into the detailed docs.
Good point!
>
> * We wish the HOWTO were proofread better.
Please get out the red pen, hard copy, and do so.
I WILL PUT THE CHANGES IN!
> - In several places, the example of what to type says one thing, but
> the accompanying text description uses reference terms that don't
> match the example. For instance, "cancel" vs. "clean" in the
> following excerpts from section 2.11:
> Many utilities in the UNIX System V environment require
> the lp, lpstat, and cancel, programs. <...> In order to
> support these applications LPRng emulates the lp, lpstat,
> and clean programs. See the LPRng man pages for lp, lpstat,
> and cancel in the LPRng distribution for details and
> compatibility. <...> Finally, if the lprm program is
> invoked with the name cancel it will simulate the cancel
> command. This can be done by making a symbolic link to the
> lprm program or by making a copy of the lprm program with
> the name cancel.
> h4: {60} # cd /usr/bin
> h4: {61} # ln -s lprm clean
> h4: {62} # clean 489
> clean 513
> Needless to say, this sort of thing is horribly confusing.
Fixed.
Please please please if you find these, tell me.
>
> - When giving examples of what to type, bits and pieces of broken
> formatting tags sometimes appear as text. For instance, the
> beginning of section 5 of IFHP-HOWTO.html turns out like this:
> model= emphasis/Model Information/
> model_from_option= emphasis/Option with model information/
Sigh...
>
> - For the examples, please choose names for your printers and hosts
> that are obviously site-specific. Something like "my_lp", or even
> the ever-popular "foo", is far better than cryptic things like "h4"
> that could be confused with required syntax. Using "lp" as both a
> keyword and printer name (e.g., section 4.2) is especially bad.
> How is the reader supposed to know which instances of "lp" should
> be replaced?
Good point! How about hplj4 ?
Ummm... as for 'lp', it is not only bad, it is HIDEOUS.
It is also the default printer name ";-) I curse this a lot.
>
> - Please make sure your examples really work as written. For example,
> the installation instructions from section 2.8 read in part:
> h4: {8} % su # you must do the following commands as root
> h4: {9} # make install
> h4: {10} # # if checkpc did not run, do the next command
> h4: {11} # checkpc -f
> h4: {12} # # check to see if the server is running
> h4: {13} # lpq
> However, as root, checkpc and lpq were not in my path. I had to
> hunt around to find that they had been installed in ./sbin and
> ./bin, respectively.
And if you are running CSH, you need to do 'rehash'.
>
> - Lots of small typos. E.g., from section 12.11:
> # Simple example of a bounce queue
> <...>
> # uncomment ab if you want banner
> #ab
> Shouldn't that be "#:ab" in the last line?
>
> * The instructions say you can run the checkpc program without
> the -f option to see if everything is ok, but during our
> installation it failed to complain about some (apparently) critical
> problems with our manually-set permissions for the queue files.
> That is, "checkpc -f" fixed it, even though "checkpc" said there
> was nothing wrong. Perhaps the startup script should just run
> "checkpc -f" automatically? (That is, assuming that "checkpc -f"
> never changes anything outside the realm of the print queue files.)
This is very odd and sounds like a bug.
>
> * lpc (kill,abort,etc) doesn't make the subserver daemon stop, when
> a large file is being written to the printer by the filter (ifhp).
> So we wait a long time for the filter to finish.
I am curious what version you are using. The current implementation
sends a killpg() (kill process group) that should kill off the
subserver AND the server as well as all processes in the process group.
What version of Solaris are you using?
>
> * We miss the "clean" command, from bsd's lpc.
What does this do? By the way, which of the 28 versions of BSD lpd's
are you talking about :-)
>
> * Even with hardware flow control turned on, we sometimes see serial
> driver overflows on input (i.e., ifhp isn't reading the port fast
> enough when the system is loaded). Is this from PCL messages
> printing every ten seconds, or something like that?
>
> Oct 19 17:13:48 frigate.cse.psu.edu unix: WARNING: se0: Buffer overrun
> Oct 19 17:18:58 frigate.cse.psu.edu last message repeated 95 times
>
> Adding of=ifhp seems to have fixed this---does that seem plausible?
No... not at all... I am VERY puzzled...
>
> * When a non-lprng (Solaris) system does an lpq on us, they get pages
> of status back. That seems unhelpful. The documentation talks about
> Solaris reversing long vs short listings, but that doesn't seem correct.
> We want to see the user's name, the file name, etc. But not pages
> and pages of debugging output from the spooler and filter; that should
> be reserved for LPRNG verbose output, unless a filter will parse that
> stuff and extract sensible messages to present (like, "out of paper").
> Somehow HP's own print filter does a nice job of this; I wish LPRNG
> would do the same.
The problem here is trying to make something that is usable by
everybody.
I have tried several solutions to this problem and I get equally large
complaints from all sides.
The only solution I have found that seems to work
is to use the LPD option: 'return_short_status=HOSTSPEC'
where HOSTSPEC is a wildcard or whatever that matches
the various Solaris Systems.
>
> * Moreover, the "long" status is not just status for the last job.
> It's the concatenation of the last several jobs worth of status.
> Very unhelpful, and also confusing for users.
Unless, of course, their job is one of the previous ones...
>
> * When we do lpq, we see information about everything except the
> actual current status of the printer. (Is it out of paper, etc.)
You want to get more status: lpq -ll
>
> Printer: lj326a@frigate '326 Pond'
> Queue: no printable jobs in queue
> Status: job 'schwartz@galapagos+396' removed at 16:42:19.241
> Filter_status: (of) done at 16:42:19.183
>
> * If we run out of paper in the middle of a job, ifhp doesn't seem
> to notice and report that fact. Surely it should get status back in
> that case?
Only if the printer has error/status messages to report it.
No status message, no can do... sigh... I HATE some printers
like this.
>
> * We only print postscript jobs. Is using ifhp the right idea?
> Should we use something simpler?
>
> * When I canceled a print job, it didn't reset the printer's console
> message.
This is because the 'subspooler' was killed off and did not
write a message to the console.
Ummm... your comment about this and the one about the filter
not being killed off seem to be in conflict. Perhaps what
you are seeing is a Zombie, where the process cannot exit until
the socket connection is closed by the remote printer. This will
take a bit of time, especially if there is stuff in the buffer.
>
> * When setting the console message, maybe the basename of the file
> should be generated, instead of the whole path, given that screen space
> is limited.
Good idea. I will put it on the todo list.
>
> * Question: is it better (worse,same) to let ifhp open the device,
> or to let lpd do it?
Let LPD do it. It has better recovery mechanisms.
>
> * On our second printer, an HP 4M plus with an ethernet card, if the
> printer is out of paper, then lprng says:
>
> using model 'hp4mplus' at 19:35:11.520
> pagecount using 'pjl info pagecount' at 19:35:11.526
> setting up printer at 19:35:11.526
> getting sync using 'pjl echo' at 19:35:11.526
> code = 41202, 'PC/Upper/Tray2 - Letter Paper', ALERT OPERATOR at 19:35:19.319
> no response from printer at 19:35:31.315
>
> It did get a response, so why does it say otherwise, and why does lpq
> report "no response" instead of the error code? If of=ifhp is required to
> make this work, I wish the docs would say so more clearly. In any case,
> using of=ifhp, we get the correct error message for a while, but after
> the job times out, the "no response" message wins.
Ummm.... can you say 'bug?' Clearly this is not the way to do it.
>
> * Should lpd_bounce be used if talking to a network printer using RFC1179?
Yes. No. Maybe. Its an option just for this reason.
>
> * Why doesn't lprng (or at least a filter) know how to read PPD files?
> ifhp has snippets extracted from various ones, but that seems tedious
> and manual.
>
Yep. Sure is.
Which of the 6 PPD file 'conventions' do you want to use?
I was DRIVEN to hand editting the PPD stuff...
Patrick
Patrick Powell Astart Technologies,
[EMAIL PROTECTED] 9475 Chesapeake Drive, Suite D,
Network and System San Diego, CA 92123
Consulting 858-874-6543 FAX 858-279-8424
LPRng - Print Spooler (http://www.astart.com)
-----------------------------------------------------------------------------
YOU MUST BE A LIST MEMBER IN ORDER TO POST TO THE LPRNG MAILING LIST
The address you post from MUST be your subscription address
If you need help, send email to [EMAIL PROTECTED] (or lprng-requests
or lprng-digest-requests) with the word 'help' in the body. For the impatient,
to subscribe to a list with name LIST, send mail to [EMAIL PROTECTED]
with: | example:
subscribe LIST <mailaddr> | subscribe lprng-digest [EMAIL PROTECTED]
unsubscribe LIST <mailaddr> | unsubscribe lprng [EMAIL PROTECTED]
If you have major problems, send email to [EMAIL PROTECTED] with the word
LPRNGLIST in the SUBJECT line.
-----------------------------------------------------------------------------
