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: 
AttachmentSize
PDF icon CIA-RDP79M00097A000300010028-9.pdf470.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