[comp.protocols.iso.x400] EAN

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
------------------------------------------------------------------------