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:
Attachment | Size |
---|---|
![]() | 438.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