topic Re: Creating files under SYSROOT:[SYSMGR].. in Operating System - OpenVMS

Creating files under SYSROOT:[SYSMGR]..

Muthuvel.B — Wed, 16 Mar 2005 04:12:30 GMT

Hi,

We can't edit the files created under SYS$SYSROOT:[SYSMGR.'SUBDIR'] whereas it can be done in SYS$COMMON:[SYSMGR]though the directory pointed by the logical SYS$MANAGER points to both the directories as specified above.

Can anyone explain why is it like this?

Muthuvel.B

Re: Creating files under SYSROOT:[SYSMGR]..

Ian Miller. — Wed, 16 Mar 2005 04:35:05 GMT

If you look at the two logicals SYS$SYSROOT and SYS$COMMON you will discover that SYS$SSYROOT translate to two places and SYS$COMMON: translates to 1. Say you have a system disk DKA0. You have created a directory SYS$COMMON:[SYSMGR.SUBDIR] so this is DKA0:[VMS$COMMON.SYSMGR.SUBDIR].
If you look at SYS$SYSROOT:[SYSMGR.SUBDIR] that translates to two places
DKA0:[SYS0.SYSMGR.SUBDIR] and DKA0:[VMS$COMMON.SYSMGR.SUBDIR]

SYS$COMMON:[SYSMGR.SUBDIR] translates to DKA0:[VMS$COMMON.SYSMGR.SUBDIR] only.

If you read a file in SYS$SYSROOT:[SYSMGR.SUBDIR] then VMS searches both, however if you create a file then VMS attempts to use the first translation only (which fails).

See for example
http://h71000.www7.hp.com/doc/731FINAL/4477/4477pro_006.html#index_x_341

Re: Creating files under SYSROOT:[SYSMGR]..

Kris Clippeleyr — Wed, 16 Mar 2005 04:58:46 GMT

Hi,

I'm not sure exactly what phenomenon you are taking about.
But, the logical SYS$MANAGER should be translated as SYS$SYSROOT:[SYSMGR]; the logical SYS$SYSROOT should translate to the$disk:[SYSx.], where the$disk is your system disk & SYSx is your system's root (e.g. SYS0, SYS1, etc.). This is the "specific" side of things; SYS$SYSROOT is further translated as SYS$COMMON:. SYS$COMMON is then translated as the$disk:[SYSx.SYSCOMMON.]. The SYSCOMMON.DIR is an "entered" file, i.e. it's the same file as the$disk:[000000]VMS$COMMON.DIR. (Have a look at the file ids (DIREC/FILE)); this is the "common" side of things.
Although both directories "the$disk:[SYSx]" and "the$disk:[SYSx.SYSCOMMON]" have a SYSMGR.DIR in them, these files are *NOT* the same.
If the logical names sys$sysroot, sys$manager, and the like, are not altered, I see no reason that you have trouble accessing files via SYS$SYSROOT:[SYSMGR.subdir], even if the 'subdir' is created in the SYS$COMMON:[SYSMGR] directory.

For further reading, see
http://h71000.www7.hp.com/doc/731FINAL/4477/4477pro_006.html#common_dir_structure

Hope this helps.
Kris (aka Qkcl)

Re: Creating files under SYSROOT:[SYSMGR]..

Ian Miller. — Wed, 16 Mar 2005 06:17:34 GMT

Kris,
Consider this

Directory SYS$SYSROOT:[SYSMGR]

DT.DIR;1

Total of 2 files.

Directory SYS$COMMON:[SYSMGR]
VAXINFO$PRODUCTS.DIR;1

Total of 3 files.

Grand total of 2 directories, 5 files.
$ cre sys$sysroot:[sysmgr.vaxinfo$products]x.x
%CREATE-E-OPENOUT, error opening SYS$SYSROOT:[SYSMGR.VAXINFO$PRODUCTS]X.X; as output
-RMS-E-DNF, directory not found
-SYSTEM-W-NOSUCHFILE, no such file

but
$ cre sys$common:[sysmgr.vaxinfo$products]x.x

succeeds. And then reading the file also succeeds.
$ dir sys$sysroot:[sysmgr.vaxinfo$products]x.x

Directory SYS$COMMON:[SYSMGR.VAXINFO$PRODUCTS]

X.X;1

Re: Creating files under SYSROOT:[SYSMGR]..

Kris Clippeleyr — Wed, 16 Mar 2005 06:51:18 GMT

Ian,

I was somewhat mislead by the sentence

We can't edit the files created under...

I assumed that the files to be edited were already there (although in SYS$COMMON:[SYSMGR.subdir]). If so, you can edit them via the path SYS$SYSROOT:[SYSMGR.subdir], newer versions are still created in SYS$COMMON. Creating a new file via SYS$SYSROOT:[SYSMGR.subdir] is indeed not possible if 'subdir' does not exist on the "specific" side.

Regards,
Kris (aka Qkcl)

Re: Creating files under SYSROOT:[SYSMGR]..

David B Sneddon — Wed, 16 Mar 2005 06:52:19 GMT

What editor are you using?

zen_FTA14> create/directory sys$sysroot:[sysmgr.subdir]
zen_FTA14> create sys$sysroot:[sysmgr.subdir]temp.dat
this is a file in sys$sysroot:[sysmgr.subdir]
zen_FTA14> dire sys$sysroot:[sysmgr.subdir]

Directory SYS$SYSROOT:[SYSMGR.SUBDIR]

TEMP.DAT;1 1/3 16-MAR-2005 11:45:42.

Total of 1 file, 1/3 blocks.
zen_FTA14> editt/teco/nocommand sys$sysroot:[sysmgr.subdir]temp.dat
*ht$$
this is a file in sys$sysroot:[sysmgr.subdir]
*ex$$
zen_FTA14> dire sys$sysroot:[sysmgr.subdir]

Directory SYS$SYSROOT:[SYSMGR.SUBDIR]

TEMP.DAT;2 1/3 16-MAR-2005 11:46:24.
TEMP.DAT;1 1/3 16-MAR-2005 11:45:42.

Total of 2 files, 2/6 blocks.

Regards
Dave

Re: Creating files under SYSROOT:[SYSMGR]..

Ian Miller. — Wed, 16 Mar 2005 07:06:46 GMT

Dave,
the difference with your example is that the subdir is in [sys%.sysmgr] not [vms$common.sysmgr]

Re: Creating files under SYSROOT:[SYSMGR]..

David B Sneddon — Wed, 16 Mar 2005 07:48:08 GMT

Take 2...

zen_FTA14> cre/dir sys$common:[sysmgr.subdir]
zen_FTA14> dire sys$sysroot:[sysmgr]subdir

Directory SYS$COMMON:[SYSMGR]

SUBDIR.DIR;1 1/3 16-MAR-2005 11:54:12.11

Total of 1 file, 1/3 blocks.
zen_FTA14> create sys$common:[sysmgr.subdir]temp.dat
this is a file in sys$common:[sysmgr.subdir]
zen_FTA14> editt/teco/nocommand sys$sysroot:[sysmgr.subdir]temp.dat
*ht$$
this is a file in sys$common:[sysmgr.subdir]
*ex$$

zen_FTA14> dire sys$sysroot:[sysmgr.subdir]

Directory SYS$COMMON:[SYSMGR.SUBDIR]

TEMP.DAT;2 1/3 16-MAR-2005 11:54:52.89
TEMP.DAT;1 1/3 16-MAR-2005 11:54:27.34

Total of 2 files, 2/6 blocks.

Attempting to *create* files in sys$sysroot:[sysmgr.subdir]
will fail if SUBDIR.DIR does not exist in the
specific root -- but *editing* works, as above.

As someone who only uses TECO, I have seen others
have various problems, hence my question about
what editor is being used.

Regards
Dave

Re: Creating files under SYSROOT:[SYSMGR]..

Kris Clippeleyr — Wed, 16 Mar 2005 08:17:13 GMT

Dave,

Attempting to *create* files in sys$sysroot:[sysmgr.subdir] will fail if SUBDIR.DIR does not exist in the specific root -- but *editing* works, as above.

That is exactly what Ian pointed out, and I overlooked (kinda).

As someone who only uses TECO, I have seen others have various problems, hence my question about what editor is being used.

I tried with EDIT/TPU and got the message "Directory not found". However, EDIT/EDT happily creates a new file in SYS$COMMON:[SYSMGR.subdir] (invoked as EDIT\/EDT SYS$SYSROOT:[SYSMGR.subdir]newfile.txt) even if the "subdir" does not exist on the "specific" side of things.

Regards,
Kris (aka Qkcl)

Re: Creating files under SYSROOT:[SYSMGR]..

David B Sneddon — Wed, 16 Mar 2005 09:19:19 GMT

Kris,

I just tried my previous example of the directory
in the SYS$COMMON tree and used EDIT/TPU and EDIT/EDT
specifying SYS$SYSROOT with no problems...
i.e. editing existing files. EDIT/TPU failed
to create a file as you report. The original
question was about editing files, not creating
them.

I think Muthuvel needs to provide an example of
exactly what commands are being used and the exact
error messages.

Regards
Dave

Re: Creating files under SYSROOT:[SYSMGR]..

John Gillings — Wed, 16 Mar 2005 15:31:50 GMT

As has been pointed out, SYS$SYSROOT is a search list of rooted logical names. For this to work correctly in all cases, the directory trees under each entry in the search list should be identical.

So, if you create a subdirectory:

SYS$COMMON:[SYSMGR.NEWDIR]

you should also create:

SYS$SPECIFIC:[SYSMGR.NEWDIR]

If the SYS$SPECIFIC directory doesn't exist then references to create files as:
SYS$SYSROOT:[SYSMGR.NEWDIR]
will fail because RMS will attempt to create a file in the first search list entry, which doesn't exist.

If you have your default set to SYS$SYSROOT:[SYSMGR.NEWDIR] and you attempt to edit a file in that directory, you may get several messages flashed up, along the lines of

Error searching for SYS$SYSROOT:[SYSMGR.NEWDIR].;
Directory not found
No such file

These are annoying, but don't actually affect the edit session.

When dealing with search lists, you need to be especially careful where files land. Try to refer to files in system roots using either SYS$SPECIFIC or SYS$COMMON, rather than by the search list name. When copying files, always use /LOG to make sure the file goes where you expect/require it to go.

If you want to create sub directories within system roots, it's a good idea to replicate them in all other system roots to avoid unexpected errors.

You should also become familiar with what files belong in the specific and common roots and make periodic checks to make sure they remain in the correct root.

I've included a command procedure SANITY_CHECK_ROOT.COM as an attachment (renamed to .TXT). It can be used to check for missing directories in search lists, and to find which files are obscured. Note that having files in the specific root obscure files in the common root is sometimes the whole point of having a search list, but it can also be a problem. Check any instances to make sure you understand why they exist.

Re: Creating files under SYSROOT:[SYSMGR]..

John Gillings — Wed, 16 Mar 2005 15:37:42 GMT

sorry, forgot to give an example...

$ @SANITY_CHECK_ROOT SYS$COMMON SYS$SPECIFIC SYSMGR

will check the SYSMGR directory in SYS$SPECIFIC against SYS$COMMON.

It will report any subdirectories found in SYS$COMMON:[SYSMGR] but not found in SYS$SPECIFIC:[SYSMGR]. It will also report any files in SYS$SPECIFIC:[SYSMGR] that obscure files in SYS$COMMON:[SYSMGR]

$ @SANITY_CHECK_ROOT SYS$COMMON SYS$SPECIFIC SYSMGR *.COM

will do the same, but only check .COM files

$ @SANITY_CHECK_ROOT SYS$COMMON SYS$SPECIFIC SYSMGR *.* CREATE

will CREATE any missing subdirectories in SYS$SPECIFIC:[SYSMGR]