Help/Systems - System I Automated Operation & Business IntelligenceRobots
Google Search

Help/Systems www

Archive for the 'Service Level Agreements' Category

How to move a tape drive between partitions

Tuesday, November 20th, 2007

Four-step process can be totally automated

Monitoring and adjusting your IBM System i for maximum efficiency and operations can be time-consuming and difficult. Add the complexities of coordinating resource movements for business processes in a logically partitioned System i, and you can have difficult operational issues. What you need is an easy-to-use interface to your Hardware Management Console (HMC) that helps you move your partitioned resources for maximum performance. That interface is Robot/LPAR, the software package that works with the HMC to move processor, memory, and I/O devices among your partitions interactively or in batch mode.

You install Robot/LPAR on one or more i5/OS partitions on your System i and it communicates with the HMC to manage partitions and set, adjust, or move resources. Robot/LPAR is especially useful for system administrators who must share or provide resources across partitions because of Service Level Agreements (SLAs).

Robot/LPAR works with the HMC to move resources to meet your business needs. With Robot/LPAR, you can move shared resources based on critical batch processes and you can schedule these movements using Robot/SCHEDULE. You can eliminate guesswork, mistakes, and the need to have someone monitor your LPAR processes—through automation. Robot/LPAR helps you ensure that your memory, processor resources, and devices are where they need to be to minimize the costs and maximize the efficiency of your partitioned environment. Your System i processes run quickly because Robot/LPAR works with the HMC at the operating system (i5/OS) level so all resource movements are fast and efficient.

Instead of buying a larger System i to handle workload changes, or buying separate devices for each partition, you can save money by using Robot/LPAR to share your resources. You share your memory, processor, and device resources across several partitions by moving them as they are needed.

Let’s look at a common scenario. (This article assumes you have Robot/LPAR, Robot/SCHEDULE, and Robot/NETWORK installed on both partitions to completely automate this process.) You control the movement of resources from the Robot/LPAR Move Resources Menu.

Each day at the end of daytime processing on partition A, you want to perform a system backup and then start the nightly batch processing. To do so, you must move a shared tape device, known as TAP01, from partition B to partition A for the backup. Then, after the backup on partition A completes, you must move the device back to partition B for its backup.

  1. Because partition B currently owns the device TAP01, you can use Robot/LPAR, Robot/SCHEDULE, and Robot/NETWORK (with cross-system reactivity), to issue a Put I/O Resource (LPRPUTIOR) command from partition B. (Note: Cross-system reactivity is the ability to perform dependent job processing across multiple systems using Robot/NETWORK and Robot/SCHEDULE. Robot/NETWORK tells Robot/SCHEDULE to start a job on one system based on the successful completion of a Robot/SCHEDULE job on another system.) Robot/LPAR automatically varies off the device, its IOP, and any attached devices before it moves them. Because this is an IOP device, you use the *IOP parameter to indicate that the device, its IOP, and any other devices attached on the IOP must be moved. (Note: If this were an IOP-less IOA device, you would specify *IOA, and only the device would be moved.)
  2. After TAP01, its IOP, and any associated devices have been moved, you can have Robot/NETWORK tell Robot/SCHEDULE on Partition A to run a job to vary on the device and start the backup job(s).
  3. After the daily backup completes on partition A, you react to move TAP01 back to partition B to start daily backups there. Because partition A now owns the tape device, you use another LPRPUTIOR command to move the device, its IOP, and its attached devices to partition B. Robot/LPAR varies off the device before moving it.
  4. After the device(s) are moved successfully, you have Robot/NETWORK tell Robot/SCHEDULE on partition B to start a job to vary on the device in partition B and start the backup process.

Other functions
The Robot/LPAR Move Resources menu also allows you to:

  • Adjust and set resource levels for processor capacity and memory size
  • Display partition information about the managed system and partitions.
  • Change the partition state to shut down or activate a partition.

Contributed by Anna Deuel, Product Manager

New job monitors help control batch processes

Wednesday, April 25th, 2007

If you have to comply with Service Level Agreements, check this out!

When you are doing the day-to-day management of your batch processes—especially if you need to comply with Service Level Agreements (SLAs)—the new job monitors in Robot/SCHEDULE 10.0 can be very helpful. They can help answer questions such as:

  • Did Job A complete on time?
  • Did Job B complete too quickly?
  • Did Job C start later than the forecasted start time?

You don’t need to use job monitors on every job. That would be overkill. But, you should use them for your critical jobs.

Setting up job monitors
When you set up the job monitors for a job, you specify the monitoring criteria (job overrun, job underrun, or late start). These options are independent of one another: you can use one, two, or all three. You also specify what Robot/SCHEDULE should do if it identifies a job monitor event. Robot/SCHEDULE can end a job or notify you by sending a message to the job’s message queue; sending a text, e-mail, or pager message via Robot/ALERT; or by sending a status message to the Robot/NETWORK Status Center.

When a monitored job reaches one or more of the criteria defined on the Job Monitors tab, Robot/SCHEDULE takes the specified action and enters a record in the job monitor event log. You can display this log from the Robot/SCHEDULE Explorer toolbar.

The Job Monitor Events Report lists all monitored events that have occurred on the system. You can specify whether to purge the job monitor log automatically, and how many job monitor events to retain in the log, on the General System Defaults window.

The Job Overrun monitor
The Job Overrun monitor detects jobs that run longer than their specified maximum duration, or complete later than a specified time of day. If the job does not meet the duration or completion time, the notification process begins. This type of check is ideal for long-running processes, such as backups or end-of-month processing. It is also good for processes that must complete by a specified time to avoid SLA penalties. For instance, your SLA may require data to be uploaded to the customer’s Web site by a specified time or you will incur a fine.

The Job Underrun monitor
The Job Underrun monitor detects jobs that complete in less than a specified minimum run time. This monitor is designed to be used with applications that rely on data that is sent to the System i from another server. If the data does not arrive on time, the files are empty. When the Robot/SCHEDULE job starts the application, it runs with great performance, but terrible results. Applications that perform data polling are notorious for this type of problem.

The Late Start monitor
The Late Start monitor detects jobs that start later than their scheduled run time by the amount of time you specify, or that start later than a specified time of day. This monitor is designed to notify you if a job has not started within the time parameters you specified. The “must start by” option is not valid for EVERY-type jobs.

Note: The Late Start monitor uses the *INTERNAL forecast to identify jobs that start later than their scheduled run time. If you add a job for which you want to specify a Late Start job monitor, the job must be included in a build of the *INTERNAL forecast to be monitored.

Effect on “dummy” jobs
To achieve similar results in earlier versions of Robot/SCHEDULE, you might have created “dummy” jobs that ran only if an important job did not finish on time. You can continue to use this approach in Robot/SCHEDULE 10.0, but we think you’ll find job monitors better and easier to implement.

Note: If you have been using the Help/FACTS, “Using the Robot Automated Operation Solution to Meet Service Level Agreements,” you’ll find that job monitors offer more options after you convert to Robot/SCHEDULE 10.0.

Contributed by Tom Huntington, Vice President of Technical Services

Help/Systems 6533 Flying Cloud Drive,
Suite 200
Eden Prairie, MN 55344
Ph. (952) 933-0609
Fx. (952) 933-8153
Contact information
Map/Driving Directions
Privacy Policy

Free Email Sign-Up

To get the latest operations automation and business intelligence news, sign up for Robot Direct by entering your e-mail address. We'll let you know about site updates or breaking news about twice a month!

Email Marketing Email:(required)


Please select default option:
HTML Version
Text-Only Version
!
Try our software FREE for 30 days!