6.4.1 Access permission considerations
When you have registered the required JP1 users, you must decide what access permissions (JP1 permission levels) to grant to these JP1 users in regard to which groups (JP1 resource groups).
- Organization of this subsection
(1) Determining the JP1 resource groups to be defined
The access permissions for JP1/AJS3 units are managed in groups known as JP1 resource groups. You can define any name you like for a JP1 resource group. For example, if access permissions are grouped by company department, you can assign corresponding names such as purchasingdep or personneldep.
Access permissions can be set for each JP1 resource group. The set access permissions are associated with JP1 users. Each JP1 user is allowed to operate on the units in the associated JP1 resource group only within the set range of access permissions.
A unit that does not belong to any JP1 resource group is not subject to access control. This means that all JP1 users can view or change that unit. Conversely, if a JP1 resource group is not associated with any JP1 users, it cannot be accessed by any JP1 users. When deploying JP1/AJS3, make sure that all JP1 users are granted the appropriate access permissions for all units, as follows:
-
Have JP1 resource groups been set for all units?
-
Have appropriate access permissions been set for the JP1 resource groups, and are all JP1 resource groups associated with JP1 users?
-
Have all JP1 users been associated with a JP1 resource group?
Multiple JP1 resource groups can be associated with a single JP1 user. For example, the same JP1 user can be associated with General Affairs Department JP1 resource group and with the Sales Department JP1 resource group. This allows the access permissions to the two departments to be controlled separately for a particular JP1 user.
(2) Determining JP1 permission levels
The operations that can be performed on a JP1 resource group are determined by its JP1 permission level.
A JP1 permission level is set for each JP1 resource group associated with JP1 users. For example, if a JP1 user is associated with the General Affairs Department JP1 resource group and with the Sales Department JP1 resource group, you can set a JP1 permission level for the General Affairs Department JP1 resource group allowing units to be executed and edited, and a different JP1 permission level for the Sales Department JP1 resource group allowing units to be viewed only. Thus, the associated JP1 user will have permission to execute and edit units in the General Affairs Department JP1 resource group, and to view units in the Sales Department JP1 resource group.
There are three types of JP1 permission level:
-
Access permission for defining and executing jobnets
-
Access permissions for executing and working with commands in the execution environment of QUEUE jobs and submit jobs
-
Access permissions for operating agent management information
The names of the permission levels and the operations possible with each are covered below. Refer to the details on operations given here when setting JP1 permission levels.
(a) Access permissions when defining and executing jobnets
There are the following five kinds of access permissions for defining and executing jobnets:
-
This is the administrator's permission. It confers ownership of the unit, the permission to operate resource groups, the permissions to define, execute, and edit jobnets, and so on.
-
Confers permissions including the permissions to define, execute, and edit jobnets.
-
Confers permissions including the permissions to define and edit jobnets.
-
Confers permissions including the permissions to execute and view jobnets.
-
Confers permissions including the permissions to view jobnets.
The following table lists the JP1 permission level names and details of their operation when defining and executing jobnets.
|
Operation details |
JP1_AJS_Admin |
JP1_AJS_Manager |
JP1_AJS_Editor |
JP1_AJS_Operator |
JP1_AJS_Guest |
|---|---|---|---|---|---|
|
Changing the owner, JP1 resource group, or execution-user type of a unit for which you do not have owner permission (by using the Executed by setting)#1 |
P |
-- |
-- |
-- |
-- |
|
Defining units |
P |
P |
P |
-- |
-- |
|
Changing the definition of units under the jobnets |
P |
P#2 |
P#2 |
-- |
-- |
|
Changing jobnet definitions |
P |
P |
P |
-- |
-- |
|
Replicating and moving units, and changing their names#3 |
P |
P |
P |
-- |
-- |
|
Deleting units#4 |
P |
P |
P |
-- |
-- |
|
Outputting units to standard output files |
P |
P |
P |
P |
P |
|
Outputting definitions of units to standard output files |
P |
P |
P |
P |
P |
|
Backing up units |
P |
P |
P |
P |
P |
|
Recovering units |
P |
P |
P |
-- |
-- |
|
Defining calendar information for a job group |
P |
P |
P |
-- |
-- |
|
Defining a jobnet execution schedule for a specific period |
P |
P |
P |
P |
P |
|
Registering a defined jobnet for execution |
P |
P |
-- |
P |
-- |
|
Canceling the registration of a jobnet for execution |
P |
P |
-- |
P |
-- |
|
Registering a jobnet for release |
P |
P |
P#5 |
P#5 |
-- |
|
Canceling the release of a jobnet |
P |
P |
P#5 |
P#5 |
-- |
|
Viewing the release information for a jobnet |
P |
P |
P |
P |
P |
|
Outputting information such as the job execution history, current status, and next planned execution to a standard output file |
P |
P |
P |
P |
P |
|
Temporarily changing a schedule defined in a jobnet |
P |
P |
-- |
P |
-- |
|
Temporarily changing the status of a job |
P |
P |
-- |
P |
-- |
|
Changing the status of a job |
P |
P |
-- |
P |
-- |
|
Suspending the execution of a jobnet |
P |
P |
-- |
P |
-- |
|
Rerunning a jobnet |
P |
P |
-- |
P |
-- |
|
Killing a job or jobnet |
P |
P |
-- |
P |
-- |
|
Exporting units |
P |
P |
P |
P |
P |
|
Importing units |
P |
P |
P |
-- |
-- |
|
Exporting the execution registration status of a jobnet |
P |
P |
P |
P |
P |
|
Importing the execution registration status of a jobnet |
P |
P |
-- |
P |
-- |
- Legend:
-
P: Possible
--: Not possible
- #1
-
If no owner has been set for a unit, all users can change the JP1 resource group, owner, and execution-user type (by using the Executed by setting).
For details on unit owner permission, see (3) Unit owner permission.
- #2
-
The items you can change in a job definition depend on the execution-user type (in the Executed by setting). For details, see (6) Access permissions for changing a job definition.
- #3
-
The permission is required for the parent unit of the unit to be copied, moved, or renamed. For example, when you want to move the unit /AAA/BBB/CCC, the permission must be set for the JP1 resource group of the unit /AAA/BBB. Note that you need the following permissions for a unit that you want to copy, move, or rename.
To copy a unit, the JP1_AJS_Admin, JP1_AJS_Manager, JP1_AJS_Editor, JP1_AJS_Operator, or JP1_AJS_Guest permission must be set for the JP1 resource group of the unit (including subordinate units).
To move or rename a unit, the JP1_AJS_Admin, JP1_AJS_Manager, or JP1_AJS_Editor permission must be set for the JP1 resource group of the unit.
- #4
-
The permission is also required for the parent unit of the unit to be deleted. For example, when you want to delete the unit /AAA/BBB/CCC, the permission must be set for the JP1 resource groups of the unit /AAA/BBB/CCC (including subordinate units) and the unit /AAA/BBB.
- #5
-
JP1_AJS_Editor and JP1_AJS_Operator permissions are both required.
This is because registering a jobnet for release and canceling the release involves changing the jobnet definition and submitting the redefined jobnet for execution.
A user who performs operations on a unit must have permission to operate the JP1 resource group set for that unit. In addition, the JP1_AJS_Admin, JP1_AJS_Manager, JP1_AJS_Editor, JP1_AJS_Operator, or JP1_AJS_Guest permission must be set for the JP1 resource groups of the upper-level units.
JP1 users mapped to OS users with administrator's permissions or superuser permissions can execute all operations regardless of their JP1 permission level. These JP1 users can also execute commands to perform all operations on units regardless of the permissions set in the JP1_USERNAME environment variable for the JP1 users. However, if yes is set for the ADMACLIMIT environment setting parameter instead of the default, only the operations within the JP1 permission level are allowed.
For details about the ADMACLIMIT environment setting parameter, see 20.11.2(4) ADMACLIMIT in the JP1/Automatic Job Management System 3 Configuration Guide.
Note that if no JP1 resource group has been set for a unit, all users can perform all JP1/AJS3 operations with respect to that unit.
- Cautionary notes
-
-
Access permission for the referenced JP1/AJS3 - Manager is granted for manager job groups and manager jobnets.
-
While JP1/AJS3 - View is connected to JP1/AJS3 - Manager, access permission information is stored in a JP1/AJS3 - Manager cache. For this reason, when access permissions are changed, the change might not be applied to the connected JP1/AJS3 - View. When you change access permissions, disconnect JP1/AJS3 - View from JP1/AJS3 - Manager, change the access permissions, and then connect JP1/AJS3 - View again.
-
(b) Access permissions for executing and working with commands in the execution environment of QUEUE jobs and submit jobs
There are three types of access permissions for executing and working with commands in the execution environment of QUEUE jobs and submit jobs.
-
This is the administrator's permission. It confers the permission to set job execution environments, the permission to operate queues and job executing agents, and the permission to operate jobs queued by other users.
-
This confers the permission to operate queues and agents, and the permission to operate jobs queued by other users.
-
This confers the permission to register submit jobs and to operate jobs that you have queued yourself.
When setting access permissions for executing and working with commands in the execution environment of QUEUE jobs and submit jobs, assign these permission levels to the JP1 resource group JP1_Queue. Note that the entry JP1_Queue is case sensitive.
The following table lists the JP1 permission level names and details of their operation for executing and working with commands used in the execution environment of QUEUE jobs and submit jobs.
|
Operation details |
JP1_JPQ_Admin |
JP1_JPQ_Operator |
JP1_JPQ_User |
|---|---|---|---|
|
Registering submit jobs |
P |
P |
P |
|
Canceling/killing job execution |
P |
P |
O |
|
Holding job execution/releasing a job from held status |
P |
P |
O |
|
Moving a job |
P |
P |
O |
|
Outputting job information |
P |
P |
O |
|
Outputting ended job information |
P |
P |
O |
|
Deleting ended job information from the database |
P |
P |
-- |
|
Opening a queue |
P |
P |
-- |
|
Closing a queue |
P |
P |
-- |
|
Adding a queue |
P |
-- |
-- |
|
Deleting a queue |
P |
-- |
-- |
|
Outputting queue information |
P |
P |
P |
|
Changing the definition of a queue |
P |
-- |
-- |
|
Connecting a queue to an agent |
P |
-- |
-- |
|
Disconnecting a queue from an agent |
P |
-- |
-- |
|
Changing the maximum number of concurrently executable jobs |
P |
-- |
-- |
|
Adding an agent |
P |
-- |
-- |
|
Deleting an agent |
P |
-- |
-- |
|
Outputting agent host information |
P |
-- |
-- |
|
Adding an execution-locked resource |
P |
-- |
-- |
|
Deleting an execution-locked resource |
P |
-- |
-- |
|
Outputting information about an execution-locked resource |
P |
P |
P |
- Legend:
-
P: Possible.
O: Possible, but not for jobs executed by other users.
--: Not possible
- Cautionary note
-
The execution and operation of commands used in the execution environment of QUEUE and submit jobs is subject to the access permissions defined for the manager that requested the processing.
(c) Access permissions for working with agent management information
There are three kinds of access permissions for working with agent management information:
-
This is the administrator's permission. It is the permission required to add, edit, and delete execution agent and execution agent group definitions.
-
This is the permission required to change the job transfer restriction status of execution agents and execution agent groups.
-
This is the permission required to view statuses and definition information for execution agents and execution agent groups.
When setting access permissions for working with agent management information, assign these permission levels to the JP1 resource group JP1_Queue. Note that the entry JP1_Queue is case sensitive.
The following table lists the JP1 permission level names and operational details for working with agent management information.
|
Operation details |
JP1_JPQ_Admin |
JP1_JPQ_Operator |
JP1_JPQ_User |
|---|---|---|---|
|
Adding an execution agent |
P |
-- |
-- |
|
Adding an execution agent group |
P |
-- |
-- |
|
Deleting an execution agent |
P |
-- |
-- |
|
Deleting an execution agent group |
P |
-- |
-- |
|
Changing the execution host for an execution agent |
P |
-- |
-- |
|
Changing the number of concurrently executable jobs at an execution agent |
P |
-- |
-- |
|
Changing the description of an execution agent |
P |
-- |
-- |
|
Changing the description of an execution agent group |
P |
-- |
-- |
|
Adding an execution agent that connects to an execution agent group |
P |
-- |
-- |
|
Changing the priority of an execution agent connected to an execution agent group |
P |
-- |
-- |
|
Removing an execution agent as a connection-destination of an execution agent group |
P |
-- |
-- |
|
Changing the job transfer restriction status of an execution agent |
P |
P |
-- |
|
Changing the job transfer restriction status of an execution agent group |
P |
P |
-- |
|
Displaying the status of an execution agent# |
P |
P |
P |
|
Displaying the status of an execution agent group# |
P |
P |
P |
|
Displaying the status of all execution agents and execution agent groups# |
P |
P |
P |
|
Displaying the names of all execution agents and execution agent groups# |
P |
P |
P |
|
Outputting the definition of an execution agent# |
P |
P |
P |
|
Outputting the definition of an execution agent group# |
P |
P |
P |
|
Outputting the definition of all execution agents and execution agent groups# |
P |
P |
P |
- Legend:
-
P: Possible.
--: Not possible
- #
-
Users with administrator's permissions or superuser permissions can perform all operations regardless of their JP1 permission levels.
(3) Unit owner permission
The user who defines a job or jobnet is set as the owner and holds owner permission. Owner permission allows the user to change the following settings for the job or jobnet, regardless of the set JP1 permission level:
-
JP1 resource group
-
Owner
-
Execution-user type (through the Executed by setting for jobs)
Even if you are the unit owner, unless you have permission to view the unit's JP1 resource group, you cannot open the Define Details dialog box in JP1/AJS3 - View. That is, although you are the unit owner, you cannot change the unit's JP1 resource group, Owner, or Executed by setting in JP1/AJS3 - View. To change the settings in this situation, execute the ajschange command and change the JP1 resource group to a JP1 resource group that gives you view permission. For details on the ajschange command, see ajschange in 3. Commands Used for Normal Operations in the manual JP1/Automatic Job Management System 3 Command Reference.
If no owner has been set for the unit, all users can change the JP1 resource group, Owner, and Executed by setting.
(4) Access permission for creating or copying a unit, or making a release entry
When a user creates or copies a unit, or makes a release entry for a unit, the unit owner and JP1 resource group are set by default as follows:
- Creating a unit in JP1/AJS3 - View
-
Owner: The JP1 user who created the unit
JP1 resource group: The JP1 resource group of the upper-level unit
- Creating a unit using the ajsdefine command
-
Owner: The owner set in the unit definition file
JP1 resource group: The JP1 resource group set in the unit definition file
- Copying a unit using JP1/AJS3 - View or the ajscopy command
-
Owner: The JP1 user who copied the unit
JP1 resource group: The JP1 resource group of the copy-source unit
- Registering a unit for release using JP1/AJS3 - View or the ajsrelease command
-
Owner: The owner of the unit to be released
JP1 resource group: The JP1 resource group of the unit to be released
- Creating a unit by centrally or individually exporting using JP1/AJS3 - Definition Assistant
-
Owner: The owner set in the definition management template
JP1 resource group: The JP1 resource group set in the definition management template
You can apply functionality so that a unit that you created, copied, or made a release entry for inherits the owner and JP1 resource group from its upper-level unit. This functionality is known as the upper-level unit-attribute inheritance function. Using this functionality you can, if you wish, set the same owner for all units in the system without having to change the owner or JP1 resource group of the unit you are creating, copying, or releasing.
(a) Overview of the upper-level unit-attribute inheritance function
The upper-level unit-attribute inheritance function can be applied to a job group or jobnet. Every unit that is created, copied, or set for release in the job group or jobnet for which this functionality has been set will inherit the owner and JP1 resource group of the upper-level unit. This functionality does not change the owner or JP1 resource group of units that you have already defined or cut and pasted.
The following figure shows an example of the upper-level unit-attribute inheritance function.
|
|
![[Figure]](GRAPHICS/ZG060030.GIF)
When the upper-level unit-attribute inheritance function is disabled, the JP1 user who performed the copy operation (jp1userX) is set as the owner, and the JP1 resource group (Sales) of the copy-source unit is set as the JP1 resource group of the new Job 1 when Job 1 is copied to Jobnet B.
When the upper-level unit-attribute inheritance function is enabled, the owner and JP1 resource group set for Jobnet B are inherited when Job 1 is copied to Jobnet B.
When the upper-level unit-attribute inheritance function is set for a job group or jobnet configured with two or more levels, the owner and JP1 resource group are inherited from the unit directly above the newly created or copied unit.
The following figure shows an example of the upper-level unit-attribute inheritance function set for a multi-level job group.
|
|
![[Figure]](GRAPHICS/ZG060035.GIF)
In this example, the upper-level unit-attribute inheritance function is set for Job Group B. When you copy Job 1 from Jobnet A to Jobnet B, the new unit inherits the owner and JP1 resource group settings from Jobnet B, which is directly above it. It does not inherit settings from Job Group B.
- Cautionary notes
-
-
The upper-level unit-attribute inheritance function is supported in JP1/AJS3 - Manager 09-50 and later versions. However, if you are using JP1/AJS3 - View 09-10 or an earlier version to connect to the Manager program, copied units will inherit the settings from the upper-level unit, but any new units you create will not inherit upper-level settings.
-
When you restore a unit by using the ajsrestore command or JP1/AJS3 - View, or when you import a unit by using the ajsimport command, the original definition is restored. For this reason, the upper-level unit-attribute inheritance function is not enabled when it is set for the restoration-destination upper-level unit.
-
When you make a release entry, if the upper-level unit-attribute inheritance function is set for the release-target upper-level unit, the function settings take precedence. If you want to apply the owner and JP1 resource group settings of the release-source unit, disable the upper-level unit-attribute inheritance function or define unit-attribute profiles so that the source and target units have the same attributes.
-
When you create a new unit by copying an existing unit, and the full name of the new unit is the same as the full name of a unit for which the upper-level unit-attribute inheritance function is enabled, the new unit inherits the owner and JP1 resource group settings of the unit that was copied.
-
(b) Setting the upper-level unit-attribute inheritance function
To set the upper-level unit-attribute inheritance function, you need to define a unit-attribute profile. The unit-attribute profile sets the full path name of the unit to which the function applies and defines how the function is to behave.
-
Full path name of the target unit
Specify the full path name of the job group or jobnet to which the upper-level unit-attribute inheritance function will apply. To set the function for all units controlled by the scheduler services, enter a slash (/).
The unit or units that you specify in the profile are the same as those to which the execution-user fixing function applies. For details on the execution-user fixing function, see (5) Job execution user.
-
Function behavior
Set either of the following values to specify how the function is to behave:
- entryuser
-
A unit copied to or created in the target job group or jobnet inherits the owner and JP1 resource group settings from the upper-level unit. However, if the new unit was copied from a source job whose execution-user type (Executed by) is the unit owner, the source job settings are kept and the settings of the upper-level unit are not inherited.
- all
-
A unit copied to or created in the target job group or jobnet inherits the owner and JP1 resource group settings from the upper-level unit. Even if the new unit was copied from a source job whose execution-user type (Executed by) is the unit owner, the settings of the upper-level unit are still inherited.
The following figures show the differences in function behavior between the entryuser and all settings.
Figure 6‒4: Behavior of the upper-level unit-attribute inheritance function ("entryuser" set) ![[Figure]](GRAPHICS/ZG060040.GIF)
In this example, entryuser is set for the upper-level unit-attribute inheritance function. When Job 1 and Job 2 are copied to Jobnet B, Job 1 inherits the owner and JP1 resource group settings from Jobnet B because the Executed by setting is User who registered for Job 1. Job 2, on the other hand, keeps the owner and JP1 resource group settings of the copy-source unit because its Executed by setting is User who owns.
Figure 6‒5: Behavior of the upper-level unit-attribute inheritance function ("all" set) ![[Figure]](GRAPHICS/ZG060041.GIF)
In this example, all is set for the upper-level unit-attribute inheritance function. When Jobs 1 and 2 are copied to Jobnet B, both jobs inherit the owner and JP1 resource group settings from Jobnet B.
- Supplementary note
-
When the upper-level unit-attribute inheritance function is set for multiple units at different levels in a job group or jobnet, the function behavior set for the upper-level unit closest to the copied or created unit takes precedence. For example, if the function is set for a job group and for a jobnet in that job group, the function behavior set for the jobnet will take precedence for any jobs added to the jobnet.
For details on setting a unit-attribute profile, see 21.1.3 Setting up the upper-level unit-attribute inheritance function and execution-user fixing function in the JP1/Automatic Job Management System 3 Configuration Guide. For more information about unit-attribute profiles, see 21.1.4 Details of unit-attribute profile in the JP1/Automatic Job Management System 3 Configuration Guide.
(c) Example of using the upper-level unit-attribute inheritance function
The following describes an example of using the upper-level unit-attribute inheritance function.
For the purpose of this example, assume that jobnets are defined according to the following policies:
- Policy for defining access permissions
-
The access permissions (owner and JP1 resource group) are set as user1 and Accounting, respectively, for all units.
- Policy for defining units
-
-
When two or more JP1 users are connected to a manager host by JP1/AJS3 - View, each JP1 user defines units for the particular tasks he or she is responsible for.
-
Create Jobnet A in a job group Test for testing purposes, and define Jobs 1 and 2 under Jobnet A.
-
Perform a test run of Jobnet A in the job group Test. Then copy Jobnet A to the job group Deploy and start operation.
-
Let's assume that the manager host environment has been configured and the Test and Deploy job groups have been set up. Assume also that user1 is set as the owner and Accounting is set as the JP1 resource group of job group Deploy.
The following figure shows an example of defining a jobnet with these settings using the upper-level unit-attribute inheritance function.
|
|
![[Figure]](GRAPHICS/ZG060043.GIF)
In this example, JP1 users jp1userA, jp1userB, and jp1userC are connected to the manager host by JP1/AJS3 - View. The unit-attribute profile for AJSROOT1 defines /Deploy as the target unit to which the upper-level unit-attribute inheritance function applies, and all as the function behavior.
The JP1 users each define Jobnet A, Job 1, and Job 2 in Test, the job group for testing units. In each case, the JP1 user name is set as the owner of the defined unit. Having been tested in the Test job group, Jobnet A can now be copied to the Deploy job group. The copied Jobnet A inherits the access permissions of the upper-level Deploy job group. Similarly, the copied Job 1 and Job 2 inherit the access permissions of the upper-level Jobnet A, and hence the access permissions of the Deploy job group. This means that all units copied to the Deploy job group can be run with the same owner and JP1 resource group.
(5) Job execution user
When a jobnet is executed, the JP1 user who executes the jobs defined in the jobnet is known as the execution user.
You can select either of the following as the execution user of a job (by using the Executed by setting):
- User who registered
-
The job is to be executed by the JP1 user who registered the jobnet for execution, if the user has execution permission for the job.
- User who owns
-
The job is to be executed by the JP1 user set as the job owner, if the user has execution permission for the job. It does not matter whether execution permission has been granted to the JP1 user who registers the jobnet for execution.
OR jobs, judgment jobs, and event jobs are executed under the account of the user who started JP1/AJS3. For this reason, you cannot set Executed by for OR jobs or judgment jobs. If you set Executed by for an event job, the setting will be ignored.
At execution, the job is forwarded to the target host system (the agent host). The job execution user must therefore be mapped to the OS user on the target host system. If you set User who registered in the job's Executed by setting, map the JP1 user who registers the jobnet for execution to the OS user. If you set User who owns, map the job owner to the OS user.
Regardless of a job's Executed by setting, you can fix its execution user as the JP1 user defined as the owner of the upper-level unit. This functionality is called the execution-user fixing function. It allows all the jobs in a jobnet to be executed under the same JP1 user account, regardless of who registered the jobnet for execution.
- Cautionary note
-
The execution-user fixing function is supported in JP1/AJS3 - Manager 09-50 and later versions.
(a) Overview of the execution-user fixing function
The execution-user fixing function can be set for a job group or jobnet. Jobs in the job group or jobnet for which the function has been set are executed by the JP1 user set as the owner of that job group or jobnet, regardless of the Executed by setting in the detailed definition of each job.
The following figure shows an example of the execution-user fixing function.
|
|
![[Figure]](GRAPHICS/ZG060045.GIF)
In the first case above, the execution-user fixing function is disabled. When jp1userX registers Jobnet A for execution, Job 1 will be executed by jp1userX because the job's Executed by setting is User who registered.
In the second case above, the execution-user fixing function is enabled. When jp1userX registers Jobnet A for execution, Job 1 will be executed by jp1userA, the owner of Jobnet A, regardless of the job's Executed by setting.
- Cautionary notes
-
-
When the execution-user fixing function is enabled, the actual execution user differs from the Executed by setting in the detailed definition. As a result, a permission error might occur when a job is executed if the execution user set by the execution-user fixing function does not have execution permission for the job, even though access permission for executing the job is set for that user in Executed by in the detailed definition.
-
Setting the execution-user fixing function does not alter the definition information of any job. Jobs are executed by the JP1 user set by the execution-user fixing function, regardless of the Executed by setting in the detailed job definition.
-
By setting the execution-user fixing function for the upper-level unit, you can fix the execution user of the types of jobs listed below. Event jobs are excluded because they are executed independently of the execution user.
-
Standard jobs#
-
Action jobs
-
Custom jobs
-
Passing information setting jobs
-
HTTP connection jobs
- #
-
You can fix the execution user for Unix jobs and PC jobs even if they are queueless jobs.
- Cautionary note
-
The settings for the execution-user fixing function at the connection-destination host apply to jobs in a remote jobnet.
When the execution-user fixing function is set for an upper-level unit configured over two or more levels, the JP1 user set as the job execution user will be the owner of the upper-level unit closest to the job among those units for which the execution-user fixing function has been set.
The following figure shows an example of the execution-user fixing function set for a multi-level job group.
|
|
![[Figure]](GRAPHICS/ZG060050.GIF)
In Example 1, the execution-user fixing function is set for Job Group A. When you register Jobnet A for execution, the execution user of Job 1 will be jp1userA, the owner of Job Group A for which the function is set.
In Example 2, the execution-user fixing function is set for Job Group A and Jobnet A. When you register Jobnet A for execution, the execution user of Job 1 will be jp1userB, the owner of Jobnet A, which is the closest upper-level unit for which the execution-user fixing function has been set.
(b) Setting the execution-user fixing function
To set the execution-user fixing function, you need to define a unit-attribute profile. The unit-attribute profile sets the full path name of the unit to which the function applies and defines how the function is to behave.
-
Full path name of the target unit
Specify the full path name of the job group or jobnet to which the execution-user fixing function will apply. To set the function for all units controlled by the scheduler services, enter a slash (/).
The unit or units that you specify in the profile are the same as those to which the upper-level unit-attribute inheritance function applies. For details on the execution-user fixing function, see (4) Access permission for creating or copying a unit, or making a release entry.
-
Function behavior
Set either of the following values to specify how the function is to behave:
- entryuser
-
The execution user of the jobs in the unit subject to the execution-user fixing function is fixed as the owner of that unit. However, if the Executed by setting of any of the jobs in the unit is User who owns, the job owner will be the execution user for that job.
- all
-
The execution user of the jobs in the unit subject to the execution-user fixing function is fixed as the owner of that unit. This applies even if the Executed by setting of any of the jobs in the unit is User who owns.
The following figures show the differences in function behavior between the entryuser and all settings.
Figure 6‒9: Behavior of the execution-user fixing function ("entryuser" set) ![[Figure]](GRAPHICS/ZG060055.GIF)
In this example, entryuser is set for the execution-user fixing function. When Jobnet A is registered for execution, Job 1 will be executed by its owner (jp1userB) because the job's Executed by setting is User who owns. The execution user of Job 2, on the other hand, is fixed as the owner of Jobnet A (jp1userA) because the Executed by setting of Job 2 is User who registered.
Figure 6‒10: Behavior of the execution-user fixing function ("all" set) ![[Figure]](GRAPHICS/ZG060056.GIF)
In this example, all is set for the execution-user fixing function. When Jobnet A is registered for execution, the execution user of Jobs 1 and 2 is fixed as the owner of Jobnet A (jp1userA).
- Cautionary note
-
When the execution-user fixing function is set for multiple units at different levels in a job group or jobnet, the function behavior set for the upper-level unit closest to each job takes precedence. For example, if the function is set for a job group and for a jobnet in that job group, the function behavior set for the jobnet will take precedence for the jobs in that jobnet.
For details on setting a unit-attribute profile, see 21.1.3 Setting up the upper-level unit-attribute inheritance function and execution-user fixing function in the JP1/Automatic Job Management System 3 Configuration Guide. For more information about unit-attribute profiles, see 21.1.4 Details of unit-attribute profile in the JP1/Automatic Job Management System 3 Configuration Guide.
(c) Example of using the execution-user fixing function
The following describes an example of using the execution-user fixing function.
For the purpose of this example, assume the following jobnet configuration:
-
Jobnet A is defined on manager host hostM and is owned by jp1userX.
-
Jobs 1 and 2 are defined in Jobnet A. The Executed by setting of both jobs is User who registered.
The following figure shows an example of executing Jobnet A defined as above and using the execution-user fixing function.
|
|
![[Figure]](GRAPHICS/ZG060060.GIF)
In this example, the execution-user fixing function is set for Jobnet A and the function behavior is set as all. When jp1userA, jp1userB, or jp1userC registers the jobnet for execution, Job 1 and Job 2 are forwarded to an agent host. The execution user of both jobs is fixed as the Jobnet A owner (jp1userX) regardless of who registered each job. As a result, to execute the jobs on their respective agent host, jp1userX must be mapped with the OS user (osuser1). User mapping is not required for the user who registered the jobs (jp1userA, jp1userB, or jp1userC). There is no need to add a user mapping definition if another JP1 user who registers Jobnet A for execution is added later.
(d) Combining the execution-user fixing function and the upper-level unit-attribute inheritance function
You can set both the execution-user fixing function and the upper-level unit-attribute inheritance function using the same unit-attribute profile. When you use both functions, you can select the behavior of each function separately as either entryuser or all. If you select a different behavior for each function, the job execution process becomes more difficult to predict. We therefore recommend that you set the same behavior value for both functions.
The following table describes how the different function behaviors work in combination.
|
No. |
Behavior value of the execution-user fixing function |
Behavior value of the upper-level unit-attribute inheritance function |
Description |
|---|---|---|---|
|
1 |
entryuser |
entryuser |
The execution user can be fixed as the job owner for selected jobs only. This setting remains unchanged when the job is copied. Specify this combination of values when you create a special job as a part and then copy it to incorporate it in the system. |
|
2 |
all |
all |
The execution user, owner, and JP1 resource group are systemized for all the jobs in the specified unit. |
|
3 |
entryuser |
all |
We do not recommend this combination. The execution user can be fixed as the job owner for selected jobs only, but the setting changes when the job is copied. |
|
4 |
all |
entryuser |
We do not recommend this combination. You might want to keep the execution user of the copy-source job when you copy a particular job, but the execution user will be fixed as the owner of a different unit when the job is executed. |
(6) Access permissions for changing a job definition
The items that can be changed in the detailed definition of a job depend on the definition contents and whether the JP1 user has access permission for the job. You can change all items in a detailed definition if any of the following conditions is met:
-
The ADMACLIMIT environment setting parameter is omitted or is set to no, and the JP1 user who is to perform the operation is mapped to one of the following OS users:
-
In Windows
An OS user who has administrator permissions
-
In UNIX
An OS user who has superuser permissions
-
-
A resource group and owner are set for the operation-target job, and the JP1 user who is to perform the operation has the JP1_AJS_Admin permission for that resource group.
-
No resource group is specified for the operation-target job.
If the JP1 user does not have administrator's permissions, JP1_AJS_Manager or JP1_AJS_Editor permission level must be granted to change the detailed definition of a job. The definition items that can be changed depend on whether the JP1 user has owner permission for the job and the job's Executed by setting.
The following table describes which definition items can be changed according to whether the JP1 user has owner permission and the Executed by setting.
|
Whether the JP1 user has owner permission |
"Executed by" setting |
|
|---|---|---|
|
User who registered |
User who owns |
|
|
Yes |
All |
All#1 |
|
No |
Some |
None#2 |
- Legend:
-
All: The JP1 user can change all items.
Some: The JP1 user can change items other than the job owner, JP1 resource group, and execution-user type.
None: The JP1 user cannot change any items.
- #1
-
If a user with owner permission changes the job owner, the job's Executed by setting will automatically change to User who registered.
This is to prevent execution by an unauthorized user. If the Executed by setting had remained as User who owns, and the JP1 user changed the owner to a user who is not permitted to execute the job, the job would be executed under an unauthorized user account.
- #2
-
Users without owner permission cannot change detailed information for a job when the Executed by setting is User who owns. This is to prevent users from freely changing a job definition and executing it with the account of the owner previously set for the job.
If no owner has been set for a job, all definition items can be changed regardless of the job's access permission or Executed by setting.