VMS ODS-5 symlinks are a POS IX. The support in the Linux ods5 file system is
limited or maybe I should say experimental.

Following symbolic links is off by default. To get symlink support, mount with -o syml

On VMS (with the default settings for a process, that is after a "set

$ copy tt: hello
Hello World!
[ Exit ]
$ create/symlink="hello" world

This results in the files

HELLO.;1 and WORLD.;1 with world containing "hello" as a symbolic link. And a 

$ type world.
Hello World!

gives the somehow expected result.

The problem here is, the symbolic link, the contents of WORLD.;1, is not an
ODS-5 filename! How can the Linux ods5 file system ever find this?

The lookup method is an inode operation and now has to find both, ODS-5 files
with version and - as a result of following a symbolic link - the last version
of an ODS-5 file without a version specified or even a directory file without
the .DIR type.

Simplified, this is done with looking for the version delimiter. If the
ods5_lookup sees it, then we do an ordinary lookup, if it sees none, then we
do a symbolic link lookup.

Even with sophisticated checks if the ';' delimits a version number, this
creates several problems

1. A symbolic link to a file "a.b;1" which is the ODS-5 target "a.b^;1;0"
will incorrectly lookup the different ODS-5 file "a.b;1".

2. Version-less file specifications are allowed and show as such! This was
never intended! But with file completion the versions are added.

3. Dirless directories work! This was intended to be available only with a
separate option. But with file completion the .DIR type is added.

4. The option dotversion makes this more complicated.

Symbolic links to ODS-5 files like "a.b^;1;1" are likely rare. Symbolic links
to ODS-5 files like "a.1" are probably more common. Both will not be
correctly resolved.

Therefore, syml disables dotversion and the check for a version is simply
the check for any ";" in a filename.