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