On Sun, 23 Nov 2014, Gregg Levine wrote:
Hello!
And where was it hiding?
SRC:<BBN-MONITOR>
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
Hello!
And where was it hiding?
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."
On Sun, Nov 23, 2014 at 2:01 PM, Cory Smelosky <b4 at gewt.net> wrote:
Afternoon,
To the probably 0 other people interested...I think I managed to stumble
across a later version of the BBN monitor...not sure if it's TENEX, just
patches to the networking stack. It was (not really) hidden within the
SRI-NIC SRC: structure dump.
The source contains a copy of BBN Report 5925
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
Afternoon,
To the probably 0 other people interested...I think I managed to stumble across a later version of the BBN monitor...not sure if it's TENEX, just patches to the networking stack. It was (not really) hidden within the SRI-NIC SRC: structure dump.
The source contains a copy of BBN Report 5925
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
Verzonden vanaf mijn BlackBerry 10-smartphone.
Van: Mark Abene
Verzonden: woensdag 19 november 2014 04:42
Aan: hecnet at update.uu.se
Beantwoorden: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] TOPS-10/20 copyright status
You're likely right, and I had it backwards (SC versus Foonly).
On the other note, it would be really cool to revive TYMCOM-X and its dev environment (excluding the Tymnet Engine node-code generation tools). But it's very possible that British Telecom wouldn't allow that to happen, if in fact they still hold all the copyrights that they absorbed from acquiring Tymnet and Tymshare.
-M
On Mon, Nov 17, 2014 at 8:57 PM, Pontus Pihlgren <pontus at update.uu.se> wrote:
On Mon, Nov 17, 2014 at 04:23:38PM -0800, Mark Abene wrote:
>
> If I remember correctly, Compuserve was using Foonlys towards the end,
> since they were much more economical to run than the Systems Concepts
> machines. Maybe someone can comment.
That sounds backwards. At least the F1 was a very complex
machine even requiring a DeC PDP-10 to even boot. The SC-40 was
comparatively nimble. Lpok at gerrys youtibe videos.
I don't know much about the later foonlys. I'd like to know
more.
/P
You're likely right, and I had it backwards (SC versus Foonly).
On the other note, it would be really cool to revive TYMCOM-X and its dev environment (excluding the Tymnet Engine node-code generation tools). But it's very possible that British Telecom wouldn't allow that to happen, if in fact they still hold all the copyrights that they absorbed from acquiring Tymnet and Tymshare.
-M
On Mon, Nov 17, 2014 at 8:57 PM, Pontus Pihlgren <pontus at update.uu.se> wrote:
On Mon, Nov 17, 2014 at 04:23:38PM -0800, Mark Abene wrote:
>
> If I remember correctly, Compuserve was using Foonlys towards the end,
> since they were much more economical to run than the Systems Concepts
> machines. Maybe someone can comment.
That sounds backwards. At least the F1 was a very complex
machine even requiring a DeC PDP-10 to even boot. The SC-40 was
comparatively nimble. Lpok at gerrys youtibe videos.
I don't know much about the later foonlys. I'd like to know
more.
/P
On 2014-11-17 07:55, Paul_Koning at Dell.com wrote:
On Nov 15, 2014, at 9:17 PM, Johnny Billquist <bqt at softjar.se> wrote:
...
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.
I haven t tried it, at least not much, with RSX images. But the emulation in RSTS is often able to run unmodified images from the other operating systems. It certainly works that way for RT11 emulation. It is true that using a RSTS/E build is preferable, if you can find one, because that will enable some RSTS-specific things. But if all you can find is an RSX image, it s worth a try.
Yes, many RSX images will work. And I have not checked if KERMIT do something tricky or not. If it's just plain RSX code, then it could work just fine under RSTS/E. If they use ASTs to actually deal with things in an asynchronous manner, or more odd RSX stuff, then the RSTS/E emulation layer might not be enough.
I know that there are separate build files and pieces for RSTS/E in KERMIT-11, and since those files are available, I would just grab it all (from MIM:: for example) and built it myself.
Johnny
On Mon, Nov 17, 2014 at 04:23:38PM -0800, Mark Abene wrote:
If I remember correctly, Compuserve was using Foonlys towards the end,
since they were much more economical to run than the Systems Concepts
machines. Maybe someone can comment.
That sounds backwards. At least the F1 was a very complex
machine even requiring a DeC PDP-10 to even boot. The SC-40 was
comparatively nimble. Lpok at gerrys youtibe videos.
I don't know much about the later foonlys. I'd like to know
more.
/P
On Sun, Nov 16, 2014 at 9:57 AM, Jim Carpenter <jim at deitygraveyard.com> wrote:
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. :(((
If I remember correctly, Compuserve was using Foonlys towards the end, since they were much more economical to run than the Systems Concepts machines. Maybe someone can comment.
BTW, anybody know if TYMCOM-X survives anywhere? (That's the
Tymshare/Tymnet one.)
I was a TYMCOM-X "user" of sorts. Joe Smith, formerly of Tymshare, may possibly know what happened to the code, if you ask him nicely. :) His site is here: http://www.inwap.com/pdp10/
-Mark
On Nov 17, 2014, at 11:08 AM, Cory Smelosky <b4 at gewt.net> wrote:
On Mon, 17 Nov 2014, Paul_Koning at Dell.com wrote:
On Nov 15, 2014, at 9:17 PM, Johnny Billquist <bqt at softjar.se> wrote:
...
$ 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.
...
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...
RSTS uses RMS for this sort of thing, and yes, it certainly should understand RSX RMS files without further help. I wonder if RSX is sending something bogus based on the fact that the remote system is RSTS. Hard to say without seeing what is sent.
9.1 is VMS.
It might be worth experimenting with block or record mode to see if that helps. Executables are fixed:512 files so it doesn?t make a whole lot of difference which mode is used. Another possibility might be to copy RSX to VMS and then VMS to RSTS.
FTP to VMS (image mode), VMS to RSTS is what game the error!
Oops, I misunderstood, I thought the file was coming from RSX. What does VMS claim the RMS attributes are for that file? If it started out with FTP, it may be something odd, like stream. I don t remember how to query RMS attributes on VMS, but I assume there is a way.
An alternative way to transfer files that give NFT trouble is to back then up, then send the backupset. RSTS can read VMS backupsets (if you have a sufficiently new RSTS V9.0 or later, if I remember correctly). Backupsets are fixed record sequential files, which in general should copy just fine.
paul
On Mon, 17 Nov 2014, Paul_Koning at Dell.com wrote:
On Nov 15, 2014, at 9:17 PM, Johnny Billquist <bqt at softjar.se> wrote:
...
$ 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.
...
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...
RSTS uses RMS for this sort of thing, and yes, it certainly should understand RSX RMS files without further help. I wonder if RSX is sending something bogus based on the fact that the remote system is RSTS. Hard to say without seeing what is sent.
9.1 is VMS.
It might be worth experimenting with block or record mode to see if that helps. Executables are fixed:512 files so it doesn?t make a whole lot of difference which mode is used. Another possibility might be to copy RSX to VMS and then VMS to RSTS.
FTP to VMS (image mode), VMS to RSTS is what game the error!
paul
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
