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.

[Jan van den Ende]

Mike,

just tell him that in this case, because of the network, his "rooted" name contains "::" :-)
-- just as long as he is not going to evaluate the logical name!

Proost.

Have one on me.

jpe

[John Gillings]

Mike,

>You guys are correct, I just do not
>know whether this will cause an issue
>locally.

Shouldn't be a problem. Just make the logical name on all nodes identical.

So, on NODE46...

$ DEFINE/TRANS=CONC MYDATABASE dev:[dir.]

DBA on NODE46 can access stuff like:

$ TYPE MYDATABASE:[ACCOUNTS]MAY.REPORT

On any other node, define the same logical name as:

$ DEFINE MYDATABASE NODE46::MYDATABASE:

DBA can access stuff like:

$ TYPE MYDATABASE:[ACCOUNTS]MAY.REPORT

So, it's the same no matter where he is. The goal of DECnet making itself completely transparent is achieved.

How can this be a problem?

[Mike Smith_33]

I am not sure at this point, I have the dba doing testing verifying that his application works with the logical. So far so good.

[Mike Smith_33]

Ok guys, here is one possible problem that I am seeing. I have a proxy into node46 from node65. The logical on node65 points to node46::locallogical: and I have also set up acls for the proxy account on the entire filesystem, top down as follows:

test.dir (proxy_account, opt=default, rwed)
(proxy_account,rwed)


This should give the proxy account full access. We can read from and copy a file to the directory structure just fine but we can't create a directory on node46 from node65.

65->set def ingmm7:[ingres.ckp]
65->creat/dir [.test]
%CREATE-E-DIRNOTCRE, [.TEST] directory file not created
-LIB-F-INVFILSPE, invalid file specification


I have tried creating after setting default and without setting default. Same error. The software needs to create a directory during installation. As I said, I had no idea what issue we would find but I had a feeling we would find one. Any ideas? Is it something simple like adding control access to the acl??

[John Gillings · Accepted solution]

Mike,

65->set def ingmm7:[ingres.ckp]
65->creat/dir [.test]
%CREATE-E-DIRNOTCRE, [.TEST] directory file not created
-LIB-F-INVFILSPE, invalid file specification

Tricky!

Unfortunately CREATE/DIRECTORY doesn't understand network specifications. You can get around this by using a network task on the other end. Here are a pair of procedures. CREDIR.COM replaces the CREATE/DIRECTORY command. It will check the target directory specification. If it's on the local node, it just creates a directory. If not, it invokes the network object REMCREDIR.COM to perform the CREATE/DIRECTORY on the other node.

Put both procedures in the login directories on both nodes. Replace any CREATE/DIRECTORY commands on either node with @SYS$LOGIN:CREDIR. For more general use, place REMCREDIR in a central location and DEFINE/SYSTEM REMCREDIR full-file-spec.

(beware of wrapping!)
CREDIR.COM

$ stat="%X30001"
$ IF p1.EQS."" THEN READ/PROMPT="_File: "/ERROR=Quit/END=Quit SYS$COMMAND p1
$ ON WARNING THEN EXIT '$STATUS'
$ node=F$PARSE(p1,F$ENVIRONMENT("DEFAULT"),,"NODE")
$ IF node.EQS.""
$ THEN
$ CREATE/DIRECTORY 'p1'
$ stat=$STATUS
$ ELSE
$ dev=F$PARSE(p1,F$ENVIRONMENT("DEFAULT"),,"DEVICE")
$ dir=F$PARSE(p1,F$ENVIRONMENT("DEFAULT"),,"DIRECTORY")
$ OPEN/READ/WRITE net 'node'"0=REMCREDIR"
$ WRITE net "''dev'''dir'"
$ READ net stat
$ CLOSE net
$ ENDIF
$ Quit: EXIT 'stat'


REMCREDIR.COM
$ ON WARNING THEN CONTINUE
$ OPEN/READ/WRITE net SYS$NET:
$ READ/END=quit net line
$ CREATE/DIRECTORY 'line'
$ stat=$STATUS
$ WRITE net "''stat'"
$ CLOSE net
$ quit: EXIT

[John Gillings]

Oh, almost forgot...

Note that if you don't have complete control of the procedures containing the CREATE/DIRECTORY commands, it's also possible to modify CREDIR.COM so it can act as a replacement for all "CREATE" commands.

$ CR*EATE=="@somewhere:CREDIR"

Anything that isn't "CREATE/DIRECTORY" just gets executed directly. However, that's a bit more complex to implement correctly, so unless you really need it...

[Lawrence Czlapinski]

Mike, we just had a similiar situation where we had changed the physical device of a rooted logical. It turns out that for things to work properly the root had to be defined as a physical device.
So our solution was to define the roots as follows:
$!$ def/sys/exec std$disk _$1$DKA300: /trans=conc
$ phy_std$disk = f$getdvi("DEV_DISK_2","ROOTDEVNAM")
$ def/sys/exec std$disk 'phy_std$disk' /trans=conc
$ phy_maint$disk = f$getdvi("DEV_DISK_1","ROOTDEVNAM")
$ def/sys/exec maint$disk 'phy_maint$disk' /trans=conc
This allowed us to change the root's physical disk without bringing the system down. You would want to shutdown the applications that are using the roots first.
Lawrence

[Lawrence Czlapinski]

Mike, then I was able to use the rooted logical over DECnet:
ASDEV1» dir cnaxp1::std$disk:[000000]
worked successfully
Lawrence

[Lawrence Czlapinski]

Mike, as stated by others, the logical needs to be defined on the remote node.
Lawrence