MEMORANDUM TO(Sanitized)FROM GERARD P. BURKE
Document Type:
Collection:
Document Number (FOIA) /ESDN (CREST):
CIA-RDP79M00097A000300010028-9
Release Decision:
RIPPUB
Original Classification:
K
Document Page Count:
8
Document Creation Date:
December 15, 2016
Document Release Date:
August 22, 2003
Sequence Number:
28
Case Number:
Publication Date:
March 7, 1973
Content Type:
MEMO
File:
Attachment | Size |
---|---|
CIA-RDP79M00097A000300010028-9.pdf | 470.47 KB |
Body:
Approved For Release 20/10/01 : CIA-RDP79M00097A0003000028-9
March 7, 1973
Here is the paper on COINS which
Bill Baker mentioned. It was prepared by
STAT
Approved For Release 2003/10/01 : CIA-RDP79M00097A000300010028-9
Approved Forvilelease;20 3110/01 :,,CIA-RD9Jy100 W000300010028-9
ABSTRACT: In most cases COINS, as now constitute,', has increaa^d the productivity
of its users and improved the quality of their work. To increase the benefits of the system
and to make it valuable to an even larger percentage of its possible users a number of quite
feasible measures should be taken. Among those are the increasing number, time span, and
detail of files, keeping files more current, removing restrictions on output of certain file
data, and improving certain features of hardware and software. However, no matter what is
done, there will remain a residue, hopefully small, of people whose missions require
information to be more up-to-date than we can hope to make it at this time. There are also
people who are ineducable, in the computer sense.
The changes necessary in order to produce a permanent system of greater value will he
discussed.
It would be desirable to continue the system as improved.
Approved For Release 200 /i, OJT
RECEIVED
Approved F ,Releate'~f? lh b 79MOObWA000300010028-9
The present study is a follow-on to one made principally by the writer late in 1970. A
report of that study of user problems and attitudes was made. However, to avoid being
circumscribed by the prior conclusions, the report was not used as a basis for the interviews
conducted for the instant study.
The size of the present sample of interviewees, including both sponsors and users, is a
alf dozen times as large as that of 1970. The numL,er of files a.id the number of
organizations involved are larger by a significant amount than they were at the time of the
first study.
Various criteria can be used to evaluate or describe a user. Among these are his need
for currency, attitude toward using electrical devices, understanding of computer
capabilities, satisfaction with the system output, view of the mechanical file as a threat or an
advantage to him, and desire to have mere or improved files. Even with so many dimensions
to cope with, it is sometimes possible to discern clustering about some sort of modal image.
I did not notice any such phenomenon. In other words, user descriptions distributed rather
flatly, except that on balance users tended to defend the value of the system to them.
Good files are the sine qua non for a successful system. Optimization of every other
element does not offer as much overall as changing the picture on files. Intrinsically, file
improvement is the easiest thing to accomplish, since a mere change in management attitude
should be sufficient.
With one laudable exception, sponsors did not show any great desire to expand files,
improve detail to make them more current, or in general to expend resources or effort on
improving this product.
It is easy to play the critic about this problem, but it is more useful to know how it
arose and why it persists, and then to describe a solution without any derogatory
implications.
A person who creates a file, or who inherits its maintenance, usually has a sort of
parochial view of the situation. The important thing to him is that the file works locally.
Incidentally, this statement is just as true in industry, as it is in our community. One result
of this is that the file can be bipartite, i.e., that the most recent entries can exist in a sort of
"tickler", with the main file semi-archival. Having a "tickler" means that updating the main
file is an act of convenience rather than necessity. Furthermore, it contributes to the power,
or rather the sense of power, of the possessor of the most current information to be able to
dole it out on request. However, in business as well as in government, very few files of any
size or importance are of interest only locally. Thus, payroll information is needed for cost
estimates, labor distribution is needed for payroll, etc.
What permits blockage of the free flow of needed information in any organization, is
the attitude of management to the importance of that flow. Realization of that importance
leads to the conclusion, in every case, that the timely and accurate maintenance of a file is
as important a function, for one responsible for the file, as his own use of it, It is more than
one can expect of human nature that one who builds a file from which he extracts a
monthly or semi-annual report to keep it current for the benefit of someone he doesn't even
know. Therefore, granting that outside interest in the file is for the common good, it is up
to command to rule on the priority of the updating function.
Approved For Release 200SM-0/01: CIA-R1P 9 00097A000300010028-9
Approved FoA,,,Release 8f . EU-1: M00l A000300010028-9.
Every kind of user turned up in the sample. There were those who never touched a
terminal, relying on trained intermediaries. There were those who composed one successful
program, and used it exclusively thereafter, not stretching their luck. There were others who
composed new programs as they needed them. There were trained intermediaries who
fulfilled requests without understanding them, and others who took part in the construction
and rationale of the requests. The latter were generally librarians. Surprisingly, complaints,
praise, or suggestions for improveme,it were largely independent of the kind u, user.
The principal complaints were:
1. Compartmentation of files meant that TK and Delta Gamma material was
not transmitted. This meant that the user had no assurance that his answer was complete.
raised the possibility that the answer might indicate whether it exhausted the file or whether
a call on the grey phone was necessary. There was neither rejection or hearty acceptance of
this proposal. Considering the milieu in which we operate, I cannot see the harm in
transmitting the data, if the source is not given.
2. Certain files did not go back far enough in time for some users, particularly
where year to year comparisons were needed. It was plain that this is a question only of
degree, i.e., of doubling the active time span in some cases. The fact that information which
was removed from the active file was retained on archival tape, and could be retrieved, was
not known to many users who could well afford deferred service using such information.
3. Updating practices came under fire. The maintenance schedules as quoted
were not only too infrequent, but were not adhered to. Files supposed to be updated twice
a month were in fact revised only quarterly. Daily updating turned out to mean 48-72 hours
behind in some cases. Of course, the severity of user reaction reflected user time constraints,
the infrequent user being more contented than one who used the file each day. It is also fair
to point out, for example, that the need for immediate or on-line updating is not apparent
where the information itself is not very recent.
4. Turnaround time was generally satisfactory. However, there were some
complaints. Service from the NSA computer was ordinarily much faster than that from DIA.
This is apparently due to the fact that COINS calls are treated like internal calls by the NSA
system, but not by the DIA system. This also may be due to the fact that COINS calls are
essentially background to the interactive system.
5. Abort messages are curt. After all, a large proportion of aborted requests
require no more than some slight change to be effective. It would be useful if there were
many more detailed abort messages available, so that retransmission of a request could be
made speedily. To take care of the many aborts caused by garbling of the message by the
communication system, it is necessary to improve transmission redundancy.
6. There is a limitation on the number of characters which may be transmitted
t- a requestor. This sometimes produ ' half a loaf which is no bets^r than none, and more
aggravating. There are three simple cures for this problem. One is to increase the bound on
transmission, which will reduce but not eliminate the cases of dissatisfaction. Secondly, an
interactive type of response would reveal how many answers have been retrieved, which
Approved For Release 20M=pl T0097A000300010028-9
Approved For Release 200,/1 1?:kc I' fk 009R000300010028-9
would give the requestor a chance to refine his retrieval criteria so as to eliminate some of
the answers. The third sets up a scratch file for the answer. In that case the requestor can
print the answers in batches, or do further processing of what has been retrieved, a desirable
capability in any event.
7. Terminals are insufficient in number, and badly placed. People will settle for
what they can got over a grey phone, or do without, rather than walk up some flights and
across the length of a building to find a terminal. Yet a single terminal in an out of the way
area is the sole resource of several agencies.
8. In some files, certain fields contain summary information. For example, if
several different kinds of aircraft were to take part in an exercise, the file might show the
total number of such aircraft, even though a breakdown by type was available. By doing
this, it becomes impossible to sort the file by aircraft type. Unless it is plain that certain
details are never made the basis of study, it is wrong to summarize them prior to entry into
a file. Summaries can always be made on output.
9. Not every file has a user guide. The examples of programs in the user guides
are too terse, too few, and are not sufficiently annotated. Some user guides never reach a
user, but are filed by a supervisor, as are many of the newsletters published by COINS. I am
rather sure this is done innocently and, in some cases, because the user is in an unclassified
area.
10. The classic difficulty with all retrieval systems exists here, i.e., the keywords
used by the indexer are not the search words envisioned by the customer. There is really no
sure fire cure for this, but a fair anodyne consists of a good thesaurus for the subject matter,
a realization by the customer that the problem exists, some quality control on indexing, and
the ability to retrieve on textual scan.
The greatest praise for the system came from those who could benefit from format
control such as matrix presentation of data according to two criteria. The ability to sort
according to various criteria was much valued. The ability to get summary counts was also
important. It is in just these capabilities that the librarian or grey phone is deficient. In
other words, a good librarian can find the mot juste, as it were, but fails where a large
amount of data must be processed in some special way and presented in some particularly
meaningful form.
There are other benefits of which users are aware. Thus, one need no longer wait upon
the working schedule, previous engagements, or moods of the man who knows the file.
Furthermore, if there is a failure of communication and an irrelevant answer is produced, an
amendment can be made without embarrassment. Local hard copy files can be eliminated.
The shopping list for improvements to or changes in the system is very long. Those
important enough to comment on here fall into two classes. The first of these consists of
problems which can be accomplished within a short time frame and without requiring
intervention by higher management. The second set consists of cases where more manpower
:oust be committed, more n;grey spcat, a longer time span allowed for con,,iletion, or some
kind of command decision made.
4
Approved For Release 29'/P1 00097A000300010028-9
Approved F ,Releasar 1I& PT&M 9M00WA000300010028-9
Among the relatively easily achievable irnprovements:
1. Have a user guide for every file. Keep it up to date. Number the editions and
list current numbers in the newsletter. Make a a effort to destroy outdated editions.
2. When a person first becomes a user, make sure that his first two or three
%-ttempts to interrogate the system are successful. This means that someone from the COINS
staff shepherds him through these interrogations. A person is turned off, or becomes a good
customer, largely on the basis of what he first experiences. Observe the kind of hand-holding
IBM systems engineers perform.
3. The present trouble shooting practices of the COINS staff, already quite
commendable, should be retained and expanded. Those who have trouble more than once
should receive a second dose of superintended success as in the previous paragraph.
4. Tutorial courses should be file oriented, not language oriented. This matches
the customers attitude and interest, although we might consider certain librarians and
persons serving as interfaces to be exceptions.
5. Whenever the system software can pinpoint the reason for its decision to
abort, it should print the reason. To be able to give reasons in every case is more than we
can expect at this time. However, the large majority of cases of dissatisfaction with the
abort message can be eliminated right now.
6. Begin a comparative study on the differences among like-named fields in
different files. Those differences tend to take a user in flank when he goes to a new file for
information which he is used to find in another file.
7. Begin setting up some formal way of describing differences in transliteration
among files.
8. Increase the bookkeeping capability of the system so as to eliminate the
present onerous manual reporting practices. In doing so, there will probably be an increase
in accuracy, troubleshooting capacity and timeliness. Include the use of a file, by the
organization which maintains it, among the statistics, for comparative purposes.
9. Introduce thesaurus ideas into keyword lists, to narrow the communications
gap between indexer and user.
10. For people who tend to make only one or two kinds of queries, supply tapes
which can be used to subsume set-ups of the terminal, all parts of the request save
parameters, and sign off procedure. Here again we have an IBM precedent, where the
salesman filled out a magnetic band program, for the customer on one of its small
machines.
11. Eliminate the DIA requirement for ribbon changing. At least take advantage
of the acceptability of ribbons which have been reversed three times, by running random
sequences against new ribbons until they are acceptable.
12. Instead of the number codes,, which mystify users, in certain coded fields
have the program either furnish the glossary for each code, or, better, translate it into
acceptable form on output.
Approved For Release 2003/i 0T,('Ty?~: `G" -R'pPT91, OT097A000300010028-9
Approved Forii&lease 20b~t1h9/ ~ b F6I _nm00094&000300010028-9
13. Encourage users to visit the COINS office on an informal basis. Perhaps some
attention should be paid to change the appearance of the office to cater to this kind of
business.
14. Increase the number of characters which may be returned in response to a
request. Reestablish the POST verb, so that a local scratch file is set up which can be
transmitted in parts, further manipulated, or reduced in size.
Those improvements which represent larger costs or efforts or changes in policy stances
1. Increase the number of terminals at certain user locations. Put them into
more accessible locations.
2. Introduce a HELP option to make on-line tutorial comments available, e.g.,
expanded versions of the abort messages.
3. Introduce an interface at least between the TILE and DIAOLS languages.
Begin work on generalizing language interfaces.
4. Extend on-line and current file maintenance under suitable safeguards.
5. Indicate whether a report is complete, or whether technical information has
been omitted. Show date of last change in records where information of that kind is
significant.
6. Put requests from the switch more on a par with the local queue in the DIA
7. Consider the benefit from having unevaluated information, identified as
such, in the files. This is analogous to taking account of unconfirmed orders for planning
purposes, in the business world.
8. Take the proper command actions to have file sponsors rate the quality,
maintenance and currency of files as a high priority aspect of their missions. As part of this,
sponsors should be put under a duty to:
a. Inform users of the value of a file.
b. Train potential new users.
C. Know and maintain contact with users.
d. Be responsive to needs of users which are beyond needs of sponsor.
e. Take part in preparation of Users' Guides, training aids, seminars, etc.
9. Increase bandwidth.
10. Most important: files, files, files!
6
Approved For Release 2003/10/01 CIA-RDP79M00097A000300010028-9
Approved Forpelease(10Z1;!6,
I,fi.#,7PM000 7*000300010028-9
CONCLUSION: There is no question that a substantial number of users in my sample
have had their own potential, and the value of their work, enhanced by the availability of
this system. The number of those fitting the above description, and the quality of the total
product, would be enlarged as the above suggestions were implemented.
It was not part of my mission to look at costs. Perhaps someone should do this.
Subject to such lack of knowledge on costs, the system is valuable as it stands and has a
good potential for near term and far term enhancement.
I think COINS should be kept going, as long as there are organizations which have the
interest in the value of our intelligence product to contribute to it, and people, who have
the wit to realize that it can help them, are willing to use it.
25X1A
Approved For Release 2003/10/01 CIA-RDP79M00097A000300010028-9