On Fri, 25 Apr 2014, Brian Hechinger wrote:
GRE tunnels? I'm your guy. :)
What's the SNMP IP again? I have everything (mostly) ready to go here again...I just need to add the pf rule. ;)
I'll send you a private mail of what info I need when I'm at my computer.
-brian
On Apr 25, 2014, at 17:40, Mark G Thomas <Mark at Misty.com> wrote:
Hi,
I'm thinking I'd like to get connected to hecnet, and maybe put one
of my VAX systems online.
I've got a static Verizon FIOS IP, and a Cisco router with which I could set
up a GRE tunnel.
Who can help me?
Mark
--
Mark G. Thomas (Mark at Misty.com)
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
GRE tunnels? I'm your guy. :)
I'll send you a private mail of what info I need when I'm at my computer.
-brian
On Apr 25, 2014, at 17:40, Mark G Thomas <Mark at Misty.com> wrote:
Hi,
I'm thinking I'd like to get connected to hecnet, and maybe put one
of my VAX systems online.
I've got a static Verizon FIOS IP, and a Cisco router with which I could set
up a GRE tunnel.
Who can help me?
Mark
--
Mark G. Thomas (Mark at Misty.com)
Hi,
I'm thinking I'd like to get connected to hecnet, and maybe put one
of my VAX systems online.
I've got a static Verizon FIOS IP, and a Cisco router with which I could set
up a GRE tunnel.
Who can help me?
Mark
--
Mark G. Thomas (Mark at Misty.com)
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
