On Sat, Nov 15, 2014 at 5:35 PM, Cory Smelosky <b4 at gewt.net> wrote:
See if they've gotten anywhere with getting the rights to release the
CompuServe Monitor source, too.
Does this still exist??? I begged Gerry Moersdorf for a dump of the
SCSI drives in the CompuServe SC-40s. He was unable to do it. I really
wanted it too. :( And LCM will never give me a copy of theirs. :(((
BTW, anybody know if TYMCOM-X survives anywhere? (That's the
Tymshare/Tymnet one.)
Jim
On 2014-11-15 15:10, Cory Smelosky wrote:
On Sat, 15 Nov 2014, Cory Smelosky wrote:
I'll grab it and see if it works. I do however need to find out why
my cluster boot node keeps rebooting on DECnet/LAT accesses. More
reason to get the 4000 up I guess. ;)
Yup, that works...except on the VAX but it likely crashed shortly
after attempted login. Terminal powered back on.
Johnny
$ copy 9.1::sys$specific:[decnet]k11.tsk k11.tsk
Node: 9.1
User: csmelosky
Password:
System Password:
?NFT -- Bad RFM field in FAB
What a helpful error message.
:-)
Anyway, K11.TSK is probably not what you want, since all the TSK files on MIM are RSX images. You probably want to grab all the sources, and the command files, and build it yourself.
I checked, and there are definitely RSTS/E build files in there.
As for the error message, knowing RMS helps. FAB is the File Access Block. RFM is (if I remember right) Record Format. Probably RSTS/E cannot just grok the record format of that file. You can give switches to NFT under RSX at least, to tell what the format should be when copying...
On MIM:
.nft help mode
NFT has three modes of transfering the file data (BLOCK, RECORD and
AUTOMATIC) and two file data types (IMAGE and ASCII).
The default mode of transfer is AUTOMATIC (/AX). NFT selects either
BLOCK or RECORD mode to copy the file data depending on the remote
system type and the device involved.
In BLOCK mode (/BK), the file data is copied in 512. byte blocks.
Block mode allows more efficient transfer of Sequential Variable format
files, And it is the only way NFT will transfer RMS Relative and
Indexed Sequential files. The remote file system must be able to
understand your file organizations, or the resultant files are useless.
In RECORD mode, the file data is copied in records. The remote system
can store the data in the manner used on that system. This less
efficient since the individual records must be read and written to the
file.
The default data type, IMAGE (/IM), specifies that the file is to be
transfered as 8 bit bytes and with no changes to the format.
If the remote node does not support the current format or attributes
the transfer will be rejected.
The ASCII data type (/AS), specifies that the file contains ASCII
text and can be converted to an appropriate format for the remote
file system. In particular NFT will convert Variable format files
to Stream format when transfering to an RT-11, RSTS/E, or TOPS-20
systems. In order to properly convert these files, the ASCII switch
will select RECORD mode transfer.
Johnny
On 11/15/2014 05:34 PM, Johnny Billquist wrote:
Yes, they are running TOPS-20. But exactly how much of it, I can't tell.
I'm no expert on TOPS-20, and mostly go on what I can recall Rich
Alderson telling me.
That's absolutely amazing. I have a few strings I can pull in that
crowd; I will see what I can find out, and what I can get ahold of.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
On Sat, 15 Nov 2014, Cory Smelosky wrote:
I'll grab it and see if it works. I do however need to find out why my cluster boot node keeps rebooting on DECnet/LAT accesses. More reason to get the 4000 up I guess. ;)
Yup, that works...except on the VAX but it likely crashed shortly after attempted login. Terminal powered back on.
Johnny
$ copy 9.1::sys$specific:[decnet]k11.tsk k11.tsk
Node: 9.1
User: csmelosky
Password:
System Password:
?NFT -- Bad RFM field in FAB
What a helpful error message.
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
On Sat, 15 Nov 2014, Johnny Billquist wrote:
As for KERMIT - For what system? :-)
RSTS/E 10.1, 11/23+ 512K(bytes) of memory.
Yeah. Sorry. I should pay closer attention... On MIM, you have the latest KERMIT-11 that was generic for all OSes. But I know that someone (at the moment the name escapes me) wrote some further development that only worked on RT-11 and I think RSTS/E, which I do not have on MIM.
But check MIM::DU:[KERMIT]
I'll grab it and see if it works. I do however need to find out why my cluster boot node keeps rebooting on DECnet/LAT accesses. More reason to get the 4000 up I guess. ;)
As for accessing MIM, just enable outgoing proxy in NCP. Or else use
GUEST/GUEST.
I should probably definitely figure out ncp on RSTS/E
Somewhere in the back of my head is a brain cell saying that proxy access was not supported on RSTS/E... But RSTS/E is not my field of expertise. For now, just use GUEST/GUEST, and you should atleast have access.
Yup, that works...except on the VAX but it likely crashed shortly after attempted login. Terminal powered back on.
Johnny
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
On 2014-11-15 14:29, Cory Smelosky wrote:
On Sat, 15 Nov 2014, Johnny Billquist wrote:
On 2014-11-15 14:04, Cory Smelosky wrote:
Uh...this is gonna seem a little strange...
Does anyone have a copy of Kermit somewhere DECNET accessible...along
with how I can get
$ dir 1.13::
Node: 1.13
User: decnet\
Password:
System Password:
?NFT -- Connection rejected to node 1.13
?NFT -- Access not permitted
to behave happily for guest access?
As for KERMIT - For what system? :-)
RSTS/E 10.1, 11/23+ 512K(bytes) of memory.
Yeah. Sorry. I should pay closer attention... On MIM, you have the latest KERMIT-11 that was generic for all OSes. But I know that someone (at the moment the name escapes me) wrote some further development that only worked on RT-11 and I think RSTS/E, which I do not have on MIM.
But check MIM::DU:[KERMIT]
As for accessing MIM, just enable outgoing proxy in NCP. Or else use
GUEST/GUEST.
I should probably definitely figure out ncp on RSTS/E
Somewhere in the back of my head is a brain cell saying that proxy access was not supported on RSTS/E... But RSTS/E is not my field of expertise. For now, just use GUEST/GUEST, and you should atleast have access.
Johnny
On Sat, 15 Nov 2014, Johnny Billquist wrote:
Doh! That was in the subject line... Sorry...
No worries.
Hmm. I could probably help with that, if you haven't figured something out. Later today...
I'm stumped on exactly which binary/source files I'd need to copy. ;)
Johnny
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
On 2014-11-15 14:28, Johnny Billquist wrote:
On 2014-11-15 14:04, Cory Smelosky wrote:
Uh...this is gonna seem a little strange...
Does anyone have a copy of Kermit somewhere DECNET accessible...along
with how I can get
$ dir 1.13::
Node: 1.13
User: decnet\
Password:
System Password:
?NFT -- Connection rejected to node 1.13
?NFT -- Access not permitted
to behave happily for guest access?
As for KERMIT - For what system? :-)
Doh! That was in the subject line... Sorry...
Hmm. I could probably help with that, if you haven't figured something out. Later today...
Johnny
On Sat, 15 Nov 2014, Johnny Billquist wrote:
Unfortunately I do not have much details. I was at the Living Computer Museum and talked with RIch Alderson, who used to work at XKL. And he showed me a newer generation router from XKL, opened up, at LCM. And they use a PDP-10 on a chip, and it was actually running TOPS-20, and I could play around at the EXEC level in there.
Very, very interesting!
But for normal usage, customers would just see this as a router from XKL, with a command interface, in addition to SNMP. No way they would ever know that it's actually TOPS-20 in there.
Huh. Dave and I'll need to pull some strings...;)
I do not know if they use this same setup in all their products, or just some. And I don't remember exactly what product LCM at on display. But I can check that up next week, as I am in Seattle then.
Please do! I am very interested!
See if they've gotten anywhere with getting the rights to release the CompuServe Monitor source, too.
Johnny
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
On 2014-11-15 14:19, Dave McGuire wrote:
On 11/15/2014 05:10 PM, Johnny Billquist wrote:
It's certainly possible (IMO) that it could be brought into this era
technologically, as it has a good base to build on, but I don't know of
any companies or investors who would support such work. I think it
should happen, but it likely will not.
Think of it this way. Remember "wash boards"? I don't know if you
have a different term for them in Sweden, but they are how we washed
clothes a century ago, before automated washing machines. It's a rough
metal plate in a wooden frame that sticks out of a bucket of soapy
water, and you rub the clothes on it to flush out the dirt. If the wash
board is patented, and someone still owns that patent, it's very
unlikely that anyone in the business world would consider that patent to
be worth anything, for the obvious reason.
Analogies are always problematic.
Consider this - a piece of software used in embedded applications is a
piece of software you will probably never hear of. Might not even be
possible to buy if you tried.
Well yes, I understand that. I am an embedded systems developer. But
see below.
Does that mean it is dead, or have no value?
This is the state of TOPS-20 at the moment. It is being used as embedded
software, that you'll never see, or hear of. But it's still alive.
I'm aware of the use of the XKL chipset's application in the network
switches, but I was unaware of their use of TOPS-20. I thought they
were running a bare-metal firmware load written for that purpose. Is
this not the case, are they actually running TOPS-20, or at least some
part(s) of it, on those embedded processors?
If so, I need to pull a few strings and get my hands on one. Or several.
Yes, they are running TOPS-20. But exactly how much of it, I can't tell. I'm no expert on TOPS-20, and mostly go on what I can recall Rich Alderson telling me.
Johnny
