Stories
about People and Machines

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.

How the IBM S/360 Green Card Came About - by Milton Thrasher June 2006, June 2011

I find that many remember the "Green Card" from the 1960s. It is the pocket reference card for the S/360 instruction set and the many other things that programmers needed to know. It was perhaps the most significant thing I did at IBM in my 35.5 years considering its overall effect It was the most heavily used publication in the 60?s and 70?s. It was later changed to a buff color but continued to be referred to as the "Green Card". In 1964, I was the Manager of Systems Engineering Techniques Development in the Eastern Region in NYC. The goal was to reduce the number of systems engineers needed by providing tools and techniques to make them more efficient and effective. The newly formed DPD HG SETD Department was headed by Alvin Gayle. He was under Jerry Haddad with 6 to 8 people in White Plains, about 15 people in Kingston and probably 8 or 10 people in each of 3 Regions. They had a long list of proposed products. I did not see many of them as very helpful in reducing the need for Systems Engineers. Most called for programs to be ordered from PID ? the IBM Program Information Department. My theory was that if it was not in the pocket/purse or attach case of the System Engineer, it probably was not going to be very helpful to many. I was in the Eastern Region with access to the IBM Time Life Data Center. I proposed and got funding for the development of PAT/360, the S/360 reprogramming of a Procedure for Automatic Testing that was available for the 1401/1405/1410 family. It allowed customers to put a series of S/360 Assembler Language Programs on magnetic tape to be tested remotely. A tape could be sent to the data center for hands-off remote operation. The application programs would be compiled and data tapes generated from the control cards. An attempt to execute the application programs would be made after test data tapes were generated from control cards. When the program failed, an automatic memory 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 importance was that System Engineers could stay with their customers and not spend the time to travel to NYC or other data centers to test programs which is very time consuming if done manually. The Automatic remote testing could be done by mail or by messenger overnight! The savings in travel costs were significant for IBM and its customers. Because the people I had been assigned to work in SETD had no similar programming experiences, I got permission from Jerald Haddad's staff to use some money saved by not hiring for my staff so that I could hire an outside consultant/programmer. To do the PAT/360 project, I hired David Goldstein, a former IBM systems programmer who had worked for the Poughkeepsie Programming Center Manager but based at Time Life. He was a very bright and competent programmer who saw a bigger future in contract programming. Dave and I planned how to convert the PAT/360 System from the PAT/1401 which was the simplest of those available. We took our scheme to the Endicott Programming Center when Earl Wheeler was the Director. He assigned some of his people including Charles Schultz, the S/360 Assembler Development manager to work along with us. Schultz provided a collection of programming aids used to develop the S/360 Basic Tape and Basic Disk Operating Systems which were steps for building Disk Operating System/360. We were surprised how cooperative this group was because they had a planned comparable but more complex system called AutoTest/360 for DOS/360 users. That system was top-heavy with many more control cards and set up procedures. We perceived that it was doomed to failure if it ever got delivered. That created a political problem that was destined to work against PAT/360 later. Our new found collection of aids included an early version standalone compiler, disk dumps, tape dumps and a set of diagnostic programs. They came with minimal documentation along with a very early version of the Basic Tape Operating System. Dave Goldstein and I took them to the Time/Life Data Center and we became a small sensation of the time. We got their first System/360 to actually do productive work in S/360 mode! Until then, they operated strictly in 1401/1410 or 7070 compatibility mode. I adopted the role of a customer developing and testing S/360 DOS programs. I had done some sample assembly language programs for the IBM/1401. I had to relearn how to program in S/360 Assembler Programming Language due to the very complex instruction set with many options. Some programs had to be written in a lower level machine language for performance. So the ?bits and the bytes? were very important. The SRLs, System Reference Library manuals, were very large and not easy to work with. I had a stack of manuals about 24 inches high. We needed a handy reference card so I built it from these appendices and added some tables I created to manipulate EBCDIC. I knew that the card could not be finalized until a lot of people proofed it by using used it heavily and pointed out more things needed. I printed five versions with ever increasing content on light weight paper that would self-destruct. That way they would eventually disappear. They were printed in larger size fonts than the final card so that they could be read more easily during development. Dave and I worked many days and nights at the T/L Data Center to get the first TOS/360 to assemble the converted IBM 1401 BAL to S/360 Assembler routines. Dave got excellent cooperation from the Endicott Center because he found and fixed a lot of bugs for them. He also 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 programmers to NYC to work along with us. Having close proximity to the developers, Dave and I were able to get PAT/360 running 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, almost as soon as we finished the first PAT/360 Type I program release, we were shot down by the DPD HQ Software Product Marketing Administrators. They thought their job was to only support Type I Programs developed by the Product Divisions. They had a dim view of Type III Programs that were available from PID but unsupported. I was never able to get resources to maintain PAT/360 even though it was up and running and saving people tremendous time in developing Assembly Language Programs. That was because they thought that DOS/360 AutoTest which was only planned, not announced, had 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 when it was finally released a year later, AutoTest was scarcely used due to its cumbersome control cards and obscure instructions. It introduced more problems than the customers' own programs! It was like a very complicated Job Control Language. Our PAT/360 required a minimum of 3 control cards for each program. It was very stable and did not require much maintenance. The SETD Headquarters group would not allow us to spend any resources or publicize it in their brochures once it was released! I challenged the DPD Headquarters product administrators to try using AutoTest documents and PAT/360 for tests of actual programs. That was for them to 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. A number of S/360 early customers took PAT/360 as their main tool for program development. Time Magazine, housed in the same building as the Time/Life Data Center, was one of our first users. 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 that were testing at the Time Life Data Center. Word of mouth and recommendations by the Time Life Data Center Reps was very positive. That was important to me later in my career. Several of the Data Center Reps went on to be my higher level management! They remembered what a strong technical program I had created. I watched the customer programmers work with their memory dumps to find out what features they needed in addition to what was on the preliminary reference cards. Then, I would talk to the Poughkeepsie publication manager who would consider adding something more to the SRLs or clarify what was written. We had a very symbiotic relationship, particularly with David Ulrich. He was a competent programmer and took a big interest in helping with the pocket reference card development. After releasing the five iterations of the reference card to customers and documenting their comments, I took it to the DPD Headquarters Technical Publications Department to have it 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 picked the green for 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 most 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. The card was very useful to other than Assembler Language Program. That was because it showed how to calculate with EBCDIC, the base 14 numbering system of the S/360. 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 expected things to start happening badly. And they did. First, Al Gayle's headquarters group objected because the Green Card was not on their sanctioned project list. That was even though I did it as an aside to the PAT/360 project with out any additional funding. Next, 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. This resulted in the Eastern Region?s number two man, the former Western Region manager, coming to visit me to learn about my "bum publication". I showed him the reference 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 on the right track!" Very soon thereafter, I got a better job in DPD HQ Software Marketing due to my hands-on work with S/360 software! About this time, OS/360 was being tried out in the T/L Data Center and found to have significant operating problems. One thing led to another and I was assigned to work on ?usability problems? for OS/360. They were known as Human Factor problems. I was assigned to work with Ted Plaut, Manager of Product Test. He had programmers that identified many user problems before the releases could be approved. They needed fixes as quickly as possible to meet the ever shortening release dates for versions with new peripheral product support. I went out to the Regional Software Marketing Representatives to solicit fixes from SEs and customers who were able to solve problems locally. We called the project Operational Characteristics Improvement Program ? OCIP. It soon became the banner for getting things fixed. We even dabbled in getting some hardware changes. For instance, the first console was an IBM 1040 typewriter type terminal, not a display unit. Later, we were one the first to support the color displays. That became a great show piece. Very soon thereafter, Buck Rodgers, 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. When Buck Rodgers became DPD President, he remembered OCIP fondly. He gave me a book titled ?The Entrepreneur? as a memento which I still have. Chuck Ruby, who became a very 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 had a better overall view of OS/360 than most of the Poughkeepsie Programming Center architects and managers. That was because he had to make many 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 chad of the checks would fill the air and cause the filters to clog if on the same floor. He had a lot of suggestions and some code that could be used by others. Very soon thereafter, I 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 creditability 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 other side. He came to me with this idea. I immediately took a mocked up sample match book to a neighbor, Terry O'Connell of Westfield, NJ. He had just become an area manager for the Diamond Match Company. He took my order for a case of match 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 Security Manager. He demanded to know whom I worked for and who paid for the 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. That one case of match books had a life of its own. Some Poughkeepsie OS/360 programmers reported they found a box of them in Hong Kong. Those who wanted to be in the ?know? carried them in their pockets. Don Gavis claimed that they created a ?state of mind? throughout the development centers which were spread throughout the manufacturing division. IBM Palo Alto, Boulder, Kingston, and Hursley England had large roles to play in OS/360 Development. We had OCIP Meetings at most of the locations to get their managers directly involved. I remember Tom Apple in San Jose Data Management being initially suspicious of our authority but he later became a great proponent. 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 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, 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 lower model hardware did not provide the memory or performance required by the huge number lines of OS/360 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 both 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 the 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 the reputation as the man to talk to if you wanted to get your problems fixed. I had the problem that IBM was very conscientious about not pre-announcing 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. The consultants needed to be in a position to provide the best advice as to what to spend their resources on. The Industry Marketing Director for Consultants took a big interest in OCIP. He was able to bring a lot of IBM management attention and resources to OCIP. OCIP continued until Release 20 when OS/360 became fairly stable and the need for usability fixes became much less. I made a final presentation to management that we had solved 240 specific problems and had expended over $10,000,000 additional resources over 5 years. They included Checkpoint/Restart, System Management Accounting, remote console support, and improved Job Control Language and ?lost device end interrupt?, a particularly troublesome problem. We gave test code to those accounts that had severe problems so that the fixes came back to us with assurance that they solved the known problems. The way we wound down the program was typical of IBM. They simply found new jobs for the people involved and terminated the program unceremoniously. Milton Thrasher mthrasher@verizon.net 941 966-9172 Sarasota, FL Milton Thrasher mthrasher@verizon.net 941 966-9172 Sarasota, FL

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