Between a Rock and a Hard Place!

Individual files in an HFS (Hierarchical File System) must always be accessed through the OMVS kernel. Therefore, SMP/E is "OMVS aware":

a new HFS element type (++HFS) and HFS-associated MCS parameters have been introduced. SMP/E understands OMVS permission bits.
DDDEFs can point to directories within an HFS
SMP/E incorporates a new utility used to load HFS objects, BPXCOPY
to install maintenance into an HFS requires that an OMVS kernel be running
anyone who needs to install maintenance into an HFS must be defined as an OMVS "super user"

Note that the modules required to run the OMVS kernel are loaded into standard MVS load libraries. Most of the utilities used by OMVS users are loaded into the HFS; there is a "permission bit" called the "sticky bit" which indicates that the program should be fetched from MVS libraries rather than the executable file in the HFS. This feature is typically used for highly-used programs such as the OMVS shell, which is the "startup program" for most users in the OMVS environment.

Good Housekeeping Note

Although the HFS containing the SMP/E target files must be "mounted" (online and available to OMVS), you should not install maintenance onto the running system. One method is to install maintenance into an HFS that mirrors the structure of the production environment. This HFS can be used as a test environment and then later swapped into the production location. For fallback, you can swap the original HFS back in.

SMP/E maintenance to HFS files often makes use of a "hard link" to define a copy of an HFS file in an alternate location. This is similar to an alias in a PDS - essentially, there are two pointers to the same file. However, extreme care is required when attempting to rollin maintenance selectively on a file by file or directory by directory basis. For more information, refer to SMP/E and Hard Links

SMP/E at OS/390 V2R7 and up incorporates support for symbolic links. While this type of link is more flexible, the existence of a symbolic link does not guarantee the existence of the "real" HFS file. Thus, you can have "orphan" symbolic links that point to a nonexistent HFS file.

Speaking of Super Users

An OMVS user with uid=0 is a "super user". This means that they can access any file in any HFS which is available to OMVS. In an OMVS world, there is no distinction between the "super user" who installs maintenance and the "super user" who administers the system. You may wish to take this into account when planning your backup strategy.

SMP/E at OS/390 V2R7 and up allows a non-"super user" to install maintenance into HFS (if authorized for BPX.SUPERUSER).

See Checking out Unix System Services Executables for information about finding internal timestamps for programs stored in the HFS. See SMP/E for more general information on SMP/E.