>>Foteos Macrides said:
>>> This was also a historic (8-) opportunity to see how the EMBL
>>> UUEN/DECODEing software fares when the file crosses an Internet -> BITNET
>>>>Nope, Rainer Fuchs and the person who designed the EMBL
>>uuencode/uudecode did it *explicitly* for that problem. I also tested
>>it when I started the UH Gene-Server. A crude guess would suggest
>>that, from my end anyway, it has been tested on the order of 4000
>>>>dr. dan davison
>> So why couldn't I decode it until after I did an E3 -> 5E global
>search and replace? Note that carats are not corrupted when crossing a
>gateway in the BITNET -> Internet direction, or when travelling entirely down
>a BITNET chain or entirely via Internet from EMBL, only when going across from
>Internet to BITNET.
>> The routing info for your posting indicates that you communicate with
>BIO-SOFT at genbank.bio.net via your Internet address, so you should not have
>experienced the corruption and should have had no trouble decoding the file.
Let's think this all the way through while we have a concrete example.
Your server is on the Internet so it should also get UUENCODEd files from EMBL
without corruption. Rainer exchanged the "historic" file with Rob via
Internet, and it was posted to software/BIO-SOFT via genbank.bio.net, so no
corruption would be expected to that point. Internet nodes which SHOULD have
experienced a corruption are those subscribed to BIO+SOFT via
LISTSERV at IRLEARN.BITNET, because the posting had to cross from Internet to
BITNET (at STANFORD or CUNY) going from genbank.bio.net to the LISTERVer. Is
that so, and could subscribers on such nodes decode the file without doing an
E3 -> 5E global search and replace?
I also just tried getting an EMBL .UUE file via Email from your
gene-server, and the carats were not corrupted, but you're using PMDF to put
it locally onto a BITNET chain (i.e., it didn't cross an external Internet ->
BITNET gateway getting TO your server from EMBL, and it similarly didn't cross
one to get here FROM your server), so that didn't turn out to be a test of the
hypothesis (it's the EBCDIC/ASCII mapping at the external gateways that
appears to have a bug, which has existed for so long that it's accepted as a
"characteristic" of the gateways).
I'll be out of town until mid-week, so I won't be able to respond to
responses to this posting until then (Whooh! The "noise" will be away for a
Foteos Macrides Worcester Foundation for Experimental Biology
MACRIDES at WFEB2.BITNET 222 Maple Avenue, Shrewsbury, MA 01545