David B. Trout

14611 NE 40th Place
Apartment 601
Bellevue, WA 98007-3336
phone: (425) 883-6717
email: fishsoftdevlabs.com

I first got interested in computers, I think, when I read an article in Popular Mechanics magazine that my Dad subscribed to about a guy who had a computer in his basement with a terminal in the kitchen that his wife could use to store her recipes and help her adjust the amount of ingredients based on how many servings she wanted to prepare. I thought that was really cool, having a computer in your basement.

Then when I read about the Altair 8080 and how you could "program" it to perform calculations, I was hooked.

In high school, we didn't really have a computer. We just had a tabulating machine of some sort that printed the report cards. The only thing close to a computer was a Hewlett Packard Desktop Programmable Calculator. It was about the size of a typewriter. As I recall, it had 10 "registers", 8 "pages" of memory, and each "page" could hold 64 "instructions". There were two types of branch instructions: a conditional jump that would either skip over the next instruction or not (depending on whether the condition was true/false) and an unconditional branch instruction that would branch to the first instruction on any of the 8 pages. Extremely primitive.

Still, believe it or not, I wrote a program for it that could solve complex polynomial equations. Of course, the parameters accepted by the program were pretty limited given the number of instructions/pages I had to work with. It could only accept so many terms and each term could only have so many digits, but still, it was pretty cool to be able to punch in the values and start the program and let it tell you the answer. :)

It also came with an optical card reader attachment that read punch cards (that you had to punch by hand using the provided stylus) and I "punched" all my programs and put them in a binder for my math teacher. He was pretty impressed by it all. When he signed my yearbook he wrote "May all your programs run!" :)

A fellow classmate who was taking advanced classes started taking a freshman college course in Fortran programming and I went out and bought the same textbook he was using ("Fortran IV with Watfour and Watfive" I believe it was) and read it through from cover to cover, doing all the suggested exercises at the end of each chapter even though I didn't even have a computer. I did them anyway because I thought it was fun. My older brother, who was already in college, called me one day because he was taking a course in Fortran programming at the time and didn't know how to accomplish his homework assignment so I helped him with it. :)

When I got to college myself (Carnegie-Mellon University), I of course spent all my free time at the computer center. My programming course wasn't scheduled until the second semester by I managed to convince the dean to give me access to my "account" ahead of time to let me get a head start. I wrote programs (in Fortran of course) that calculated the real and imaginary roots of complex polynomial equations and printed out their calculated curve, labeling the minimum, maximum and inflexion points. I also wrote a simple game program (Mille Bournes) that you could play on a time-sharing teletype connected to a DEC PDP-11. (The PDP-8 they had didn't have multiply/divide instructions and all multiply and divides had to be done in software).

It wasn't long before I had used up all my allocated computer time (CPU seconds) so I began "scrounging" for more time. While reading some PDP-11 manuals I learned the RSTS (Resource Sharing Time Sharing) had a "pseudo-terminal" feature that let your program "type" on a "virtual" keyboard. After "finding" an account to use, I wrote a simple program that used this pseudo-keyboard feature to determine a person's account password via the brute force method of trying to logon to their account time and time again using a different calculated password each time. I was eventually caught and thrown out of the computer center. Shortly thereafter I met my wife and we got married and dropped out of college to start a life on our own.

We moved to Cleveland Ohio (where she was from) and after a few odd jobs here and there working at McDonalds, etc, I eventually landed a job as a computer operator at Associated Credit Services (now defunct) out of Houston Texas. (They had a remote Data Center in Cleveland and that's where I worked). I started on a System/370 model 155 running DOS/VS which was later upgraded to a model 158 running DOS/VSE. After mastering operations I was promoted to System Support Supervisor in charge of all four shifts of computer operators and helped manage the Data Center itself.

Around this time I began taking programming classes at a local community college (Cuyahoga Community College) and learned COBOL and assembler. COBOL was interesting but too verbose for my tastes, but assembler I really liked. I began writing a few simple programs at work that helped out in the day-to-day operation of our Data Center. One such program I believe "enqued" (locked) the file (database) that a given partition was about to update to ensure no other partition would try and update it at the same time, thereby completely eliminating the periodic data corruption we would experience when operators accidentally ran jobs that updated the same database at the same time. I also wrote a tape library management program that helped the tape librarians keep track of their many thousands of tapes (up until then it was all done manually).

Eventually the Director of Software at the company headquarters in Houston found out I knew assembler (no doubt after I found some bugs in their patches (PDZAPs) they sent me) and offered me a position as a programmer. I accepted, promptly moved to Houston Texas and began writing/maintaining the programs responsible for updating the database of a nationwide credit reporting network with tens/hundreds of millions of records in them.

Partial list of some of mainframe "buzzwords" I'm familiar with

DITTO

DYL260/DYL280

PDZAP

MAINT

SSERV

CSERV

RSERV

LNKEDT

JCL

POWER/VSE

JECL

VM/SP

CP

CMS

REXX

XEDIT

FSWRITE/FSREAD

DIAG83

EXCP

WAIT/WAITM

LOAD

COMRG

SYSCOM

PIB

PUB

LUB

PCB

TIK

CCB

CCW

CSW

SIO

TIO

$$A$...

$$BATT

$$BOCRT...

$$ABER...

$$RAST...

$MAINDIR

IPW$...

After several years of programming at ACS writing I/O modules and such (that did EXCP at the channel program level (CCWs, CCBs, etc)), I moved to another company called Universal Computer Systems as one of the original members of their System Software Development department.

At UCS I manually added a lot of "Advanced Functions" features to their non-AF version of DOS/VSE by writing our own versions of 4K paging instead of 2K paging, V=R support, (all of which involved modifying the DAT (Dynamic Address Translation) page/segment tables, real page frames, control registers, etc), Fast Transient Load, Automatic Disk File Allocation/Management, Conditional JCL, FBA ramdisk (wrote that in one weekend), Enhanced Error Recovery, Rotating priorities, and even completely rewrote the system console management code to make it resident inside the supervisor (and do I/O at the device level via SIO/TIO instructions) instead of loading a jillion-and-one $$BOCRTx transients just to display one line on the console, etc.

I worked with $$ABERRZ, etc physical transients, $$Bxxx logical transients, $$RASTnn error recovery transients, modified/extended the partition/system communications regions (COMREG/SYSCOM), the partition control blocks (PCBs), fixed bugs in the system library maintenance SVA module ($$MAINDIR), fixed bugs in BTAM's channel appendage routines, enhanced their online teleprocessing monitor program, worked with the micro department to make some enhancements to their serial controller communications logic to greatly reduce/eliminate NAKs, modified/enhanced the IPL bootstrap phases, wrote disk formatting programs to initialize disks at the SIO instruction level, added Automatic Standalone Dump and Re-IPL logic to the system so if it ever died it would automatically do a Store Status, take a standalone dump, re-ipl and then run DOSVSDMP to print/format the dump for my later analysis, etc. Lots of cool stuff.

I used this last feature to find and correct a particular nasty day-one bug in VSE's original I/O interrupt (SGIOINT?) and channel-scheduling (SGCHANN?) logic that plagued us for quite some time. Whenever the system would get really busy it would sometimes crash because one of its I/Os failed in a strange way. The I/O buffer didn't contain the expected data. I eventually traced it down to a single instruction: a CR that should have been a CLR. What was happening was this:

When an interrupt occurred and it went about examining the CSW bits (CE/DE/UC, etc), it reached a portion of it's logic where it took a different branch depending on whether the register it was working with contained a CHANQ entry number or a CHANQ entry pointer. It grabbed the CHANQ entry number from the PUB that corresponded to one of the 254 channel queue table entries that particular I/O was for and either shifted it a few bits and added it to the address of the channel queue table (to point to the proper CHANQ table entry) or else took a branch to another section of code because the I/O was a head-queue (SVC 15?) request -- a system priority I/O request. Depending on which it was (system i/o completion (head queue) or user i/o completion) was determined by whether the register contained just a CHANQ entry number (a value less than 255) or a CHANQ entry pointer (value greater than 255), and depending on which it was, it either posted the system I/O complete or posted the user's I/O as complete (and dequeued the CHANQ entry as appropriate).

Only problem was, the address of the CHANQ table was a pointer in low core, the high-order byte of which was used as the free-list pointer (i.e. the CHANQ entry number of the next available CHANQ entry to be used for the next I/O request), and when the system got really busy, it reached a point where more than 128 channel queue entries were being used and the free-list pointer (the high order byte of the CHANQ table address) thus ended up with a value X'80' or greater. This caused it to take a wrong turn because now, even though the register contained a CHANQ pointer (and not just a CHANQ entry number), it thought it contained just a CHANQ entry number because the value in the register was less than 255 (because it was now a negative number).

Arithmetically, X'8001C8E0' is less than X'000000FF', not greater, and because it was doing an arithmetic compare (CR) instead of a logical compare (CLR), it ended up posting the wrong task's I/O as being complete! It posted one task's I/O as being complete (when it really hadn't even been started, thus explaining the "garbage" or incorrect data we were seeing in the I/O buffer) and another task's I/O (that was actually complete) never got posted at all and so it ended up waiting forever for an I/O to complete that was already done or else crashing because one if its I/O's it thought was done never actually got started and the data in it's buffer was either garbage or the data left over from a previous I/O! :)

That was a killer bug to find but it was very rewarding to find it. I cried when I found it I was so happy. Changing one little bit in one little byte (changing a CR instruction to a CLR instruction) fixed our problem and the system began working reliably from then on. I got a special Letter of Commendation from the president of the company himself (and a System Programmer of the Year award later on too) for finding that one. :)

I did a lot of other cool stuff at UCS. When the micro department was developing their new tape drive product I wrote a little program on the AS/400 that helped test it (exercise it). I wrote it in CL (Command Language) I think. I also made some changes to VM too (DMKVDR -- Virtual Device Release) to not issue the rewind/unload CCW whenever you detached a tape unit from a user. (This was killing us since our bank of tape drives were being shared by two systems and whenever the operators would re-IPL the VM system, all the tape drives would rewind/unload, completely killing whatever program on the other system happen to being using them. :) I even found a bug in IBM's TCH (Test Channel) instruction microcode for the 9370 "Micro Mainframe" computer (as well as forcing one to rear its head in their BiSync microcode because we were, at the time, still using BTAM, who's channel programs looped to poll the line). Lots of cool stuff.

Just before I left UCS I was made a member of a team of four programmers assigned the task of designing and developing a new operating system for the TI9000 series computer (which was based on the Motorola 68030 microprocessor chip). UCS had acquired (purchased) the entire Data Processing Division of Ford Motor Company (called FDCS - Ford Dealership Communications System) for $100 million or so and wanted to replace the Texas Instruments UNIX operating system that was currently running on all the thousands of boxes throughout all the thousands of Ford dealerships throughout the country with one we could call our own.

I recommended to the president that we write it a portable language like 'C' so when we were done we would have an operating system that would not only run on the TI boxes but one that would also run on all the mainframes we sold too, thus letting us simplify things by only having one operating system to support instead of two (one for the mainframes and one for the micros), but he decided that since we were all assembler programmers like him, we would write it in assembler. (Sigh! As much as I liked assembler I thought that was a big mistake and it turns out I wasn't wrong.)

About 9 months into the project -- after we had already finished designing it and had it over 50% coded and tested (I had already done the Power On Self Test (POST) code and the console code that did I/O out the UART chip to read/write to the console (which let me learn how to use a In Circuit Emulator (I.C.E.) ("SourceGate" I believe was the brand) and burn EPROMS in the process), SCSI File Management code and helped out with the Task Dispatching code) -- the Division of Texas Instruments that manufactured our box (the TI9000 series) was sold to Hewlett Packard who immediately announced they were discontinuing support for the 9000 series. The project came to a screeching halt and via some rather questionable political maneuvering, the Vice President of Software (who at the time was my boss and who I had a falling out with) laid me off "for financial reasons." (He said I was making too much money ($64K/yr at the time) and could no longer afford me).

After having trouble finding a new mainframe position (I spent a short 1-1/2 months at Dynamic Marketing Systems (DMS) training junior assembler programmers and trying to help design a new software system), I went out and bought myself a PC with Windows 3.1 and taught myself Visual C++ (since that seemed to be where all the jobs were at the time).

I eventually got hired to complete a short-term 'C' programming project at a company called BiSys (a banking services company) through a contracting outfit called AJILON. I completed the project in a few weeks and after I was done I was moved to the mainframe department (since that's where most of my experience was and where they needed help the most) to help convert them from VSE/SP to VSE/ESA. I converted/developed a bunch of procedures for them and wrote some VSAM programs and helped maintain their online banking modules in both COBOL and assembler (but mostly assembler).

About this time I also designed and wrote a PowerPC cross-assembler product that ran under Windows and generated PowerPC code, but I never managed to completely finish it and so it never actually made it to market. Still, I learned quite a bit about the PowerPC architecture and Visual C++ writing it, which was good.

Also about this time I got on the Internet for the first time and posted my resume. Shortly thereafter I got a call from a contracting agency (Volt) asking whether or not I wanted to contract for Microsoft in Redmond Washington. Well after spending 15 years in the Texas heat I was eager to move to a climate and geography more akin to what I grew up with (Pennsylvania) so I accepted the offer and moved to Bellevue WA (where I currently reside) and began working in the Product Support Department at Microsoft helping to provide Premier Support for all their premier (big-name-lotsa-money) customers using their Visual C++ product (mostly MFC).

That lasted 1-1/2 years and then in July of '98 my contract was purposely not renewed (due to legal reasons; see class action lawsuit "Vizcano v. Microsoft" (not sure about the spelling on "Vizcano")) and I found myself once again unemployed.

Since then I have looked high and low for a programming position (either mainframe or micro, software or hardware), but for reasons I'm yet unable to fathom, have not found one, and thus remain unemployed to this day. (3-1/2 going on 4 years now -- a new record.)

I haven't been idle during my unemployment however, because while waiting for the right company to find me (I've stopped looking; after 2-1/2+ years of looking and not finding, I decided to let them come to me if they're interested, rather than the other way around) I've kept myself busy by writing programs like my AdCruncher Proxy that filters out banner ads from web pages (or filters out anything you want it to really) and getting involved in an open source programming project called Hercules (of which my contributions seem to be well received much to my delight. A programmer loves getting praise from his own peers).

I'm currently still heavily involved in Hercules development and will probably remain involved in Hercules for quite some time as it seems to be a good "marriage" for me. It's a free, open source, System/370, ESA/390 and z/Architecture Emulator that allows you to turn your PC into an IBM compatible "mainframe" capable of running IBM mainframe System/370, ESA/390 and z/Architecture (64-bit) operating systems, which lets me continue doing PC programming (Visual C++ under Windows and GNU gcc 'C' under Cygwin under Windows (that provide a Linux-like environment)) as well as keep the old mainframe operating systems and architecture alive.

There's a lot to be said about the IBM mainframe world. It's hardware and operating system software is remarkably reliable (unlike some other well-known major PC operating system), typically running for years between IPLs (reboots). Rock solid, it is, and much of it is due to years of work by people like me. People who's years of experience in the operating system arena have given them a firm understanding of operating systems that goes beyond just theory, and which is just as applicable to today's PC operating systems as it was with the mainframes of years past.

In fact, what I find to be quite ironic about my unemployment is the fact that personal computer operating systems are taking the same exact evolutionary path that mainframe operating systems took and we seasoned programmers -- who experienced first hand the evolution of the mainframe operating systems -- are already experienced in all the operating system concepts that appear to be "new" to personal computer operating systems.

Remember when "virtual memory" came to the PC world? Been there. Done that. We had it for years in the mainframe world. Pre-emptive multi-tasking? Been there and done that too. In fact, there's not much of anything that personal computers do today that has not already been done years ago in the mainframe arena. Sure they have fancy graphical user interfaces instead of clunky text based user interfaces, but under the hood -- where it really matters -- it's still the same. The same task and resource management, the same memory management, the same file and I/O management, etc. It's all basically the same since all operating systems still have to perform the same basic functions in order to accomplish what it is they need to accomplish.

And we seasoned programmers -- who have had years and years to get these concepts right -- are still just as valuable today as we were when we were working our way up through the ranks.

Not all of us may be intimately familiar with all the latest and greatest marketing-hyped software buzzword concepts of the month (COM+, .net, C#, XML, etc, etc, etc), but that doesn't mean that we aren't already familiar with all the core concepts upon which they're all based.

Because we are.

And have been.

For years.