Installing service into the z/OS UNIX file system

Some customers install service in response to a particular problem that they experience; some customers install service to prevent problems from occurring. This latter method is called preventive service. In either case, service is installed into the file system in a way similar to how it is installed into MVS™ data sets. This topic describes how to install service.

To install service, system programmers create a copy of the system that they are migrating from onto another pack. Sometimes the system that they are migrating from is the active production-level system, called the driving system. This new copy is called the target system. The DDDEFs or the DD statements in the cataloged procedure that is used when applying service are updated to point to the libraries on the target system. When service is applied, updates are made to the target libraries.

After service is installed, the new target libraries are tested, and if successful, are put into production as the new driving system.

As you prepare to install service into the file system, keep the following facts in mind:

There is only one file hierarchy active at any given time. You might have multiple file systems on your system. But z/OS UNIX does not recognize them unless they are mounted at a directory (mount point) within the file hierarchy.
If you install service directly on the production file system, you will copy new load modules over existing ones. This causes potential tracking and system-level problems. Therefore, you should create a copy of the production file system before installing service.
In most cases, you will copy the root file system. However, you can use this same concept to duplicate other production file systems that are mounted in the file hierarchy or in individual directories. For help copying the root file system, see Copying the file system.

This new copy must be mounted at a directory (mount point) within the active file hierarchy. The directories in the newly mounted file system will be the target libraries when installing service.
The distribution libraries for elements installing into the file system are still partitioned data sets.

Installing service into the file system involves the following steps. In these steps, the new file system is called the service file system. The first two steps are shown in Figure 1.

Create a clone of the system that you are migrating from. This includes copying all necessary partitioned data sets and file systems. A number of utilities such as IEBCOPY or DFSMSdss can be used to copy partitioned data sets.
With a superuser ID, mount the service file system at a mount point within the active file hierarchy. To do this, first create a directory (mount point) for the /service directory:
1. Issue the TSO MKDIR command and create a directory called /service:
```
MKDIR '/service'
```
2. Issue the TSO/E MOUNT command to mount the service file system to the root file system.
3. At this time, the /service directory has permission bits of 755. This prevents unauthorized users from corrupting the service file system.
Change the DDDEFs or DD statements used by the SMP/E cataloged procedure to point to the new target directories. For example, the DDDEFs must now point to /service/bin/IBM instead of to /bin/IBM.
Note: With SMP/E, you can perform the ZONEEDIT function for all directories. You no longer need to change individual DDDEFs for directories manually.

Also change the VOLSER information of the DDDEFs or DD statements for the partitioned data sets.
Install the service.
Test out the new target libraries.
After the target libraries have been successfully tested, you can move them into production. To replace the original file system with the service file system, using either one of the following methods:
- Use DFSMSDss DUMP and RESTORE to copy the service file system to the original file system.
  Or
- Unmount the original file system. Next, unmount the service file system from /service and mount it on the original file system mount point. This step might require changes to the BPXPRMxx member. A reIPL is also required.
Keep the target system SYSRES and the target system file system synchronized, because service might affect both files into the file system and members of the partitioned data set. Make both the target system SYSRES and the target file available at the same time.