Generating job names for OMVS address spaces

When the kernel provides an address space for a fork or spawn request, the following rules are used when generating the job name:

For fork and spawn requests that do not involve changing user IDs, the job name of the child is set to the base job name with a number from 1 to 9 appended at the end. For example, if you logon to TSO, you will have a job name that is the same as your user ID (for example, SMORG). The first fork or spawn creates an address space with SMORG1. In this case, the base job name is SMORG and all children inherit the same base job name.
Continuing this example, if address space SMORG1 does a fork or spawn, the new child address space will have a job name of SMORG1 to SMORG9. It is possible to have multiple address spaces with the same job name running concurrently.
If you run a batch job with a job name that is 8 characters long (such as PAYROLLX), then all child processes created by this job have the same job name.
When you use rlogin to enter the system, the rlogin daemon prompts for your user ID and password or password phrase. The daemon then validates the caller and performs a setuid() followed by an exec(). The setuid()/exec() combination triggers the kernel to change the job name of the address space to the user ID. Because rlogin supports 8-character user IDs, any children created by this process will follow the rules defined in Step 1 and Step 2, depending on the length of the user ID.
If a daemon issues a spawn() with user ID, the child address space is assigned a job name that is the same as the user ID.
If a daemon does a spawn() or exec() with the _BPX_JOBNAME environment variable set, the address space gets the requested job name.

Any time the job name is changed, the new job name becomes the base job name for future children.

Restriction: JES attributes for a job with a job name assigned with _BPX_JOBNAME cannot be displayed by job display commands under JES2 or JES3.