Question; have you or a colleague ever executed the PWRDWNSYS command by mistake?
Following on from my introductory article earlier this month about exit points here’s a straightforward (and useful!) one to get you started.
Question; have you or a colleague ever executed the PWRDWNSYS command by mistake?
On a system with multiple LPAR’s running it is quite easy to forget which LPAR you are working on. Sometimes in my working environment of customer system DR restores, testing and running simulation upgrades it is possible to be working on live LPAR’s and test versions at the same time.
Confession time; I was once within an F16 of restarting a customer’s production LPAR instead of the test version I had restored in the office. Eek!
ProTip: When using the ACS Client (which you should all have migrated to by now!) use the Watermark feature so you can easily see which LPAR you are about the execute the PWRDWNSYS command on.
So how do you get the system to ask the question, are you really sure you want to do this? The answer is by using an IBM i exit point called QIBM_QWC_PWRDWNSYS. This pre-power down system exit point QIBM_QWC_PWRDWNSYS has two possible formats, PWRD0100 and PWRD0200.
Format PWRD0100
The first format PWRD0100 is used to add a program that is called when the PWRDWNSYS command is used. This format has no parameters and, in this example, will simply issue a message to the QSYSOPR message queue. Here’s the CLP you would need.
Compile the program and then you would register the exit point like this
ADDEXITPGM EXITPNT(QIBM_QWC_PWRDWNSYS) FORMAT(PWRD0100) PGMNBR(1) PGM(YOURLIB/YOURCLP)
WRKREGINF to see a list of exit points and any attached exit point programs.
ProTip: A user must have *allobj and *secadm special authorities to add or remove exit programs to/from an exit point.
The program number comes into play if you have multiple exit point programs for a specific exit point.
Once this is done any time the PWRDWNSYS command is issued a message will be sent to the QSYSOPR message queue and the power down process will not continue until the message is answered with a G. This also works when using the go power menu.
So in this example you can’t prevent the PWRDWNSYS executing but you have just created an extra hurdle to jump. But as this is now a program, you can add what ever logic is most appropriate to your environment. Perhaps you would want to check
The user issuing the command is part of a nominated group
No one else is signed on
Your applications have been shutdown
That this user knows an extra password
The point is you can tailor this logic to whatever suits your environment the best.
One last point to note is that when using format PWRD0100 the exit program is called when the PWRDWNSYS or ENDSYS commands are used.
ProTip: If a user exit program is defined to the QIBM_QWC_PWRDWNSYS exit point for format PWRD0100, then the PWRDWNSYS command issuer must have *use authority to the user exit program and *execute authority to the library that contains the program. If not, then the user exit program is not called and the system will continue to power down.
Format PWRD0200
The second format PWRD0200 is a bit more complex and can be used to add one or more programs that are called when the PWRDWNSYS command is used.
These exit programs can perform clean up functions or check that jobs have completed before the system is powered down. It also has the ability to cancel the PWRDWNSYS request should your exit program determine that the PWRDWNSYS should not be allowed to proceed. More on this next month.
Summary
This exit point can be really useful in controlling power down sequences and ensuring all is well before allowing the PWRDWNSYS request to execute.
You can have a read about this exit point here https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_74/apis/xpwrdwn.htm