The Director's Chair
by Cesare Petrizio		Advanced Technique
		From FOCUS to WebFOCUS
		Feature Preview
		New Feature
		FOC101
		Feature
		FOCUS – Then and Now
		Releases Currently Shipping and Latest Certifications
		User Group Meeting Schedule

Estimating Sizes of FOCUS or XFOCUS Databases In estimating the number of bytes, blocks, tracks, etc., to allocate for FOCUS or XFOCUS databases, there are several areas to consider: Segments Data storage Pointers Indexes and text fields Control information overhead Unused space on a database page Estimating Segment Size (For Both FOCUS and XFOCUS Databases) The number of bytes required for data storage is determined by the USAGE for the fields in the segment. Since pointers require full word (4-byte word) boundaries, if the total length of a segment instance is not divisible by 4, it is padded to a full-word boundary. Any change to the storage length will require doing a REBUILD/REORG. However, changes to USAGE formats that do not affect storage requirements may be made by simply using a text editor to change the Master File Description, for example I2, I9, etc. Storage lengths for the various field formats are as follows: Format Type Length Storage in Bytes A n n I 1-10 4 D 1-16 8* F 1-9 4* P 1-15 8 P 16-31 16 TX N/A 4** * Precision will vary if a format length greater than the maximum is specified. ** TEXT fields in FOCUS/XFOCUS databases are actually stored in separate pages. The only overhead in the segment with which they are defined is a 4-byte pointer to the actual variable-length text. Each pointer/link in a FOCUS or XFOCUS database is 4 bytes and any change in design that affects the number of pointers requires a REBUILD/REORG. The pointer types are: CHAIN pointer: Every instance in a FOCUS/XFOCUS database points to the next instance of the same segment. Note that this includes UNIQUE segments (SEGTYPE = U). PARENT-TO-CHILD pointer: A PARENT segment points to the first instance of each CHILD segment. This includes static cross-reference children (SEGTYPE = KU or KM). For a SEGTYPE = KU, the pointer points to the actual instance in the cross-reference file. For SEGTYPE = KM, the pointer points to the index entry in the cross-reference file. CHILD-TO-PARENT pointer: Each CHILD instance points back to its PARENT instance. This allows for alternate file views. Indexes and Text Fields It is difficult to estimate size requirements for text fields, as they depend solely on the number of characters input, without limitation on actual size. All text fields are stored on separate pages from the segment instances, but there is not a separate page for each text field. So, if you specify TXTFLD1, TXTFLD2, and TXTFLD3, only one page is initially assigned to all instances of all text fields, while the pointers in their parents show the actual page and offset values. The basic storage requirements for indexes are field lengths (based on USAGE) plus a 4-byte pointer. When an index exceeds one page it is split into two, and a “root page” with a field value (plus 8) is created. Again, it is difficult to estimate the actual storage requirements for an index, as the way it is loaded affects the utilization of the index pages. Thus, it is usually safer to assume half-full pages, rather than underestimate the requirements. Control Information Two types of control information are stored for each page in the database in the File Directory Table and the Control Block Information. The File Directory Table contains information for each segment, index, and text field. This includes the segment/index name, segment size, number of pointers, total number of pages, etc. You can display this information by entering: ? FDT filename. In FOCUS databases, the FDT is stored on page 1, along with first instances of the root segment that fit on the remainder of the page. In XFOCUS databases the FDT takes up all of page 1, with no root segment instances. Control Block Information on each page includes segment number, date, time, and transaction number of the last update to the page, plus the addresses of free and deleted space on the page. For a summary, enter: ? FILE filename. In a FOCUS database, the Control Block resides in bytes 3,968 thru 4,096 of each FOCUS page. In XFOCUS databases, because the page length requires it, the control information takes 92 bytes plus 4 bytes for each instance on the page. Unused Space on Database Pages The page size for FOCUS databases is 4K (4,096 bytes), of which 3,968 are available for storing data and pointers. Thus, only three instances of a 1,000-byte segment would fit on a page, rendering the remaining 968 bytes unusable, as they could not hold a full instance. The page size for XFOCUS databases is 16K (16,384). To determine usable space, since an additional pointer is required for each instance, it is generally easier to assume an extra pointer for each instance and a page size of 16K – 92 (or 15,292). So, using a segment size of 1,000 bytes with additional overhead of 4 bytes per instance, we can store 16 instances on an XFOCUS page. With very small segments, conversely, you have better storage utilization with FOCUS databases, as an 8-byte segment can store 496 instances on a FOCUS page, but only 1,357 instances on an XFOCUS page. To aid you in making these calculations, the CALCFILE utility focexec has been updated for XFOCUS databases. CALCFILE reads your Master File Description and prompts you for the expected number of instances per segment and then calculates the number of pages you should allocate. Index pages, as suggested previously, are assumed to be half full.