[continued from previous message]

Scaling. Uploads to current Linux's will be painfully slow, single-digit KBytes/s range, even over 100M Ethernet. If you disable window scaling in
/proc (or /sys?), it's fast again, but everything else will be slow. Or if you put a Cisco ASA in between to delete the WScale-Option while the TCP handshake takes place.

There's that "Open" again. And again with something to be interoperable
with other systems.

Yes, and this time again with a subtle twitch.

Fortunately, Cisco decided to implement the server side in IOS. Nice!

Interesting.
I'll have to check this out.

Works like a charm. You can to telnet & friends with just a Mac SE attached to LocalTalk. :-)

To get on-topic again: Did you know that IBM once build LocalTalk cards
(SPD) for the AS/400?

No, I did not.

See here: <https://www-01.ibm.com/common/ssi/cgi-bin/ssialias?appname=skmwww&htmlfid=897%2FENUS193-242&infotype=AN&mhq=IBM%20Network%20Station%208361%20Series%20100&mhsrc=ibmsearch_a&subtype=CA>
"March 25, 1994: 9404 Model 140 and Workstation Adapter (for LocalTalk (1)) (#6054/#8054/#9054).
(1) Registered trademark of Apple Computer, Inc."
Search for these feature codes and you'll find more information.
Interestingly, there are no pictures to be found in google.

And at least for V3Rsomething there was a PTF bringing the AppleTalk
network stack to OS/400! Documents I find say that this solution even
provided console capability!

Very interesting!

Indeed!

I have herd tell of IBM building a 386 / 486 / Pentium computer that
went into an AS/400 much like an IOA. The idea was to allow a low power
PC to be in the AS/400 foot print for multi-OS compatibility. Somewhat
the same idea of my P/390-E allowing OS/390 to run in a PC chassis.

Yes, that was called an Integrated PC Server. There were models for the proprietary slots in 9406-600 class machines (same as the 9401-150) and later also for PCI only machines.

At first it was just called an integrated file server IOP, than Integrated PC Server (IPCS), than integrated XSeries and maybe more.

I have a Pentium Overdrive Board (2850) with the accompanying board with
S3 graphics chip and other peripheral support. It was hard to get hand on a breakout cable to actually see what's going on on the PC side (VGA, PS/2 Keyboard and Mouse, Serial and Parallel Port).

I had Windows 2000 Server installed on it but after a while, something became defective. I didn't take time to search for replacement boards, yet to learn what exactly got broken.

So the Token Ring, Serial (SDLC), and Coax are all methods to connect to
IBM networking technologies.

Yes. The Coax/Twinax-Card was special in the way that it couldn't be used with standard AppleTalk and MacTCP.

The serial card could be used as standard
serial ports but also for X.25 and SDLC. I have Mac X.25 server but I didn't take time to have a closer look at it. I think, it's also a network central gateway to provide X.25 services to other Macs via AppleTalk.

The Token Ring Card could be used with AppleTalk and MacTCP but it is
painfully slow. I measured about 200 KBytes/s FTP on a reasonably fast Mac
IIfx with not much difference when put into a PowerMac 7100. A PowerMac 7500
in the same ring with a PCI NIC sucked 1,5 MB/s per FTP from the same server.

I have such a card which additionally has a DB-15 port for Twinax!

Are you sure that the DB-15 was for Twinax?

Yes. The card is called "Apple Coax/Twinax Card"

I ask having seen either DB-9 or DB-15, I don't remember which, pigtails
with two twinax connectors.

DB-15, M or F depends on what's to be connected on the other side. A distinction I don't understand.

Maybe you confuse DB-9 with Token Ring? Or with the end of the "small" 4-port twinax-brick?

Here's the only (small) photo I could find on the net. I should start to make photos myself.
<https://yesterbits.com/scans/apple-product-data-sheets/>
Links pointing to Dropbox are broken, though.

And now I'm again learning that there was even more highly interesting stuff. CL/1 server vor MVS/TSO! MacAPPC! It seems that the latter is part of the API stuff for SNA.ps. And MacDFT, which seems to be the other Application to talk to the Coax/Twinax-Card.

Or is there a chance that it's an Ethernet AUI port?

Nope.

I was highly disappointed to learn that SNA.ps doesn't support that
Twinax-Port.

Is there a different file that does?

I'm not sure.

Or why would a card exist that doesn't have software to support one of its features?

Because the software support maybe was once planned, but never released.

A bit similar to the splendid Mac IIfx. The first Mac to incorporate true
DMA for SCSI transfers. Unfortunately, stock MacOS never made use of that capability. A/UX did, rumor says.

Ya. LocalTalk <-> AppleTalk can be somewhat nebulous. The common
definition that I hear is that LocalTalk os the physical layer(s) and AppleTalk is the protocol(s) that ran on top.

Yap. Early documentation referred to what we now know as LocalTalk as "Apple Bus". Maybe someone decided it was too technical and renamed it AppleTalk to sound more friendly.

AppleTalk migrated to Ethernet too.

Not only Ethernet. Afterwards, Apple needed to clarify that Ambiguity and called AppleTalk different depending on which media: EtherTalk, TokenTalk, FDDITalk. Ah, yes, and LocalTalk.

Did you know that almost every internal HP-Print Server for Ethernet supported AppleTalk, IPX and IP but the Token Ring variants supported just IPX and IP.

And, in case you ever need to configure the IPX part of those Print Servers, you really don't need JetAdmin. JetAdmin just configures SNMP over IPX transport. You can set the same parameters via SNMP over IP, too. I was very surprised and documented my findings: <https://kb.pocnet.net/wiki/JetDirect_IPX-Konfiguration>

A good friend of mine that does (did) a lot with Apples and Macs states
that the 230 kbps was really the bandwidth between the CPU and the SCC.
Half of it was towards one hardware port and the other half was
towards the other hardware port.

Not true.

First, you can plug a "printer cable" (RS-422 MiniDin 8 with Mac Pinout) between to Macs and use a terminal program to transfer files with up to 230.4 kb/s. Given the receiving Mac's CPU is fast enough to not miss a byte. Buffer? Which buffer?

Second, there was one pin on that connector you could supply an external clock signal to. No terminal program supported that switchover but rumor says, there once was an implementation of hardware and software to supply external
clocking with LocalTalk and thus raise throughput. I don't remember the name
of that product, though.

According to my friend, booting over LocalTalk was supported very early on.

Only with Apple II, not with Macs, though.

Yes. Macs.

So it functioned as something like MS-SNA Server and / or Novell's SAA.

Yes.

I thought that was a 1990's or earlier misconception. Is this still
true?

I think there are still some people that believe it.

Unbelievable! Pun intended.

Allow me to redirect you to here:
<https://www.ibm.com/support/knowledgecenter/en/ssw_ibm_i_72/ifs/rzaaxfsknow.htm>

Thank you for the link.
This really sounds like file system support / drivers in the Linux kernel.

A bit like that, yes.

QNTC sounds like SMB / CIFS / SMB2 client.

Yes, but very crudely. I never tried hard enough to learn how to configure a workgroup name, so it might talk to Samba.

I think Integrated xSeries Server (IXS) is the PC board that I was talking about.

Yes, see above.

Question: What is the significance of the "Q" in front of a number of
things? I see it in the file systems and I seem to remember "qsysopr".

This is another mystery to me. I'd really love to ask Frank Soltis about that before he dies (of age, that is). Meanwhile, I've come to the conclusion that everything starting with a 'q' is an object which was supplied by IBM. And 'q' because there are only a few senseful (english) words starting with 'q', so there'd be no accidental ambiguity.

Imagine it had been 'F' and there bychance was an object for a User Class Key...

Let's call it a simplification for educational purposes.

Granted. Thanks!

More and more platforms are gaining better and better support for OSS.

Yes but that's not always good in terms of the platforms intrinsic security.

:wq! PoC

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

[continued from previous message]

different to IPv4 addresses and netmasks.

MAC addresses are exactly the same. Nothing at L2 changes.

Yes, IPX addresses are completely different from IP addresses. But that doesn't matter.

It doesn't matter because the IPX packet is from the local IPX address
to the remote IPX address of the gateway running on the NetWare server
that does the opposite.

So it goes from APIs that think TCP/IP to a Novell Winsock stack using
the local IPX address to a remote IPX address where the corresponding
gateway receives the IPX packet, extracts the TCP or UDP portion and
then sends it out as traditional TCP/IP or UDP/IP.

It's conceptually very similar to IP over SNA via AnyNet.

Since the Network Number in IPX was already 32 Bit, this solution
*could* have prevented the need for IPv6 in the first place! ;-D

Ya. I've wondered what would have happened if IPX had won instead of IP.

Nope. :-)

MacTCP provided an IP stack and proprietary API to Mac
Applications. Open Transport was a complete rework to integrate
AppleTalk and IP under the STREAMS API, also as PPC native code. AFAIR
the only other company using STREAMS was Novell with their Netware.

I may have the names wrong. But I know that the IP support the predated
Open Transport was on top of DDP.

On a side note, The Open Transport IP implementation has problems with
Window Scaling. Uploads to current Linux's will be painfully slow, single-digit KBytes/s range, even over 100M Ethernet. If you disable
window scaling in /proc (or /sys?), it's fast again, but everything
else will be slow. Or if you put a Cisco ASA in between to delete
the WScale-Option while the TCP handshake takes place.

I wonder if there is an IPTables target to (conditionally) disable
window scaling (for specific IPs)

I have a Pentium Overdrive Board (2850) with the accompanying board
with S3 graphics chip and other peripheral support. It was hard to
get hand on a breakout cable to actually see what's going on on the
PC side (VGA, PS/2 Keyboard and Mouse, Serial and Parallel Port).

Nice!

I'm not surprised that the breakout cable was difficult to find.

Those are the types of accessories that get lost in the shuffle, despite
people holding onto the bigger components.

Yes. The Coax/Twinax-Card was special in the way that it couldn't be
used with standard AppleTalk and MacTCP.

I'm not at all surprised.

The serial card could be used as standard serial ports but also for
X.25 and SDLC. I have Mac X.25 server but I didn't take time to have
a closer look at it. I think, it's also a network central gateway to
provide X.25 services to other Macs via AppleTalk.

Nice.

Though, it's my understanding that X.25 was largely used as a long
distance serial interface or to transport other protocols. I'd think
that the gateway machine would gateway more common protocols.

The Token Ring Card could be used with AppleTalk and MacTCP but it is painfully slow. I measured about 200 KBytes/s FTP on a reasonably fast
Mac IIfx with not much difference when put into a PowerMac 7100. A
PowerMac 7500 in the same ring with a PCI NIC sucked 1,5 MB/s per
FTP from the same server.

Yes. The card is called "Apple Coax/Twinax Card"

Thank you for thee confirmation.

DB-15, M or F depends on what's to be connected on the other side. A distinction I don't understand.

Is the M or F on the DB-15 or the Twinax connector?

My understanding is the difference is simply a matter of which gender
connector you're working with. If you have a couple long runs of Twinax
with M connectors, it would connect to the F connectors on the breakout
cable. Conversely, if you wanted to come directly out of said breakout
cable into another machine, you'd need the M connector on that breakout
cable. So it has to do with pick the cable with the gender that you
need so that you don't need adapters.

Maybe you confuse DB-9 with Token Ring?

Well, Token Ring does use a DB-9 (more properly DE-9), as in a 9 pin d-sub-shell, connector. Token Ring has F DB-9 connector (or RJ-45) on
card. Serial uses a M DB-9 connector (or M DB-25).

And now I'm again learning that there was even more highly interesting
stuff. CL/1 server vor MVS/TSO! MacAPPC! It seems that the latter
is part of the API stuff for SNA.ps. And MacDFT, which seems to be
the other Application to talk to the Coax/Twinax-Card.

I'm sort of surprised to learn that Coax / Twinax connected terminals
were Distributed Function Terminal. I thought DFTs were a completely
different class, more akin to ASCII terminals. I could easily have the
wrong understanding.

Nope.

ACK

I'm not sure.

Because the software support maybe was once planned, but never
released.

*facepalm*

A bit similar to the splendid Mac IIfx. The first Mac to incorporate
true DMA for SCSI transfers. Unfortunately, stock MacOS never made
use of that capability. A/UX did, rumor says.

A/UX. That's something I've never messed with.

Yap. Early documentation referred to what we now know as LocalTalk as
"Apple Bus". Maybe someone decided it was too technical and renamed
it AppleTalk to sound more friendly.

Likely.

<This> will allow your Apple computers to talk to each other.

Not only Ethernet. Afterwards, Apple needed to clarify that Ambiguity
and called AppleTalk different depending on which media: EtherTalk, TokenTalk, FDDITalk. Ah, yes, and LocalTalk.

I didn't know about TokenTalk or FDDITalk. I vaguely remember hearing
about EtherTalk.

Did you know that almost every internal HP-Print Server for Ethernet supported AppleTalk, IPX and IP but the Token Ring variants supported
just IPX and IP.

I agree that most of the older ones supported more protocols.

I think that some of them had DLC support too.

And, in case you ever need to configure the IPX part of those Print
Servers, you really don't need JetAdmin. JetAdmin just configures
SNMP over IPX transport. You can set the same parameters via SNMP
over IP, too. I was very surprised and documented my findings: <https://kb.pocnet.net/wiki/JetDirect_IPX-Konfiguration>

I'm not at all surprised by that.

Not true.

First, you can plug a "printer cable" (RS-422 MiniDin 8 with Mac
Pinout) between to Macs and use a terminal program to transfer files
with up to 230.4 kb/s. Given the receiving Mac's CPU is fast enough
to not miss a byte. Buffer? Which buffer?

You said something very key: Mini Din 8 as in the 8 pin cable.

My understanding is that the 8-pin cable was really two 3-pin cables,
plus something, in the same cable. Thus you were using /both/ channels.

Second, there was one pin on that connector you could supply an
external clock signal to. No terminal program supported that switchover
but rumor says, there once was an implementation of hardware and
software to supply external clocking with LocalTalk and thus raise throughput. I don't remember the name of that product, though.

Interesting.

Only with Apple II, not with Macs, though.

I thought it was more than just Apple IIs. But there were a number of
Apple II models. I'll give you that Macs didn't have nearly the same functionality.

Unbelievable! Pun intended.

:-P

Yes, but very crudely. I never tried hard enough to learn how to
configure a workgroup name, so it might talk to Samba.

It's been too long since I've really worked with Samba. I recently had
someone tell me that Samba did not support NetBEUI and that it only
supports NetBIOS over TCP/IP (a.k.a. NBT).

I say this because I wouldn't be surprised if the (early) version of
QNTC was NetBEUI only and didn't support NBT, thus might not be able to
talk to Samba.

This is another mystery to me. I'd really love to ask Frank Soltis
about that before he dies (of age, that is). Meanwhile, I've come to
the conclusion that everything starting with a 'q' is an object which
was supplied by IBM. And 'q' because there are only a few senseful
(english) words starting with 'q', so there'd be no accidental
ambiguity.

Interesting.

Imagine it had been 'F' and there bychance was an object for a User
Class Key...

:-)

Granted. Thanks!

;-)

Yes but that's not always good in terms of the platforms intrinsic
security.

I completely agree.

I feel the need to say "73" and "station secure".



--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

[continued from previous message]

I never heard of DFT before at all, so you're more an expert than me. :-)

Not much to be found online. <https://www.ibm.com/support/knowledgecenter/en/SSDTBM_3.2.0/com.ibm.gddm.v3r2.adms700/adms7a0591.htm>

Because the software support maybe was once planned, but never
released.

*facepalm*

Come on, that also happened with other companies. ;-)

A bit similar to the splendid Mac IIfx. The first Mac to incorporate
true DMA for SCSI transfers. Unfortunately, stock MacOS never made
use of that capability. A/UX did, rumor says.

A/UX. That's something I've never messed with.

I've a Mac IIci with A/UX 2 (feeling like System 6) and a IIfx with A/UX 3 installed, mimicking System 7. Nice is that if an application crashes, I could easily telnet to the host and kill the Mac OS task. No need to do a hard reset anymore. Drawback is that the Mac environment because of constant polling for new events creates a load of 1.

First, you can plug a "printer cable" (RS-422 MiniDin 8 with Mac
Pinout) between to Macs and use a terminal program to transfer files
with up to 230.4 kb/s. Given the receiving Mac's CPU is fast enough
to not miss a byte. Buffer? Which buffer?

You said something very key: Mini Din 8 as in the 8 pin cable.

Yes, for additional handshaking.

My understanding is that the 8-pin cable was really two 3-pin cables,
plus something, in the same cable. Thus you were using /both/ channels.

Nope, it's not that simple. It's simple in other ways, though. See <http://bitsavers.trailing-edge.com/pdf/apple/networking/localtalk/AppleBus_An_Introduction_1985.pdf>
for details.

Yes, but very crudely. I never tried hard enough to learn how to
configure a workgroup name, so it might talk to Samba.

It's been too long since I've really worked with Samba. I recently had someone tell me that Samba did not support NetBEUI and that it only
supports NetBIOS over TCP/IP (a.k.a. NBT).

True. I also tried to find out if earler samba releases supported NBF but apparently, it never did. Just NBT.

I say this because I wouldn't be surprised if the (early) version of
QNTC was NetBEUI only and didn't support NBT, thus might not be able to
talk to Samba.

That's possible. Maybe I need to find out which Ethertype field NBF used.

https://en.wikipedia.org/wiki/NetBIOS_Frames

"NBF protocol uses 802.2 type 1 mode to provide the NetBIOS/NetBEUI name service and datagram service, and 802.2 type 2 mode to provide the NetBIOS/NetBEUI session service (virtual circuit)."

Yet another thing to try out: Add 1 and 2 to the line description, vary off/on and see if I can connect to the NT4 VM.

Yes but that's not always good in terms of the platforms intrinsic
security.

I completely agree.
I feel the need to say "73" and "station secure".

Doesn't ring a bell here.

:wq! PoC

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

[continued from previous message]

over IP, too. I was very surprised and documented my findings:
<https://kb.pocnet.net/wiki/JetDirect_IPX-Konfiguration>

I'm not at all surprised by that.

Not true.

First, you can plug a "printer cable" (RS-422 MiniDin 8 with Mac
Pinout) between to Macs and use a terminal program to transfer files
with up to 230.4 kb/s. Given the receiving Mac's CPU is fast enough
to not miss a byte. Buffer? Which buffer?

You said something very key: Mini Din 8 as in the 8 pin cable.

My understanding is that the 8-pin cable was really two 3-pin cables,
plus something, in the same cable. Thus you were using /both/ channels.

Second, there was one pin on that connector you could supply an
external clock signal to. No terminal program supported that switchover
but rumor says, there once was an implementation of hardware and
software to supply external clocking with LocalTalk and thus raise
throughput. I don't remember the name of that product, though.

Interesting.

Only with Apple II, not with Macs, though.

I thought it was more than just Apple IIs. But there were a number of
Apple II models. I'll give you that Macs didn't have nearly the same functionality.

Unbelievable! Pun intended.

:-P

Yes, but very crudely. I never tried hard enough to learn how to
configure a workgroup name, so it might talk to Samba.

It's been too long since I've really worked with Samba. I recently had someone tell me that Samba did not support NetBEUI and that it only
supports NetBIOS over TCP/IP (a.k.a. NBT).

I say this because I wouldn't be surprised if the (early) version of
QNTC was NetBEUI only and didn't support NBT, thus might not be able to
talk to Samba.

This is another mystery to me. I'd really love to ask Frank Soltis
about that before he dies (of age, that is). Meanwhile, I've come to
the conclusion that everything starting with a 'q' is an object which
was supplied by IBM. And 'q' because there are only a few senseful
(english) words starting with 'q', so there'd be no accidental
ambiguity.

Interesting.

Imagine it had been 'F' and there bychance was an object for a User
Class Key...

:-)

Granted. Thanks!

;-)

Yes but that's not always good in terms of the platforms intrinsic
security.

I completely agree.

I feel the need to say "73" and "station secure".

:wq! PoC

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)