[2005] in Enterprise Print Delivery Team
Re: SAP & IPM printer processes
daemon@ATHENA.MIT.EDU (Huxley, Bil)
Fri Dec 7 08:42:25 2001
Message-Id: <5.0.2.1.2.20011207082949.00af45b0@po9.mit.edu>
Date: Fri, 07 Dec 2001 08:43:31 -0500
To: Theresa M Regan <tregan@MIT.EDU>, "Lynne E. Durland" <durland@MIT.EDU>
From: "Huxley, Bil" <huxley@MIT.EDU>
Cc: Cana Lynn McCoy <cana@MIT.EDU>, hesreq@MIT.EDU, printdel@MIT.EDU,
R3-Print@MIT.EDU, kelley@MIT.EDU, ops@MIT.EDU,
Garry Zacheiss <zacheiss@MIT.EDU>
In-Reply-To: <5.0.2.1.2.20011206104532.0247fd80@hesiod>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Hi,
I wished to comment on one additional observation with our recent EP1
experiences and these process notes. I'm dropping CAOTech from this
distribution at this time because I think we've wandered beyond their area
of involvement :)
R3-Print never received notice of the Moira changes for EP1 via the feed to
ASST/windsurf. Even though that was the point which started a lot of this
most recent dialogue about processes and the flow of info to various teams
to trigger their action items and even though it's been confirmed that the
switch to Pillage was fed and acted upon I'm guessing now that the
'windsurf' logic identifies only additions and deletion as causes for
notification, though it's processing more than that to the SAP Printcap.
Question: should R3-Print be notified of other changes observed in the
Moira feed? The new broader capabilities with regard to print servers
(we're not just on Arbor-Eater and Fiber any more Toto) is the current
focus, but even with regard to Moira updates to models and locations there
might be value in notifying R3-Print. Are there any other attributes which
should be considered for notification?
What do y'all think"
Bil
At 12/6/2001 11:43 AM -0500, Theresa M Regan wrote:
>Hi Lynne,
>
>thanks...
>
>Based on the last few exchanges, it seems that a recap of current process
>may be helpful and possibly, alleviate a step or two. Example: e-mail to
>r3-print may not necessary if the queue is included in the current
>process. Also, there are two dimensions of MOIRA's printer
>characteristics, we rely on from time-to-time that may be helpful to
>mention: restrict list and LPC ACL
>
>Current Process
>------------------------
>
>Athena Print Services will create a printer definition in MOIRA and for
>administrative users mark it as SAP. (Generally, these requests are sent
>to "hesreq". Some requests come via Computing-Help.)
>
>Today, any printer requests for the administrative community and/or SAP
>are created in MOIRA and propagated to the print servers: arbor-eater or
>fiber. (After printer definitions are created, hesreq receives revisions
>from time-to-time and these revisions are reflected in the daily process.)
>
>Nightly, the printer definitions from arbor-eater and fiber are sent to
>windsurf.
>
>R3-print is notified when the "new" or "deleted" print queue data arrives
>at windsurf.
>
>R3-print is notified, again, after the printer definitions have been
>updated on all of the R/3 servers.
>
>Since Garry has confirmed that the nightly feed will include pillage and
>plunder when designated SAP, this appears to fall nicely into the
>process. (I should go back and at the windsurf e-mail notifications to be
>sure that we clearly note the IPM queues.)
>
>If people agree with the above steps, then, we can alleviate the r3-print
>e-mail when sending requests to hesreq.
>
>Once the printer definitions are defined on the servers, they are
>configured within SAP R/3 (SF2) and transported to all remaining SAP R/3
>environments.
>
>There are a few Departments who prefer that only certain people print to
>their printers. These departments maintain an Athena list and it is noted
>within the MOIRA printer definition. It is reference as "Restrict List".
>
>After discussion at R3-Admin, we wish to recommend that IPM print queues
>consider using this approach, as well. Example: glmp would have a list
>glmp-print-restrict and its administrator would be the key Process
>Owner. The Process Owner could delegate the maintenance, if desired.
>
>(My experience with APS is that the print request arrives at the server
>and after a comparison with the list, it is either printed or
>deleted. How the IPM implementation would handle requests from an
>unauthorized person is a "printdel" question.)
>
>Another MOIRA printer characteristic, we have used on a limited
>basis... is who may manage print queues? For those Departments with
>technical staff and lots of printers, we have set the attribute: LPC
>ACL For CAO, it is managed through the list caoprint
>
>Hopefully, I have captured the printer/print queue process accurately and
>reasonably clearly. If others wish to clarify or expand, please feel
>free. Once printdel has had time to consider the restrict list approach,
>possibly, we could focus on its implementation for the 4 queues in
>question: glmp, glte, gltw, (missing one).
>
>Thanks,
>Theresa
