How To
Summary
Sometimes, after switchmgr is done, either from MDM to BKM or back from BKM to MDM, you may find lots of FTAs unlinking from the current master. This because the original master has some linking problem to the current master, such as link down, OS crash/rebooting etc, so it still marks itself as the master manager but not FTA yet in its Symphony file, and so do FTAs' Symphony marked so. In this case FTAs will still try to link to the original master instead of the new master which have switched to.
Objective
Make sure switchmgr procedure is done by using the correct steps, which will preventing the linking issue afterwards.
If linking issue happened, make sure every workstation Symphony file marks the current master as master domain manager but not the original one.
This is also suitable for DM/BDM swicthmgr activities.
Steps
1. Make sure the target master receive the latest update.
Find out if there is a full status FTA or backup master in environment. This will be your "new" master.
- on old master:
cd TWSHOME
mv Sinfonia Sinfonia.old
cp Symphony Sinfonia
cp Symphony Sinfonia
- on new master:
cd TWSHOME
move Sinfonia Sinfonia.old
- on old master:
conman "link <new master cpu name>"
If this is unsuccessful, it means this old master is completely irresponsible, so go to the step 2, skip step 3 and continue with step 4 onward directly.
2. Run "switchmgr" on new master to make it current master.
conman "switchmgr masterdm;<new master cpu name>"
Check TWSHOME/stdlist/TWSMREGE_yyyymmdd.log should have following similar info recorded:
16:09:25 28.12.2012|MAILMAN:+ AWSBCV116I Switching managers in domain MASTERDM from workstation "MDM" to workstation "BKM".
3. Check on current master and old master Symphony workstation type:
- on new master:
conman "sc"
Output should be like following, new master (BKM) marks it is the master whilst the old master (MDM) marked as an FTA and fully linked:
CPUID RUN NODE LIMIT FENCE DATE TIME STATE METHOD DOMAIN
BKM 198 *UNIX MASTER 10 0 10/11/17 00:00 I J MDEA MASTERDM
MDM 198 UNIX FTA 10 0 10/11/17 00:00 LTI JW MD MASTERDM
- on old master:
conman "sc"
Output should be similar to above in the new master:
CPUID RUN NODE LIMIT FENCE DATE TIME STATE METHOD DOMAIN
BKM 198 UNIX MASTER 10 0 10/11/17 00:00 I J MDEA MASTERDM
MDM 198 *UNIX FTA 10 0 10/11/17 00:00 L I J MD MASTERDM
In this case the FTAs will be auto linked to the new master. And you can stop from here. If you have DA linking problem, go to the end of this doc.
But if you see old master still showing itself is the Master like below, and it is not linked to the BKM, then perform the next steps.
CPUID RUN NODE LIMIT FENCE DATE TIME STATE METHOD DOMAIN
MDM 198 *UNIX MASTER 10 0 10/11/17 00:00 I J MDEA MASTERDM
BKM 198 UNIX FTA 10 0 10/11/17 00:00 MASTERDM
MDM 198 *UNIX MASTER 10 0 10/11/17 00:00 I J MDEA MASTERDM
BKM 198 UNIX FTA 10 0 10/11/17 00:00 MASTERDM
4. Make the old master mark it is acting as an FTA now:
- on old master:
cd TWSHOME
conman "stop;wait"
conman "shut;wait"
ps -ef | grep <TWSUSER>
kill <PIDs of any remaining TWS processes>
rm Symphony Sinfonia Jobtable ---> use mv if you want to backup files
rm *.msg
rm pobox/*.msg
rm network/NetReq.msg
StartUp -> start ONLY netman
conman "stop;wait"
conman "shut;wait"
ps -ef | grep <TWSUSER>
kill <PIDs of any remaining TWS processes>
rm Symphony Sinfonia Jobtable ---> use mv if you want to backup files
rm *.msg
rm pobox/*.msg
rm network/NetReq.msg
StartUp -> start ONLY netman
- on newmaster:
conman "link <old master cpu name>"
conman "link <old master cpu name>"
The old master should now showing correctly as an FTA from both conman sc output on MDM and BKM, all other FTAs are linked up.
And you can stop from here. If you have DA linking problem, go to the end of this doc.
But if old master can not be linked to the new master, then it means the old master has problem, other FTAs still remembers the old master, then you need to go next step to update all FTAs Symphony.
5. Update FTAs to link to the new master.
5.1) If in the workstation definition from the database, your current master is the true master, then you can preform on current master:
set old master to ignore or set it to a single mailman server ID, ref to the doc "How to tune IWS to improve FTAs linking (adding mailman server)" in the Related URL section.
NOTE: NOT use this procedure on BKM when it is not defined as "manager" in the database. Because in some cases it will reload the history plan file. By the worst situation need to do ResetPlan -scratch to recover. Ref to the doc "How to recover from the situation that JnextPlan ran on backup master brought back years old plan file" in the Related URL section.
optman ls | grep cf --> record the value
optman chg cf = ALL
JnextPlan -for 0000
optman chg cf = <previous value>
FTAs should be all updated with the current master info and linked up.
5.2) If in the workstation definition from the database, your current master is the backup master or full status FTA, then you have to cleanup each FTA using the same procedure as step 4 to link up each FTA one by one.
If you have very slow linking up all FTAs for either step 5.1 or 5.2, then ref to the doc "How to tune IWS to improve FTAs linking (adding mailman server)" in the Related URL section.
During the process if you found DA unlinking problem, then ref to the doc "All Dynamic Agents unlink after OS rebooted (broker unlink)" in the Related URL section.
Related Information
Document Location
Worldwide
[{"Type":"MASTER","Line of Business":{"code":"LOB77","label":"Automation Platform"},"Business Unit":{"code":"BU048","label":"IBM Software"},"Product":{"code":"SS8GJD","label":"IBM Workload Automation"},"ARM Category":[{"code":"a8m0z0000000CYaAAM","label":"How To-\u003ESWITCHMGR"}],"ARM Case Number":"","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"10.1.0;10.2.0;9.5.0"}]
Was this topic helpful?
Document Information
Modified date:
19 June 2020
UID
ibm10876258