[1797] in Enterprise Print Delivery Team
Re: Queues and some understanding
daemon@ATHENA.MIT.EDU (Garry Zacheiss)
Thu Oct 18 17:32:55 2001
Message-Id: <200110182132.RAA06208@brad-majors.mit.edu>
To: "Lynne E. Durland" <durland@MIT.EDU>
cc: Garry Zacheiss <zacheiss@MIT.EDU>, ops@MIT.EDU, printdel@MIT.EDU
In-Reply-To: Your message of "Thu, 18 Oct 2001 13:43:42 EDT."
<5.0.2.1.2.20011018133954.00abbe40@hesiod>
Date: Thu, 18 Oct 2001 17:32:51 -0400
From: Garry Zacheiss <zacheiss@MIT.EDU>
>> Why can't ep12 stay where it is? Is it a requirement of the "bounce"
>> portion of the work that the queues be on the same server?
It's not a requirement, but not doing so would require us to special
case ep12 in the automatically generated printcaps for the SAP print
servers, and would be a monumental hack. If pillage can't support
duplex queues, I would classify it as "crippled beyond belief".
>> In one of your paragraphs below you describe what could work in the
>> printcap on pillage, then say that won't work. What will?
I pointed out that the reason why what I suggested won't work is
because you've added an "if=" line to the .common block (which is
included in all printer definitions) that overides the "if=" line in the
.hp2 block. I didn't suggest a fix for this because the correct fix
will require refactoring the shared config blocks in the printcap. You
might want to have a .common2 that includes everything in .common except
for the if tag, or you may prefer some other approach. There is no
single right answer.
>> Is there a time tomorrow that you and I can get together and discuss
>> this in person? I will not have my usual 4 p.m. deadline to walk out
>> the door.
I'm not available today or tomorrow, but I could possibly make time
next week; however, I really don't think this requires a meeting.
Setting up duplex queues should be straightforward (and, as I've
mentioned before, you really should look into having pillage's printcap
automatically generated, or at least manipulated by scripts. Editing it
by hand is just asking for trouble in the long run).
Garry
