Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!usc!orion.oac.uci.edu!ucivax!gateway From: poole@chx400.switch.ch (Simon Poole) Newsgroups: comp.protocols.iso.x400 Subject: Re: EAN (DFN?) - PP interworking problem Message-ID: <1990Nov27.212435.25568@chx400.switch.ch> Date: 28 Nov 90 01:19:20 GMT References: <2035*harald.alvestrand@elab-runit.sintef.no> Reply-To: Simon Poole Organization: SWITCH Zuerich, Switzerland Lines: 22 Approved: usenet@ICS.UCI.EDU x-attn: jns ReSent-To: mhsnews@ICS.UCI.EDU In article <2035*harald.alvestrand@elab-runit.sintef.no> harald.alvestrand@elab-runit.sintef.no (Harald Tveit Alvestrand) writes: >I have seen it also from DFN. >There is even a special log message given in UBC-EAN: >txpact.c: w_fmt( Log, "`Oextra `d bytes at end of APDU (ignored)`n", >It is logged at WARNING level, so you have to have level 7 to get it written. >(-t7 on TXP invocation). >I have not seen it lately, though, and never on an UBC connection. We see this mesagge pretty often too, alas while this is the same symptom, it's not actually related to EAN generating one of these bogus message files (it's the result of receiving one, but EAN seems to handle this error correctly, with other words the error doesn't seem to propagate). I assume that the problem is actually caused when EAN writes the message to disk; if you look at the stuff at the end of the message it normally is a copy/leftover from the beginning of the message. -- ------------------------------------------------------------------------ Simon Poole poole@verw.switch.ch / poole@chx400.switch.ch / mcsun!chx400!poole ------------------------------------------------------------------------