1258 
MONITORING 
Chairman Warner: The thing I wonder 
about is, since you have identical hardware, are 
you going to be able to share any of your ef- 
forts ? It looks to me like you've got completely 
different file structures and a completely differ- 
ent monitor system. 
Mr. Uretz : Right. The basic computer moni- 
tor is the same, but the executives are different. 
I think the sharing will come at the level of the 
user programs which, with a little doctoring, 
can be made to fit. Once all the problems of this 
system design are out of the way and things are 
running, I think it's then a matter of working 
with the basic processors themselves and sharing 
those. Data, once it is ours, goes to the sec- 
ond tier, where it can be organized in almost 
any form. It's a very versatile thing and also 
tapes of data can be handed over for compara- 
tive work. But no, we'll never take a program 
verbatim from one system and just routinely 
put it on the other. But the concept and much of 
the programming can be used. 
Chairman: One thing that wasn't clear to 
me is, are you sharing core ? Do you have multi- 
ple programs in core at the same time or are 
you doing everything with swapping? 
Mr. Uretz : We are not swapping. All the ex- 
ecutive tasks, the "talking" of the terminals to 
the user, is core-sident executive and practi- 
cally instantaneous and simultaneous. The user 
processors are only called for that split second 
of time when they're needed. Then they're 
loaded in four areas available with from 1,000 
to 1,500 words. One is really the backgound 
area with 8,000 words and the processor is 
called only after all sampling has been com- 
pleted. After all the dialogue has taken place 
and when a processor is called, it goes to the 
reference file to get the calibration data informa- 
tion. It goes to the day file which stores data 
to get any data it needs. These things can be done 
very quickly because, in general, the data you 
want is still in core, it hasn't gone up to the disc. 
We have two sectors where there are 360 
words worth in core at all times and the process 
is carried out and the program executed. If a 
program is long, e.g., execution takes a minute, it 
gets into priority number, say, three, with 
other programs of that order of time and 
there's a stack kept. So a response to a user 
might get slowed down if three or four users 
want one minute processors. But the millisec- 
onds-per-use processor, which is the majority 
to date of processor I would say, gets in and 
out so fast (and ahead of the very long proces- 
sors) that you get good response time for all 
users. 
Chairman : The UNIVAC, you said, is not a 
time-sharing system, so you're just batching it 
over to UNIVAC periodically? Or are you 
sending it over as it's accumulated? 
Mr. Uretz: We send the data over once a 
day. We have some summary capabilities. We 
haven't put these in now. Right now, other than 
to give user's results for a particular test, if he 
wants to see some summary data over any pe- 
riod of time, he has to wait until we send the 
data specifically. Now, if he's real anxious, we 
can at any time initiate this, send the day file, 
and continue from there. But generally, we send 
it once a day and for the kind of operation 
we're running, this seems to be fine. People gen- 
erally aren't trying to do summary statistical 
work on-line. At least they haven't so far. 
