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
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
