Delivery folder consistency check has been implemented
During an upgrade to CAST AIP ≥ 8.3.21, a consistency check has been implemented to ensure that the index.xml file located in the folder Delivery\plugins and the plugins (i.e. sub-folders) present in the Delivery\plugins folder are consistent. This check has been added to avoid situations where, for example, the version of a plugin (e.g. discoverer or an extractor) located in the Delivery\plugins folder and the reference to that plugin version in the index.xml file, differ.
If any inconsistencies are detected during the upgrade, these will be logged in a new log file called ServMan-Utils produced by CAST Server Manager, located here (if the default settings are used):
Click to enlarge
Where possible, inconsistencies are repaired. When this is not possible, the upgrade stops with and an error is logged in the main CAST Server Manager log file, located in the same folder as above, for example:
IBM MQSeries updates
Syntax coverage has been improved when using data from JCL. The following is now supported:
- FROM instream data SYSIN when using DB2 utility to call PGM - ACCEPT
- FROM PARAM when Exec Program
The following syntax is now supported:
- ACCEPT verb for processing data passed as input to Cobol programs via SYSIN
- Data passed as input to Cobol programs via PARM
Configuration change to increase analysis performance
A change has been to the SAP/ABAP Analyzer in order to improve analysis performance (execution time) particularly for very large analyses. For those upgrading to 8.3.21 and for new "out of the box" installations, in the following file:
the following line:
has been replaced with:
CAST Delivery Manager Tool
Exclusion rule changes
A change has been made in the CAST Delivery Manager Tool to the exclusion rule Exclude Eclipse project located inside the output folder of another Eclipse project. In previous releases this exclusion rule in fact addressed two different things:
- projects located inside the output folder of another Eclipse project
- projects that share the name of another Eclipse project
To provide more flexibility, this rule has now been split in to two separate rules to address both exclusion scenarios handled by the original rule, as follows:
|Rule name||Notes||Position of option "out of the box" in 8.3.21||Position of option after upgrade to ≥ 8.3.21 position|
|Exclude Eclipse project located inside the output folder of another Eclipse project||Same name as in previous releases but this rule no longer excludes projects that share the name of another Eclipse project.||Enabled||Same position as prior to the upgrade.|
|Exclude Eclipse project sharing the name of another Eclipse project|
New rule to address this specific scenario.
|Enabled||Same position as original rule prior to the upgrade to ensure consistency of results.|
CAST Transaction Configuration Center
Saving empty transaction objects - new feature
Transactions are more and more frequently used for purposes other than AFP/AEP counting. However, the concept of "Transaction" was until now strongly Function Points-oriented, meaning Transactions which did not access any Data Entity or End Point did not always have their objects saved. This new feature aims to change the way such Transactions are collected and managed.
All Transactions are still identified by their Entry Points, but objects that are part of Transactions which do not access any Data Entity or End Point can now be saved, whichever enhancement measure is selected for their application: EFP (Enhancement Function Points) or AEP (Automated Enhancement Points) - see TCC - Enhancement node - Right hand panel.
In terms of AFP, saying that a Transaction is not valid can still be done by using the existing Delete or Ignore action. If a Transaction does not make sense, then the corresponding Entry Point must be removed.
Transactions considered as valid for AFP counting but neither accessing any Data Entity nor End Point will still have both their FTR and DET properties set to 0.
Having this type of empty Transactions in AFP/AEP counting is controlled by the new Function Point computation setting called Save objects of empty Transactions. The value of this setting will by default be set to "ALWAYS" for a new application, whichever enhancement measure is enabled (EFP or AEP), meaning that objects of its empty Transactions will always be saved.
To prevent variations in computation duration and volume of saved data for an application whose AIP version has just been upgraded to ≥ 8.3.21, the value of this setting will be set to "ONLY AEP" by the upgrade process. This setting value means that objects of empty Transactions will always be saved if the application enhancement measure is AEP, and never be saved if it is EFP, which is the behavior up to and including 8.3.20.
Before computing a new Snapshot or launching a Function Points computation, the Save objects of empty Transactions setting value can be changed in the following dialog boxes of the CAST Transaction Configuration Center:
To prevent variations in computation duration and volume of saved data for an application whose AIP version has just been upgraded to ≥ 8.3.21 - the version where objects of empty Transactions can be saved - the upgrade process will set the value of the Save objects of empty Transactions setting to "ONLY AEP". However, since for new applications the default value of this setting is "ALWAYS", then the value of this setting in the Global Computation Settings dialog will be set to "ALWAYS" too. Consequently, where the upgraded application uses Global Computation Settings (instead of Application Computation Settings) it is necessary to override these global settings, which is indicated by a "*" in front of the setting along with a change in the label of the "[x] Use Global Computation Settings" check-box:
Call graph of empty Transactions
If objects of empty Transaction are saved and there are any, their call graph and their full call graph can be viewed in the same way as for those of non-empty Transactional Functions. Below is an example of what such a call graph looks like:
Function Points computation report
The Function Points computation report (generated during the Compute action) has been refined to provide information regarding:
- the per-application setting about whether objects of empty Transactions will be saved, or won't
- how many empty Transactions have been found
- among the above empty Transactions, how many will have their Function Point value estimated (depending upon the Default FP value for empty Transactional Functions setting)
Below is an example of the Function Points computation report in previous releases, taking the example of FPs computed for 3 applications in a single shot (2 applications are using AEP, 1 application is using EFP):
Below is an example of the Function Points computation report in ≥ 8.3.21, taking the same applications as above:
- the 2 applications whose Enhancement measure is set to AEP will have the objects of their empty Transactions saved,
- the objects of empty Transactions not being saved for the single application whose Enhancement measure is set to EFP (as would be the case after an upgrade to ≥ 8.3.21),
- a default FP value for empty Transactional Functions having also been set for one of the applications:
Summary of Function Points computation report changes
- Number of applications with full call graph
- Number of applications with reduced call graph
-> in addition of the formerly reported application# (because their name is generally unavailable from the context where Transaction graphs are computed), indication of whether objects of empty Transactions will be saved: "empty TRs saved", or not: "empty TRs not saved"
- Number of Data Entities + End Points
-> renamed from "Number of DF records / TR end points" to avoid acronyms
- Number of non-empty + empty Transactions : N ( = non-empty: n1 + empty: n2 )
-> replaces values formerly displayed in "Number of transactions" and in "Number of empty / estimated transactions" (or one of its 2 other possibilities "Number of empty transactions" and "Number of estimated transactions" reported depending upon the "Default FP value for empty Transactional Functions" computation setting was, respectively, "0" for all applications or different from "0" for all applications whose Function Points were computed). As of now, only the counts of empty and non-empty Transactions are reported (N is always equal to n1 + n2), another line in the report being in charge of displaying, among all empty Transactions, the count of only those which are estimated
- Number of links -> Data Entities + End Points : N ( = DE+EP: n1 + intermediate objects: n2 )
-> replaces the formerly displayed "Number of links -> DF records / TR end points", with values now indicating the counts of each of the sorts of objects composing Transactional Functions AFP graphs (N is always equal to n1 + n2):
- the number of data entities (aka data function records), included in the count for n1
- the number of transaction end points, also included in the count for n1
- the number of objects on paths between transaction entry points (included in the count for n2) and the deepest data entities or end points (excluded from the count for n2) existing on these paths
- Number of links -> other objects in full graphs : N ( includes K links in empty Transactions )
-> since objects of empty Transactions can now be saved on option, the mention "( includes K links in empty Transactions )" makes explicit that such K objects are part of the reported count N
- Number of objects in the largest non-empty Transaction
- Number of objects in the largest empty Transaction
-> these two lines replace the formerly displayed "Number of objects in largest transaction", ambiguous because it wasn't explicitly stating that empty Transactions were not taken into account in the computing of the reported maximum value even though empty Transactions could exist and have their objects be saved for applications whose Enhancement measure was "AEP"
- Saved reduced call graphs of transactions in application #ID ( N details )
- Saved full call graphs of transactions in application #ID ( N details )
-> these messages indicate that objects belonging to the Transactions of the application whose ID is reported have been saved. The overall number of objects that have been saved is given by N, which includes objects belonging to empty Transactions if their objects have to be saved as well. Messages will start with "Saved reduced call graphs of ..." for applications whose Enhancement measure is EFP or if Function Points are computed using the CAST Transaction Configuration Center, whereas messages will start with "Saved full call graphs of ..." for applications whose Enhancement measure is AEP and Function Points are computed during a Snapshot.
- Number of empty Transactions with estimated FP value
-> reports the number of empty Transactions whose FP value will be estimated. Estimation will happen if the "Default FP value for empty Transactional Functions" computation setting has been changed from its default value "0" to another value
- Number of elements allowed in SCC groups
- Number of elements in largest used SCC group
- Number of ignored SCC groups (too large)
-> these lines used to be displayed only if at least one SCC group (Strongly Connected Component grouping many objects all having strongly interconnected dependencies) was containing more than 1000 objects - or the number of objects defined in the SYS_SITE_OPTIONS table by the GRAPH_MAX_SCC_ELEMENTS option - for warning about the existence of some parts of the Transactions graphs having been wiped out from the calculations because of too large SCCs (aka "LSCC" or "big potatoes"). As of now, the default or the overridden maximum number of objects allowed in SCC groups is always reported (this value possibly being "unlimited" if the GRAPH_MAX_SCC_ELEMENTS option has been configured suitably). Still, the value reported as the "Number of ignored SCC groups (too large)" is the indicator of whether none or some too large SCC groups have been excluded from the computation of the Transactions graphs, and therefore as well from the objects that will be accounted as being part of the affected Transactions.
Assessing Function Points for empty Transactional Functions based on non-empty Transactional Functions
It is now possible to configure the CAST Transaction Configuration Center to assess Function Points for all Transactional Functions for which the call graph does not reach a data entity nor an end-point based on existing Function Points that have been computed.
CAST Transaction Configuration Center determines the average number of nodes in the call graph of non-empty Transactional Functions corresponding to one DET. This ratio allows CAST Transaction Configuration Center to assign the number of DET to empty Transactional Functions, depending on the number of nodes in their associated call graph. The Function Point value will be then assessed based on that number of DET and with an FTR=1.
A new value (ASSESS) is available to assess the Function Point value in the Compute settings:
It is not possible to set ASSESS when Save objects of empty Transactions is set to NEVER:
When computing Function Points with the parameter set to ASSESS empty transactional functions will no longer exist. Their number and Function Point counts are displayed in the AFP Calibration page (see the lines in blue):
The average number of objects per DET ratio is computed on the number of object details in the non-empty transactional functions call graph and the corresponding DET. This ratio is then applied to empty transactional functions to determine their DET. A tooltip is available on blue lines:
The Transactional functions panel will distinguish transactional functions with an "assessed" Function Point from the others by the icon displayed in the Default FP column:
The origin of the Function Point value is sent to AFP metrics as:
The Impact of using ASSESS, is in the enhancement measure. All transactional functions which were empty in a previous snapshot after setting ASSESS will no longer be empty in the next snapshot, so they will be seen as new Transactional functions in the Enhancement panel with a status ADDED. This will increase the AFP value and consequently increase the AEP/EFP values.
If the enhancement measure for the application is set to the legacy EFP and the empty transactional function's detail is saved only for AEP then no assessment will be done, even though the ASSESS is set in computing settings.
View the list of objects of a transaction
It is now possible to see the list of objects called by a transaction in AFP Calibration > Transactional functions using the right click View objects option. This also allows you to understand the Function Point value for assessed transactional functions:
Click to enlarge
This will open a dialog box with the list of objects called by the associated transaction. This list contains all objects called by the transaction with the name, fullname, object type, and the role in the transaction graph:
Click to enlarge
View the list of Data Functions of an assessed transactional function
An assessed transactional function is originally an empty transactional function, which has no data function. When using the View datafunctions called by this transactional function right click menu option in AFP Calibration > Transactional functions:
a message is displayed to show that the transaction is assessed and has no data function:
Items that are considered datafunctions of a transaction
Previous releases of CAST Transaction Configuration Center did not recognize certain object types to be datafunctions of a given transaction. This has now been updated and the following objects are correctly recognized as datafunctions of a given transaction:
- COBOL file
- COBOL database
- COBOL database segment
- Data functions defined by type inheritance of category "APM IFPUG Data Function"
See also Changes or new features - 8.3.21.
User Input Security
The User Input Security feature has been updated and improved as follows:
- AIPCORE-1700 - User Input Security is now able to detect security violations in ASP.Net Core applications.
- AIPCORE-1702 - User Input Security is now able to detect security violations in ASP.Net MVC and ASP.Net MVC Core applications.
- AIPCORE-1704 - User Input Security now takes into account arguments of main/Main methods (java / C# / VB.Net) as entry-points.
- AIPCORE-1705 - User Input Security is now able to detect security violations in Apache Struts 2 applications.
- AIPCORE-1753 - NoSQL injections for applications using MongoDB/SpringData for Java can now be detected. Results are provided via the rule 8418 - Avoid NoSQL injection.