+

Search Tips   |   Advanced Search

Set up a job manager environment

A job manager environment consists of a job manager and the targets that it manages. Job manager targets can be:

Setting up a job manager environment involves...

Job managers are part of the flexible management environment. Job managers can manage stand-alone appservers registered to an administrative agent. Those nodes and administrative agents are also part of the environment.

Ensure that the profiles in the either all have security enabled or all have security disabled.

Job managers can manage v8 and v7 target nodes. A job manager can manage a node at an equal or lesser version number than the job manager. For example, a v8 job manager can manage v8 and 7 nodes. A v7 job manager can manage v7 nodes. The fix pack portion of the version number does not matter; for example, a v7.0.0.3 job manager can manage a node at v7.0.0.9, which is v7 with fix pack 9 installed.

Further, a job manager can manage a v8 or v7 deployment manager that has a v8, v7, or v6 federated node. A deployment manager registered with a job manager can manage a mixed version cell. Using the job manager, we can submit jobs that manage any resources in the mixed version cell, including resources on a v6 federated node.


Tasks

  1. Determine the topology for the environment.

    Flexible management encompasses administrative agents and job managers. Determine which machines, targets, and target resources such as servers and applications to be in the environment. To manage stand-alone application servers, use an administrative agent on each computer where the stand-alone application servers reside. To collectively manage deployment managers and stand-alone application servers on the same or different computers, use a job manager. The stand-alone application servers must be registered with an administrative agent before we can manage them using a job manager. See Scenarios 5 and 10 in the Planning to install WAS topic.

  2. Determine the security roles needed for the environment.

    Profiles in the flexible management environment must either all have security enabled or all have security disabled. When creating, we can specify security options, user names, and passwords. We need appropriate security roles authorize us to work with a job manager and to manage registered targets and resources on those targets. If the environment includes stand-alone application server target nodes, then we must be authorized to work with an administrative agent and its nodes.

  3. Create a management profile for the job manager.

    Use the Profile Management Tool or the manageprofiles command.

    For example, in the Profile Management Tool, select the Management environment and click Next, select the Job manager server type, and select options that create the profile. By default, a job manager has its own administrative console, administrative security is enabled, and the console port is 9960. To disable administrative security, to specify a security certificate, or to change the default ports, use the advanced profile creation option when creating the job manager profile. By default, the first administrative agent profile in a product installation is named JobMgr01 and its server name is jobmgr. For manageprofiles examples, see the topic on the manageprofiles command. For -templatePath, specify the management template. For -serverType, specify JOB_MANAGER.

    The job manager configuration includes a datasource named OTiSDataSource which is used in the implementation of the job manager, and does not need to be configured or otherwise managed by the administrator.

  4. Create profiles for any administrative agents and stand-alone appservers that we intend to have in our flexible management environment.

  5. Register the stand-alone appservers with the administrative agent.

    Stand-alone nodes are also called unfederated or base application servers. They are not managed by a deployment manager. Stand-alone application servers typically have a profile name such as AppSvr01. An administrative agent must be on the same computer as its stand-alone nodes. Registering the stand-alone nodes with the administrative agent enables the administrative agent to manage the nodes. We must register stand-alone application servers with an administrative agent before we can register the stand-alone application servers with the job manager.

    See: Administrative agent environment.

  6. Create profiles for any deployment managers and federated nodes that we intend to have in our flexible management environment.

    Federated nodes are managed by a deployment manager. Federated application servers typically have a profile name such as AppSvr01, however we cannot administer them individually. We must administer federated nodes using the deployment manager. See topics on creating cell profiles, management profiles for deployment managers, or the manageprofiles command.

  7. Synchronize the clocks on all involved systems.

    To change the system clock, stop all the application servers, the node agent servers, the deployment manager server, the administrative agent server, and the job manager server first. After stopping the servers, change the system clock, and then restart the servers. If we change the system clock on one system, ensure the clocks on all systems that communicate with each other and have WAS installed are synchronized. Otherwise, we might experience errors, such as security tokens no longer being valid.

  8. Start the job manager server.

    • Run the startServer command.

      For example, suppose the JobMgr01 profile has the server name jobmgr. Run the following command from the bin directory of the JobMgr01 profile:

      startServer jobmgr

    • (Windows) Use the Windows operating system Taskbar.

        Start > [All] Programs > IBM WebSphere > product_name > Profiles > job_manager_profile > Start the management server for job administration

    • Use the START command to start the job manager:

      START job_manager_proc_name,JOBNAME=server_short_name, ENV=cell_short_name.node_short_name.server_short_name

    If the job manager starts successfully, the message open for e-business displays and is written to the job manager startServer.log file:

    Server launched. Waiting for initialization status. Server jobmgr open for e-business; process id is 1932.

    See topic on starting and stopping the job manager.

  9. Register stand-alone appserver targets with a job manager.

  10. Register deployment managers with the job manager.

  11. Register host computers with the job manager.

    A remote host target is not required to have any WAS products installed. There are no software requirements for this host beyond its operating system. Registering a remote host with a job manager enables the job manager to access applications, command files, and other resources on the host computer.

    To register Liberty with a job manager, use a procedure for registering a target with a host.

  12. Verify that the targets are registered with the job manager.

    Use an administrative console or wsadmin scripting commands to see a list of targets that are registered with the job manager.

    • In the job manager console or deployment manager console, click...

        Jobs > Targets

      The Targets page lists targets that are registered with the job manager.

    • Run the AdminConfig list command to see a list of managed targets. Run the following wsadmin scripting commands from the administrative agent bin directory to list stand-alone appserver targets, or from the deployment manager bin directory to list other targets.

      • To use the Jython scripting language, enter the following two commands in succession:

        wsadmin -lang jython
        print AdminConfig.list('JobManagerRegistration')

      • To use the Jacl scripting language, enter the following two commands in succession:
        wsadmin
        $AdminConfig list JobManagerRegistration

      After verifying the targets are registered with the job manager, enter quit to exit the wsadmin scripting tool.

  13. Ensure that the servers in our flexible management environment are running.

    In the job manager console or deployment manager console, click...

    On the Target resource page, a server status of Started shows that the server is running.

  14. Optional: Disable the com.ibm.otis.Audit_mm_dd_yyyy.log log file by specifying the JVM property otis.audit.location with a value of OFF. or move the log file to a new directory location. Job manager maintains an additional log which is in the profile logs directory by default. The purpose of the log is to record job manager internal activity.

    The name of the log file is com.ibm.otis.Audit_mm_dd_yyyy.log, where mm, dd and yyyy are month, date and year respectively. A new file is created for each day if activity occurs that can be logged.

    This log file can be moved to another directory by specifying the JVM property otis.audit.location with a value of the new directory location.

The flexible management environment is set up and the job manager is configured.


What to do next

Submit jobs using the job manager.


Subtopics


Related:

  • Job manager
  • Create management profiles for job managers
  • Set up the administrative agent environment
  • Create management profiles with administrative agents
  • Job manager security
  • Create cell profiles
  • Create management profiles with deployment managers
  • Restart the administrative agent
  • Restart the job manager
  • Register nodes with the job manager
  • Administer nodes remotely using the job manager
  • Submit jobs
  • Configure port settings
  • manageprofiles command
  • JobManagerNode .
  • New target settings
  • Commands for the AdminConfig object
  • System administration for WAS V7: Part 3: Administering a flexible management topology