Remote procedure on DecNet V

[Antoniov.]

I migrated a decnet IV host to decnet V (VMS V7.3-2). In my network there is a old alpha with V6.2 and DecNet IV.
Before migration, on old alpha I could type
$ TYPE NEW::"0=mycmd"
where mycmd was an object recorded in NCP database of NEW alpha.
Hence new alpha has DecNet V reither this command can't work nor simple remote command like $ DIR NEW::*.*
I checked for proxy database. It's fine.
How can I run a remote procedure or remote command on new DecNet V ?
I'm newbie in DecNet OSI :-(

Antonio Vigliotti

[Uwe Zessin]

Does it work if you put a username/password into the ACS? e.g.:
$ directory NEW"username password"::

Any error message?

[Ian Miller.]

You need to define a session control application

@SYS$STARTUP:NET$CONFIGURE ADVANCED

select option for 'Configure application database'
then select option for ADD
and follow the prompts.

The result of this is a new NET$SESSION_STARTUP.NCL

[Bojan Nemec]

Antonio,

I have no DECNet V installed (I prefer to work with the old good phase IV ;). I find a procedure which I wrote some years ago to create a DECNet V object:

CREATE NODE 0 SESSION CONTROL APPLICATION
SET NODE 0 SESSION CONTROL APPLICATION -
ADDRESSES = {NUMBER = } -
,CLIENT = -
,INCOMING ALIAS = TRUE -
,INCOMING PROXY = FALSE -
,OUTGOING ALIAS = FALSE -
,OUTGOING PROXY = FALSE -
,NODE SYNONYM = TRUE -
,IMAGE NAME = -
,USER NAME = "" -
,INCOMING OSI TSEL =

Which is equivalent to old NCP:

NCP> DEFINE OBJECT NUMBER -
FILE -
OUTGOING CONNECT PRIVILEGES -

USER PASSWORD

You put this in SYS$MANAGER:NET$APPLICATION_STARTUP.NCL

Bojan

[Joseph Huber_1]

Apparently You have no TASK object defined. (don't know if that's omitted by net$configure with a cause).

Define it in net$application_local.ncl like that:

CREATE NODE 0 SESSION CONTROL APPLICATION TASK
SET NODE 0 SESSION CONTROL APPLICATION TASK ADDRESSES = {NAME=TASK} -
,CLIENT = -
,INCOMING ALIAS = TRUE -
,INCOMING PROXY = TRUE -
,OUTGOING ALIAS = FALSE -
,OUTGOING PROXY = TRUE -
,NODE SYNONYM = TRUE -
,INCOMING OSI TSEL = -
,USER NAME = "ILLEGAL"

The user name ILLEGAL makes sure only proxy accounts can use it (assuming You have no legal user named ILLEGAL :-).

For others like FAL , lookin NET$APPLICATION_STARTUP.NCL, I wonder what happened when You NET$COMNFIGUREd.
Eventually copy a sample from my location:

http://wwwvms.mppmu.mpg.de/vms$common/sysmgr/net$application_startup.ncl

[Wim Van den Wyngaert]

Before you create objects, check what you have.

mc ncl show ses con app xxx [all]

xxx = TASK for T2T
xxx = FAL for remote file access
xxx = * to see them all

Wim

[Antoniov.]

Wow,
how many answer!

Uwe,
yes, with direct password it works but I don't want supply username and password.

Ian,
executed procedure but it yet doesn't work. I'm not sure about parameter supplied.

Bojan,
I saw in SYS$STARTUP:NET$APPLICATION_STARTUP.NCL
my definition by above Ian's procedure
!* Session Control Application MYDCL added
!* 13-SEP-2005 17:07:32.11 by SYSTEM
CREATE NODE 0 SESSION CONTROL APPLICATION MYDCL
SET NODE 0 SESSION CONTROL APPLICATION MYDCL ADDRESSES = {NAME=MYDCL} -
,CLIENT = -
,INCOMING ALIAS = TRUE -
,INCOMING PROXY = TRUE -
,OUTGOING ALIAS = FALSE -
,OUTGOING PROXY = TRUE -
,NODE SYNONYM = TRUE -
,IMAGE NAME = USR$BIN:MYDCL.COM -
,INCOMING OSI TSEL =
I deletede USERNAME because I want to use proxy.

Joseph,
I addes USERNAME="ILLEGAL"
It seems doesn't work

Wim
MC NCL SHOW SESS CON APPL MYDCL
show me

Node 0 Session Control Application MYDCL
at 2005-09-13-17:23:23.690+02:00Iinf

Identifiers

Name = MYDCL


Thank to allbodies.

Antonio Vigliotti

[Antoniov.]

Because I can't execute remote command,
I wanto to simply my trouble.
At moment I want type
$ DIR NEW::*.*
on old alpha and see dir on new alpha

Antonio Vigliotti

[Ian Miller.]

"$ DIR NEW::*.*
on old alpha and see dir on new alpha"

If the proxies are right on the new alpha then this should work - does it?

[Uwe Zessin]

If it works with explicit username and password, then you can expect the object to be working and there is something wrong with the proxy processing.

Again, may I ask if you got any error message?

- anything from OPCOM?
$ reply/enable=network

- something in the ACCOUNTING or AUDIT logs?

[Antoniov.]

Nope Ian,
I have on old
NEW::USER USER /DEFAULT
and on new
OLD::USER USER /DEFAULT
I have same username on both systems.
I set /default on both systems.

Antonio Vigliotti

[Wim Van den Wyngaert]

mc authorize show /prox *

The (D)default is not missing ?
Try with username only.

Wim

[Antoniov.]

It's weird.
On old
$ DIR NEW::*.*
%DIRECT-E-OPENIN, error opening NEW::*.*;* as input
-RMS-E-FND, ACP file or directory lookup failed
-SYSTEM-F-INVLOGIN, login information invalid at remote node

It appears as I have not proxy on new server.

On new server
UAF> sh */proxy

Default proxies are flagged with (D)

NEW::BRUNOG
BRUNOG (D)

NEW::SYSTEM
SYSTEM (D)

NEW::ANTONIOV
ANTONIOV (D)

NEW::USER
USER (D)

On old system I type DIR as ANTONIOV user.

Antonio Vigliotti

[Wim Van den Wyngaert]

Antonio,

You don't have to declare mydcl. Only task or fal. Make sure all settings shown are the same as in enclosure.

Wim

[Antoniov.]

Wim,
my system shows information like yours.
Obviously UID is different.
For task also username is different; in your log there is *DECNET_TASK* while in my system is
For fal,
I have no got name FAL in addresses section, just then number 17.
Your username is FAL$SERVER, my username is

Antonio Vigliotti

[Uwe Zessin · Accepted solution]

Don't you need a Phase V style entry like ?
LOCAL:.OLD::USER USER (D)

[Bojan Nemec]

Uwe,

I think you are right.

Antonio:
See the documentation:

http://h71000.www7.hp.com/doc/73final/6499/6499pro_009.html

Bojan

[Robert_Boyd]

Antonio,

If the output you supplied from SHOW PROXY on the new system, you do not have an entry that will match on connections from the OLD system.

What happens if you try

UAF> add/proxy old::username username/def
UAF> show/proxy *::*

?

Robert

[Antoniov.]

Uwe,
bingo!
I declared old decnet style proxy.
With local:.old::user user (decnet new style) now it works fine.
Just solved 1.st trouble, I try remote procedure.

Antonio Vigliotti

[Antoniov.]

At first glance also remote procedure seems to work.
Trouble was proxy database.
However I discovered some new feature about Decnet OSI.
Thank to allbodies.

Antonio Vigliotti

[Uwe Zessin]

Congratulations!
I'm just glad that the other stuff like nodename database and so on was set up correctly ;-)
Else, it would have been a more interesting session!

[John Gillings]

Antoniov,

There's a program to convert your old proxy data base into the new format. SYS$UPDATE:NET$CONVERT_DATABASE It's recommended as part of your update to Phase V.

To get proxies right, it's worth turning on LOGIN and LOGFAIL alarms and checking the OPCOM messages from a test connection - they will tell you exactly what the incoming user is seen as (ie: "node::" or "local:.node" etc...)

[Michael Yu_3]

Hi Antonio,

There are two proxy files, net$proxy.dat and netproxy.dat. Net$proxy.dat is used for phase V style full name while netproxy.dat is used for phase IV compatibility.

There is a program in sys$system, called convert_proxy.exe, which can convert the old proxy records in netproxy.dat to net$proxy.dat.

You may need mutiple entries in the proxy database for the same remote user if you are using multiple namespaces in your network.

Thanks and regards.

Michael

[Wim Van den Wyngaert]

Antonio,

What I don't understand is how you got the errorneous proxies. Manually addding a proxy adds the local word automatically.
Didn't the migration procedure convert them ?

Wim
(prefers fresh installs above upgrades)

[Antoniov.]

I know convert_database because at first time I comverted old vms and decnet in new vms and decnet. System worked fine.
I repeated installation from scratch, initializing system disk, so I added manually proxy. But I'm newbie in decnet V so I used old style.

Antonio Vigliotti