Adventures in Truth Engineering – 1964-1966

By: Larry Walker, May 2023; Context: Sperry Knowledge Systems Center.

The Beginning

Married while Larry was still in college, Judy and Larry began thinking about ‘what is next’. While Judy was working to cover their living costs while in college and Larry made a little money on ‘odd jobs’ around campus, they were nearing the end of their ‘college days’. That is when it hit them: “What kind of jobs are there for math majors?”
Turns out, the college counselor was quite optimistic. “Well, for starters, there are jobs for mathematicians. General Mills recruits college grads of many types to enter directly into their ‘leadership program’ where you rotate positions for the first three years to learn the company, and then begin to move up the management chain. There are always jobs for graduates in Sales. And – you could be a Programmer.
The last one got Larry’s attention. He had had ONE programming class – using Fortran – and he loved it. He just could not imagine that there were jobs for doing something that much fun!
He interviewed with one large company to be a mathematician. During the process, they asked him to solve several calculus derivatives. When done, he could not imagine doing ‘that’ for a living. General Mills was interesting – but – there was NO guarantee that a management role was waiting at the end of three years, so he was dubious. Sales was NEVER an option.
So, he proceeded to arrange interviews with both IBM and Control Data – both for positions back in his home state of Minnesota. The location certainly did appeal.
The IBM interview was impressive. When he entered their building in Rochester, there was a sign prominently displayed: “Welcome, Larry Walker”. Wow! The interview itself was with multiple levels of management plus one or two of the programming staff – all impressive. He also met with Human Resources, which gave him a rundown of the full suite of IBM employee benefits — very impressive. On his flight home from IBM, he reviewed the benefits brochure: good salary, lots of room for moving up, life insurance, family health insurance, good time off for vacations, etc. Everything was there for the taking. He proceeded to write a 3-page paper highlighting how IBM covered every aspect of his life from the day he joined – until the day he died. His observation: “Well, if IBM takes care of ALL of those things – what do I do?”
The next week he visited Control Data in Minneapolis. It was cold – twenty-two degrees below zero! Having been raised in International Falls, he could not wait to walk from the hotel to the company building – about 6 blocks. It felt like home!
There was no welcome for him when he walked in – he noticed. Nor was anyone sure who it was he was supposed to meet with. After some shuffling around, they finally got him lined up to meet with people in the Systems Programming Group.
Systems Programming was NOT in the downtown building, so they lined up a car to take him to their Arden Hills facility. The car was old, and the driver insisted on driving with the window down – letting in the below zero cold air. The driver was a young kid, but there was one thing he knew – CDC was going to rule the computing world! His excitement made him oblivious to the cold.
The Systems Programming interview confirmed the driver’s impression – CDC, indeed, would become the computing industry leader. He only met with two CDC people, but they were quick to offer him a position – turns out ‘systems programmers’ were in short supply.
Flying home, Larry reviewed his two leading offers: IBM clearly the computing industry leader, professional, and confident, and CDC, disorganized, but incredibly excited about their future. And the IBM offer was about $100/month more than the CDC offer (20% higher). By the time he landed, the decision was made, CDC was the clear winner!

The First Professional Job – 1964

It turned out that Systems Programming work was done in Assembly language, where there is a one-to-one mapping between commands in the language and the instructions supported by the computer hardware. There was NO resemblance to the little he knew from his Fortran course.
He sat at his desk reading the Assembly language commands: Load A, Load B, Add AB, Jump, — and on and on – there were more than 100 commands . It was worse than the 6-months he spent learning Spanish. He had no clue what any of these commands were intended to do. Finally, he had to do the unforgiveable – he walked down the aisle to his new boss’s office and asked him to explain what any of this meant, and then what would it do. It was embarrassing to have a job and to have NO idea how to do the job!
With good coaching, Larry got the hang of Assembly language. His first assignment was to write a program that would add sequence number to each punched card. Punched cards were often the input used to get a computer program into the computer, and these card decks could get quite large. If they happened to fall and scatter, it was nearly impossible to get them back in order.
Larry’s first program required 500 instructions which meant 500 punched cards.
Once he had the program completed, he took the deck of punched cards and stood in front of a blackboard. Then he picked up each card; determined what instruction it contained; and began to diagram on the board what would happen.
In each case. When he was done with these validation steps, he was ready to run it on the computer – and actually ‘sequence number’ a set of punched cards.
It ran correctly – the first time he got on the computer! He was NEVER this thorough after that first time. This was the only time that any of his programs ran on the first try.
While he was in this learning stage, he observed an interesting visit to his Systems Programming Group. An older gentleman with slightly greying hair arrived and asked to see the head of the department. When Mike came out, the gentleman said, “Here is the description of the Operating System we would like your team to build.” Mike glanced at what appeared to be about a 50-page document and said, “OK” With that the older man turned and left.
Larry later learned that this team had never developed anything as major as an operating system. Mike, the leader, was about 30 years old – everyone else was younger. No one ever explained the contents of the 50-page document. Three lead designers/developers were quickly named. Gary and Jim were both ex-customer engineers whose previous job was to support hardware deliveries to clients. The third person, Bill, was one year out of graduate school. No one in the group had ever built an operating system before.
Larry was assigned to the operating system development team, and his job was to write the device handlers for various equipments that could be attached to the mainframe computer: card reader, card punch, magnetic tapes, discs, and the computer typewriter console. This involved learning how each piece of equipment communicated with the computer, data sizes that could be transmitted to each type, error handling if errors were detected in the transmission of information, etc. etc.
It turned out that to test the drivers he developed, he was sent to California which was the only location that both had one of the new computers and all the devices that could be attached. By then he had just over a year’s experience in programming. Since he was a ‘newbie’, he got computer time to test late at night, often, the only person there. As he began testing his programs, he kept getting error notices. He went over his coding again and again, and finally became convinced that it was NOT his problem – there must be some kind of problem with the hardware.
He stayed all night, so he could ‘report’ this to others in the morning. The whole time he waited, he got more and more nervous – who was he (with one year of experience and knowing no one at this location) to tell the engineers that their hardware had a problem?!
Fortunately, the analysis was correct – it was a hardware error. Larry got a nice ‘atta boy’ for isolating this problem.
Later Larry realized that by developing unique drivers for each of the devices, there was a lot of duplicated code. He set about to fix this and ended up with a Universal Device Driver that could handle any pairing of devices – if they could be physically paired to transmit data to and from. Later in life, he began to wonder if this was a modest example of ‘abstraction’, i.e., build several unique solutions; then find what is common to all of them and build a universal solution that could handle all the previous unique solutions.
Larry became part of a team of three to make the 3200 computer a peripheral device handler for CDC’s must larger, faster 3600 computer. The idea was that the 3600 would then be freed up to support larger, more complex applications while the 3200 handled the interface and processing of all the attached devices. This ‘satellite system’ became known as 3200 SASY.
3200 SASY was sold to Phillips Company in Holland, and CDC wanted to make Phillips a VERY satisfied client. The supposition was that the much larger Phillips Company might become an excellent conduit for CDC computers in Europe. Larry was sent over to install SASY and make sure everything worked well – a 1-month assignment.
It turned out that the Phillips financial officer was very particular about how the company’s accounting was handled – and – was always afraid that these new-fangled computers would lose his valuable ‘numbers’. Larry spent 3 months sending this precious data first to disc (but he couldn’t see them there); then to punch cards (but these were clumsy); then to the computer typewriter console (too slow), and finally to tape (which he had come to trust).
When all this was done, the customer asked if we could connect the headquarters system to a remote computer 100 miles away. CDC wanted to please them, so said yes and committed Larry to send these messages.
Turns out, this involved a communications network connection which was totally different than the direct connection of all the other devices Larry had worked on. Messages sent over the phone lines simply disappeared – never seen by the system on the other end of the line. Working late at night for a month, Larry and an engineer Larry had never met, slowly but surely worked up a complete packet to wrap around each message. This included, Start of Message, End of Message, Checksum (to detect phone line errors) etc. In fact, this was a complete communications transmission protocol – developed by continuous trial and error.
The Phillips finance guy finally approved the trial run for the 3600-3200 SASY system. Larry was watching with his fingers crossed. What he saw was the 5-man operating staff could NOT keep up with the efficiency of the new configuration – the same 5-man team that previously worked at a leisurely pace for their 8-hour shift. Larry just watched, muttering under his breath, “Run you B….s, run.”
Upon returning to Minnesota, Larry became part of a small team looking into how to add communications devices to the 3200 Master configuration. CDC only had access to teletype devices at that time, so the team wrestled with how many teletypes they could support at one time. While not certain of their analysis, they decided they could not support more than 50 teletypes at one time – while giving each user a ‘reasonable’ response to queries.
That winter, phone calls from headhunters began to pour in. The emerging computer industry was desperately short of Systems Programmers. Some calls were humorous: “Were you a music major? We have heard that music majors make good Systems Programmers.” Twenty percent raises were the norm being offered, so Larry was interested – with 3 kids at home and a baby on the way.
Larry and Judy had talked it over and were both excited about the possibility of going to Europe – neither had ever been there. An exciting offer arose – 20% raise + overseas benefits; live in any of Paris, Brussels, or Munich, and support customers already in place in those 3 cities. This was too good to be true! They began to think about getting ready to go.
But – Larry ran across a newspaper article describing the largest commercial computer industry contract – ever! It was to build an airline reservation system for United Airlines (UAL) – by far the largest airline in the world at that time. The contract was for $60 million, 4 multiprocessing mainframe computers, massive amounts of storage capacity, and 5,000 cathode ray tube (CRT) terminals spread across the country. The contract stipulated that response time to queries was 1 second – and – system downtime would be less than 24 hours in a year.
Larry was stunned. Having just completed the CDC study on how to support 50 teletypes – with NO guaranteed response – he could not imagine the system being promised by this contract. He quickly decided that he had to be part of this. He had to work with the team of people who even thought they could do this.
One problem. Chicago was NOT Paris or Brussels or Munich – not even close! The best Larry came up with was to promise Judy air conditioning if they moved to Chicago. Not a fair trade!
Larry applied and was quickly accepted. One reason was that the software to be used as the foundation for the UAL system was Exec 8 – Sperry Univac’s flagship operating system – competitive with IBM’s OS 360. Exec 8 was developed and maintained in Roseville, MN – close to where Larry worked. His first assignment was to become the Exec 8 expert for the UAL project. Three-week notice was given to CDC – who immediately offered to match the 20% raise he would get in Chicago. This angered him. As a married man with fourth child on the way, he was upset that CDC would not have been paying him what he was worth. There was no way he would stay after that.
He did, however, volunteer to do 3 weeks of extensive testing for 3200 Master. This meant going to work at 3:00 a.m., the only available time for testing. He felt he owed at least this much to the company that had employed him and guided him into a successful programming career. And his team there was wonderful.
His testing did uncover several operational problems – well worth the effort. Later in life Larry saw an article from IBM where they compared their operating systems to the competition. 3200 Master was the only one they identified as comparable to their own!

Leave a Reply