Pages

Saturday, August 3, 2019

To See Ourselves As Others See Us (Part 3)

This posting is based on a talk I gave to The Villages Philosophy Club on 19 July 2019. plus supporting stuff from my Blogs and other sources.

PART 3 - TOASTMASTERS AND MY EARLY CAREER AT IBM


MY IBM CAREER STARTS
IBM Federal Systems in Owego specialized in making digital computers that could stand the rigors of  use in military aircraft. At the time, virtually all airborne computers were of the analog type, so we were pioneers the new digital world. 

We were also responsible for integrating these digital computers into the Avionics ("aircraft electronics") Systems, connecting them and making them work seamlessly with the (mostly analog) sensors and controls and displays. 

After we won the Avionics integration contract for the Air Force/Navy A-7 D/E, I was the "cognizant engineer" responsible for the Head-Up Display (HUD) and the Moving Map. 

Our customer was Ling-Temco-Vought (LTV), the airframe manufacturer, located in the Irving/Arlington area of Texas, between Dallas and Ft. Worth. How did I, a brash Brooklyn engineer get along with those Texans? Well, as I'll explain, it was rocky at first, but ended well. 

Those of you who are hunters know, when you look through a gun scope, the crosshairs appear to be at a distance and in focus with the distant target.  A HUD works in a similar way. From the viewpoint of the pilot, the HUD symbols are focused at a distance and overlay the ground ahead of  the aircraft. 

The graphic above shows a HUD device as well as the pilot's view.

I thought my first visit to LTV as an IBM engineer went pretty well. However, I did notice that the Texas engineers did NOT interrupt me while I was speaking, and, when  they did speak, it was in a slow drawl!

Now, where I grew up (in Brooklyn), if someone does NOT interrupt while you are speaking, that is an indication they are not listening, or not interested. If they speak slowly, that is an indicator of mental limitations.

When I returned to New York, my manager told me he had received a memo from our representative at LTV. According to the memo, the LTV engineers said I was disruptive at the meetings and that I needed to change my manners or be replaced by someone else.

I read the memo and prepared a written reply, refuting each and every criticism in detail. Indeed, I had worked with our representative at LTV when he was working in New York and I thought he respected me and my engineering knowledge. I liked him and I thought he liked me.

Before submitting my written reply to my manager, I showed it to a fellow engineer, Noel Seebe, a Brit who was working on the HUD project because of his expertise with optics.

Noel read the complaint memo, and my written reply, and said that he was sure everything I had written was true. But, he added, "When the King doesn't call you, don't go to the King!"

I realized Noel was right! I folded my written reply and put in in my desk drawer.

Lesson #5: IF THE KING DOESN’T CALL YOU 
– DON’T GO TO THE KING.

That turned out to be excellent advice! On subsequent trips to LTV I was careful not to disrupt meetings. I listened to what those Texas engineers had to say, thought about it, and replied in a restrained manner.

It did not take me long to realize that some of them were as smart as me, perhaps even smarter!

As we got to know each other better, I told them about my farming hobby. One of them was raising horses on his farm and he invited me to visit.

Perhaps the best piece of character evidence that I was an OK guy was that photo of me shoveling steaming, stinking chicken manure! (See Farm Days)

Lesson #6: EVEN SLOW DRAWLIN’ TEXANS 

WHO DON’T INTERRUP 

MAY BE AS SMART AS NEW YORKERS 

– PERHAPS SMARTER !



I COMPROMIZE THE INTEGRITY OF OUR AVIONICS SOFTWARE
As noted above, I was the "cognizant engineer" for the HUD, so I was notified of a HUD-related problem that had come up in the Avionics Integration Laboratory. 

When flying level, the horizon bar on the HUD display is supposed to be stable, however, it would jump up or down a noticeable amount every few seconds. As soon as they showed it to me, I understood the problem. The raw Pitch angle, supplied by the Inertial Platform, had insufficient resolution. The HUD was magnifying the small changes in Pitch angle that occur when flying.

The solution was what, in the analog world, would be called a "low pass filter".  We had to take the raw Pitch angle, as supplied by the Inertial Platform, and filter it such that any change would be sent to the HUD in tiny increments rather than all at once. Of course, if the aircraft was Pitching up or down at a high rate, the "low pass filter" had to be removed or the horizon bar would lag the actual changes.

Now, I knew there was a formal process for requesting software changes. I would have to write the problem up and submit a formal Engineering Change Request, which would be reviewed by a committee. If approved, an analyst and a programmer would be assigned and the change would be made and tested.

Well, to me, that seemed like an overly complex and slow way to make things happen!

So, I spent some time in the Avionics Integration Laboratory watching the test engineers and test programmers do their jobs. The program for the Avionics Computer was written in a "higher-level" language and compiled every week or so. The resultant code, in low-level "machine language" was printed out in a multi-page "listing".

When the test engineers detected a problem, they would get the test programmers to write out what they called a "patch" - a machine-language change to a portion of the program.  The patch would be entered into the computer in 32-bit "words" by flipping toggle switches for each bit. If the patch fixed the problem, the programmer would write it in the higher-level language and it would be included in next week's compiled version.

OK, so I got a copy of the current listing and found where I needed to insert the "low-pass filter" code I had written in machine language.

When I was ready, I waited for the test engineers and test programmers to go to lunch.

Using the toggle switches, I manually entered a GOTO instruction at the proper place, instructing the program to jump to an area of computer memory that was currently empty. Then, word by word, I entered my machine language code (less that 50 words), followed by another GOTO to direct the computer back to where it was supposed to be.

It worked! In level flight the horizon bar slowly drifted a bit up and down with no perceptible jumps. I used the manual control for the simulated Inertial Platform to rapidly change Pitch angle, and I was pleased to see that my "low-pass filter" recognized the rapid changes and allowed the raw signal through!

SWEET SUCCESS !!! (OR NOT?)

When the test engineers and test programmers returned from lunch I showed them what I had done. Instead of thanking me, they were angry!

Initially, I thought they were angry because I had "stepped on their toes" by doing work that was in their domain of responsibility. I'm sure that was part of it, but, as they angrily explained, I had compromised the integrity of the computer program. All of the changes they had painstakingly made and tested since the last program compile were now in limbo. How could they tell if, in my clumsy way, I had inadvertently changed some of their patches, or some existing code?

In any case, my solution worked and they accepted it. I learned a key lesson!

Lesson #7: IT IS EASIER TO ASK FOR FORGIVENESS
 AFTER THE EVENT 
THAN FOR PERMISSION BEFOREHAND.


I HELP SOLVE THE "BIT PICK" PROBLEM AND BECOME A HERO!
We had a serious problem during flight test! Our Avionics System would be working perfectly well, and then, suddenly, things would go wrong. The pilot would turn the computer off and then back on again, but the system would not recover and the flight test had to be terminated, wasting time and money.

Computer hardware was not in my purview, but, being nosy, I tried to learn as much about the problem as I could. It turned out that, once on the ground, technicians would run the "checksum" which is the sum of all the 16-bit half words in the part of computer memory that stored the program and the constants. They would compare this checksum with the correct value computed prior to the flight. The correct, 16-bit checksum always had one bit different from the newly computed checksum, indicating that one bit in memory had changed from a "0" to a "1".


Analysis of the computer memory showed that the failed computer would have a single bit (out of a quarter million bits) set incorrectly. It was always a bit that was supposed to be a "0" that was set to "1"! So they called it the "bit pick" problem.


They would then reload the computer program and the system would work again. It would work fine on the ground, but, the next time they flew, there was a good chance the system would fail at some point, so they had to land and reload again.

Thinking about it, I suddenly remembered a riddle about the "King's Goldsmiths" - and that turned out to inform part of the solution!


THE RIDDLE: The King had ten Goldsmiths and one of them was making gold bars that were one gram too light. Of course, the King could have weighed a sample from each goldsmith to detect the thief, but, if he did so, there wouldn't be any riddle.

The King announced he would detect the rogue goldsmith with ONE weighing. How did he do it?

Well, he summoned all ten goldsmiths and ordered them to bring samples of their gold bars. Then, he said, pointing to the goldsmith furthest to his left, you are goldsmith number one, give me one of your gold bars. He pointed to the next goldsmith and said, you are number two, give me two bars, and so on to the tenth goldsmith.

He put all the gold bars on a scale, noted the total weight, and instantly knew who was the cheater!

How? Well, if the gold bars were supposed to weigh 1000 grams, the total weight should have been 55,000 grams. If the total was one gram less than that, goldsmith number one was the thief, if two grams short, goldsmith number two was the chief, and so on.

HOW DID I USE THIS RIDDLE TO HELP SOLVE THE "BIT PICK" PROBLEM? Well, we had a quarter-million "goldsmiths" (bits in computer memory) and one of them was giving us a "1" when it should have given us a "0".

I came up with a scheme I called a "weighted checksum" in which each 16-bit half-word was weighted according to its place in memory. For example, the first half-word would be counted once, the second half-word counted twice, and so on. Thus, each bit in memory was multiplied by a different amount according to which half-word it happened to be in and what position in that half-word.

By subtracting the correct weighted checksum from the newly calculated weighted checksum, we could identify which bit in memory had been "picked", assuming, as was the case, that only a single bit out of the quarter-million had been "picked". (NOTE: Actually, it was a bit more complicated than I indicated above. If I recall correctly, we had to multiply the first word by 4096 +1, the second by 4096 +2, and so on.)

They assigned a programmer to write to code for my "weighted checksum" routine. It worked as follows:

1) While running, if the computer detected a "write-protection error" (an attempt to write in the area of memory reserved for constants and the program itself - which should never change) or a "time out" (the program got into an "infinite loop" and failed signal a hardware counter every tenth of a second), the system would trigger my subroutine.

2) The subroutine would re-calculate the weighted checksum and compare it to the correct value (which was stored in multiple locations in memory). The difference between those values would identify the "picked" bit.

3) The subroutine would temporarily suspend the "write-protection" feature, would change the "picked" bit to the correct value, namely "0", and record the time of the event, the address of the "picked" bit, and other information.

4) The subroutine would restart the program.

All of the above took less than a minute.

Thus, whenever a bit got "picked" during flight test, it was quickly repaired so flight test could continue without any need to land the aircraft and reload the program. That saved lots of  time and money.

My fix also made a record of when this happened, and what the aircraft was doing at that time.

This helped to determine that the bit "picking" was occurring the first time a given computer memory module flew to high altitude.  That fact helped the hardware engineers determine the cause and how to solve it.

It turned out that our computer memory utilized magnetic-cores. These are tiny donut-shaped devices that may be magnetized in one of two directions, signifying a "1" or a "0".

A bit is "read" by forcing it to the '0" state. If it was in the "1" state, forcing it to "0" would generate a magnetic pulse that was sensed and reported to the computer program as a "1" in that location. If it was already in the "0" state no pulse was generated so the computer program knew it was a "0".

Thus, reading a half-word in memory forced all of its bits to be "0", so the computer program had to restore each bit that was supposed to be a "1".

Well, it turned out that the tiny magnetic cores had a thin plastic coating. Some air could be trapped within that coating. During flight test, depending upon the altitude, the temperature, the thickness of the plastic coating, how much air was trapped, and other factors, any given core could "pop". If a given core happened to "pop" exactly at the time it was being read, the "pop" could generate a magnetic pulse that could indicate it was a "1" rather  than a "0".  Thus, the computer program would restore that bit incorrectly as a "1" rather  than a "0". Wala, bit "pick".

The solution was to "bake" the computers in a high-altitude (low pressure) chamber for a number of hours to assure that all the magnetic cores would "pop".

In September 1969 I received an IBM Outstanding Contribution Award for my "Weighted Checksum Routine to Restore Altered Bits". That award included a cash payment, a trip to Washington, DC for my wife and myself where we stayed at the Watergate Hotel (before it became famous). At the awards dinner we met famed newsman Eric Sevareid, who, in his wonderful talk, reminded us of the "good old days, when the water was clean and sex was dirty".

TOASTMASTERS HELPS ADD PUBLIC SPEAKING  TO MY RESUME
As I noted earlier, my Technical Writing abilities from being Editor of my college engineering magazine and summer internships with ITT Federal had helped my career at IBM. I needed to add public speaking to my "kit of tricks" and that happened when I was invited join the Owego Toastmasters Club. 


Our Toastmasters club met once a week for dinner. Our training included short, impromptu talks that gave almost everyone a chance to speak at each meeting for a tightly time-controlled "Table Topic" as well as a few scheduled speakers to give longer, prepared talks.

One of my favorite features was the "Ah Counter", where one member used a bicycle horn to sound a "beep" when anyone said "Ah" or "Err" or had a too long pause in their Table Topic or Prepared Talk. (All Ahs were counted, and totals were reported at the end of the meeting, but the horn sounded only for the first five.)  That training eliminate all of my Ahs and, even  to this day, my talks very seldom include those types of pauses. 

Ahs still bother me and, when I listen to speakers - including some professionals - I notice their bothersome Ahs.

Each Prepared Talk was critiqued by one of the more experienced members, and many of the others would submit short written comments.  My Brooklyn accent and pronunciation was squared away by these  critiques. For example, I used to pronounce the T in "metal", and was trained to pronounce it as "D".

In our critiques, we were expected to stick to speaking technique rather than arguing with the speaker's opinions. In other words, we were to accept whatever opinion the speaker was supporting, and suggest how they might express it better.

I found it refreshing (as well as instructive) to listen to speakers with different opinions from that point of view. For example, when I watched the recent debates between potential Democratic Presidential Candidates, I did not instantly argue with their opinions, but rather thought about how I, if I shared their views, would present their arguments more forcefully.

Toastmasters had speaking contests at the Club level, the Area, level, Statewide, and so on. These talks were of the type that might be given after a formal dinner. At the time, it was (almost) a requirement to start your talk with a joke - preferably one with some sexual or otherwise controversial edge. In the process, I learned several great Toastmasters jokes.

When I presented this Topic to the Philosophy Club, I told two of those jokes during the discussion period after my talk. I noted that I was telling these jokes as if these situations actually happened  to me, even though they did not. Here they are!

Toastmaster Jokes
SEX AND SAILING:  In the 1960's and early 1970's, Toastmasters was male-only as were most other clubs. My wife, Vi, belonged to a female-only club that was having their annual banquet. She had purchased a ticket for $10 or $15, quite a bit of money at that time. However, because one of our children was ill, she could not go. (In those days, if a child was sufficiently sick, the husband was not considered capable of managing the situation.)

Well, I'm a cheapskate and didn't want to see that money go to waste, so I decided to go! Vi tried to dissuade me, wondering if they would even allow me into a woman-only venue.

Well, not only did they let me in, but the woman in charge enthusiastically rushed over and said: "You're Vi Glickstein's husband, right? You're a Toastmaster who gives talks?"

"Yes, I'm Ira, Vi's husband."

"Well," she continued, "I'm so relieved you're here. Our main after dinner speaker can't make it and I wonder if you could give the talk? Vi always tells us wonderful things about your speeches!"

"Thanks," I replied, "I'm scheduled to give a Toastmasters talk later this week, but I don't think the topic is appropriate for your group."

"What's  the topic?" she inquired.

"It's about Sex," I replied, "and I'm not sure it would be appropriate for me to talk about Sex to a group of women, especially without my wife being here."

"Oh," she replied enthusiastically, "I'm sure it will be fine!"

So, after the dinner, I gave the talk and it was very well received.

When I got home, Vi asked me how I liked her woman's group meeting, how was the food, etc. I told her the meeting was good, they served chicken, of course, but it was good, etc. 

Then, I realized I had to tell her about my presenting the after-dinner speech.

"A funny thing happened, the scheduled speaker cancelled I had to give the after dinner speech."

"How'd your talk go?" she asked.

"Pretty good" I replied. 

Of course "no good deed goes unpunished" so that wasn't the end of it.

"What did you speak about?" Vi asked. (Pause for laughter.)

"I spoke about Sss..." I began, stopping in the middle of the word when I realized this was definitely not a good time to tell my wife I had spoken about Sex to a group of women without her being there.

"... I spoke about Sailing." (Pause for laughter)

She looked at me quizzically, and that was the end of our conversation. Of course, it was not the end of my problems. 

A couple days later, Vi was in the super market and ran into the woman who had been in charge of the banquet. The woman ran to Vi, and gave her an especially strong hug. 

"You know your husband Ira gave the main after dinner speech at my banquet?" she asked.

"Yes, Ira told me." my wife nodded.

"He's is a wonderful speaker," the woman continued enthusiastically.

"I know," Vi replied, "Ira gives those Toastmasters talks all the time." She was used to hearing complements about my public speaking.

"AND," continued the woman, "Your husband is such an EXPERT on that SUBJECT!" (Pause for laughter)

Vi looked at her quizzically. "Ira is NO EXPERT on that SUBJECT!" (Pause for laughter.)

"... He's only done it TWO times." (Pause for laughter.)

"... And the first time, he got seasick." (Pause for laughter.)

"... And the second time, his hat blew off."

"LIKE-EE SOUP-EE" (SEEMS RACIST, BUT IT ENDS OK): I belonged to a men's group that had an annual banquet and I happened to arrive a bit late.

"I'm sorry Ira," said the guy in charge, "But we messed up on the reservations, and we don't have any more seats available at the tables. The only seat we have is at the end of the head table."

So, I went up to the head table and sat in the end seat. The guy next to me was Asian, Chinese or Japanese, I  thought. He had some index cards in his hands and was going over them and making marks on them that looked like Chinese. He did not acknowledge my arrival.

A couple times, I tried to strike up a conversation, but he only grunted and continued working on those damned index cards. Perhaps, I thought, he doesn't speak English.

Finally, dinner service began. The Chinese guy finally put his cards down and started to eat his soup.

I leaned over to him and said "Like-ee soup-ee?" As soon as I heard myself say that, I felt ashamed. The guy turned towards me, and gave me a dirty look. We finished the meal in silence.

Then, it was time for the after-dinner speaker. To my amazement, it turned out to be this Chinese guy, and he gave a terrific speech - in perfect English. When he was done he received a prolonged period of enthusiastic applause. Every one at the head table stood to shake his hand as he made his way back to his seat.

When he got to where I was standing, we shook hands, and he said to me, "Like-ee speech-ee?"

Magazine2


As shown above, the November 1969 issue of Toastmaster magazine included a piece by me about Robert's Rules off Order, a subject I learned the hard way during my years in Student Government.


IRA PUBLISHED AGAIN IN A NATIONAL MAGAZINE

In July 1977, Popular Science, a national magazine for do-it-yourself science enthusiasts, published my story on "A Van Bench/Bed [that] Clears Away for Cargo".

magazine3

Add caption
















Nice to see photos of our three girls and me from those days! We had fun family camping and made good use of this very comfortable bed! And, when it was folded away, it served as a convenient bench and storage area.

AMAZINGLY THE ENTIRE POPULAR SCIENCE ITEM WRITTEN BY ME IS AVAILABLE FREE ONLINE! CLICK HERE AND SCROLL DOWN)


Ira Glickstein

NOTE: This is PART 3. (To go back, Click for PART 1 or PART 2)


(This is the end of PART 3.)  CLICK TO CONTINUE TO PART 4 (OR BACK TO PART 2)





LINKS TO ALL PARTS OF "TO SEE OURSELVES AS OTHERS SEE US"


PART 1 - MY MORAL AND POLITICAL PHILOSOPHY TAKE SHAPE IN MY COLLEGE DAYS

PART 2 - MY CAREER, MARRIAGE, FLYING, AND OUR "GREEN ACRES" DAYS.


PART 3 - TOASTMASTERS AND MY EARLY CAREER AT IBM


PART 4 - APPLE II AND IBM PC ROCK OUR WORLD

PART 5 OUTDOOR ACTIVITIES IN NEW YORK AND  FLORIDA

PART 6 - ACTIVE RETIREMENT IN THE VILLAGES, FLORIDA

No comments:

Post a Comment