[2266] in Enterprise Print Delivery Team
Re: Issues with the New Central Printing Service
daemon@ATHENA.MIT.EDU (Rocklyn E. Clarke)
Thu Feb 7 23:37:47 2002
Mime-Version: 1.0
Message-Id: <p05010403b886023fb3a3@[18.152.2.129]>
In-Reply-To: <200202052012.PAA15540@fort-point-station.mit.edu>
Date: Thu, 7 Feb 2002 23:37:40 -0500
To: David F Lambert <LAMBERT@MITVMA.MIT.EDU>,
Susan S Minai-Azary <AZARY@MIT.EDU>, Theresa M Regan <TREGAN@MIT.EDU>
From: "Rocklyn E. Clarke" <rclarke@MIT.EDU>
Cc: Enterprise Printing Delivery Project Team <printdel@MIT.EDU>,
Roger A Roach <RAR@MIT.EDU>, Bob Ferrara <rferrara@MIT.EDU>
Content-Type: multipart/alternative; boundary="============_-1198979434==_ma============"
--============_-1198979434==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Hello Everyone,
Over the past two weeks I have been reflecting on some of the issues
that have come up as we have implemented the Central Printing
Service. Once of these issues relates to the architecture of our
service and how it relates to MIT's IT infrastructure (hopefully I'm
using these terms correctly). I would like to lay this issue out as
background for later discussion.
Mainframe Printing:
-------------------
The print service that currently exists on MITVMA and MITVMC utilizes
an infrastucture that includes three key layers of abstraction:
- "Virtual Print Queues"
Print output is assigned a destination value (DEST) which determines
which printers can process it. These are "virtual" in that a single
DEST value may be served by two or more printers and two different
DEST values may be processed by the same printer.
- "Location Data"
Print output is assigned a distribution value (DIST) which determines
where it should be delivered once printed.
- "Virtual Userids"
Print output can be generated by or on behalf of a userid which
belongs to a department rather than to an individual. This userid
can have default values for the DEST and DIST options and is
automatically associated with a specific accounting code (presumably
the appropriate one for the department).
All of the above make it easy to distribute and account for print
jobs in a way that does not require any significant distinction
between print jobs generated for individuals and print jobs generated
for departments or for production processes. All of these rely on
the context of users logging in (i.e. authenticating themselves) to a
single machine.
Things are different with the new Central Printing Service:
Central Printing Service (CPS):
-------------------------------
The new Central Printing Service can in theory support the same three
layers of abstraction, but because of the context in which the
service is implemented, this is reduced to two for all practical
purposes:
- "Virtual Print Queues"
Like the mainframe, CPS provides "virtual" print queues. Two
different print queues may direct output to the same real printer and
print jobs to a single print queue may in fact be printed on multiple
suitable printers.
- "Location Data"
CPS allows users to specify the building and room number to which
their print output should be delivered.
- "Virtual Userids" (not ready for prime time)
Because CPS is implemented on a real print server it is possible to
set up departmental or generic userids on that server which are not
"owned" by any individual. Multiple kerberos principals could be
authorized to submit print jobs on behalf of such a generic userid.
As a practical matter however, this is not convenient for our users.
It requires them to follow one procedure when printing on their own
behalf and a different procedure when printing on behalf of a
department. In other words, they would issue a standard klpr to
print on their own behalf, but login to the print server and issue a
local klpr to print for a department or for a production process.
This is a messy solution which lacks the tranparency that exists in
the mainframe environment.
It should therefore be clear that our transition to CPS as currently
implemented results in the loss of a useful layer of abstraction.
Although the web interface to CPS does require the user to specify a
cost object, this doesn't provide the same flexibility that a
departmental userid does. Print jobs submitted via klpr must rely on
the previously set cost object. There are ways of compensating for
the loss of the "virtual userid" layer of abstraction (I can think of
at least one I'd love to code). We probably shouldn't pursue
solutions however until we have agreed on what the infrastructure and
architecture issues are and what impact they have. Presumably this
will happen whenever we meet.
Rocklyn
-------
At 3:11 PM -0500 2/5/02, David F Lambert wrote:
>Hello Susan & Theresa,
>
>At our weekly printdel meeting yesterday, Rocklyn shared some
>of the conversation he had with you recently. Based on his
>comments, it appears that you both have some issues or concerns
>regarding the implementation of the new central printing service.
>Given that we are already running production work with this new
>service and the team would like to wrap up their delivery work,
>it would be useful to resolve any pending issues you have sooner
>than later.
>
>Therefore, the print delivery team would like to request that
>you document your issues/concerns in a prioritized list, send the
>list along to printdel@mit.edu, and schedule us for an ITAG
>meeting (if you feel it's appropriate) as soon as possible.
>If OCP and ITAG have differing issues, two prioritized
>lists are fine with us. Additionally, if Theresa wants to meet
>separately from the ITAG meeting, that's fine too.
>
>I know we all have MIT's best interest in mind. So, the team
>is very confident we can resolve any remaining issues/concerns
>to everyone's satisfaction.
>
>We would like to address your concerns sooner than later. This
>has been a long and tedious project which needs to get wrapped up.
>With production work already being handled by IPM, resolving any
>remaining issues now would be beneficial to all involved.
>
>Thanks in advance for your timely response.
>
>Dave (for the printdel team)
--============_-1198979434==_ma============
Content-Type: text/html; charset="us-ascii"
<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { margin-top: 0 ; margin-bottom: 0 }
--></style><title>Re: Issues with the New Central Printing
Service</title></head><body>
<div>Hello Everyone,</div>
<div><br></div>
<div>Over the past two weeks I have been reflecting on some of the
issues that have come up as we have implemented the Central Printing
Service. Once of these issues relates to the architecture of our
service and how it relates to MIT's IT infrastructure (hopefully I'm
using these terms correctly). I would like to lay this issue out
as background for later discussion.</div>
<div><br></div>
<blockquote>Mainframe Printing:</blockquote>
<blockquote>-------------------</blockquote>
<blockquote>The print service that currently exists on MITVMA and
MITVMC utilizes an infrastucture that includes three key layers of
abstraction:</blockquote>
<blockquote><br></blockquote>
<blockquote>- "Virtual Print Queues"</blockquote>
<blockquote>Print output is assigned a destination value (DEST) which
determines which printers can process it. These are
"virtual" in that a single DEST value may be served by two
or more printers and two different DEST values may be processed by the
same printer.</blockquote>
<blockquote><br></blockquote>
<blockquote>- "Location Data"</blockquote>
<blockquote>Print output is assigned a distribution value (DIST) which
determines where it should be delivered once printed.</blockquote>
<blockquote><br></blockquote>
<blockquote>- "Virtual Userids"</blockquote>
<blockquote>Print output can be generated by or on behalf of a userid
which belongs to a department rather than to an individual. This
userid can have default values for the DEST and DIST options and is
automatically associated with a specific accounting code (presumably
the appropriate one for the department).</blockquote>
<blockquote><br></blockquote>
<blockquote>All of the above make it easy to distribute and account
for print jobs in a way that does not require any significant
distinction between print jobs generated for individuals and print
jobs generated for departments or for production processes. All
of these rely on the context of users logging in (i.e. authenticating
themselves) to a single machine.</blockquote>
<div><br></div>
<div>Things are different with the new Central Printing Service:</div>
<div><br></div>
<blockquote>Central Printing Service (CPS):</blockquote>
<blockquote>-------------------------------</blockquote>
<blockquote>The new Central Printing Service can in theory support the
same three layers of abstraction, but because of the context in which
the service is implemented, this is reduced to two for all practical
purposes:</blockquote>
<blockquote><br></blockquote>
<blockquote>- "Virtual Print Queues"</blockquote>
<blockquote>Like the mainframe, CPS provides "virtual" print
queues. Two different print queues may direct output to the same
real printer and print jobs to a single print queue may in fact be
printed on multiple suitable printers.</blockquote>
<blockquote><br></blockquote>
<blockquote>- "Location Data"</blockquote>
<blockquote>CPS allows users to specify the building and room number
to which their print output should be delivered.</blockquote>
<blockquote><br></blockquote>
<blockquote>- "Virtual Userids" (not ready for prime
time)</blockquote>
<blockquote>Because CPS is implemented on a real print server it is
possible to set up departmental or generic userids on that server
which are not "owned" by any individual. Multiple
kerberos principals could be authorized to submit print jobs on behalf
of such a generic userid. As a practical matter however, this is
not convenient for our users. It requires them to follow one
procedure when printing on their own behalf and a different procedure
when printing on behalf of a department. In other words, they
would issue a standard klpr to print on their own behalf, but login to
the print server and issue a local klpr to print for a department or
for a production process. This is a messy solution which lacks
the tranparency that exists in the mainframe environment.</blockquote>
<blockquote><br></blockquote>
<div>It should therefore be clear that our transition to CPS as
currently implemented results in the loss of a useful layer of
abstraction. Although the web interface to CPS does require the
user to specify a cost object, this doesn't provide the same
flexibility that a departmental userid does. Print jobs
submitted via klpr must rely on the previously set cost object.
There are ways of compensating for the loss of the "virtual
userid" layer of abstraction (I can think of at least one I'd
love to code). We probably shouldn't pursue solutions however
until we have agreed on what the infrastructure and architecture
issues are and what impact they have. Presumably this will
happen whenever we meet.</div>
<div><br></div>
<div><br></div>
<div>Rocklyn</div>
<div><br></div>
<div><br></div>
<div>-------</div>
<div>At 3:11 PM -0500 2/5/02, David F Lambert wrote:</div>
<blockquote type="cite" cite>Hello Susan & Theresa,<br>
<br>
At our weekly printdel meeting yesterday, Rocklyn shared some<br>
of the conversation he had with you recently. Based on his<br>
comments, it appears that you both have some issues or concerns<br>
regarding the implementation of the new central printing service.<br>
Given that we are already running production work with this new<br>
service and the team would like to wrap up their delivery
work,</blockquote>
<blockquote type="cite" cite>it would be useful to resolve any pending
issues you have sooner<br>
than later.<br>
<br>
Therefore, the print delivery team would like to request that<br>
you document your issues/concerns in a prioritized list, send the<br>
list along to printdel@mit.edu, and schedule us for an ITAG<br>
meeting (if you feel it's appropriate) as soon as possible.<br>
If OCP and ITAG have differing issues, two prioritized<br>
lists are fine with us. Additionally, if Theresa wants to
meet<br>
separately from the ITAG meeting, that's fine too.<br>
<br>
I know we all have MIT's best interest in mind. So, the team<br>
is very confident we can resolve any remaining issues/concerns<br>
to everyone's satisfaction.<br>
<br>
We would like to address your concerns sooner than later.
This<br>
has been a long and tedious project which needs to get wrapped up.<br>
With production work already being handled by IPM, resolving any<br>
remaining issues now would be beneficial to all involved.</blockquote>
<blockquote type="cite" cite><br></blockquote>
<blockquote type="cite" cite>Thanks in advance for your timely
response.</blockquote>
<blockquote type="cite" cite><br></blockquote>
<blockquote type="cite" cite>Dave (for the printdel team)</blockquote>
<div><br></div>
</body>
</html>
--============_-1198979434==_ma============--
