Upgrade from Decnet IV to Decnet V

[Guillou_2]

Hi,

I am trying to install Decnet V in order to replace Decnet IV on our vax 4000-200 with VMS 6.2 and UCX V4.2 eco3).

I follow the install guide, all is ok during the installation.

My final goal is to configure Decnet over TCPIP. After configuring it with the net$configure menu, during reboot I see that some command of the ncl script doesn't work.
I have message like this:
"ncl-e-invalid command, unrecognized command
set osi transport \RFC1006\ listener ports={102,399}"

After the reboot, the server can do a set host ip$xxxxx to another server but a set host ip$xxxx to it or to himself doesn't work.

With a ucx sho dev, I can't see a listener for the port 399, a telnet on this port is impossible. The process PWIP_ACP is ok.

The flush command and show node 0 doesn 't work in NCL.
NCL>flush session control naming cache entry "*"_
%NCL-E-INVALIDCOMMAND, unrecognized command__\flush\ session control naming cache entry "*"

Show address give something like this:
NCL>sho address
Show Node 0
at 2005-01-22-10:42:38.73000 + 00:00 I 28147497.67107

Identifiers
Address = {{{%X0113}, {DNA$ProtID$SessCtlV3 Number = 19}, {DNA$ProtID$OSI %XDEC0}, {DNA$ProtID$RoutingV3 49::00-01:AA-00-04-00-6B-
04:21}}, {{%X0113}, {DNA$ProtID$SessCtlV2 Number = 19}, {DNA$ProtID$OSI %XDEC0}, {%X09 %X15003851}}, {{%X0113}, {DNA$ProtID$SessCtl
V3 Number = 19}, {DNA$ProtID$NSP}, {DNA$ProtID$RoutingV3 49::00-01:AA-00-04-00-6B-04:20}}}

I am totally lost, someone already saw this kind of problem?

regards

Steph

[Joseph Huber_1]

To enable Decnet-over-IP in Your UCX system,
You have also to configure and start the PWIP driver/server in ucx$config menu option 4
"optional components".

Then, in order to use You TCPIP DNS names instead of IP$xxxxxx, add Domain to the list of
decnet name services in net$configure.

>... Node 0 ... not working etc.
might be simply a consequence of the IP transport not working, anyhow (re)do the naming setup with net$configure and see.
Eventually check with decnet_register, if the node is defined correctly.

[Daniel Fernandez Illan]

Hi Steph

have you execute net$configure after migrate to DECnet phase V?.
When you use NCL>sho node 0. Do you obtain a node name included in database (decnet_register tool)?
It's possible that you node isn't defined to DECnet.
Regards
Daniel

[Volker Halle]

Steph,

the errors you describe look like something is wrong with the NCL syntax/parsing tables. Maybe a bad NCL$GLOBALSECTION.DAT file ?

If the RFC1006 listener ports aren't defined, you can't connect to the system with DECnet-over-IP.

Which version of DECnet-OSI for OpenVMS VAX are you running ? Have you installed any DECnet-OSI patch (MC NCL SHOW IMPL) ?

We're running a VAX V6.2 system with DECnet-OSI V6.3-ECO04 and UCX V4.2 ECO 1 and DECnet-over-IP works fine...

Volker.

[Guillou_2]

After migrating to decnet osi net$configure was executed, the local and domain were defined in the decnet name service, the pwip driver was started, nodes were registered in the local database with decnet register.

We try to install decnet osi v6.3, the patch eco 5 was added but the problem persist.
All the other server that we manage have this product and work fine.

I think that the RFC1006 isn t configured even if I use the option 4 of net$configure.
I attached a file with the result of some command.

Steph

[Joseph Huber_1]

One point in Your screen listing of UCX show dev:
port 102 is there, but port 399 is not present, and 399 is the one for decnet-over-ip.

Did You really configure PWIP , not just option 4 in net$configure ?
Option 4 in UCX$CONFIG, then stop/start UCX !

No clue otherwise where the ncl "syntax" errors come from, the ncl commands look correct, and on my system they work.
(but mines is VMS 7.3-1 , and I can't go back so far as 6.x to check :-).

[Daniel Fernandez Illan]

Hi Steph.
When use net$configure, you need create a OSI template for decnet over TCP/IP.
You need answer yes to question:
* Do you want to create additional OSI templates? [NO] :
and continue with the procedure.

See:
http://h71000.www7.hp.com/doc/73final/6497/6497pro_002.html#index_x_119
for more information.

Saludos.
Daniel.

[Volker Halle]

Steph,

NCL on your system refuses to accept the network service name of RFC1006. For OpenVMS, this is a valid network service name. I don't think you can configure/manipulate the existence of those network services.

Could there be a bad SYS$SHARE:NCL$GLOBALSECTION.DAT file on this node ? If the NCL commands refering to 'RFC1006' would not be rejected by NCL; they should set up the necessary config to allow DECnet-over-IP to work. You don't have to create additional OSI transport templates - they are provided by default.

Vague guess: could there be other products installed on this node, which may also provide a NCL$GLOBALSECTION.DAT file (e.g. DECnis ) ?

Volker.

[Guillou_2]

Hi all,

I try to investigate the problem with the information given by Volker and I can see that:

Before upgrade:
dirf [*...]*globalsection*

Directory $1$DIA0:[SYS0.SYSLIB]

NCL$GLOBALSECTION.DAT;1 9741 28-MAR-1995 14:08:43.94 (RWED,RWED,RE,RWED)

Total of 1 file, 9741 blocks.

Sho dev /file
00000000 [SYS0.SYSLIB]NCL$GLOBALSECTION.DAT;1

run files_info.exe
_Filespec: $1$dia0:[SYS0.SYSLIB]NCL$GLOBALSECTION.DAT

FILE: _$1$DIA0:[SYS0.SYSLIB]NCL$GLOBALSECTION.DAT;1
Total access count of 1, XQP access 1, writers 0, size 9741/9744

PID USERNAME READS WRITES ACCESS CHARACTERISTICS
-------- ------------ -------- -------- ----------------------
00000000 VMS 42 0 Read, Cathedral, Complete, NoWriteShr

After upgrade three ncl$globalsection were added in [vms$common.syslib], [syse$syscommon.syslib] and [sys0.syscommon.syslib].
These files have the same size (27283 blocs) and the creation date is 31-oct-1995

If I compare with another server working with same os, ucx and decnet osi version, I can't find the first file I only find the three files added by Decnet_osi.

[Volker Halle]

Steph,

that looks very suspicious !

You seem to have an old/bad NLC$GLOBALSECTIONS.DAT file in SYS$SPECIFIC:[SYSLIB]

The correct file (and it's only ONE file, not 3) has to be in SYS$COMMON:[SYSLIB] and will have been updated there by DECNET_OSI. If you would do a DIR/FILE_ID you'll see, that it's the SAME file (same file-id) which shows up 3 times due to the VMS system disk structure (different roots on a system disk).

The easiest way to recover would be to rename the file in $1$DIA0:[SYS0.SYSLIB] and reboot.

Volker.