Can I use IBM DFSMSdss (program ADRDSSU) to consolidate extents and move CA Datacom database files between devices?

Products

• Datacom
• DATACOM - AD
• CIS
• COMMON SERVICES FOR Z/OS
• 90S SERVICES
• DATABASE MANAGEMENT SOLUTIONS FOR DB2 FOR Z/OS
• COMMON PRODUCT SERVICES COMPONENT
• Common Services
• CA ECOMETER SERVER COMPONENT FOC
• Easytrieve Report Generator for Common Services
• INFOCAI MAINTENANCE
• IPC
• UNICENTER JCLCHECK COMMON COMPONENT
• Mainframe VM Product Manager
• CHORUS SOFTWARE MANAGER
• CA ON DEMAND PORTAL
• CA Service Desk Manager - Unified Self Service
• PAM CLIENT FOR LINUX ON MAINFRAME
• MAINFRAME CONNECTOR FOR LINUX ON MAINFRAME
• GRAPHICAL MANAGEMENT INTERFACE
• WEB ADMINISTRATOR FOR TOP SECRET
• Xpertware

Issue/Introduction

Summary: 

There are times when it is necessary to use utilities other than CA Datacom DBUTLTY to maintain database files. When a database file needs to be moved to a different device, or when multiple extents need to be consolidated, the DBUTLTY program cannot do this, and it is necessary to use programs like ADRDSSU provided as part of the IBM DFSMSdss product.

Environment: 

This applies to CA Datacom/DB and CA Datacom/AD running on z/OS.

Instructions: 

CA Datacom database files (both index and data areas) operate with pre-formatted blocks, regardless of whether the file is allocated in tracks or cylinders, and regardless of whether one volume or several are allocated to the file. As a result, space management for the database files and extents is managed at the block level.

This means that access to the data in the file is made relative to first block, so extents can be condensed from more into fewer, or into just one extent without any consequences as long as the sizing attributes stay consistent. Also, as long as the track geometry is the same (as is the case among all 3390 models), files can freely be moved among devices.

The DFSMSdss DEFRAG command operates at the track level, so it should not affect the block utilization for the database files. Using the COPY command requires a little more attention, as you need to ensure that you handle all blocks in the file. This means you will need to use the ALLD(*) and ALLX (or ALLDATA(*) and ALLEXCP) keywords. As with all activities that change the physical database files, you will want to be comfortable running this against test databases to note the effect before you use these commands on your production volumes containing CA Datacom databases.

Because of the serialization process used, you will need to have exclusive control of the CA Datacom database files on any volumes upon which you run the DEFRAG or COPY command, and you will need to close the databases in the Multi-User Facility (called MUF) prior to running the DFSMSdss commands. This means that you will need to close the databases in CICS (using the DBOC CLOSE or a similar transaction), and you will need to run a separate job first for program DBUTLTY with functions similar to these:

//SYSIN     DD  *
  ACCESS  DBID=###,STATUS=OFF,USERS=FAIL
  COMM    DBID=###,OPTION=CLOSE
/*

Once the DEFRAG or COPY is complete, you can restore access to the databases with DBUTLTY, using the ACCESS DBID=###,STATUS=WRITE function, and then use DBOC OPEN (or a similar transaction) to open the databases in the CICS regions in order to resume processing with those databases.

Note: Trying to DEFRAG or COPY the database files with a non-Datacom utility while the base is open could lead to data and/or index corruption, and this will likely lead to RC 13(02) and other error codes.

As always, please contact CA Technologies support for CA Datacom if you have further questions.

****

Environment

Release:
Component: DB