On Apr 23, 2014, at 3:36 PM, Johnny Billquist <bqt at softjar.se> wrote:
On 2014-04-23 21:31, Paul_Koning at Dell.com wrote:
On Apr 23, 2014, at 3:16 PM, Johnny Billquist <bqt at softjar.se> wrote:
...
Indeed, the quota was the problem. Works now. Excellent! Cool. However, RSTS/E did not present the kind of attributes on text files that I would have thought.
Native RSTS files don t *have* attributes, no more than Unix files do. FAL supplies something if you don t specifically ask for a transfer mode, and that something is probably a safe but unhelpful default like undefined records, 512 block size.
Right. I just sortof expected DAP to say that they were stream files, or something like that.
But on the other hand, that could possibly be messy if the file actually was some binary thing, so maybe unknown makes more sense after all.
Yes, that s why it is done that way.
If you ask for text mode, FAL will handle that, and supply something more helpful. Either stream_crlf, or it will convert to a more popular RMS format, I don t remember.
It obviously do work right if you ask for ASCII. I wonder which end do the conversion in that case. Is the sending side aware that the file should be sent as some kind of ASCII text file?
Quoting the DAP 5.6.0 spec, Attributes message:
DATATYPE(EX-2) : BM = The type of data being transferred. The
default is Image. Unless a file has
attributes specifying whether the file
contains ASCII or Image data, the value
(ASCII or Image) sent by the accessing
process when opening a file, is returned by
the accessed process.
Bit Meaning (When Set)
0 ASCII (see Note 1).
1 IMAGE (default) (see Note 2 below).
2 EBCDIC (Reserved).
3 Compressed format. ...
Note that it says the default is Image, which is another reason why RSTS FAL defaults as it does. And the setting up the link section says that after opening the connection, an Attributes message is sent by the accessing system specifying the mode and format of the data , followed by an access message to specify the operation.
So NFT says what it wants, FAL replies that it will comply, and FAL sends the data in the requested form.
RSX and VMS don t have this because all files are RMS files.
Well, technically, in RSX you can have either an RMS-11 DAP, or an FCS-11 DAP. But since RMS is pretty much a superset of FCS it's more of a technicality than a real point. :-)
What I should have said is that on RMS and VMS, all files have RMS style attributes, while on RSTS only some do. For files that don t, the user and/or application are expected to know what the file format is; the OS doesn t help you.
paul
On 2014-04-23 21:36, Johnny Billquist wrote:
On 2014-04-23 21:31, Paul_Koning at Dell.com wrote:
On Apr 23, 2014, at 3:16 PM, Johnny Billquist <bqt at softjar.se> wrote:
...
Indeed, the quota was the problem. Works now. Excellent! Cool.
However, RSTS/E did not present the kind of attributes on text files
that I would have thought.
Native RSTS files don t *have* attributes, no more than Unix files
do. FAL supplies something if you don t specifically ask for a
transfer mode, and that something is probably a safe but unhelpful
default like undefined records, 512 block size.
Right. I just sortof expected DAP to say that they were stream files, or
something like that.
But on the other hand, that could possibly be messy if the file actually
was some binary thing, so maybe unknown makes more sense after all.
If you ask for text mode, FAL will handle that, and supply something
more helpful. Either stream_crlf, or it will convert to a more
popular RMS format, I don t remember.
It obviously do work right if you ask for ASCII. I wonder which end do
the conversion in that case. Is the sending side aware that the file
should be sent as some kind of ASCII text file?
RSX and VMS don t have this because all files are RMS files.
Well, technically, in RSX you can have either an RMS-11 DAP, or an
FCS-11 DAP. But since RMS is pretty much a superset of FCS it's more of
a technicality than a real point. :-)
And I should probably correct myself. When I write DAP, I meant FAL.
Unless I'm confused DAP is the protocol, while FAL is the object/task/program that implements DAP on the listener side.
Johnny
On 2014-04-23 21:31, Paul_Koning at Dell.com wrote:
On Apr 23, 2014, at 3:16 PM, Johnny Billquist <bqt at softjar.se> wrote:
...
Indeed, the quota was the problem. Works now. Excellent! Cool. However, RSTS/E did not present the kind of attributes on text files that I would have thought.
Native RSTS files don t *have* attributes, no more than Unix files do. FAL supplies something if you don t specifically ask for a transfer mode, and that something is probably a safe but unhelpful default like undefined records, 512 block size.
Right. I just sortof expected DAP to say that they were stream files, or something like that.
But on the other hand, that could possibly be messy if the file actually was some binary thing, so maybe unknown makes more sense after all.
If you ask for text mode, FAL will handle that, and supply something more helpful. Either stream_crlf, or it will convert to a more popular RMS format, I don t remember.
It obviously do work right if you ask for ASCII. I wonder which end do the conversion in that case. Is the sending side aware that the file should be sent as some kind of ASCII text file?
RSX and VMS don t have this because all files are RMS files.
Well, technically, in RSX you can have either an RMS-11 DAP, or an FCS-11 DAP. But since RMS is pretty much a superset of FCS it's more of a technicality than a real point. :-)
Johnny
On Apr 23, 2014, at 3:16 PM, Johnny Billquist <bqt at softjar.se> wrote:
...
Indeed, the quota was the problem. Works now. Excellent! Cool. However, RSTS/E did not present the kind of attributes on text files that I would have thought.
Native RSTS files don t *have* attributes, no more than Unix files do. FAL supplies something if you don t specifically ask for a transfer mode, and that something is probably a safe but unhelpful default like undefined records, 512 block size.
If you ask for text mode, FAL will handle that, and supply something more helpful. Either stream_crlf, or it will convert to a more popular RMS format, I don t remember.
If the RSTS file is one that does have attributes already, like a TSK file or an RSX format object file or a BCK (backup set) file, RSTS will just send those attributes across and all is well. The trouble is that you have to supply attributes if they aren t already in place.
RSX and VMS don t have this because all files are RMS files.
paul
On 2014-04-23 20:39, Paul_Koning at Dell.com wrote:
On Apr 23, 2014, at 2:28 PM, Jordi Guillaumes i Pons <jg at jordi.guillaumes.name> wrote:
El 23/04/2014, a les 20.13, Johnny Billquist <bqt at softjar.se> va escriure:
Cool. Thanks.
TOPS-20 FAL looks semi-sane, and I can talk with it.
Tops-10 FAL looks really weird, but at least some kind of communication is possible.
RSTS/E FAL is not agreeing with RSX, it would seem. :-(
Well, I can get at least a little bit of communication. I can get a DIRECTORY and I can type a remote file, forcing the mode to ASCII (/AS).
......
NFT>ti:=bitxot"[201,2] guestguest"::login.com
NFT -- Error in opening output file TT:LOGIN.COM
Invalid or Unsupported Record format
NFT>ti:=bitxot"[201,2] guestguest"::login.com/as
Since RSTS native files are not RMS files, and login.com most likely is such a file, chances are it s coming across as a file of undefined record format. Either that, or stream-crlf. You may want to look at a protocol trace to see what it s doing. That could explain the unsupported record format message.
RSTS can certainly talk to other NFTs, but you have to tell it how to map native files to some RMS format, if you re pulling from RSTS.
Pretty much:
.nft bitxot"201,2 guestguest"::login.com/at
Directory BITXOT::_SY:[201,2]
23-APR-14 21:17:47
LOGIN.COM
Size: 1./4. Created: 25-APR-14 04:24:00
Owner: [201,2] Revised: 25-APR-14 04:24:00
Expires: <none_specified>
File protection: System:RWED, Owner:RWED, Group:, World:
File organization: Sequential
File attributes: Allocation=0
Record format: Undefined, no maximum defined
Record attributes: None
Total of 1./4. Blocks in 1. Files
.nft bitxot"201,2 guestguest"::login.com/id
NFT -- Version V9.0
Local NFARs V8 DAP V7.1 Buffer size= 2064. OS=RSX-11M+ FS=FCS-11 DC=Yes
Remote FAL V4.1 DAP V5.6 Buffer size= 636. OS=RSTS/E FS=RMS-11 DC=No
Johnny
On 2014-04-23 20:28, Jordi Guillaumes i Pons wrote:
El 23/04/2014, a les 20.13, Johnny Billquist <bqt at softjar.se> va escriure:
Cool. Thanks.
TOPS-20 FAL looks semi-sane, and I can talk with it.
Tops-10 FAL looks really weird, but at least some kind of communication is possible.
RSTS/E FAL is not agreeing with RSX, it would seem. :-(
Well, I can get at least a little bit of communication. I can get a DIRECTORY and I can type a remote file, forcing the mode to ASCII (/AS). If you were getting an "Insufficient network resouces" error that was my fault (I forgot to increase the quotas for the GUEST user).
Indeed, the quota was the problem. Works now. Excellent! Cool. However, RSTS/E did not present the kind of attributes on text files that I would have thought.
Johnny
On Apr 23, 2014, at 2:28 PM, Jordi Guillaumes i Pons <jg at jordi.guillaumes.name> wrote:
El 23/04/2014, a les 20.13, Johnny Billquist <bqt at softjar.se> va escriure:
Cool. Thanks.
TOPS-20 FAL looks semi-sane, and I can talk with it.
Tops-10 FAL looks really weird, but at least some kind of communication is possible.
RSTS/E FAL is not agreeing with RSX, it would seem. :-(
Well, I can get at least a little bit of communication. I can get a DIRECTORY and I can type a remote file, forcing the mode to ASCII (/AS).
......
NFT>ti:=bitxot"[201,2] guestguest"::login.com
NFT -- Error in opening output file TT:LOGIN.COM
Invalid or Unsupported Record format
NFT>ti:=bitxot"[201,2] guestguest"::login.com/as
Since RSTS native files are not RMS files, and login.com most likely is such a file, chances are it s coming across as a file of undefined record format. Either that, or stream-crlf. You may want to look at a protocol trace to see what it s doing. That could explain the unsupported record format message.
RSTS can certainly talk to other NFTs, but you have to tell it how to map native files to some RMS format, if you re pulling from RSTS.
paul
El 23/04/2014, a les 20.13, Johnny Billquist <bqt at softjar.se> va escriure:
Cool. Thanks.
TOPS-20 FAL looks semi-sane, and I can talk with it.
Tops-10 FAL looks really weird, but at least some kind of communication is possible.
RSTS/E FAL is not agreeing with RSX, it would seem. :-(
Well, I can get at least a little bit of communication. I can get a DIRECTORY and I can type a remote file, forcing the mode to ASCII (/AS). If you were getting an "Insufficient network resouces" error that was my fault (I forgot to increase the quotas for the GUEST user).
nft
NFT>bitxot"[201,2] guestguest"::/li
Directory BITXOT::_SY:[201,2]
2014-04-23 20:18:50
LOGIN.COM 1./4. 2014-04-25 04:24:00
Total of 1./4. Blocks in 1. Files
NFT>ti:=bitxot"[201,2] guestguest"::login.com
NFT -- Error in opening output file TT:LOGIN.COM
Invalid or Unsupported Record format
NFT>ti:=bitxot"[201,2] guestguest"::login.com/as
$ SET TERM/INQ
The reverse route (RSX -> RSTS) seems also to work:
nft
NFT>bitxot"[201,2] guestguest"::LOGS.FTN=LOGS.FTN
NFT>BITXOT"[201,2] guestguest"::/li
Directory BITXOT::_SY:[201,2]
2014-04-23 20:26:16
LOGIN.COM 1./4. 2014-04-25 04:24:00
LOGS.FTN 1./4. 2014-04-25 05:20:00
Total of 2./8. Blocks in 2. Files
NFT>TI:=BITXOT"[201,2] guestguest"::LOGS.FTN/AS
PROGRAM LOGS
INTEGER I
REAL*8 LN10,L,L10
LN10 = LOG(10.)
DO I=1,100
L = LOG(REAL(I))
L10 = L / LN10
WRITE(5,100) I,L,L10
100 FORMAT (I4,X,F10.8,X,F10.8)
ENDDO
END
NFT>
There apparently was, but it seems few ever have seen it. (Guess it falls under the same category as DECnet/8. It apparently did exist at one point, but noone seems to actually have run it. Well, I actually have DECNET-8 sources, but it's only DECnet phase II, and in addition it requires RTS-8.)
I recall to have read somewhere that there was a Phase III implementation for RT-11.
Jordi Guillaumes i Pons
jg at jordi.guillaumes.name
HECnet: BITXOV::JGUILLAUMES
On Wed, 23 Apr 2014, Johnny Billquist wrote:
We'll see who manages first.
Mine is up...I just need to open SNMP and hae an update forced.
By the way, I didn't know there was DECNET for RT-11...
There apparently was, but it seems few ever have seen it. (Guess it falls under the same category as DECnet/8. It apparently did exist at one point, but noone seems to actually have run it. Well, I actually have DECNET-8 sources, but it's only DECnet phase II, and in addition it requires RTS-8.)
Johnny
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
On 2014-04-23 20:00, Jordi Guillaumes i Pons wrote:
El 23/04/2014, a les 11.16, Johnny Billquist <bqt at softjar.se> va :
I've been fixing some DECnet code in RSX, and I'm now looking for systems to check against.
What I'm testing is NFT/DAP access, and systems I'd like to test against is Ultrix-32, OSF-1, TOPS-20, RT-11, RSTS/E. Essentially anything not VMS or RSX. :-)
Do anyone have any such systems online on HECnet at the moment, which I can have file access to?
BITXT0: TOPS-20, USER=GUEST, PASSWORD=GUEST
BITXOT: RSTS/E, ACCOUNT=201,2, PASSWORD=GUESTGUEST
>
> Additionally:
>
> BITXT1: TOPS-10, USER=GUEST, PASSWORD=GUEST
>
Cool. Thanks.
TOPS-20 FAL looks semi-sane, and I can talk with it.
Tops-10 FAL looks really weird, but at least some kind of communication is possible.
RSTS/E FAL is not agreeing with RSX, it would seem. :-(
I can put up a Ultrix-32 system if there is no other one available.
We'll see who manages first.
By the way, I didn't know there was DECNET for RT-11...
There apparently was, but it seems few ever have seen it. (Guess it falls under the same category as DECnet/8. It apparently did exist at one point, but noone seems to actually have run it. Well, I actually have DECNET-8 sources, but it's only DECnet phase II, and in addition it requires RTS-8.)
Johnny
