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
[email protected]
www.jbrain.com
