gtps4m1aSystem Generation

Database Allocation

There are four considerations when allocating DASD space for the database.

  1. What records are needed?
  2. How much space will they occupy?
  3. Which records need backup copies?

    Backup copies are often referred to as duplicates, or more simply, dupes. All records, some records, or no records may have duplicates. Whether records are duplicated is determined by the overall DASD duplication scheme (whether the system is fully, selectively, or nonduplicated).

  4. Where will the records be located?

    Each record group must have a specific and unique address assigned to it.

The allocation of records on all online modules in the same logical device type (DEVA, B, C, and D) is identical.

See Keypoint Records for the allocation of the keypoint area.

Record Types and Space Requirements

In the disk file programs and data records area, the records are grouped as follows:

Fixed file data records in the system are mainly disk resident. The fixed file area may be formatted for large (1055-byte), small (381-byte), or 4K-byte records, which are either duplicated or nonduplicated. Records are allocated across the online modules. The number and size of each type of record is determined based on various system and application parameters.

Records allocated to other file areas are omitted from the fixed file data record area. In addition to the fixed file disk resident records, main storage (#GLOBA, and others) records must be allocated. Backup copies for these records are disk resident in the fixed file area. Space should also be included for at least a 20 % expansion factor in each fixed area. These expansion areas are defined by coding SPARE records in RAMFIL statements (see RAMFIL). Table 13 is a worksheet for allocating fixed file data records. In order to convert the number of records to the number of tracks per module, divide the number of records of a given size by the number of records per track, times the number of online modules.

Table 13. Fixed File Data Record Worksheet

Fixed File Record Types Number of Records Number of Tracks/Modules
4KB Keypoint Records    
4KB, NonDup, High Activity    
4KB, NonDup, Low Activity    
Large, NonDup, High Activity    
Large, NonDup, Low Activity    
Small, NonDup, High Activity    
Small, NonDup, Low Activity    
4KB, Dup, High Activity    
4KB, Dup, Low Activity    
Large, Dup, High Activity    
Large, Dup, Low Activity    
Small, Dup, High Activity    
Small, Dup, Low Activity    

Disk file pool storage areas are used by system and application programs for the storage of temporary data. The directories which control the use of the pool storage areas reside in the fixed file area. Directories exist for each of the following pool types.

Whether short-term pools are duplicated or not depends on the system's file configuration. DASD short-term pools are only duplicated in a fully duplicated file system.

After fixed file requirements have been determined, the balance of the file space is available for the assignment of random pools. Some of the things that should be considered in the assignment of the file area for file pool storage are:

UFT/FTI Examples

The heart of the expanded addressing scheme represented by FARF4, FARF5, and FARF6 is the UFT/FTI. The UFT/FTI design uses a hierarchical technique for dividing very large amounts of file address space. A UFT points to several FTIs and each FTI potentially points to a split in the FACE table. The UFT and FTI are part of a file address. Together with a record ordinal number, a UFT/FTI combination specifies a file address in the database.

The UFTI parameter on the UFTFTI statement specifies a UFT followed by the FTI size. The FTI size specifies a length, in bits, of FTIs to be coded for a particular UFT. It is not the FTI itself. The UFT/FTI pairs coded on the UFTI parameter are used only for FARF4 and FARF5 addresses. The UFT/FTI pairs coded on the UFTI6 parameter are used only for FARF6 addresses.

For example:

     UFTFTI  UFTI=((3,8),(4,12))

specifies a slice starting at UFT 3 comprising up to 256 (that is, 28) FTIs, and a slice starting at UFT 4 comprising 4096 FTIs.

For example:

     UFTFTI  STAGE=FARF45,MODE=FARF5,
             UFTI=((0,8),(1,12),(2,10),(61,16),(62,14),(63,12),
             (20,23),(21,25)),
             UFTI6=((2,10),(30,15)) 
Note:
FARF6 addresses are dispensed in either FARF34 or FARF45 address mode.

The meaning of the UFTI parameter on this statement is:

The FTI size, in bits, defines the number of valid FTI numbers that can be associated with a particular UFT. In turn, the UFT/FTI combination limits the number of ordinals that can be represented by the combination. Because the number of UFT bits is fixed (at 6 bits for FARF4 and FARF5 and 16 bits for FARF6), once the FTI length is set, the maximum number of ordinals for the record type is also set. The maximum number of ordinals is represented by the remaining bits in FARF5 or FARF6 addresses and by the remaining bits minus 2 additional control bits in FARF4 addresses. While FARF addressing is described in detail in TPF Database Reference, FARF4, FARF5, and FARF6 addresses are distinguished graphically by Figure 23.

Figure 23. FARF4, FARF5, and FARF6 Addresses


Ellipses (...) in the figure represent the variable nature of the FTI.

UFTI pairs can be defined for both FARF4 and FARF5. The UFTI4 and UFTI5 parameters on the RAMFIL statement contain actual UFT,FTI pairs. The following is valid assuming the previous UFTFTI statement:

     RAMFIL TYPE=LSA,RECNO=00014,RECID=#APPOP,DUPE=YES,BAND=1616,
            BASE=00800,UFTI4=(61,20),UFTI5=(61,21)

The UFTI4 parameter states that the FARF4 address for record ID #APPOP has 61 as a UFT and 20 as an FTI. UFT 61 is defined earlier as having a 16 bit FTI, so all FTIs ranging between 0 and 216 -1 (65 535) are valid. The UFTI5 parameter defines a FARF5 address for #APPOP with a UFT of 61 and an FTI of 21. Note that the same UFT can be used for both FARF4 and FARF5 addresses but a UFT/FTI pair can only be used once.

Here is another example:

     UFTFTI UFTI=((10,6),(11,6))
     RAMFIL RECID=#FRED,RECNO=100,BAND=10,UFTI4=(10,1),UFTI5=(11,1)
     RAMFIL RECID=#BILL,RECNO=101,BAND=11,UFTI4=(10,2),UFTI5=(11,2)
     RAMFIL RECID=#EDNA,RECNO=102,BAND=12,UFTI4=(10,3),UFTI5=(11,3)

UFT 10 has an FTI length of 6 bits, so there are 26 (64) FTIs pointed to by UFT 10. The maximum number of ordinals in each slot is as follows:

    32 bits
  - (6 bits UFT length + 6 bits FTI length)
  ---------
    20 bit ordinal number or ordinals < 220 (1 048 
or
  - (2 FARF4 control bits)
  ---------
    18 bit ordinal number or ordinals < 218 (262 144) for F

UFTs and FTIs can be thought of as first and middle names, while ordinals can be considered last names. Every unique record ordinal needs a unique first, middle, and last name.

For example:

     UFTFTI  UFTI=((3,22),(5,21)),MODE=FARF4
     RAMFIL  RECID=#FRED,RECNO=16,UFTI4=((3,1026),(5,24),(3,437)),TYPE=S SA

A series of record ordinals is specified by the following RAMFIL statement. The type of record is #FRED. There are 16 small ordinals on device A. UFTI4 indicates they are FARF4 record ordinals that are divided among 3 UFTI pairs. The first pair (3,1026) is the first and middle name for the first group of four ordinals. The last names for these are 0, 1, 2, and 3. The second group of ordinals is specified by the (5,21) pair. The second group has 3 bits available according to the UFTFTI macro above and this allows 8 ordinals: 0, 1, 2,..., and 7. Finally, the third group has 2 bits, because it is governed by the UFT 3, and so 4 ordinals.

Shown graphically, the 16 ordinals specified by this RAMFIL statement are distributed over 3 UFTI pairs.



              UFT=3|       UFT=5     |   UFT=3
           FTI=1026|      FTI=24     | FTI=437
                   |                 |
  ordinals: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
                   |                 |

Written out, the addresses for the ordinals are:



     #FRED ordinal  0:  3 1026 0
           ordinal  1:  3 1026 1
           ordinal  2:  3 1026 2
           ordinal  3:  3 1026 3 _____
           ordinal  4:  5   24 0
           ordinal  5:  5   24 1
           ordinal  6:  5   24 2
             
·
·
·

·
·
·

·
·
·

·
·
·

·
·
·
ordinal 11: 5 24 7 _____ ordinal 12: 3 437 0 ordinal 13: 3 437 1 ordinal 14: 3 437 2 ordinal 15: 3 437 3

Observe that when a new UFTI pair starts, the ordinal number index in the address begins again at zero.

Thinking about UFTI pairs and ordinal numbers as names helps to clarify how UFTFTIs are structured. Each first and middle name pair specified by the UFTI pairs implies a limited set of ordinal indexes, as shown earlier. Moreover, each first name has a large set of middle names that go with it. As with (3,22), the previous example we have 222 possible middle names. Putting these middle names together with the ordinal index results in a diagram of addresses as follows:



       U   F   O
       F   T   r I
       T   I   d n
               i d
               n e
               a x
               l
       -   -   -
       3   1   0
       3   1   1
       3   1   2
       3   1   3
       3   2   0
       3   2   1
       3   2   2
       3   2   3
       3   3   0
       3   3   1
       3   3   2
       3   3   3
       
·
·
·

·
·
·

·
·
·
3 222 0 3 222 1 3 222 2 3 222 3

You could make a similar diagram for the pair (5,21), with the only exception being the last group of ordinal indexes distinguished by their middle names is as follows:



       U   F   O
       F   T   r I
       T   I   d n
               i d
               n e
               a x
               l
       -   -   -
       :   :   :
       5 221 0
       5 221 1
       5 221 2
       5 221 3
       5 221 4
       5 221 5
       5 221 6
       5 221 7
 

Two Unusual Cases

Choosing appropriate FTI sizes for each UFT during coding of the UFTFTI statement is important. When a large FTI size is chosen, only small ranges of ordinal numbers can be defined for each FTI. Suppose you code the following:

     UFTFTI  STAGE=FARF45,MODE=FARF5,UFTI=(2,25)

The UFT/FTI pairs defined this way only map 2 ordinal numbers each. This is because of the following arithmetic based on the structure of UFT/FTI addresses:

        6 bit UFT (fixed amount)                32 bit address
     + 25 bit FTI (from UFTI parameter)       - 31 bits (UFT + FTI)
      ---                                      ---
       31 bits accounted for (UFT + FTI)         1 bit ordinal numbers

The 2 ordinal numbers are 0 and 1.

Because #FRED is 10 ordinal numbers long, 5 UFT/FTI combinations are required, each containing 2 records. This means that you would have to code:

     RAMFIL RECID=#FRED,RECNO=10,....,UFTI5=((2,0),(2,1),(2,2),(2,3),
                  (2,4))

The UFTI5 definition contains specifications for all the UFT/FTI pairs needed for the 10 records.

Such UFT/FTI combinations are not bad, but you can imagine writing large numbers of combinations for large groups of records using inappropriate UFT/FTI combinations. Mapping a pool type containing a large number of ordinals with a 1-bit area for representing records is extremely difficult, time-consuming and error prone. Moreover, because each FTI takes up about 8 bytes of storage in the online FCTB, resulting in a needlessly large FACE table.

The opposite extreme is:

     UFTFTI STAGE=FARF45,MODE=FARF5,UFTI=(3,1)

and the following RAMFIL:

     RAMFIL RECID=#FRED,RECNO=10,....,UFTI5=(3,0)

This UFTFTI macro provides for 2 UFT/FTI pairs. This means that each UFT/FTI combination maps 25 bits of ordinal, or 33 554 432, records. Obviously, only one UFT/FTI combination is needed to map all 10 ordinals of #FRED. This results in a waste of 225 -10 addresses (33 554 422), because the UFT/FTI combination (3,0) can only be used for a single RAMFIL statement.

A small FTI size is good for mapping pool or fixed record types containing a large number of ordinals. Large FTI sizes are good for mapping pool or fixed record types with a small number of ordinals. By being aware of the record type requirements it is possible to waste very little addressing capacity and yet have a minimal online FACE table size.

If a particular record type requires many ordinals, there must be a sufficiently small FTI to provide the bits required to represent the ordinals. If a record type will only have a few ordinals, the FTI size can be very large and there will still be enough bits to represent the highest ordinal in the record type. There are no performance considerations for laying out UFT/FTI combinations, so the UFT/FTI combinations and record ordinal requirements can be balanced in this way without performance considerations.

Record Duplication

There are two kinds of duplication:

These combine into three kinds of duplicated systems:

The duplicate record in a record type (either pool or fixed) is assigned to the same relative position on an alternate disk module. Therefore, an even number of modules is required.

Device duplication is sometimes referred to as system duplication because customers often run with only 1 device type (DEVA). If more than 1 device type is defined, the duplication on 1 device type can be different from the duplication on another device type. On a fully duplicated device, all records are duplicated no matter how the DUPE parameter is coded on any RAMFIL. This is true for both fixed and pool records.

The partially duplicated database, like a fully duplicated system, requires an even number of modules. However, within a partially duplicated database, nonduplicated long-term pools are supported. In a partially duplicated database:

See Figure 24 for an example. The DUPE parameter on the RAMFIL statement controls whether the record type is duplicated or not.

A nonduplicated database implies a system with no duplicated record types. Records on a nonduplicated device type are never duplicated, no matter how the DUPE parameter is coded on any RAMFIL. This is true for both fixed and pool records.

For fully duplicated and nonduplicated device types, the DUPE parameter is meaningless, except for pools. The DUPE parameter controls the pool type being defined out of the 9 possible pool types. A 4K, long-term, duplicated pool is a different pool from a 4K, long-term, nonduplicated pool type even though both are duplicated in a fully duplicated system.

Address Assignment

After the method of duplication has been selected, the next step is to assign specific disk addresses to the various record types. It is recommended that the file design adhere to the following guidelines:

All disk packs of a logical device type (DEVA, DEVB, and so forth) are formatted the same. Therefore, only the disk layout for 1 module needs to be determined.

File Design Worksheets

Table 14 provides a disk file design worksheet for a partially duplicated file layout (module-to-module duplication). The worksheet represents a single prime module. Duplicate modules require that all duplicate copies of prime records are to be located in the same relative position because they are on the prime modules. All fixed records that are specified as nonduplicated (fixed nonduplicated or fallback) on the prime modules would also be specified as nonduplicated on the duplicate packs but would contain no data. Nonduplicated pools should be spread across all modules, therefore utilizing the space available on the duplicate modules.

Enter the total number of records for each record type and calculate the size of each area (number of tracks per module). The size of each area equals the number of full tracks required for a given area divided by the number of prime modules. Users should be sure to provide spare tracks for future expansion. At least 10 % per record type, where appropriate, is recommended.

Table 14. Module-to-Module Duplication Worksheet

Record Type Duplicate File? Address HEX
CYL HD
Permanent Records1 00 00 00 00
Core Image Restart Area1 00 xx2 00 xx2
4KB Keypoints1



Small Long-Term Pool



Large Long-Term Pool



4KB Long-Term Pool



Large Short-Term Pool



Small Fixed



Small Programs



Large Programs



4KB Programs



Large Fixed



4KB Fixed



Small Short-Term Pool



Large Fixed



Small Long-Term Pool



Large Long-Term Pool



Partially Duplicated Layout Example

Once the disk files are completely defined and the duplication factor is determined, determine the starting address of each area and complete the worksheets. Figure 25 provides example SIP RAMFIL statements for the sample file layout in Table 15. Note that the sample is for a 4-module, selectively duplicated system, and the keys relate to locations in Figure 24.

Table 15. Four-Module 3380 Sample File Layout

Record Description Dupe ? K E Y Total # Records Tracks per Module DISPL Decimal Hex
CYL HD CYL HD
Permanent Records 3 A
1 0 00 00 00 00
Small LT Pool No B 817,260 3,855 25 01 10 01 0A
Large LT Pool No C 114,600 955 3,880 258 10 102 0A
4KB LT Pool No D 16,080 402 4,835 322 05 142 05
Small Fixed No E 3,604 34 5,237 349 02 15D 02
Small LT Pool Yes F 21,200 200 5,271 351 06 15F 06
Large LT Pool Yes G 16,080 268 5,471 364 11 16C 0B
4KB LT Pool Yes H 9,000 450 5,739 382 09 17E 09
Small Fixed Yes I 27,348 258 6,189 412 09 19C 09
Large Fixed Yes J 15,480 258 6,447 429 12 1AD 0C
4KB Fixed Yes K 5,160 258 6,705 447 00 1BF 00
Small Program Yes L 742 7 6,963 464 03 1D0 03
Large Program Yes M 2,040 34 6,970 464 10 1D0 0A
4KB Program Yes N 3,000 150 7,004 466 14 1D2 0E
Large Fixed No O 102,000 1,700 7,154 476 14 1DC 0E
Small ST Pool No P 21,200 100 8,854 590 04 24E 04
Large ST Pool No Q 16,080 134 8,954 596 14 254 0E
4KB ST Pool No R 9,000 225 9,088 605 13 25D 0D
4KB Keypoints 3 S 240 12 9,313 620 13 26C 0D

Figure 24. 3380 Device Sample Layout. This diagram is based on the information contained in Table 15.


Figure 25. Sample Device RAMFIL Macros. Not all parameters are shown (see RAMFIL).


 RAMFIL  RECID=POOL,TYPE=SSA,RECNO=817260,DUPE=NO,POLID=LT,BASE=00110
 RAMFIL  RECID=POOL,TYPE=LSA,RECNO=114600,DUPE=NO,POLID=LT,BASE=25810
 RAMFIL  RECID=POOL,TYPE=4SA,RECNO=16080,DUPE=NO,POLID=LT,BASE=32205
 RAMFIL  RECID=#RID01,TYPE=SSA,RECNO=1802,DUPE=NO,BASE=34902
 RAMFIL  RECID=#RID02,TYPE=SSA,RECNO=1802,DUPE=NO
 RAMFIL  RECID=POOL,TYPE=SSA,RECNO=21200,DUPE=YES,POLID=LT,BASE=35106
 RAMFIL  RECID=POOL,TYPE=LSA,RECNO=16080,DUPE=YES,POLID=LT,BASE=36411
 RAMFIL  RECID=POOL,TYPE=4SA,RECNO=9000,DUPE=YES,POLID=LT,BASE=38209
 RAMFIL  RECID=#RID03,TYPE=SSA,RECNO=20000,DUPE=YES,BASE=41209
 RAMFIL  RECID=#RID04,TYPE=SSA,RECNO=7348,DUPE=YES
 RAMFIL  RECID=#RID05,TYPE=LSA,RECNO=15480,DUPE=YES,BASE=42912
 RAMFIL  RECID=#RID06,TYPE=4SA,RECNO=5160,DUPE=YES,BASE=44700
 RAMFIL  RECID=#XYZZZ,TYPE=SSA,RECNO=742,DUPE=YES,BASE=46403
 RAMFIL  RECID=#XYNLL,TYPE=LSA,RECNO=2040,DUPE=YES,BASE=46410
 RAMFIL  RECID=#MRES4,TYPE=4SA,RECNO=3000,DUPE=YES,BASE=46614
 RAMFIL  RECID=#RID07,TYPE=LSA,RECNO=102000,DUPE=NO,BASE=47614
 RAMFIL  RECID=POOL,TYPE=SSA,RECNO=21200,DUPE=NO,POLID=ST,BASE=59004
 RAMFIL  RECID=POOL,TYPE=LSA,RECNO=16080,DUPE=NO,POLID=ST,BASE=59614
 RAMFIL  RECID=POOL,TYPE=4SA,RECNO=9000,DUPE=NO,POLID=ST,BASE=60513
 RAMFIL  RECID=#KEYPT,TYPE=4SA,RECNO=240,DUPE=NO,BASE=62013

Database configurations containing multiple DASD device types require separate file layouts and separate RAMFIL macros for each device type. The appropriate worksheets provided in this section should be used for each device type included in the system being generated.


Footnotes:

1
For a description see Permanent Record Area.

2
These records may be located anywhere.

3
For a description, see Permanent Record Area.