Job user identity examples

 

These examples illustrate how the job user identity (JUID) is assigned in different situations.

• A job runs under a user profile called USERA. The JUID is USERA. If the job uses the QWTSETP API to switch to USERB, the JUID changes to USERB.

  In this situation, the Set By value for the JUID is *DEFAULT. Because the job that is running single-threaded, the job user identity is the current user profile under which the initial thread of the job is running (unless, the job user identity was explicitly set by an application). For job queue jobs and completed jobs, the job user identity is the user name from the qualified job name.

• A single-threaded job runs under user profile USERX. The JUID is USERX. If the job initiates secondary threads, the JUID remains as USERX. If all the threads then swap to USERY, the JUID is still USERX.

  In this situation, the Set By value for the JUID is *SYSTEM. Because this is an active job which is currently running as a multi-threaded job, the job user identity is implicitly set by the system. The job user identity is set to the name of the user profile under which the job was running when the job became multi-threaded. When the job returns to running single-threaded, the job user identity will be reset to the *DEFAULT value.

• If a server running under a user profile called SERVER calls the QWTSJUID API, the JUID will be set to SERVER. If the server then calls the Set Profile (QWTSETP) API to set its current user profile to CLIENT while processing work on behalf of that client, the JUID remains as SERVER. Likewise, if the server initiates secondary threads that each call QWTSETP to run under various user profiles, the JUID remains as SERVER.

  In this situation, the Set By value for the JUID is *APPLICATION. The job user identity is set explicitly by an application using an API. This value applies to both single-threaded and multi-threaded jobs.

 

Parent topic:

Job characteristics