More interesting things about our work with MIT

See listNOV 28 196666-FM1-170FM/Deputy Chief, Mission Planning and Analysis DivisionMore interesting things about our work with MIT

I always start out these MIT newsletters with the hope they will be short enough that you'll be willing to read 'em. A couple of things came up at our Program Development Plan review on November 16 there that I thought I would pass on.

1. It's becoming more and more obvious that the program development facilities at MIT – both digital and hybrid – are going to be severely saturated during the first 3 or 4 months of next year. During that period we will be working simultaneously on the AS-206, 207, 208, 503 CM and two 504 programs, and we certainly will not have the second hybrid on the line. And so all this work will be dropped on the two 1800 digitals and the sin- gle hybrid facility until the IBM 360 digital computer is made operational. Since I am convinced the 360 readiness will not come early, I have asked MIT to set up a special task force specifically to keep the development of that facility progressing at the greatest possible speed. In addition we propose to help as much as we can by doing such things as preparing pro- grams here at MSC for use in checking out the vital MAC compiler being developed by one of their contractors.

2. It is my understanding that all AC effort on program development being carried out at Milwaukee shall be terminated upon delivery of the AS-50l documentation which is scheduled for delivery on about December 5. The nine AC people who were sent to MIT for work on AS-501 are all being retained and are now working on AS-206.

3. It looks like we will be able to have a meaningful computer storage review in January. Ed Copps pointed out it is not only lack of storage that's going to trouble us, but also other things like the limit to the num- ber of verbs and nouns, whatever they are, that are available.

4. Rick Nobles and his guys struck a vein of gold the other day up at MIT in the form of detailed flow charts of some parts of the program. These flow charts are the form of documentation everyone felt in their bones must be available somewhere 'cause you just can't program without something more definitive than the GSOP. Now that we have discovered them, MIT has agreed to let us use them with the understanding that they are not controlled documents and that MIT retains no responsibility for their accuracy and quality. We are delighted to accept the flow charts under those terms and will be responsible for reproducing and distributing them to whoever has need to know. I would like to reiterate that we have al- ways maintained that the MIT documentation is inadequate, particularly in the area of flow charts and I have every intention of emphasizing that battle as soon as we get our program development plans in shape.

5. Some weeks ago we discussed the possibility of having several MSC people associated with flight crew working in residence at MIT with Jim Nevins' merry band on the development of Chapter 4 of the GSOP and associated crew procedures. Our objective was twofold – to speed up com- pletion of that work for AS-504 as well as training these people to service the flight crews in their training for these tough Block II missions. MIT is still anxious to have these people come, but I understand from a brief discussion with Joe Loftus, who is handling this matter at MSC, that he has run into some problems. I certainly hope he is able to overcome these soon because it sure looked like a good idea to make MSC as independent as possi- ble of MIT in the training of flight crews.

6. It looks like our biggest schedule problem will be delivery of the AS-207/208 programs. Although we have been meeting our AS-278 milestones with regard to GSOP delivery and program coding pretty well, MIT has recently revised their estimate of how long it takes to perform program integration and verification. It seems to me that the only way to improve the delivery schedule is to get the facilities MIT needs as soon as possible, as noted above, and to reduce the amount of work that is required. We are pursuing the idea of establishing processor priority lists both here and at MIT with the intent of carrying along all of them (including those unique for AS-503) in the AS-278 program assemblies, but giving maximum emphasis on the debug- ging and integration to those with the higher priority. For example, it's evident that it is not necessary to have the entire concentric rendezvous flight plan operating to perform the AS-278 mission, since the maneuvers in those re-rendezvous mission phases will be established pre-flight and/or by ground control a la Gemini with the need for onboard maneuver determination starting only at TPI. I'm sure there are a number of other processors which could also be labeled not mandatory for the mission. It is our intention to see just how far we can back off in an effort to help the schedule. It is rather depressing that we have to take steps like this, but the advantage of this approach is that if the program integration proceeds faster than antici- pated, or if more time becomes available for one reason or another, it will only be necessary to start working on processors which are already in the assembly, which is a much easier thing to do than to add them in when a re- prieve occurs. And of course it gives us the option of accepting delivery of a flight program in which some of the lower priority processors are not work- ing in order to obtain it sooner.

Wasn't very short was it, or interesting either, but I'll be darned if I'll throw it away after getting it to this stage.