Tools for Documentation

Enter your search terms Submit search form PowerHA Tools The original question was PowerHA specific, so let’s start with the PowerHA snapshot tool. The cluster snapshot tool lets you save and restore cluster configurations by saving a file a record of all the data that defines a particular cluster configuration. Then, you can recreate a particular cluster configuration, provided the cluster is configured with the requisite hardware and software to support the configuration. This snapshot tool can also make remote problem determination easier because the snapshots are simple ASCII files that can be sent via e-mail. You can also use the PowerHA-specific qha and qcaa scripts. These are real-time tools that you can use with your running systems more than as a deliverable, but they’re still valuable. Alex Abderrazag has provided a nice script to help you understand cluster manager internal states. HMC Scanner When it comes to documenting the way my servers have been configured, I like to use HMC Scanner. HMC Scanner gives you a nice summary spreadsheet with almost anything you want to know about your environment, including serial numbers, how much memory and CPU are free on your frame, how each LPAR is configured, information on VLANS and WWNs, and much more. I did a video on running HMC Scanner and IBM’s Nigel Griffiths has also posted a video on HMC Scanner for Power Systems. HMC Scanner works for AIX, IBM i, Power Linux and VIOS LPAR/VM. System Planning Tool I also like to use the IBM System Planning Tool (SPT), which I blogged about in “Configuring Your Machine Before it Arrives” and which you can find on the IBM support tools website. The SPT provides nice pictures of the machines showing which slots are populated and assigned to which LPARs. If you’re comfortable with the command line, you can manipulate sysplans with the following commands, which may be easier than going into the GUI to do the same functions: lssysplan rmsysplan mksysplan cpsysplan viosbr For VIO server-specific documentation, I like to use viosbr. After you’ve taken a backup, run: viosbr –view –file This provides a lot of information to document the setup of your VIO server. It will show your controllers, physical volumes, optical devices, tape devices, Ethernet interfaces, IP addresses, hostnames, storage pools, optical repository information, ether channel adapters, shared Ethernet adapters, and more. snap –e AIX-specific commands would include snap –e, which lets you gather a great deal of system information and run custom scripts to include other information with your snap. This tool is often run in conjunction with support to collect the information they need to help resolve issues with your machine. prtconf Another worthwhile command is prtconf. This command gives you information like model number, serial number, processor mode, firmware levels, clock speed, network information, volume group information, installed hardware, and more. IBM i Options For IBM i, the midrange wiki has good information about different methods you can use to gather data, including how to print a rack config from a non-LPAR system: Sign on to IBM i with an appropriate userid On a command line, perform command STRSST Select option 1, Start a service tool Select option 7, Hardware service manager F6 to Print Configuration Take the defaults on Print Format Options (use 132 columns) HMC In the new HMC GUI, you can select your managed server then Manage PowerVM and you have options to see your virtual networks, virtual storage, virtualized I/O, and more. This information can also be helpful in documenting your environment. Self-Documenting Tools I find there’s value in having systems that can “self-document” via scripts and tools compared to administrators creating spreadsheets that might or might not get regular updates as soon as changes occur. Somhotlinke might find self-documenting tools don’t provide the correct information, which leaves us with the question of whether it’s better to have no documentation or wrong documentation when you’re working on a system. Self-documenting tools are a starting point. Whatever documentation you have on hand, take the time to double-check what the actual running system looks like compared to what you think it looks like. By not assuming anything about your running systems, you can avoid creating additional problems and outages because reality didn’t match what the documentation said. Many Different Documentation Tools From the frame, to the OS, to the VIOS, to the HMC, there are many different pieces of your infrastructure to keep an eye on and many different tools you can use to document your environment. I’m sure readers use many other tools and I’d be interested  in hearing about those. Please weigh in with a comment.

Improve Memory Utilization With the PowerVM AMS Feature

Enter your search terms Submit search form The PowerVM feature, Active Memory Sharing (AMS), helps Power Systems address peak memory demands and improve overall memory utilization at the server level. Based on a concept similar to the shared processor pool, AMS starts with a pool of physical memory and then shares it among a group of LPARs. Each LPAR has a desired memory setting that specifies the amount of memory it’s permitted to use. The aggregate of the desired memory settings is permitted to exceed the physical size of the pool, which overcommits the physical memory pool from a design perspective. The main idea is to move memory to and from LPARs to satisfy their requirements. Similar to the way AIX operates, if the demand for memory exceeds the physical memory available, paging devices on the virtual I/O server (VIOS) become active. Memory sharing has different operational dynamics than processor sharing. With processor sharing, the processor state for an idle LPAR can be quickly saved, freeing it for another LPAR to use. However, the give and take of memory between LPARs isn’t as fluid as processor sharing with the shared processor pool. AMS is included with PowerVM Enterprise Edition and can be implemented on POWER6 and POWER7 servers. It’s supported with AIX V6.1 or higher and IBMi V6.1. Implementing AMS Finding situations to implement AMS can be somewhat challenging, primarily because: For most applications, you want to avoid page-in activity. If systems begin moving memory pages back into physical memory, the application is likely to suffer a noticeable degradation in performance. Many applications aren’t well behaved and don’t free up unused memory blocks. This results in a situation where memory is allocated to an LPAR, but might not be in active use. AIX (or IBMi) and the hypervisor must work together to determine which memory blocks should be paged out to the VIOS paging device. Here are two use cases that address these challenges. They’re good candidates for AMS because the shared memory pool LPARs are predominantly “quiet,” just waiting to ramp up to run production workloads. AMS provides a fast, automated method to move physical memory to the LPARs in need. AMS for High Availability Clusters Use of AMS can simplify the configuration and operation of PowerHA high-availability clusters, especially those with a large number of servers being clustered to a single recovery server. For example, you might have a PowerHA cluster with eight active servers and one hot standby server. Each active server has one 32GB production LPAR with a corresponding cluster partner LPAR on the standby server. The cluster partner LPARs only require 2GB of memory while in standby mode and 32GB of memory when a failover is active. It’s assumed that the standby server will be configured to support just one failover at a time. Without AMS, a typical design would assign 2GB of memory to each of the recovery LPARs with 30GB of unallocated memory available for an active failover. Total memory required on the standby server would be 46GB [(8 x 2GB) + 30GB = 46GB]. During a cluster failover for one production LPAR, an additional 30GB of memory would need to move to its cluster partner on the standby server. This could be accomplished with a scripted or manual dynamic LPAR (DLPAR) operation at the Hardware Management Console (HMC). Implementing AMS on the standby server, however, can simplify and automate this process. With AMS, a 48GB shared memory pool would be configured. Each cluster partner LPAR would be set up to have access to 32GB of memory from the pool. During a failover event, the corresponding cluster partner LPAR would automatically make use of up to 30GB of additional physical memory from the pool. There should be no delay in acquiring this memory because it doesn’t need to freed from the other LPARs. After the production workload has been shifted back to the production server, the additional 30GB of memory is no longer needed on the cluster partner. To prevent that 30GB from remaining with this LPAR, it could be shutdown and reactivated. The LPAR would reboot and resume operation with just the 2GB of memory required to sustain standby operations. This would leave 30 GB of unallocated memory in the shared memory pool, ready for use by any cluster partner LPAR. AMS and Disaster Recovery Using AMS as part of a disaster recovery (DR) architecture has a similar theme. Assume you have a collection of DR recovery LPARs with minimal workload under normal operation. This time, a DR event causes an AMS-based recovery LPAR to make use of additional memory. When the DR event occurs, the workload on the corresponding recovery LPAR increases, and memory is automatically shifted to that LPAR from the shared memory pool. Using AMS for DR would work best if the collection of recovery LPARs on a single server was composed of a mix from several physical production locations or at least, different physical servers. If all recovery LPARs on a single server were to become active at the same time, an overcommit situation would likely result in undesired paging. Another option would be to configure development and test LPARs along with the recovery LPARs at the DR site. The recovery, development and test LPARs would share a single shared memory pool. During a large-scale DR event, the development and test LPARs could be shutdown. This would automatically free up memory in the pool for use by the recovery LPARs. Potential Savings With some creative thinking, you may find a good use for AMS in your Power Systems environment. This will position you to take advantage of the flexibility and potential cost savings available with AMS.

Manage AIX Workloads More Effectively Using WLM

Enter your search terms Submit search form Since AIX V4.3.3, the free, built-in offering called Workload Manager (WLM) has allowed AIX administrators to consolidate workloads into one OS instance. WLM manages heterogeneous workloads, providing granular control of system CPU, real memory and disk I/O. It does this using percentages of resources and a combination of classes, shares and tiers to manage CPU time, memory and I/O bandwidth. WLM is integrated with the AIX kernel including the scheduler, Virtual Memory Manager and disk device drivers—running in either active or passive modes. Effectively a resource manager, WLM tracks: The sum of all CPU cycles consumed by every thread in the class The physical memory utilization of the processes in each class by looking at the sum of all memory pages belonging to the processes, and The disk I/O bandwidth in 512-byte blocks per second for all I/O started by threads in the class A combination of targets and limits can be used to determine how resources are allocated. Targets are basically shares of available resources and range from 1 to 65,535, whereas limits are percentages of available resources with a minimum, soft maximum and hard maximum setting. Limits take priority over shares so, normally, only limits get defined. Hard limits have precedence, then tiers, soft limits and, finally, shares. Tiers WLM uses tiers to define class importance relative to other classes. You can define up to 10 tiers (0-9) to prioritize classes, with 0 being most important and 9 least important. WLM assigns resources to the highest tier process that’s ready to run. Processes default to tier 0, but it’s common to assign batch or less important workloads to tier 1 to prioritize online response. Classes A class is a set of processes with a single set of resource limits. An individual class is either a superclass or a subclass. Resource shares and limits are assigned to a superclass based on the total resources in the system. Subclasses can be defined to further divide a superclass’s assigned resources among its assigned jobs. Five predefined superclasses exist by default, and you can add up to 27 user-defined superclasses. Each superclass can have 12 subclasses: two predefined and 10 user-defined. Each class is assigned a name with a maximum of 16 characters. Superclass names must be unique, and subclass names must be unique within their assigned superclass. Classification The files necessary to classify and describe classes and tiers are defined in the /etc/wlm directory, beneath which is a directory created for the schema to be used. For example, if the /etc/wlm/prodsys95 directory is the production system’s definition for 9-5, an additional directory could be created for outside those hours. A simple cronjob command could switch between the two definition sets. Classification requires several files, including: Classes list each class, its description, the tier to which it belongs and other class attributes. Rules are where control is exerted over the class resources. Limits and shares define resource limits and shares, respectively. The optional description file includes a definition of the classes. Threads are assigned to a class based on class rules. This can be done automatically using a rules file or manually by a superuser. Each class assigns minimum and maximum amounts for CPU, memory and I/O throughput. To correctly assign a process to a class, WLM goes through process identification, analyzing the process’s attributes to see how it matches up with the class definitions. Processes can be identified and classified by owner or group ID, the full application path and name, the process type or a series of application tags. WLM assigns each class a set of resource shares and limits. Additionally classes can be assigned to tiers to further group and prioritize classes. WLM reads the rules file from top to bottom and assigns a process to the first matching rule, which makes it important to list rules from specific (top) to more general (bottom). Processes are generally assigned to a class based on the user ID, group or fully qualified path and application name. Type and tag fields can also be used. Type can be 32bit, 64bit, “plock” (the process is locked to pin memory) or fixed (a fixed-priority process). What WLM Does For CPU, WLM gathers utilization for all threads in each class 10 times per second in AIX V5.3 and beyond. It then produces a time-delayed average for CPU for each class. That average is compared against tier values, class targets and class limits, and a number is produced that results in either favoring or penalizing each thread being dispatched. WLM also monitors memory 10 times per second and enforces memory limits using least recently used (LRU) algorithms. As of AIX V5.3, TL05, it’s possible to set hard memory limits. However, if that limit is reached, the LRU daemon will start stealing pages from the class—even if memory pages are free. For I/O, WLM enforces limits by delaying I/O when the limit is reached. Activation and Monitoring WLM can be started in one of two modes: passive or active. Always start with passive so the effects can be monitored without making it active. Do this using the command /usr/sbin/wlmcntrl -d prodsys –p where prodsys is the directory name in which the configuration files live. Once the configuration has been proofed and monitored, WLM can be started in active mode by leaving off the –p. Steps to Implementation The first, most critical step is to design the classification criteria. Do so by evaluating workloads and determining how tiers and classes will be broken down, along with what limits should be applied to them. The second step is defining the class, limits, shares and rules files, and starting WLM in passive mode. Then refine the definitions before activating them. Once everything is tested, the final step is to restart WLM in active mode so it not only monitors—but also manages—the system. WLM enables the consolidation of workloads into one AIX instance while ensuring that applications get the percentage of resources required to provide the performance necessary for success. This allows workloads to be combined into the same OS instance to take better advantage of system resources. It’s worth the effort to classify workloads running on your systems now, even if WLM only ever runs in passive mode. This provides an additional means of monitoring what’s happening as well as a potential management tool, should the need arise. Commands for WLM acctcom Updated with a –w flag to list WLM information and a –c flag to list only specific classes, many other commands, such as ps, were also updated. nmon nmon has been updated to gather WLM statistics (use the –w flag). nmon analyzer The analyzer reports on WLM statistics, adding data in the BBBP tab and adding three new tabs that contain WLM information – WLMBIO, WLMCPU and WLMMEM. ps –ae –o pid,user,class,pcpu,tag,thcount,vsz,wchan,args This command provides a list of processes that includes WLM class information

Improve Your Operations with New CoD Features

Enter your search terms Submit search form IBM recently enhanced its Capacity on Demand (CoD) offerings for the new POWER7+ 770 and 780 servers and updated POWER7 795 server. These enhancements provide new operational features and financial benefits. A closer look might change your perspective on CoD from a usage model for special circumstances to one for mainstream, day-to-day use. Enterprise class Power Systems servers can be configured with CoD processor cores and memory that are readily available when needed. CoD resources can be enabled with: Capacity Upgrade on Demand (CUoD permanent activation) Elastic CoD Utility CoD (cores only) Trial CoD Elastic CoD For this article, I’ll focus on the recent enhancements to Elastic CoD, which is a new name for what was previously called On/Off CoD. This name change is meant to emphasize the new features being offered. Like On/Off CoD, Elastic CoD allows you to activate CoD resources in 1 processor core and 1 GB memory increments. Processor cores and memory can be activated independently of one another. To get started, Elastic CoD enablement keys must be entered at the Hardware Management Console (HMC). When these resources are needed, the desired amounts of processor cores or memory are activated via the HMC. Resource use must be reported to IBM monthly and is billed quarterly. The monthly reporting requirement can be automated through an HMC connected to IBM via Electronic Service Agent. With the previous On/Off CoD implementation, the enablement keys permitted the use of up to 360 processor days and 999 GB memory days. Upon reaching one of these limits, a new enablement key had to be ordered. Some customers found themselves in a situation where they had to frequently re-order enablement keys. For example, if you were to activate 16 cores for a temporary project, 360 processor days would be consumed in just 22 days. Likewise, if you activated 64 GB of memory, it would take just 15 days to reach the 999 GB memory days permitted. A new 90-day Elastic CoD offering provides the ability to activate all CoD processor cores and memory for a full 90-days per enablement key. This will eliminate the requirement to frequently reorder the enablement keys for heavy users of CoD resources. Credits Elastic CoD credits are a new feature available with the purchase of new 780+ and 795 servers. As part of the server purchase, IBM will provide a quantity of no-charge, temporary processor core days and GB memory days to be used at your discretion. Potential uses include: addressing processing peaks, setting up temporary virtual servers, workload balancing, or disaster recovery (DR). The CoD credits are immediately available whenever you need them. There’s no need to submit a request for temporary activation keys. Here are some highlights of the Elastic CoD credits offering: Credits are included with the original purchase of a new Model 780 (9179-MHD) or Model 795 (9119-FHB) server. The servers must be running system firmware level 7.6 or higher. A credit of 15 Elastic On/Off processor days and 240 GB memory days will be provided for each installed processor core that’s purchased. Both active and CoD processor cores qualify as installed processors. The credit is held “on-account” by IBM. To acquire and make use of the credits, a temporary CoD contract must be in place with IBM. This contract has two primary requirements: Elastic CoD usage must be reported to IBM monthly, and Usage will be reconciled quarterly. Once all credits have been consumed, an invoice will be generated for additional use. Here’s an example for a Model 780 system ordered with 32 processor cores installed and 16 processor core activations. The credits provided are: 32 installed cores times 15 core days per core equals 480 available processor days 32 installed cores times 240 GB memory days per core equals 7,680 GB memory days Note that the 16 processor-core activations are not relevant to the amount of credits provided. Power Systems Pools The Power Systems Pools feature is also available for use with new Model 780+ and 795 servers. Designed to assist customers with planned maintenance events, the feature enables you to redistribute your processor and memory activations across a pool of 780 and 795 servers during an event. This is an enhanced version of the former PowerFlex offering for Model 795 servers. The following are some configuration and operational rules that apply to Power Systems pools: The pool can consist of any combination of up to 10 780 and 795 servers running system firmware 7.6 or higher. At least 50 percent of the total amount of installed processors and memory within the server pool must be permanently activated. You’re permitted to have eight planned maintenance events per year. All of the servers within a pool are permitted to participate in each event. AIX and IBM i cannot be intermixed within the same pool. Each maintenance event can last up to seven days, after which, all processor and memory resources must be returned to their previous state. Requests for a maintenance event must be submitted to IBM at least two business days prior to planned usage. Power Systems Pools can make it much easier to conduct planned maintenance events with no application downtime. Once the temporary activation keys are entered at the HMC, the Live Partition Mobility (LPM) feature of PowerVM can be used to migrate LPARs off of the servers requiring maintenance. Note that this feature is not intended to be part of a DR scenario due to the two-business-day requirement to acquire the temporary activation keys. Reconsider CoD IBM’s new 90-day Elastic CoD enablement feature, no-charge CoD credits and Power Systems Pools features offer ways to get creative with CoD implementations. Use of these new features can improve operational flexibility and provide financial savings.

Working With Active Memory Expansion

Enter your search terms Submit search form Active Memory Expansion (AME) is a Power Systems feature that can improve the utilization of physical memory assigned to an LPAR. Operating systems running on AME enabled LPARs are unaware that AME is active. If you need to free up physical memory on a server, AME can be used to reduce the physical memory assigned to LPARs. If you have an LPAR that needs more memory, AME can make additional memory available without an increase to the LPAR’s physical memory assignment. Introduction to AME AME expands the physical memory assigned to an LPAR and makes the installed operating system “see” more memory than is actually assigned to it. For example, an LPAR might have a desired memory setting of 32 GB, but with AME enabled the operating system might “see” 40 GB. The hypervisor achieves this expansion by compressing least used memory pages. The increase in available memory is called the expansion factor. Continuing our example, the expansion factor is 1.25, which increases the 32 GB of physical memory allocation by 25 percent. This results in 40 GB of memory visible to the LPAR. On POWER7 servers, the compression/expansion is performed using general processor cycles. For POWER7+ and POWER8 servers, dedicated AME circuitry was added to the processor. This circuitry reduces general processor cycle consumption by 90 percent. Preview the Benefits of AME The AIX command amepat (AME Planning and Advisory Tool) can be used to estimate the AME benefit for a particular workload. It’s available on AIX 6.1 and higher and can be run on servers as old as POWER4. The amepat tool should be run during peak processing periods. If you conduct your AME modeling during non-peak periods, CPU contention might occur during peak workloads as AME might consume more CPU than originally planned. The output of the amepat command displays a table of data that lists various options for memory expansion with four main columns: Expansion Factor provides a multiplier for how much additional memory the LPAR will see. For example, an expansion factor of 1.5 indicates that the LPAR will see 50 percent more memory than the modeled physical memory allocation. Modeled True Memory Size is the amount of physical memory that would be allocated to the LPAR. Modeled Memory Gain is the amount of additional memory above the physical memory that would be provided through the use of AME. CPU Usage Estimate lists the estimated amount of CPU that would be consumed for the corresponding expansion factor. As the expansion factor increases, so will the amount of required CPU to achieve this level of expansion. One of the flags for amepat lets you specify the target environment where you plan to use AME. This takes into consideration the significant reduction in CPU usage provided by the dedicated AME circuitry on the POWER7+ and POWER8 processors and can be helpful when consolidating older server workloads onto newer servers. An average compression ratio is also displayed. Larger ratios indicate good compressibility. You might also see an amepat output that shows 0.00 for the CPU Usage Estimate. This indicates that there’s an opportunity to reduce the amount of physical memory assigned to the LPAR without consuming any CPU. At some point, further reductions in physical memory would then begin to invoke some level of AME work and begin to consume some CPU cycles. Enabling Your Server to Use AME AME is available for POWER7/7+/8 servers running AIX 6.1 or higher. The server must be managed by an HMC. AME is ordered as a server hardware feature code, with the initial server order or as an upgrade. There is a single one-time-charge for AME per server. Once purchased, IBM provides an AME enablement license key. This license key is entered on the HMC. All of the LPARs running on an AME enabled server are eligible to use AME. The break-even point for the purchase of AME on POWER8 servers can be expressed in terms of physical memory purchase avoidance: S822: 40 GB S824: 40 GB E850: 60 GB E870: 41 GB E880: 41 GB For example, on an S824 server, if you can use AME to reduce physical memory consumption by at least 40 GB then AME might be a good fit. Configuring an LPAR to Use AME AME is enabled for an LPAR within the partition profile configuration menus. If your server has AME enabled, you’ll see AME configuration options at the bottom of the partition profile memory configuration tab. There’s a checkbox to enable AME. If checked, you’ll also need to provide an expansion factor in the range of 0 to 10. Note that choosing 0 would yield no expansion. For performance tuning, the expansion factor can be dynamically changed on a running LPAR using a dynamic LPAR (DLPAR) operation from the HMC. You might also choose to use DLPAR operations to change (add/remove) the amount of physical memory assigned to the LPAR. Monitoring AME in Use The amepat tool can also be used with an LPAR that has AME enabled. Data about the current amount of memory compression and CPU use for AME will be displayed. In addition, amepat will list several potential expansion factor values along with corresponding modeling data, similar to the information provided when amepat is run in a preview mode for LPARs not actively running AME. Last, amepat will provide recommended configuration changes to improve the overall performance of AME for the LPAR. Take a Test Drive If you’re planning to migrate LPARs running on older Power servers to new POWER7/POWER8 servers, it’s recommended that you run the amepat tool on your LPARs to see if AME would be effective for your workloads. For workloads already running on POWER7/POWER8 servers, running amepat can help you decide if implementing AME would be beneficial. Remember that AME can be used to expand the memory of an existing LPAR or to reclaim physical memory. If you have some LPARs that look like a good fit for AME, IBM offers a one-time, no-charge 60-day AME trial per server. This trial will allow you to conduct real AME test before committing to a purchase of AME. Find additional information in the IBM Knowledge Center.

AIX Call Home Web Monitors System Health

Enter your search terms Submit search form

IBM Call Home is an incredibly useful feature that monitors the health of your system and automatically notifies both you and IBM support when events that need action take place. It will automatically open a service request and transfer the initial diagnostic data to the support team so that they can start an initial remediation plan. The only data sent is diagnostic data, which is encrypted to ensure security. This feature helps ensure rapid remediation of system problems and should be enabled on all systems where possible.

Enabling Call Home

Call Home is also referred to as ESA (electronic service agent) and this software is installed on the HMC (hardware management console) if you have one. Otherwise you need to install it on every server. Below are the instructions for configuring it on the HMC; on a server you would go to smitty and select electronic service agent. If that isn’t an option, then you may need to install it. The ESA home page has links with instructions on installation and configuration.

Configuring on the HMC

• On the HMC you configure ESA and then enable it for use
• The configuration will request your IBM customer number, contact information and details for sending notification emails
• You will need to allow communication to IBM servers through your firewall
• Verify connectivity between the HMC and IBM

So what is Call Home Web

Call Home Web is a new feature that was added to Call Home. It provides a dashboard that gives a view into your most recent events along with a summary of the past seven days. The system summary can be exported for later use. Call Home Web supports most Power Systems, Power-based PureFlex Systems, and IBM Storage Systems that report Call Home information. In order to use Call Home Web, the system must either be under warranty or be included in a maintenance support contract. When the system is added to Call Home Web, an entitlement check occurs⎯if a warranty or support contract cannot be found then the system cannot be added. At that point, you can request manual entitlement assistance.
Features provided by Call Home Web include:
Dashboard view
Where you view your most recent events and a summary of the past seven days
Manage my systems
Where you edit information about your systems and organize systems into groups
Groups
Which allows you to group systems into logical groups. You may want to group all the HR systems together or all the database ones or you may prefer other groupings
Contract information
Keeps track of information on your warranty and support contract, including when it expires. It can be set up to notify you when your contract is close to expiring
Events by my inventory
Shows events for your system, on an individual or group basis if groups have been set up
How to and help information
Also called Call Home Assistance. Provides information on how to set up and enable Call Home and Call Home Web as well as on how to register systems and general usage. You can also get additional site assistance such as descriptions of what the various icons mean
Risk analysis indicators
From the dashboard you can go to the system summary section to get a breakdown of indicators of current risks to your systems, specifically backlevel software.
Recommended software level
Under system details there is a risk analysis section that provides details on whether your system is at the minimum recommended level. If it’s not at the minimum recommended level, then links are provided to download that level.
Notifications for back-level software
Under system details is an associated users section, where you can request notifications when Call Home determines that your software is backlevel
System summary by group
If you have setup groups, then on the dashboard under system summary you can choose to display by group, sort by group and filter by group. This lets you quickly drill down into groups of systems that maybe having issues.

Adding Systems

Another feature added to Call Home Web is the ability to request a boarding spreadsheet. If you have a large number of systems to add then you can send an email to spe@us.ibm.com and request a boarding spreadsheet. This comes with instructions and allows you to put all your systems in a spreadsheet that will then be uploaded by the Call Home helpdesk. Individual systems are added using the Managing My Systems tab. You start by clicking on the Register New Systems button and then follow the instructions. Using an S824 8246-42A serial 02-0012345 as an example, you will need to be able to provide the following information:

• 4 digit Machine type – i.e. 8246
• 3 digit Machine model – i.e. 42A
• 7 digit Machine serial – i.e. 0012345
• Call Home Web System name – whatever name you want Call Home Web to refer to this system by
• Country where the system gets its entitlement
• Your IBM customer number – 7 characters

After you click on submit you’ll see either registration success, entitlement failure, test event required or machine type not supported by Call Home Web. If the registration is successful, then click on the “Requires confirmation” link and agree to the terms and conditions. If it requires a test event, then generate a test event for that server within 3 hours. Creating a test event or problem is a function within ESA that is easy to perform. If you receive an entitlement failure, then click on the link to get more information and complete the entitlement failure form to have the help desk determine the issue.

Summary

IBM Call Home constantly monitors the health and functionality of your system. This is a critical tool in your system health and maintenance strategy. IBM Call Home Web provides you with an additional interface that allows you to group information together and rapidly get an overall view of your entire environment’s health. In today’s business environment it’s important to understand this. Call Home and Call Home Web provide a view into your systems that helps you proactively manage events to reduce potential downtime.