[2216] in Enterprise Print Delivery Team
Re: For Garry - Must Bounce Queues Change Job Names?
daemon@ATHENA.MIT.EDU (Rocklyn E. Clarke)
Tue Jan 22 13:22:20 2002
Mime-Version: 1.0
Message-Id: <p05010402b8735cbb05ec@[18.152.2.129]>
In-Reply-To: <200201221405.JAA08950@riff-raff.mit.edu>
Date: Tue, 22 Jan 2002 13:22:17 -0500
To: Garry Zacheiss <zacheiss@MIT.EDU>
From: "Rocklyn E. Clarke" <rclarke@MIT.EDU>
Cc: Enterprise Printing Delivery Team <PRINTDEL@MIT.EDU>,
"Housman, Jody L" <jhousman@MIT.EDU>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Hi Garry,
I think it would be best for you to compile a new lpd and provide a
pointer to the new binaries. Please send email to
IPM-SYS@MITVMA.MIT.EDU when this is done so that Jody will know where
to find it. Given the other things that are in her queue, she
probably won't be able to get to this until sometime in February.
Nevertheless, it will be good to have the code waiting for her when
she's ready. Thanks for all your help.
Rocklyn
P.S. I still have my end of the Moira transition and banner page work in my
queue. I expect to get to it this week and will send appropriate email
then.
-------
At 9:05 AM -0500 1/22/02, Garry Zacheiss wrote:
> >> By "mainstream LPRng source" I meant the source we download from the
>>> net, since I assumed that this would move the maintenance burden from
>>> us to Patrick Powell. Now that LPRng is in use by the Central
>>> Printing Service we have become an additional "instance" of LPRng use
>>> at MIT. I therefore feel that it is appropriate to want LPRng to
>>> meet the needs of both Athena Print Services AND the Central Printing
>>> Service as long as those needs don't conflict. If the change in
>>> function that I am suggesting will not cause problems for Athena,
>>> then I think it is reasonable to ask Powell to adopt them (he can
>>> always say no).
>
> Well, I can always ask him if he's interested in this behavior
>change, but that won't have any direct benefit to you; LPRng is on to
>version 3.8.x or so by now, and we're still using 3.6.1 and, at least on
>the Athena side, will continue to for the forseeable future. Any
>changes that made it back to the LPRng mainline would appear in some
>later patch release of LPRng 3.8, presumeably, and you would need to
>migrate to that to take advantage of them. You can do that if you want,
>but I can state quite firmly that I won't be able to help you with it.
>
> I think you're better off either having us make this change in the
>Athena repository or making it yourself and keeping it locally. I get
>the impression you're not in a position to have your tree diverge from
>ours, so you probably want to pursue having us pull it into the Athena
>tree. Since it's not a behavior change we care about, this shouldn't be
>a problem.
>
>>> If this is better accomplished with actual patches to use as a
>>> reference, then I will need to have someone code them since I don't have
>>> the expertise to do it myself and neither does anyone else on my team.
>
> As it happens, I looked at this just now and it's a simple change.
>diffs are included below; I'll submit these for inclusion in the Athena
>source tree. Are these sufficient for someone to generate a new lpd for
>pillage, or would you like me to compile a new lpd for you to test?
>
>Index: lpd_jobs.c
>===================================================================
>RCS file:
>/afs/dev.mit.edu/source/repository/third/lprng/lprng/src/common/lpd_jobs.c,v
>retrieving revision 1.2
>diff -u -r1.2 lpd_jobs.c
>--- lpd_jobs.c 2001/03/07 01:19:31 1.2
>+++ lpd_jobs.c 2002/01/22 13:55:51
>@@ -1003,7 +1003,6 @@
> Set_str_value( &jcopy.info,ERROR,"bad
>bq_format value");
> }
> Set_str_value(lp,FORMAT,Bounce_queue_format_DYN);
>- Set_str_value(lp,"N","(lpr_filter)");
> Set_flag_value(lp,COPIES,1);
> Set_decimal_value(lp,SIZE,job_size);
> }
>Index: lpr.c
>===================================================================
>RCS file:
>/afs/dev.mit.edu/source/repository/third/lprng/lprng/src/common/lpr.c,v
>retrieving revision 1.14
>diff -u -r1.14 lpr.c
>--- lpr.c 2001/11/01 22:11:01 1.14
>+++ lpr.c 2002/01/22 13:56:00
>@@ -886,7 +886,6 @@
> fatal(LOG_INFO,"Make_job: no bq_format value");
> }
> Set_str_value(lp,FORMAT,Bounce_queue_format_DYN);
>- Set_str_value(lp,"N","(lpr_filter)");
> Set_flag_value(lp,COPIES,1);
> Set_decimal_value(lp,SIZE,job_size);
> if( !name ) Set_str_value(&job->info,TRANSFERNAME,0);
