Did KeyKOS allow organizations to communicate with each other?

15 views
Skip to first unread message

ArndtS...@freenet.de

unread,
Sep 6, 2021, 2:10:40 AM9/6/21
to cap-talk

I've read that Tymshare customers could buy computing time, and then distribute virtual credits among the meters of their employees/users accounts, who could then log in and use the system.

One of the reasons KeyKOS was invented was to *prevent* organizations from accessing each others resources, but did the OS still enable people/programs to communicate across organizational boundaries?

I'd like to learn how this worked in practice, and technically.

Was there a mailbox or even a globally accessible dataspace with unique names where capabilities could be shared? Say, Airline A communicate with Airline B?

- Arndt

Bill Frantz

unread,
Sep 7, 2021, 4:06:57 PM9/7/21
to cap-...@googlegroups.com
KeyKOS nee Gnosis was designed to solve the problem of
cooperation between competitors in a computer utility. The
canonical example was: We have two chemical engineering
companies. One has a new chemical they want to analyze. The
other has a not new analysis program that they don't want to
release, but are happy to rent access. We want to provide OS
levels of assurance to both companies that the analysis program
can't be stolen, and that it can't exfiltrate the details of the
chemical it is analyzing. We also wanted to support a number of
ways of charging for the program's use.

On 9/5/21 at 2:10 AM, ArndtS...@freenet.de
(ArndtS...@freenet.de) wrote:

>I've read that Tymshare customers could buy computing time, and
>then distribute virtual credits among the meters of their
>employees/users accounts, who could then log in and use the system.

Remember that KeyKOS was never used by timesharing customers.
It's actual use included acting as a communication interface
between VM/370 and Tymnet. This interface included IBM 3270
terminal simulation using "glass teletypes". All of the uses
didn't make serious use of the meters which permitted computer
time use policies.


>One of the reasons KeyKOS was invented was to *prevent*
>organizations from accessing each others resources, but did the
>OS still enable people/programs to communicate across
>organizational boundaries?

Yes. A capability could be shared across organizational boundaries.


>I'd like to learn how this worked in practice, and technically.
>
>Was there a mailbox or even a globally accessible dataspace
>with unique names where capabilities could be shared? Say,
>Airline A communicate with Airline B?

An administrator could setup a shared directory (record
collection). Any of the entities sharing it could read and write
capabilities and data. They could also make derived capabilities
with fewer privileges e.g. read-only, and quite usefully, limit
the ability to list the directory. This last restriction has the
practical effect that you can only access a capability if you
know it's name.

Cheers - Bill

---------------------------------------------------------------------------
Bill Frantz | Re IOT: "How many access control systems
does it take
www.pwpconsult.com | to change a light bulb?" - Dean Tribble

ArndtS...@freenet.de

unread,
Sep 7, 2021, 6:07:09 PM9/7/21
to cap-talk
Thank you very much Bill :)

>All of the uses didn't make serious use of the meters which permitted computer time use policies.

I previously thought that this was the main bottleneck, but it seems that the ability to trustlessly share code and data had been more important!

Could you elaborate a bit on how resource allocation in terms of *memory* worked?
If I remember correctly, the idea of allowing and metering dynamic memory usage was in the air, but not used in practice, where customers bought fixed allocations instead (I suppose not for KeyKOS itself as well, but by the machines controlled through it?).

I think I'm still not clear about what the OS was used for in practice (by what you said it seems only special use cases and as a communication interface to the actual computers used by customers), and how it was to program for it, how many domains were used, and how complex each was.

Were there tools to (visually?) monitor the capability network/metering hierarchy?

This was all so way before my time that I have no intuition whatsoever about it.

> the problem of cooperation between competitors in a computer utility

Are there companies still today that provide this service? A trusted, non-public computing intermediary?

- Arndt

Bill Frantz

unread,
Sep 7, 2021, 10:35:36 PM9/7/21
to cap-...@googlegroups.com
On 9/7/21 at 6:07 PM, ArndtS...@freenet.de
(ArndtS...@freenet.de) wrote:

>I previously thought that this was the main bottleneck, but it
>seems that the ability to trustlessly share code and data had
>been more important!

I think the ability to build applications where there were a
number of Tymnet circuits working into a single program was one
of the wins. All the other Tymshare systems assumed one circuit
was a single user.

Tymshare had a high-end tax preparation service which I vaguely
remember used the system in this kind of invisible, back-end maner.

After Key Logic split off from Tymshare/MacDonnell Douglas, we
used the system for software development. We had a CP simulator
which permitted us to run CMS from VM/370 in a KeyKOS domain. So
we had a very usable development system without having to create
it from scratch, or port it from somewhere else.


>Could you elaborate a bit on how resource allocation in terms
>of *memory* worked?
>If I remember correctly, the idea of allowing and metering
>dynamic memory usage was in the air, but not used in practice,
>where customers bought fixed allocations instead (I suppose not
>for KeyKOS itself as well, but by the machines controlled
>through it?).

I don't remember the details. What we were aiming for was
something like the system we had developed for our VM/370
service. Basically we charged for working set and page transfers
in and out of the working set. It had the advantage for the
customer that sitting idle was much cheaper than the older
system that charged for the memory side of the virtual machine,
whether you were using it or it was sitting idle.

The trick was to make the memory charges independant of the
memory load on the system, so the costs to the user were repeatable.


>I think I'm still not clear about what the OS was used for in
>practice (by what you said it seems only special use cases and
>as a communication interface to the actual computers used by
>customers), and how it was to program for it, how many domains
>were used, and how complex each was.

I hope the above gives some insight into the answer to this question.


>Were there tools to (visually?) monitor the capability
>network/metering hierarchy?

I don't remember how we monitored performance. We certainly did
some measurement, and a tool that monitored the meters would be
easy to construct. BTW, such a tool would have some effect on
performance since you would have to unprepare the meter to read
it's value and it would need to be prepared again before a
domain could run under it.

One of our really serious efforts was the debit/credit
benchmark, where we were trying to maximize transactions/second.


>>the problem of cooperation between competitors in a computer utility
>
>Are there companies still today that provide this service? A
>trusted, non-public computing intermediary?

This would probably be a cloud service. I'm not up on them.

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz | When all else fails: | Periwinkle
(408)348-7900 | Voice and CW. | 150 Rivermead
Rd #235
www.pwpconsult.com | | Peterborough,
NH 03458

David Nicol

unread,
Sep 9, 2021, 11:20:23 AM9/9/21
to cap-...@googlegroups.com

Really? "Record collection?" That's hella cute.

On Tue, Sep 7, 2021 at 3:07 PM Bill Frantz <fra...@pwpconsult.com> wrote:

An administrator could setup a shared directory (record
collection). Any of the entities sharing it could read and write

 
--
"Lay off that whiskey, and let that cocaine be!" -- Johnny Cash
Reply all
Reply to author
Forward
0 new messages