You mean a Tokenray network? On Sat, May 22, 2021, 4:34 PM Lyle Bickley via cctalk <cctalk at classiccmp.org> wrote:

On 5/22/2021 7:50 PM, Lyle Bickley via cctalk wrote: I guess that's a selling point of TR, but I loathed it when introduced to it after using Ethernet at UIUC.? Having to learn CPI-C, LU-2, LU-6.2, APPC, etc. and configure Communications Manager/2 on OS/2 to emulate a FEP (3174?, not sure, my mind tended to bury such information, and in fact I'm not sure if that's what it did or if it connected to a FEP, that info is gone and I've no desire to go review it). When the network worked, it was fine, of course, but it seemed every week someone would do something that would switch a TR card in a PC to 4Mb, and the entire network would die, "beaconing" for an hour while the IT folks ran around trying to figure out where the issue lie.? And, it was an office building, so not a ton of noise... Seeing the 370 (3090, as I recall, nice imposing looking machine) was impressive, and I will admit working in a firm with an IBM 370 architecture machine gave me a new and profound appreciation for the staying power of the mainframe (I started the job thinking, as all recently minted IT professionals no doubt think, that the mainframe was soon to be discarded in favor of UNIX and potentially the newly arrived Linux OS. That job changed my mind). But, I never grew fond of TR, and as soon as IBM supported Ethernet, I was happy. (Plus, there was no TR driver in Linux initially, and we all desperately wanted to run Linux on our PCs to run a real OS instead of Win3.1 or OS/2. OS/2 was nice, to be fair, but it was not UNIX...) Jim

On 5/23/2021 12:31 AM, Grant Taylor via cctalk wrote: Oh, I don't know, I mean, CM ES and CM/2 were just OS/2 emulators of a FEP, I believe (they were emulating something, I know that much), and we talk about other emulators on here all the time. It was 1993, I was fresh out of college with a Computer Engineering (kinda like a EE degree, but with small signal instead of power design in the last semesters) degree from UIUC and the job market seemed in the dumps.? Hardware jobs (I interviewed at Motorola to work on the uC group, but no dice) were scarce, and software development openings (CompE had some CS classes in it) were bad as well, but a bit better.? Took a job with Compuware (still in business, I believe... Yep, now part of BMC), one of the IBM barnacle companies, to coin a term (they wrote some industry standard apps like FileAid and AbendAid and XPediter, if my memory doesn't fail me) for IBM shops.? IBM-like dress code (dress slacks, shoes, college shirt, tie), but it paid well.? I was hired in their communications group, working on a multi-platform piece of code called "GCS" (Generalized Communications System).? The overall idea was to create OS/2 counterparts for the company's mainframe flagship products, some of which could also function as front ends for the mainframe versions.? File-Aid, for example, was a file transfer/file manipulation app on the mainframe, and FileAid/2 did the same on OS/2, but also allowed transfers to/from the mainframe.? The transfer functionality required a way to do transfers, as one can expect, and the goal was to support as many customer configurations as possible.? GCS was born.? GCS was a set of libraries that provided some low level transfer routines that could be compiled into mainframe and OS/2 apps (RS6000 as well, and later Windows 3.1 and Windows NT).? The transfer was protocol agnostic, but there was a directory server functionality that would configure which protocols could be used between two endpoints.? Sometimes it was CPI/C, which I think was a half duplex true communications protocol, while others were APPC/LU6.2, as I recall (I didn't do much with the actual protocols, as I was junior on the team), which could be full duplex.? The bare minimum was LU2, which I believe is 3270 protocol.? It's probably old news to anyone on here, but LU2/3270 was a horrible way to transfer files.? Essentially, you would connect to the 370, it would pass control to the endpoint, you would send a screen of data back, it would send data back to you, repeat.? To do a file transfer using LU2, you would use the OS/2 communications low level libraries to create a virtual 3270 screen and connect to the mainframe (using connections strings retrieved from this directory server thing our team had written) and send some EBCDIC chars in the first field, the 370 would then respond to those, etc.? If a file needed to be transferred from mainframe to PC, the PC sent the required set of "commands", and the mainframe split the file into 80x24 chunks of data and sent it down, the client re-assembling and passing off the resulting blob.? Smarter people in the group than I realized the 370 terminal environment would support 3270 terminals that were up to 16384 or so bytes in size, whatever that translated to in rows and columns.? So, all 3270 virtual sessions were created with those dimensions, to save the number of splits and chatter. I configured CM/ES and CM/2 to hook the GCS endpoints to the mainframe and populated the paths in the Directory Server to denote which protocols were used for which paths. I realize now that outside of groups like this, no one understands half duplex transmissions.? GCS simulated full duplex conversations over half duplex pipes, which required an insane amount of work, but we created tons of little threads in OS/2 to manage all of the housekeeping. The idea was that the developer and end user need not care if LU6.2 (full duplex) or LU2 or CPIC (half duplex) was in use.? I'm laughing now thinking of all of the web and even TCP/IP devs who take full duplex for granted and don't even know about half duplex. Anyway, the system seemed (in retrospect) as brittle as it sounds.? I went on a number of beta installs to IBM shops to install and configure, and it was a chore each time.? Navigating not only the TR segments, various RACF security issues, etc., made almost every beta install close to doomed.? The system was heavy, as you needed a directory server installed, the apps themselves, and CM/2 if it was not already in place.? Good times...! I, of course, came from UNIX and TCP/IP land, and 802.2 and all these crazy protocols were just bizarre to me.? I had bought the Comer books right after college because I was trying to implement TCP/IP on my Commodore 64 (got SLIP, TCP, and IP working, back in 1995 or so), and there was a guy at the company named Walter Falby who was a uber 370 programmer.? At one point, he was leading the Compuware group writing a program that would trick the 370 into feeding different dates to regular apps on the machine, to be sold as a utility to help companies test their SW for the year 2000 rollover.? Deep knowledge of 370 assembler.? Reminds me of "Mel" of the free verse story fame.? Anyway, Falby started asking me about TCP/IP, and I was happy to share what I knew.? He borrowed my Comer books and printouts of the RFCs (not sure where I printed them from back in those days, but they were available somewhere) and implemented a full TCP/IP stack for the 370, they called it Host Communications Interface (HCI).? I'm not sure if Compuware gave HCI away to customers or they just charged a bit for it, but I remember Walter being stupified IBM was selling TCP/IP for such a high price and deigned to do something about it. As TCP/IP came into focus on OS/390 and OS/2, GCS added TCP/IP as one of the protocol options.? By that time, I knew my way around GCS and the issues.? I've forgotten the specifics, but I do remember the original OS/2 GCS code was written by a guy named Paul who was still the primary dev, but had relocated back to California. He had implemented a "waitforsignal" construct incorrectly, and the code spun in a tight loop until data arrived.? I don't know why, but the code was not easy to fix to use the correct construct.? OS/2 handled it OK, but it was still a resource hog.? My claim to fame (as it were) in this group was realizing that one could dispense with the huge library overhead (2 threads per connection, etc.) for full duplex protocols like TCP/IP, and I hacked together something called GCS Quick, which only worked with LU6.2 and TCP/IP, but ran much faster than our heavy GCS and was much more portable to Windows 3.1 and UNIX (RS6000).? Obviously brighter minds than I took the idea and created GCSLite, which slimmed down the overhead and optionally pulled it in when needed for LU2 and other half duplex needs. Towards the end of my time there, we were doing Windows 3.1 ports with 3270 emulators.? Seems like Chameleon was a product name, but not sure. Extra! I think was one.? Anyway, we modified GCS Lite to work with those apps, and continued to support OS/2 and the mainframe, and supported the RS6000 as well. I remember Compuware ran everything under VM, which makes sense since there were so many different development teams needing a 370 environment for their work.? I also remember all of the mainframe devs striving to write their code so it ran "above the line".? I seem to recall there was a 16MB "line" (24 bit addresses?) and older code would only run in the first 16MB. And C trigraphs! The bulk of GCS was portable C code and was used on both OS/2 and the mainframe, but evidently the "{" and "}" don't exist on the 3270, so every time we made changes to the portable code, we'd run a File-Aid job on the source tree to convert all the regular C characters to tri-graphs and then upload the resulting munged files for compilation.? Writing this down reminds me this was all unreal.? Rube Goldberg would be proud. The WWW was heating up by 1996 (though archive.org was not around, I actually had one of the first 10,000 web sites back in the day, though I don't think there's any record of it), so I took a new position doing web development.? The new firm had a mainframe as well, but I was mostly hidden from it, and didn't get close to it again until the mid-2000s when I wrote a java utility that took XML DTDS/XSDs and spit out COBOL code and copybooks that represented the XML, so the mainframe folks could consume XML messages.? By that time, Ethernet had taken over, and I never saw TR again. They did segment things, as I recall, but it always seemed to take a long time to find and fix. I remember shuffling SLS disks into the PS/2 (when PS/2 was a model line of IBM machines, not just an old keyboard connector footprint :-) At Aegon/Transamerica in the mid 2000s, I championed the use of the zOS environment to serve up our Java web applications, using some UNIX subsystem for zOS (ah, found it.? Unix System Services-USS, not zLinux).? But, so much Java code depended on ASCII being the codebase, and zOS was just not suited for such types of loads.? We had to abandon the attempts after a year or so, we even had IBM helping us, to no avail.? I suspect zLinux does better, but zOS really prefers batch workloads or CICS stateless type workloads.? Web workloads were just hard for it (at the time, I suspect they've solved the problems now) Working at 4 or so firms that used zOS gave me a nice appreciation for the fact that the world still runs on mainframes. But, if I'm honest, I'm kinda glad I no longer have to worry about EBCDIC, CICS, IMS, finding a 3270 emu, RACF, or hearing people call storage DASD. Dealing with such disparate platforms complicated every systems integration project or architecture discussion I had at those firms.? The last two firms I've been at no longer have big iron (last company converted their zOS app to MicroFocus COBOL on rs6000 and then retired the app, and current firm doesn't have any, that I know of). Jim -- Jim Brain brain at jbrain.com www.jbrain.com

I don't believe that any of the early LAN products emulated what IBMers would call an FEP. Generally, an FEP is a 37XX computer running NCP, EP or PEP. https://en.wikipedia.org/wiki/IBM_37xx Originally these had an interface to the channel and serial interfaces to which a variety of devices could be connected, so simple async terminals, terminal cluster controllers and RJE workstations. There were also "remote" FEPs that connected to a local FEP via a comms line. Later Token Ring and Ethernet interfaces were added. IBM did produce an emulation of the 37xx boxes as https://en.wikipedia.org/wiki/Communications_Controller_for_Linux but this runs on the mainframe. The early tools generally appeared to the Mainframe as a 3174 Terminal Cluster Controller and attached screen. They did not emulate any of the 37xx or 3174 CPUs, they "just" re-implemented the IBM protocols. So you still (usually) needed an FEP on the mainframe although it was also possible to use a Token Ring interface on a channel attached 3174 (3174s could be directly attached to the mainframe) or even attach to the channel using PC channel cards. The tools were not limited to terminal emulation, they would also allow PC applications to connect to the Mainframe using a range of SNA protocols. I would say they are all old enough and obsolete enough to be considered "in scope" on here. Dave

Jim, Dave, Thank you for your very interesting emails. On 5/23/21 3:49 AM, Dave Wade G4UGM via cctalk wrote: I'm glad to know that. That means that some more of my hobbies are in scope to discuss on cctalk. :-) -- Grant. . . . unix || die

On Sat, 22 May 2021 23:00:31 -0600 Grant Taylor via cctalk <cctalk at classiccmp.org> wrote: Here's IBM's "Redbook" on Token Ring: "IBM does not view high-speed Token Ring as a requirement for the majority of its customers, and therefore the decision has been made not to provide 100 Mbps high-speed Token Ring uplinks on its products..." Also: "Note: IBM Statement of Direction, effective October 2001: For z900 server, this feature is called the OSA-2 Token Ring feature, and can only be configured as two 4/16 Mbps Token Ring ports. Note: Effective October 2001: OSA-2 Token Ring feature (feature code 5201) is superseded by the OSA-Express Fast Ethernet feature (feature code 2366), and OSA-Express Token Ring feature (feature code 2367), as required. OSA-2 Token Ring feature (feature code 5201) is not carried forward on G5/G6 server to z900 server upgrades." To download the Redbook: http://www.redbooks.ibm.com/redbooks/pdfs/sg245975.pdf Interestingly, in spite of their statement of direction, for a time, IBM did make a "High-Speed 100/16/4 Token- Ring PCI Management Adapter" (Token Ring PDF attached...). It was NOT popular - and not many were sold. Ethernet had "won" the hearts and minds of IT folks (plus Ethernet by that time was full duplex - at both 100Mbps and 1000Mbps, potentially doubling it's capabilities). Ethernet also could be implemented for a fraction of the price of Token Ring. When IBM began to support Ethernet on mainframes, Token Ring "died" ;) As a networking company we never installed any 100Mbps Token Ring networks - and weren't aware of any implemented by our competitors. Cheers, Lyle -- 73 NM6Y Bickley Consulting West https://bickleywest.com "Black holes are where God is dividing by zero"

On Sat, 22 May 2021 23:00:31 -0600 Grant Taylor via cctalk <cctalk at classiccmp.org> wrote: Here's IBM's "Redbook" on Token Ring: "IBM does not view high-speed Token Ring as a requirement for the majority of its customers, and therefore the decision has been made not to provide 100 Mbps high-speed Token Ring uplinks on its products..." Also: "Note: IBM Statement of Direction, effective October 2001: For z900 server, this feature is called the OSA-2 Token Ring feature, and can only be configured as two 4/16 Mbps Token Ring ports. Note: Effective October 2001: OSA-2 Token Ring feature (feature code 5201) is superseded by the OSA-Express Fast Ethernet feature (feature code 2366), and OSA-Express Token Ring feature (feature code 2367), as required. OSA-2 Token Ring feature (feature code 5201) is not carried forward on G5/G6 server to z900 server upgrades." To download the Redbook: http://www.redbooks.ibm.com/redbooks/pdfs/sg245975.pdf Interestingly, in spite of their statement of direction, for a time, IBM did for a period make a "High-Speed 100/16/4 Token- Ring PCI Management Adapter" It was NOT popular - and not many were sold. (For more detail, see: ftp://ps-2.kev009.com/incoming/timc/PDFS/IBM/Networking/IBM_C_TR.pdf) Ethernet had "won" the hearts and minds of IT folks (plus Ethernet by that time was full duplex - at both 100Mbps and 1000Mbps, potentially doubling it's capabilities). Ethernet also could be implemented for a fraction of the price of Token Ring. When IBM began to support Ethernet on mainframes, that was the "death knell" of Token Ring ;) As a networking company we never installed any 100Mbps Token Ring networks - and weren't aware of any implemented by our competitors. Cheers, Lyle -- 73 NM6Y Bickley Consulting West https://bickleywest.com "Black holes are where God is dividing by zero"