CAST AIP 8.3.x Documentation
Page tree
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Next »

On this page:

Target audience:

CAST AI Administrator

Summary: this page lists:

  • Impacts of changes made to CAST AIP 8.3.4 on Quality Model results post upgrade

  • Other impacts of changes made in CAST AIP 8.3.4

All changes in results related to extensions are now listed in the extension documentation and will not appear in this page.

Impacts of changes made in CAST AIP 8.3.4 on Quality Model results post upgrade

JEE

SCRAIP-32219 - Do not use auto wiring - 7714

A bug has been discovered which is causing the Quality Rule "Do not use auto wiring - 7714" to report more failed checks than total checks. This bug has now been fixed and after an upgrade to CAST AIP 8.3.4, results may differ for this Quality Rule - there will be a reduction in the number of failed checks.

Mainframe Cobol

SCRAIP-31919 - Number of lines of code

A bug has been discovered which is causing the measure "Number of lines of code" to report a negative value. This bug has now been fixed and after an upgrade to CAST AIP 8.3.4, results may differ for this measure - the results will be accurate.

SCRAIP-31510 - Variables defined in Working-Storage section must be initialized before to be read - 8034

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.

Other impacts of changes made in CAST AIP 8.3.4

Mainframe Cobol

SCRAIP-31358 - Unknown Object created when there is no caller for it

A bug has been discovered which causes an "Unknown" Cobol object to be created when an analysis does not, in fact, contain any caller to this object. This bug has now been fixed and therefore after an upgrade to CAST AIP 8.3.4, results may differ.

SCRAIP-31917 - Mainframe Analyzer creates wrong links to Nested Program belonging to other programs

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:

 PostgreSQL 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 : 

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 already been shared and the generation of altered values for existing snapshots is permitted (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 already been shared and the generation of altered values for existing snapshots is forbidden (i.e. the data must always remain the same), then you should NOT use the Recompute Checksum and Snapshot Statuses option.
  • No labels