Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!orion.oac.uci.edu!ucivax!gateway
From: poole@verw.switch.ch (Simon Poole)
Newsgroups: comp.protocols.iso.x400
Subject: EAN (DFN?) - PP interworking problem
Message-ID: <1256*poole@VERW.SWITCH.ch>
Date: 26 Nov 90 20:46:04 GMT
Lines: 31
Approved: usenet@ICS.UCI.EDU

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