Release | Yes/No |
|---|---|
| 8.3.x |  |
| 8.2.x | |
RDBMS | Yes/No |
|---|---|
| Oracle Server | |
| Microsoft SQL Server | |
| CSS2 | |
Recommendation and special cases
Mainframe Job - Split recommendations
This is for mainframe analysis results. It is assumed that if you split jobs they are all linked together through a linker.
General considerations
- You may have the same file in different jobs: its objects will be merged in KB.
- Keep all JCL files in the same job, more precisely, if a job contains a JCL file it should contain all the JCL files.
- Always include all copybooks in a job containing COBOL.
- You may split COBOL programs among different jobs.
- CICS files may be put in a separate job
Special case of JCL + COBOL + IMS
In the case of JCL + COBOL + IMS: you may have IMS separated, but you should keep JCL and COBOL in the same jobs (if you need to split Cobol, put all JCL in each job containing Cobol).
Example :
a job (JOB A1) with all IMS
a job (JOB A2) with all JCL, half COBOL programs, and all COBOL copybooks
a job (JOB A3) with all JCL, the rest of COBOL programs, and all COBOL copybooks
DotNet job - Split recommendations
Dot NET solution can contain code source projects and assembly. Code source projects are related together or to the assembly by "links". After launching analysis, CAST-MS will generate a specific configuration of "links" between AUs or between AU and assembly. Note that the configuration of "links" depends on the Release version of CAST-MS, the main difference resides on "links" between AU and assembly generated by a source project.
Before splitting a Dot NET job we have to be sure that we will not break "links" between AU's. Otherwise, we could have a negative impact on results.
Let's take the following source code example :
We have 3 source code project A, B, D, and 2 assemblies B.dll and C.dll. Links between A and B.dll, C.dll, D.cssproj are reference links, and the link between B.dll and B.cssproj is a generation link (Assembly B.dll is generated by Project B).
- In 8.3.x we will have the following analysis unit:
To conclude, in version 8.3.x and higher, we can split one AU from other(s) only if the project of this AU is generating assembly
J2EE Job - Split recommendation's
In 8.3.x and higher
Regarding the J2EE analyzer, please see the process described in the official documentation: J2EE - application qualification specifics - Split your analysis
Impact of splitting
If you do not respect methodologies or recommendation of job splitting, you can have some negative impact on results:
- Missing transactions
- Missing violation of quality rules (full positive or full negative)
- Missing links
Methods to split Execution Units / Analysis Units in 8.2.x /8.3.x
There are four ways to split Execution Units / Analysis Units
The Delivery Manager Tool will discover the application by pointing to the application source code and will create packages. Each package will contain Analysis Units that are grouped by the Execution Unit.
In order to avoid an Out Of Memory or a crash, you can discover smaller packages.
For Example, in the screenshot below, in the DMT, the Main Package is pointing to the main root folder of the source code.
This package can be split into multiple smaller packages as shown below:
This will lead to the creation of multiple smaller packages.
The Analysis Units are grouped into Execution Units. Analysis Units having the same "Execution Units Annotation" are grouped in the same Execution Unit. The Execution Unit annotation is visible in Expert Mode.
The Execution Units Annotation is in the Execute Tab of an Analysis Unit, as you can see below :
To split the Execution unit into multiple Execution Units, you need to set different annotations to each analysis unit. Then, each analysis unit will be executed alone and not grouped with other analysis units.
When you need to split Analysis Units into many Analysis Units, you need to exclude from the source settings of the main Analysis Units you want to split, some source path and create a new analysis unit that will analyze the path that has been excluded from the first analysis unit.
Shown below is the main analysis unit to split :
We exclude from this Analysis Units a folder :
And we create a new Analysis Units having the same configuration, but in the source settings, will analyze the folder that has been excluded from the main Analysis Units.
To make these two analysis units executed in two different Execution Units, we need to set the Execution Units Annotation with two different values.
The Analysis Units are grouped into Execution Units. Analysis Units having the same "Execution Units Annotation" are grouped in the same Execution Unit. The Execution Unit annotation is visible in Expert Mode.
The Execution Units Annotation is in the Execute Tab of an Analysis Unit, as you can see below :
Before splitting the EU we can take the backup of the table to revert the changes, below are the queries:
set search_path = <YOUR_MANAGEMENT_DATABASE> create table temp_cms_net_analysis as select * from cms_net_analysis -- Create a temporary table to copy the content of original table select * from temp_cms_net_analysis -- check the copied contents
Before running, the below query make sure to close the CAST-MS.
If we have massive AUs in one single EU and if there is a requirement to split the EU's (mostly in case of an investigation by Dichotomy), then we cannot open each AU and put several annotations, rather it can be done by running the below query
update cms_net_analysis -- This table contains the list of .Net Analysis Unit (table name differs with technology) set exectag = object_id -- This will put Execution Unit Annotation corresponding to object_id of Analysis Unit
Below is the screenshot after running the above query the AUs has different annotations
Sometimes there are cases when we have lots of analysis units and then splitting each analysis unit into different execution units can lead to performance issues while running the analysis due to the isolation of all the analysis units.
So in such cases, we split the analysis unit into different GROUPS (Groups are nothing but the execution units). To achieve this you need to first find the range of object_ids and then create the queries accordingly.
Below is a sample query where the object_ids are considered from a range of 100000 and 110000 which can help to split the analysis units into several groups.
update cms_net_analysis set exectag = 'GROUP1' where object_id between 100000 and 110000 ............. update cms_net_analysis set exectag = 'GROUP2' where object_id between 110001 and 120000 .............
To go back to the initial configuration of the Execution unit (without the split), close CAST Management Studio and run the following queries :
set search_path = <YOUR_MANAGEMENT_DATABASE>; truncate table cms_net_analysis; insert into cms_net_analysis select * from temp_cms_net_analysis;
