[1804] in Enterprise Print Delivery Team
Re: resolved: (appears) gltw, glte, glmp
daemon@ATHENA.MIT.EDU (David F Lambert)
Sun Oct 21 14:24:26 2001
Message-Id: <200110211823.OAA03980@fort-point-station.mit.edu>
Date: Sun, 21 Oct 01 14:00:36 EDT
From: David F Lambert <LAMBERT@MITVMA.MIT.EDU>
To: Theresa M Regan <tregan@MIT.EDU>, r3-print@MIT.EDU,
Enterprise Printing Delivery Project Team <printdel@MIT.EDU>
cc: debbie@MIT.EDU, mprudden@MIT.EDU, Gillian Emmons <gemmons@MIT.EDU>,
Jay Nickerson <jnicker@MIT.EDU>, Garry P Zacheiss <zacheiss@MIT.EDU>,
James M Kretchmar <kretch@MIT.EDU>, Thomas J Coppeto <tom@MIT.EDU>,
mark@MIT.EDU, Paul Page <ppage@MIT.EDU>, ASST <asst@MIT.EDU>,
Roger A Roach <RAR@MIT.EDU>, Tom Dalton <tdalton@MIT.EDU>,
Datacenter Operations Services <DOST@MITVMA.MIT.EDU>,
Jeff Banta <jeffbant@us.ibm.com>
In-Reply-To: Message of Sat, 20 Oct 2001 21:21:58 -0400 from <tregan@MIT.EDU>
Many, many thanks to all for testing various paths, isolating the funkiness
we'd been experiencing on the E19 printer, performance with the pillage
server, bad behavioral problems printing from various SAP servers, analyzing
test results, finding the source problem, and for patching the switch.
The print delivery team had been poking at this problem for some time
with the primary symptom being the slowness of the E19 printer. The
recent SAP printing tests really helped identify the source of the problem.
Our only known remaining problem with meeting the original goal for November
printing of October GL statements is some additional disk space for pillage.
At least that issue should be a lot simpler to resolve! :)
Again, my thanks to everyone for their time spent on this.
Dave (for the print delivery team)
ps. We will perform additional testing tomorrow to confirm the switch
fixed the other problems we experienced. Assume all is well unless
you hear otherwise by the day's end.
pps for Theresa. I checked the IPM queues too, and didn't see the recent
file submits. Another note this weekend indicated pillage was sending
lots of messages to the op console. I suspect there's another problem
with pillage. We'll track that down and get you an answer tomorrow.
On Sat, 20 Oct 2001 21:21:58 -0400 you said:
>Good Day,
>
>After further discussion and testing, today, it appears that the problem
>sending SAP R/3 print requests from SF5/PS1 to "pillage" may be resolved.
>
>The solution included an update to w91-109-sw-1's (18.92.0.9)
>configuration, to force the communication between pillage and the switch to
>use full duplex. Previously the switch had been communicating with pillage
>in half duplex mode, despite pillage expecting full duplex communication.
>This configuration was causing degraded performance overall between w91's
>local network and remote locations, and complete inoperability between the
>SAP R/3 environment and the IPM server within the local ethernet segment.
>While destinations outside of the local network appeared functional, they
>still likely suffered degraded performance due to the mismatch in
>communication modes between the switch and pillage.
>
>Unfortunately, I can not test all scenarios or validate any printing.
>
> -- at the moment, SF5 is unavailable
> -- print requests from PS1 arrive in the gltw queue; however, the
>printer is unavailable
>Printer: gltw@pillage 'ibm3160 W91-130' (printing disabled)
>
>Queue: 4 printable jobs
>Server: no server active
>Status: job 'zacheiss@western-outpost+96' removed at 14:34:36.632
>
>Rank Owner/ID Class Job Files Size Time
>1 tregan@beech+98 A 98 000MED7h.SF5.cop 145421 15:56:16
>2 tregan@beech+99 A 99 <NULL> 409902 15:58:36
>3 tregan@beech+100 A 100 <NULL> 2112169 16:03:36
>4 tregan@beech+101 A 101 <NULL> 633042 16:03:37
>athena%
>
> -- the web page, <https://pillage.mit.edu/>, does not reflect the
>recent print requests. Why?
>
>As people have time on Monday, any additional testing and printing would be
>appreciated.
>
>Thanks,
>Theresa
>
