FINAL REPORT STUDY OF COINS EXPERIMENT

• Document Type: CREST
• Collection: General CIA Records
• Document Number (FOIA) /ESDN (CREST): CIA-RDP79M00096A000300070001-3
• Release Decision: RIPPUB
• Original Classification: C
• Document Page Count: 91
• Document Creation Date: December 20, 2016
• Document Release Date: November 7, 2007
• Sequence Number: 1
• Publication Date: May 1, 1970
• Content Type: MF

Approved For Release 2007/11/07: CIA-RDP79M00096A000300070001-3
C-O-fit-F-I-D-E-N-T-I-A. L
SDT,D-MM-25
1 May 1970
NSA review
completed
U N I T E D S T A T E S I N T E L L I G .E N C E B O A. R D
INTELLIGENCE INFORMATION HANDLING COMMITTEE
System Design and Development Subcommittee
MEMORANDUM FOR: SDF,DS Members
SUBJECT: Final Report Study of COINS Experiment
Attached for your information and retention is .
copy of the Final Report, Study of COINS "Experiment"
from October 1969 - March 1970. This was prepared by
for the COINS
Project Manager.
Attachment:
As Stated
Distribution List:
Approved For Release 2007/11/07: CIA-RDP79M00096A000300070001-3
 1 1 1 L UIVI I UtIV I If-\L Wii 531-C-1169
Approved For Release 2007/11/07: CIA-RDP79M00096AO00300070001-3 y _
Coy mrnur y C )`1 u - . i a I -eH*0 t n C) 5 17 s0m6m
`~?~:k-'~'~~',ii~"'".~-..~`n~~"..?` -.';c-mss W;~~--'.,.;~~4+t~'r:rY;.~m~;.~' ~.'~'
?:';:'.:.:: ., ga- Z& ZiP!'.'"""^',1:: 1y' ^$.31 a~~.o`. '.' eit~'ia`_x'S^~., '" .: i:Cu:.'....? - [ ....,~-..:`,"'rte '..~
y l~ Rc~~.~v -1~~,5} 4i a'sYtT'C? ~ EP'? ~w~~~ ~a?
.^~... i/.: \'. r. .a-. ?u~i~~.aY~:Y.[~R~ti" '. .~ Ar:i~.~S.,aF~'l.%ui.rYi -iw~eiJ.~:~i~'~
FINAL REPORT
STUDY OF COINS "EXPERIMENT" (U)
October 1969 - March 1970
TR-70-1169-02
27 March 1970
Prepared for:
National Security Agency
Fort George G. Meade, Maryland 20755
GROUP-1
Excluded from automatic downgrading
and declassification
This material contains information affecting the national
defense of the United States within the.meaning of the
espionage laws, Title 18, U. S. C., Sections 793 and 794,
the transmission or revelation of which in any manner
to an unauthorized person is prohibited by law.
CONFI DENTI AL
Approved For Release 2007/11/07: CIA-RDP79M00096AO00300070001-3
 Approved For Release 2007/11/07: CIA-RDP79M00096AO00300070001-3
Approved For Release 2007/11/07: CIA-RDP79M00096AO00300070001-3
 Approved For Release 2007/11/07: CIA-RDP79M00096A000300070001-3
TR-70-1169--02
Page ii
TABLE OF CONTENTS (U)
Page
SECTION 2
2.1
2.2
2.3
2.4
2.5
2.6
2.7
- SUMMARY OF WORK PERFORMED
Orientation
Preliminary Recommendations
Switch Change Study
Service Check Study
Communications Controller Study
Message Design Study
Data Collection Study
Communications Study
- MESSAGE DESIGN STUDY
Interrogations - INTG
Receipts and Releases - RCPT and RLSE
Aborts - ABRT
Answer - ANSR
Service Messages - SRVC
Queues and Communications Control Data
Summary
2- 4
2- 4
2- 6
2- 8
2- 8
2-13
2-16
SECTION 3 - COINS DATA COLLECTION AND ANALYSIS
3.1 Existing Procedures
3.2 Recommendations
3.3 Estimated Costs
SECTION 4 - COINS COMMUNICATIONS
4.1 General
4.2 Requirements
4.3 New Products and Techniques
3- 1
3-20
3-36
4- 1
4- 3
4-12
Approved For Release 2007/11/07: CIA-RDP79M00096A000300070001-3
 , Approved For Release 2007/11/07: CIA-RDP79M00096A000300070001-3
TR-70-11 69-02
Page iii
LIST OF FIGURES (U)
Number
Page
3-1
Definition of INTG Record in LOGGA File
3- 3
3-2
Definition of ANSR Record in LOGGA File
3- 4
3-3
COINS Processing with Host and Addressee
DIA
3- 7
3-4
COINS Processing with Host = DIA and
Addressee & DIA
3-10
3-5
COINS Processing with Host DIA and
Addressee = DIA
3-13
3-6
Analysis of COINS Message Length by
Message Type-February 1970
3-29
3-7
Comparison of Percentages of Total COINS
Messages and Total Segments by Segment
Length/Message
3-30
3-8
Relationship of Elapsed Time and Total Number
of Segments
3-33
3-9
Relationship of Elapsed Time and Total Number
of Segments
TI Synchronous System
4-3
Secure TI System
4-21
4-4
Super Encrypted TI System
4-22
Approved For Release 2007/11/07: CIA-RDP79M00096A000300070001-3
 Approved For Release 2007/11/07: CIA-RDP79M00096A000300070001-3
TR-70-1169-OZ
Page iv
LIST OF TABLES (U)
Number
Page
2-1
COINS Message Types
3-1
COINS Message Length by Message Type
3-24
3-2
Time Analysis of Nine Consecutive INTGs
Against LOGGA File on 14 November 1969 3-31
3-3
Time Analysis of Nine Consecutive INTGs .
Against LOGGA File on 13 November 1970 3-32
Approved For Release 2007/11/07: CIA-RDP79M00096A000300070001-3
 Approved For Release 2007/11/07: CIA-RDP79M00096AO00300070001-3
Approved For Release 2007/11/07: CIA-RDP79M00096AO00300070001-3
 Approved For Release 2007/11/07: CIA-RDP79M00096AO00300070001-3
TR-70-1169-02
Page 1-1
SUMMARY OF WORK PERFORMED (U)
(U) During the six months of this contractual effort, the
Study Team has worked on eight different aspects of the COINS
Experiment. Each of these studies is summarized in this section
in accordance with the instructions contained in paragraph lb of the
contractual Data Item Description which states:
"b. Brief summary of all work done, including
that yielding negative results or positive
results not used. All information shall
be referenced to the appropriate Progress
Report, or section of the Final Report,
where the subject is discussed in detail."
(U) Sections 2, 3 and 4 of this report contain detailed
discussions of the work undertaken since the publication of the
mid-contract report.
Approved For Release 2007/11/07: CIA-RDP79M00096AO00300070001-3
 Approved For Release 2007/11/07: CIA-RDP79M00096A000300070001-3
TR-70-1169-02
Page 1-2
1.1 ORIENTATION (U)
(C) Shortly after Informatics was awarded the contract
to study the communications subsystem in the COINS "experiment",
it was briefed at each of the agencies participating in the experiment.
Next, half-day briefings at DIA, CIA, NPIC and finally at NSA were
given. Since the system was in an experimental stage, most of the
information given at these briefings was in terms of current
organization of the system, and current operational problems.
It became apparent that although the communications software
interface had been pre-specified, most agencies were modifying or
interpreting communications requirements in light of their own
needs. ' Most of the information presented in the preliminary report
was gathered at these orientation meetings. These were a good
source of information pertaining to COINS particularly in the area
of current operational doctrine.
(U) Since the time of these orientation meetings, each
system in the network has undergone some modification. Informatics
has kept abreast of these changes by attending the monthly meetings
of the Computer Communications Interface Panel (CCIP). It has
also attended meetings of the Test and Analysis Panel. Demonstrations
have been given using the system at three of the four participating
agencies.
(U) These meetings were documented in meeting reports
numbered from 1 thru 13.
Al A L
Approved For Release 2007/11/07: CIA-RDP79M00096A000300070001-3
 Approved For Release 2007/11/07: CIA-RDP79M00096A000300070001-3
fl r ,?
1.2 PRELIMINARY RECOMMENDATIONS (U)
TR-70-1169-02
Page 1-3
(C) The Study Team reviewed the material collected
during the orientation task and concluded that there were areas
where improvements could be achieved with relatively small
investments in resources. These short-term improvements were
detailed in Section 3 of the mid-contract report. These recom-
mendations were titled:
1. COMMUNICATIONS HARDWARE PROBLEMS
2. ADD CAPABILITY TO RECOVER FROM
SWITCH DISK FAILURE
3. MODIFY FREQUENCY OF SRVC (CHECK
OPERATION)
4. MODIFY THE SEGMENTING ALGORITHM
5. IMPROVE LOGGA FILE DATA
6. STANDARDIZE PARITY CHECKING
7. STANDARDIZE PRECEDENCE ALGORITHM
8. STANDARDIZE USE OF ABRT (FAULT)
9. STANDARDIZE TIME OF CLOCKS AT ALL
COMPUTERS
10. STANDARDIZE RLSE MESSAGE PROCESSING
11. IMPLEMENTATION OF WARM START
CAPABILITY AT NPIC
p 0,1 r ~ ~n, r p., MIA 1.
Approved For Release 2007/11/07: CIA-RDP79M00096A000300070001-3
 Approved For Release 2007/11/07: CIA-RDP79M00096A000300070001-3
TR-70-1169-02
Page 1-4
1 . 3 SWITCH CHANGE STUDY (U)
(U) During the data collection phase of the contract, it
became apparent that the central switch was not performing all of
the functions required by the participating agencies. The switch
was losing messages after they had been receipted for. It was
generating more traffic than necessary for the operation of the
system through the SRVC (Check) message. And, it was fairly
inflexible because of limited core space. Two approaches were
examined regarding a change to the communications switch. These
1 . elimination of the switch,
2. and upgrading of the switch.
Informatics could not then, and cannot now, recommend either
course of action. Each has advantages and disadvantages. These
have been documented both in the preliminary report and in this
final report. Further study in this area will be required to
determine what course of action should be followed regarding the
COINS communications switch.
(U) This study was documented in Section 2 of the mid-
contract report.
Approved For Release 2007/11/07: CIA-RDP79M00096A000300070001-3
 Approved For Release 2007/11/07: CIA-RDP79M00096AO00300070001-3
TR-70-1169-02
Page 1-5
SERVICE CHECK STUDY (U)
(U) During the past few months, Informatics personnel
and Computer Communications Interface Panel (CCIP) members
have devoted time to the solution of problems caused by current
procedure for handling of the SRVC (CHECK) message. Problems
occur when participating systems do not receipt SRVC (CHECK)
messages in a timely manner. Non-receipt of a CHECK message
may indicate any of the following situations:
1. System failure
2. Communication line problems
3. A participating system was unable to generate
a RCPT within the time constraints of the
switch because of other processing requirements.
If a RCPT is not. received for a SRVC (CHECK), the Switch
automatically puts the particular system in BREAK status. This
is, of course, undesirable if there really aren't system or
communications problems. The problem has been recognized by
the CCIP members and some general accord has been reached as
to solutions. In general, what is required is:
1. modification of the criteria for generating SRVC
(CHECK) messages at the switch,
2. an expedient receipting for CHECK messages by
the participating systems and,
3. implementation of procedures for determining
which line is down when communications
problems do occur.
(U) A definitive statement of the problem and its solutions
is contained in Section 2. 5. 5 of this report.
Approved For Release 2007/11/07: CIA-RDP79M00096AO00300070001-3
 Approved For Release 2007/11/07: CIA-RDP79M00096AO00300070001-3
VI I1L
TR-70-1169-02
Page 1-6
1.5 COMMUNICATIONS CONTROLLER STUDY (U)
(C) During the data gathering phase of the contract, it
was stated by personnel at the CIA that they were receiving unwanted
DLE characters in the data stream. Normally the IBM 2701
Communications Controller strips these characters from the data
stream. However, the IBM 2701 used by the CIA had been modified
to work with synchronous data communications. There were two
questions that had to be answered regarding this situation. These were:
1. Why were the DLE characters appearing on the line?
2. Why weren't the other agencies receiving unwanted
DLE characters?
(U) Informatics researched the subject through the IBM
publications and determined that the reason that DLE characters
were appearing on the line was that the IBM 2703 Transmission
Control Unit generates DLE/SYN characters whenever the computer
fails to service the transmission control unit in timely manner.
The reason that the IBM 360/30 computer is unable to service the
IBM 2703 transmission control unit in a timely manner is that the
computer itself is very slow and there is a model 1850 Channel to
Channel Adapter which is attached to the selector channel. The
selector channel has priority over the multiplexor channel and
therefore uses all of the computer's I/O bandwidth when it is
operating. This in addition to the amount of time required for a
Start I/O instruction and some of the other character oriented
instructions could cause the computer to miss servicing the IBM 2703.
Normally the IBM 2701 eliminates DLE/SYN characters, however,
the IBM 2701 used in the COINS network has been modified so that
only the SYN characters are deleted.
f 01a~ Pu, nrm'AL
Approved For Release 2007/11/07: CIA-RDP79M00096AO00300070001-3
 Approved For Release 2007/11/07: CIA-RDP79M00096AO00300070001-3
TR-70-1169-02
Page 1-7
(U) The reason that the other agencies are not detecting
unwanted DLE/SYN characters is that these characters are deleted
before they ever appear in a message buffer. The communications
data being transmitted to the Univac 494 computers is read into a
primary buffer. The data in the primary buffer is transferred on a
character by character basis to a message buffer. Each character
in the primary buffer is examined and if it is a DLE or an SYN
character it is deleted before it is placed in the message buffer.
(U) This study is documented in Section 3. 1 of the mid-
contract report.
Approved For Release 2007/11/07: CIA-RDP79M00096AO00300070001-3
 Approved For Release 2007/11/07: CIA-RDP79M00096A000300070001-3
TR-70-1169-02
Page 1-8
1. 6 MESSAGE DESIGN STUDY (U)
(U) A study of the various message types used in the
system and the procedures followed for handling these messages
by the various systems in the network has revealed a few
inconsistencies and problems. The serious problems have been
recognized by the CCIP members and are being resolved. While
most of the inconsistencies in interpretation and handling of the
various message types do not cause serious problems during the
experimental phase, awareness of these inconsistencies should
yield a clearer understanding of the performance of the network.
An attempt should be made to eliminate them should the network
become fully operational.
(U) Section 2 of this report contains definitions of the
messages as they now stand, a statement of recognized inconsistencies
and problem areas and solutions where applicable. Participants
are encouraged to make known any other inconsistencies in inter-
pretation and processing of the various message types as an aid to
understanding current performance of COINS. This information
will be useful in adding additional systems to the network.
Approved For Release 2007/11/07: CIA-RDP79M00096A000300070001-3
 Approved For Release 2007/11/07: CIA-RDP79M00096A000300070001-3
TR-70-1169-02
Page 1-9
1.7 DATA COLLECTION STUDY (U)
(U) The Data Collection Study was an outgrowth of the
Study Team's attempt to determine the network's quality and
reliability. It was necessary to understand the data gathering and
analysis methods currently being used to summarize COINS
utilization and effectiveness. The results of this study and analysis
are detailed in Section 3 of this report.
(U) It should be noted that the COINS system has really
been in a "shakedown cruise" state since the inception of its use.
Therefore, the data that has been gathered and analyzed thus far
reflect equipment changes, software changes, file maintenance
changes, and a growing knowledge of the details of COINS design.
Approved For Release 2007/11/07: CIA-RDP79M00096A000300070001-3
 Approved For Release 2007/11/07: CIA-RDP79M00096AO00300070001-3
TR-70-1169-02
Page 1-10
1.8 COMMUNICATIONS STUDY (U)
(U) In the mid-contract report, Informatics investigated
the possibility of either upgrading or deleting the 360/30 message
switching computer from the COINS network. No recommendations
concerning the desirability of either approach were made. It is a
very difficult area since any approach one takes has advantages as
well as disadvantages. Informatics can still make no recommendation
concerning the practicality of keeping the 360/30 switch. In this
report certain aspects of this problem have once again been examined.
Primarily this effort has been directed to obtaining information
about pulse code modulation (PCM) systems. A great deal of time
has been spent in researching the Ti system and to outlining areas
for future study.
(U) The results of this study are documented in Section 4
of this report.
Approved For Release 2007/11/07: CIA-RDP79M00096AO00300070001-3
 W Approved For Release 2007/11/07: CIA-RDP79M00096A000300070001-3
TR-70-1169-02
Page 2-1
SECTION 2
MESSAGE DESIGN STUDY (U)
(U) The Study Team was requested to study the COINS
messages to determine whether they are effectively performing a
necessary function. This section contains the results of that investi-
gation.
(U) One authority on communications indicated that the
following types of information must be included in a system where
messages are being transmitted from one location to another:
1) The message itself (interrogations and answers
for COINS)
2) Acknowledgement receipt of message containing
results of checks for transmission errors.
3) Requests for retransmission
4) Communications lines' status
5) System recovery
6) Message status and accountability
7) Communications line control characters (such as
synchronization, start of message and end of
message characters)
8) Header information to identify message identifier,
originator (device and station), addressee, type of
message, and priorty
(U) The COINS Network and its message structure has
all of these types of information. For the most part, they are organ-
ized by message type and controlled and monitored with the assistance
of queues. The use of the various message types adequately support
the COINS functions defined in COINS Principles of Operations.
However, some problems have occurred due to procedures used in
handling the various types of messages under some operational
Approved For Release 2007/11/07: CIA-RDP79M00096A000300070001-3
 Approved For Release 2007/11/07: CIA-RDP79M00096A000300070001-3
TR-70-1169-02
Page 2-2
conditions. As, was stated in earlier studies, most of the inconsis-
tancies in handling and interpretation of the various message types
do not cause serious network problems. If unrecognized, however,
these could cause difficulty in evaluation of network performance.
If the system is to become fully operational, participating systems
should conform as nearly as possible in their processing and use of the
message types. New systems joining the network should also conform
to the same standard set of definitions. It should be noted that new
types of messages can be added to these standards and that definitions
of existing types can be changed when these changes constitute an
improvement and when the participants consent to conform in their
use and interpretation.
(U) Table 2-l.lists the various message-types used by
the COINS community. The column on the left identifies the type of
information listed above that the message conveys. The two columns
on the right indicate the roles that the switch and the participating
system have in the use of these messages. The last two types of
information (header and communications control characters) are in-
cluded in every message type and therefore have been omitted from
the table.
(U) The discussion of this section has been divided into
seven sections:
2.1 INTERROGATIONS
2.2 RECEIPTS AND RELEASES
2.3 ABORTS
2.4 ANSWER
2.5 SERVICE MESSAGES
2.6 QUEUES AND COMMUNICATION CONTROL DATA
2.7 SUMMARY
Approved For Release 2007/11/07: CIA-RDP79M00096A000300070001-3
 Approved For Release 2007/11/07: CIA-RDP79M00096AO00300070001-3
TR-70-1169-02
Page 2-3
(U)
Data
Type
Table 2-1. COINS MESSAGE TYPES (U)
Message Type
Originator
Addressee
INTG Interrogation
ANSR Answer to Interrogation
RCPT Receipt
RLSE Release
ABRT (ERROR) Abort for Parity
Errors
ABRT (CAUSE) Abort for Hardware
Errors
SRVC (READY)
SRVC (BREAK)
SRVC (PRINT)
SRVC (BEGIN)
SRVC (TRACE)
SRVC (TRACK)
SRVC (ALARM)
SRVC (CHECK)
SRVC (ALERT)
SR VC (LIMIT)
System
System
System or
Switch
System
System or
Switch
System
System
System
System or
Switch
System
Sy stem or
Switch
System
System to Switch
Switch to System
System to Network Con-
troller I
System
System
System or
Switch
System or
Switch
System
Switch
System
System
System or
Switch
System or
Switch
Switch
Network
Controller
and
Originating
System
Approved For Release 2007/11/07: CIA-RDP79M00096AO00300070001-3
 Approved For Release 2007/11/07:
1flCINryNLLyAn,~jjjj--ky'RyJDP{%t79l9M00096AO00300070001-3
TR-70-1169-02
Page 2-4
Each section discusses the informational requirements, the definition
of the message-types, the related procedures (as stated in the COINS
Principles of Operation), problems/inconsistencies encountered to
date and where applicable, recommendations for changes.
2.1 INTERROGATIONS-INTG (U)
(U) An interrogation is one of the two basic messages that
actually contains operational data that interacts with a human user.
The INTG is used to ask a question of another system in the network.
Its contents and syntax must conform to the requirements of tln
system being interrogated. Interrogations are checked for parity,
proper format and proper procedure. If no problems are encountered,
the standard sequence of message transmissions are made. Differ-
ences occur when error conditions are encountered. These differences
are included. in the discussion of ABRT messages.
(U) No changes to the INTG processing are being sug-
gested or recommended.
2.2 RECEIPTS AND RELEASE-RCPT AND RLSE (U)
(U) Receipts and Releases are acknowledgements of the
receipt of messages. In the case of receipts, it acknowledges the
completion of transmission from one node to another for any type of
message (except receipts). For all messages, the receipt also
acknowledges that the message-type and the addressee fields con-
tained recognizable values. In the case of INTG and ANSR, the re-
ceipt acknowledges that there was an acceptable level of parity errors.
(C) The RLSE message was originally intended to inform
an interrogating system (the requesting user at his terminal) that the
interrogated system has successfully received an interrogation and that
0 'N" i !T I A 1.
Approved For Release 2007/11/07: CIA-RDP79M00096AO00300070001-3
 Approved For Release 2007/11/07: CIA-RDP79M00096AO00300070001-3
TR-70-1169-02
Page 2-5
the interrogating system may release its copy of the interrogation.
The RLSE is only sent from one system to another. The switch does
not generate RLSE messages. As was stated in our previous report,
although RLSE is still used in the system, the RCPT has to a large
extent preempted its function. Systems now release their copy of
message when a RCPT is received instead of waiting for the RLSE.
Notification of the user is based on receipts at NSA, but is based on
releases at NPIC.
(C) The RCPT is used throughout the network as an in-
dication of successful receipt of a message. If a RCPT is not re-
ceived within a fixed time interval the message is retransmitted.
This time interval and related procedures differ widely within the
network. The switch now waits 120 seconds for RCPT of a message.
DIA also expects a RCPT in 120 seconds. CIA will retransmit a
message if no RCPT has been received in 50 seconds. If the second
retransmission is not receipted in 50 seconds, the message is aborted.
NPIC will wait up to 15 minutes for a RCPT. They will retransmit a
message two times after original transmission.
(C) It is recommended that the RLSE message processing
be standardized to include informing the user that the addressee sys-
tem has received the interrogation. Further, it recommends that the
Switch maintain a ledger file of interrogations for which it has not
received a release message. When an appropriate time has elapsed
(to be determined; for each system), the Switch would initiate a SRVC
(TRACE). If the result of the trace operation indicates that the mes-
sage has been lost, then the Switch should re-transmit the INTG from
its ledger file.
(U) It should be noted that the revised use of the RLSE
does not guarantee that the user will always receive a reply to the
interrogation for the following reasons:
COW3TA1
Approved For Release 2007/11/07: CIA-RDP79M00096AO00300070001-3
 Approved For Release 2007/11/07: CIA-RDP79M00096A000300070001-3
TR-70-1169-02
Page 2-6
1)' The addressee system can fail and lose its queue
including the INTG
2) The Switch can log out the ANSR because of a
queue overflow
3) The Switch can log out the ANSR after a maximum
number attempts to transmit it
4) The orginating system fails and loses its queue and
therefore cannot associate the ANSR with the user
terminal .
2.3 ABORTS-ABRT (U)
(U) Abort messages are considered to be replies by the
COINS Network because they are transmitted to the user. However,
they are triggered in one case by transmission failures and by faults
introduced in the INTG by the user.
(U) When transmitting information via communication
lines, distortions frequently occur which require that error checking
devices or procedures be provided. After the messages are received,
integrity of the message, recovery of the message and other message
protection facilities must be provided. There is frequently a mis-
understanding between message and transaction validation. In trans-
action validation, checks are made to insure that the proper format,
valid parameters, etc. are met. In message validation, which we
have chosen to call message protection, provision is made to deter-
mine that the entire message has been received properly. Several
techniques are available to insure message protection. They are:
1) Inclusion of and testing of parity bit for each
character
2) Duplication of vital section of a message
3) Send every message two times
4) Compute, send and check horizontal parity "hash
sum"
Approved For Release 2007/11/07: CIA-RDP79M00096A000300070001-3
 Approved For Release 2007/11/07: CIA-RDP79M00096AO00300070001-3
TR-70-1169-02
Page 2-7
The COINS Network only uses the first technique.
(U) There are three ABRT message subtypes:
ABRT (CAUSE)
ABRT (FAULT)
ABRT (ERROR)
(C) The ERROR subtype is used to indicate that parity
errors were encountered in an interrogation or answer. This
massage is sent in lieu of a RCPT message. Transmission errors
(detected as an unrecognizable message type) are handled by with-
holding both the RCPT and ABRT (ERROR) which should trigger a
retransmission. When the Switch has received two consecutive
ABRT (ERROR) messages for an INTG that it is forwarding to an
addressee, it will stop transmitting the INTG and forward the ABRT
(ERROR) message to the originating system. There is no limit to
the number of ABRT (ERROR) messages that the switch will send.
It does not count them. It is up to the sending system to count the
retransmissions and inform the user of the ABRT (ERROR) situation,
DIA will attempt to retransmit a message only two times. CIAuses
the FAULT message to indicate parity errors.
(U) The ABRT (FAULT) message is used to indicate an
error in the format of an interrogation. It is generated by the
addressee system. A FAULT message, if required, would normally
follow a RCPT and RLSE message.
(C) The ABRT (CAUSE) message is usually an indication
of hardware problems. It counts as a reply to an interrogation. If a
CAUSE message is generated by a destination system it will have been
preceded by a RCPT and RLSE. CIA uses the ABRT (CAUSE) if inter-
rogation queues are filled. It would seem that the SRVC (ALARM) was
intended for this purpose.
Approved For Release 2007/11/07: CIA-RDP79M00096AO00300070001-3
 Approved For Release 2007/11/07: CIA-RDP79M00096AO00300070001-3
~~ h`i1OJ ' !..'
TR-70-1169-02
Page 2-8
(Cl It is recommended that the abort-type messages
should be expanded to include other types of malfunctions such as
lost messages such as ANSR's that cannot be matched to an INTG.
2.4 ANSWER - ANSR (U)
(U) The answer, as the name implies, should be the
successful product of an interrogation.' It is forwarded through the
Switch back to the system originating the interrogation.
(U) No changes to the ANSR processing are being sug-
gested or recommended.
2.5 SERVICE MESSAGES-SRVC (U)
(U) Service-type messages are used to check and ex-
change information about the status of the Switch, the component
systems and the communication lines that connect them. There are
nine SR VC message subtypes:
1) SRVC (READY)
2) SRVC (BREAK)
.3) SRVC (PRINT)
4) SRVC (TRACE)
5) SRVC (TRACK)
6) SRVC (ALARM)
7) SRVC (BEGIN)
8) SRVC (CHECK)
9) SRVC (LIMIT)
1`u \A1) ~, I11L
Approved For Release 2007/11/07: CIA-RDP79M00096AO00300070001-3
 Approved For Release 2007/11/07: CIA-RDP79M00096A000300070001-3
TR-70-1169-02
Page 2-9
2.5.1 SRVC (READY)/(BREAK) (U)
(U) The READY and BREAK messages are used for
starting and stopping operations. These messages are not sent
from one participating system to another. They are always sent
between one participant and the Switch. The Switch then forwards
the status (READY/BREAK) to all other Systems. Once a system
is in BREAK status, it must transmit a READY to the Switch to re-
join the network. The Switch may put a system in BREAK status if
communications problems are indicated due to failure to receive
receipts for the CHECK messages it sent to the system.
2.5.2 SRVC (PRINT) (U)
(U)? The PRINT message is used to send messages to the
console operators at the Switch and the systems in the network. The
switch uses the PRINT message to communicate ALARM conditions
to participating systems.
2.5.3 SRVC (TRACE)/(TRACK) (U)
(U) The TRACE and TRACK messages are used for mess-
age tracing. If an INTG has been outstanding for an excessively long
period of time, the user at the originating system may send a TRACE
message to the addressee system. The system's response will be a
TRACK message indicating whether the message is active or there
is no record of the INTG
2.5.4 SRVC (ALARM)/ BEGIN) (U)
(U) The ALARM and BEGIN messages are used for net-
work overflow prevention. An ALARM is sent when there is a danger
of running out of buffers. The recipients are expected to refrain from
Approved For Release 2007/11/07: CIA-RDP79M00096A000300070001-3
 k Approved For Release 2007/11/07: CIA-RDP79M00096A000300070001-3
TR-70-1169-02
Page 2-10
sending any non-receipt-type messages. When a systems in the net-
work send a ALARM to the Switch, the Switch then suspends trans-
mission to that system and forwards the ALARM to the other systems.
The participating systems will suspend transmission of all but RCPTs
to the system in ALARM. status. The ALARM status is lifted when a
BEGIN transmitted from the system in ALARM status.
2.5.5 SRVC (CHECK) (U)
(U) The SRVC (CHECK) message is used to test the status
i
of the COINS network lines. It is sent by the Switch to each partici-
pating system in READY status every 120 seconds. If a system does
not send a RCPT for the SRVC (CHECK) to the Switch in a timely
manner, it is put in BREAK status by the Switch and a SRVC (BREAK)
informing the other systems is sent out. Failure to send a RCPT for
a CHECK may be due to failure of the system or to failure of one or
both of the communications lines. If a system or its receive line is
out, it obviously will not receive the CHECK message. If its out-
going line is down, it may, indeed receive the CHECK message and
generate a RCPT for it. The RCPT, however, cannot reach the
Switch. The CHECK message is intended to detect just such problems.
It shouldbe noted that the COINS Principles of Operation states that
the SRVC (CHECK) message is also available to the systems in the
network for a similar purpose.
2.5.5.1 Problems. (U) Problems have arisen because systems
have failed to send a RCPT for other reasons such as when processing
requirements of previous messages have prevented a system to send
a RCPT to the Switch in a timely manner. As a result, the system was
put in BREAK status needlessly.
Approved For Release 2007/11/07: CIA-RDP79M00096A000300070001-3
 Approved For Release 2007/11/07: CIA-RDP79M00096AO00300070001-3
TR-70-1169-02
Page 2-11
(U), The solution to this problem as well as the ac-
companying problem of determining which line is down when communi-
cations problems do exist involves:
1) Modification of procedures used at Switch for
generation of SRVC (CHECK) message.
2) Timely transmission of RCPT of CHECK messages
by participating systems.
3) Implementation of procedures at the Switch and at
participating systems to insure rapid and accurate
diagnosis of communications problems when they
do occur.
Considerable discussion of this problem has taken place during and
outside of CCIP meetings and some accord has been reached. The
panel members, therefore should be given credit for recognition of
the problem and their efforts toward its solution. What remains
to be done is to make a definitive statement of the solution with some
alternative enhancements to expedite diagnosis of problems detected
by the use of the SRVG (CHECK).
2.5.5.2 Modification of Procedures Used at Switch for Generation
of Check Messages. (U) The Switch currently sends a SRVC (CHECK)
message every 120 seconds to all active systems. The Switch should
send a CHECK message to a system only if there has been no in-
coming traffic from that system for 120 seconds. (whether active or
in the BREAK status). If the Switch does not receive a RCPT for the
CHECK message within 240 seconds, a SRVG (PRINT) message
should be sent to the Network Controller and the system operator
informing them of the condition. After two more times, the system
should then be put in BREAK status and the resulting SRVC.(BREAK)
message sent to the other systems. It would be the responsibility
of the switch operator to get in touch with the operator of the system
put in BREAK status to determine if he received the SRVC (PRINT)
sent prior to going into BREAK status. If the PRINT. was not received,
Approved For Release 2007/11/07: CIA-RDP79M00096AO00300070001-3
 u
r
.ew 00096A000300070001-3
Approved For Release 2007/11/07: CIA-RDP79Mw
TR-70-11 69-02
Page 2-12
there is definithly a problem with the line coming into the system
and possibly a problem with the line going out. If the PRINT was
received, the problem is probably in the line going from the system
to the Switch and the incoming line may be all right. In either case,
the communications people at the Switch and at the system should be
notified. When the system recovers, it can RCPT for a CHECK
message which will cause the Switch to put it in READY status and
broadcast it to the other systems.
(U) The possibility of using an ALARM instead of a
BREAK should be considered. If ALARM were used, other systems
in the network would know that the Switch is holding up all traffic for
the system in ALARM status except for RCPT's. Procedures would
still have to exist, however, to put the system in BREAK status if
the time required to correct the problem were of considerable
duration. Once the system is in BREAK status in this case, it must
send a SRVC (READY) to the Switch in order to rejoin the network.
2.5.5.3 Timely RCPT of CHECK Messages. (C) The suggested
modifications to procedures for generation of SRVC (CHECK) message
by the Switch should reduce the probability of a system being un-
necessarily put in.BREAK status. It is still incumbent upon the parti-a
cipating systems to send a RCPT for a CHECK message in a timely
manner. Processing of incoming CHECK messages should be given
priority over normal traffic if the four minute interval allowed by
the Switch for RCPT of a CHECK message cannot otherwise be met.
CIA currently processes incoming messages on a first-in, first-out
basis. CIA also responds to a BREAK message by sending a READY
message to the Switch. This should prove unnecessary if a BREAK
is only issued in the case of detection of communications problems.
coo3y B\ rfl tL
Approved For Release 2007/11/07: CIA-RDP79M00096AO00300070001-3
 Approved For Release 2007/11/07: CIA-RDP79M00096AO00300070001-3
- aH
L4 j \I L.k91,P. IUQeta.
TR-70-1169-02
Page 2-13
2.5.6 SRVG (ALERT) (C)
(C) The ALERT message is used to indicate non-receipt-
ing of messages and a possible communications failure. The Switch
currently uses a SRVC (PRINT) in place of the ALERT to indicate
such problems to operators at other systems. The Switch considers
ALERT conditions to exist when:
1) A message is unrecognizable after three times at
transmission.
2) An incoming non-INTG message has an average of
more than 35 parity errors in a segment.
3) A message is not receipted within 120 seconds of
line availability time.
The SRVC (ALERT) is not issued by DIA. NPIC will issue an ALERT
if a parity error is detected in the Addressee field of a message or
if more than 4 parity errors are detected in any segment of a message.
2.5.7 SRVC (LIMIT) (U)
(U) The LIMIT is used to report error conditions due to
oversize messages. (greater than 100 segments). The message is sent
to the system that sent the overlength message.
2.6 QUEUES AND COMMUNICATIONS CONTROL DATA (U)
(U) At times messages will be received so rapidly from
the input devices that the network cannot keep pace with the processing
of all of the messages. When this condition occurs, the switch and
systems must store the input messages either in core memory or on
mass storage devices and generate a list of messages to be processed
and where they are stored. This list is called a queue. If input
messages continue to be received in such profusion that the system
DAL
Approved For Release 2007/11/07: CIA-RDP79M00096AO00300070001-3
 Approved For Release 2007/11/07: CIA-RDP79M00096A000300070001-3
TR-70-1169-02
Page 2-14
falls further and further behind, some sort of action must be taken
or a system overload will develop. The same condition can also occur
on output.
(U) Message accountability requires that both hardware
and software facilities be used. Some examples of the software
techniques for message accountability follow but this should not be
considered a complete list.
1) Acknowledgement that the message has been re-
ceived - After correct receipt of message, system
accountable for message.
Message sequence number - by system and termi-
nal
A) Continual check to insure each number is con-
se cutive
B) Out-of-sequence or missing numbers indicate
error.
3) Ledger balancing - Maintain a ledger of input and
corresponding output messages for each transaction.
4) Message release - Reverse of 1. Responsibility
for message not released until the receiving unit
acknowledges proper receipt.
5) Previous reply - Another technique is used to account
for messages in the conversational mode. No
message count is used in this system but rather
the reply to the previous response is used as the
accountable technique. If the response is not that
which is desired, the operator may request a re-
start and the computer system must be designed
to go back to a certain point and start again from
that particular point.
(U) In COINS, a priority is assigned to messages. This
in effect means that lower priority processing will be delayed to pro-
cess the higher level priority messages. A priority queue list must
be determined for each priority level. Without priority assignments,
the first message in is the first message to be processed. This is
also true in a priority system but only within the individual priority
Approved For Release 2007/11/07: CIA-RDP79M00096A000300070001-3
 Approved For Release 2007/11/07: CIA-RDP79M00096A000300070001-3
TR-70-1169-02.
Page 2-15
level. The first message of priority 1 would be processed before
the second message with the same priority. However, priority 2
messages would take precedence over priority 1 messages even
though they might have been received at a later time. Since high
priority message.s could in effect block processing of all messages
of a lower priority if they were to occur in abundance, another con-
torl is sometimes exercised in other systems. After a certain period
of time, the priority of a message will be increased if it has not
been processed. This is done to insure that low priority messages'
are given consideration. The changing of priorities does increase
the programming complexities and core storage requirements.
Priorities may have little effect on communications especially if the
message is processed at a later time.
(U) In COINS, the message length is fixed. In other
systems, messages may be of different lengths. The objective of
the system analyst is to determine the length of the majority of the
messages to properly allocate core buffer sizes for each of the lines.
If the buffer, which is a series of core positions which have been set
aside to receive or transmit messages, is too long, core memory is
wasted. If the buffer size is too short, the message must be seg-
mented, stored either in core or on mass random storage or both
and linked to the previous segment. This requires additional computer
processing. Therefore, the goal is to derive the optimum size buffers
to handle the greatest majority of the input and output messages.
(U) No suggestions or recommendations are being made
in this area because the queueing in the Switch is undergoing a major
Approved For Release 2007/11/07: CIA-RDP79M00096A000300070001-3
 Approved For Release 2007/11/07: CIA-RDP79M00096AO00300070001-3
TR-70-1169-02
Page 2-16
2.7 SUMMARY (U)
(U) The estimated cost for the recommended changes
are summarized below. The first column identifies the section
which contains the improvement.
(U) In general the participants should examine and define
their individual procedures for handling the various message types.
The definitions should be combined with those of other participants
and inconsistencies noted. This information should prove useful
in future discussions of problems and improvements to the network.
As individual systems are modified or upgraded, they should attempt
to more closely conform to an agreed-upon standard.
commendation
R
Section
e
2
2
Inform Users that RLSE message
4 man-months
.
for interrogation has been received
each system
2.2
Create Switch Ledger File for inter-
5 man-months
rogations waiting for RLSE messages.
2.2
Enable Switch to initiate TRACE when.
4 man-months
RLSE is not received in timely time
2
3
Enlarge ABRT-type categories
3 man-months
.
for switch and
each system
2.5
Modify SRVC (CHECK) procedures
1 man-month
in Switch
5
2
Modify RCPT of CHECK messages at
2 man-months
.
the Systems
for each system
Approved For Release 2007/11/07: CIA-RDP79M00096AO00300070001-3
 Approved For Release 2007/11/07: CIA-RDP79M00096AO00300070001-3
TR-70-1169-02
Page 3-1
COINS DATA COLLECTION AND ANALYSIS (U)
(U) The Study Team has reviewed the data collection and
analysis activities associated with the COINS activity. The initial
investigation was accomplished during the system programming con-
ference at each of participating members. Subsequently, a member
of the team participated in the meetings of the COINS Test and Analy-
sis Panel. Finally, exploratory queries were prepared and processed
against the LOGGA file which contains a history of the message traf-
fic for on-line analysis.
3.,1 EXISTING PROCEDURES (U)
(U) Data collection for COINS occurs in each of the sys-
tems and in the COINS switch. There are four types of records:
1) Network Activity Log and LOGGA File
2) COINS Users Log Sheets and MTARA File
3) System Operating Logs
4) System Operator Logs
3.1.1 Network Activity Log and LOGGA File (U)
(U) The LOGGA file is the primary source for operational
statistics for the COINS Experiment. It is created from the raw data
collected in the Network Activity Log. The Network Activity Log con-
tains a record for each message processed by the network switch. It
records the time for five basic events within the switch's processing
cycle. The contents of both of these files are listed in the COINS
Principles of Operation Handbook dated 31 July 1969. Therefore it
is not necessary to repeat that data in this study.
Approved For Release 2007/11/07: CIA-RDP79M00096AO00300070001-3
 Approved For Release 2007/11/07: CIA-RDP79M00096AO00300070001-3
TR-70-1169-02
Page 3-2
(U) The Network Activity Log is updated with a record
for each message that it forwards from one system to another. At
this point, no attempt is made to match or correlate the various mes-
sages related to an interrogation.
(U) At the end of each working day, the Network Activity
Log is used to update the LOGGA File. Not only are the day's data
added to the file, but they are processed prior to being added. Three
types of records that are used only for DIA processing are deleted;
HOST, LIST and CANCE. In addition, the records are sorted by
Reference ID number so that the ABORT, ANSR and INTG can be
related and the INTG record can be augmented with the times asso-
ciated with ABRT or ANSR. This process is illustrated in Figure 3-1.
The INTG record in the LOGGA file is significantly longer than its
counterpart in the Network Activity Log. The processing into an in-
tegrated INTG record is very useful because it permits an analysis
of the ultility of system in terms of responding to requests for data,
(U) Figure 3-2 illustrates the processing required for
an ANSR record in the LOGGA file. Processing similar to that foil
the- ANSR is accomplished for ABRT, RLSE, RCPT and SRVC mes.-
sages.
(U) The recording of message lengths (measured in terms
of number of segments) requires some explanation. Each LOGGA
record has two length fields: one for the message (LNGHI) and one
for the associated reply (LNGHA). The following tabulation defines
the fields for the various message types in the LOGGA File:
Approved For Release 2007/11/07: CIA-RDP79M00096AO00300070001-3
 Approved For Release 2007/11/07: CIA-RDP79M00096AO00300070001-3
TR-70-1169-02
Page 3-3
Figure 3-1 . Definition of INTG Record in LOGGA File
TIMEX
Time INTG entered switch
RCPTM
Time RCPT sent for INTG
SWIRE
Time INTG queued for relay by switch
RCPRE (blank for DIA = ADDRE)
Time RCPT received for relayed
INTG
QETIM (DIA only)
Time INTG queued for editing for
DIA 360-SO
FIFTY
blank
TIMEX
Time ANSR entered switch
RCPTM
T Ve RCPT for ANSR sent to
a ressee
SWIRE
Time ANSR queued for relay by
switch
RCPRE
Time RCPT received on relayed
ANSR
QETIM (DIA only)
Time INTG queued for transmission
to 360- 50
FIFTY (DIA only)
Time last segment of ANSR received
from 360-50
RCPI'.E (blank for DIA = ADDRE)
Time RCPT received for relayed
_TG
QETIM (DIA only)
Time INTG queued for editing for
DIA 360-SO
TIME 2*
Time INTG queued for addressed
computer
TIMEX
Time INTG entered switch
RCPTM
Time RCPT sent for INTG
SWIRE
Time INTG queued for relay by switch
FIFTY
blank
TIME 3**
Time ANSR to INTG received at switch
TIME 4
Time ANSR to INTG queued to leave
switch
(~
r
* for ADDRE $ DIA, equals RCPTM of INTG
for ADDRE = DIA, equals QETIM of ANSR
for ADDRE D (A, equals RCPTM of ANSR
for ADDRE = DIA, equals FIFTY of ANSR
Approved For Release 2007/11/07: CIA-RDP79M00096AO00300070001-3
 Approved For Release 2007/11/07: CIA-RDP79M00096AO00300070001-3
TR-70-1169-02
Page 3-4
ACTIVITY LOG ANSR RECORD
TIMEX
Time ANSR entered
switch
RCPTM
Time RCPT for ANSR
sent to addressee
SWIRE
Time ANSR queued for
relay by switch
RCPRE
Time switch received
RCPT for relayed ANSR
QETIM (DIA only)
Time INTG queued for
editing for 360-50
FIFTY (DIA only)
Time last segment
received from 360-50
TIMEX
Time ANSR entered switch
RCPTM"
Time RCPT for ANSR sent
to addressee
SWIRE
Time ANSR queued for relay
by switch
RCPRE
Time switch received RCPT
for relayed ANSR
Q E TIM
Time INTG queued for
editing for 360-50
FIFTY
Time last segment received
fr. om host
TIME 2
Time INTG queued for
addressed computer
TIME3
Time reply to INTG
received at switch
TIME 4
Time reply to INTG queued
to leave switch
Figure 3-2. Definition of ANSR Record
in LOGGA File
Approved For Release 2007/11/07: CIA-RDP79M00096AO00300070001-3
 Approved For Release 2007/11/07: CIA-RDP79M00096A000300070001-3
TR-70-1169-02
Page 3-5
Message Type ' LNGHI LNGHA
Length of INTG Length of associated
ANSR or ABRT
ANSR Length of message N. A.
rC L.7.C,
SRVC
ANSR Length of message if >1 N. A.
ABR T DIA Blank if =1
RLSE
SRVC
(U) LOGGA provides:
1) A record of INTGs received by the switch.
2) A basis for determining system response; i.e.,
answered, aborted for fault or error, or never
answered.
3) A basis for measuring elapsed time for various
switch-type operations, such as preparing receipts.
4) A basis for counting housekeeping-type messages
such as Release and Service messages,
5) A basis for estimating total traffic handled by the
switch measured in terms of segments and mess-
ages.
6) A basis for tabulating detected transmission and
parity errors.
(U) However, the LOGGA file does not contain any data
concerning the processing performed by the Host and Addressee com-
puters. There are several reasons why this data is not available:
1 } Clocks at the various systems cannot easily syn-
chronized. Therefore elapsed time for non-switch
computer processing cannot be reliably determined,
2) Any INTG or ANSR that fails to be received by the
switch is omitted from the LOGGA file since LOGGA
only reflects switch activity.
3) Time is recorded in rather large intervals such as
half-seconds and thousandths of an hour. These are
too gross to use for many of the measurements that.
an analyst would like to have.
Approved For Release 2007/11/07: CIA-RDP79M00096A000300070001-3
 Approved For Release 2007/11/07: CIA-RDP79M00096A000300070001-3
TR-70-1169-02
Page 3-6
(U) The COINS switch has different processing paths for
its traffic as a function of the host and addressee systems. Figure
3-3 illustrates the various steps involved when a user at one non-
DIA agency queries a file at another non-DIA agency. The labels of
the time fields recorded in the LOGGA file are shown in the figure.
Figure 3-4 illustrates the processing performed when a DIA user
queries a file at a non-DIA agency. It should be noted that the DIA
computer is not involved because the COINS switch services the DIA
terminals .
(U) Figure 3-5 illustrates the processing performed when
a user at a non-DIA agency queries a DIA file. It is important to
note that no receipts are exchanged between the DIA computer and
the switch. The reason is that the transfer of messages occurs over
a high-speed adaptor line rather than over communication lines
and that it has proved to be very reliable. The system designers
have done an excellent job of defining equivalent points in the switch's
processing for the three processing paths shown in the three figures.
(It should be noted that when ANSRS becomes the DIA system, all
processing will follow the flow shown in Figure 3-3. )
(U) The DIA system programmers have prepared quite a
few RIT's for querying the LOGGA File. An RIT permits an analyst
to specify an RIT identification and the values for the selection para-
meters, rather than a complete complex query. He then receives the
results of the retrieval presented in a pre-defined format.
(U) One of the most frequently used RITs is the one
identified as LOGAR. In most cases, the analyst specifies the
dates to be encompassed by the report. The resulting report has
four parts:
Approved For Release 2007/11/07: CIA-RDP79M00096A000300070001-3
 Approved For Release 2007/11/07: CIA-RDP79M00096AO00300070001-3
User at terminal composes and trans-
mits INTG to host computer
Host processes INTG into COINS form
Host queues INTG for transmission
to switch
I
Ilost transmits INTO to the
switch
I,
Host queues INTG to wait for
related RCPT
No RCPT RCPT
within 2 received
minutes
Host receives RCPT for INTG
Host removes INTG from queue
for messages waiting for RCPTs
Host queues INTG to wait
for related RISE
Switch checks INTG for trans
mission and parity errors and
finds none
RCP M S WIRE
Switch queues Switch queues
RCPT for trans- INTG for trans-
mission to host mission to the
addressee
Switch trans-
mits RCPT to
host
Switch transmits
INTG to
addressee
Addressee receives INTG
--~
Switch queues INTG to wait
for related RCPT
No RCPT
within 2
RCPT minutes
received
Addressee checks INTG for trans-
mission and parity errors and find
none
Addressee ueuc$ RCPT for trans-
mission toSwltch
Figure 3-3. COINS Processing with Host and Addressee DIA (Page 1 of 3) (U)
Approved For Release 2007/11/07: CIA-RDP79M00096AO00300070001-3
 Approved For Release 2007/11/07: CIA-RDP79M00096AO00300070001-3
Host#DIA
Switch
Addressee # DIA
RCPRE
Switch receives RCPT for INTG
Addressee transmits RCPT to switch
Switch removes INTG from queue for
message waiting for RCPTs
Addressee queues RISE for transmissio
to switch
Switch receives RISE
Addressee transmits RLSE to
switch
I
Switch checks RLSE for
Addressee queues RISE to wait
transmission errors and finds none
for related RCPT
Switch queues Switch queues
RISE for host RCPT for trans-
mission to addressee
i
Host receives RISE
4-
1-
Switch trans - Switch trans-
mits E to mits RCPT to
RLS
addressee
host
Addressee receives RCPT for RLSE
and removes RISE from queue for
messages waiting for RCPTs
f
Host checks RLSE for trans-
mission errors and finds none
1
Switch queues RISE to wait for re-
lated RCPT
;Aiidressee prepares ANSRto INTG
Ii and processes it. into COINS fo?mat
No RCPT within RCPT
2 minutes received
ansmission to
RCPT f
ortt
Host queues
PP
Switch receives RCPT for RISE and
Addressee queues ANSR for trans-
Host transmits RCPT to switch
re moves RISE from queue for mess-
ages waiting for RCPTs
mission to switch
Figure 3-3. COINS Processing with Host and Addressee DIA(Page 2 of 3) (U)
01Q
0
W
I
cc
Approved For Release 2007/11/07: CIA-RDP79M00096AO00300070001-3
 Approved For Release 2007/11/07: CIA-RDP79M00096AO00300070001-3
? Host DIA
Switch
Addressee DIA
TIME 3
Host removes INTG from queue
i Switch receives ANSR
1"
~
Addressee transmits ANSR to
for messages waiting for RISES j
1
r
switch
Switch checks ANSR for parity and trans-
mission error and finds none
Addressee queues ANSR to wait
Host queues INTG to wait for
related ANSR or ABRT
11
Switch queues Switch queues
for related RCPT
- No RCPT RCPT
NSR for trans-
mission to host
RCPT for
addressee
within 2
minutes
received
S
i
h
i
S
Addressee receives RCPT for
H
i
ANSR
w
tc
transm
ts
witch trans-
ANSR and removes ANSR from
ost rece
ves
ANSR to host
miss RCPT to
addressee
queue for messages waiting for
RCPTs
Host checks ANSR for parity
and transmission errors and finds
none
Switch queues ANSR to wait for RCPT
Host queues RCPT for ANSR
No RCPT
within 2
minutes
RCPT
received
Host transmits RCPT for
ANSR
Switch receives RCPT for ANSR and
removes ANSR from queue for messages
Host formats and transmits
waiting for RCPTs
ANSR to user at his terminal
Figure 3.-3. COIN'S Processing with Host and Addressee ; DIA (Page 3 of 3
(U)
Approved For Release 2007/11/07: CIA-RDP79M00096AO00300070001-3
 Approved For Release 2007/11/07: CIA-RDP79M00096AO00300070001-3
Host = DIA
---------------
Switch detects that addressee is not
DIA
Switch processes INTG into COINS
form
S WIRE
Switch queues IN TG for transmission
to addressee
Switch queues INTG to wait for re-
lated RCPT
NoRCPT
within 2
minutes
I
Switch receives RCPT for INTG
Addressee receives INTG
Addressee queues RCPT for trans-
mission to switch
Addressee transmits RCPT to switch
{
'Figure 3m4> COINS Processing with Host = DIA and Addressee DIA (Page 1 of 3) (U)
Approved For Release 2007/11/07: CIA-RDP79M00096AO00300070001-3
 Approved For Release 2007/11/07: CIA-RDP79M00096AO00300070001-3
Addressee queues RISE for trans-
mission to switch
Switch receives RISE
Switch checks RISE for transmission
errors and finds none
Switch queues RCPT for transmission
to addressee
Switch transmits RCPT to addressee
Addressee transmits RISE to switch
Addressee queues RISE to wait for
related RCPT
Addressee receives RCPT for RISE
and removes RISE fro Qttcue for
messages waiting for i' I Is
Addressee prepares ANSR to INTG
and processes it into COINS format
Addressee queues ANSR for trans-
mission to switch
Figure 3-4, COINS
Processing with Host DIA and Addressee DIA (Page 2 of 3)(I)
Approved For Release 2007/11/07: CIA-RDP79M00096AO00300070001-3
 Approved For Release 2007/11/07: CIA-RDP79M00096AO00300070001-3
Host = DIA
Addressee transmits ANSR to
switch
Switch checks ANSR for parity and
transmission error and finds none
Switch queues RCPT for transmis-
sion to addressee
Addressee queues ANSR to wait for
related RCPT
No RCPT
within 2
minutes
RCPT
received
Addressee receives RCPT for
ANSR from queue for messages
wai ' s; for RCPTs
Switch transmits RCPT to addressee
Switch formats and'transmits ANSR
to user at his terminal
-Figure 3-4. COINS Processing with Host = DIA and Addressee A DIA (Page 3 of 3)(U)
Approved For Release 2007/11/07: CIA-RDP79M00096AO00300070001-3
 Approved For Release 2007/11/07: CIA-RDP79M00096A000300070001-3
User at terminal composes and
transmits INTG to host
Host processes INTG into COINS
form
Host queues INTG for transmission
to switch
Host transmits INTG to the
switch
Host queues INTG to wait for
related RCPT
No RCPT
within 2
minutes
RCPT
Host receives RCPT for INTG
I
Host removes INTG from queue for
messages waiting for RCPTs
I J1
Host Que-u-es INTG to wait for re-
lated ME
Switch checks INTG for transmission
and parity errors
Switch queues RCPT for transmission
to host
Switch performs query edit on INTG
Figure 3-5~ COINS Processing with Host DIA and Addressee = DIA (Page 1 of 3) (U)
Approved For Release 2007/11/07: CIA-RDP79M00096A000300070001-3
 Approved For Release 2007/11/07: CIA-RDP79M00096AO00300070001-3
Host-
Host receives RISE
Host checks RISE for transmission
errors and finds none
Host queues RCPT for transmission
to switch
Host transmits RCPT to switch
verit Addressee -_DIA
SWIRE (INTG)
Switch queues INTG for transmission to
addressee
Switch transmits INTG to addressee
computer
Switch queues RISE for transmission to
host
Switch transmits RISE to host
Switch queues RISE to wait for related
RCPT
No RCPT IRCPT
within 2 'received
minutes
Addressee prepares ANSR to INTG
and processes, it into COINS format
Addressee queues ANSR for trans-
mission to switch
Switch receives RCPT for RISE and re-
moves RISE from queue for messages
waiting for RCPTs
.n i xw{ I~S~C~ - JTL 1~'Pag- ry U
A
Approved For Release 2007/11/07: CIA-RDP79M00096AO00300070001-3
 Approved For Release 2007/11/07: CIA-RDP79M00096AO00300070001-3
Host # DIA
Switch
Addressee = DIA
TIME 3 =FIFTY
~I
r
H
m
t
INTG f
os
re
oves
rom queue
for messages waiting for RLSEs
Switch receives ANSR
Addressee transmits ANSR to switch
Host queues INTG to wait for re-
Iated ANSR or ABRT
TIME 4 = SWIRE,(ANSR)
Switch queues ANSR for transmission
to host
Host receives ANSR
Switch transmits ANSR to host
Host checks ANSR for parity and
transmission errors and finds none
Switch queues ANSR to wait for
I
RCPT
Host queues RCPT for ANSR
No RCPT
within 2
minutes
RCPT
received
Host transmits RCPT for ANSR
Host formats and transmits ANSR to
user at his terminal
Switch receives RCPT for ANSR
and removes ANSR from queue
for messages waiting for RCPTs
Figure 3-5. COINS Processing with Host DIA and Addressee = DIA (Page 3 of 3) (U)
Approved For Release 2007/11/07: CIA-RDP79M00096AO00300070001-3
 Approved For Release 2007/11/07: CIA-RDP79M00096AO00300070001-3
TR-70-?1169-02
Page 3-16
1) Counts of messages by message type and a total
of all segments in the system
2) Average query response time for each agency
3) Counts of interrogations by host and addressee
systems
4) Counts by host and addressee systems of interro-
gations for which replies (ANSR or. ABRT) were
received
The LOGAR processing recognizes the characteristics of the in-
tegrated INTG-type records in the LOGGA file and its message and
segments counts are appropriately adjusted. For this reason, the
LOGAR RIT cannot be used to derive counts of messages by message
length. Similarly the response time cannot be used as a selection
parameter.
(U) There has been some criticism of the COINS statistics
because all DIA-to-DIA and some CIA-to-CIA traffic is included in
LOGGA file. This occurs because the COINS switch services all DIA
terminals regardless of whether they are requesting DIAOLS or
COINS service. There is some feeling that a request from a DlA user
for data from a DIA COINS File should be omitted from the statistics,
since similar traffic at the other agencies does not use the switch and
therefore is omitted from the statistics. This criticism will disap-
pear when ANSRS replaces DIAOLS because DIA-to-DIA traffic will
then by-pass the switch. In this case, the DATANET-30 will service
the DIA terminals and will screen the traffic and only forward non-
DIA traffic to the switch. DIA traffic will be sent directly to the
ANSRS computer.
3.1.2 COINS User Log Sheets and MTARA File (U)
(U) In order to provide missing time data, the Test and
Analysis Panel created a COINS User Log sheet. Its purpose was two-
fold: one, to collect the elapsed time data as experienced by the
. Approved For Release 2007/11/07: CIA-RDP79M00096AO00300070001-3
 Approved For Release 2007/11/07: CIA-RDP79M00096AO00300070001-3
TR-70-1169-02
Page 3-18
user and; two, to acquire users reactions to COINS. Sampling pro-
cedures were created and the MTARA File was defined. The MTARA
File combines the data from the LOGGA file with the user's input
from the COINS User Log sheets. The message ID number was used
to match the two types of data. In this way, the MTARA File could
be used to compare the system performance with user's evaluation of
his results. Experience to date indicates that the users are not suf-
ficiently motivated to fill out the sheets. In addition, it was found that
the sheets that were filled out were inaccurate and frequently incom-?
plete.
(U) The MTARA File, however, continues to be useful.
After several months of test, the LOGGA has been purged of earlier
data. So now the MTARA File is the COINS history file. Queries
against it are generally processed in the batch mode. However, DIA
currently is preparing some RITs for on-line use of the file.
3.1.3 System Operating Logs (U)
(U) Each of the Coins systems maintain logs of its
COINS traffic. These are normally printed at the end of the day in
the batch mode. The listings are usually reviewed by a systems
programmer for abnormalities in the data or for answering questions
from a user. These listings are usually retained for a few days and
then destroyed. However, the switch log listings have not been de-,
stroyed. DIA has a safe filled with them.
(U) These logs serve several purposes. First, they pro-
vide the basic data for tracing an interrogation through the system and
noting the processing it encountered in the host computer. Second, it
serves as a record of the SRVC (READY) and SRVC (BREAK) messages
sent and received by the system. This assists in the tracing of the
traffic and determining causes for lost messages.
Approved For Release 2007/11/07: CIA-RDP79M00096AO00300070001-3
 Approved For Release 2007/11/07: CIA-RDP79M00096A000300070001-3
TR-70-1169-02
Page 3-19
(U) These logs will be useful in determining causes for
some of the lost messages and for determining elapsed time for pro-
cessing. However, at least one system log only records the first
segment of each message. This means that analysis of message
lengths and contents cannot be done.
3.1.4 System Operator Logs (U)
(U) Each of the systems maintain a COINS Operator Log
which chronicles the status of the COINS system during the day. It
indicates whether the system is up or down and the cause for being
down (using such categories as computer, communications lines or
software). It contains a record of the times when the system was re-
initialized (and thereby losing its queue).
(U) These logs have the same problem as other operator
logs in terms of completeness and reliability. This is because the
system is depending upon a person to remember to record the event
at the same time as it is pressuring the same person to diagnose
a fault and take corrective action. In spite of these difficulties,
operator logs are useful for gross measures of system reliability.
Approved For Release 2007/11/07: CIA-RDP79M00096A000300070001-3
 Approved For Release 2007/11/07: CIA-RDP79M00096A000300070001-3
TR-70.-1169-02
Page 3-20
3.2 RECOMMENDATIONS (U)
(U) The recommendations are devided into three parts:
1) Changes to the message formats
2) Changes to the L OGG A File
3) Additional analyses to be made
3.2.1 Changes to the Message Formats (U)
(U) Several changes to the message formats are sugge st-
.ed to provide a more complete record of the processing of a message.
The first suggestion is that a user-time be added to the header of
every message. For INTG and SRVC (TRACE) messages, this time
would be defined as the time the last character of the message was
received by the computer. For other messages, it would be defined. as
the time the related triggering action occurred (such as successful
check for transmission errors before RCPT is queued). The Study
Team recognizes that the clocks at the various systems are not syn-
chronized at present and therefore no meaningful data can be derived
from this one change. However, this problem is being discussed by
the Subsystem Managers and a solution may be available in the next
few months.
(U) The second change to the message formats is the
creation of new message type - SENT. This message would be
created by the host systems upon the completion of the transmission
of a reply to the user. Reply would be defined as an ANSR, ABRT
or a response to a SRVC (TRACE) message. The purpose of the
SENT message is to provide anew time to be added to the integrated
INTG record in LOGGA. When the record is also augmented with the
time the INTG is received from the user, (as recommended in the
previous paragraph) it becomes possible to compute, turn-around time
Approved For Release 2007/11/07: CIA-RDP79M00096A000300070001-3
 Approved For Release 2007/11/07: CIA-RDP79M00096A000300070001-3
TR.-70-1169-02
Page 3-21
for an interrogation, as experienced by a user. The data to be included
in the SENT message would be the usual header data, the same refer-
ence ID as in the ANSR message and the time the transmission to the
user began and ended.
(U) The third change to the message format would be the
addition of two fields to indicate the size of the queues at the time a
message is queued for transmission. The first field would indicate
the number of messages ahead of the subject message in terms of
priority and precedence. The second field would indicate the number
of"messages behind the subject in the queue.
(U) Another change would be a new field to be used to
identify messages that are a part of an integrated test of the system.
Such a field would simplify subsequent analysis of the LOGGA and
MTARA data.
3.2.2 Changes to the LOGGA File (U)
(U) The recommended changes to the LOGGA File are
closely related to the changes recommended to the various message
types. The primary change is the addition of new fields to the file
records:
1) User input time
2) Time user received reply
3) Size of queue higher priority
4) Size of queue - lower priority
5) System Test indicator
(U) The second change to the LOGGA File is the new
message type (SENT) which was discussed in section 3.2.1.
Approved For Release 2007/11/07: CIA-RDP79M00096A000300070001-3
 Approved For Release 2007/11/07: CIA-RDP79M00096A000300070001-3
Y'Ydy 11~L-r~,~y ~1S71+1
TR-70-1169-02
Page 3-22
(U) The third change to the LOGGA is the purging of the
DIA to DIA traffic from the file at the time of the cutover to ANTSRS.
This action will provide compatible data for summarizing COINS file
utilization data from the inception of COINS.
(U) Although it is not a recommendation, Informatics be-
lieves that it would be interesting to compare the utilization of COINS-
type files by the host organization with that of the COINS Community.
Historical data collected to date cannot provide this information.
3. 2. 3 Additional Analyses to be Made (U)
(C) The semi-annual COINS report contained several tabu-
lations of the COINS activity. One tabulation was similar to part 1 of
the LOGAR report format. The column headings were October,
November, December and Total. The row headings were Aborts,
Answers, Interrogations, Releases, and Service Messages. This is
a useful report and should be continued. It would be useful if it also
contained percentages.
(C) Two other tabulations counted the interrogations, re-
plies and non-replies by requesting agencies and by addressee agen-
cies. These two tabulations should be continued.
(C) A final tabulation was by file and sponsoring agency.
It counted the number of interrogations, answers, aborts and non-
replies for each month in the quarter. This tabulation provides the
data to determine the files' usefulness to the COINS community.
(C) During the course of the study, the Study Team has
been asked if the system could provide data to answer such questions
as:
iT JJ
Approved For Release 2007/11/07: CIA-RDP79M00096A000300070001-3
 Approved For Release 2007/11/07: CIA-RDP79M00096A000300070001-3
n
CORDE1flAL
TR-70-1169-02
Page 3-23
(C) 1) Are the 2400 baud lines adequate for COINS?
2) What is the reliability of COINS communications
system?
3) What is the average length for a COINS message?
4) What is the effect of using standard-length seg-
ments?
5) What is the effect of the current segmenting al-
gorithm?
6) Do certain files require a longer turn-around time
than others? Can the time be predicted?
(C) The answers to the first two questions cannot be deter-
mined from the statistics now being collected. Other sources are re-
quired. As to the length of COINS message; Table 3-1, Figure 3-6
and Figure 3-7 provide data summarized from the LOGGA File for
February 1970.? Table 3-1 is a tabulation of message counts by
message type and by the number of segments per message. The line
identified as blank are DIA-originated messages which were exactly
one segment long. The messages that are greater than 100 segments
(which is the COINS maximum) are DIA answers being sent to DIA
users. Figures 3-6 and 3-7 are bar-charts illustrating the data of
Table 3-1 reduced to percentages. Based upon these tables, we can
easily say that during February 1970, the average COINS message was
3. 6 segments or 554 characters in length. We can also say that 85%
of the messages are only one segment long.
(C) Table 3-2, Table 3-3, Figure 3-8 and Figure 3-9
illustrate another type of analysis that might prove to be useful in
predicting system response. Table 3-2 contains data extracted from
the LOGGA File for nine consecutive interrogations against the LOGGA
file. These interrogations were' transmitted from NSA to DIA on
14 November 1969. Table 3-3 contains data extracted from the LOGGA
File for nine consecutive interrogations against the LOGGA File.
These interrogations were input at DIA on 13 March 1970. Figure 3-8
Approved For Release 2007/11/07: CIA-RDP79M00096A000300070001-3
 Approved For Release 2007/11/07: C IA-RDP79M00096A000300070001-3
c 1, 05 1 -I)"L 1,151Al 11 11 v
TR-70-1169-02
Page 3-24
(C) TABLE 3-1. COINS MESSAGE LENGTH
(Page 1 of 5)
BY MESSAGE TYPE (U)
February 1970
f
b
Total
Number of Mes
sages by pe
er o
Num
Segments
Per Message
Number of
Segments
All -
Types
Inte
rog
r- Release
ation
blank
3395
3395
219 47
1672 1457 0
88 6889
1
1
9433
9433
211 142
0
1103
1150
575
107 289
153 25
819
273
10 243
19 1
1108
277
24 253
0 0
510
102
3 99
0 0
606
101
0 101
0 0
7
525
75
1 73
0 1
8
360
45
1 43
0 l
9
405
45
0 45
0
10
190
19
0 19
11
341
31
31
12
636
53
53
13
572
44
44
14
1512
108
108
15
285
19
19
16
400
25
25
17
527
31
31
18
322
18
17
19
266
14
14
20
200
10
10
21
252
12
12
22
396
18
18
23
368
16
16
24
144
6
6
25
175
7
7
26
338
13
13
r, r
L J,- 11
Approved For Release 2007/11/07: CIA-RDP79M00096A000300070001-3
 (C)
Number of
Total
Number of Messages by T e
Segments
Number of
All-
Abort
-Answer
Inter-
Release
Service
Per Message
Segments
Types
rogation
27
162
6
6
28
364
13
13
29
261
9
9
30
270
9
9
31 -
186
6
6
32
128
4
4
33
297
9
9
34
204
6
6
35
210
6
6
36
684
19
19
37
z22
6
6
38
152
4
4
39
195
5
5
40
40
1
1
41
123
3
3
42
756
18
18
43
473
11
11
44
132
3
3
45
45
1
1
46
92
2
2
47
517
11
11
48
240
5
5
49
245
5
5
50
0
. 0
0
51
102
2
z
52
104
2
2
53
583
11
11
. Approved For Release 2007/11/07: CIA-RDP79M00096A000300070001-3
TR--70-1169-02
Page 3-25
TABLE 3-1. COINS MESSAGE LENGTH (Page 2 of 5)
BY MESSAGE TYPE (U)
February 1970
r~11 11 dli;~ p4, 1h~
Approved For Release 2007/11/07: CIA-RDP79M00096A000300070001-3
 Approved For Release 2007/11/07: CIA-RDP79M00096A000300070001-3
MAU
(C)
Number of
Segments
Per Message
TR-70-1169-02
Page 3-26
TABLE 3-1. COINS MESSAGE LENGTH (Page 3 of 5)
BY MESSAGE TYPE (U)
February 1970
Total
Number of
Segments
54
108
2
55
220
4
56
504
9
57
114
2
58
348
6
59
1593
27
60
300
5
62 124
2
63 126
2
64 64
1
65 130
2
66 264
4
67 134
2
68 272
4
69 276
4
70 210
3
71 213
3
72 288
4
74 74
75 225
76 228
77 77
78 78
79 79
81 162
82 82
83 249
Inter-
rogation
by Typ
Approved For Release 2007/11/07: CIA-RDP79M00096A000300070001-3
 Approved For Release 2007/11/07: CIA-RDP79M00096A000300070001-3
C
TR-70-1169-02
Page 3-27
(C)
Number of
Total
Number
mber of M essages b Type
Number
r of
All -
Abort
Answer
Inter-
Release
Service
Message
egments
Segments
Types
rogation
336
4
4
85
225
3
3
86
172
2
2
89
89
1
1
95
190
2
2
96
96
1
1
97
291
3
3
100
4800
48
48
102
102
1
1
104
104
1
1
106
106
1
1
108
108
1
1
117
117
1
1
123
123
1
1
132
132
1
1
139
139
1
1
153
153
1
1
157
157
1
1
176
176
1
1
178
178
1
1
201
201
1
1
204
204
1
1
223
223
1
1
233
233
1
1
251
251
1
1
255
255
1
1
259
259
1
1
Approved For Release 2007/11/07: CIA-RDP79M00096A000300070001-3
TABLE 3-1. COINS MESSAGE LENGTH (Page 4 of 5)
BY MESSAGE TYPE (U)
February 1970
 Approved For Release 2007/11/07: CIA-RDP79M00096A000300070001-3
~ 11dbU fr..'rsx TR-70-1169-.02
Page. 3-28
(C) TABLE 3-1. COINS MESSAGE LENGTH (Page 5 of 5)
BY MESSAGE TYPE (U)
February 1970
Number of Total Number of Me s sages b T e y
Segments Number of All- Abort Answers Inter- Release Service
Per Message Segments Types rogation
276
276
1
1
283
566
2
2
324
324
1
1
332
332
1
1
405
405
1
1
411
411
1
1
547
547
1
1
557
557
1
1
644
644
1
1
675
675
1
1
796
796
1
1
924
924
1
1
`Total
54441
15140
577
2153
2947
2546
6917
vd Ail-
Approved For Release 2007/11/07: CIA-RDP79M00096A000300070001-3
 Approved For Release 2007/11/07: CIA-RDP79M00096AO00300070001-3
(C) Figure 3-6e Analysis of COINS Message Length By Message Type
February 1970 (U)
100% 1
75%
500/6
25%
4-18
2
1
1
5-924
41-924
2
1
2
1 -40
1
21-30
1
11-20
6-10
5
4
3
2
ALL ABORT ANSWERS INTER- RELEASE
MESSAGES ROGATIONS
numbers inside bars indicate the number of segments per message
SERVICE
Approved For Release 2007/11/07: CIA-RDP79M00096AO00300070001-3
 (C)
100%
90
80
50
40
7
1
Approved For Release 2007/11/07: CIA-RDP79M00096AO00300070001-3
Figure 3-7. Comparison of Percentages of Total COINS Messages
and Total Segments by Segment Length/Message (U)
February 1970
5-924
5-924
% of Total % of Total
Messages Segments
Approved For Release 2007/11/07: CIA-RDP79M00096AO00300070001-3
 Approved For Release 2007/11/07: CIA-RDP79M00096AO00300070001-3
Table 3-2, Time Analysis of Nine Consecutive INTGs Against LOGGA File
on 14 November 1969 (U)
G &
Reply
INTG
ABRT (F)
(1)
INTG
ABRT (F)
(2)
INTG
ANSR
(3)
INTG
ANSR
(4)
INTG
ANSR
(5)
INTG
ABRT (F)
(6)
INTG
ANSR
(7)
INTG
ANSR
(8)
INTG
ANSR
(9)
Time Message Entered Switch
TIMEX
14:130
14:161 14:319
14:386
14:448
14:519
14:569
14:760
14:840
Time RCPT Sent/Received
RCPTM
14:131
14:167 14:320
14:386
14:448
14:519
14:S70
14:760
14:840
Time Message Queued for
SWIRE
14:131
14:167 14:320
14:386
14:448
14:519
14:570
14:760 ,
14:840
Transmission
Time RCPT Received on
RCPRE
blank
blank blank
blank
blank
blank
blank
blank
blank
Relayed Message
Time 1NTG Queued for Edit
QETIM
14:131
14:167 14:320
14:386
14:448
14:519
14:570
1 14:760
14:840
(blank for ADDRE # DIA)
I
Time Last Segment Received
FIFTY
blank
blank blank
blank
blank
blank
blank
blank
blank
from HOST for ANSR
or ABRT
Time INTG Received at
TIME 2
blank`
blank* { 14:321
14:388
14:450
14:521
1 14:571
14:763
14:841
Switch
Time Reply Received at
TIME 3
blank*
blank* 14:399
14:465
14:604
14:686
14:725
15:010
15:178
Switch
Time Reply Queued to Leave
TIME 4
14:132
14:168 14:400
14:466
14:607
14:687
14:728
15:014
15:183
Switch
Length of Interrogation
LNGHI
1
1 1
1
1
1
1
1
1
Length of Reply
LNGHA
2
2 2
2
9
1
9
14
14
Elapsed Time (TIME
4- TIMEX)
:002
:007 :081
:080
:159
:168
:159
:254
:343
*
Fault detected by 3
60-30 rather
than 360-50
Approved For Release 2007/11/07: CIA-RDP79M00096AO00300070001-3
 Approved For Release 2007/11/07: CIA-RDP79M00096A000300070001-3
TR-70-1169-02
Page 3-32
(C)
Table 3-3. Time Analysis of Nine Consecutive
INTGs Against LOCIGA File on 13 March 1970 (U)
INTG Type Time Elapsed
Number LNGHI LNGHA TIMEX Response Response Time
FAULT
021
08.701
ABRT
.
2
08.840.
ANSR
08.945
.105
3
0
6
00.9 65
ANSR
09.070
.105
4
0
6
09.482
ANSR
09.682
.200
ABRT
09
687
152
5
0
1
09.535
FAULT
.
.
ABRT
691
09
091
6
0
1
09.604
FAULT
.
.
7
0
5
09.663
ANSR
10.092
.429
8
0
4
11.935
ANSR
12.138
.203
9
0
4
11.995
ANSR
12.241
.246
1',,~tl~T~~~
Approved For Release 2007/11/07: CIA-RDP79M00096A000300070001-3
 Approved For Release 2007/11/07: CIA-RDP79M00096AO00300070001-3
r _ :}. i, r,r .'spit y. +-r,. - T{ I
t ;i_,i_ t; i r -~ ?.i- ?{,- { :t? -. };. t- :r_..T.' _ !: 'r __ ..`~?
~
~-.-..
r , , I r
~ r !-
-.
te
`r
~,-.`r
'
~ --
--~? , r f~
1-
T
_`
~
?
~
-r
T
r`- f r -
' t TI =!
ar_ I I' { L{ I f II 1 _ .
r~ It , _I _ r
,
I
`
~--
~
F -j r
"t
+~~
:~
-'-,_
f
?, ';I_
. ,?.,~
1 - }. I r
. }
__ -,
.
.l,
+
!
f
r.
1 !
, .,
t
..-
Hours
r 7.
1
T
,
_ ..t_~
1
1
-
_
_ _.
- - rIT _1_._ _.
-?-.. l.T
;~_
?!-
_
}
-
y- -
i -
_-------
= ma
__.~,
Ela
sed
{{{
;I
~
;
I I
_
4
:{: I F
;
I
i
p
. !
!r {
~
,
.
{, ,
_
I
T
T.
Time'
~
'~. } r
I
i
~
t
I
~ k
4 .?~4
r
_ _. ~"`
7
~
'
L''
~
^?YL-
.
{ T F '.