This chapter describes the non-stop processing enhancements.
This section contains the following topics:
Change tracking enables changing the database environment of a Central Version (CV) in a fault-tolerant manner. Specifically, it enables the DBA to perform the following actions:
Change tracking also provides an easy way for a local mode job to use the same database environment (definition and data sets) as a CV, even if that environment has been impacted by dynamic modifications.
More Information
To track changes, CV maintains a description of its database environment in a new type of file called a SYSTRK file. The presence of such a file in the execution JCL of a CV triggers change tracking by that CV. A local mode job, such as a journal archive job, can share the description of the CV's database environment by referencing the same SYSTRK file in its execution JCL.
A SYSTRK file holds a description of the database environment most recently in use by the CV. During startup, an image of the current DMCL is written to SYSTRK along with information about database and journal files defined in the JCL. If DCMT commands issued during CV execution cause critical changes to its database environment, SYSTRK is updated to reflect those changes. If the CV fails, the runtime database definition is restored from SYSTRK during restart, ensuring that the files being updated at the time of failure are the ones recovered by warmstart unless explicitly overridden by changes in the JCL used to restart the CV.
Change tracking is optional. If no SYSTRK file is referenced in the execution JCL of the CV, change tracking is not in effect, meaning that the potential for a warmstart failure is introduced when varying in a new copy of a DMCL or dynamically changing the data set name of a file. Additionally, any permanent status established for an area whose page range is changed is lost or may be misapplied to another area whose page range is also changed.
Change tracking can be temporarily inactivated or disabled for a CV to facilitate expansion or replacement of a SYSTRK file. However, doing this impacts the ability to dynamically change the database environment.
To implement change tracking for a CV, take the following steps:
Once change tracking has been initiated for a CV, its use should be continued indefinitely; otherwise, permanent area or journal statuses will be lost. Despite this, if you choose to discontinue the use of change tracking, do so as follows:
Note: You can temporarily disable change tracking by issuing a DCMT VARY CHANGE TRACKING command or by overriding the SYSTRK file assignments to reference a dummy file.
More Information
A SYSTRK file must be formatted before it can be used. The FORMAT utility statement has been enhanced for this purpose.
Syntax
►─ FORMAT ─┬ . . . ────────────────────────────────────────────────────┬──────►◄ │ │ └ SYSTRK ── SYSTRK-format-options ──────────────────────────┘
Expansion of SYSTRK-format-options
┌─────────,─────┐ ►──── ▼ ─ target-ddn ─┴──────┬──────────────────────────────────────────┬─────►◄ └─ INITIAL ┬───────────────────────────┬───┘ └─ initial-SYSTRK-options ──┘
Expansion of initial-SYSTRK-options
┌───────────────────────────────────────────────────────────────────────┐ ►───▼ ─┬─ FILE COUNT file-cnt ─────────────────────────────────────────────┬┴─►◄ ├─ DELETE ┬ ON ─┬───────────────────────────────────────────────────┤ │ └ OFF ┘ │ ├─ PAGE SIZE page-size ─────────────────────────────────────────────┤ ├─ FILE SIZE number-of-pages ───────────────────────────────────────┤ └─ LIKE ─ ddname2 ─┬────────┬─┬────────────────────────────────────┬┘ └ ACTIVE ┘ └ EXPAND ─ pct-increase ─┬─────────┬─┘ ├ percent ┤ └ % ──────┘
Parameters
Indicates that one or more SYSTRK files are to be formatted.
Specifies the DDname or linkname of a SYSTRK file to be formatted.
Note: The target-ddn should not begin with the DDname prefix used for referencing SYSTRK files. Otherwise, CA IDMS attempts to use it for building the DMCL definition and fails if it cannot do so.
Indicates this is the first time the SYSTRK file is being formatted. If specified, no check is made to determine whether the file is in use by a CV. INITIAL must be specified the first time a file is formatted. It should not be specified when a file is being re-formatted unless you are sure that the file is not in use by a CV.
Specifies the number of SYSTRK files that are maintained as active mirrors. The file-cnt must be an integer in the range 2 through 4.
If file-cnt is not specified, the value is taken from the file identified by ddname2, if specified, or at run time from the file count currently in use by the DC/UCF system. If file-cnt has never been specified on a format for a related SYSTRK file, the first time that a DC/UCF system writes to a set of SYSTRK files, it sets file-cnt to be the lesser of the number of files currently allocated and 4. The value can be altered dynamically by a DCMT VARY CHANGE TRACKING command.
Specifies whether the DC/UCF system is to automatically delete obsolete SYSTRK files.
(z/OS and z/VM systems only) Enables automatic file deletion.
Disables automatic file deletion.
If DELETE is not specified, the value is taken from the file identified by ddname2, if specified, or at run time from the delete option currently in use by the DC/UCF system. If DELETE has never been specified on a format for a related SYSTRK file, the first time that a DC/UCF system writes to a set of SYSTRK files, it sets the option to OFF. The option can be altered dynamically by a DCMT VARY CHANGE TRACKING command.
Specifies the size of each page to be written to the SYSTRK file being formatted and must be an integer in the range 4088 through 32764. On z/VM, the value must be 4096. On z/OS, the maximum page-size is 32760. Do not specify page-size for VSAM files.
Specifies the number of pages to be written to the SYSTRK file being formatted and must be an integer in the range 10 through 999,999.
Specifies the DDname of a file from which the attributes and contents may be taken. If ddname2 is specified together with either or both page-size and number-of-pages, the latter values override the respective attributes of the file identified by ddname2.
Note: ddname2 should not begin with the DDname prefix used for referencing SYSTRK files unless the identified file contains the DMCL definition to be used during execution of the command facility.
Indicates that the contents of the file identified by ddname2 are to be copied to the file being formatted even if the file identified by ddname2 is currently in-use by a CV.
Specifies the percentage increase in the number of pages written to the file being formatted over the number of pages in the file identified by ddname2. The pct-increase must be an integer in the range 0 through 1000.
Note: For more information about the DDname prefix used for referencing SYSTRK files, see Referencing SYSTRK Files in Execution JCL.
Usage
Referencing SYSTRK Files During Format
To avoid I/O errors when building the runtime environment in local mode, only previously formatted files should be referenced using a DDname that matches the SYSTRK DDname prefix. For this reason, it is recommended that non-matching DDnames always be used to identify SYSTRK files being formatted.
SYSTRK File Attributes
If a SYSTRK file is being formatted to be added as a mirror of an existing file, the page sizes of the two files must be the same and the file being formatted must have at least as many pages as the existing file. If these criteria are not met the following conditions can occur:
If INITIAL is not specified, the page size and number of pages of a file being formatted remain unchanged.
If INITIAL is specified, the number of pages written to the file is determined according to the following precedence rules:
page-cnt * (100 + pct-increase) / 100
Specifies the number of pages in the file identified by ddname2.
Specifies the value in the EXPAND parameter, if specified or 0.
((DMCL-size + page-size -1) / page-size)*4
Specifies the size of the DMCL load module.
Specifies the page size of the file being formatted.
In the latter two cases, the number calculated is rounded up to the next larger integer value. If the calculated value is less than the minimum, it is set to the minimum of 10. If the calculated value is larger than the maximum, it is set to the maximum of 999,999.
If INITIAL is specified, the size of the pages written to a non-VSAM file is determined according to the following precedence rules:
For VSAM files, the page size is the file record size. Any attempt to override this through a PAGE SIZE parameter fails.
Choosing a SYSTRK Page Size
In most cases, the FORMAT utility's default page size for SYSTRK files provides an acceptable tradeoff between memory, I/O, and disk space. Consider overriding the default only if the size of the DMCL is extremely large (500K or more). A larger page size will reduce I/Os and disk space requirements at the expense of slightly increased memory usage for buffers.
Estimating the Minimum Number of Pages for a SYSTRK File
To estimate the minimum number of pages needed for a SYSTRK file, perform the following steps:
Copying SYSTRK File Contents
If a LIKE parameter is specified, the contents of the file identified by ddname2 are copied to the files being formatted unless the file identified by ddname2 is in use by a CV or the attributes of the two files are incompatible. If the contents of ddname2 are not copied, a message indicates the reason.
If the file attributes are compatible, specify the keyword ACTIVE to force the copy to occur even if the file identified by ddname2 is in use by CV. Only do this if you are sure that CV will not update the file while the copy is in progress, otherwise, the contents of the two files may not be the same which can lead to unpredictable results during CV restart. Ensure that a CV does not update its SYSTRK files by varying change tracking inactive before doing the format.
There is normally no need to force the contents of SYSTRK files to be copied. CV automatically updates newly formatted SYSTRK files as part of making them active mirrors.
Note: Formatting SYSTRK files can only be done in local mode.
JCL Considerations
When you submit a FORMAT statement through the batch command facility in local mode to format SYSTRK files, the JCL to execute the facility must include statements to define the SYSTRK files to be processed.
To format a new SYSTRK file, code the following:
//anydd DD DSN=user.systrkn,DISP=(NEW,disp), // UNIT=disk,VOL=SER=nnnnnn, // SPACE=(space)
To reformat an existing SYSTRK file, code the following:
//anydd DD DSN=user.systrkn,DISP=(OLD,PASS)
The target DDname specified in the FORMAT SYSTRK statement.
Data set name of the SYSTRK file.
Note: For more information about generic JCL to execute the batch commandfacility, see the chapter pertaining to your operating system in the CA IDMS Utilities Guide.
Examples
Formatting SYSTRK Files
The following sample IDMSBCF statement instructs the FORMAT utility to format three new SYSTRK files (track01, track02, track03). It directs the utility to format the files to have the default page size of 7548 and contain 60 pages each. CA IDMS will maintain 3 active mirrors.
format systrk track01, track02, track03 initial file count 3 file size 60;
Sample Output
Formatting SYSTRK Files
The following listing was generated after the successful completion of the previous FORMAT SYSTRK example.
IDMSBCF CA IDMS Batch Command Facility FORMAT SYSTRK TRACK01, TRACK02, TRACK03 INITIAL FILE COUNT 3 FILE SIZE 60; Systrk file TRACK01 page size 7,548 file size 60 delete NULL file count 3. Systrk file TRACK02 page size 7,548 file size 60 delete NULL file count 3. Systrk file TRACK03 page size 7,548 file size 60 delete NULL file count 3. Status = 0 SQLSTATE = 00000 AutoCommit will COMMIT transaction Command Facility ended with no errors or warnings
SYSTRK files are referenced in execution JCL using file assignments whose DDname begins with the value specified by the SYSIDMS parameter: SYSTRK_DDNAME_PREFIX. The default value for this parameter is SYSTRK. Because mirroring is used to provide recovery in the event of file damage, multiple SYSTRK files must be used at runtime.
Depending on your operating system, you can reference SYSTRK files in execution JCL by including one of the following:
Referencing SYSTRK files using a model is the recommended approach because it enables the set of active SYSTRK files to be changed without impacting execution JCL.
Using a Model SYSTRK File Assignment
A model SYSTRK file assignment has a DDname that is the SYSTRK_DDNAME_PREFIX. It references a data set whose name is used as the prefix for constructing the names of the real SYSTRK files by appending a numeric suffix ranging from 1 to 9 to the end of the model's data set name.
For example, if the SYSTRK_DDNAME_PREFIX is SYSTRK and a model SYSTRK file assignment references a data set name of DBDC.SYSTEM73.SYSD with a disposition of SHR, CA IDMS attempts to discover through dynamic allocation the data sets shown in the following table:
|
DDNAME |
DSN |
DISP |
|---|---|---|
|
SYSTRK1 |
DBDC.SYSTEM73.SYSD1 |
SHR |
|
SYSTRK2 |
DBDC.SYSTEM73.SYSD2 |
SHR |
|
" |
" |
" |
|
SYSTRK9 |
DBDC.SYSTEM73.SYSD9 |
SHR |
The presence of a file assignment whose DDname is SYSTRKn overrides the generated data set name and disposition. If an overriding file assignment refers to a dummied file, the overridden file is not used.
If a model SYSTRK file assignment refers to a dummied file, it is equivalent to not including a model file assignment in the execution JCL.
Note: The data set referenced by a model SYSTRK file assignment is never opened. While the file must exist, its contents are not relevant.
Note: In z/VSE if a model SYSTRK label is used, the individual SYSTRK files must be defined in system labels, or cataloged in a CA DYNAM catalog. Otherwise it is recommended to use individual SYSTRK file assignments. If the IDMSLBLS JCL procedure is used, you may wish to add a SYSTRK model or individual file assignments here.
Using Individual SYSTRK File Assignments
The DDNAME for an individual SYSTRK file assignment is the SYSTRK_DDNAME_PREFIX suffixed with a digit from 1 to 9. For example, if the SYSTRK_DDNAME_PREFIX is SYSTRK, the DDNAMEs that can be used for SYSTRK files are SYSTRK1, SYSTRK2, . . . SYSTRK9.
Using this approach to reference SYSTRK files requires that a file assignment be included in the JCL for each SYSTRK file to be used. To change the set of files being used, you must update every set of JCL in which they are referenced.
This section describes the facilities that are available for managing change tracking. The following topics are covered in this section:
Displays information on the status of change tracking and on the SYSTRK files currently known to the system.
Syntax
►►─ DCMT ─┬───────────────────┬─ Display CHAnge TRAcking ─────────────────────►◄ └─ broadcast-parms ─┘
Parameters
Specifies to execute the DCMT command on all or a list of data sharing group members.
Note: For more information about broadcasting and broadcast-parms, see How to Broadcast System Tasks in the CA IDMS System Tasks and Operator Commands Guide.
Example
DCMT D CHANGE TRACKING Change Tracking - Status Delete PageCnt Target-FileCnt Actual-FileCnt ACTIVE OFF 21 4 2 SYSTRK contents Size PagCnt Pct Last Updated (time zone: UTC) DMCL + file information 35076 5 24% 2007-06-14-17.06.20.642828 Permanent area statuses 0 0 0% 2007-06-14-17.06.23.349039 Journal status overrides 0 0 0% 2007-06-14-17.06.20.674228 Control information 30192 4 19% N/A -------------------------- ------ ------ ---- Total: 65268 9 43% File Name MirrorStat MODE ErrStat PagSize PagCnt Fl-Type DD-Name SYSTRK1 ACTIVE Clos 0 7548 21 non-VSAM SYSTRK1 DSname: DBDC.SYSTEM73.SYSTRK1 DISP=SHR VOLSER:CULL06 FORMAT datetime (time zone: UTC) 2007-06-08-13.31.15.587813 CONTROL datetime (time zone: UTC) 2007-06-14-17.06.15.640034 SYSTRK2 ACTIVE Clos 0 7548 21 non-VSAM SYSTRK2 DSname: DBDC.SYSTEM73.SYSTRK2 DISP=SHR VOLSER:CULL06 FORMAT datetime (time zone: UTC) 2007-06-08-13.31.15.674543 CONTROL datetime (time zone: UTC) 2007-06-14-17.06.15.640034
Usage
CHAnge TRAcking displays the following attributes:
DCMT VARY CHANGE TRACKING changes the status of change tracking.
Syntax
►►─ DCMT ┬───────────────────┬ Vary CHAnge TRAcking ───────────────────────────► └─ broadcast-parms ─┘ ►────┬─ REFresh ─────────────┬────────────────────────────────────────────────►◄ ├─ ACTive ──────────────┤ ├─ INActive ────────────┤ ├─ DISable ─────────────┤ ├─ FILe COUnt file-cnt ─┤ └─ DELete ┬─ ON ──┬─────┘ └─ OFF ─┘
Parameters
Specifies to execute the DCMT command on all or a list of data sharing group members.
Note: For more information about broadcasting and broadcast-parms, see How to Broadcast System Tasks in the CA IDMS System Tasks and Operator Commands Guide.
Adds new SYSTRK files to the list of mirrors and terminates use of older or non-existent mirrors. New SYSTRK files are made active before terminating the use of other SYSTRK files. In the process of becoming active mirrors, the contents of new files are brought up-to-date if necessary. Terminated files are deleted if the current delete option is ON. After a successful refresh, the status of change tracking is active.
If change tracking is active, this option has no effect. If change tracking is inactive or disabled, this option activates change tracking and enables the execution of DCMT commands that update information in SYSTRK. An automatic refresh is done as part of activation. Any files with out-of-date contents are brought up-to-date as part of the process of becoming active. The contents of all SYSTRK files are refreshed if change tracking was previously disabled. At least one SYSTRK file must exist and achieve active mirror status before certain DCMT commands can be executed.
Note: For a list of impacted commands, see DCMT Commands that Require Active Change Tracking.
Deactivates change tracking and prevents the execution of certain DCMT commands. All SYSTRK files are closed and deallocated except those that have encountered an I/O error.
Disables change tracking but does not prevent the execution of certain DCMT commands. Disabling change tracking should only be used in an emergency situation because the inability to record changes in the SYSTRK files may lead to incorrect recovery during warmstart and incorrect area statuses on system restarts.
Specifies the target number of files to be maintained as active mirrors. file-cnt must be an integer in the range 2 through 4. To affect the number of files actually in use while change tracking is active, issue a DCMT VARY CHANGE TRACKING REFRESH command.
Specifies whether the DC/UCF system automatically deletes obsolete SYSTRK files.
(z/OS and z/VM systems only) Enables automatic file deletion.
Disables automatic file deletion.
Usage
Refreshing SYSTRK File Use
If the REFresh option is specified or change tracking is activated by specifying the ACTive option, the system replaces existing SYSTRK files with more recently formatted ones. This is useful in expanding the size of SYSTRK files because newer files can have more pages than existing files. To increase the amount of SYSTRK space available, all files must be replaced with files having the larger number of pages.
The following algorithm is used when refreshing SYSTRK file usage:
Note: This may take some time if the file is in use by another job.
DCMT Commands that Require Active Change Tracking
If change tracking is in use for a CV, the following commands are impacted by the status of change tracking:
Note: If change tracking is inactive, these commands are prohibited. If it is disabled, a warning is issued if these commands are executed.
A set of SYSTRK files can be expanded by using the FORMAT utility statement. The procedure for expanding files while CV remains active differs depending on whether the SYSTRK files are referenced through a model SYSTRK file assignment or if they are referenced using individual file assignments.
Expanding Files Referenced Through a Model SYSTRK File Assignment
Assuming two SYSTRK files are in use, take the following steps to increase the size of the SYSTRK files while the CV remains active:
FORMAT SYSTRK DD1, DD2 INITIAL LIKE DD3 EXPAND 20 PERCENT
Where DD1 and DD2 are the DDnames of file assignments referencing the new SYSTRK files, and DD3 is the DDname of a file assignment referencing one of the old SYSTRK files. In this example, the files are being expanded 20 percent over their current size.
DCMT VARY CHANGE TRACKING REFRESH
When the old files are no longer in use, they can be deleted.
Expanding Files Referenced Through Individual File Assignments
Assuming two SYSTRK files are in use, take the following steps to increase the file size while the CV remains active:
DCMT VARY CHANGE TRACKING INACTIVE
FORMAT SYSTRK DD1, DD2 INITIAL LIKE DD3 EXPAND 20 PERCENT
Where DD1 and DD2 are the DDnames of file assignments referencing the new SYSTRK files, and DD3 is the DDname of a file assignment referencing one of the old SYSTRK files. In this example, the files are being expanded 20 percent over their current size.
DCMT VARY CHANGE TRACKING ACTIVE
This section describes the impact that change tracking has on the execution of existing DCMT commands and the new SYSIDMS parameters related to change tracking.
The output of this command now includes the output from a DISPLAY CHANGE TRACKING command so that it includes output from all of the following commands:
The DCMT DISPLAY FILE command displays information about a specified file. It has been enhanced to support journal and SYSTRK files.
Syntax
►►─ DCMT ─┬───────────────────┬─ Display ──────────────────────────────────────► └─ broadcast-parms ─┘ ►──── File ─┬─ . . . ──────────────────────────────────┬──────────────────────►◄ ├─ journal-file-name ──────────────────────┤ └─ SYSTRK-file-name ───────────────────────┘
Parameters
Displays information about one or more files.
Specifies the name of a disk or archive journal file.
Specifies the name of a SYSTRK file.
The DCMT VARY FILE command alters information about a specified file. It has been enhanced to enable altering information about SYSTRK files and to update SYSTRK when changing the data set name of a database or journal file.
Syntax
►►─ DCMT ─┬───────────────────┬─ Vary ────────────────────────────────────────► └─ broadcast-parms ─┘ ►── File ─┬─ segment-name.file-name ───────────────┬────────── . . . ────────►◄ └─ SYSTRK-file-name ─────────────────────┘
Parameters
Identifies a specific file.
Specifies the segment associated with the file.
Specifies the name of the file.
Specifies the name of the SYSTRK file.
Enables access to the file and sets its status to something other than 9999 if this is a database file. If the file is not open, it is opened the next time it is accessed. Varying the file active allows suspended transactions that are waiting on the file to resume execution.
If this is a SYSTRK file, its mirror status is changed to active or activating. Before an activating mirror becomes active, its contents are brought up-to-date.
Disables access to the file and sets its status to 9999 if this is a database file. The ability to vary database files inactive is provided to simulate I/O errors for the purpose of testing recovery procedures.
If this is a SYSTRK file, its mirror status is changed to inactive. If this is the last active mirror, change tracking is inactivated.
(z/OS and z/VM systems only) Allocates the file dynamically, using its currently assigned data set name and other options specified on its definition.
Changes the data set name of a database file in the runtime DMCL to new-dataset-name. If the file has not been opened, then only the DSname is changed. If the file has previously been opened, then the DSname is changed, and the DDname is cleared to blanks.
Data set names of SYSTRK files cannot be changed.
Usage
Changing the Data Set Name of a File
The ability to change the data set name of a file through a DCMT VARY FILE command is provided for emergency situations only, such as, when a data set is physically damaged and cannot be recovered using its original name. Data set name changes made through a DCMT VARY FILE command are temporary and are not preserved after a normal shutdown. Furthermore, they introduce the potential for incorrect recovery during warmstart unless change tracking is active or appropriate changes are made to the execution JCL of the system to ensure that the correct data set is referenced.
Note: To make permanent changes to the data set name of a file, change its definition in the dictionary and use a DCMT VARY DMCL command to make the change effective within a DC/UCF system.
To change a data set name through a DCMT VARY FILE command, the following conditions must be met:
The DCMT VARY AREA/SEGMENT command updates information about one or more database areas. It has been enhanced to maintain permanent area statuses in the SYSTRK files if change tracking is in effect for the CV.
Changing the Area Status Permanently
A permanent area status is one that is retained until it is changed by another DCMT VARY command, or until the system journal or SYSTRK files are formatted. The area status is retained across normal shutdowns and across abnormal terminations, provided the warmstart option of the area in the DMCL specifies MAINTAIN CURRENT STATUS.
Note: The permanence of an area status has no effect on physical area locks. It only affects the mode in which the area is accessed when the system is next started. If the DC/UCF system is shut down normally, all physical area locks held by the system are removed, regardless of whether the area status of the system was assigned as UPDATE PERMANENT.
If change tracking is in use for the DC/UCF system, permanent area statuses are recorded in the SYSTRK files. Status entries are identified by area name and are deleted when their associated area is no longer in the runtime DMCL. A vary that affects the permanent status of an area fails if change tracking is inactive and receives a warning if it is disabled.
If change tracking is not in use for the DC/UCF system, permanent status entries are recorded in the system journals and are identified by page group and low-page number. If a page group or low-page number of an area is changed, an existing permanent status entry cannot be matched against the area. If this happens, the usage mode of the area defaults to the usage-mode specified in the DMCL and the orphaned status entry for the area remains in the journals until they are formatted. It is also possible for an orphaned status entry to be misapplied to a new area with a matching low page number and page group.
The DCMT VARY DMCL command updates the database environment in use by the CV to reflect the current DMCL load module. It has been enhanced to maintain an up-to-date description of that environment in the SYSTRK files if change tracking is in effect for the CV.
Using a New Copy of the Database Load Module
DCMT VARY DMCL NEW COPY allows programs running under the DC/UCF system to benefit from changes made to the database definition without having to recycle the system. For example, an area can be added to an existing segment while the system remains active.
When a DCMT VARY DMCL NEW COPY command is issued, CA IDMS applies changes to the database definition that have been made by the following DDL statements:
Additionally, CA IDMS loads a new copy of the database name table. The system must be recycled to implement changes made to the journal buffer, to VARY in a DMCL generated under a release level that is different from that of the current DMCL, or to remove or replace all active disk journal files at the same time.
Impact of Change Tracking
If change tracking is in use, a DCMT VARY DMCL NEW COPY command can only be issued if change tracking is active or disabled. We recommend that change tracking be active in systems in which new copies of DMCLs are to be varied online.
Note: For more information, see Recovery Considerations and DMCL Changes.
What DC/UCF Does in Response to a New Copy Command
In response to a DCMT VARY DMCL NEW COPY command, CA IDMS performs the following actions:
When quiescing access to impacted entities, the following actions are taken:
Note: If areas or disk journals must be varied offline, the vary operation could have a lengthy completion time. Before responding Yes to the prompt, note the areas affected by the change and the transactions that are accessing those areas. If disk journals are being changed, look for transactions that may depend on those journal files for recovery. Look especially for long-running transactions that do not issue frequent commits.
Recovery Considerations and DMCL Changes
If change tracking is active when a DCMT VARY DMCL NEW COPY is issued, CA IDMS ensures that any subsequent warmstart uses the correct data sets and DMCL definition by recording the new definition in the SYSTRK files. If a failure occurs prior to writing the new DMCL to SYSTRK, the system restarts using the old DMCL definition and data sets. Otherwise, the system restarts using the new definition and data sets. If the write to SYSTRK fails because of an I/O error or out-of-space condition, the vary operation continues but change tracking is varied inactive, and manual intervention is needed to restart the CV in the event of a failure. Therefore, you should correct the cause of the failure and vary change tracking active as soon as possible. If the CV fails before these corrective actions are taken, specify IGNORE_SYSTRK_DMCL=ON in the SYSIDMS file when restarting the system, and ensure that the execution JCL does not reference obsolete data sets. If IGNORE_SYSTRK_DMCL=ON is not specified, warmstart fails due to a mismatch between the timestamp in the DMCL and that recorded on the journal files.
If change tracking is disabled or not in use when a DCMT VARY DMCL NEW COPY is issued, manual intervention may be necessary to ensure correct recovery in the event that a subsequent warmstart is needed. The necessary actions depend on when the failure occurs:
New SYSIDMS parameters have been added in support of change tracking.
Specifies whether to disable building the runtime DMCL from the SYSTRK file and instead force the use of the DMCL load module.
Specifies to disable use of SYSTRK for building the runtime DMCL.
Specifies to build the runtime DMCL from SYSTRK if the CV was not previously shutdown normally.
OFF
Specifies the DDname prefix to be used for referencing SYSTRK files in execution JCL.
Specifies the 1- to 7-character DDname prefix.
SYSTRK
Dynamic Journal files provide enhanced 24x7 capabilities by enabling the journal files in use by a CV to be changed while the system remains active. Journal files can be added, removed, or replaced without processing interruption. If change tracking is employed, the following additional functionality is provided:
To implement this feature, a data set name can be specified during journal file definition and if present, is used to dynamically allocate the file at runtime. New options on the DCMT VARY JOURNAL command enable changing a journal's data set name and varying journal files on and offline. Journal files can be dynamically added, replaced or removed by varying a new copy of the DMCL.
To dynamically change the data set name of a journal file or remove a journal file, it must be "quiesced." A journal file reaches a quiesced state when no active transaction is dependent on it for recovery and its contents have been archived. The ability to quiesce use of a journal file is new for r17.
During a DCMT V DMCL NEW COPY command, the system automatically quiesces use of journal files that have been removed or whose definition has had critical changes.
A new FILE OFFLINE option on the DCMT V JOURNAL command enables the DBA to quiesce use of a specific journal file. When a CV restarts after an abnormal termination, an offline journal remains offline. A PERMANENT option on the VARY command enables the DBA to specify that the offline status should be retained across a shutdown and restart. The PERMANENT option is only available if change tracking is active.
To Dynamically Add a Journal File to a CV
CREATE/ALTER DISK JOURNAL dmcl-name.journal-name DSNAME 'data-set-name'
To Dynamically Remove a Journal File
DROP DISK JOURNAL dmcl-name.journal-name
Note: It is not possible to apply critical changes to all active journal files at one time when varying in a new copy of the DMCL. To make such changes without recycling CV, repeat the above process and replace or remove only some of the journal files each time.
To enable dynamic allocation of journal files, new parameters have been added to the CREATE DISK JOURNAL and ALTER DISK JOURNAL DDL statements:
Syntax
►─┬─ CREATE ─┬─ DISK JOURNAL ─ . . . ──────────────────────────────────────────► └─ ALTER ──┘ ►─┬────────────────────────────────┬───────────────────────────────────────────► └─ ASSIGN TO ─┬─ ddname ─────────┤ ├─ filename ───────┤ └─ NULL ───────────┘ ►─┬─────────────────────────────┬──────────────────────────────────────────────► └─ DSNAME ─┬ 'data-set-name' ─┤ └─ NULL ◄──────────┘ ►─┬─────────────────┬──────────────────────────────────────────────────────────► └─ DISP ─ SHR ◄───┘ ►─┬──────────────────────────────────────────┬─────────────────────────────────► └─ VM VIRTUAL ADDRESS ─┬─ virtual-address ─┤ └─ NULL ◄──────────┘ ►─┬───────────────────────────┬───────────────────────────────────────────────►◄ └─ VM USERID ─┬ vm-user-id ─┤ └─ NULL ◄─────┘
Parameters
Specifies an external file name. Every external file name in a DMCL definition must be unique. In z/VSE without DYNAM/D, an external file name must be specified. In other environments, if the external file name is not specified, a data set name or VM virtual address must be specified.
(z/OS and z/VM systems only) Specifies the external name for the file. ddname must be a 1- through 8-character value that follows operating system conventions for ddnames.
(z/VSE systems only) Specifies the external name for the file. filename must be a 1- through 7-character value that follows operating system conventions for file names.
Sets the external file name to blanks. It is equivalent to not specifying an external file name for a file. This option is not valid under z/VSE unless DYNAM/D is being used.
Specifies the name of the data set to be used when dynamically allocating the journal file for z/OS, z/VSE, and OS-format data sets under z/VM.
data-set-name must conform to host operating system rules for forming data set names.
A data-set-name that includes embedded periods must be enclosed in single or double quotation marks.
Under z/VM, the DSNAME parameter or VM VIRTUAL ADDRESS and USERID parameters, or both can be specified.
Sets the data set name to blanks. This is equivalent to not specifying a data set name for a file.
(z/OS and z/VM systems only) Specifies the disposition to be assigned when the file is dynamically allocated.
Indicates that the data set used for the file is available to multiple DC/UCF systems and local mode applications at a time.
Under z/VM, DISP SHR causes a link with an access mode of multiple read (MR).
SHR is the default when you do not include the DISP parameter in a CREATE JOURNAL FILE statement.
(z/VM systems only) Specifies the virtual address of the minidisk used for the journal file. virtual-address is a hexadecimal value in the range X'01' to X'FFFF'.
Sets the virtual address to blanks. On CREATE statements, this is equivalent to not specifying a virtual address for a file. On ALTER statements, it removes any previous virtual address specification for the file.
(z/VM systems only) Identifies the owner of the minidisk used for the journal file. vm-user-id is a 1- to 8-character value.
A user ID for an OS-format data set must be specified. The user ID is optional for CMS-format files.
If a user ID is not specified for a CMS-format file, CA IDMS assumes that the owner of the minidisk is the user ID of the virtual machine in which it is running.
On CREATE statements, this is equivalent to not specifying a minidisk owner for a file. On ALTER statements, removes any previous minidisk owner specification for the file.
Usage
Dynamic Allocation of Journal Files
Dynamic allocation of files is operating system and file-type dependent. For information about allocating files dynamically, see FILE Statements in the CA IDMS Database Administration Guide
The DCMT DISPLAY JOURNAL command displays information about the journals. It has been enhanced to display information about a specific journal file.
Syntax
►►─ DCMT ─┬───────────────────┬─────────────────────────────────────────────────────────► └─ broadcast-parms ─┘ ►─ Display ─┬─ Journal ─┬─ journal-file-name ─────────────────────────────────┬─┬─────►◄ │ └─ FILe journal-file-name ─┬────────────────────────┬─┘ │ │ └─ PENding TRAnsactions ─┘ │ └─ Journals ────────────────────────────────────────────────────────┘
Parameters
Displays information about a disk journal.
Specifies the name of the disk journal.
Outputs information about pending transactions.
Usage
Displaying Pending Transactions of a Disk Journal File
A pending transaction is a transaction that is active and might need the named disk journal if the transaction has to be backed out. Pending transactions prevent the disk journal from reaching an offline status.
Example
DCMT DISPLAY JOURNAL FILE journal-file-name PENDING TRANSACTIONS
DCMT DISPLAY JOURNAL FILE SYSJRNL2 PENDING TRANSACTION Task / LTE Trans-ID Pri Orig Module SS/AM St Stat Date:Time 57 165 100 LOC LOCKTEST EMPSS01 RW H 2007-03-16-08.52.45.6079
The DCMT VARY JOURNAL command varies journaling-related options and switches the active journal from one file to another. It has been enhanced to enable changing the status and attributes of an individual journal file.
Syntax
►►─ DCMT ─┬───────────────────┬─ Vary ─────────────────────────────────────────► └─ broadcast-parms ─┘ ►── Journal ┬─ . . . ───────────────────────────────────────────────────────┬─►◄ ├─ SWAp ◄───────────────────────────────────────────────────────┤ └─ FILe journal-file-name ┬ OFfline ┬────────────┬┬────────────┬┤ │ └─ PERmanent ┘└ ID dcmt-id ┘│ ├ ONline ─────────────────────────────┤ ├ ACtive ─────────────────────────────┤ ├ Inactive ───────────────────────────┤ ├ ALlocate ───────────────────────────┤ ├ DEallocate ┬───────┬────────────────┤ │ └ Force ┘ │ └ DSname new-dataset-name ────────────┘
Parameters
Directs CA IDMS to switch the active journal file from one file to another.
Specifies the name of the disk journal to be varied.
Makes the specified disk journal file inaccessible to the system.
Specifies that the OFFLINE status of the journal file is permanent. The status remains in effect until it is changed by another DCMT VARY command or the SYSTRK files are formatted.
The ability to record a status as permanent requires that change tracking be active. If change tracking is not active, the OFFLINE status is not made permanent and a warning message is issued.
Specifies the identifier that is assigned to this vary operation. It must be a 1- to 8-alphanumeric character string that is unique across all outstanding DCMT operations originating on this DC/UCF system.
If no dcmt-id is specified, the vary operation is assigned an internally generated identifier.
The identifier can subsequently be used to monitor or terminate the vary using DCMT DISPLAY ID and DCMT VARY ID commands.
Makes the specified disk journal file accessible to the system.
Enables access to the journal file and sets its status to something other than 9999.
Varying the file active allows suspended transactions that are waiting on the journal file to resume execution.
Disables access to the journal file and sets its status to 9999. No new journal images are written to the file, but it can still be read for recovery purposes.
The ability to vary journal files inactive is provided to simulate I/O errors for the purpose of testing recovery procedures.
Dynamically allocates the journal file using its currently assigned data set name.
Dynamically closes and deallocates the named file.
Directs DC/UCF to mark the file as deallocated and closed, even though these actions were not taken. This option is useful for certain types of error conditions for which a close cannot be completed.
Changes the DSname temporarily in the runtime DMCL to new-dataset-name. If the file has previously been opened, the DDname is cleared to blanks.
To change the DSname of a disk journal, it must be offline.
Usage
Forcing a Journal SWAP
The SWAP option of the DCMT VARY JOURNAL command directs the DC/UCF system to switch the active journal file from one disk journal file to another. If only one journal file is online and usable, the contents of the journal file must be offloaded before the command can complete and journaling resume. This causes a delay in the execution of all update transactions until the swap completes.
Varying a Specific Journal File
The DCMT VARY JOURNAL FILE command is intended for solving disk journal problems such as I/O errors while DC/UCF remains active. Before issuing any DCMT VARY JOURNAL FILE command, see Recovery Procedures from Journal File I/O Errors in the CA IDMS Database Administration Guide.
To successfully issue a VARY JOURNAL FILE command, the target journal file must not be the active journal file. Additionally, the following restrictions apply depending on the nature of the change:
Varying a Disk Journal File Offline
When varying a disk journal file offline, the system quiesces use of the journal file before marking it as offline. While the journal file is quiescing, the following is true:
Note: Once the journal file reaches the quiesced state, it is closed.
The DCMT DISPLAY JOURNAL FILE command is used to determine which transactions may have journal images on the target file.
Dynamically Allocating and Deallocating Journal Files
The ability to dynamically allocate and deallocate journal files is operating system and file-type dependent. The restrictions are the same as those for database files.
Note: For more information about allocating and deallocating files, see DCMT VARY FILE Command in the CA IDMS System Tasks and Operator Commands Guide.
Example
DCMT VARY JOURNAL FILE journal-file-name OFFLINE
DCMT VARY JOURNAL FILE SYSJRNL2 OFFLINE Journal SYSJRNL2 OFFLINE Disk Journal Segno LoRBN HiRBN NxRBN Ful Act Rcv Arc Stat DsRBN DsINTV Tql SYSJRNL2 OFFLINE ------ Journal File ------- MODE Stat Pg-Size Fl-Type M-Cache S-Cache DD-Name SYSJRNL2 Clos 0 2932 non-VSAM No No SYSJRNL2 VOLSER: CULL06 DSname: (JCL)... DBDC.SYSTEM73.SYSJRNL2 DISP=SHR
The CA IDMS scratch area is a virtual database whose content disappears when a job step ends. To eliminate all I/O to the associated file, the scratch area can be maintained in memory. Scratch enhancements for r17 include the following:
You can control scratch in memory using the following methods:
Use the system generation SYSTEM statement to control the scratch area.
Syntax
►►─┬──────────┬─ SYStem dc/ucf-version-number ─ . . . ────────────────────────► ├─ ADD ────┤ ├─ MODify ─┤ └─ DELete ─┘ ►──┬──────────────────────────────────────────────────────────────┬──────────► └─ SCRatch in STOrage is ─┬─ NO ◄──────────────────────────────┤ └─ YES ─┬───────────────────────────┬┘ └── scratch-storage-parms ──┘
Expansion of scratch-storage-parms
►►──┬───────────────────────┬─────────────────────────────────────────────────► └─ LOCation ─┬─ XA ─────┤ ├─ ANY ◄───┤ └─ 64-bit ─┘ ►──┬─────────────────────────────────────────────┬───────────────────────────► └─ PRImary extent is ─┬─ prim-size-with-unit ─┤ └─ DEFAULT ◄────────────┘ ►──┬──────────────────────────────────────────────┬──────────────────────────► └─ SECondary extent is ─┬─ sec-size-with-unit ─┤ └─ DEFAULT ◄───────────┘ ►──┬─────────────────────────────────┬───────────────────────────────────────►◄ └─ LIMit is ─┬─ limit-with-unit ─┤ └─ DEFAULT ◄────────┘
Parameters
Specifies whether scratch information resides in memory.
Specifies that the scratch information is not memory-resident.
Specifies that the scratch information is memory-resident.
Controls where memory for the scratch information is allocated with the following options:
Determines the storage location. The storage needed for scratch processing is allocated directly from the operating system and not from the CA IDMS storage pools.
ANY Acquires 64-bit storage, if possible. If the request to allocate 64-bit storage fails, XA storage is acquired.
XA Acquires 31-bit storage.
64-bit Acquires 64-bit storage. If the request to allocate 64-bit storage fails, no attempt to acquire XA storage is done.
Notes:
Specifies the primary scratch allocation size.
Specifies the size of the initial storage area acquired for scratch use. Enter a number in the range 1-32767 followed by a unit of KB (Kilobyte: 2**10), MB (Megabyte: 2**20), GB (Gigabyte: 2**30), TB (Terabyte: 2**40), or PB (Petabyte: 2**50).
Specifies the system default value. If the DMCL contains a scratch area definition, the default value is the number of pages in the area multiplied by the page size. If no scratch area is defined in the DMCL, the system default value is 1 MB.
Specifies the secondary scratch allocation size.
Specifies the amount of additional storage acquired when all existing scratch storage is in use. Enter a number in the range 1-32767 followed by a unit of KB (Kilobyte: 2**10), MB (Megabyte: 2**20), GB (Gigabyte: 2**30), TB (Terabyte: 2**40), or PB (Petabyte: 2**50).
Specifies the system default value. The size of the secondary allocation is equal to the size of the primary allocation.
Specifies the maximum scratch allocation size.
Specifies the maximum amount of scratch storage. The system continues to allocate more storage for scratch processing until the sum of all allocations reaches the value specified by limit-with-unit. Enter a number in the range 1-32767 followed by a unit of KB (Kilobyte: 2**10), MB (Megabyte: 2**20), GB (Gigabyte: 2**30), TB (Terabyte: 2**40), or PB (Petabyte: 2**50).
Specifies the system default value. If the DMCL contains a scratch area definition, the default value is the number of pages in the area multiplied by the page size. If no scratch area is defined in the DMCL, the system default value is the size of the primary allocation plus 99 times the size of the secondary allocation.
More Information
For more information about the System Generation SYSTEM statement, see the CA IDMS System Generation Guide.
A new DCMT DISPLAY SCRATCH command has been added to obtain the following information about scratch usage:
Syntax
►►─── DCMT ─┬───────────────────┬─────────────────────────────────────────────► └─ broadcast-parms ─┘ ►──── Display SCRatch ───────────────────────────────────────────────────────► ►──────┬────────────────────────────────────────┬────────────────────────────►◄ │ ┌──────────────────────────┐ │ ├─ SORt ──┬ ▼ ┬─┬── DEScending ◄─┬────┬┴─┘ └─ ORDer ─┘ │ └── ASCending ───┘ │ └─ BY ─┬─ SIZe ◄──────┬─┘ ├─ LTErm ──────┤ ├─ SCRatch id ─┤ └─ USEr id ────┘
Parameters
Indicates to execute the DCMT command on all or a list of data sharing group members.
Note: For more information about broadcasting and broadcast-parms, see How to Broadcast System Tasks in the CA IDMS System Tasks and Operator Commands Guide.
Displays global statistics, definition-related, and detailed information about scratch.
Requests sorted output.
Specifies to display the higher values first in the sorted output. This is the default.
Specifies to display the lower values first in the sorted output.
Identifies the sort criterion.
SIZe
Specifies to sort by the scratch area size. This is the default.
LTErm
Specifies to sort by the logical terminal name.
SCRatch id
Specifies to sort by the scratch area ID.
USEr id
Specifies to sort by the user ID.
Usage
Obtaining Output with SORT BY
SORT BY allows you to obtain the output that is most relevant for a given situation as shown in the following examples:
Example
DCMT DISPLAY SCRATCH SORT DESCENDING BY SIZE
DCMT DISPLAY SCRATCH SORT DESCENDING BY SIZE Total number of pages 391 Location ANY Storage Page size 2676 Storage address 00000001 00900000 Primary extent #pages 391 Primary extent size 1 MB Secondary extent #pages 783 Secondary extent size 2 MB Storage limit #pages 11363 Storage limit size 29 MB PUT scratch requests 223 Scratch Areas active 9 GET scratch requests 91 Scratch Areas created 12 DELETE scratch requests 44 HWM concurrent Scr. Areas 9 Pages in use 240 HWM pages in use 241 Pages in use percentage 61% HWM pages in use percentage 61% Buffers N/A HWM pages in use for 1 S.A. 141 Pages found in buffer N/A HWM pages found for 1 S.A. N/A Pages written N/A HWM pages written for 1 S.A. N/A Pages read N/A HWM pages read for 1 S.A. N/A Scratch Area ID Size: Pages / % LTERM User id OCF*FSEO 140 35 VL72001 USER02 DDDLFSEI 83 21 VL72002 USER01 SSCHFSEO 6 1 VL72001 USER02 OCF*FSEI 3 <1 VL72001 USER02 SSCHFSEI 3 <1 VL72001 USER02 DDDLFSEO 2 <1 VL72002 USER01 DDDLFSEC 1 <1 VL72002 USER01 OCF*FSEC 1 <1 VL72001 USER02 SSCHFSEC 1 <1 VL72001 USER02
More Information
For more information about DCMT commands, see the CA IDMS System Tasks and Operator Commands Guide.
A new DCMT VARY SCRATCH command has been added to dynamically alter the scratch area control parameters.
Syntax
►►─── DCMT ─┬───────────────────┬─────────────────────────────────────────────► └─ broadcast-parms ─┘ ►──── Vary SCRatch ──────────────────────────────────────────────────────────► ►──────┬──────────────────────────────────────────┬──────────────────────────►◄ ├─ LOCation ─┬─XA ──────┬──────────────────┤ │ ├ ANY ─────┤ │ │ └ 64-bit ──┘ │ ├─ SECondary extent is sec-size-with-unit ─┤ └─ LIMit is limit-with-unit ───────────────┘
Parameters
Indicates to execute the DCMT command on all or a list of data sharing group members.
Note: For more information about broadcasting and broadcast-parms, see How to Broadcast System Tasks in the CA IDMS System Tasks and Operator Commands Guide.
Specifies the size of the secondary allocation, maximum amount of storage, and storage location.
Specifies where memory for the scratch information is allocated with the following options:
Determines the storage location. The storage needed for scratch processing is allocated directly from the operating system and not from the CA IDMS storage pools.
ANY
Acquires 64-bit storage if possible. If the request to allocate 64-bit storage fails, XA storage is acquired.
XA
Acquires 31-bit storage.
64-bit
Acquires 64-bit storage. If the request to allocate 64-bit storage fails, no attempt to acquire XA storage is done.
Specifies the secondary scratch allocation size.
Specifies the amount of additional storage acquired when all existing scratch storage is in use. Enter a number in the range 1-32767 followed by a unit of KB (Kilobyte: 2**10), MB (Megabyte: 2**20), GB (Gigabyte: 2**30), TB (Terabyte: 2**40), or PB (Petabyte: 2**50).
Specifies the maximum scratch allocation size.
Specifies the maximum amount of scratch storage. The system continues to allocate more storage for scratch processing until the sum of all allocations reaches the value specified by limit-with-unit. Enter a number in the range 1-32767 followed by a unit of KB (Kilobyte: 2**10), MB (Megabyte: 2**20), GB (Gigabyte: 2**30), TB (Terabyte: 2**40), or PB (Petabyte: 2**50).
Usage
Changing Scratch Parameters
The following information should be taken into consideration when changing scratch parameters:
Example: prim-size-with-unit=10 MB; sec-size-with-unit=5 MB; limit-with-unit=50 MB; three secondary extents are allocated (25 MB of storage is in use). DCMT VARY SCRATCH LIMIT 20 MB is issued. A secondary allocation is freed only when it becomes entirely unused.
Examples
DCMT VARY SCRATCH SECONDARY EXTENT 1 MB
V SCR SECONDARY EXTENT 1 MB IDMS DC293001 V71 USER:JSMITH Scratch Secondary extent changed to 1 MB
DCMT VARY SCRATCH LIMIT 10 MB
V SCR LIMIT 10 MB IDMS DC293001 V71 USER:JSMITH Scratch Limit changed to 10 MB
More Information
For more information about DCMT commands, see the CA IDMS System Tasks and Operator Commands Guide.
The DCMT HELP command has been enhanced to display a help screen of the DCMT DISPLAY SCRATCH and DCMT VARY SCRATCH syntax.
Syntax
►►─── DCMT ─┬───────────────────┬─────────────────────────────────────────────► └─ broadcast-parms ─┘ ►─────── Help ┬─ . . . ──────────────────────────┬───────────────────────────► └─ SCRatch ────────────────────────┘
Parameters
Displays syntax for the HELP command.
Displays the scratch help screen.
More Information
For more information about the DCMT HELP command, see the CA IDMS System Tasks and Operator Commands Guide.
Use the following SYSIDMS parameters to control the scratch processing:
Enables storage allocation from the operating system for scratch processing.
Specifies the same as SCRATCH_IN_STORAGE=ANY.
Specifies to allocate the scratch area as defined in the DMCL.
Acquires 64-bit storage if possible. If the request to allocate 64-bit storage fails, XA storage is acquired.
Acquires 31-bit storage.
Acquires 64-bit storage. If the request to allocate 64-bit storage fails, no attempt to acquire XA storage is done.
OFF
Note: Usage of 64-bit storage is controlled by the MEMLIMIT parameter of the JOB or EXEC JCL statement.
Specifies the maximum amount of scratch storage. The system continues to allocate more storage for scratch processing until the sum of all allocations reaches the value specified by limit-with-unit. Enter a number in the range 1-32767 followed by a unit of KB (Kilobyte: 2**10), MB (Megabyte: 2**20), GB (Gigabyte: 2**30), TB (Terabyte: 2**40), or PB (Petabyte: 2**50).
The default value is determined as follows:
Specifies the primary scratch allocation size. Enter a number in the range 1-32767 followed by a unit of KB (Kilobyte: 2**10), MB (Megabyte: 2**20), GB (Gigabyte: 2**30), TB (Terabyte: 2**40), or PB (Petabyte: 2**50).
The default value is determined as follows:
Specifies the amount of storage to allocate when all existing scratch storage is in use. Enter a number in the range 1-32767 followed by a unit of KB (Kilobyte: 2**10), MB (Megabyte: 2**20), GB (Gigabyte: 2**30), TB (Terabyte: 2**40), or PB (Petabyte: 2**50).
The default size of the secondary allocation is equal to the size of the primary allocation.
More Information
For more information about SYSIDMS parameters, see the CA IDMS Common Facilities Guide.
|
Copyright © 2009 CA.
All rights reserved.
|
|