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.
A crucible of informative mistakes
