(Sanitized) IMPLEMENTATION EFFORT

• Document Type: CREST
• Collection: General CIA Records
• Document Number (FOIA) /ESDN (CREST): CIA-RDP78-04723A000100060001-9
• Release Decision: RIPPUB
• Original Classification: S
• Document Page Count: 13
• Document Creation Date: December 12, 2016
• Document Release Date: May 23, 2002
• Sequence Number: 1
• Publication Date: December 15, 1970
• Content Type: MF

Approved For Release 2002/06/28 : CIA-RDP78-04723A000100060001-9
15 December 1970
MEMORANDUM FOR: Deputy Chief, OCS
Implementation Effort
1. This memorandum is a comprehensive review of the
Project to date. It will attempt to show why we are
involved in 'front-ending'; the problems we have faced and
are facing; the considerations involved in making certain
critical decisions; our position now; and finally what direc-
tion the 0 project staff feels we should be taking.
2. The Business of 'Front-Ending':
Two very basic reasons for a front-end computer are
1) to provide switching and
2) to relieve the host processor of the burden of handling
communications I/O.
This latter reason manifests itself in several ways:
Communications I/O causes an increased load on the
central processor due to the number of interrupts
generated.
2) The software necessary to handle varying types of
terminals is overly-complex. Furthermore, some
types of terminals might be prohibited because of
hardware restrictions and a lack of software to
support them.
3) Communications I/O causes a proliferation of trans-
mission control units which are both costly and at
any one point in time dedicated to a particular computer.
These problem areas are present in our computer center to
varying degrees.
 6 E
11CRET
Approved For Release 2002/06/28 : CIA-RDP78-04723A000100060001-9
We now have attached to the 360/67 one 2703, two 2701's,
and three 2848's to support the communications requirement to
that machine. We expect it to increase. We are required
to support various types of devices (2260's, 2741's, teletypes,
1050's) in CP. We cannot implement other terminals unless
they are compatible with the aforementioned types without
modifying CP. We have two 2701's attached to 360/65-2 for
RJE requirements. We have a 100K RTE program in the 65-2
just to support RJE. We are supporting a remote requirement
through a 9300 in Office of Communications. We have a large,
though really undefined (estimates of 200 terminals have been
given), terminal requirement for information retrieval purposes.
There is a possible requirement to support offices remote
from the center with OCS computers (IPRD, 9300
This means more communications lines into our center.
These are the needs (some firm, other projected) that
we can see today. More importantly, though, we feel that
applications involving communications facilities will increase
drastically rather than decrease. We feel that we will have
real problems in the next five years coping with these applica-
tions unless we start preparing now.
3. What Happened:
It was decided in OCS approximately 1 1/2 years ago to take
a positive step towards meeting our future requirements by
acquiring a front-end computer. After an initial selection
process, al computer was brought in for test and
evaluation in April 1970. Somewhat before that time,
7-1was appointed project leader for the Oproject.
was also appointed to the team. Their respon-
sibilities were to represent OCS on a design and implementation
team composed of OCS and 0 personnel. This team was to:
1. Design and implement a communications interface
to OS on the 360/65-2 for the purpose of bringing an RJE
job stream into OS.
2. Design and implement a communications interface
to CP on the 360/67 to handle time-sharing terminals.
Approved ,For Release 9 '`'Ct -RDP78-04723A000100060001-9
25X1A
25X1
25X1A
25X1A-
 Approved For Release 09
25X1A
tl
'i.
A part of the system (hardware and software) that0 25X1A
provides to its customers is a program called 25X1A
which is designed to run in OS as a type IV
SVC. This is an access method which provides programs running
in OS macros to communicate with the processor. 25X1A
Through either a misunderstanding on the part of OCS in the
initial selection or a misrepresentation by (it has never 25X1A
been clear which was the case) it was the impression of OCS that
Owould work for CP. Very early in the design effort it
developed that 0 would not work for CP and that indeed the
interfacing of Il and CP would be a tremendous problem.
The design and implementation effort, therefore, became two
distinct problems, that of interfacing to OS and that of inter-
facing to CP.
4. Interfacing to OS:
It was decided to utilize VC in OS to bring in
an RJE job stream. After considering the problem of how to
use the SVC, it was decided to implement the interface on an
OS reader and writer basis for the following reasons:
1. The OS RJE program required 100K bytes of
resident core which we felt was unnecessary.
2. The reader/writer interface provides more flexi-
bility for decision on what type of devices could be used
as RJE terminals.
3. The reader and writer interface would require
less core than OS RJE since they are smaller and are
transient.
25X1 A
4. It was felt the reader and writer interface would
be less version dependent.
Accordingly, work was started on this type of interface.
Detailed RJE specifications were drawn up jointly by
and OCS personnel with final specifications reviewed, agree
upon, and completed by mid-September 1970. A proposed
25X1A.
 Approved For Release 20 g &-~X78-04723A000100060001-9
25A
1A
schedule for software codin , debugging and testing was drawn
up and submitted Slippage occurred for the follow-
ing reasons:
1. Problems were encountered by in generating 25X1A
a Network Control Program (NCP) to meet the RJE specifi-
cations.
2. There were eight major hardware problems
identified.
25
1A
3. There were unanticipated problems in the complexity
of thenterface in the OS writer,.
25JX1A
2 X1A
4. The timing problems using= under CP made it, 25X1A"
necessary to do all our testing on block time with a dedi-
cated machine. This greatly cut down the available number
of test opportunities.
5. The FMSAC 2780 terminal was available only on
a sporadic basis.
6. There were bugs in code. For example, 25X1 A the BSC handler was never proper y tested by I 25X1A
before delivery.
nation of both.
7. There was a lack of knowledge about the proper
2780 conventions. (This problem complicated pin-pointing
bugs in the BSC handler. )
8.
is very unstable. (An IPL of OS is necessary
after running each test program to insure stable conditions).
At present (11 Dec 70), the interface
b
is still
, not complete
ecause of some minor problems in the
system.
25X1 A.
1t
The test period indicates that the present ONCP inter-
~
25XIA
face is too unstable for the OCS environment. Solutions include
re-writing thelNCP interface, a new interface or a combi-
~~ iii'
-.-Ap.provedFnr R e_2 0 /06/28 ; CIA-RDP78-04723A000100060001 9
l + r J /~ {(
f t t
OJI.
MaCIREll
 ECRET
Approved For Release 2002/06/28 : CIA-RDP78-04723A000100060001-9
25X1A
25X1A
5. Interfacing to CP:
When it was learned (early June) that 0 could provide
no ready software to interface to CP, we began exploring alter-
natives to solve the problem. Some of the ground rules we
established were that it should not cost CP any increase in
communications overhead and that modifications to CP should be
kept to a minimum. We did not want to make CP any more
version dependent than it already was. The two alternatives
that emerged from our study were these:
1) Owould build a new Computer Interface
Adapter (CIA) which would allow thelI computer to
be able to respond to 256 unique addresses on the OS
multiplexor channel. This would enable software in the
computer to emulate any 270X transmission control
unit with no impact on host computer software, i. e. ,
existing channel programs within CP (or OS) would not need
to be modified. We placed a 95% chance of success on this
method. It would, however, cost OCS an additional
$50, 000 to $100, 000.
3 to 4 man-months would be necessary on the 0 side.
2) Software in the host computer system would have
to be modified to communicate with the I computer
over the existing CIA. This was in fact the method of
attack we were already employing in the interface to OS.
However, there we had the advantage in thatIwas
already written. In CP we estimated the software modifi-
cations would take 6 to 9 man-months. In addition, another
We recommended alternative l above. It would result in a
common interface to any IBM machine which has a communica-
tions requirement and can support a 270X, and it would have the
least impact on existing software. We further recommended a
change in the contract for both money and time allocations to
reflect this recommendation.
While these activities were being carried on (OS interface
testing and evaluating CP alternatives) many discussions were
held with OCS management to review the decision to acquire
Approved For Release 2002/06/28: CIA-RDP78-04723A000100060001-9
25X1 Ai'y'
25X1A
l;~. ji
25X1 A(;l
25X1
 Approved For Release 2
RDP78-04723A000100060001-9
initially, Some people in OCS were disappointed in
performance and the company's financial position.
The objections were very well stated in a memorandum to Acting
Director of Computer Services, subject: IF dated
8 October 1970, written by then Ch of of Operations
Division. The arguments will not be summarized here. After
much discussion, a recommendation was made byl
to re-negotiate the contract and continue developmental work
E -1 The contract was re-negotiated byl
and it called for the implementation of our previous recommen-
dation. Some hardware initially contracted for was turned back
to in order to pay for the construction of a new-CIA. As
a result the project is still under its initial funding of $340, 000.
6. Projected Plans:
The projected plan is summarized in an attachment to this
memorandum. Although our new design goals under the revised
contract are geared to present requirements of interfacing
h
e
to the 360/65's using OS and the 360/ 67 using Cl-, t
ted advent of future computer technology with parallel
expec
processing and an increased sensitivity to interrupts lends added
weight to the concept of data concentration. In our proposed
tasks we have, therefore, tried to be as flexible as possible in
providing for both line and data concentration as well as 270X
transmission control unit emulation in the front-end processor.
In the proposed systems design, both the capabilities of 270X
emulation and a0like interface (providing concentration
capability) will be given equal weight. We will implement both
in our design if it is at all possible.
In general, the 0 development task as proposed has
three major breakdowns (see attachment):
1) Preliminary design - 15 Dec 70 through 30 Jan 71
2) Final detail design - 1 Feb 71 through 30 Apr 71
3) Writing, testing - 1 May 71 through 29 Feb 72
In the preliminary design area, we are attempting to define
as many general system requirements as possible. One of the
most important questions will be whether it is feasible and
practical to do both 270X emulation and a= like interface
j X11
25X1 Ai,;
25X1 A i
25X1 A ''
lf,i
25X1 k?
25X1A
 Approved For Release 2002/06/28 : CIA-RDP78-04723A000100060001-9
25(1 A
_2 jX1A
i
simultaneously. Another possible requirement will be message
switching. We consider the ability to communicate among the
various computers in our center to be an immediate and import-
ant requirement. We will consider the feasibility of doing rolling
and scrolling in the front-end processor. The 2260 code
(assuming we still have 2260's) could be removed from CP. If
we have some other CRT devices, the fact that the front-end
could roll and scroll for them might mean that we could buy less
sophisticated CRTs. Security requirements as well as recovery
and/or backup will also be explored.
In the final design phase, we will translate the general
requirements arrived at into detailed systems design. Modules
to be changed will be identified, requirements in detail will be
specified, flow charts drawn and a time schedule for the third
phase will be developed.
At various points in phase 1 and phase 2 we will formally
review our design with as many knowledgeable people from
Das possible. Arrangements have already been made
for 0 to provide consulting services. Furthermore, time
has been left for formal education on Osoftware in phase I.
The third phase will be the actual writing and testing of
software. We also hope to validate at this time many of the
design goals which came out of phases 1 and 2. We do not
believe that we will be exactly right in either the philosophy of
the system or its details. What we do hope to accomplish is
to contribute heavily to OCS's experience and body of knowledge
in .front-ending as well as providing some operational capability.
Some of the more detailed changes which we can foresee
at this time follow. Generally they fall in three areas:
1) Computer interface-adapter software to provide
270X emulation as well as a =type interface.
2)
systems tuning to enhance throughput.
3) Dine terminal handlers.
lVa
Approved For Release 2002/06/28 , CIA-RDP78-04723A0001000600001-9 1J;Jr
25X'GA
~1 ! (s
~i
yy ~I~
 Approved For Release 2002/06/28 : CIA-RDP78-04723A000100060001-9
Computer Interface Adapter (CIA) Handler
This handler, which is a part of the Osupervisor,
will either be completely rewritten or a module will be added
to it to simulate those functions which are now handled by 270X
control units. Some of these functions are:
* Cyclic Redundancy Check, Vertical Redundancy Check
and Longitudinal Redundancy Check
* Status Responses
Initial Select
Commands
ll~
Approved For Release 20$2106/28 : CIA-RDP78-04723Al0001,0446,9, p1 9,. , ~.
7
* Line Addressing Capability
* CCW Analysis
Commands
In addition, the handler will be modified to distinguish the 270X
requests from the~ike requests. (like requests being
those which allow the host computer to concentrate data and
block messages into one transmission across the channel opera-
ting in subselector rather than multiplexor mode. Testing of
current=access method in the 360 indicates that present
provided 360 SVC and0 NCP are too unstable
for operational use. Proposed modifications would include modi-
fications to the 360 SVC to make it look more like a standard OS
access method, and to simplify channel checking procedures
back and forth across the channel, reducing interrupt overhead
and removing stringent packet restrictions and data. restrictions.
Alike access method added to OS would present a fairly
comprehensive programming effort because interrupts from
more than one line presented as data from II would have
to be presented separately to OS so that they could be properly
posted and handled.
A number of modules in the Native Processor Support
Routine (NPS) as part of NCP would have to be modified or re-
written to properly interface with the new channel requirements.
For the Olike interface, it is conceivable that the Background
J ~, 'i t
rI
25X1A';J
+J+II I'I
25X1 A ii'
25X1A
 Approved For Release &i"%&-IDP78-04723AO00100060001-9
Timing Routine (BGD) and Queue Update Routine (QUPD) would
have to be modified to provide the ability to generate interrupts
in order to transmit messages in large bursts to the host com-
puters on either a time or size basis. For conversational type
terminals with core queued messages. the Selection Routine which
would be modified to scan core for full buffers to be transmitted
to the host computer, would also.incorporate some facility for
interfacing to the CIA handler for purposes of transmitting blocks
of messages when N number of buffers are full for any given computer.
Core Queue Management modules would also be modified.
{
25j A
ltd. T
Approved For Release 2g02/06/28 s ~(i~Qd a 06po01"-q.
Prior to final systems specification, it will be necessary to
determine the level at which the line handlers must operate and
interface to NCP. This requirement is generated because of the
need in conversational systems to not generate a new I/O command
until the current I/O is actually complete at the terminal. In
general, a host computer initiated I/O is complete once it is
successfully transmitted across the channel to I but in
terms of the problem program, it may not be complete until it
has been transmitted to the terminal, where in a store and for-
ward application, the I/O is obviously complete as soon as it is
Systems Enhancements to Improve Throughput
A throughput analysis of the current configuration and system
has shown that a number of modifications must be made to the
system in order to provide the kind of throughput necessary to
support our projected number of at least 200 terminals. This
analysis considered conversational messages but did not consider
RJE messages. RJE messages, because of their size, require
an undetermined number of disk accesses. NCP currently
handles data internally on a byte basis. We propose modifying
NCP to process I/O on a block or word basis. Current NCP
design provides for either core-queued or disk queued messages,
but not both at the same time. We recognize the need for both
types of queuing, i. e. , to core queue conversational type
terminals, which have predictable maximum messages sizes, and
to disk queue RJE type terminal messages, with varying message
sizes. Core queuing is a necessity. if.we.are to achieve the
projected throughput. The following is an example of the types
of throughputs currently attained and attainable in the system
with modifications:
4is`
successfully received by
 4) Selection Routines to allow scan to select messages
for transmission from core and from disk queues,
5) The Queue Update routine, which appends or deletes
sectors as messages are queued and dequeued,
6) Line buffer handling modules must be modified to
provide block or word processing.
Approved For Release 2002/06/28 : CIA-RDP78-04723A000.1.00060001-9
Approved For Release 20/OS'4-1 P78-04723A000100060001-9
* Standard NCP with 6108 (slow disk) queuing on I/O
allows 18 mega/sec.
* Standard NCP with core queuing on input and 6108
disk queuing on output allows 28 msgs/sec.
* NCP with block or word processing, core queuing
on input, 6108 disk queuing on output allows
32 msgs/sec.
* NCP with block or word processing and.core queuing
on I/O allows 40 msgs/sec.
These figures approach maximum throughput capability of
a general purpose communications software package with the
scope of NCP. It is probably possible to increase throughput
capability by a special purpose package tailored to our needs.
A portion of our development on this aspect will be the analysis
of throughput capabilities of proposed modifications to system.
Another study will consider the maximum achievable capabilities
through complete rewrite, tailor-making a package to achieve
maximum capability of hardware.
Modules which have to be modified or rewritten are:
1) The Mass Storage Queue modules to allow both core
and disk queuing,
2) The Core Queue Buffer Management Routine,
3) The queuing modules which are entered upon
scheduling transmission to allow NPS to provide messages
from either core or disk,
 Approved For Release 2=- P78-04723A000100060001-9
Another systems enhancement would be the ability to select
messages on a priority level for a limited number of lines. Cur-
rently, the priority selection scheme' requires priority selection
for all lines if it is selected at all. In the case of user input from
terminals, it might be nice to allow the user to input more than
one line, such as when he is creating a new file, wherein his
message would have to be disk queued rather than core queued
while in input mode. Modifications would have to be made to
a number of blocks and routines having to do with queuing so
that the status of a terminal can be changed from conversational
to nonconversational (disk queued). Current systems design only
permits dyntabs, which describe the lines and line groups, to be
modified at IPL time. We recommend that this be changed to
dynamic modification through the operator console. This would
probably entail the addition of a new operator function to the
Command Module which is the module which accepts commands
from the console and interfaces to the rest of the system.
Line Terminal Handlers
During the design period, we will endeavor to determine the
types of line handlers which must be included in the system and
make provision for providing them.
It must be stressed that these time esti crates and dates are
only estimates and subject to change as conditions develop.
25X1A
 Approved For Release 2
Emm
&WP78-04723A000100060001-9
ATTACHMENT
25?C1A
1. 15 Dec 70 - 30 Jan 71 Preliminary Design
A. Required 2703 capability
on the Tim
B. Preliminary consulting
25X1 A 0
Sharing System and0 on NCP (Dec 14-18)
C. Formal Education (Jan 4-9)
D. Block Processing
E. Core Queuing
25X1 A F. Feasibility of a like Interface in Conjunction. with
2703 Emulation
G. Preliminary System Requirements for:
Store and Forward
Message Switching
Real-Time Services
Roll and Scroll
Security Requirements
Recovery or Back-up Requirements
2. 1 Feb - 30 Apr 71 Final Detail Design
A. MA/CIA Handler and Interfaces
B. Modifications to Native Processor Support (NPS)
C. OCIA -- MA/CIA Relationship
D. Block Processing
E. Core Queuing
F. Level of Operation and Interfaces of Line Handlers to the
Remainder of NCP
G. Other: Communication Interfaces
9300 Interfaces
ASP Interfaces
H. Final Detail Specifications for Each Module (New or
Modified)
I. Time Schedule for Next Phase
3. 1 May 71 - 29 Feb 72 Code, debug, comprehensive system
testing, experimentation and valida-
tion of design philosophies and re-
quirements.
e
 App
App
EN E WILL SS 1
OFFICIAL ROUTING SLIP
TO
NAME AND ADDRESS
DATE
INITIALS
DDS / IP C
2
3
4
5
6
ACTION
DIRECT REPLY
PREPARE REPLY
APPROVAL
DISPATCH
RECOMMENDATION
COMMENT
FILE
RETURN
CONCURRENCE
INFORMATION
SIGNATURE
Remarks :
The attached provides a status report on the
communications processor. Pardon
the jargon, but the subject is rather technical.
Summary: We have much work to do to get
0 into productive use.
FOLD HERE TO RETURN TO SENDER
FROM: NAME, ADDRESS AND PHONE NO.
DATE
ove
D/OCS
F>es~a el~8 [4D02/ 6/2 :dt~01~
12/ 30/70
040MBe
FORM NO. 237 Use previous editions
1-67
1-0
25X1