[inforoots] Re: inforoots Digest, Vol 25, Issue 5

[Stan Sieler]

Glenn writes:

> Larry Kelly joined GRiD in 1983, we made the decision to use GPIB in  
...
> You might also be thinking of Larry Gravell, who was in manufacturing  

The position for Larry Kelly that I posted was the one that I
found in his mini-resume, posted at www.kelly.com (which I had to find
via www.archive.org, since kelly.com seems to be dead now). 


> NFS did not hit the scene until about 1986, it was defined in RFC1094  
> in March 1989.

thanks.

 
> The DS/3000 system was also interesting, it was not really a  
> networked file system since it did not support a LAN (that came later  
> with NS/3000 circa 1988 as i remember).  DS/3000 supported modem  
> connections or X.25 connections in a point-to-point mode and it was  

Still a network :)
...although without any routing.  A typical DS network was a
graph, and users had a photcopy of a picture of the graph 
taped to their cubicle walls, because you had to route 
yourself from machine A to machine C if they weren't directly
connected together.


> at the time).  We did not run any user jobs on GRiDCentral, it was  
> more like today's web services model but, of course, all proprietary  
> APIs..  Did DS/3000 have an API interface, i do not remember that? (i  

If I'm on a machine called LARRY, and I open a DSLINE to MOE, I can
access the file CURLY on MOE by saying:

    :file curly;dev=MOE#disc

(A "File equation" was a Burroughs MCP-like technique to
alter (or specify) attributes for a file behind the back of a program.)

If I then got into the editor, I could say:

   :editor
   text curly

and now I'm editing CURLY on MOE, and the editor has no idea the
file isn't a local disk file.  All standard file system API's
work (open/close/read/write/fgetinfo (to get information about the file)
transparently.  In fact, there were a few odd cases where I wished
it *wasn't* so transparent, because the implementors hadn't 
quote thought through all the things that one needs for a file system.
The biggest was a lack of any method of saying "hey, please
display this message at the console of the computer where this
file resides" ... something our backup system (STORE) needed
at reel-switch time.  Also, IIRC, there was no way of determining
the name of the computer the file resided on (it could be many
"hops" away ... the equivalent of being more than two routers away).
(Thus, If I wanted to create "curly.bak", I couldn't ... because
I didn't know what computer to create it on.)

One could also associate a remote machine name, user ID, and logon
credentials with a given local database name, and access the remote
database as though it was on the local machine.  This was
called RDBA (Remote DataBase Access), and was completely
transparent to the database user. 
("database" means "IMAGE/3000 database" here.)

DS/3000 was a combination of NFS and rlogin ... you could logon
to a remote machine, and say ":remote" ... from that point
you were essentially really logged in to the remote machine,
and you could switch back and forth from the remote session and
the local session ... and you could have multiple remote sessions
at the same time.

A remote session could request a file from the originating 
session:   :file original; dev=#disc

The "#disc", instead of "disc", meant "go 'back' one hop".
If you (or your code) knew that you had originally logged onto
machine A, and then remoted to machine B, from from B to C,
code on C could access files on A via "dev=##disc".  Of course,
that had to be specified manually (well, a program could "probe"
and try to guess :)

You could request a remote connection (for use as a session or a file access)
via:
    :dsline <machine name>

or
    :dsline <port#>

IIRC, only a few unusually connected remote machines would have a port
number (and be requested by number) ... 
the rest used the early network transport (ARPA PROBE?), and
were requested by name.

But the port# method was useful... for fun, I wrote a worm using 
DS/3000 (and port # access) as the transport mechanism, circa
1979/1980 ... with code to kill itself after getting two machines away :)
(I might have been inspired by the 1972 book, "When HARLIE was one".)
It worked, although it used brute force to guess the logon
password at the remote machines.  Luckily (sort of :), in those
days one could do repetitive logon attempts without getting
bounced or delayed.  (That changed later, of course.)


> Yes, thank you for correcting my sentence, it was confusing ;-)

No problem...by the time I got to it, I'd forgotten about John E,
so when I thought it was John M, it had seemed to contradict your
earlier sentence :)   So, for anyone without a short attention
span, it would ... wait, what was I talking about?

After leaving GRiD, Larry Kelly started Kelly Computer Systems,
in Mountain View, CA, making memory boards for the HP 150,
HP LaserJets, and HP 3000 / HP 9000 computers.

My company got him the "kelly.com" domain name, something I'm sure 
that "Kelly Services" (formerly "Kelly Girls") was annoyed about :)

Kelly's boards might have been the first third-party add-on
boards for the LaserJet and for the HP-150.  He and Jonathon Lim
did a lot of good design work on their various products.

My company, Allegro Consultants, Inc., got involved with Kelly Computer 
when we took a home-modified HP memory board to him for repair
(we'd modified a couple of HP boards to quadruple their
capacity, successfully, and then fouled up a third board, 
and hoped he'd be willing to test it for us.)

As I was leaving his office after meeting him, I made an
off-hand comment, something like "with the price of memory
getting lower, maybe we could figure out how to add (and use)
much more memory than the HP 3000 could normally use,
maybe something like a RAM disk".

Shortly afterwards, we worked together to produce the
first RAM disk for the HP 3000/64.  We discovered the backplane
could address 64 MB, but the O/S would only address and use
16 MB, so that we built bigger boards and used the extra
memory as a RAM disk.  When the 3000/70 came out, the extra
address lines were removed, so we re-invented bank switching
to access up to 128 MB (or so) of RAM disk.  I always thought
it ironic that the bank switching hardware for the Kelly RAM disk
was designed by Jonathon Lim (as in LIM: Lotus Intel Microsoft).

(Yes, I know that LIM didn't "invent" bank switching for the IBM PC,
IIRC it was Tall Tree Systems.)

Kelly produced a unique, AFAIK, font cartridge for the LaserJet,
which had the ability to let the user download and save (in 
the cartridge) their own fonts.  (It may have had the ability
to suck in the fonts from someone else's cartridges.)

I tried to talk Kelly into creating a 'fax box' to sit
inbetween a phone line and a LaserJet, giving it fax
receiving ability (and, with a separate serial port for
attaching to a computer, fax sending ability) ... this
was before anything like it was on the market (IIRC),
but it never got off the ground.  Probably just as well,
because fax to/from PCs started taking off and was cheaper.

I suspect that the declining profit margin in memory boards,
increasing competition for LaserJet memory boards, and
slow sales of HP computers, combined to do them in.
The fact that HP started using a proprietary memory controller
on their memory boards for their PA-RISC computers didn't
help, either.   (Expensive and time-consuming to design
an equivalent controller.)
HP eventually abandoned that, or customer pressure forced
them to, luckily (for the customers, because competition
is good for us :)

Stan