SAFE TERMINALS
Document Type:
Collection:
Document Number (FOIA) /ESDN (CREST):
CIA-RDP84-00933R000500090024-4
Release Decision:
RIPPUB
Original Classification:
K
Document Page Count:
6
Document Creation Date:
December 15, 2016
Document Release Date:
October 31, 2003
Sequence Number:
24
Case Number:
Publication Date:
February 25, 1981
Content Type:
MF
File:
Attachment | Size |
---|---|
![]() | 294.23 KB |
Body:
Approved For Relee 2003/12/18 : CIA-RDP84-00933R00O0090024-4
It
25 February 1981
STAT
STAT
STAT
ILLEG
IB
ILLEGIIB
MEMORANDUM FOR: Deputy Director of Data Processing
Chief, Consolidated SAFE Project Office
Deputy Director for Processing
FROM: Bruce T. Johnson
Director of Data Processing
SUBJECT: SAFE Terminals
1 Attached is a copy of an informal memo from
S// /- `_
STAT
to Bill Hart raising some concerns about our commitment to the
Delta Data. I could have wished that he had elected to bring
these concerns directly to us, but Bob is still feeling his way
in his new role and when he asked Bill how he ought to proceed,
Bill suggested this approach. I urge you not to invest any
energy in questioning the approach but instead concentrate on the
concerns he expresses.
2. It seems to me that as far as SAFE is concerned, the die
has been cast. What has apparently failed to recognize
is that TRW's design called or three levels of hardware starting
with a smart terminal. Whether that terminal be a Delta Data or
brand X, its characteristics would be an integral part of SAFE.
Now that we have moved as far as we have in the direction of the
Delta Data, I believe change must inevitably delay the SAFE IOC...`.
I would like to have an estimate of the extent of that delay but
I believe it would be considerable.
3. I I concern about the availability of externally
developed software is legitimate and has been the subject of
;mp.t discussions here in ODP. In this, as in so many other
things, we end up making judgments about the trade-offs.
4. We are scheduled for a meeting on the subject with Hart,
on Thursday afternoon, 26 February at 1300
hrs. I suggest t at and someone from CSPO STAT
accompany me to the meeting an am open to suggestions about
who else should go. I would like your comments, either orally or
written, before I go to that meeting and I suggest that those who
i
a on
will be attending with me join me for lunch in the cafeter
hat we may talk about the meeting immediately
b,lunch is not convenient, please advise.
Att kppr$ved For Release 2003/12/18 : CIA-RDP84-00933R000500090024-4
J61, nruce T. Johnson
Bruce T. Johnson
ILLEGIB
Approved For Release 2003/12/18 : CIA-RDP84-00933R000500090024-4
O/D/ODP/B.Johnson:ee/25 Feb. 81
Distribution:
1 - ea adse
1 - ODP Registry
2 O/D/ODP
ILLEGIB
Approved For Release 2003/12/18 : CIA-RDP84-00933R000500090024-4
Imr, "of
ROUTING AND TRANSMITTAL SLIP
PC) GF.3 }31
building, Agency/Post)
1. EO/DDA
~X_
Date
FE
n
4V .IG
~'
2
ADDA
- 2-
s.
3.
; D/ODP .
..
!3.
Action
File
Note and Return
Approval
For Clearance
Per Conversation
s Requested
For Correction
Prepare Reply
Circulate
For Your Information
See Me
P OR mment
investigate
Signature
Coordination
Justify
REMARKS DDA 80-0394 Subj: RFP of SAFE Terminals
2. to 3.
I have tentatively set up an appointment for
you, Terry and Bob to meet with me on the attached
memorandum for 1330, Thursday, 26 February.
Please confirm that you can attend and feel free
to bring anyone you would like to have attend. The
meeting will be in my office.
./
17) ~7_ I"
STA~OT use this form as a RECORD of approvals, concurrences, disposals,
clearances, and similar actions
Post)
n ormatlon Handling Systems
STn-Architect
l02
Room No.-Bldg.
7C! 8 i)^
Phone No.
Q
OPTIONAL FORM 41 (Rev. 7-76)
Prescribed byy GSA
FPMR (41 CF1) 101-11.206
Distribution:'.
Original YRS - Addressee w/att
T- D/ODP w/att
1 - C/BLS w/att
1 - DDA Subject Watt
1 - DDA Chrono w/att
1 - RCS Chrono w/att
Att: Memorandum to ADDA from IHSA dtd 20 Feb 81
Subj: RFP for SAFE Terminals
P84 -00 . 000500090024-4
B1.
DD' .;z 1stry
1So 039
Approved For Release 2003/42/18 : CIA-RDP84-00933R000500090024-4
Approved h j'Release 2003/12/18: CIA-RDP84-0093, R0005000ftU2 WB
NOTE FOR: William N. Hart
Associate Deputy Director of Administration
STAT FROM:
Information Handling Systems Architect
1. Talking-,Viith Terry 'recently, I learned a e RFP for the
e a
here
ar
SAFE terminals may go out shortly. I and conceL11CU. T
number of serious questions that I have about the Delta Data 7260
that lead me to wonder whether we are ready to, make this long-term,
expensive commitment.
Although the terminal concept appears to be right-on with
respect to our needs, the development seems to require a far greater
investment than was anticipated and duplicates mature technology now
emerging in the private sector. The imminent SAFE procurement
appears to lock us in to a specific terminal, a unique terminal
protocol, and a unique allocation of functions between host systems
and terminals for probably the next 10 years or so. This-uniqueness
appears to me to commit the Agency to the development of all the
needed terminal functions. I am concerned that that is a far bigger
investment than we anticipated and of doubtful affordability. Even
if we could afford it, the current status and recent history
indicate that we are likely to end up having an all-up capability
much later than we would using commercially available equipment,
modified to fit our environment.
2. The 7260 is a two-sided, flexible configuration system,
with a mother board that can accept additional cards to perform a
variety of functions. It is thus expandable to perform a wide
variety of processing and interface functions.
The version to go into BLOCK I of 'the SAFE (234 terminals)
seems to be a "bare bones" version. As such, it is relatively
economical--slightly less than $6K.per unit, excluding RDT&E. While
this cost looks quite attractive relative to the functions it
provides, it is balanced by the rather high price of add-ons that
are almost certain to he procurred, e.g., $6K for a dual floppies
system needed to support most independent processing operations. I
suspect that an all-up 7260 is likely to gross out at about $20K,
and extensive use of a retrofitting approach would increase that.
Approved For Release 2003/12/18 : CIA-RDP84-00933R000500090024-4
Approved F'Release 2003/12/18: CIA-RDP84-00R000500090024-4
3. Specific questions that I have include the following:
A unique OS was developed for the terminal, rather than
applying a standard microcomputer OS like CP/M. The
result is that the great community of applications
packages and languages hosted by such a common
OS--including word processing (WP), graphics, and
compiled HOLs like COBOL, FORTRAN, and PASCAL--cannot be
applied. We have to develop any such packages users
want, as well as application packages such as statistical
analysis and linear programming packages.
? A unique form of BASIC has been developed for the 7260.
It has some special primitives that are attractive for
our environment, but has been described by one trial user
as "arcane." It appears to me that we,,are unnecessarily
committing ourselves to the support of a language.
e Although graphic symbols and pictures are included, a
graphics capability will not be immediately provided. I
question very strongly fielding a smart terminal that
does not have a graphics,capab_i_lity. A position. that
such a capability can be added later, if needed, seems
very risky to me, and again commits us to expensive,
unique in-house developments duplicating what is commonly
available in the commercial arena. From what I can see,
a graphics capability is needed now and should be in the
initial version of any procured terminal. (The fact that
users may not have stressed such a capability two years
ago is irrelevant. NPIC, for one, needs a graphics
capability now. I suspect NFAC does also.)
s Of the 64K of core memory on the processing side, all but
12K has been consumed by operational software. Since 12K
is quite limited, and generally inadequate, there is talk
about adding another 128K to the processing side. This
would involve further RD&E investment for a new card,
however, and modifications to the OS, of unknown scope.
? It was required that the 7260 emulate the DD 5000 in
hardware. I don't know how readily modifiable this is,
but it seems to me a modifiable emulation is needed.
This would permit us to modify protocol to another
standard in the future, should we wish, avoiding having
to write off the terminals prematurely because of a
system reconfiguration..
4. In thinking about alternatives and the realities of our
environment --like meeting our terminal GFE Schedule to TRW on
SAFE--there are a number of factors to consider. I believe that:
Approved For Release 2003/12/18 : CIA-RDP84-00933R000500090024-4
Approved F elease 2003/12/18 : CIA-RDP84-009 8000500090024-4
? The immediate terminal application will be for WP, much
of it not under SAFE, and analyst file manipulations,
both under VM and SAFE with its SUL. A processing
capability is not needed in the Block I SAFE.
e There is a need within the near term for both BASIC
programming support and graphics. These two functions
require a full system capability, i.e., a special card
and dual floppies.
? The technology trend in large organizations is to provide
distributed processing. I think that need can be met
over the next five to ten years with a smart terminal
configured to support compiled HOL processing, graphics,
and numerous, standard applications packages. If we do
not meet the distributed processing need with smart
terminal processors, I fear we will be forced into much
more expensive and managerially difficult solutions
involving distributed minis..
The consequence of these factors is that a mix of terminal
capabilities is a feasible and more economical solution than buying
all in the most complete configuration needed. The flexible
approach is the SAFE plan, with some level of currently unplanned
retrofitting to develop the needed, more sophisticated capabilities.
The terminals could all be from one source, as planned by SAFE, or
from more than one, as long as they are functionally compatible
(including protocol). The only problem associated with different
sources of terminals that I see is dupl-ication- investment in
functionalities and protocols to fit our environment. I do not
believe that these are likely to be significant as compared to the
benefit of being able to piggy-back available technology, as long as
these are only a limited number of different sources.
Approved For Release 2003/12/18 : CIA-RDP84-00933R000500090024-4