CA Datacom Active Delivery for Version 14.01 delivers enhancements that provide you with improved usability, reduced costs, and more high-availability functionality.
Enhancements and Benefits
The following information provides an overview of the enhancements for the core set of CA Datacom products. For more information, see the PDCs, PTFs, and scenarios available through CA Support online and also on the CA Datacom Version 14.01 bookshelf.
This section contains new or enhanced information for the following topics:
CA Datacom Core Products
CA Datacom Tools Products
The following information provides an overview of the enhancements for the core set of products. For more information, see the PDCs, PTFs, and scenarios available through CA Support online and also on the Version 14.01 bookshelf.
The Version 14.01 zIIP enhancement delivers an improved internal architecture that increases the amount of CA Datacom Multi-User Facility (MUF) processing that is processed on a WLM enabled SRB. Therefore, it is available for execution on an IBM zIIP processor.
The end result is that early customer adopters have seen their CA Datacom MUF regions offloading over 90 percent of the total CPU to an IBM zIIP processor.
Benefits
The Version 14.01 bookshelf provides a link under By Scenario or Feature for “Enhanced zIIP Exploitation.” This link contains a FAQ document and a pre-recorded presentation that explains the enhanced zIIP exploitation feature.
For more information, see the Database and Systems Administration Guide. This guide provides information about how to set up the MUF to start the MUF region with the zIIP feature enabled.
The additional zIIP offload capabilities are immediately available to user sites that are running with the current maintenance (PTFs) applied for Version 14.0.
The two Dynamic System Tables that provide information on the zIIP eligibility and zIIP actual CPU usage are:
This table provides information about the WLM-enabled SRB tasks and their zIIP eligibility CPU, actual CPU, and other related information.
This table provides information about the CPU seconds consumed by each of the TCB and WLM-enabled SRB tasks (and their zIIP eligibility).
The Change Data Capture (CDC) PLUS option allows the CDC environment to add up to eight additional CDC PLUS databases for the CDC captured data row storage. These additional PLUS databases allow you to separate the CDC captured data rows by application function, security access, or other business need that requires the captured data rows to be logically separated.
You can send captured data row changes to one or more of the CDC PLUS databases. This allows you to select the change capture information that is needed for each business case. Each of the CDC PLUS databases can be secured using different external security rules providing access protection to the data in the captured rows.
Benefits
The "How to Build CDC PLUS Databases" scenario provides information that guides you through the necessary steps to establish the CDC PLUS environment.
Supplemental reference information is also provided for:
For more information, see "How to Build CDC PLUS Databases" on the 14.01 bookshelf under the Scenario section.
Implementing the Version 14.01 CDC PLUS databases requires the definition of the additional CDC PLUS repositories (databases). These databases are defined similarly to the existing BASE database definition (DBID 2009). The database definitions (BTG decks) are available through CA Support online PTFs and their installation is covered in the CDC PLUS Scenario.
Once the additional change capture (PLUS) databases are defined, update your CDC parameters in the MUF region. As with the database definitions, these parameter definitions and implementation instructions can be found in the CDC PLUS scenario.
On request, CA Support can provide a recorded webcast presentation that can guide you through the process of implementing a CDC PLUS environment.
As part of the implementation of CDC PLUS, many existing CDC messages were updated to include information on the CDC change capture database that is being targeted. These necessary changes in the messages are to help you understand which of the CDC repositories is affected. For the sites using the basic setup, the CDC change repository is considered the “base.” Sites implementing the additional CDC repositories see those as PLUS 2, PLUS 3, and so on.
The CDC PLUS option could generate messages for:
The following messages are new for the CDC PLUS option.
This message was generated because a STATUS_CDC console command was issued to monitor the status of Change Data Capture (CDC).
This message is generated in response to a STATUS_CDC command as the second line in that response.
This message is generated in response to a STATUS_CDC command as the second line in that response.
This message was generated because a STATUS_CDC console command was issued to monitor the status of Change Data Capture (CDC). Information is provided relating to the output slots with the number of AUD log records to process and the DBID where the slot output is directed.
For more information about these messages, see the Message Reference Guide on the Version 14.01 bookshelf.
The Online Area Move (OAM) functionality provides a unique capability for CA Datacom users. The OAM is a patent-pending technology. This new technology allows you to move the underlying data blocks for a data or index area from one physical DASD dataset to another without interrupting your access to the data stored in the index and data area.
The only requirement is that the dataset architecture for the source and target datasets must be a 3390 device with both datasets having the same block size.
With OAM, the database administrator or system programmer can move index and data areas from one physical dataset to another to fulfill a significant business need without interrupting user access. OAM is another tool in the arsenal of CA Datacom that allows businesses to keep their data up and accessible 24x7.
The OAM functionality is performed within the MUF address space which allows the coordination necessary to permit user access. Since it is a MUF resident task, it is controlled and monitored using all of the standard MUF monitoring tools such as, SYSVIEW and Dynamic System tables. A new OAM status command is provided to assist you in monitoring the online move process.
Benefits
Two scenarios are provided to help you prepare for and perform an OAM.
Provides information to guide you through the necessary steps to create (PREINIT) the dataset that is used as the target for an OAM process.
Additional information is also provided on the DBUTLTY functions that are used to:
Provides information to guide you through the process to move the contents of the underlying dataset of an index or data area to a new dataset. This action is done without interrupting your access to the data stored in those areas.
Step by step instructions are provided to assist you in successfully moving the underlying datasets for your index or data areas. The new DBUTLTY commands are included that are used to trigger (ONLINE_AREA_MOVE) and monitor (STATUS_OAM) the OAM process. The scenario includes information on the following topics:
For more information about these scenarios, see the Version 14.01 bookshelf under the Scenario section.
Implementing the Version 14.01 OAM utilizes a new set of DBUTLTY functions to set up the target dataset and a simple console command to MUF to activate the OAM process.
Since you are actively moving database data while other users may be accessing the data, we recommend that you become familiar with the process and do various test executions using a test or sandbox environment.
The OAM process is straight forward. However, it is something that you want to test and become familiar with before attempting to use it in a production environment.
On request, CA Datacom support can provide a recorded webcast presentation to guide you through the process of using OAM to move an active index or data area.
There are three types of messages that you might receive during your Online Area Move:
Progress Message
This informational message can occur for the following reasons and requires no action:
Status Message
This informational message provides information about the status of the online move and requires no action.
Error Message
This message provides information about the failure of an online move request. Each message should be analyzed to determine the appropriate course of action.
The CXX (directory) dataset maintains various sets of information on the database, areas, and tables in the Datacom environment. For many years, the DBUTLTY REPORT AREA=CXX function has been used to list information in the CXX dataset.
Most of the CXX information is relatively stable and only changes when a database change is catalogued from the Datadictionary. However, there is certain statistical information that changes continuously for databases that tasks running in the MUF process.
For the last several releases, there has been a continuous effort to keep as much of the MUF processing done in memory to:
One of these efforts included keeping CXX statistical information for active databases in the MUF memory. Typically, a database is opened shortly after the MUF is enabled. Its CXX information is copied into the MUF memory. That information remains in the MUF memory until the database is closed to MUF. While the database is open to MUF, all of the changes to the statistical information, such as row counts and blocks in use, are updated in CXX definition in MUF memory. This information is only copied back to the CXX dataset when the database is closed to MUF.
Since Release 11.0, when you issued the DBUTLTY COMM OPTION=STATS command you could force the CXX information for a given database in MUF memory to be updated back to the CXX dataset. If you were running a CXX report (which prints its information directly from the CXX dataset), you were instructed to execute the COMM OPTION=STATS function before running any CXX report to ensure that the report would have the latest CXX statistical information.
However, many sites have implemented automated processes to print and analyze CXX reports. In other cases, the COMM OPTION=STATS command was forgotten. The end result is that the information retrieved from the CXX report would have inaccurate statics. These inaccurate statistics might lead to an incorrect decision such as whether a data area needs to be extended or not.
In a different case, the MUF could ABEND due to an unplanned event. When this happens, the normal processing to copy the in-memory CXX statistical information back to the CXX dataset may not get a chance to complete. When this occurs, the next iteration of the MUF starts with CXX statistical information from the CXX dataset which may no longer represent the correct values. The current MUF iteration would appropriately update the statistical information as it changes. However, since the values started out incorrect, they will most likely remain incorrect. In some cases, these incorrect values may not be noticed for long periods of time.
Once the incorrect value is uncovered, DBUTLTY functions can be executed to correct key statistics such as row counts and blocks in use.
To improve the reliability of the statistical information in the CXX, Version 14.01 has delivered four separate enhancements to provide Automatic CXX (Directory) Information Updates.
Enhancements
If a database is open in MUF at the time a CXX report is requested for that database, the DBUTLTY process automatically issues the COMM OPTION=STATS command. This command ensures that the CXX dataset information is updated with the current information in MUF memory before the CXX report is created.
Benefits
Most sites have the History database (DBID 1007) enabled. This functionality triggers MUF to record information on a daily basis regarding data area usage and record when LXX spill processes are used to create RXX datasets.
If a database is open in MUF when the History database daily collection of area usage is written, a COMM OPTION=STATS command is issued. This action ensures that the CXX dataset information is updated from MUF memory at least once every 24 hours.
Benefits
In previous releases, a sub-function of the DBUTLTY RETIX function was provided to update specific information regarding data area block usage (KEYNAME=*DATA) and table row counts (KEYNAME=*SETR). These functions run while the database is open in MUF and update the statistical information stored in the MUF memory (CXX definition) for that database.
If either of these functions are executed with a database open in the MUF, the COMM OPTION=STATS process is executed at the end of the KEYNAME=*DATA or KEYNAME=*SETR function. This action ensures that the statistical information from the MUF memory is also updated into the CXX dataset.
Benefits
During an abnormal termination of the MUF address space, the CA Datacom code attempts to gain control of the address space and perform certain abnormal termination processes.
If the ABEND processing does get control and the CXX statistical information in the MUF is still intact in the MUF memory, a process (similar to the COMM OPTION=STATS command) is executed to update the statistical information from the MUF memory to the CXX dataset.
Benefits
Note: If the MUF region is flushed or the LPAR crashes without the MUF ABEND routines being executed, the CXX statistical information is not updated. In these cases, you can choose to execute the *DATA and *SETR functions to reset the area block usage information and table row count statistics.
There are no scenarios or other articles around these four enhancements since most of the automated CXX updates occur without requiring you to be involved. We have added brief updates to the various CA Datacom manuals to explain when the automated CXX statistical updates are triggered.
The IXX (index) dataset maintains various indexes (or keys) for the tables that are associated with the IXX dataset. The IXX design uses a “balanced binary tree” process to store index values and quickly provide the information that is required to find a specific data row.
To maintain the balance and performance of the index, CA Datacom includes an Index Queue process. The Index Queue process can run anytime that a database is open to MUF and it is detected that rebalancing of the index tree is needed. Typically this occurs when there are many additions and or deletions of data rows which cause a significant shift in the index values stored in the index.
This enhancement includes three separate improvements to the Index Queue process to improve its performance and abilities.
Since most of the “Index Queue Processing” occurs without you being involved, there is no scenario or other articles around these three enhancements.
The SQL language provides significant capabilities for you to access your data using the simple and flexible SQL language syntax.
This enhancement includes five separate improvements to the SQL language processing within CA Datacom. Each of these enhancements is described in the following topics.
The GROUP BY clause can now contain SQL Expressions, to allow you to create more flexible SQL queries to retrieve and group data rows using SQL expressions.
For more information about the SQL GROUP BY clause and the use of SQL expressions, see the SQL User Guide on the Version 14.01 bookshelf.
SQL can now use index-only processing for columns that are defined as VARCHAR (and are part of the index).
Index-only processing eliminates the cost of reading the data row by returning data columns directly from the traversal index when that index contains all columns that the query references, and isolation level is not ‘R’ (repeatable read).
Since the index does not store the VARCHAR length, it is recomputed without trailing blanks.
For more information about the SQL Index only processing for VARCHAR columns, see the SQL User Guide on the Version 14.01 bookshelf.
Performance is improved on complex SQL queries where multiple tables are accessed by the SQL statement using the OR predicate by evaluating predicates for previous tables before calling Compound Boolean Selection (CBS).
Example
SELECT * FROM T1,T2 WHERE T1.COL1 = 1 OR T2.COL2 = 2;
Previously, neither predicate could be passed to CBS to possibly restrict an index scan range because CBS accesses a single table. Predicates can now be sent to CBS for the second table T2 by evaluating the predicates on previous tables.
In this example, if COL1 = 1 is TRUE, the COL2 =2 predicate is not passed to CBS since the row has already been accepted. If COL1 is not 1, then the COL2 = 2 predicate is passed to CBS. This predicate is the only one that can accept the row.
For more information about SQL Multiple Tables under an OR Predicate Evaluation, see the SQL User Guide on the Version 14.01 bookshelf.
SQL can now use the internally stored row-count value to respond to a SELECT COUNT(*) query when only one table is referenced and no WHERE clause is present.
This enhancement was done with the Automatic CXX Update Enhancement (as described previously) which takes multiple steps to keep the internally stored (MUF memory) row count as accurate as possible.
Add a simple WHERE clause that has an always “true” condition if you want to force the SELECT COUNT(*) query to read and count every data row. For example: SELECT COUNT(*) FROM SYSUSR.PAYROLL WHERE 1 > 0.
For more information about the SQL SELECT COUNT(*) enhancement, see the SQL User Guide on the Version 14.01 bookshelf.
This enhancement applies to queries that join a master table to one or more optional tables with only one possible matching row. Not accessing unreferenced optional tables improves performance. The most common example is when a view is defined to return all possible optional data, but a query is only interested in some of the optional data.
Example
An insurance company may have a master contact record for a customer and optional matching rows for an auto, home, or life insurance policy.
For convenience, a view is defined to return data from all four tables by using a LEFT JOIN to select the optional policy tables. Since there is a matching Primary Key on all four tables on customer-id, there can only be one matching row on each of the optional policy tables.
With this enhancement, a query using this view to analyze only auto insurance data now only accesses the master and auto policy tables. Accessing the other optional tables and then doing nothing with that data is eliminated.
Note: “SELECT COUNT(*)” benefits from this optimization because there can only be one matching row with the equijoin condition on the common Primary Key.
For more information about the SQL Elimination of Left Outer Join tables, see the SQL User Guide on the Version 14.01 bookshelf.
Since most of the “SQL processing updates” occur without requiring your involvement, there is no scenario or other articles around these four enhancements. Instead we have added brief updates to the SQL User Guide to explain the implementation of these enhancements.
This informational message is issued in response to a selected module loaded by MUF or DBUTLTY. The message is also issued each time DBSQLPR is used.
|
Copyright © 2015 CA Technologies.
All rights reserved.
|
|