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