User:Steamerandy/aboutme

About Me

I Andy Patterson have only my experience and IQ as qualifications and more then enough units in several technology fields for degree's in each. I am a published software developer. One of the main developers of Here & There published by Fifth Generations. I designed the real time task switching kernel and multi threaded comunacation protocall that Hear & There ran on.

In the 80's I worked for "FutureDate". an In Circuit Emulator manufacturer. They were bought by Kontron Electronics. At FutureDate our group wrote compilers and assemblers used with our ICE (In Circuit Imulator) development systems. I worked on code genneration for multiple target processors. We had PASCAL, ADA, and MODULA II compilers and assembler prodects for every ICE supported processor. I became head of the language development group at Kontron.

My qualifications comes from my experience on projects I have personally been involved with.

My older brothers, electronic engineers and technicians, greatly influenced my early interest in electronics and science. Because of that interest I excelled in math and science.

My programmaig background has focused on compilers and operatoring systems. They have been my passion for as long as I have been programming.

AP_Exec

AP_Exec was a TSR prioritized preemptive multitasking operating system kernel. The scheduling algorithm used was based on DEC's TOPS-10 operatoring system. The programing interface was through vectored library method and messages similar to AMIGA DOS. AP_Exec provided multitasking to compatible TSRs. and programs. Most common PC application were compatible. DOS calls, a single threaded resource, were available to all tasks. A device driver, device server model was developed using separate loadable modules for (hardware spicific) device code and generic functional program interfaces server code. This allowed a single device driver hardware specific module to handling all like devices while a device server provides a consistant application interface. Some Device server modules imulated the standard bios calls. Others provided messaging protocols on serial ports. A bios call imulating server replaced the polled i/o with buffered interupt i/o.

Here & There

Here&Thre, originally ROSA (Remote Oncall Support Access), was marketed by Fifth Generation Systems the last year before the company was acquired by Symantec on October 4, 1993. Here&There has a very small footprint remote control and file transfer software package. Competing products were pcAnywhere and Carbon Copy. AP_Exec was used in implementing Here&There. It's real time multitasking and device server driver technology enabled Here&There to provide simultaneous background file transfer along with remote control or generale user activity. It also allows the host side of the remote control to always be present. Host was the computer being ran. The computer roles could be switched on the fly. This feature allowed the support person to demonstrate an activity on their local computer. Switching back they could control the the others computer. Generally both computers input devices (keyboard and mouse) controlled the host. Setting could prevent control from either. And be password protected.

Factory Floor Data Collection=

AP_Exec was used in implementing a factory floor data collection system. A DOS PC was used to poll a network of data collection terminals, An RS422 serial interface was used to implement the terminal network. Terminals were polled by the PC. An APExec serial port device server implemented a polling protocall. TSR tasks talked to the terminals providing various services. AP_Exec was used in the 80186 based terminals allowing them to be used in many application. A minimal implementation of dos/bios allowed terminal application to be written in C.

Getting started

I started in collage as a math physics major in an accelerated math program, taking calculus, FORTRAN and electronics my senior year of high school. I was actually enrolled, a student body member, at both schools. High school during the day and evening courses at collage.

QUICK LINKS

link	topic	comment
Aceing the math SAT	First high school algebra class.	A challenge from my brother.
Math entrance exam	Start collage concurent with senior high school year	Aced the advanced math entrance exam. Completing it in 15 minutes.
My first programming experance	Programming	First programming course
LGP 30	Machine language programming on paper tape. A FORTRAN class and no compiler.	Machine code and FORTRAN
Assembly	H200 Easycoder	Programming in assembly languages
My first operatoring system	Honeywell H200 Job Control System	Increased student job thru put by a magnitud.
First programming job	Hired by the collage data center.	Operatoring system maintaince and enhancements.
TOPS-10 Internals	Becoming a Tops-10 guru.	I go to TOPS-10 Internal's class.
#ACM SegPLAN CWIC meetingss	Learn about CWIC from the authors.	Meet Erwin Book and get CWIC manuals.

Aceing the math SAT

It all started the second week of my sophomore year in high school when I took algebra I. I was interested in electronics as my older brothers were working in electronics. My oldest brother gave me a circuit puzzle. Given voltage across one component, current through another, and resistance another. Using Kirchhoff's laws I derived the soloution. A quadratic equation I didn't know how to solve. Couldn't let my brother best me so I was up all night studying my algebra book to get the soloution. I got hooked on math. Perhaps I am a bit obsessive compulsive when interested in something. I learn everything I can about it. I kept on. Checking math books out of libraries. Buying some I found in stores. My brother gave me his old high school math book (1946). It covered trig and fundamental concept of solving for the slop of a curve. Basic derivative but never describing as such. Within a few weeks I went through trigonometry, calculus, difference and differential equations. Towards the end of my soffmore year we were given a math SAT in algebra class. I got 100% correct. (Off the percentile scale.) That got the attention of Miss Lang, head of the math department. I was put on an accelerated program taking Algebra 2 and geometry my junior year. Trig and Calculus my senior year. In my junior or senior year I ran across and purchased a book on electronic circuit design using Laplace transforms. Although the only mention of Laplace was a fine print paragraph on the back side of the front cover. Anyway I learned to figure transforms and their reverse for circuits and signels. The product of which is the output signal transform. Wow! differential equations turned into algrabra. Cool. I recently ran across a paper on fractional derivatives. A doctoral theses that was the same formula I had worked out while I was in high school.

Math entrance exam

I aced the Collage higher math entrance exam. Finishing a 4 hour exam in 15 minutes. A couple of people gave up and handed in their exam before me. When I handed in my papers the test monitor snidly said "give up". It must have been my expression. He looked at my papers and noted my time. I missed 3 problems. I should have worked them out on scratch paper. Which also had to be turned in. The problems were substitution problems of 3 or 4 levels. i.e. y=g(u), u=h(t), t=k(x). Find y = f(x) =g(h(k(x)))

In junior high they wonted to put me in remedial classes. My mother objected and demanded thay test me. I was given an IQ test. Actually several of them. My lowest was 186. I didn't find that out for over 20 years. My mother waited that long to tell me.

First Programming Class

My first experience of programming was in a FORTRAN class doing machine coding on a an LGP-30 rotating drum memory computer that used a flexowriter for I/O and had a 4k drum memory of 31 bit words. I do mean machine coding. No symbolic addresses. We used numeric track & word address locations. In coding machine code programs, one has to act as an assembler. Making notes on forward jumps so one can go back and fill in the address. It was simplified by the coding form we used. Having an address field and numbered lines making it easy to calculate addresses. But you had to know the address before it could be coded. That made me acutely appreciative of the power of symbolic programming. FORTRAN programs were never compiled or run. They were hand chckked by the instructer. The FORTRAN class got me hooked on computers.

Once hooked. I took every programming class offered by the collage. They were all business data processing classes except the one math department FORTRAN class. Which I had already taken. The business programming classes included lab time on a Honeywell H-200 computer shared with the collages administration data center. The H-200 had replaced a IBM 1401 that same year. The 1401 and H-200 computers did not have operatoring systems. Programs were self loading. The operator selected the boot device and pressed the boot key.

Easycoder

I took the Easycoder assembly language programming course in 1966. On my own I learned the H200 machine architecture and excelled in class.

The first assignment was an 8080 list program. Eighty column card to 80 character print line. A card deck listing. A program that reads a punch card and prints it on the line printer. What I did was kind of a joke. I wrote up the simple program only doing it with buffered overlaping I/O. And knowing how the boot strap worked I added the extra instructions to clear the buffers and mark opcode characters. From the assemble listing I punched up a self booting program fitting on a single card. Submitted the self booting list program with it's source cards to be listed, Took a bit of explaining but got the operator to set the boot devise to the card reader. Shazzam got my listing and turned it in. It took a bit of explaining but my instructor had to accept it worked. Most times it pays to do more then asked. Go that extra step.

I do not know why but it seams I was about the only student to learn how to make a keypunch drum card. It was in concept like tab stops on a typewriter. The common codes delineated numeric, alpha, alpha numeric or skip fields. There were two character codes for each type field. One of which marked the first position of a field. A tab stop if you will. The codes were all listed on the inside cover of the card drum cover. Instructors handed out drum cards the first week of class. I learned were the codes were and just punched a drum card when I needed one. Why do I mention this? Because other students were always trying to give me ones I left in the keypunch machines. Or were asking me to make them one. Only a vary few asked how to make one.

Job Control System

In the EASYCODER classes I wrote an operating system (or batch Job Control System, JCS) for the Honeywell H-200. The JCS streamlined batch processing increasing job throughput by a magnitude and more. The JCS read punched card JCL input. I used a Burroughs JCL idea. The first card column having an illigal character code, (¿) all rows punched. The Honeywell card reader would stop on an illigal character code unless in column binary mode. This allowed jobs to be stacked in the card hopper preventing jobs from reading into the following job, (Taking it as data.) The initial Batch Job Control System was running in the fall of 1966.

Before the JCS an operator had to boot the compiler or assembler. (FORTRAN on magnetic tape. COBOL and EASYCODER booted from separate mounted disk packs.) After a compilation or assembly the operator determined if a submitted job compiled or assembled successfully, Checking the listing print out for errors. If successful loading it's executable with data cards in the card reader. If it didn't terminate. The operator had to manually stop it and reboot the processor. The operator was to note the reason for execution failure, On the job listing.

I later implemented a structured file system and a program loader that simulated tape relative loads on disk. The file system paved the way in putting all development programs on a single disk pack. The Job Control Program was becoming an Operating Systom.

With my OS student jobs were simply placed in the card hopper one after the other. Adding jobs as the hopper emptied. Usually extra end job cards were placed between jobs in case a job failed to terminate. The card reader buffered cards that were cleared on a system boot.

A job started with a JCL language, list or run card. A language card started with the language to be processed, FORTRAN, COBOL, or EASYCODER. Other parameters included class code and assignment. Other options saved the program to a disk file. Most were optional. A ¿DATA JCL card following the program deck executed the last compile or skiped to the ¿EOJ card if the compile had errors. An ¿EOJ jcl card followed the data cards and served to stop the card reader if the program failed to terminate. Extra ¿EOJ cards could be thrown between jobs. On boot up the operatoring system read cards in column binary mode looking for a JCL job card. If the compile failed my OS regained control and simply looked for the next JCL job card. A ¿LIST job card simply listed cards until another JCL card was read. The illigal punch code prevented a job from reading the naxt job as data. With my OS scanning for job cards, student jobs could be stacked in the card hopper. Job cards were usually punched in reverse so their notch was reversed. Making it easy to separate jobs.

It was my idea to write an OS in the EASYCODER class. Convincing the instructor took a bit. Stacking jobs in the card hopper didn't seam possible. The instructors didn't understand the hardware as I did. Only one even knew about reading in column binary mode. This was all possible because in those days the software source code came with mainframe computers.

I first wrote a program that read column binary mode and translated the 12 bit code to six bit characters printing the results. A second program demo read a COBOL job card, punched a COBOL compiler parameter card and printed a short report of the details. The parameter card worked showing the idea to be possable. I got the go-a-head.

Large program systems were written using overlays. Code overlays were loaded as needed. I moded COBOLs parameter card overlay to expect the card image in memory instead of reading it. I got a disk pack to test with. I had to do every thing. Copying the COBOL pack. Moding the test COBOL disk. Making my JCL program boot instead of COBOL's parameter card reader. I got it working for COBOL. Once COBOL was running on student jobs it was obvious of the benifit of my JCL proposal. The first few days there was a lot of idle time as student jobs were flying thru. It was live tested only in one evining lab sesion. The word got out of the short job turn around time and the second day the lab was crowded with students. We learned a few things from the test. We learned the need for extra EOJ cards between jobs. Jobs were being skipped when the previous job failed and the card reader stopped on the illegal punch code with the next jobs job card buffered in the reader. Rebooting cleared the buffer and the job got skiped. Nobody knew the card reader buffered a card ahead. I then got the go ahead for EASYCODER. FORTRAN being on tape was a different problem. I wrote a bootstrap sequence that was clever. The supplied bootstrap sequence required the processor to be in two character address mode on boot. If it were in 3 or 4 character mode it didn'work. Normally instruction retrevel is turminated by a word mark on the following instruction. The exception being the set word mark instruction. The two address instruction terminated after the second address. That is how the bootstrap starts. With set word mark instructions marking the opcodes before they are retrieved. So the address mode makes a big differance. A five character instruction in two address mode or a seven character one in three character address mode. Nine if four character address mode. I cleverally devised a set word mark sequence that worked in any address mode. I put my bootstrap sequence into use. The operator only had to hit the boot button to relode and continue processing jobs. There was no file systems. Disk space allocation was done by the system programmer. Disk space usage was allocated by track and sector kept on paper documents by the system programmer.

First programming job

A computer operator position opened up at the collage. The instructors got me the job with the understanding that I would be performing as a systems programmer maintaining and improving my operatoring system. I continued development on my OS and integrated it with data center applications. With the job came the keys. The computer was shared by the data center midnight to noon and instruction noon to mednite. The computer was open from 10PM when classes ended to 8AM when the data center personal came to work. So basically I had the computer during those off hours. I designed a file system and used it to install the FORTRAN, EASYCODER, and COBOL systems on the same disk pack. Added console commands for running programs from disk. With all languages on one disk pack different language jobs no longer on different disks or tape. Different language jobs could be easily mixed. And instruction went to open computer labs. It also brought harmony between instruction and the data center. No longer did data center programmers have to wait till the next morning to make a test compile or quick test run. They could simply throw it in with student jobs. The operating system had so improved the job processing that we had students from Long Beach State sneaking in and running assignments. The operating system loged jobs. The log file could be printed or analyzed by programs. Instruction used it to analyze class assignments. For example average number of attempts might show a problem with an assignment.

Advanced computer lab

There were other "advanced students" that the instructors recognized. With the instructors encouragement we had an after hours computer lab after 10PM. I worked with these students doing special projects. There were usually only one or two students a year out of around 200.

The operating system was instrumental in getting a DEC-System-10 to replace the Honeywell H200 computer system. It was a print out of the log file of one day. One of the bid requirements was the number of jobs run per day to be grater then what the H200 was currently doing. Really kind of unfair as I designed the JCL (JOB Contral Language) to stream line student job thru put. IBM planed to bid a model 30. Thay didn't submit a bid after seeing the job log. There were three bids. Borrows bid a B5500, Honeywell I think bid an H1250. Digital Equipment bid a KA10 with a full compliment of 256K, 36bit word memory and got the contract.

TOPS-10 Internals

With the purchase of the DEC-System-10 came two seats in a TOPS-10 internals course given at the DIGITAL headquarters in Manard Mass. I was one of the two sent to the class. My boss, the department head was the other. There we studied the time sharing scheduler code. Learned the systems configuration file and building tops-10. Studied various internal structures. Run queues, wait queues, resource queues. event queues and studied the operatoring system code that implemented and used them. Device drivers were gone over in detail. It was a well done class. Having studied other operatoring systems and written the batch job control system I found Tops-10 to be elegantly simple. Except for the terminal code. It had went thru so many additions or changed it was a mess.

ACM SegPLAN CWIC meeting

I had been playing with compilers for a while and regularly attended L.A. ACM SegPLAN meatings. It was at a SegPLAN meeting that I met Erwin Book when he gave a talk on CWIC. I spoke with him about CWIC. He gave me manuals for the SYNTAX and GENERATOR languages. The MOL-360 compiler was also included with the CWIC system. I'm not sure if I got a MOL manual. The SYSTAX language is a descendant of Dewey Val Schorre's META II. Dewey was also part of the CWIC development team. I was introduced to Val when I visited Erwin at SDC to discuss the SLIC compiler compiler I was developing. SLIC included the SYNTAX and GENERATOR languages of CWIC. No MOL at the time. MACRO-10 worked just fine. We talked about my ideas of pseudo code and machine description languages separating target machine code output from the tree crawling generator language providing a target indipendent in sequence optimizer phase. He thought it a good idea and was very encouraging. I talked to Erwin several times and he was always helpful. My implementation of SLIC differed from CWIC mostly in the generation of machine code output. SLIC's objects differed from the common lisp objects used in CWIC. Lists were implemented as dynamic arrays. Few actions on a list changed their size. A layered memory managed algorithm is used. The free common sized blocks kept in lists are very quick to allocate and deallocate.

SLIC

SLIC (System of Languages for Implementing Compilers) is a compiler-compiler or metacompiler consisting of five transformation phases. Each written in a specialized language. SLIC was written while a student and computer operator at Cerritos Collage Norwalk California.

SLIC uses five phases that are for specific transformations and should not be confused with passes. Not all phases are required, depending on application. The first phase, syntax analysis, drives the system. Making it syntax directed.

1. SYNTAX

The syntax phase reads the source program analyzing it, transforming it into abstract syntax trees and cataloging symbols into the dictionary. The trees are passed to generator functions written in the generator language. The SYNTAX parser language is compiled into a scannerless parser. It has both syntax and token rules. It uses both look ahead and backtracking that are programed using operators. A backtrack alternative operation saves the compiler state at the start of its left alternative. There is both backup and backtracking. Backup restoring only the input state when a token or string match fails. Backtracking occures only in sequences. Once an ellement is matched a backtrack occures on a failure of any successive test. In the syntax rule below both backtracking '\' and non backtracking '|' are used.

 rule = id(('==':BKTR syntax_rule
           |'=' :SYN  syntax_rule
           |'..':TOKN token_rule
           |':' :CHCL char_class ) ';' !2
           |'(' unparse ')' "=>" action ';'
            $('(' unparse ')' "=>" action ';')
           | ERRORX(" ==, =, .., : or ( expected") 
         \ ERRORX("Syntax error in rule") ;

If an id is matched the next sub-goal is the rule type operator '==', '=', '..', or':'. The '==' tried first. if '==' is not matched the next non-backtrack alternative '=' is atempted. Then the '..', ':' and '(' If no rule type is matched the non-backtracking alternative ERRORX(" ==, =, .., :, or ( expected") is taken. If any one of the rule type operator strings is matched and an error occurs in the following code a long backtracking failure is caught by the \ ERRORX("Syntax error in rule") alternative.

2. GENERATOR

A generator function is a named set of transformations consisting of a unparse pattern and an action. A simple pattern might be a tree pattern:

 GEN(<node>[<variable>,<variable>]) => <action>

If the <node> is matched the left and right sub-tree branches would be assigned to <variable>s. But in the case of trees it may be desired to process the branches. And that may be done in the pattern:

GEN(<node>[GEN(<variable>),GEN(<variable>)]) => <action>

The above pattern on matching the node calles itself with the left branch returning the result in a local <variable>. The same for the right branch. More complicated patterns can be matched going down branches. Action are written in a procedural list processing LISP 2 like language. Many types of optimizations may be performed in the generator language.

The generator language appends pseudo instructions to a section's code list. Sections are declared global and may have properties, section variables etc. The action of appending pseudo instructions to sections is called planting. The terms plant, planting, or planted come from CWIC. In CWIC machine code was planted into named memory blocks called sections. Sections are used to separate code types .. instructions, variable etc. Sections were written to the output file using a flush statement:

 .FLUSH <section name>;

SLIC uses the same terms. However pseudo code is planted, appended to the code list of a section. Sections are used to separate code types. instructions, data, constants. Or what ever required. The SLIC flush statement causes the pseudo code list to be executed and released.

3. ISO

In Sequence Optimizer's are optionally run when a section is flushed. There like a search and replace of a vary powerful code editor. ISO are not string search and replace but operate on objects. Analyzing symbol attribute etc. (ISOs were not implemented.)

4. PSEUDO

PSEUDO istruction are executable procedures that are called when sections are flushed. One might think of then as powerful assembly macro instruction. They serve a simular purpose producing machine code. They are procedural functions that call MACHOPs to output machine code to the object file. MACHOPs appear to be assembly instructions in the PSEUDO procedure body.

5. MACHOP

Machine code is produced by MACHOP functions. The operand syntax or valid parameters are specified in the MACHOP header. Variables local to the MACHOP are assigned the assembly instruction parameters. The machine instruction is output as a sequence of bit fields. Optionally assembly may be output to the compiler program listing. The MACHOP specifies the formating of the instruction fields. A field starts with a radix character:

B(binary)

O(octal)

D(decmal)

H(hexadecimal)

or

blank(cancatanated with previous field)

H(5):  <expression>
 (3):  <expression>

specifies a 5 bit field and a 3 bit field that if printed is to be a combined 8 bit value printed in HEX. The radix has no effect other then print formating. If any field is not defined at the time of printing the field is filed with *s. The MACHOP language allows both conditional expressions and statements in generating machine instruction.

The most unique feature is that code is generated into bit addressable memory space. If addressable units on the target machine is an 8 bit byte then bit addresses must be divided by 8. This allowed code generation of TI990 mini computer code which uses word aligned instruction addresses of 15 bits and 16 bit byte data addresses.

Digital Equipment Corporation

After getting the DEC-System-10 I worked on a conversion program supplied by DEC. It converted H200 COBOL to DEC-10 COBOL I fine tuned it as we were converting our school programs. We had a random access file system we used in our COBOL programes that we had got from Newport mass school district data center. I had incorporated parts of it into my H200 operatoring system to free up memory. I comonelized disk routines so my program loader and the file system shared disk functions with the COBOL random access library. I got the job of converting it to MACRO-10 code. I had many hats. Maintaining the DEC software. handling system updates etc. I served as system administrator seting up user timesharing accounts. I was doing all the software maintenance, systems programming and system administration duties as a minimum wage computer operator. So when I got a job offer to work as a DEC software specialist for 3 times the pay. I couldn't say no. I think my boss at the collage had something to do with it. He had tried to get the collage to create a systems programmer position to no avail. He was really trying to get me paid for the job I actually was performing. He knew I was going for the job interview and gave me advice. The job paid more then my brother was making as an electronics engineer. I got the job and we moved to Phoenix Arizona. It was DEC that recommended me for the job in Phoenix. I had a long and prospers association with Digital Equipment Corporate.

Ramada Inns reservation system

My first real job was a TOPS-10 Systems Specialists working for Ramada Inns. They had hired a management/design team that had designed TWA's reservation system. They had come up with a plan using dial up messaging. Front office terminal's (TI-990 mini computers) served as reservation terminals among other things. A phone reservation center was also setup in Omaha. WATS lines were cheap in Omaha because all major phone trunk lines ran thru there. SAC was headquartered there. Part of our national defence program. We had lease lines between Phoenix and Omaha.

When I started we were working out of motel rooms next to Ramada Inns Corporate while the 3 story computer facality was being built. Which was really great. It had a pool. Nice in the 110 degree summer days. The computer was housed in trallers. It wasn't a Ramada. I had several duties as a TOPS-10 software specialist. I consulted with other programmars making operating system changes. The main one being a RAID file system holding reservation data. It was all software using two removable disk packs. I also worked on the PDP-11 comunations processor that comunacated with Omaha. The computer it talked to was a Currier Data Systems terminal controler for the dial up reservation terminals. WATS line both voice and data came thru the Omaha center. I worked with the Currier Data Systems programmer implementing automatic unattended restart protocol changes in the DEC PDP-11 protocol code. It was interesting work that I later used implementing on the fly interrupt level protocol analysis that was used in serial port protocol servers of APEXEC. Separate device driver and server module was something I came up with in the design of the APEXEC operating system.

I also did system administrator duties. Setting up users and projects. Users were assigned a project programmer number. A login id code. proj,prog number. File access was controlled by the user project,programmer codes. We had two groups of programmers. Business application programmers and reservation project programmers that were organized differently. I changed the project protection scheme. We also used a prerelease version of TOPS-10 having real time job queues. Reservation message response was very important. My software specialist duties, work with other programmers. consulting on TOPS-10.

I do not remember how it happened but they knew about SLIC the compiler compiler I had wrote while at Cerritos College. They wonted to program front office applications in COBOL. I was stuck with the duties I was already performing. But it would be a great test of SLIC. The managers didn't believe a COBOL compiler could be implemented using a compiler compiler. But we're open to take a look at SLIC. At that point it had only compiled itself and test programs. I only had DEC-10 code generation working. The Consultant they brought in checked it out and gave it the go ahead. So now added to my work load was working with the consultant writing a COBOL cross compiler. And coding the TI-990 instructions for the project. That took a bit of my time for the first couple of weeks. The consultant was a very capable programmer and picked up the SLIC languages quickly. Within three months we had a working COBOL compiler. I still was spending a lot of time on the comunacation code changes. I met Steve Russel while working on the comunacation protocol code. He had written the original code. He held DEC badge no. 4. My future boss at DEC was working on site. Working on DEC-System-10s was a totally different world. DECUS was the DEC user group. Software bugs were reported in DECUS. But unlike any other computer manufacturer DEC was alone in that almost every software bug report included the fix by the same person reporting the bug. With the DEC-10 systems came the source for every piece of software. Including the TOPS-10 operating system.

The COBOL compiler was a success. The only bug I know of was one the DEC-10 COBOL compiler also had. We had followed the DEC-10 SYNTAX. It had deviated from the standard in its file descriptions. COBOL had a file contains clause:

FILE CONTAINS <number> RECORDS.

DEC's extension allowed RECORD or RECORDS.

FILE CONTAINS <number> (RECORDS | RECORD).

Presumably for the case:

FILE CONTAINS 1 RECORD.

But RECORDS was optional one could just write:

FILE CONTAINS <number> (RECORDS | RECORD | .EMPTY).

That resulted in an ambiguous situation. A RECORD CONTAINS clause following the file contains clause that ended with the the <number> caused a problem RECORD of the RECORD CONTAINS clause wold be taken as part of the file contains clause and the remaining record contains clause was flaged an error. It was a simple quick fix. Where we had: ("RECORDS"|"RECORD"|.EMPTY) we changed to peek ahead:("RECORDS"|(-("RECORD" "CONTAINS")"RECORD"\.EMPTY) The kicker though is the DEC COBOL compiler had the identical problem. And the application programs were supposed to test with the DEC compiler. The main reason for copying DECs COBOL syntax.

This was a huge project with over 40 programmers working on it. Besides my self there were four programmers working on system software. One deadacated to TI-990 mini computer system code. It had to dial the reservation center send reservations and receive conformation and arrival messages. Load and run Hotel front office applications. Two worked on TOPS-10 OS or RAID changes and the consultant writing the COBOL compiler. Then there were the 40 application COBOL programmers writing front office applications. It all had to be completed a one year. It got done. But an interesting event occurred. Maybe the first denial of survive attack. Well not actually an attact. An over site. The front office TI-990s were all programed to call in at mednite (Phoenix or Omaha?) to check for undelivered messages. Well of course the worst happens. The computer in Omaha went down. At the time we had around 1000 inns on the system. They were programed to hang up, wait 15 seconds, and try again. 1000 computers across the country calling the same number in Omaha every 15 seconds. That did not make SAC happy. When I came into work the building was serrounded by military and black SUVs. They were not happy at all. We changed the midnite call in algorithm using a random call back period. The calling were also staggered with inns calling in at different initial times. Anyway the problem got fixed.

Software Specialist for DIGITAL

After Ramada Inns I was hired by DIGITAL as an on site software specialist at Fort Hunter Liggett. I didn't really do much programming. I wrote a time sink device driver that synced the computer time with a standard time received from a standard clock somewere. I just had to read the time from a connected device. It also checked that it was in sync on a set interval.

The DEC-10 was used to track player position location and gather event data during military experiments. Players carried transceivers that communicated with stationary tracking stations. The tracking stations forwarded the messages to a bank of PDP-11 mini computers taking tower position and message timestamps calculate player position/lication information. The PDP-11 fit curves to the tracking data. Given the time location, direction, and velocity could be calculated very accurately. The messages contained event data. Tiger pull, targeted. Anything they needed. The engineering group built devices that conected to player transceivers signiling events. The job required a security clearance. Most details of the experiments were classified secret to some degree.

The AdVantage®

The AdVantage® was a graphical advertisement layout system developed by Compugraphic Corporation. The AdVantage was a PDP-11 based graphical, primarily advertisement, layout system. My first task was to convert a line break hypanation algorithm written in proprietary 8 bit macro computer assembly code to PDP-11 assembly. That was my first day at work. I had time off to take care of personal chores. Getting a residence, car registration etc. So this first few days were half days. But I had the conversion finished by the third day on the job. Thay didn't believe it until they saw it working. They had estimated it a 3 month project. The thing is I did not figure out how it worked. I simply translated one assembly function in the 8 bit assembly to PDP-11 assembly. I recognized that a few pointers were commonly used and kept those in registers. The 8 bit macro was a single accumulator machine with one index or pointer register. I didn't explain how I did it so fast. The didn't ask. The subject never came up until a bug turned up and I was asked to find the bug. I had to explain that had I little idea of how it worked that I simply translated the code. They tred the original and found the original code to have the same problem. The problem was in the rule table and fixed by the original author. Fixing my version as well. The rule tables were not part of the code. I wrote the font manager code. Which almost got me in trouble. During a dumo for the upper management a giant cactus symbol displayed full screen. (The finger) I was getting funny looks all day. The glitch was a combination of an engineers test character ROM and a hardware memory failure. The 0HFF(256 decmal) finger character was programed in the test ROM. So that explained I was off the hook. I wrote quite a few of the subsystems including designing a text message compression, decompression algorithm. Got around a 15 to 1 compression. It turned out a fun place to work. But Massachusetts was just to clickish for my kids. So I found work back in the west.

Storage Technology

I moved to Colorado again a DEC-10 software specialist at Storage Technology Corporation. I modded the print spooler for microfiche output. It was a strange place. They were using IBM 360s for timesharing and running batch jobs on the DEC-System-10. My boss quit not to long after I was hired. The engineering department went around the data center purchasing a DEC-VAX. That was about the time they filed Chapter 11 bankruptcy protection. When my boss, who hired me, left he suggested I shoud be looking for employment elsewhere before they went completely under.

Back to compilers

I found a job working for a micro-computer startup in California. It was ran and managed by a partnership. I was hired to do language development. However the other partner was the language developer. I worked on a few applications while looking for a job more interesting. I found a job with another start up, FUTURE DATA, manufacturer of In Citcuit Development systems.

FutureData

FutureData had just been purchased by GenRad (General Radio Corporation) when I joined the language development group writing a PASCAL compiler. The compiler ran on a desktop 8086 micro computer. I worked on the code generation side. The parser was written when I started. I was hired to first implement a register manager for the 8086 processor. The overlapping registers and their specialization presented some interesting challanges. The compiler was written in PASCAL. I was soon involved in all code generation. One major change was buffered input output. FutureData had written their own operating system. It was basicly a CPM clone. One feature was separate io initiation and wait completion calls. Which I quickly used to do buffered overlapping input and output.

FUTURE DATA was purchased by General Radio "GenRad" and later again by KONTRON Elentronics. Were I became head of language development. We developed PASCAL, Modula-2, ADA and assemblers for target processors. Motorola 6800, Motorola 68000, Zilog Z8000, and Intel 8086. There were others that never became popular.

TrueData

TrueData was a small company manufacturing marksens readers primarily used by schools for test scoring. I started consulting with them when Kontron moved to Hayward Calif from Irvine. I was hired by Jim McKey, the founder and CEO, when a consulting team of a programmer and electronics engineer were not able to perform in time to make a completion date. The project was a factory floor data collection terminal using mark sense travlers. When I started we had two weeks left. The previous team had been working on it for 3 or 4 months. A second team was working on PC DOS software for the project. With so little time and no terminal hardware I and Jim kludged the existing 6502 marksense board. Adding io ports for a keypad and two line lcd display. And I do mean a KLUDGE gluing chips pin up onto existing ICs and soldering jumper wires to them. I wrote some demo code and we made the show. Lucky I had 6502 experance. My first experance was mared by using a general processor book describing the instruction address byte order backwords. That cost me two weeks in writing a simple scrolling text window for an Apple 2E application. I worked at TrueData for a number of years. Working with the PC team developing the polling protocol for the data colection terminal. It was a common network type in the 70s. We implemented it using an RS422 twised pair lines. Breck my pardner in developing APEXEC was part of the PC software team. Their PC polling was using serial port bios calls. It was terribly slow and took a dedicated PC. I added polling to my 6502 code. My serial port code was interrupt driven using message queues. Its foreground terminal function were unaffected. We allowed 64 terminal's on a line. Small systems of 4 or 5 were the norm. I basically had a multitasking scheduler in my terminal code. The keyboard was a cross point contact sense done in software. It was on a timer interupt. I implemented this one nite to show what could be done if you don't waste time in a loop waiting for the serial port. Working with Breck the programmer on the PC team we wrote an interrupt driven terminal poller. That lead to the partnership that created APEXEC.

APEXEC

APEXEC is a PC-DOS TSR (Terminate and Stay Resident) program. APEXEC provides a form of DLL (dynamic link library). These were implement using a vectored enter table. APEXEC function were called thru a call vector table except for opening APEXEC itself that used an int instruction. Vector tables are filled with address's of functions in a DLL modual. Initially the vector table residing in the calling program contains an index into the libraries entry table. On an APEXEC open library call the calling program's library entry table is filed with pointers to library functions. Resident TSRs could register as a library supplying it function table. APEXEC provided many services to other TSRs as well as compatable transiate programs. It provide task forking allowing resident TSR tasks. Most dos features were available to TSRs. Named (or unnamed private) event and resource queues could be created. Resource queues allowed only a single task to run. Successive tasks were blocked until the owning task released the resource giving control to the first task waiting. Event queues block all tasks until the event is posted. Events can be posted by other tasks or sched level interrupt code. APEXEC device drives processing interrupts can schedule sched level functions to be run just before returning to user level. sched-level runs at the lowest interupt level. It allows tasks to be made runable by interrupt level events and may cause a task switch befor returning to a task from an interupt. A device driver contained minimal code to handle interupts, starting or stopping the device. A device server provided the programming interface. For example a terminal polling server handled polling the data colection terminals. The programming interface allowed programs to send and receive terminal messages, Another server took over the bios serial port calls. Another implemented the Hear & There messaging protocol. We later had two serial port device drivers for 8530 and 8259 serial port devices. The device servers could be used with either device driver. Kind of sounds like how USB works dosen't it. APEXEC was used in the second generation data colection terminals that had 80186 processors and 8530 serial ports. Run queues were linked in priority order highest to lowest. A preempted task was put on the front of it's run queue. A task using it's alloted time is transfered to a run queue specified by the run queue's to queue parameter which could be the same queue or a lower priority one. A task coming out of a resource or event wait state is put in it's primary run queue. It is simular to the TOPS-10 operating dystem. I joined DST Distributed Systems Technology in the early 90s when Here & There was sold to fifth generation systems. Note the Distributed Systems Technology I joined was not associated with the curent DST company.

Junk

My background is accodemic credentials limited as I was offered a job with Ramada Inn's as an on site DEC-10 Software Specialist in 1972. Left the collage life and have never went back. I do have a major amount of collage credits in Math, Physics, Electronic Circuit Theory, and Computer Technology.