Running Down Cache Battery Rumors and More on Damaged Objects
September 21, 2011 Hey, Joe:
I read your article about changing iSeries disk caching batteries. You said that iSeries administrators should call IBM to send out new batteries, and then schedule an IBM service call for replacement. Is this considered standard IBM maintenance or are batteries a consumable item that is billable? I’ve heard rumors of changes in IBM’s policy, where they are starting to charge for batteries…
With some help, I ran this issue past both an IBM Certified Engineer (CE) and someone in IBM CE dispatch. Both people said that it was just a rumor and that cache battery maintenance falls under your standard IBM maintenance contract. My recent experience backs that up. We replaced the batteries in two System i machines this year, and both times the replacement batteries and installation were covered under maintenance. When you call for battery maintenance, you can also ask IBM whether the batteries are covered under maintenance. They should confirm the batteries are a covered item.
Read your article on finding damaged objects in i OS 6.1.1 and had a question. Why can’t you just use the Display Object Description (DSPOBJD) command to look for damaged objects instead of using the Retrieve Disk Information (RTVDSKINF) command mentioned in your article? You can also find out whether an object is damaged by checking the Object Damaged field in a DSPOBJD output file.
Good catch, Steven. You can use DSPOBJD to find damaged objects by outputting object information to either a spooled file or to a database file.
To output object information to a spooled file, run the following DSPOBJD command to retrieve object information for all objects on your system.
DSPOBJD OBJ(*ALL/*ALL) OBJTYPE(*ALL) DETAIL(*FULL) OUTPUT(*PRINT)
If you want to retrieve this information into an output file that can be queried, run this DSPOBJD command instead.
DSPOBJD OBJ(*ALL/*ALL) OBJTYPE(*ALL) DETAIL(*FULL) OUTPUT(*OUTFILE) OUTFILE(LIBRARY/OUTPUT_FILE)
Where OUTPUT_FILE equals the name of the output file you want to store the information in and LIBRARY equals the library name where you want to store the output file.
When DSPOBJD runs, it checks all system objects it finds to determine if each object is either locked or damaged. When outputting information to a spooled file, DSPOBJD marks these objects as “locked” or “damaged” in the text description printed with each object in the report (for spooled file output, DSPOBJD only writes a single report line for each object it examines).
When DSPOBJD writes object information to a database file, it includes an Object Damaged field (ODOBDM) with each record. ODOBDM contains one of three values (0=Not Damaged, 1=Full damage, 2=Partial damage). So DSPOBJD is a valid alternative method to using RTVDSKINF to find damaged objects.
Be aware, however, that since I originally wrote that article, I’ve received a report that one reader ran RTVDSKINF to an output file every night and he says it did not write a 2 (damaged object) for a damaged controller object to the RTVDSKINF’s output file. I don’t know if this is a normal occurrence, but be on the lookout for RTVDSKINF scans that bypass damaged objects, and please write me back if you find any evidence of this occurring.
The biggest issue with using DSPOBJD for looking for damaged objects is that like RTVDSKINF, DSPOBJD will only look for damaged objects in native DB2 libraries. It doesn’t evaluate objects in the AS/400 Integrated File System (AS/400 IFS). To find damaged objects in the AS/400 IFS, you will still need to run the Reclaim Object Links (RCLLNK) command that I mentioned in my original article. To look at your complete system (native DB2 libraries and AS/400 IFS), you will need to run DSPOBJD (or RTVDSKINF) in conjunction with RCLLNK.
Reflecting on the whole process, your best bet is to detect damaged objects through a full system backup (FSB). A FSB checks all objects for damage before backup, and it is a reliable damaged objects detector. However, I also understand that with the 24x7x365 demands most iSeries, System i, and Power i shops have, you may not be able to run an FSB on a regular basis. In those instances, it’s best to fall back on using RTVDSKINF, DSPOBJD, and RCLLNK to find damaged objects.