How to submit the FORMAT statement
A FORMAT AREA or FORMAT SEGMENT statement can be submitted through either the batch command facility or the online command facility. The batch command facility can be run in either local mode or under the central version. When submitted in local mode, FORMAT SEGMENT will behave like a FORMAT FILE for each file in the segment. When running under central version, it will behave like a FORMAT AREA for each area in the segment.
Note: The FORMAT FILE, FORMAT SYSTRK, and FORMAT JOURNAL statements can be submitted only through the batch command facility in local mode.
When to use FORMAT
You must use the FORMAT utility to prepare:
When necessary, you also use the FORMAT statement to reformat database files and areas, SYSTRK files and disk journal files.
When not to use the FORMAT statement
Do not try to reformat a file, area, or journal that is currently active under a DC/UCF system. Do not format an existing journal if it contains journal records that might be needed for recovery.
When formatting SQL-defined segments
When formatting an area or segment that contains SQL-defined tables, be sure you are connected to the catalog segment where the table definitions reside. You can issue an explicit CONNECT to the DBNAME of the dictionary containing the catalog segment or to the actual segment where the table definitions reside.
How FORMAT formats a database file or area
The FORMAT statement formats a database file or area into pages using information contained in the DMCL module. When formatting a database file or area, the FORMAT statement:
Restriction on the AREA parameter
When formatting a database by file, a sequential access method (QSAM) is used. When formatting a database by area, a direct access method is used. Because the database must be formatted into blocks by a sequential access method before it can be processed using a direct access method, you can use the AREA parameter of the FORMAT statement only when you are reformatting the area.
A format by segment in local mode is equivalent to format by file in this regard, and can be used to format new files. Format by segment under central version is equivalent to format by area and can only be used to reformat existing areas.
Area format depends on the area lock
In local mode, to prevent inadvertent formatting of an area that is being updated by another application, the area is locked for the duration of the operation when formatting by area. If the area is already locked, the format will not take place.
Formatting a locked area
If a local mode application abends while an area is being updated, the lock could remain on the area. In this case, you can either explicitly unlock the area using the UNLOCK utility, you can format by file, or you can use the ALREADY LOCKED option.
If ALREADY LOCKED is specified and the area was locked, the area will remain locked after the format is complete. The ALREADY LOCKED option is not required if formatting an area online or through batch/CV and is ignored if specified.
Formatting by segment does not lock areas
If you format by segment in local mode, the FORMAT utility does not lock the areas involved.
Reformatting an area
You can reformat a database by file, by area, or by segment. Processing by file is more efficient than processing by area. However, if you format by file in an SQL-defined database, you must run the INSTALL STAMPS utility for each affected area or segment.
How FORMAT formats a disk journal file
The FORMAT utility formats a disk journal file into blocks according to the journal file definition in a DMCL module. The FORMAT utility writes a journal header record at the beginning of each block and sets the remainder of the block to binary zeros, except when the FAST parameter is specified. The FAST parameter, used only with previously initialized journal files, reinitializes the header files only.
Formatting disk journal files
A certain amount of space is reserved in each disk journal file for information about other systems with which a system communicates. All journal files must have the same amount of space since the data in one journal file is replicated to every other journal file.
You can specify the size or allow it to default. The actual size allocated may be higher than the value specified due to rounding. Space is allocated in blocks whose size is (journal block size minus 256). By default, one block is allocated. Additional blocks are allocated if needed until the total size meets or exceeds the size specified. If the journal block size is less than 256, no space will be reserved.
Committing prior work
Before executing this utility under a central version, you must commit any previous work done within the current session. For more information, see Central Version Considerations.
When to use MAX AREA
Normally when a journal is formatted, a fixed number of JHDA blocks are created. A JHDA block stores the ready status of areas for warmstart purposes. The size of a journal block and the number of JHDAs limit the number of areas that a Central Version can have open at one time.
The MAX AREA option lets a journal be formatted that can handle more areas without increasing the size of a journal block. Ideally, the size of a journal block should be optimized to improve runtime efficiency, and should not be affected by the number of areas that might exist.
The MAX AREA option can also reduce the number of JHDA blocks that are created, which frees journal space.
To calculate the number of areas that one JHDA journal block can handle, use the following formula:
number_of_AREAS = (jrnl_blksize - 32) / 8
When MAX AREA is not specified, the FORMAT utility command will create 3 JHDA blocks. The number of areas that the default will support will vary depending on the journal block size. For example if the journal were formatted with a block size of 2032 bytes, 750 areas could be open at one time, 250 per JHDA.
Native VSAM files
Native VSAM files that are to be accessed by CA IDMS/DB are not structured like CA IDMS/DB database files. Do not use the FORMAT statement against native VSAM files.
Formatting areas and segments under central version
The areas to be formatted must be in update mode to CV. The physical area lock for each area will remain on during and after the format. A logical area lock is acquired to prevent online transactions from updating the area during the format. If other online transactions are holding a logical area lock, Format will wait until the locks are released. If the wait would cause a deadlock, the format will be aborted. Once acquired, the logical area lock is released when a commit transaction is explicitly issued, or implicitly when the batch step ends, or at the end of the pseudo-converse when running online.
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 trade-off 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.
|
Copyright © 2014 CA.
All rights reserved.
|
|