Archive for category Unix
I recently ran into a puzzling problem with a Cognos Unix installation. Even though the Cognos portal was running and fully functional, Cognos Configuration reported that the service was not running. As such, it could not be stopped through Cognos Configuration. Likewise, the command line cogconfig.sh -stop also had no effect. It was a runaway process with no control available through normal Cognos channels. If we shut down the Cognos process manually, then Cognos Configuration would not start up properly. At the very end of the process, it would report a failure – even though the Cognos portal was up and fully functional again.
After digging through the logs, I discovered that the key to this problem was the Cognos Bootstrap Service (CBS). The Cognos Bootstrap Service makes sure that the main Java process is running by monitoring the shutdown port.
The log file cbs_run.log reported:
CBSBootstrapService Process ID could not be written to file. The cogbootstrapservice -stop command will not work. Use ‘kill -9′ instead.
The log file cbs_isrunning.log reported:
CBSBootstrapService Process is not running.
So if the Cognos Bootstrap Service doesn’t run at all, then Cognos Configuration will not know if Cognos is running or not.
The file that was preventing our Cognos Bootstrap Service from starting was cogbootstrap_service.pid which resides in the c10\logs directory. Our Unix account did not have rights to write to this file, which was the cause of the problem.
Once the Cognos Bootstrap Service was able to run again, our Cognos startup/shutdown issue was resolved.
If you are experiencing slowdowns and delays on Cognos reports on your Unix-based system, the first good place to look is at your ulimit parameters. To see your ulimit values, enter “ulimit -a” on your Unix system.
Pay particular attention to your maximum file descriptor, listed above as nofiles(descriptors). The default value of this item can be quite low, as you can see in this example. Setting it higher can make significant improvement on your Cognos system. You can set this value with the Unix command ulimit -n xxxxx (where xxxxx is your desired maximum file descriptor value).
You will find that these ulimit settings are a function of your Unix session, and will revert to default values after you log out. If you want to make permanent changes to your Cognos ulimit settings you will need to either:
- Create a script that calls ulimit -n xxxxx command before it calls the cogconfig.sh file for Cognos startup; or
- Add the ulimit -n xxxxx command to your .profile for the Unix account account in question (open with vi .profile)
For more information on ulimit settings for Cognos, see this IBM article here (this IBM article is specific to AIX and Linux systems).
If you have a simple Cognos Configuration change to make or if X Window GUIs are not an option, there is another way to make cogfiguration changes. Instead of running Cognos Configuration through the GUI interface you can edit the cogstartup.xml file directly to change your Cognos Configuration settings.
There are some things you need to do before you edit your cogstartup.xml file. The first is to stop the Cognos service. This can be done with the Unix shell command “./cogconfig.sh -stop” This shell script is found in your c10/bin directory.
Next, back up your cogstartup.xml file. If you corrupt the cogstartup.xml file, Cognos services may not restart. You need the backup in case you need to roll back your Cognos Configuration changes.
When you open your cogstartup.xml file, you will notice that some of the information in this file such as user names and passwords are encrypted. You will not be able to retrieve the previous settings of these parameters using this method but you can successfully change them. For best results, open and edit the file in a Unix editor – do not edit in Windows and import back to Unix. The file needs to be encoded in UTF-8.
To change unencrypted parameters, simply modify their values in the xml file.
To change encrypted parameters, remove the encrypted string and type the new value in plain text. Then change the encrypted value to false.
<crn:value xsi:type=”cfg:systemPassword” encrypted=”true”>HJdtycSUJ&*JFfda</crn:value>
<crn:value xsi:type=”cfg:systemPassword” encrypted=”false”>PasswordValue</crn:value>
When you restart your Cognos Service, the value will be encrypted and the encrypted flag will be set to true.
To restart your Cognos Service, run the Unix shell command “./cogconfig.sh -s” If you experience problems with the restart of your service, revert to your cogstartup.xml file backup and try again. For more information on this topic, see the IBM article on it here.
If you get the following errors running the cogconfig.sh shell script in Unix to start Cognos Configuration, you likely have a problem with your X Window configuration:
Exception in thread “main” java.lang.NoClassDefFoundError: Could not initialize class com.cognos.crconfig.CRConfigFrame
- Ensure you have X Window capable software installed on the machine in question, such as Exceed.
- Ensure that your Unix interface client has X11 forwarding enabled. In PuTTY, this is listed under Connections > SSH > X11.
Transitioning a cube from a Windows environment to a Unix environment can be tricky. Your cube may build perfectly in a local-build on Windows, only to give you errors like this in a server-build on Unix:
Start processing data source ‘My Data Source’.
Reading source data.
(TR3703) The user ID or password is either missing or invalid. Please re-enter the credentials.
End processing 0 records from data source ‘My Data Source’.
While it appears as though you have a problem with a data source in Unix, the real problem lies with your signon credentials. Once you transition from a local-build to a server-build in Transformer, you need to have a valid Signon defined. But when you do this, there is no way to test to see if your Signon Credentials will work – short of moving your Transformer model to the Unix server and building it. If your signon credentials are invalid, you will get a message like the one above.
So check the Signon Credentials and that should solve your problem. The apparent reference to your data source is a red herring.