IBM PC Network

[Jim Brain]

On 5/23/2021 12:31 AM, Grant Taylor via cctalk wrote:
> On 5/22/21 7:12 PM, Jim Brain 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).
>
> Given the things that I play with, I'd like to know more.  But I 
> suspect that this isn't the forum.

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.

>
> My first post high school computer job was help desk support for my 
> local city government.  There were 500 or more computers and many of 
> them were on Token Ring.  --  The migration to Ethernet was under way. 
> --  The way that the network team dealt with beaconing was 1) multiple 
> independent rings, and 2) disconnecting wings / floors of buildings to 
> quickly isolate things.  It's entirely different to have a total 
> network failure vs a floor / wing that can't use the network.
They did segment things, as I recall, but it always seemed to take a 
long time to find and fix.
>
>
> ~chuckle~  I started my Linux networking on 10Base2 and PPP back in 
> the 2.0 days.  I don't know when Token Ring was added to the Linux 
> kernel. It was removed in the early 5.4, I think.  -- Sadly, I don't 
> think that Linux can be the multi-network router that I want.  I 
> suspect that honor is going to go to NetWare 4.x or maybe 5.x.

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