The client wants to copy their View database to 3390 Mod 27 volumes, instead of their present configuration consisting of a mixture of 3390 Mod 3 and Mod 9 devices.
The plan is as follows:
1. Shut down all CA View and CA Deliver tasks that affect the source database.
2. Run SARDBASE RENAME to rename VIEW.DB1 to name VIEW.DB2, so as to make it unavailable.
3. Run SARDBASE ADDDS (DATA and INDEX), to VIEW.DB3, to add new database extents to the Mod 27 volumes.
4. Run SARDBASE COPY, to copy VIEW.DB2 to VIEW.DB3.
5. Run SARDBASE RENAME, to rename VIEW.DB3 to VIEW.DB1
Our initial trial run will be to copy the original database with all DISK layer reports present so that we can measure the time period for the COPY process rather than remove all DISK/PERM reports via temporary ERO parameter settings prior to the SARDBASE COPY function. Questions ----------- 1. Is it correct to assume that the COPY function can copy safely from one DASD device type to another provided that the track sizes on all devices are identical? 2. Since the name of the new Mod 27 database will be the same as the original M0d 3/Mod 9 database, we believe that SARPAC activity will NOT be required. Is that correct? 3. Recently we have configured Mod 27 databases with eight (8) 4094 cylinder extents per volume. We have NOT seen any performance issues of any type. Do you have any other recommendations? 4. We assume that the COPY function copies all panels and banners to the output database. Is this correct? Please verify all information with CA Level 2 (SE) support. Thank you for your time, cooperation, and assistance. Best regards, --- Greg Hill M&T Bank 716-639-6420
CA View - All Releases
To copy a View database to another database:
1. Run SARDBASE ADDDS (DATA and INDEX), to VIEW.DB3, to add new database extents to the Mod 27 volumes.
2. Shut down all CA View and CA Deliver tasks that affect the source database (SARSTC, SARFSS, SARXMS, SARXTD, SAREAS).
3. Run SARDBASE COPY, to copy VIEW.DB1 to VIEW.DB3.
4. Run SARDBASE RENAME to rename VIEW.DB1 to name VIEW.DB2.
Note: A test run can be done of a SARDBASE COPY, while the source database is still active, to measure the time period needed to fully copy it, however the resulting output database would be of no use.
. Q1: The SARDBASE COPY safely copies data from one DASD device type to another, provided that the track sizes on all devices are identical?
. A1: The COPY function can indeed be done safely, from one DASD device to another, so long as the track geometries are similar.
. Q2: Since the name of the new Mod 27 database will be the same as the original Mod 3/Mod 9 database, will SARPAC activity not be required?
. A2: As the source and target databases will be the same entity, SARPAC will not be required.
. Q3: Mod 27 databases have been configured, with eight 4094-cylinder extents per volume. There being no performance issues of any kind, are there any recommendations?
. A3: View database extents will be direct-access files when the number of cylinders allocated is 4369 or less.
. A View database extent allocated above 4369 cylinders, to the maximum allowed of 32760, is a standard physical-sequential file.
. However, the BLKSIZE used, in the ADDDS statements, could have a bearing on performance, based on the optimization of the space used.
. A suggested optimized BLKSIZE, for a View DATA extent, is 13682 (98% track usage).
Q4: We assume that the COPY function copies all panels and banners to the output database. Is this correct?
. A4: The SARDBASE COPY copies everything: the index, reports, panels, banners, messages, and SARINIT parameters.