time(seconds) unlimited
file(blocks) unlimited
data(kbytes) unlimited
stack(kbytes) 8192
coredump(blocks) unlimited
nofiles(descriptors) 256
memory(kbytes) unlimited

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:

1. Create a script that calls ulimit -n xxxxx command before it calls the cogconfig.sh file for Cognos startup; or
2. 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).

After importing and/or exporting a Cognos Adaptive Analytics Framework (AAF) package, the following problems are encountered:

• Reports return calendar data errors
• Validating Cognos AAF package returns “The information in IBM Cognos Framework Manager package was not completely loaded.  XML failed to parse.  Invalid document structure.”

Solution:

Stop and restart your Cognos services.  Then revalidate your AAF package.

photo credit: HikingArtist.com

Have you ever wondered why the only way you can read SAP data is through SAP connection plug-ins for your ETL tool-of-choice?  Why can you not simply read SAP tables as is from the source database?  Why is everything data transfer-wise just a little bit harder with SAP?

Well, for years I just assumed that SAP (being a proprietary system) liked a tight grip on its data systems.  But as I was looking into a situation for a client, I learned the truth was a bit more complicated.

It all started when I wanted to join the transaction header table (BKPF) with the transaction detail table (BSEG).  Couldn’t this be done at the SAP source, instead of in the data warehouse staging area?  If this was a straight-up relational database, joining these tables would be a no-brainer.

Now anyone familiar with SAP knows about the cryptic table names and columns, and probably has at least a passing awareness of the ABAP/BAPI/IDOC programming languages that read SAP data.  So this alphabet soup is where we start.  But the cryptic names aren’t the half of it.

The first thing you need to understand is that SAP is not what you would consider to be a garden-variety relational database.  SAP actually maintains three different types of tables, 2 of which are unreadable outside of SAP’s programming environment.  One of these table types is called a cluster table.  It is a control table of sorts that reads from many different physical tables.  BSEG is just such a table, and is therefore not readable by straight SQL commands.  The second table type is called a pooled table, which is used to store program parameters.  The third and final table type is called transparent, and this is what most SQL programmers would call “normal”.  It is physically and logically the same table, and can therefore theoretically be read by standard SQL commands (although virtually all SAP interfacing is done through SAP programming in any case).

Knowing this helps SAP’s world make a little more sense.

CCLAssertError:0:Fatal: CCL_ASSERT_NAMED(bFoundFont, “[RSPdfOutputText::onDISetText] No font available for the text data”);

Cognos report PDF generation requires that you have:

1. fonts installed on your Cognos server, and
2. the Cognos configuration setting for fonts defined properly so those fonts can be found.

To resolve this, you need to go into Cognos Configuration and modify the settings for the Environment > Font Settings > Physical Font Location.  The fonts included with your Cognos 10 installation should be found in your C10/bin/fonts directory.  To see these fonts, make sure your font setting includes “../bin/fonts”.

What you need to understand is that when you select “Include Cognos groups and roles”, you are selecting ALL Cognos groups and roles – not just the ones associated with the package or packages you selected one screen before.  And when you select “Include data sources and connections”, you are likewise selecting ALL data sources and connections.  And if you leave the default selection in place that reads “Replace existing entries” you will overwrite all of your definitions on your destination Cognos server.

Now, depending on what you want to do, this might be OK.  But on a standard single package migration, you will almost never want to deploy these options.

This might also be a good time to suggest backing up your destination server before you deploy exported content.  Better to be safe than sorry!

photo credit: Ken and Nyetta

A recent client of mine was in the habit of naming Cognos data source connections after the environment they were connecting to, as was the custom of the underlying Oracle TNS names.  So a connection to a DEV, TEST or QA source would have some notation of this in its name, such as MyConnection_DEV.  This worked fine until it came time to migrate the project from one environment to another, and then this data source connection configuration turned into a real headache.

Because each environment had its own unique data source connection name, it was impossible to simply export Cognos packages from one level and import into another.  Modifying FM data models and republishing them was necessary, which was a lot more work than it should have been.  One developer even complained that he felt like he had to start each project over every time he migrated it.  I think that is a good way to look at a Cognos data source connection – a starting point.  Modifying this starting point (by which I mean its name, not its attributes) means you are in a sense starting over.  A better approach is to maintain a standard name across your DEV/QA/PROD environments so that you do not have so much extra work every time you migrate.  With this name constant, you can set your attributes in each environment freely to connect to whichever database you desire.  This prevents having to republish packages or remap data connections at every turn.

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.

Original XML:

<crn:parameter name=”disp_sharedsecret”>
<crn:value xsi:type=”cfg:systemPassword” encrypted=”true”>HJdtycSUJ&*JFfda</crn:value>
</crn:parameter>

Changed XML:

<crn:parameter name=”disp_sharedsecret”>
<crn:value xsi:type=”cfg:systemPassword” encrypted=”false”>PasswordValue</crn:value>
</crn:parameter>

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.

./cogconfig.sh
Using /usr/jdk/jdk1.6.0_22/jre/bin/java
02/12/2011,12:18:53,Err,java.lang.ExceptionInInitializerError, com.cognos.crconfig.CRConfigFrame.<init>(CRConfigFrame.java:109)
Exception in thread “main” java.lang.NoClassDefFoundError: Could not initialize class com.cognos.crconfig.CRConfigFrame
at CRConfig.main(CRConfig.java:305)

To resolve:

• 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.

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.

QE-DEF-0285 The logon failed.
QE-DEF-0325 The logon failed for the following reason:
RQP-DEF-0068 Unable to connect to at least one database during a multi-database attach to 1 database(s) in:
DataSource
UDA-SQL-0432 Unable to locate the gateway “cogudaor”

If you have a valid Oracle client installed on your machine (Oracle 9 or up for Cognos 8/10), then check your System Environment variables.  I had a recent experience at a client where both Oracle 8 and Oracle 10 client software were installed on a machine.  Because the ora805\bin reference appeared before the ora10\bin reference in the Path variable, Cognos Framework Manager could not connect to the data source and reported the above error.  Simply by changing the order of those references in the Path variable, the configuration problem was resolved.