This "Nuggets" is focused on a recent issue with had with a customer that could not get tcamd login to work, thus they could not run any further tacmd commands.
Below I have listed what the symptoms were and how you can correct this problems should you see it too.
Step 1 - Check the logs!
With any tacmd issue, the first step is always check the logs!
To set the tacmd traces:
For Windows systems,
Manually edit the KUIENV file in the CANDLEHOME directory with the standard KBB_RAS1 statement to include the following:
KBB_RAS1=ERROR (UNIT:kui all)
On UNIX systems,
Manually edit the $CANDLEHOME/bin/tacmd shell script to add a line like the following example:
KBB_RAS1=ERROR (UNIT:kui all)
If you then try to log in again and check the logs, it will give you a good indication of what is going wrong.
The log is located here: $CANDLEHOME/logs/kuiras1.log
90% of tacmd login failures are caused by the user inputting the wrong password. This quick check will save you time opening a PMR, as this log is very clear and easy to see error messages
Please note: Check the logs as soon as you have attempted to log in. Running additional tacmd commands may overwrite the KUIRAS1.log
Step 2 - Still having issues?.......
If you are still having problems logging in and you happen to be running AIX on your HUB TEMS..... You may well be hitting the issue I have described below:
To diagnose the problem set 'set -x' on top of the tacmd script file before executing the login command.
The below result shows that the tacmd command is unable to get the working JavaHome due to lack of permission
+ export CANDLEHOME
+ + /opt/IBM/ITM/bin/CandleGetJavaHome
+ [ ! -d /opt/IBM/ITM/registry ]
+ . /opt/IBM/ITM/bin/dynarch.shl /opt/IBM/ITM/registry/archdsc.tbl
+ 2> /dev/null
Step 3 - How to fix the issue
The reason for the failure is due to a lack of permissions for the file $candlehome/config/env.config.
This control file contains (among other things), the Java home directory. The underpinnings of CandleGetJavaHome read/update this file, as part of normal operations. Consequently, when you use "secureMain -g <group> lock", all userids requiring access to ITM functions need to be in <group>.
It looks like in this case, someone had changed the permission of the $candlehome/config/env.config file after executing the "secureMain -g <group> lock"
After changing the permission of the $candlehome/config/env.config the problem is resolved.
The difference is explained by permission for the file $candlehome/config/env.config.
xxxx470: (not working user)
-rw-rw---- 1 root tivadmin 1174 Feb 28 19:59 env.config
xxxx471: (working user)
-rwxrwxrwx 1 root tivadmin 1174 Feb 28 18:55 env.config
This is a tricky one to find, so hopefully this will help you out should you find yourself locked out of tacmd
Step 4 - Still not working.......Time to talk to support
If you still cant login after the above texts and corrections, then you need to raise a PMR with support.
Please attach the Kuiras1.log (or a full PDcollect Ideally) and support and help pin your particular cause down
To follow my social updates on IBM software, please feel free to connect with me by clicking on the images below:
Find all my other blogs here:
LINK ------------> Full Index of My Blogs <------------ LINK
Subscribe and follow us for all the latest information directly on your social feeds: