Macro Assemblers - on-line telemetry analysis

An IBM Career - design of 1401, work on floppy disk, ...

Programmer "English" from Dick Weaver March 2008

Robert B Garner wrote: > Dick, > > Thanks for your great feedback (as always). > > Were you an English instructor? > Don't you know that programmers can't write and shouldn't even try!? ;-) > > I'll incorporate your feedback this evening and resend. > > - Robert English instructor? No. It all dates back to a curious event at IBM. Seems there was an IBM employee (I've forgotten who) with a photographic memory who commuted in a car pool and, to occupy his mind while commuting, decided to review an IBM language manual, marking outright errors in red, could be done better in blue, simple edits in green, and so on. When he was finished, the now very colorful manual was put on the shelf in his office. One day his manager noticed the manual, saw what he had done, and asked for permission to send it to the language development group. So the manual arrived at our publications department, who brought it to me saying they could not possibly process about a thousand comments as a "Reader's Comment Form" and what should they do. We had a quick conversation: me "This is the answer!", pubs "But what's the question?", me "Why is our manual so hard to use". We launched a rewrite. The exact details are vague now, but over about a year (there was other work going on) the 300 page language manual was rewritten to about 200 pages. I did the rough markup and a cut and paste (at a time when real scissors and real glue were used) on the floor at home (some text may have been deleted by our cat); a writer did the rest. I became a lot more careful about manual wording (and still made errors) and the writer, in an environment where pages produced was one measure of his productivity, had a productivity of minus 100. My English remains bad, but I'm now a nut about not saying things more than once and always using the identical terminology and phrases (exactly what we were taught NOT to do in high school English). dick w

Invisible Ink has its uses - by Stan Paddock September 2007

All IBM 519's had a device that could print on one end of a card up to nine numbers on one line or the other. What printed was under the control of the wiring of the control panel. One day one of the operators handed me a card and said that the end-printer was printing incorrectly. I could see nothing there and I said “don*t you mean not printing at all.” He repeated his statement and escorted me over to a dark closet then turned on a UV lamp. Then I then could see the error in the glowing number. They were using invisible ink. The ribbon in the machine looked like a strip of oily white cloth. By the time I finished the repair my hands were glowing under the lamp as much as the printing. They had started this system because tires were turning up missing somewhere in the plant. At each stage an inspector should count the number of tires in a batch and write it on the card under the printed numbers. He could see the original number printed on the card and he got to estimating the count instead of actually counting. Because there were certain defects that would cause tires to be rejected the number of tires in each batch would often decrease. The day when the invisible numbers started coming out there was flurry of calls wanting to know how many tires should be in each batch. They were told to “just count them.” They then asked “how will we know how many there should be, and how many were they were to count, and how will we know if we are right?” The reply was “Just count them all and we will tell you if they are correct or not.” Shortly there was noted of occasion a sharp drop in the number of tires in one general area. A lookout room was built in the rafters over that department to watch them. From the high perch they saw a trash truck stopping out or normal sight of the floor level people. They layered the bottom of bed with tires and filled the top with trash. All this with a camera rolling featuring them. A undercover police car followed the truck to a warehouse with many stolen tires in it. The system of invisible numbers worked so well that they continued using it. I remember innocently saying once to another C.E. they used invisible ink to print on their 519. I had to explain the process and reason to him.

1401 and other early machine type coding pads - by Milton Thrasher June 2006

I too had troubles with coding pads so I perfected a way to write code on the back of envelopes and go to a key punch with them and punch away before running through an accounting machine to print them for proof reading. Coding the 1401 in actual machine language with a period for stop, a + for add, a - for subtract, a * for multiply, a b for branch, a / for divide made life easy. I was on the 1401 evaluation team before it was announced to see if one could write a meaningful program in 1.4K. The attached story tells about that. I collected "one card program" that would do meaningful work on the 1041. You could put them in front of a deck of key punched cards for things like gang punching all the cards that followed, reproduce a deck of cards to match the cards that followed, end print data on the cards that followed and all sorts of neat little functions that saved time for people. I was the IBM Eastern Region Manager of Systems Engineering responsible for developing things to make the field SE's more effective. These cards found their way all over the country into 1401 installations and I would find worn out copies when I visited which assured me that they were well used. I also create tape timing reference cards using the IBM 1401 Fortran to calculate the tape speeds based on record size and blocking factor for the many different speed tape units that became available. The following file tells more about those projects. Then, when S/360 came along, I had a lot of good things to work on which set me up for doing the OS/360 program support work at IBM White Plaines, NY headquarters. It if fun reminiscing about those good old days when life was simpler. I am sure you will remember the "Green Card". That was the pocket reference card for the S/360 instruction set and other things that programmers needed to know. It was one of my inventions which was perhaps the most significant thing I did at IBM in my 36.5 years considering the overall effect it had. It was later changed to a buff color but was always referred to as the "Green Card". Here is how it came about. I was working in the Eastern Region as Manager of Systems Engineering Techniques Development. That was an organization set up to reduce the number of systems engineers needed in the field by providing them with tools and techniques to make them more efficient and effective. The DPD Headquarters management of SETD was headed by Alvin Gayle. It was set up under Jerald Haddad with about 15 people in Kingston and probably 8 or 10 people in each of 3 Regions. I was in the Eastern Region with close access to the Time Life Data Center. One of my projects was the development of PAT/360, a reprogramming of a Procedure for Automatic Testing that was available for the 1401/1405/1410 family. It allowed a person in the customers office to put on one magnetic tape a series of programs to be tested along with control cards to generate data tapes. The one tape would be sent to the data center for remote operation. The application program would be compiled and the data tapes generated from the control cards. An attempt to run the application program would be made and output tapes created. When the program failed, an automatic member dump would be written back on the original tape along with the collection from the output tapes if any. The resultant tape would be returned to the customer who could then find the errors and resubmit. The impact of this program was very significant in that it saved the travel time and expense to come to the NY Time/Life Data Center. The downside was that the Systems Engineers would then not be able to have the joys of coming to New York as a reward for their hard work with their customers. To do the PAT/360 project, I hired a former IBM systems programmer, David Goldstein, who had worked for the Poughkeepsie Programming Center Manager but was based at Time Life. He had left IBM because he was not happy with their approach to doing things. He was a very bright and competent programmer that saw a bigger future in doing contract programming. Because the people I had been assigned to work for me in SETD had no similar programming experiences, I got permission from Jerald Haddad's staff to use the money saved by not hiring a person on my staff so that I could hire an outside consultant/programmer. Dave and I planned how to convert the PAT Systems from the PAT/1401 which was the simplest of those available. We took our scheme to the Endicott Programming Center where Earl Wheeler was the director. He assigned some of his people including Charles Schultz, the S.360 Assembler Development manager to work with us. He had a collection of programming aids that were being used to develop the Basic Tape Operating System and Basic Disk Operating System which were preliminary to the Disk Operating System/360. We were surprised how cooperative this group was because they were developing a comparable but much more complex system called AutoTest/360 for DOS users. This system was overdesigned and top-heavy with many more control cards and set up procedures which we perceived would doom it to failure if it ever got produced. There in was a political problem that was destined to work against PAT/360 later. The collection of aids they provided included an early version compiler, disk dumps, tape dumps and a set of diagnostic programs. We were given with very minimal documentation along with a copy of their very early version of the Basic Tape Operating System. Dave Goldstein and I took that to the Time/Life Data Center and were the sensation of the time. We were able to get their first System/360 units to actually do productive work in S/360 mode. Up until then, they were operating strictly in 1401/1410 or 7070 compatibility mode. While we were developing PAT/360, I adopted the role of a customer trying to develop a S/360 DOS program and learned to program in S/360 Assembler Programming Language which was very complex because of the huge instruction set with many options. The SRLs, System Reference Library manuals, were very large and not easy to work with initially. I had a stack of about 24 inches high manuals. From these I copied the Appendices which had most of what was needed to have on hand when coding. It was these Appendices that I used to create the pocket reference card initially. Knowing that it would not be finalized until a lot of people used it and pointed out things they needed, I printed the first five versions on light weight paper that would self-destruct. They were also in larger size fonts than the final would be so that they could be read more easily. Dave and I worked many days and nights at the T/L Data Center to get the first TOS/360 to run. Dave got excellent cooperation from the Endicott Center because he was finding a lot of bugs for them. He was also very helpful to them as he had many good suggestions on how to solve some of their most difficult problems. Soon, the Endicott Programmers realized that they could get a lot of machine time at the T/L Data Center. They sent a small group of their programmers to NY to work along with us. Having close proximity to the developers, Dave and I were able to get PAT/360 running almost as soon as the Endicott Programming Center made their first release of TOS/360. We were well ahead of their first release of BOS/360. But, we were shot down before DOS/360 was supported by PAT/360. The S/360 product administrators at DPD Headquarters thought we were counterproductive. DOS/360 AutoTest was announced that specified functions that included ours. It was to be a fully supported program while ours was in the Type III unsupported library. That was very unfortunate because AutoTest was scarcely used due to its cumbersome control cards and obscure instructions. It introduced more problems than the customers' own programs had! It was like a very complicated Job Control Language. Our PAT/360 only required a minimum of 3 cards to run a series of jobs. It was very stable and did not require much maintenance. The SETD Headquarters group would not allow us to spend any resources on it once it was released! I challenged the DPD Headquarters product administrators to try using Autotest and PAT/360 and decide which they would use if they were the Systems Engineers on a customer account. They refused to try either system. This was a very disappointing encounter with the headquarters bureaucracy which shaded my thinking and approach to handling future encounters. The customers took PAT/360 as a main tool for their program development. Time Magazine was housed in the same building as the T/L Data Center and were our first user. They claimed that even with their close proximity, they were able to get more programs tested and running sooner than they would have otherwise. They gave us a strong testimonial. This gained PAT/360 a lot of new users very quickly. I would watch the users work with their memory dumps and find out what features were needed in addition to what was on the preliminary cards. Then, I would talk to the Poughkeepsie publication manager who would consider adding something more to the SRLs or to clarify what was written. We had a very symbiotic relationship, particularly with David Ulrich who took a big interest in the helping with the pocket reference card development. After about five iterations of the card, I took it to the DPD Headquarters Technical Publications Department to have it form numbered, type set and printed. Alice Gnad, a first level manager, assigned Al Reynolds to work with me to finalize it and select the color. We settled on green as being easier on the eyes for the fine print. The first printing was done in about 10 panels, 5 per side. Not long after we were up to the final 16 panel card which was about as large as could be handled easily. We found that programmers had glass desk top covers and put the two sides of the card under glass. That helped account for the huge volume of cards that were needed very quickly. Each S/360 class was started by handing out the "Green Card" with my phone number on it. This produced a lot of good suggestions. Knowing that no good deed goes unpunished, I expect things to start happening badly. And they did. First, Al Gayle's headquarters group objected because the Green Card was not a sanctioned project on their list. Then, Roger Bury, the head of DPD Publications sent a complaint letter to Y. P. Dawkins, Eastern Region Manager stating that a person in his region was producing "bum publications". He meant that they were not authorized and did not go through his product test cycle like other publications from DPD Hdqtrs had to. This resulted in his number two man, a former Western Region manager coming to visit me to learn about my "bum publication". I showed him the card and the steps I had gone through to produce it. I also showed him the list of esoteric projects that I was being asked to staff and fund from my budget which I had refused. After listening to my story, that manager said, "Keep up what you are doing. You are right on track!" Later, David Kearns who eventually became President of Xerox, checked up on me at times. About this time, OS/360 was being tried out in the T/L Data Center and found to have significant problems. One thing led to another and I was soon offered a job in DPD Headquarters to work on the usability problems for OS/360. Very soon thereafter, Buck Rogers, Western Region Manager and later IBM DPD President, took notice of some of the things I was doing. He came to White Plains with the Bank of America account salesman, Hal Durett, and their list of usability problems. They had documented 19 things that they must have fixed in OS/360 to allow them to process their "messengers" from their outlying branches by 11:00 a.m. everyday without fail. Chuck Ruby, who later became a well known SE Manager, was assigned to follow through with me when dealing with the Poughkeepsie Programming Center to get the fixes they needed done expeditiously. Chuck knew more about OS/360 over all than most of the Poughkeepsie Programming Center architects and managers. That was because he had to make the local innovative fixes to keep their many S/360 Model 65s running with Reader/Sorters for their check processing. They had the Reader/Sorters on one floor and the computers on the floor above. That was because the dust from the chads of the checks would fill the air and cause the filters to clog if on the same floor. The Bank of America problems were somewhat unique and met some resistance by the developers because they were not universal. This caused some friction between the Western Region and DPD Headquarters on the prioritization of fixes. Eventually, Buck Rogers and his team came back to DPD Headquarters in person with Hal Durrett and Chuck Ruby to meet with George Kennard, then President of the Development Division. Jack Rodgers, my Systems Management Director was in the meeting with Glenn Morgan and I representing DPD OS/360 Marketing. Glenn Morgan was responsible for software in the Western Region. Glenn Morgan later came to Headquarters and became my second level manager. I think he appreciated the importance of my work from that beginning encounter. He observed that I had a good handle on what could be done at the working level if given some authority. During the meeting, George Kennard started digging in his heels at the amount of work that the Bank of America problems represented and the time schedule that they had to be fixed. At one point, Jack Rodgers simply got up and said,"George, you can stand there and get red in the face and explode on us but these problems have to be fixed and now!" We are going to make the Bank of America a successful installation so that we can continue to sell S/360s to the large accounts. You have to go and get what ever resources you need but you can not dismiss these problems. Fortunately, George Kennard backed down and agreed to get into it personally. Very soon thereafter, we was given the clout needed to get things moving. Bill Viteck was assigned by Ted Climis as the management link I was to work through. There was a systems planning department with a long list of add-on functions. And, there was my separate list of problem areas. I was eventually given a budget of as much as 5% of the lines of code and 10% of the cost of each module throughout the OS/360 as needed to get the problems fixed. This gave OCIP the authority and c reditability that it needed. Before that happened, George Widding hit upon the idea of putting out match books with the words: OS/360 - Performance, Function and Usability on one side and Human Factors Will Be Fixed on the back side. He came to me with this idea. I immediately took the sample match book to a neighbor, Terry O'Connell of Westfield, NJ who had just become an area manager for the Diamond Match Company,. He took my order for a case of batch books with about twenty to a box. They were delivered in about 2 weeks. When I got them, I took them directly to Poughkeepsie and had the cigarette vending machines stocked with them and told Don Gavis about them. He said, "That's a great idea!" But, before I got back to White Plains that day, I had a call from the Poughkeepsie Plant Facilities Manager. He demanded to know whom I worked for and who paid for those matches. He was convinced that they were very damaging publicity for the Poughkeepsie Programming Center's product. I could not convince him that they would be helpful in getting the programmers to focus on fixing the problems. Very soon, my manger, George Widding was called on the carpet for these matches. He called me at home and told me to confess that he had authorized them. He later told me that the match books were just the last straw. He had been very demanding that Poughkeepsie fix a number of other problem areas beside usability and they were gunning for him. Glenn Morgan had a Western Region bright young man in mind to replace him. That was Ivan Bowman. He was a very detail man and knew a lot about how the Operating System was designed and how it was supposed to evolve. About a month later, Ivan replaced George Widding who took a job as the Systems Engineering Manager for the Western Region. This was very good for OCIP in that he would call in from cities like Boise, UTAH with direct input on how the OS/360 problems were impacting sales. Soon, each region was asked to appoint an OCIP representative to work with me in establishing what problems should be addressed. These were OS/360 level program administrators only. DOS/360 program administrators were never given such an opportunity because the direction was to try to move all customers to OS/360. That was because, even to the very end, Larry Foster and other OS/360 architects claimed that they could produce an OS/360 subset that would satisfy even the small customers. Of course, that never happened because OS/360 like government never shrinks. It grew by leaps and bounds and the new hardware announcements could not keep up to provide the memory or performance required by the huge number lines of code. Once large customers found out about the Bank of America getting special treatment, the user groups - GUIDE and SHARE put OCIP on there meeting agendas and demanded to know more about the program. They each met twice per year with working committees meeting between major meetings. So, four times per year, I made presentations of what was being done to solve their problems. We established a discipline to have them vote on the severity and importance of each problem with an estimate of how many customers of which types would be affected. I quickly gained a reputation as the man to talk to if you wanted to get your problems fixed. I had the problem that IBM was then very conscientious about not preannoucing products. It was the time of the Consent Decree. Our competition could promise the moon but we could only announce things that were eminently deliverable. I had to have all of my presentations scrubbed by the legal and customer relations departments. The Industry Marketing Sector that dealt with consultants was especially sensitive to what I would say as their clients wanted to be in a position to give their clients the best advise as to what to spend their resources on. The Industry Marketing Director for Consultants who took a big interest in OCIP. He was able to bring a lot of IBM management attention and thus resources to OCIP. OCIP continued until Relapse 20 when OS/360 became fairly stable and the need seemed to be much less. The way we wound down the program was typical of IBM. They simply found a new job for the people involved and terminated the program. More on this later. Milton Thrasher mthrasher@verizon.net 941 966-9172 Techniques Development

Please send Assembler Coding Sheet

IBM 101 - "and counting"

Pioneer Business Programming from Gerry Jean

In January, 1956, I was one of 15 or so people selected by my employer, Pepperell Mfg. Co., headquarted in Boston (I was then working at the Lewiston, Maine finishing plant) and sent to NYC for two weeks of indoctrination/training on the Datatron 205. Our instructors were Paul King and Gordon Lovelace. With Electrodata/Burroughs input, Pepperell selected the four least confused attendees, I being one of the four. We started to design and code a basic order/invoicing system, taking all of 1956 and 1957. One of the four selected was already a New Yorker; the other three of us moved our families (Long Island) in the spring/summer of 1957. The 205 was installed in 1958 in the Wurlitzer Bldg. on 42nd Street (at Times Square). Alas, it was uninstalled in 1960 because of (1) inordinate machine downtime, and (2) poor system support systems at the various company branches. I'd like to know if you could direct me in finding any text/photos of the Pepperell installation. I've tried the Pepperell web sites but the company has gone through at least two acquisitions that I'm aware of and I haven't any luck trying that route. > a) do you still have documentation on the Datatron 205? Unfortunately, no. I'm always on the lookout for some whenever I browse through old computer stuff in a dusty old bookstore. > b) what language were you using to code the > order/invoicing system Machine language. (64 = clear & add; 04 = change on non-zero; etc.) I think that Burroughs' first assembly language was STAR, which was initially available on the B220. > c) could you amplify on > (1) inordinate machine downtime, It seemed that the maintenance engineers had more time with the B205 than we users did. In order to run our production programs, Pepperell had an agreement with Atlantic Mutual Co. (marine/hull insurance), also in NYC, to use each other's B205 off-hours to keep our production systems from falling too far behind. The order processing was never able to catch up to the backlog. > (2) poor system support systems at > the various company branches. In 1956-57 I don't believe there was even the position/function known as system analyst ...... certainly not any text books available. Burroughs had assigned a "tech rep" to work with us ..... Ira Rubin (who went on to be a fulltime professional bridge player). Ira was a mathematician by training and he tutored us as though we were all well-versed in that discipline. For example, instead of the flow-charts checking "new order # GEQ previous order#", we were taught to use "n sub-prime 1 GEQ n sub-prime2". The point is that even our system designs were tough to follow & required constant referencing of a legend to decipher n, a, x, tt, etc. Don't forget that we were extreme babes-in-the-woods ...... just like youngsters, we looked to our tech. rep. as our guru and believed that this was the way to do things. The technical people that Pepperell had at various branches still had IBM tab equipment and, naturally, only could think along that technology. Again, the tech staff at the B205 NYC site consisted of, besides the keypunchers, we four programmers. We had no expertise (nor the staff) to properly coordinate systems at the computer site and the branch tab shops. Burroughs didn't/couldn't provide any meaningful assistance in the design area ... in fact, our tech rep support only lasted through the summer of 1956 ... we went it alone after that. We were truly all pioneers! Gerry Jean - Pacifica, CA