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
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.
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.
paul
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.
paul
On Sun, 16 Nov 2014, Jim Carpenter 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. :(((
I'm betting the LCM is just stuck on copyright...I'm hoping anyway. It's certainly their style to release it.
BTW, anybody know if TYMCOM-X survives anywhere? (That's the
Tymshare/Tymnet one.)
I hope so! I've tracked down TENEX, WAITS, TOPS-10/20, evidence of the CompuServe monitor, and FOONEX but never TYMCOM-X.
Jim
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
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
