Uniquely identifying UPM objects

USS processes inherit their z/OS job name from the address space where the USS process originates. If the originating address space uses the USS spawn callable service (TOM uses spawn) to create a job, it can specify a job name for the new address space where the job will run. If the originating address spaces does not specify a job name, the job name has the same name as the address space that issues the spawn. The address space can also inherit its job name from the creating address space if it uses the fork USS callable service to create the new USS process.

When the inherited job name is less than 8 characters, z/OS processing appends a numeric value from 1 to 9 to the end of the job name. When the value exceeds 9, z/OS processing restarts the numbering at 1 for the next spawn or fork.

USS processes can be created in the following ways:

• The USS spawn callable service, by default, creates a new address space and can optionally create the new USS process in the same address space
  TOM uses spawn to create the USS process in a new address space.
• The USS fork callable service always creates the USS process in a new address space
• With an attach_exec USS callable service: this process creates the USS process in the same address space
• With an attach_execmvs USS callable service: this process creates the USS process in the same address space
• With the first USS callable service from a non-USS address space: this is often called dubbing; the task that issues the USS callable service in the existing address space is dubbed as a USS process

When the spawn service specifies the job name, z/OS does not append a digit. For the others in the list, the resulting job name of the new USS process is inherited from the existing address space.

Under certain conditions, the TOM UPM Extension needs to determine if the USS process for the UPM object is running on the system by using its identifying information, which is the command and parameters. If the identifying job name is specified, the UPM Extension uses this additional information to locate the USS process in the system. The UPM Extension compares the identifying job name with the job name of the USS process running in the system. The comparison is based on the characteristics of the UPM Identifying job name and the actual job name.

For example, if you want TOM to manage two instances of the IBM FTP daemon, you must define a UPM object for each one, specifying FTPD as the USS process command and parameters. Then you can have two cataloged procedures, FTPD1 and FTPD2, with job names FTPD1 and FTPD2. Use MVS start command types for both objects. The start command for FTPD1 is START FTPD1, which creates the USS process FTPD with job name FTPD11 (the first time it is started). The start command for FTPD2 is START FTPD2, which creates the USS process FTPD with job name FTPD21 (the first time it is started). By specifying identifying job name FTPD1 for the FTPD1 object and FTPD2 for the FTPD2 object, the UPM Extension can correctly locate and manage each of the objects.

In another example, you want two different UPM objects (U1 and U2) with the same USS process command and parameters of /home/my-id/pgms/mypgm1 -f mylogfile. For the U1 object, specify MYJOB1 in the Identifying job name field and for U2, specify MYJOB2 for the Identifying job name value. For both objects, define the following attributes:

• A Start command of type USS
• A spawn job name of &@UPM.IDJOB (this is an object reference variable that resolves to the value specified in the Identifying job name) field
• The same command text as the USS process command and parameters

When TOM starts U1, the USS process has the job name MYJOB1. When TOM starts U2, the USS process has the job name MYJOB2. UPM can identify the USS processes which have identical commands or parameters by using the job names.