[2551] in Enterprise Print Delivery Team
Re: Problem with spooling the output of the G/L Statement run
daemon@ATHENA.MIT.EDU (Theresa M Regan)
Wed May 7 12:49:59 2003
Date: Wed, 7 May 2003 12:49:53 -0400
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
Cc: Jay Nickerson <jnicker@MIT.EDU>, David F Lambert <LAMBERT@MITVMA.MIT.EDU>,
Gillian Emmons <gemmons@MIT.EDU>, r3-admin@MIT.EDU, r3-print@MIT.EDU,
Enterprise Printing Delivery Project Team <printdel@MIT.EDU>,
isst@MIT.EDU, debbie@MIT.EDU, klyons@MIT.EDU
To: David M Rosenberg <rosenberg@MIT.EDU>
From: Theresa M Regan <tregan@MIT.EDU>
In-Reply-To: <1052318072.3eb91978cc9e1@webmail.mit.edu>
Message-Id: <ED0D3BBF-80AB-11D7-B931-000A95788FA2@mit.edu>
Content-Transfer-Encoding: 7bit
Good Afternoon,
here is a brief update...
When Ron called and mentioned the problem to me, it sounded like a
problem we experienced earlier.
My quick recollection was the handshaking between devices was the
problem (half duplex vs full duplex) which was resolved by Network
Operations, last time. It appears that pillage's connection to the
network was recently moved, so, the problem reappeared. Network
Operations revised the switch's settings to 100Mb/s full-duplex.
Below is a more complete explanation and a recommendation/suggestion to
mitigate this problem in the future.
Thanks,
Theresa
Network Operations Summary:
Ethernet devices on a network support what is called auto-negotiation
which allows two interconnected devices to negotiate the connection
speed and duplex between them. Connection speeds can vary from 10Mb/s
100Mb/s or 1000Mb/s with today's technologies, and duplex is of either
full or half-duplex. Full duplex allows an ethernet connection to carry
data in both directions simultaneously, effectively doubling the
transmission capacity. As an example a 100Mb/s full-duplex link can
effectively carry 200Mb/s transmitting and receiving.
Devices which negotiate and decide on speed and duplex settings which
do not agree with the settings the device they are negotiating with
decided will experience a variety of odd network failure modes. Normal
link tests using for example icmp pings will show that the link appears
to be working correctly, but under duress it will be poor performing
and tcp/ip applications may exhibit a variety of odd failure modes.
Pillage the ipm print server auto-negotiated with the Cisco catalyst
5000 and established a port speed of 100Mb/s at HALF-DUPLEX, while the
IPM server itself thought it had negotiated 100Mb/s full dupelx with
the switch, and this resulted in a duplex mismatch. The duplex-mismatch
caused tcp/ip connections to the ipm print server to sometimes fail,
and specifically this caused transmission of print jobs between the
sap/r3 environment and ipm to fail with errorrs sending. The solution
is to set the speed and duplex on the switch so as to ensure that the
appropriate speed and duplex settings are reached, and enabling
effective data transmission between other hosts and the ipm print
server. As we saw a year or so ago with a similar problem printing from
the sap/r3 environment, this was the effective solution, but a more
effective long term solution may be to set the speed and duplex
settings of the ethernet connection to 100Mb/s full-duplex within
pillage's kernel so its maintained if the machine's ethernet port moves
in the future.
On Wednesday, May 7, 2003, at 10:34 AM, David M Rosenberg wrote:
> Jay,
>
> I really doubt that the problem has anything to do with your desktop
> machine. I
> also doubt that you will have to rerun the statements. Even though
> they are not
> getting to InfoPrint Manager, they have been produced and are being
> held as
> spool files on SAP. When the problem is resolved, it should be
> possible to
> re-send them to InfoPrint Manager.
>
> From my conversation with Lynn a few minutes ago, there is a
> speculation that no
> files have gotten from SAP to InfoPrint Manager for the last week or
> so.
>
> It might be helpful if someone can try to determine the most recent
> date on
> which files from the SAP production system were successfully printed
> through
> InfoPrint Manager.
>
> I'm at Lincoln today. I can be reached at 181-2344.
>
> --
> /David M Rosenberg
>
>
> Quoting Jay Nickerson <jnicker@MIT.EDU>:
>> Hello,
>>
>> I'm thinking it has to do with the new machine I upgraded to
>> recently. I
>> found that I could not map to printer EP12. I called Lynne and she
>> informed me that I needed to get KLP installed. Bill Huxely
>> installed KLP
>> and then printer EP12. Bill helped me last evening at about 6 pm. I
>> started the statement job earlier in the day yesterday. Also, I
>> have not
>> been receiving any other reports such as 001's and 4 copies of the
>> Fund
>> Analysis report for April 2003. Could this be the problem? And now
>> that
>> KLP is installed will the problem go away? Do I need to rerun the
>> statement job?
>>
>> Jay
>>
>>
>> At 08:43 AM 05/07/2003 -0400, David F Lambert wrote:
>>> Gill,
>>>
>>> I don't see any GL jobs queued on the IPM side. I'll make sure Sue
>>> Starr
>>> or Lynne Durland look at the problem. In the future, it would be
>>> best
>>> to contact either DOST (x3-7049 or dost@mit.edu) or ISST
>>> (isst@mit.edu).
>>> Will let you know what we find as soon as possible.
>>>
>>> -Dave
