Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Redirect
visiblefalse
locationAIPCORE:Changes in results post upgrade - 8.3.4

Panel

On this page:

Table of Contents

Target audience:

CAST AI Administrator

...

A bug has been discovered which is causing the false violations to be reported for the Quality Rule "Variables defined in Working-Storage section must be initialized before to be read - 8034" when the analyzer is not able to handle the reference identifier length. This bug has now been fixed and after an upgrade to CAST AIP 8.3.4, results may differ for this Quality Rule - no false violations for this case.

SAP / ABAP

Avoid using BREAK or BREAK-POINT statement - 7524

Violations are being reported for the "BREAK-POINT ID" syntax. "BREAK-POINT" clauses with an ID are recommended by best practices and therefore should not raise a violation of the Quality Rule. This has now been corrected and after an upgrade to CAST AIP 8.3.4 and the generation of a post upgrade snapshot, results may differ: when the syntax "BREAK-POINT ID" is used, violations will not be reported. As such, a reduction in the number of violations may be visible.

Other impacts of changes made in CAST AIP 8.3.4

...

A bug has been discovered which causes false links to be created between nested Cobol programs defined in another program and sections/paragraphs. This creates too many links so the graphical representation, Function Point data and Quality Rules are impacted. This bug has now been fixed and after an upgrade to CAST AIP 8.3.4, results may differ and are now more accurate.

SCRAIP-32261 - CAST Transaction Configuration Center - AETP and CF bug fixes

CAST has fixed two bugs that were causing the calculation of AETP (Automated Enhancement Technical Points) and CF (Complexity Factors) to be incorrect:

AETP (Automated Enhancement Technical Points)

AETP is computed by CAST AIP as AETP = (ER x IP AETP ) where ER = Equivalence Ratio and IP = Implementation Point.

IP AETP is the total EC of Technical Artifacts. In previous releases of CAST AIP, the EC of Technical Artifacts was calculated by subtracting the EC value of Functional Artifacts from the Total EC value for the entire application. However, this was not precise enough because of the shared objects in the functional part: when an artifact is shared between transactions its EC is counted multiple times. 

The fix introduced in CAST AIP 8.3.4 will now ensure that the exact sum of EC of Technical Artifacts is calculated. As a result of this this bug fix, when the AETP value changes then the AEP value will also change because AEP = AEFP + AETP. Therefore after an upgrade to CAST AIP 8.3.4 and the generation of a post upgrade snapshot, you may see differences with regard to AEP and AETP values compared with those in previous snapshots.

CF (Complexity Factor)

CAST has fixed a bug that was causing CF (Complexity Factor) values to be incorrectly calculated when using CAST AIP in a CAST Storage Service (PostgreSQL) environment. Some internal CAST AIP algorithms used in the CF calculation process were using Floating-Point Types which returned rounded values on CAST Storage Service. This is explained in the following extract from the PostgreSQL documentation:

...

titlePostgreSQL documentation on Floating-Point Types

8.1.3. Floating-Point Types
The data types real and double precision are inexact, variable-precision numeric types. In practice, these types are usually implementations of IEEE Standard 754 for Binary Floating-Point Arithmetic (single and double precision, respectively), to the extent that the underlying processor, operating system, and compiler support it.

Inexact means that some values cannot be converted exactly to the internal format and are stored as approximations, so that storing and retrieving a value might show slight discrepancies. Managing these errors and how they propagate through calculations is the subject of an entire branch of mathematics and computer science and will not be discussed here, except for the following points:

...

and

...

If you want to do complicated calculations with these types for anything important, especially if you rely on certain behavior in boundary cases (infinity, underflow), you should evaluate the implementation carefully.

Comparing two floating-point values for equality might not always work as expected.

...

are

...

These algorithms now use Numeric Types instead, providing more accurate results for CF values, since the evolved effort complexity should be compared to Effort Complexity Evolution as described below : 

Image Removed

Therefore after an upgrade to CAST AIP 8.3.4 and the generation of a post upgrade snapshot, there are two consequences of this bug fix:

  • CF values may change when comparing values in previous snapshots.
  • When the incorrectly computed CF values are corrected by this fix, AEFP values will also change for the MODIFIED transactions. 

User action for previous snapshots

The bug fixes explained above will only impact results in new snapshots, however, using the Recompute Checksum and Snapshot Statuses option in the CAST Transaction Configuration Center (Enhancement > Data Functions and Enhancement > Transactional Functions nodes) will recalculate AETP and CF values (using the new methods introduced in the bug fix) in previous snapshots as well.

CAST therefore recommends that you use the Recompute Checksum and Snapshot Statuses option with caution:

...

.