Symbolic and external links with a sticky bit

The following behavior applies to DLLs and all forms of spawn() and exec(). What applies for exec() also applies for all forms of module loading.

External links
exec() does a stat() on the passed file name. stat() does the search, not exec(). If the file name is an external link, then stat() fails with a unique reason code which causes exec() to read the external link. If the external link name is a valid PDS member name (that is, 1 - 8 alphanumeric or special characters), then exec() attempts to locate the module in the MVS™ search order. If it cannot find the module, exec() fails.

The external link is normally used when you want to set the sticky bit on for a file name which is longer than eight characters or contains characters that are unacceptable for a PDS member name.
Symbolic links
If the file name you specify is a symbolic link and exec() sees the sticky bit on, then it truncates any dot qualifiers. As long as the base file name is an acceptable PDS member name, the need to set up links in order to get exec() to go to the MVS search order should not be an issue.

For example, if you have a file named java.jll, when you set the sticky bit on, exec() attempts to load a member named JAVA. If exec() cannot find JAVA, it reverts to using the java.jll file in the file system.

The important thing to understand is that exec() never sees the name that the symbolic link resolves to, even though it can see the stat() data for the final file.

Example: If you define /u/user1/name1 as a symbolic link to /u/user1/name2 and then invoke name1, the following occurs:

The shell will spawn name1.
spawn() will access the file for name1, unaware that there is a symbolic link already established. It will access the name2 file by its underlying vnode, not by the name2 handle.
If the sticky bit is on for the name2 file, spawn() will do the MVS search for name1 (the only name it has to work with).