Page tree

Versions Compared


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


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:

If you require exact storage and calculations (such as for monetary amounts), use the numeric type instead.

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.

On most platforms, the real type has a range of at least 1E-37 to 1E+37 with a precision of at least 6 decimal digits. The double precision type typically has a range of around 1E-307 to 1E+308 with a precision of at least 15 digits. Values that are too large or too small will cause an error. Rounding might take place if the precision of an input number is too high. Numbers too close to zero that are not representable as distinct from zero will cause an underflow error.

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 Added

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:

  • If the previous AETP or AEP values have been used in a customer contract which does not explicitly forbid the generation of altered values for existing snapshots (i.e. the data is not required to remain the same), then you can use the Recompute Checksum and Snapshot Statuses option.
  • If the previous AETP or AEP values have been used in a customer contract which forbids the generation of altered values for existing snapshots (i.e. the data must always remain the same), then you should NOT use the Recompute Checksum and Snapshot Statuses option.