Thanks for confirming and testing RUNAA2. Maybe, Jos will have the opportunity to use it (in conjunction with CHGSSTUSR command to change the password, as it is required to do so within Kyndryl, every time a shared password is used).
Original Message:
Sent: Thu October 31, 2024 09:11 AM
From: Ben Rabe
Subject: IBMi - PowerHA approach for OS-interventions
Marc, your memory does serve you well and there is a RUNAA2. However, in order to run that you still have to qualify with an OS user id/pw/confirm pw as well as SST user id/pw/confirm pw.
But I did test that too and it did allow me to run the macro.
> QMGTOOLS/RUNAA2 OS400USR(BRABE) OS400PWD() OS400PWD2() SSTUSR(QSECOFR) SSTPWD() SSTPWD2() AAMACRO1(IOHRIDEBUG) AAOPT1('-removenonreportingdisks')
Request completed
Upon completion I went out and checked and all of my failed/non-reporting resources were cleaned up and the only things left behind were resources with an Unknown status.
As for your other issue with running Multipathresetter, that's an entirely different macro and I will just say that it depends on why you had to run it as well as what technologies are being used, but that macro is already called by default in PowerHA as needed and by PowerHA Tools.
PowerHA tools also offers a command to run a reset from command line....and also, if there were a valid need to run it from a native OS command, an IDEA submission would be the next logical request.
------------------------------
Ben Rabe
Original Message:
Sent: Thu October 31, 2024 05:19 AM
From: Marc Rauzier
Subject: IBMi - PowerHA approach for OS-interventions
That's a good idea to raise an IDEA! At the same time, it could be interesting to request an OS command to reset disks multipaths. I remember loosing tons of time to do it manually in the past. I am retired now for a couple of years but, in the Kyndryl (or IBM SO/ITD/Infrastructure Services) context, using an SST user profile involves connecting to a shared password vault, requesting the password with a valid reason, connecting to SST, changing the password in both vault and SST, then run the multipath resetter macro. And if your OS profile does not have *SERVICE special authority, you have to perform this procedure for another profile (such as QSECOFR) which has it. Hopefully, they found now a way to change this password automatically from the vault.
PS: wasn't there a RUNAA2 command in the past with more capabilities than RUNAA? Or, is my memory getting in trouble?
(Jos, I hope that everything is running fine for you and the IBM i team within Kyndryl)
------------------------------
Marc Rauzier
Original Message:
Sent: Wed October 30, 2024 02:58 PM
From: Ben Rabe
Subject: IBMi - PowerHA approach for OS-interventions
I should add that QMGTOOLS/RUNAA macros are meant to be used for data collection and not performing tasks to the system, such as removing failed/non-reporting resources.
We could consider in the future having some option that could do this, or the IDEA could be raised to request an OS command to run this interactively from a command line.
https://ibm-data-and-ai.ideas.ibm.com/
------------------------------
Ben Rabe
Original Message:
Sent: Wed October 30, 2024 02:55 PM
From: Ben Rabe
Subject: IBMi - PowerHA approach for OS-interventions
@Marc, that's a good idea.....but:
QMGTOOLS/RUNAA RQS(*IOHRIDEBUG) DATA('-removenonreportingdisks')
Requested advanced analysis command IOHRIDEBUG is not supported.
Seems we do not allow that to be performed at this time.
------------------------------
Ben Rabe
Original Message:
Sent: Wed October 30, 2024 02:33 PM
From: Marc Rauzier
Subject: IBMi - PowerHA approach for OS-interventions
Hello Jos
You may want to try QMGTOOLS/RUNAA command (https://www.ibm.com/support/pages/qmgtools-run-aa-macros). There is an *IOHRIDEBUG value for REQUEST parameter. With -removenonreportingdisks for DATA parameter, it might perform what you are looking for.
------------------------------
Marc Rauzier
Original Message:
Sent: Wed October 30, 2024 07:06 AM
From: Jozef Thijs
Subject: IBMi - PowerHA approach for OS-interventions
Brian and Ben, thanks for your valuable feedback.
Another question ... related to the switching of the iASP ...
In this environment, I see 10000 (and more) devices which are not reported anymore in SST. In fact, disk units (DMPxxxx) unknown. I can perform a manual cleanup of all these 'failed / non-reporting devices in Service tools ... but is there no program or command available which I can run regularly to perform a nice cleanup in SST ?
Thanks,
Kind regards,
Jos
------------------------------
Jos (Jozef) Thijs
Kyndryl Belgium
Original Message:
Sent: Thu October 10, 2024 08:52 AM
From: Jozef Thijs
Subject: IBMi - PowerHA approach for OS-interventions
Hello all,
I have to manage a new environment with PowerHA enabled, and I'm wondering if my the cluster operations are fine to perform some OS-interventions, like full system-backups, IPL, OS upgrades
Cluster setup :
3 nodes in the same Device Domain
( -PS-partition
-PT-partition
-Flash Partition
CRGs
- Active - Dev CRG à pointing to IASP Device (with recovery domain set to PS & PT partition)
- Inactive - Data CRG à pointing to Flashcopy node (but inactive, à using the lab-services toolkit to perform the FC operation on IASP level - QZRDHASM)
- Active – Peer CRG à Application id : QZRDPWRHA.DLTPRFCLU
Now, what's the best approach to cover OS operations, like full backup, IPL, or OS upgrades ...
Which actions to deliver on Cluster/PowerHA level on the IBMi to prepare a partition for restricted state ...
Flash Partition:
Putting this Flash partition in restricted state to cover these OS related interventions ...
On Flash partition:
ENDCRG of the Peer CRG
ENDCLUNOD NODE(FlashCopy node)
And after the OS-intervention:
STRCLUNOD NODE(FlashCopy node)
STRCRG of the Peer CRG
PT Partition:
Putting this PT partition in restricted state to cover these OS related interventions ...
On PT partition:
ENDCRG of the Peer CRG
ENDCRG of the DEV CRP (IASP)
ENDCLUNOD NODE(PT node)
And after the OS-intervention:
STRCLUNOD NODE(PT node)
STRCRG of the DEV CRG (IASP)
STRCRG of the Peer CRG
Plus verify the replication is active and in-sync (DSPSVCSSN SSN(xxxx) DEVDMN(Dev-domain)
(no DETACH / REATTACH operation will be done !)
PS Partition:
Putting this PS partition in restricted state to cover these OS related interventions ... (after switching IASP to PT partition)
On PS partition:
Verify the replication is active and in-sync (DSPSVCSSN SSN(xxxx) DEVDMN(Dev-domain)
And 'Switchover Reverse replication' is set to *YES
CHGCRGPRI DEV-CRG (IASP)
- Production env gets opened on PT partition.
Further on on PS partition...
ENDCRG of the Peer CRG
ENDCRG of the DEV CRG (IASP)
ENDCLUNOD NODE(PS node)
And after the OS- intervention:
STRCLUNOD NODE(PS node)
STRCRG of the DEV CRG (IASP)
STRCRG of the Peer CRG
Plus verify the replication is active and in-sync (DSPSVCSSN SSN(xxxx) DEVDMN(Dev-domain)
(no DETACH / REATTACH operation will be done !)
CHGCRGPRI DEV-CRG (IASP) back to PS partition
- Production env gets opened on PS partition.
Is this approach fine ?
Should I include an end/start operation of the Admin Domain ?
All these commands can be executed on the related partition ?
Is my view on the cluster operations fine ... or are additional actions required.
Any recommendation is welcome.
Thanks for your feedback,
Jos
------------------------------
Jos (Jozef) Thijs
Kyndryl
------------------------------