[2051] in Enterprise Print Delivery Team

home help back first fref pref prev next nref lref last post

Re: Queue Name

daemon@ATHENA.MIT.EDU (David F Lambert)
Wed Dec 12 08:59:09 2001

Message-Id: <200112121358.IAA14687@pacific-carrier-annex.mit.edu>
Date:         Wed, 12 Dec 01 07:41:54 EST
From: David F Lambert <LAMBERT@MITVMA.MIT.EDU>
To: "Lynne E. Durland" <durland@MIT.EDU>, "Huxley, Bil" <huxley@MIT.EDU>,
        R3-Print@MIT.EDU,
        Enterprise Printing Delivery Project Team <printdel@MIT.EDU>
In-Reply-To:  Message of Tue, 11 Dec 2001 10:10:27 -0500 from <durland@MIT.EDU>

Bil,

Let me see if I can help reduce some of your confusion.  I'm responding to
this version of your note so I don't have to read your HTML tags.  Again,
maybe a face-to-face with R3-Print would be more useful - and my fingertips
would certainly appreciate it.  We leave that to you to decide.  Please
see comments below.

-Dave

On Tue, 11 Dec 2001 10:10:27 -0500 Lynne said:
>Bil,
>
>I will answer one of your questions.  Yes IPM can handle flash forms and I
>have done some preliminary work to get the MITSIS flash forms moved over
>and tested.  Other flash forms currently used on VM will be handled on a
>case by case basis when the requests come in.
>
>Lynne
>
>At 08:14 AM 12/11/2001, Huxley, Bil wrote:
>>Hi Dave,
>>
>>Everything you say here comes as a surprise to me, unless you mean to
>>suggest, say, a year from now.  Implementing EP1 was a PrintDel initiative
>>based on a CAO request and OCP hardware funding and intended as a
>>pilot.  Migrating EP1 to IPM was a PrintDel initiative.  Implementing a
>>'general' print queue which utilizes the IP60 printer was an R3-Print
>>request which seemed to be less than "enthusiastically embraced" by
>>PrintDel.  You'll recall that we felt it would be advantageous to
>>implement this prior to implementing something as complicated and
>>specialized as the GL Summary Statement & DTR printing.

There's certainly no fuse or rush to change EP1.  EP1 was not a pilot
from DOST's perspective.  It was a response to an immediate CAO need for
central Postscript printing to address the ancillary monthly GL reports.
We were not thrilled about using a new less robust queue/device management
tool (APS) than we had with the MF or with the future IPM based service.
We have NOT proposed a name change to EP1.

Printdel has been under significant pressure to complete its work, and
to get the Statements moved to Postscript.  Sorry if you were left with
the impression we were not embracing the idea of a general use SAP queue
for the IP60.  We needed to provide several general use queues for non-SAP
testing & use.  Please note there are competing pressures.  The general
use queues were needed to address an immediate need of Grad Admissions.
They've been using IPM for pilot production use for several months.  We
absolutely believe there is value in the general use SAP queues and
are trying to move that piece of our work forward now.

The duplexing code was not easy to solve but was required before providing
the general queues to SAP.  That problem has been solved now - allowing us to
move forward with the general use queues.

Not everyone's request can be at the top of our task list at the same time.

>>Now I think I'm hearing that you are considering substituting DC1 for EP1
>>(effectively).  Please consider the fact that you could in fact do this
>>relatively transparently (to the desktop anyway) by simply telling IPM to
>>direct EP1 jobs to the IP60 rather than the HP 8100.  Such a switch may
>>have an impact on job delivery/availability and/or the look of the output
>>and those are certainly important considerations, but those are implicit
>>in your suggestion anyway.

We are not discussing the EP1 & EP12 printer names at this time.  We are
discussing the new central queue name for general use from SAP.  We
envision this to be used for the long term and by many users.

As part of the review of E19 services, we may wish to repoint EP1 & EP12
to the IP60s - transparent to the users and avoiding any additional work
on CAOTech's part.  We are less concerned about the appropriateness of
these names since they are used by so few people.  We also had a goal of
minimizing the impact of the HP8100 move to IPM for your users in CAO.

I spoke directly with Theresa to see if see was willing to entertain a
name change for EP60/62.  She said yes, and Lynne followed up with the
new proposed name on behalf of Printdel.  If R3-Print rejects the
proposed name, so be it.  That's your responsibility and call.  Printdel
will not lose sleep.  We just want the most meaningful name for the users'
sake.

>>We (CAO) just made a nontrivial investment to install KLP on all the
>>CAO-Reporting desktops then went through again to  install the EP1-IPM
>>queue.  Each time this kind of work needs to be done it requires shutting
>>down the User's applications and logging them off in order to log in as an
>>administrator - it's disruptive to folk's daily work and responsibilities
>>even if you don't consider the efforts of CAOTech.

We certainly appreciated the work of CAOTech as was noted in recent email
to you as well as mentioned in our monthly status report.  We understand
this is a disruption to users but would also hope that installing a new
printer was not monumental task.

>>Please consider my original question :)  If 'EP' (Enterprise Printing) is
>>considered an inadequate naming convention, why wasn't this addressed or
>>at least discussed in conjunction with very, very recent EP1
>>migration?  I'm confused if y'all consider this a big issue for EP60 and a
>>non-issue for EP1.  I also do not understand why R3-Print was not informed
>>of this issue until I asked why EP60 wasn't mentioned in your IT-Delivery
>>report.

The timing is coincidental.  EP1 is in place and is an established name.
Additionally, in consideration of the work already done with the CAO
desktops, we are NOT proposing a change.  I don't recall any Printdel
statements which indicated the EP60 name is a "big issue".  We simply
thought we could choose a more meaningful name as noted above.

>>I'd also like to offer a perception that IS may not run the only "Data
>>Center" at MIT.  This names assumes IS (it reflects an IS-centric point of
>>view, if you would).

Thank you for sharing this perspective.  EP might also offend PSB or
Copy Tech.  Do you have another suggested name which maybe less 'offensive'?

>>John Curry's five themes come to mind as I make this inquiry again :)
>>Client Orientation (and working together to streamline processes)
>>Collaboration (boundary blind processes and open sharing of common
>>information
>>Sustainability (rising to higher standards)
>>Accountability (clarity or roles and responsibilities)
>>Professionalism (best practices in many areas)

I'm not quite sure what your point is here in reminding us of John's
five themes.  Maybe a face-to-face would help as has been suggested.

>>You mentioned 'forms'.  As far as I know, the current EP1 service does not
>>provide for forms or stock (three hole punch only I believe).  I've asked
>>before if IPM will support flash forms but never got an answer.  Clearly
>>there is some forms (stock) handling for IPM because you've defined queues
>>with names like 'Central-Letter', 'Central-3hole' and 'Central-Archive'
>>(Wow there are 31 "printers" defined on Pillage currently!).

Actually, your question on flash forms was answered twice.  In my 10/5
email to you I referred to our ability to use flash forms, and that
this would be controlled/specified by queue name.  Additionally, Lynne
also sent you email on 10/5 with more specific information about flash
forms, and her activities and plans on this work.

The whole point of the original note was to say "Hey, can we do better
than EP60/62 for queue names?".  For example, do you think 'Central-Letter'
is more meaningful than 'EP60'?

>>My apologies if I haven't been listening and that's the cause of my
>>confusion and lack of understanding :)
>>   Bil
>>
>>At 12/10/2001 06:20 PM -0500, David F Lambert wrote:
>>>Hi Bil,
>>>
>>>Actually we may want to eliminate EP1 altogether at some point.  Our
>>>primary goal initially for EP1 was to move it as transparently as possible
>>>from CAO's perspective.  Since we can handle PS output on the IP60 printers,
>>>we could just point output there with new or existing logical destination/
>>>queue names.  I think it makes sense to minimize and/or eliminate
>>>different queues which basically do the same thing (forms, handling, etc.)
>>>
>>>Some duplication is required now due to accommodating SAP's inability
>>>to use klpr.  So, at some point you can expect EP1's name to change or
>>>be replaced with a queue which performs similarly.
>>>
>>>Hope that helps...
>>>
>>>-Dave
>>>
>>>On Mon, 10 Dec 2001 18:04:35 -0500 Bil said:
>>> >Hi,
>>> >
>>> >Doesn't this imply that you would want to rename EP1 too?
>>> >
>>> >Confused,
>>> >   Bil
>>> >
>>> >At 12/10/2001 01:47 PM -0500, Lynne E. Durland wrote:
>>> >>Greetings,
>>> >>
>>> >>Dave Lambert and Theresa met briefly last week to discuss the name
>>> >>EP60/EP62 for the new general queue for SAP central printing.  Dave
>>> >>expressed concern that EP60 was not as descriptive as it might
>>> >>be.  Theresa agreed to entertain other proposed names.  In our printdel
>>> >>this morning we came up with DC1 and DC12 for the names.  The DC standing
>>> >>for Data Center.  Our current goal is to get this new queue implemented by
>>> >>Friday.
>>> >>
>>> >>Please let un know if the proposed new name is acceptable.
>>> >>
>>> >>Thanks
>>> >>
>>> >>Lynne
>>> >>Lynne E. Durland
>>> >>Information Systems
>>> >>Database Services
>>> >>W91-109
>>> >>O: 617-258-5857
>>> >>C: 617-293-8091
>>> >>H: KB1FEM
>>> >>
>>> >>"When one door of happiness closes, another opens;  but often we look so
>>> >>long at the closed door that we do not see the one which has been opened
>>> >>for us."
>>> >>
>>> >>                 --Helen Keller
>>> >
>>> >
>
>Lynne E. Durland
>Information Systems
>Database Services
>W91-109
>O: 617-258-5857
>C: 617-293-8091
>H: KB1FEM
>
>"When one door of happiness closes, another opens;  but often we look so
>long at the closed door that we do not see the one which has been opened
>for us."
>
>		--Helen Keller
>

home help back first fref pref prev next nref lref last post