Rooted logical over decnet

[Mike Smith_33]

I have set up a proxy from john at node65 into peter at node46 as a default proxy. Peter has re access to the product directory. The proxy works as validated by a directory of node46::[product.xx] producing a listing.

I then defined a rooted logical as follows
$defi/sys/exec/trans=conc newlog nod46::[product.xx.]

Trying to access the directory as newlog:[000000] produces the following:

-RMS-F-DEV, error in device name or inappropriate device type for operation

Can you use rooted logicals over Decnet like I am trying to do?

[Dale A. Marcy]

I have not used rooted logicals like this, but have used regular logicals. I think the logical is being translated on the remote node where NEWLOG is not defined. I think what you need to do is change your procedure to specify the node::logical_name: and have logical name define on the remote system. In my case, because I needed to change it based on disk space, I created a login.com for the remote account that checks disk space on the target disks and defines the disk and directory based on the disk with the most available space.

[Dale A. Marcy]

I just re-read the thread and the first part of what I said does not make sense. The logical would have to be translated on the local node, because it would not know the remote node until it translated that logical.

[Dale A. Marcy]

I just tested and the problem is the /trans=conc. It will work if you remove that portion. I assume this is because the concealed does not allow it to pass the translation over to the remote system.

[Mike Smith_33]

The way the dba needs to access this, he needs to be able to move through it like a rooted logical.

On node46 there is a local rooted logical pointing into the directory structure he needs to access. We are trying to duplicated that remotely.

[Dale A. Marcy]

I think he should be able to use node46::rooted_logical:[000000] as long as rooted_logical is defined on node46.

[Mike Smith_33]

You are correct, but how do we put that into a logical? Outside of a logical it works great.

[Dale A. Marcy]

If you do not have to have the local logical concealed it will work.

$ define/sys/exec newlog node46::rooted_logical:

If it has to be concealed, I do not have an answer. Again, rooted_logical needs to be defined on the remote node.

[John Gillings]

Mike,

File specifications must fit the syntax:

:::[]

A fairly simple rule to help explain this is that everything to the right of the "::" happens on the REMOTE node. Consider that even with DECnet, the remote host doesn't need to be OpenVMS, so the local host just passes the filespec string direct to the remote host without interpretation.

Since "[product.xx.][000000]" is not a valid file specification, there is no way to pass a correct file specification to the other host. In fact the RMS-F-DEV error occurs before DECnet involvement. There is no attempt to make a network connection because a concealed device specification must, by definition, be part of the DEVICE field of a file specification, and therefore cannot contain a node specification.

As Dale has already pointed out, you need to have the rooted logical name defined on the remote host.

>On node46 there is a local rooted logical
>pointing into the directory structure he
>needs to access. We are trying to
>duplicated that remotely.

Good! So, you already have the remote logical name. Your local logical name needs to be defined in terms of the NODE46 logical name. For example, assume the remote logical name is:

$ DEFINE/TRANS=CONCEALED NODE46_ROOT:[PRODUCT.XX.]

You need to define your logical name as:

$ DEFINE NEWLOG NODE46::NODE46_ROOT:

You can then use

$ DIRECTORY NEWLOG:[000000]

or with any other directory specification, exactly the same as you would use the logical name NODE46_ROOT on NODE46.

[Mike Smith_33]

You guys are correct, I just do not know whether this will cause an issue locally. I have left the dba a voicemail. We have a production database on node46 with the rooted logical as part of the standard setup. He now has a development database on node64 and is trying to import directly from production into development. Since the application normally expects a rooted logical, I am not sure what effect this will have.