On 2012-11-02 22:02, Johnny Billquist wrote:
On 2012-11-02 21:48, Paul_Koning at Dell.com wrote:
On Nov 2, 2012, at 4:31 PM, Johnny Billquist wrote:
On 2012-11-02 19:50, Dave McGuire wrote:
On 11/02/2012 05:23 AM, Johnny Billquist wrote:
$ DIR MIM::DU:[FORTH]
And I'm getting this: (just hitting <cr> at the user/password
prompts)
?$ dir mim::du:[forth]
Node: MIM
User:
Password:
System Password:
?NFT -- Connection rejected to node MIM
?NFT -- Access not permitted
Again, this is only from RSTS/E.
Yes. The prompts are done by RSTS/E, and the error comes from MIM
because you are not specifying a user, and your RSTS/E system are not
providing any proxy information as an alternative.
Ok. Thanks for the insight. I will try to figure out how to set up
proxy info in DECnet/E. You may see me pecking on MIM a bit over the
weekend as I try to get this working.
No worries. Keep experimenting. Just FYI - In VMS and RSX, the
commands are:
NCP SET EXEC INCOMING PROXY ENABLED
NCP SET EXEC OUTGOING PROXY ENABLED
(Although you'll only need the outgoing proxy for getting it to work
in a nicer way to MIM from your system.)
On RSTS, there is no such thing as outgoing proxy. You specify access
information or not; if not, then that seems to be what you need to get
proxy.
Inbound, exec characteristic "default account" specifies the account
to use for objects that have Verification=On (meaning access control
is used) if no access control data is given. If that isn't set, you
don't get default access. If a default account is set, that is used
for default access without any password check; even if the account
normally requires a password, the fact that it is the default lets you
get in that way.
If you specify an account but no password, that is accepted if the
account is marked as "no password required".
Hmm. So there is no way in RSTS/E to do a default mapping from one user
on machine A to another user on machine B without the user having to
specify access information either then?
Too bad in that case. And I guess that this means you cannot access
files on RSX from a RSTS/E system without explicitly giving a user and
password.
Maybe the right time to remind of the GUEST/GUEST account on MIM, though... :-)
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
A coworker put a MicroVaxII in a vt103 with 4 serial lines.
He had fun telling people the VT WAS the Vax, not a terminal.
Bill
--
d|i|g|i|t|a|l had it THEN. Don't you wish you could still buy it now!
pechter-at-gmail.com
On Tue, Oct 30, 2012 at 3:13 PM, Dave McGuire <mcguire at neurotica.com> wrote:
On 10/30/2012 05:19 AM, Johnny Billquist wrote:
> You can alternatively look for a VT103 as well, since that is pretty
> much the same thing as a PDT-11/130.
> If you do some wiring on the Qbus backplane, you can do 22-bit. Throw in
> an 11/93 CPU, SCSI and what else, and you'll have an awesome system in a
> VT100 body.
This is probably a better idea, but it will likely need some
beefing-up of the power supply. The power supply in a VT103 is a bit
underpowered for bigger hardware. It can be done, though.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
On 2012-11-02 21:48, Paul_Koning at Dell.com wrote:
On Nov 2, 2012, at 4:31 PM, Johnny Billquist wrote:
On 2012-11-02 19:50, Dave McGuire wrote:
On 11/02/2012 05:23 AM, Johnny Billquist wrote:
$ DIR MIM::DU:[FORTH]
And I'm getting this: (just hitting <cr> at the user/password prompts)
?$ dir mim::du:[forth]
Node: MIM
User:
Password:
System Password:
?NFT -- Connection rejected to node MIM
?NFT -- Access not permitted
Again, this is only from RSTS/E.
Yes. The prompts are done by RSTS/E, and the error comes from MIM
because you are not specifying a user, and your RSTS/E system are not
providing any proxy information as an alternative.
Ok. Thanks for the insight. I will try to figure out how to set up
proxy info in DECnet/E. You may see me pecking on MIM a bit over the
weekend as I try to get this working.
No worries. Keep experimenting. Just FYI - In VMS and RSX, the commands are:
NCP SET EXEC INCOMING PROXY ENABLED
NCP SET EXEC OUTGOING PROXY ENABLED
(Although you'll only need the outgoing proxy for getting it to work in a nicer way to MIM from your system.)
On RSTS, there is no such thing as outgoing proxy. You specify access information or not; if not, then that seems to be what you need to get proxy.
Inbound, exec characteristic "default account" specifies the account to use for objects that have Verification=On (meaning access control is used) if no access control data is given. If that isn't set, you don't get default access. If a default account is set, that is used for default access without any password check; even if the account normally requires a password, the fact that it is the default lets you get in that way.
If you specify an account but no password, that is accepted if the account is marked as "no password required".
Hmm. So there is no way in RSTS/E to do a default mapping from one user on machine A to another user on machine B without the user having to specify access information either then?
Too bad in that case. And I guess that this means you cannot access files on RSX from a RSTS/E system without explicitly giving a user and password.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On Nov 2, 2012, at 4:31 PM, Johnny Billquist wrote:
On 2012-11-02 19:50, Dave McGuire wrote:
On 11/02/2012 05:23 AM, Johnny Billquist wrote:
$ DIR MIM::DU:[FORTH]
And I'm getting this: (just hitting <cr> at the user/password prompts)
?$ dir mim::du:[forth]
Node: MIM
User:
Password:
System Password:
?NFT -- Connection rejected to node MIM
?NFT -- Access not permitted
Again, this is only from RSTS/E.
Yes. The prompts are done by RSTS/E, and the error comes from MIM
because you are not specifying a user, and your RSTS/E system are not
providing any proxy information as an alternative.
Ok. Thanks for the insight. I will try to figure out how to set up
proxy info in DECnet/E. You may see me pecking on MIM a bit over the
weekend as I try to get this working.
No worries. Keep experimenting. Just FYI - In VMS and RSX, the commands are:
NCP SET EXEC INCOMING PROXY ENABLED
NCP SET EXEC OUTGOING PROXY ENABLED
(Although you'll only need the outgoing proxy for getting it to work in a nicer way to MIM from your system.)
On RSTS, there is no such thing as outgoing proxy. You specify access information or not; if not, then that seems to be what you need to get proxy.
Inbound, exec characteristic "default account" specifies the account to use for objects that have Verification=On (meaning access control is used) if no access control data is given. If that isn't set, you don't get default access. If a default account is set, that is used for default access without any password check; even if the account normally requires a password, the fact that it is the default lets you get in that way.
If you specify an account but no password, that is accepted if the account is marked as "no password required".
paul
On 2012-11-02 19:50, Dave McGuire wrote:
On 11/02/2012 05:23 AM, Johnny Billquist wrote:
$ DIR MIM::DU:[FORTH]
And I'm getting this: (just hitting <cr> at the user/password prompts)
?$ dir mim::du:[forth]
Node: MIM
User:
Password:
System Password:
?NFT -- Connection rejected to node MIM
?NFT -- Access not permitted
Again, this is only from RSTS/E.
Yes. The prompts are done by RSTS/E, and the error comes from MIM
because you are not specifying a user, and your RSTS/E system are not
providing any proxy information as an alternative.
Ok. Thanks for the insight. I will try to figure out how to set up
proxy info in DECnet/E. You may see me pecking on MIM a bit over the
weekend as I try to get this working.
No worries. Keep experimenting. Just FYI - In VMS and RSX, the commands are:
NCP SET EXEC INCOMING PROXY ENABLED
NCP SET EXEC OUTGOING PROXY ENABLED
(Although you'll only need the outgoing proxy for getting it to work in a nicer way to MIM from your system.)
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On Nov 2, 2012, at 10:27, "Bob Armstrong" <bob at jfcl.com> wrote:
Brian Hechinger wrote:
Is it just me or does the whole conversion of serial to modem to pots
to voip back and forth there seem a little excessive?
I thought people wanted to experience the lights blinking on their DF03 sitting next to their VT100....
I certainly wouldn't want to get in the way of that of course. I was mainly thinking from my point of view. I have asterisk talking through google voice for my non-cell voice needs and the quality tends to be a little rough at times. I don't think modems would talk well over that (if at all) and I don't get to control the compression.
If I knew I wasnot moving for a while I could see getting a POTS line for this, but in the meantime that isn't going to happen. :)
So I had an idea. What about a software modem that natively talks VoIP.
How about an open source codec that knows how to speak Bell 103/212/v.22/etc and then just sends the actual data over IP to its counterpart on the other end?
That should be easy enough I would think. There were lots of good emails with lots of great info in them. I'm going to research all those and see what I come up with.
You know, as soon as Internet service returns. :)
-brian
On Nov 2, 2012, at 6:14 PM, Peter Lothberg wrote:
If you guys actually try to do DECnet over radio I'd be interested...
=20
As long as you have a link-layer that takes a packet in and spit's it
out on the other side, taking care of retransmission, FEC coding etc,
it should work.
More precisely, you need either (a) a point to point reliable channel (anal=
ogous to DDCMP) or (b) a multicast datagram channel (analogous to Ethernet)=
.
IP over packet radio uses the latter, via the datagram mode of AX.25. That=
's a reasonable option for DECnet as well if the packet loss rate is low. =
If it's high, then the connection mode of AX.25 is a more efficient option,=
in spite of the design bugs that AX.25 inherited from X.25 and HDLC.
I was assuming using the "PTP" link mode.
The "error profile" of a HF chanel is such that the chances of
transmitting a packet without error with just HDLC decreeses with the
lenght of the packet. Ie, you might retransmitt the 576 byte packet
forever, having different bits being corupted every time.
To do this succesfull on a HF chanel, you need some kind of forward
error correct scheme.
There is a "hard decition" FEC named CI-BCH-3, that does better than
10db.
AX.25/HDLC likes VHF FM chanels with HIFI quality.
-P
On Nov 2, 2012, at 6:14 PM, Peter Lothberg wrote:
If you guys actually try to do DECnet over radio I'd be interested...
As long as you have a link-layer that takes a packet in and spit's it
out on the other side, taking care of retransmission, FEC coding etc,
it should work.
More precisely, you need either (a) a point to point reliable channel (analogous to DDCMP) or (b) a multicast datagram channel (analogous to Ethernet).
IP over packet radio uses the latter, via the datagram mode of AX.25. That's a reasonable option for DECnet as well if the packet loss rate is low. If it's high, then the connection mode of AX.25 is a more efficient option, in spite of the design bugs that AX.25 inherited from X.25 and HDLC.
paul
If you guys actually try to do DECnet over radio I'd be interested...
As long as you have a link-layer that takes a packet in and spit's it
out on the other side, taking care of retransmission, FEC coding etc,
it should work.
S9 on a clean 2.2Khz chanel is almost 2000 bit/s -:)
--P
On Nov 2, 2012, at 10:21, Cory Smelosky <b4 at gewt.net> wrote:
On Nov 2, 2012, at 10:14 AM, Brian Hechinger <wonko at 4amlunch.net> wrote:
Am I nuts?
Yes, but I like the idea.
Of corse you do. Compared to some of your ideas this is downright sane!!
:)
-brian
