IBM

My "defense" contractor "career" ended after the Christmas bombing, which meant that
I lost my beard and long hair to attend Signal Corps Officer Basic Training, near Augusta GA,
after which Hazeltine planned my deployment to Turkey, which was preparing to invade Cyprus,
while also sending contractor support to Greece.  This struck me as a really bad idea,
but a college friend already working for IBM finagled me interviews in Endicott.
Officer basic active duty for training occurred before the Fall of Saigon;
I may, in theory, be a Vietnam veteran..?!

One opening was as a System 370 microcoder; seeing a row of guys pounding away on keypunches,
I visualized pencils being ground to stubs.  Another opening was in Cost Engineering,
about which I knew nothing, but that manager was impressive, and engineering is essentially economic deployment of resources,
so this would be a learning experience.  Naturally, that manager vanished within months of my employment.
Having been hired with notably more experience than typical engineering grads, I started as a senior associate
instead of the usual junior associate.  While this meant that the usual 6 month probation was skipped,
it also resulted in my not being promoted until well after relocating to Charlotte.
A more astute IBMer would have known that a promotion could have been negotiated as part of that relocation.

As a field engineer, I would brag about reading electronics schematic diagrams the way others might read comic books.
That was of no use as an IBM cost engineer, where my assignment was to estimate scrap and rework costs for the mythical FS.
Symbolically, cost engineers were obliged to meticulously account weekly for how their 40 hours were consumed,
and I would always include at least an hour for that accounting, but was directed to charge most of my time against
so-called recon products.  IBM mostly leased mainframes, and obsolete models returned from lease would be
reconned into peripheral controllers.  While IBM's mainframe success was largely based on having sorted
backward compatibility, their mid-range commercial mainframes were cost-competitive mostly because of fast I/O
than raw compute speed.  IBM allocated costs according by so-called waterfall, where a burden was added to labor
by distributing indirect costs (e.g. my salary) across products.

My first love at IBM was APL.
I was not the first cost engineer to embrace it, but quickly converted all my work to use APL.
IBM professional employees in Endicott, at least, were nearly all still submitting programming by coding sheets.
Since my handwriting is mostly illegible even to me, that was doomed,
but in my building only some executive secretaries had access to display terminals.
APL is such a wonderfully terse language (a single line can do more than a page of Cobol, Fortran or Basic)
that my miserable typing skills were scarcely an impediment.  I soon obtained my own APL Selectric typeball
and monopolized a noisy 2741 to the extent that I was relocated from the cost engineering bullpen
to an isolated corner office, overlooking the North and McKinley intersection:


Our rented house was within walking distance of IBM;  typically poor weather
motivated entering at the diagonally opposite (N Adams and Watson) corner of connected buildings.
Coincidentally, this meant that I would regularly pass by the area [re]building my assigned products.
It eventually came out that I was the only cost engineer,
except for a couple of old-timers who actually did time-motion,
who knew where their products were being assembled.

Joe Who
At IBM, I worked only in cost engineering, then product assurance.
Our experience rather differed from typical directs
working in manufacturing, research, development, service, sales or marketing;
we relatively frequent had visitors from headquarters staff.  For example,
product assurance management reported to division, not site managers.
On his second or third visit from headquarters, one cornered me to explain
that some senior executive had lost a son (Vietnam?) and wanted to act as patron to some likely guy.
This totally freaked me, and was my first conscious experience of what I call an inflection point.
Had I been savvy and sanguine, I might have leveraged that into retirement as an IBM VP or so...
Meanwhile, it soon became evident that managers were quickly rotated thru these areas of regular HQ attention.
It would be years before I heard the phrase "designated executive potential", but much sooner began to recognize the type.
Alternating with career drones who more or less focused on work would be these clean cut white types who wear suits well.
My first was Joe Who.   Joe had some last name, but I never caught it during the brief time he was our manager.
At least weekly, some stranger would come by asking for Joe.  Disturbed from some coding meditation, I would react "Joe Who?"
.. and I was not the only one.  Thing was, Joe did not look like any regular Joe, and spent nearly no time in our area.

FS scrap and rework estimation became relatively trivial
after observing that historical ship volumes over time resembled Chi-squared_distribution.
FS hardware was interesting: liquid-encapsulated multi-chip modules.
Development provided EC projections, and costs were wanted only for machines actually on the production line,
implying that machines already shipped would either not get updated or would have costs absorbed e.g. by service..?
Whatever, the only guesswork was imagining how long machines would languish on assembly lines.
After all that was coded, by far the longest part of performing cost estimates was printing out results.
At that time, lots of IBM employees' time was spent coding numbers from candy stripe printouts into other programs...
Obtaining on-line access to their mass storage system from a 5120 bypassed that.

This left me with spare free time.  Folks show up with other APL projects:
*  rewriting their waterfall burden distribution program from SBC Basic
   Slogging thru that source, it became evident that,
   instead of understanding and correcting existing code,
   "maintainers" had been adding replacement routines, leaving dead code behind.
   I forget how many pages of Basic source, but its APL replacement was less than a page.
*  writing stock option software with which IBM would gamble free cash over weekends.
*  writing human resources management code, working with an executive secretary,
   made somewhat interesting because I was not allowed to see the data.
*  writing a generic cost justification proposal generator
   Basically, machine learning random buzzword generation.

VTL
IBM Endicott was big on technical vitality, perhaps motivated by experienced engineers feeling threatened by technology changes.
My senior year at Clarkson was the first with lab projects NOT involving vacuum tubes.
By the 1970s, not only was it over 60% of the computer market,
IBM was also practically a vertical monopoly, making most of its own components,
with very few suppliers sharing any profits.
Covers were a relatively trivial fraction of product costs, but one of the most debated in meetings.
Issues were typically resolved so late that cover vendors could charge a premium for expedited tooling...

Vertical integration enabled top-down design, with IBM components specific to intended products.
IBM specifications were not only classified, but also unnecessarily difficult to digest,
written by folks enamored of the concept that if one cannot dazzle, one can at least baffle.
Meanwhile GE and TI published plentiful and clear documentation for TTL (Transistor-Transistor Logic),
which IBM referred to as VTL (Vendor Technology Logic).  Unlike military contractors, who would
misuse approved components rather than bother getting more appropriate components approved,
younger IBM engineers working on peripheral products that I would be assuring were seduced by VTL.
These products were not considered major profit centers, but were instead "drag"
that enabled IBM marketing to offer business customers completely integrated solutions.

I took one internal IBM course on microcoding.  The basic concepts:
CPU logic is much faster than memory, potentially wasting many processing cycles while waiting for data.
Embedded microcode could implement multiple simple instructions cheaper than equivalent hardware for complex instructions.
The final course challenge was implementing microcode for some sequence of machine instructions in a minimum number of cycles.
I beat their record using a technique eventually called speculative execution.
Still resisting being ground to a nub writing System 370 microcode, I did not pursue it.

The eventual implosion of FS left me without an official assignment.
A product assurance opening in the Glendale development lab was available,
but I was required to first write operating manuals for code being left behind.
This taught a valuable lesson about documenting while coding;
if that documentation becomes too complex, rewrite simpler code.
I also discovered:
* it took about 6 weeks to become productive in new (to me) technology
* after about 6 months, I would be forgetting less useful things at about the same rate as learning more useful refinements.

PA
The product assurance technician for code entry in my department used a 3277,
and I quickly negotiated access to it.
Field engineering experience meant that I became their designated world trade ship test delegate.
The products were dumb terminals for manufacturing ("Plant Communication Devices", page 31/146),
attached by proprietary networking called R-Loop.
The terminals were boring, but I was assigned to test the controller

 and help verify an analog input option for the 3644 Automatic Data Unit.
That analog input option took many months to debug;
so far as I know, the only unit "sold" was for our manufacturing verification test.
R-Loop was the less crude predecessor to Token Ring, a rather larger fiasco.
My "contributions" to R-Loop technology were:
- pointing out that specified cable impedance was meaningless at R-Loop frequencies
- predicted network reliability would be less than that of old-fashion Christmas tree lights,
  with any failure on a loop bringing everything down.
Token Ring inherited both those short-comings, but with added complexities.
The key benefit to me was that these products were transferred to newly-announced IBM Charlotte,
along with banking terminals from IBM Kingston and random printers.

My lasting impression of IBM Endicott was how like the military it felt.

Charlotte
Unlike Endicott, where only the paint has peeled, little in Charlotte seems unchanged.
Rather that wait for their new campus to be constructed, IBM rented space for us,
initially in bank skyscrapers (since renamed), downtown between 1st and 4th, S Church and Brevard.
Space needed for testing soon had product assurance relocated to our own lab over a parking garage,
where the (ex-Endicott) lab manager joked that rotting carpet was the main heat source.
Manufacturing terminal testing had been nearly complete before relocating from Endicott;
I did hack a robot arm for automated testing of a card reader,
but most work involved integrating those terminals with 8100 and a System 370 option,
which earned me some months in Germany, where I somehow mostly programmed on an HP minicomputer.

Meanwhile, development and testing for Kingston's 4700 replacement of 3600 banking terminals was a mess.
Relatively few experienced engineers had transferred from Endicott, but even fewer moved from Kingston.
I was promoted to staff engineer and drafted into a department
with limited technical expertise and negligible testing experience.
Probably only their manager was older than I...
In one meeting, that manager was chastising other department members,
citing me as an example of someone to whom he could forward issues with only "please handle".
I made the mistake of immediately clarifying that, in many cases, I "handled" those issues by ignoring.

While most 4700 terminals used the amazingly lame B-loop inherited from 3600,
one terminal used 3700 coax for dedicated, relatively high speed communication.
My main technical contributions were obtaining a box (from IBM UK) for 3270 testing,
based on Signetics 8X305 microcontroller,
then developing a simple language and compiler for that, which the display developer also used,
since that terminal also used an 8X305.

My main perceived contribution was taking over problem review meetings,
where the development manager had previously stone-walled many issues,
exploiting this department's lack of confidence and competence.
My abrasiveness would not have worked, except that IBM Charlotte's senior managers were,
at that time, still of the old school which encouraged contention and backed me up.
As testing wrapped up, the assurance lab manager came to my office one evening to confirm
whether I considered ready to announce.

Within a year, every other member of that department had been promoted to management.

Bernie, a senior engineer, came into the lab one day and confided that I should remain there,
waiting for some division VIP.  Instead, I freaked and disappeared as soon as Bernie left...

A new lab manager arrived from IBM Raleigh, and quickly transferred a couple of his old cohorts.
For no obvious reason (perhaps because we both were NASCAR fans?), he took a liking to me,
and we all went with his wife (an IBM secretary) in his large RV to nearby NASCAR races,
where I stayed busy repairing various broken RV accessories.

Printers
Unlike computer systems, IBM updated industry-specific terminal infrequently,
Some serial printer missions had also been moved to Charlotte,
and they were more impacted by lack of experienced mechanical engineers;
development and testing of transferred printer programs were struggling.
After all, little college instruction was specific to printing,
while electronics knowledge is generally applicable, and recent grads
could be more familiar with evolving tech than would veterans.
I considered printers uninteresting and had only rarely consulted on electronics issues.

Charlotte management responded by contracting from other printer manufactures
designs which could be adapted to work with IBM's industry-specific LAN attachments.
Having LAN expertise and with printer mechanics were already developed,
I was assigned to work on a series of these boxes.
Since they used IBM-designed LAN adapters, few interesting problems arose,
so mostly dealing boring issues (EMC, fragile covers) and statistical significant failure rates.
One distraction was moving from downtown Charlotte to the then-new campus, where I now recognize nothing,
except the road names.

perspective
My only promotions occurred in Charlotte, but that decade was also most domestically complicated.
Many life events have been suppressed.  Some of these tales may be false memories or out of sequence.
FWIW, a few IBM Charlotte employees were good friends;  the 1980s were not all bad..

LSI Institute
I had not known Bruce well when he contacted me about IBM's program for spending a year in Vermont, getting a master's degree.
Site management seemed more concerned about sending a candidate that would do well, rather than most benefit.
Being single and offered full salary plus expenses, I accepted,
installed an alarm system in my house, giving the receiver and a key to my neighbor
and headed out.  It was, to me, almost a dream vacation.
I took my bicycle, tennis racket, skis, and bought an electric guitar.
My apartment was within walking distance of classes.
We had some flexibility in class scheduling, and I arranged to be done by noon most days.
Although Lake Champlain was still partially frozen when we arrived in May,
I often bicycled there afternoons that summer, stopping some days for a mimosa in town.
Despite whacking tennis balls against a plywood wall most mornings,
I never got good enough that anyone wanted to play with me.
To build ankle strength for ski season, I went to yoga classes.
Most IBMers joined study groups, but I had always studied alone.
After more than a month, I realized that engineering math was using
a newer edition of the same textbook I'd used 15 years prior.
Having purchased an IBM PC/XT and modem, I avoided contending for time on the university's
constrained computer terminal inventory, and dial-in access was never a problem.
In fact, I was able to complete homework for the (x86) microprocessor course using the DOS debugger.
For a statistics course, I build a statistics package for each chapter using IBM's APL for PC.

For one class, we were developing a language and compiler for designing digital logic chips.
When I joined IBM, they were still designing digital logic using schematic capture,
with engineers sitting at massively expensive graphics workstations,
dragging and dropping symbols for e.g. AND and OR gates, then connecting them with lines.
One key difference from software programming is that hardware can synchronously
perform many logical operations in parallel, which traditional programming language compilers do not support.
In fact, when I experimented with System C in 2010, efficient parallelism support was still poor.
The class was tasked to implement a hardware compiler for a parallelized version of Pascal.
While many other students teamed to code a compiler using VS/Pascal,
I made progress more quickly coding in PC/APL,
which also ran quicker, thanks to its optimized handling of arrays.

The dean called me in before graduation to ask about going to IBM Research,
being the only LSI student to receive all A's (including one credit hour for skiing),
but I admitted having promised IBM Charlotte's site manager to return there.

IPDS
Reading online now, some evidently think that Token Ring and IPDS were good things,
rather than symptoms of a profligate bureaucracy.  Whatever, when I returned from Vermont,
Charlotte had inherited a 3812 laser printer from Boulder, which had an optional backpack for IPDS,
which was also perpetrated by Boulder.  Whether the specification was written before implementation remains unclear,
but the documented protocol was highly problematic, specifically for error recovery.
IPDS can be looked at as an overreaction to PostScript.  It jams together mostly unrelated command sets for
text, images, graphics, barcodes and so-called self-defining fields.  Whether that hash makes sense
for printers directly attached to computers is arguable, but was fundamentally doomed for remote printers
with constrained local resources and substantial communication latency.  There is no limit to
page complexity, and IPDS (unlike PostScript) supposes "intelligence" at the host, with the
printer liable to running out of resources for caching printable (or not) "objects" liable to be sent
in no particular order, so that a serial printer may run out of memory caching items that may be
printed near the bottom of a page before receiving first objects to be printed.  While IPDS
allows printers to report such resource conditions (thus requiring complex bidirectional communication),
it did not allow for hosts to acknowledge reporting of such errors.
Consequently, a printer cannot know when/whether commands subsequent to an error are relevant.
After finally getting access to Boulders IPDS host driver code (written in PS/Pascal),
I discovered, buried deep in their code, that for such conditions it sent device reset to channel-attached IPDS printers,
which is neither specified in the IPDS specification, possible nor useful for remote printers.
I asked the 4224 development manager whether we should not first test and debug the specification
before developing, testing and debugging the printer.
He declined, perhaps already aware that he would not be around for the gruesome denouement.

Also FWIW, I was appalled at how much of that Pascal/VS IPDS driver code was about moving data
in and out of System/370 storage segments; code specific to IPDS function seemed incidental.
I did not bother pursuing whether that is/was a Pascal/VS or programmer limitation;
by that time, we were too deeply engaged in the battle of Friday development releases.
Far behind schedule, we were expected to test over weekends,
unless/until show-stopper bugs were encountered.
By no coincidence, we were usually able to report such bugs before 5PM Friday,
leaving developers to work over weekends.

Proprinter
I had nearly nothing to do with the Proprinter, but stumbled over this video:

It is, so far as I know, accurate, but avoids discussion of the disaster that was IBM's automated assembly plant.
Its robots were so unreliable that they were replaced by humans.
The plant was so poorly designed that it could not accommodate evolutionary printer designs.
Lexington had designed robotic assembly stations claimed to be programmable for any product that fit.
Sadly, while Proprinters fit, those robots could not snap and slide together those parts.

My minimal involvement was this:  the proprinter was one of the first IBM Charlotte products to use CMOS chips.
CMOS stands for Complementary Metal Oxide Silicon, where MOS is also called IGFET for Insulated Gate Field Effect Transistor.
That gate is insulated from the rest of the transistor and liable to static build-up,
which would could discharge thru the oxide insulation, destroying the transistor.
This is "solved" in CMOS integrated circuits by using diodes to conduct away voltages more negative than ground or
more positive than the power supply (5 Volts).  Proprinter development engineers' issue was that plugging one of
their prototypes into a PC would provoke random errors unless the Proprinter was kept powered one.
Being unaware of CMOS protection diodes (clearly documented in chip specs), they failed to appreciate that
protection diodes to 5 Volts, which would be reverse-biased when powered on, are active-low signals to PCs when power is 0.
I was friends with one of their young engineers, and advised him about the diodes and workaround (resistors in series with the gates).