poole@verw.switch.ch (Simon Poole) (11/27/90)
This problem has been known for some time, but as it seems that it wont be going away anytime soon, I think it's time to inform the people that will get hurt by this problem (note that this is not really PP's fault): In some circumstances EAN (I've only seen it happen with the VMS DFN version, but these just happen to be the only systems we have connected to PP sites) will generate messages with some extra junk on the end this is already the case in the message file on disk. EAN will transfer the whole contents of the file regardless if it is part of the message contents or not, alas PP doesn't ignore the extra bytes and aborts the transfer. Due to the way EAN manages it's queues this means essentialy everything comes to a screeching stop. You have the problem, if you see something like the following in your PP log files: 11/22 23:22:42 x400in84 09186 (#1406 ) io_lose -> MECH [Protocol state mismatch] 11/22 23:22:42 x400in84 09186 (#1406 ) RT-P-ABORT.INDICATION: [Session disconnect] exception in progress (Invalid operation at session) The only workaround I currently know about, is to edit the offending EAN message file with emacs and remove any junk at the end of the legal ASN.1/ BER, I'm currently doing this up to a dozen times per day on three different systems (it's not quite as bad as it sounds). Simon
harald.alvestrand@elab-runit.sintef.no (Harald Tveit Alvestrand) (11/27/90)
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. Harald A
poole@chx400.switch.ch (Simon Poole) (11/28/90)
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 ------------------------------------------------------------------------