This section of the Readme contains late-breaking information related to the PowerPlay Transformer component.
Having a mixed install of Series 7 Version 3 (7.3) MR2 BI products and/or Cognos Planning or Cognos Finance 7.3 SP3 on the same computer as earlier releases of these 7.3 products may cause these earlier releases to fail. The problems occur due to backwards compatibility issues found in the following components: UDA, XALAN and Cognos Web Services (CWS) with Cognos Visualizer.
Note that you will not have these problems if the products on the same computer are all at 7.3 MR2 and SP3 level, or if you install 7.3 MR2/SP3 products on one computer and have other products running 7.3 pre-MR2 or pre-SP3 on a different computer. For example, having Upfront and PowerPlay 7.3 MR2 on MyServerA, drilling through or launching an IWR 7.3 MR1 report on MyServerB will not cause a problem.
If you cannot follow the corrective actions described below, then you must revert all products on the computer to their previous state by restoring them from the backup you made before installing the MR2 maintenance release or SP3 service pack.
The UDA problem may be experienced by the products in Table A, when only a subset of the installed products is upgraded to MR2 or SP3.
The symptoms experienced are varied - there is no common message that identifies the problem. Before working with Customer Support to isolate your specific problem you must eliminate this known UDA issue as being the root cause. Examples of symptoms that have been encountered with 7.3 pre-MR2 products include, but are not limited to:
The build numbers of the UDA component causing the problem are in the range 7.8.23148 to 7.8.24101. To check build numbers, review the contents of your cmplst.txt file located in the <install_location>\cognos\cer4 directory. UDA component build numbers can be found in the [Services] section of cmplst.txt. Note that this is only an issue if there are any products or components in the file that have a 7.3 pre-MR2 or pre-SP3 version.
To resolve this issue you must:
The XALAN problem will be experienced by the products in Table B1, when any of the products in Table B2 are upgraded to MR2 on the specified platforms.
The symptoms experienced depend on the upgrade scenario.
If PowerPlay Enterprise Server 7.3 is kept at the Initial or MR1 level, and any of the previously listed products in Table B2 is upgraded to MR2, then accessing a cube from Cognos PowerPlay Web Explorer using the Enhanced UI may either result in a blank screen or the following message:
Internal error - request failed.
Please contact your administrator
If Cognos Visualizer Server 7.3 is kept at the Initial or MR1 level, and any of the previously listed products in Table B2 is upgraded to MR2, then a Visualizer message is displayed:
Web Browser:
There was an error in the XSL Parse engine.
The return code was: -1
The data returned was:
The error occurred during loading the stylesheet (/viz/templates/en/ZFPIndexPage.xsl), please ensure the stylesheet is valid
Please contact your administrator
Table of Content:
There was an error in the XSL Parse engine.
The return code was: -1
The data returned was:
The error occurred during loading the stylesheet (TOC.xsl), please ensure the stylesheet is valid
Please contact your administrator
The build numbers of the XALAN component causing the problem are in the range 1.2.659 to 1.2.868. To check build numbers, review the contents of your cmplst.txt file located in the <install_location>\cognos\cer4 directory. XALAN component build numbers can be found in the [Third Party] section of cmplst.txt. Note that this is only an issue if the file also contains a pre-MR2 7.3 version of PowerPlay Enterprise Server or Cognos Visualizer Authoring or Server.
To resolve this issue you must request from Customer support a new post-MR2 hot site build for all the products in Table B2 that you want to upgrade to MR2.
The CWS problem will be experienced by the products in Table C1, when any of the products in Table C2 are upgraded to MR2 on the specified platforms.
Cognos Web Services, only when used with Cognos Visualizer Server |
The symptoms are experienced when Cognos Visualizer Server 7.3 is kept at the Initial or MR1 level, and any of the previously listed products in Table C2 is upgraded to MR2. The error messages displayed are dependent on the platform as follows:
On HP-UX the following message is displayed when you configure:
configcp ->/usr/lib/dld.sl: Unresolved symbol: XML_ParserCreateNS (code) from ./libvizxml.sl core file from 'vizwebcws' - received SIGABRT configcp ->/usr/lib/dld.sl: Unresolved symbol: XML_ParserCreateNS (code) from ./libvizxml.sl core file from 'vizwebcws' - received SIGABRT
On Solaris the following message is displayed when you run some CWS requests:
Application Error
The following error has occurred:
The request failed because the server timed out. No Query Processor was available to handle the request.
The build numbers of the Visualizer Server Dispatcher or Query and Report Processor components causing the problem is in the range 600 to 1005. To check build numbers, review the contents of your cmplst.txt file located in the <install_location>\cognos\cer4 directory. Visualizer Server component build numbers can be found in the [Main Applications] section of cmplst.txt.
To resolve this issue you must request from Customer support:
You will not experience this problem if you have a mixed install of RTM/MR1 and MR3 or MR2 and MR3.
If there is insufficient storage space for the ObjectStore, you will see the following error message when you try to start Architect or Transformer Versions 7.3, 7.1, or 7.0 on Windows XP:
ObjectStore internal error.
VirtualAlloc failed to allocate at any address - not enough storage is available to process this command (8)
The problem does not seem to arise with Impromptu Web Reports, although it also uses ObjectStore.
If you experience the problem, we recommend that you do the following:
After you update an individual or member cube with data from another period, the allocated measures may appear incorrect because Transformer allocates measures at the lower levels of a dimension and then rolls them up. By design, measures are not separately allocated at each level.
Transformer cannot import an IQD data source from Framework Manager if it contains TEXTBLOB, CLOB, or BLOB data types.
Before externalizing IQD columns or query subjects from Framework Manager, ensure that they do not contain these data types.
When you format a measure to use the #,###0 setting, you may encounter problems applying this format to the Y-axis of certain chart types.
To avoid this problem, set this format option on a category-by-category basis, rather than globally setting it for all occurrences of a measure.
If the data type for a measure results in an overflow of the available storage capacity, Transformer issues an error message similar to the following:
Integer overflows occurred with measure <name> for PowerCube <cube_name>. Measure <name> was defined as <data_type>; however, the input value resulted in the aggregate value exceeding that type, and the build is now stopped.
We recommend that you check the log file and take the required corrective action. For example, you may have to change the data type of the measure from 32-bit integer to double float, and rebuild the cube.
The explanation of the order of precedence for calculated measures is incorrect, as documented in the Series 7 Transformer and PowerPlay for Windows help.
For example, the Transformer help states that calculations defined for categories are performed before calculated measures, if calculated categories and calculated measures intersect. The reverse is true. That is, the "Define a Calculated Measure" help topic should read as follows:
"Where there is an intersection between calculated categories and calculated measures, calculations defined for measures are performed first. This is important to note within PowerPlay reports where the calculated measure and category intersect."
The glossary definition for "Calculation Precedence" shared by the Transformer and PowerPlay for Windows help is also incorrect. In the list that shows the order by which PowerPlay for Windows evaluates intersecting calculations, calculated measure (after rollup calculation) should appear before calculated category.
The relevant documentation will be corrected in a future release.
The explanation of the Restrict Drill-through Targets by Level feature in the Step-by-Step Transformer documentation is incorrect.
The new Exclude option does NOT restrict drill-through to levels at or below the specified filter level: it disables drill-through at the specified level only.
PowerPlay users who click on the drill-through icon while positioned in an excluded level see the following message: "There are no drill through targets available. Verify your selection or confirm that drill through is available at this level."
The error did not arise in the MDL Reference or macro documentation.
In some cases, you may get a "No Help topic" message when you try to access the context-sensitive help, or you may be brought to the initial page of the task help when you click a Related Topics link in a What's This? Help topic. The following are examples, with some suggested workarounds:
Select SUM(value) instead of Select value. This can improve Transformer's query processing speed for Architect-related models.
In the existing documentation, the descriptions for two command-line options available for use with the Windows and UNIX versions of Transformer is incomplete.
The documentation for the -s option in the Transformer for UNIX Guide fails to mention that the model name is a mandatory argument. Like the -i option, the syntax should be described as follows: -s py_model_file.
The documentation for the -k option currently states that it cannot be used with IQD datasources. Actually, Transformer allows this argument for IQD-based models in conjunction with the -a option, but in such cases, a logon screen appears. In other words, you cannot use it in batch mode because user intervention is required to supply the mandatory logon information.
When you add drill-through, you will see a new file type in the Files of type drop-down box. The file type is called ReportNet Report Viewer file (.crr). There is no physical file which matches this file type, rather it is used as a convenience when defining drill-through to Cognos ReportNet. The name of the .crr file is the name of the target Cognos ReportNet report, and the two names must match exactly, as there can be many drill targets.
Note: The ReportNet Report Viewer file "type" drills-through to Cognos Report Studio.
Report authors should be aware that category names that exceed 30 single-byte characters in length may overlap, be truncated, or become illegible in some situations, for example, Pie chart labels. This is because category layouts on PowerPlay client interfaces are handled on a best-effort (not a size-to-fit) basis. We recommend that you shorten the category names used in your PowerPlay reports, or use short names.
When you build cubes in Transformer, if you suppress specific days from the date dimension and those days contain measure values, the days will not remain suppressed when you open the cube in PowerPlay. Further, when you review the categories in the Transformer diagram after viewing the cube in PowerPlay, the days no longer appear suppressed in the diagram.
There is no workaround for this problem.
If your data source is an Oracle database, when you create category labels in Transformer based on a numeric field, the numeric values will be scaled by two. For example, if your data source values are 100, 100.23, and .14, when this column is used in the dimension as the label and categories are generated, the category labels appear as 10000, 10023 and 14.
This is because Transformer creates category labels based on the database schema definition, and the data source input scale cannot be overwritten by modifying the columns. As a result, all measures defined in the cube will reflect the data source column input scale.