PWRDWNSYS Taking Forever After a Full System Save?

Quite frequently we encounter customers who explain to us that when they execute a PWRDWNSYS (Power Down System) command immediately following a full system save the system appears to “hang” and take forever to power down.

The scenario is always the same, they did a full system save (for example, a GO SAVE option #21) and then as soon as the full save has completed they invoke the PWRDWNSYS command (with either RESTART(*YES) or RESTART(*NO) specified, it doesn’t matter) and then the system appears to “hang” with the system displaying the SRC code “D6000298” for the partition for an extended period of time.  Once the SRC code disappears, the system powers down shortly thereafter.

We see this condition primarily on systems that have a large number of objects in the IFS (often, in the millions!) and large amounts of main memory allocated to the system/LPAR.

So, why does this happen?  This happens by design, and here’s why…

 

Save operations on IBM i create changed pages in main system memory, and once a page in main memory is changed as a result of the save operation, it needs to be written back out to disk so the change isn’t lost if the system is shutdown.  If you are backing-up an IFS that has millions of files in it then that could very well mean that when the save of the IFS is finished you have millions of pages hanging out in main system memory that need to be written back out to disk before the system can be safely shutdown, this is integral to the storage management architecture of IBM i.  The system SRC code “D6000298” is coming from the storage management function and it signifies that the system is currently doing its job and moving pages in main storage (main memory) back out to disk.

Now, how can you speed up your system’s power-downs after you do a full save?

 

Well, the first way is obvious, simply try to avoid invoking the PWRDWNSYS command immediately after you save your system, especially when your system has a large number of files in the IFS, but that isn’t always a practical (and realistic) resolution.  The most efficacious approach is to simply have storage management use a faster method to move all those changed pages in main memory back out to disk before the PWRDWNSYS command executes, and that can be done using a wonderful little command that you’ve probably never heard of, the CLRPOOL (Clear Pool) command.

Some of you who may have done some IBM i development work in a current or past life may have used the CLRPOOL command in conjunction with the SETOBJACC (Set Object Access) command to preload data on disk into main memory to make your applications go zoom!, but what you may not know is that the CLRPOOL command, when used all by itself as part of your system backup procedure, can greatly cut down on the amount of time that it takes to do a PWRDWNSYS on your system after a full save.  The CLRPOOL command is the key here because it forces all of the changed pages out of memory and back to disk faster than the standard system power down procedures can.

Rolling the CLRPOOL command (as shown in Screen #1 below) into your backup procedures is quick & easy, here are a couple of example approaches:

  • If you use a custom CL program to do your system saves, simply insert the CLRPOOL command right before you invoke the PWRDWNSYS command in your program
  • If you use BRMS for your saves, add the CLRPOOL command as an “Exit command” on the last entry in the BRMS Backup Control Group as shown in Screen #2 below

Screen #1

Screen #2

If your IFS is now busting at the seams and you have the need to regularly IPL your system immediately after a full save, try using CLRPOOL to speed up those IPLs and shutdowns!

More from this month:

1 thought on “PWRDWNSYS Taking Forever After a Full System Save?”

Leave a Comment

Your email address will not be published. Required fields are marked *