gtps4m1a | System Generation |
There are four considerations when allocating DASD space for the database.
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).
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.
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:
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))
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 |
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 |
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 |
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.
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.
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.
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 |
|
|
|
|
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.