Comments on: We have a Cache Battery failure on 550boxes, will it affect?

By: splat

splat — Fri, 03 Jul 2009 15:34:20 +0000

This happened to us a year or so ago. I/O performance was noticeably degraded, but per my CE nothing was at risk. We took the system (a 525) down for the battery replacement – the CE wasn’t keen on the idea of hot-swapping that part.

If you do drop the system for the replacement, use the *CNTRLD option on your ENDSBS – this tells the system to clear the cache, preventing data loss.

By: harisudhan21

harisudhan21 — Thu, 02 Jul 2009 13:51:15 +0000

There was a decline in the performance and we had critical overnight jobs running all through the day as a result of this during the Quarter end process. So we had to change the battery asap and there was a considerable difference in the system speed!

Thanks all for the discussion!
Hari

By: mcl

mcl — Fri, 12 Jun 2009 17:53:12 +0000

Some of the newer systems are set up so the batteries can be replaced concurrently. Most of the others are easy to do, but the system has to be down. We have a 570 that required about 4 hours to replace the batteries on the controller in the 570 chassis – but most of the others are 1 to 1 1/2 hours. Most of that time is powering the system down and back up – if the IBM CE knows what to do.

Yeah, you could do a save first – it all depends on your backup strategy as to what you might need to save – and when you did a full backup last.

I highyly recommend checking the battery status periodically using STRSST. The number of days to warning and error are estimates. System IPL’s will tend to change those values.

You can run for a while with a battery error state. We ran for two months with a battery error on our development box because purchasing had not renewed the service contract and wouldn’t pay for a service call. I did a lot of grumbling during that time…

Regards
Mike

By: dand

dand — Fri, 12 Jun 2009 16:25:23 +0000

I agree, and of late have been letting IBM replace the batteries concurrently, but several yrs ago a CE wiped out my ASP when he initialized a cache battery before replacing it. Fortunately we had done a save lib immediately before he went to work killing my system, but I had to wait for the last savsys to be sent from Iron Mountain, and ened up working straight through for 32 hours restoring the system. If you have the time, it is better to do the save first and replace the battery(s) from DST.

By: batman47

batman47 — Fri, 12 Jun 2009 15:23:46 +0000

There is a natural fear from some people when you see cache battery packs fail. I’ve been administrating the iSeries since it came out in 1988. The system has never crashed despite these cache battery packs running out of life and IBM never recommended performing a save before replacing them since they are obviously aware of the system’s design.

By: woodengineer

woodengineer — Thu, 11 Jun 2009 16:13:55 +0000

The cache battery effects on your disk controller card. When the battery is out, the system requires confirmation of a disk write before allowing processing to continue. This is what slows the system. We had to shut down our 520 to replace the battery. The kicker was that IBM strongly recommended an Option 21 Save before replacing the battery. That was the real time killer. It seems like a whole lot of CYA but that is the way IBM likes to do things. The save is your option.

A battery typically lasts about three years.