LETTER TO MR. T. V. LEARSON FROM L. K. WHITE

Document Type: 
Collection: 
Document Number (FOIA) /ESDN (CREST): 
CIA-RDP71R00510A000300180010-3
Release Decision: 
RIPPUB
Original Classification: 
K
Document Page Count: 
8
Document Creation Date: 
December 16, 2016
Document Release Date: 
December 3, 2004
Sequence Number: 
10
Case Number: 
Publication Date: 
July 9, 1968
Content Type: 
LETTER
File: 
AttachmentSize
PDF icon CIA-RDP71R00510A000300180010-3.pdf438.56 KB
Body: 
9 July 1968 Mr. T. V. Learion, President IBM corporation Armor k, New York 10504 Dear Mr. Learso*: DD/5&TJ ( 0 ?L/ The enclosed note was prepared in response to a query from my-office as to why out software maintenance and systems program- mi costs for IBM 360 equipment continue to rise after more than this. years of experience, particularly in light of a history of excellent IBM support on earlier equipment geaaerations. This evaluation is a serious and conscientious attempt to assess our current situation as a large user of IBM equipment and as an organization committed to the System 360 concept and to suggest some means for restoring our cone once in your continuous sup- port. I believe you will find it of interest? Our people recently discussed some of these matter with Mr. Joseph M. You. He provided a briefing on the quality controls embedded in operating systems releases and gave us an opportunity to test new generations of operating systems using unclassified Agency data. I am sufficiently concerned about a joint resolution of our difficulty that I have asked our Deputy Director for Science and Technology, Mr. Carl Duckett, to go to Now York with one of his senior data processing managers to discuss the matter with you or your designated representative at a mutually convenient time. Approved For Release 2005/02/10: CIA-RDP71 R005A00030018001 '01le Wk- Mr. Duckett may be reached an cerely, L. K. White Executive Director UU/S&T FILE COPY 25 Approved For Release 2005/02/10 : CIA-RDP71 ROO51 OA000300180010-3 Approved For Release 2005/02/10 : CIA-RDP71 R0051 OA000300180010-3 PPB/IPS/ LW S and OCS/WDC:cap (8 July 68 ) Rewritten: ExDir:sbo Distribution: 0-Adsew/att 1 ExDir w/o att i - ER w/att _ =--2- t?CS w / att 1 - OPPB/IPS sub j w/att 1 - OPPB/IPS chrono w/att .i. E C06;s ~DI2$1 "W'` Approved For Release 2005/02/10 : CIA-RDP71 RO0516A000300180010-3 Approved For Release 2005/02/10 : CIA-RDP71 R00510A000300~g g' PP B my office as to why our software maintenance and systems programming costs for IBM 360 equipment continue, to rise after more than three years' eexperiesce, particularly in light of a history of excellent IBM support on earlier equipment generations. I thought that you might be as Interested *9 I is this eval*etion of your product. ached note was prepared in response to a query from those matters on the qualit .(2) an opportualt unclassified Agent for restoring our confid concept and to suggest some and that of others your coatints support. poration, . Le"soa d a recent opportunity to discuss some of Joseph M. Fox who provided (1) a briefing ded in. operating system releases, and levy generations of operating system using V e app kate his Interest in our problem. I believe that the attached -note is a serious and conscientious sscs* our curro ?it*stioan as a larger user of IBM equipment and as an organiza- on committed to the System 360 M I am sufficiently-concerned about a joint resolutio* of our difficulty t h a t I have asked our nizatter for S e and Technology-, Mr. Carl Duckett to go to New York with one of his senior data processing managers to discuss the matter with you or your designated representative at autually convenient time. ely, L. K. Whitt - Executive Director- Comptro'ller Approved For Release 2005/02/10 : CIA-RDP71 ROO51 OA000300180010-3 25X Approved For Release 2005/02/10 : CIA-RDP71 R00510A000300180010-3-' Distribution: Orig & I Addressee w/att I - ExDir w/att 1-ER w/att 2 - DDS&T, OCS w/att I - OPPB/IPS sj w/att 1 - OPPB/IPS ehrono w/att 25X1 OPPB/IPS DDS&T/OCS4 1(8 July 68) 25 Approved For Release 2005/02/10 : CIA-RDP71 ROO51 OA000300180010-3 rc'r'C ? A0proved For Release 2005/02/10 : CIA-RDP71 R00510A000300180010-3 Problems with OS 360 This Agency has a large investment in IBM System 360 hardware, application programming, and training. In one area this investment is much larger than we bargained for--maintenance of Operating System/360. Our experience with OS has been most painful. Although this may be a common complaint, it takes on special meaning in our case. Our applications range across an exceedingly wide spectrum of the EDP art, most of which we would like to believe could operate successfully under the integrated environment of OS. In a sense, the 360 architecture and software design is tailor-made for us because it could provide the generality we need-at some cost to optimal performance in any one area, a cost we are willing to accept if reasonable. A listing of problems we have had is almost endless, but our basic complaints boil down to three. The pace of new releases is too fast for us to absorb with reasonable system programming manpower. The motivation to ride this treadmill is strong but not very appealing. --A new release will provide some new facilities (many of which should have been available earlier). --A new release will give better performance from already available facilities. ( In many cases prior performance was so poor that any change looks like a major improvement.) --A new release will correct earlier errors (which should have been detected and corrected prior to initial release). --IBM will cease to support release n after release n + 2 is available (which completes the carrot and stick approach). There is little evidence of quality control in IBM software production. Many Program Temporary Fixes (PTFs) are published at the same time as the system is released and have to be applied at the customer's site. Approved For Release 2005/02/10 : CIA-RDP71 R00510A000300180010-3 Approved For Release 2005/02/10 : CIA-RDP71 R00510A000300180010-3 There is little, evidence that quality control has improved. We still see the most obvious errors (e. g., the inability to cope with abnormal job termination situations) as part of a new release, errors which almost any test could hardly fail to detect. The IBM approach seems to be "test after release" at customer's expense and frustration. The release of products with known deficiencies is not only costly but gives little credit to the knowledge of the professional user. User costs in implementing new releases are unreasonable. This is manifested in several ways: --System check-out is tedious, frustrating, and expensive. We have learned that we cannot rely on IBM documentation or verbal assurance about the quality of a release. Experience at other installations is not helpful either, basically because of the scope of our activities. We have learned to question and test every aspect of the system before we expose our applications programmers to it in an operational environment. Beyond testing, a considerable amount of time is spent in transferring procedures and installation-oriented software over to the new system. This task is cumbersome and expensive, particularly considering the rapid rate of new releases. ? -System generation is inefficient, error prone, and inconsistent from release to release. It seems ironic that first and second generation techniques (e. g. , much card handling and human intervention between steps) are used to generate a so-called third generation system. Add to these ills the fact that PTFs are required to execute the system generation program itself, and the situation becomes almost incredible. -The relationship between new OS releases and hardware engineering changes requires good planning and additional effort. Over the past ten months, over 750 hours of engineering changes have been installed on our 360 systems--time unavailable for productive work and certainly well beyond that which reasonable planning would call for. Until a few months ago. IBM insisted that installation of these changes be scheduled during periods which meant a significant loss to our scheduling flexibility. Costs in this case were hidden but certainly real. Approved For Release 2005/02/10 : CIA-RDP71 ROO51 OA000300180010-3 Approved For Release 2005/02/10 : CIA-RDP71 R0051 0A000300180010-3 Currently, our central computing facility is using release 11 with portions of releases 9, 12, and 13 jury-rigged into the system. Obviously, this is a rather fragile arrangement, but probably safer and more productive to the user than coping with the unknowns of new releases. A conservative estimate of the machine time used over the past eight months in system generation, check-out and maintenance is 250 hours. Manpower during the same period was probably five man years. One might argue that additional expertise is needed on our part, but we would match the quality of our system programmers against any other installation of similar size. The people and equipment resources that we have had to dedicate to these activities were at the expense of computer work vital to our national security. After the debacle of release 9, we were assured that the pace on new releases of OS would be more deliberate and that new quality control procedures were being instituted. However, our experience with release 14 has been even more unsatisfactory. We have been building and testing a system based on this release since it became available, with unsatisfactory results. In this effort, we have followed the previous advice of our IBM representatives (which, on the advice given them within the corporation, they recently reversed) and avoided substitution of modules from earlier releases as we have done in the past. At the beginning of May, we learned through informal channels that IBM would provide a maintenance release which may solve some FORTRAN and other problems. We fail to under- stand why knowledge of IBM efforts to repair release 14 in a systematic way was withheld when it was clear that we, along with other installations, were spending time and scarce and costly resources to cure the ills of a doomed system. We believe the following specific actions are necessary: a. That IBM take specific action to reduce costs of system generation and check-out perhaps by providing standard, pre- generated systems; reducing the complexity of the customer effort in system generation; and/or providing unlimited free machine time for system generation and system check-out (regardless of installation date). b. That IBM develop a policy on the periodicity of OS releases and software plans such that customers have sufficient time to absorb them in their planning. Approved For Release 2005/02/10 : CIA-RDP71 R00510A000300180010-3 -"Approved For Release 2005/02/10 : CIA-RDP71 R0051 OA000300180010-3 c. That IBM provide quality control procedures that will clearly demonstrate through actual performance that IBM's promises regarding projected releases are valid. A specific example here would be a dramatic decrease in the number of PTFs. d. That quality control procedures include provision for the customer (or user groups or other meaningful forums) to specify benchmark tests and to receive and validate results prior to release. e. That IBM immediately announce that support to previous releases will continue until steps such as those described above are a regular part of new release policy and procedures. f. That after quality control is instituted, IBM, as a second order of business, undertake serious efforts to overcome deficiences in system capabilities 'as recognized by SHARE and GUIDE, whose recommendations. should be seriously considered. g. That IBM provide some means of incorporating engineering changes on-site in a way whick will minimize the loss of system availability to the customer. Approved For Release 2005/02/10 : CIA-RDP71 ROO51 OA000300180010-3 4