🚀 go-pugleaf

Carl (csg@pyramid.pyramid.com) writes:
{} [...]
{} That's right. Note that this *is* changing; I believe we can now run 8 bits
{} among the U.S. (Tymnet and Telenet) the U.K. (PSS) and Canada (Datapac). But
{} for amusement I tried Germany again yesterday. All my 8th-bit-on words were
{} stripped. Curious thing, too -- you *need* all eight bits to get X.25 packet
{} header through, to say nothing of the 16-bit FCS. But if the network has done
{} a protocol conversion, almost anything can happen....
You must be doing something wrong ... 

As you now, we're polling YOUR site since Jan'88 - and since the German
Bundespost (PTT) still hasn't set us "online" with our own X.25, we are
using a public-access port (public pad) to dial in at pyramid.
[you call up a local 1200 Bd. Number, where you get connected to a
 X.28/X.29 conforming PAD]

We were using UUCP 'g' protocol for four months WITHOUT any trouble, even
in transferring binaries. We now use 'f', but I tend to step over to 'k'.

I think the major problem with the transparancy (and that includes the
eigth bit) lies in the PAD being used. There are some recomended profiles
for X.28 PADs, of which the third is almost transparent.
The parameters for the third are:

1:0, 2:0, 3:0, 4:20, 5:0, 6:0, 7:2, 8:0, 9:0, 8 to 12 all 0!

The most interesting ones are 5&12 (disable flow control), 1 (ignore DLE),
and some national parameters (eg. 123 in Germany), which control the
use of PARITY bits in the data stream.

As I said, you may drive 'g' on this setup without any problems, but
be careful about some hosts, which simply reset your PAD parameters
by an X.29 message to other - and perhaps strange - values, like the
'monopad' does ...

Clemens Schrimpe

UUCP:	csch@tmpmbx	=	{pyramid|tub|unido}!tmpmbx!csch
BITNET:	csch@db0tui6	csch@tub.BITNET
PHONE:	+49-30-332 40 15
TELEX:	186672 net d
FAX:	+49-30-361 40 93
X.25:	--- hopefully available soon --- ]:-}