gtps4m39System Generation

RIATA ID

The RIATA ID macro calls are the second in a series of RIATA calls used to create entries in the record ID attribute table (RIAT).

The RIAT is created by coding a deck of RIATA calls and assembling it. The RIAT deck consists of:

  1. A RIATA START call (see RIATA START)
  2. A series of RIATA ID= calls
  3. A RIATA FINISH call (see RIATA FINISH.

For each of the IDs to be included in the RIAT, the format is as follows:

Format




ID=sd
Any self-defining term, for example:
X'2100'
B'0011000011001100'
C'WW'
2134 (decimal number)

PRIME, OVFL, RTPx
Specify one of the following:

size
Record size:

S
Small block

L
Large block

4
4K block

pool
Pool duration:

ST
Short term

LT
Long term, nonduplicated

LD
Long term, duplicated

D6
Long term, duplicated, FARF6 (the size must be coded as 4)

dev
Logical device:

A
DEVA

B
DEVB

C
DEVC

D
DEVD

R
Ratio dispensing

The default for RTP0 -- RTP9 is NOT IN USE which means the pool cannot be accessed with the GETFC macro.

PRIME and OVFL are for migration purposes only and correspond to RTP0 and RTP1. Therefore, PRIME and RTP0 cannot be coded at the same time, and OVFL and RTP1 cannot be coded at the same time.

UEXIT
Specify one of the following:

NO
A user exit is not to be defined for special processing.

YES
A user exit is to be defined for special processing.

XCP
Specify one of the following:

YES
This record ID is to be exception recorded.

NO
This record ID is not to be exception recorded.

LOG
Specify one of the following:

NO
This record ID is not to be logged.

YES
This record ID is to be logged.

RESTORE
Specify one of the following:

YES
This record ID is to be restored.

NO
This record ID is not to be restored.

Notes:

  1. The intent of RESTORE=NO is to prevent restoration of records with a given record ID by all database utility packages that restore the database. This includes the capture/restore package, the DBR package, and any other packages providing this kind of function. In particular #PROGn and #XPRGn records should specify RESTORE=NO to save time during capture and to maintain any online modifications made subsequent to a capture.

  2. If RESTORE is coded as NO, exception recording and logging can still occur so it is recommended that the LOG and XCP parameters also be coded as NO. Unexpected results can occur if RESTORE is coded as NO and either LOG or XCP are coded as YES.

VFAF
Specify one of the following:

NO
This fixed record ID is not a candidate.

DELAY
This fixed record ID is a candidate for delayed filing.

IMMED
This fixed record ID is a candidate for immediate filing.

SDELAY
This fixed record ID is a virtual file access (VFA) synchronization candidate for delayed filing.

SIMMED
This fixed record ID is a VFA synchronization candidate for immediate filing.

VFAP
Specify one of the following:

NO
This pool record ID is not a candidate.

DELAY
This pool record ID is a candidate for delayed filing.

IMMED
This pool record ID is a candidate for immediate filing.

SDELAY
This pool record ID is a VFA synchronization candidate for delayed filing.

SIMMED
This pool record ID is a VFA synchronization candidate for immediate filing.

LOCKF
Specify one of the following:

DASD
The DASD control unit lock table maintains the lock for this fixed record type.

PROC
The processor's record hold table (RHT) maintains the lock for this fixed record type.

LOCKP
Specify one of the following:

DASD
The DASD control unit lock table maintains the lock for this pool record type.

PROC
The processor's record hold table (RHT) maintains the lock for this pool record type.

RCSF
This parameter specifies which record caching attributes apply to fixed file records with the given record ID. You can specify different options for RCSF and RCSP.

RET
Retentive access -- specifies that the record ID is to be placed on the DASD surface and cache when a file-type macro is issued.

CFWS
Cache fast write access (simplex write) -- specifies that the record ID is to be placed in the volatile control unit cache when a file-type macro is issued and the cache is available. If the cache is not available, the record is written directly to the DASD surface. A single write is issued to the prime module only.

CFWD
Cache fast write access (duplex write) -- specifies that the record ID is to be placed in the volatile control unit cache when a file-type macro is issued and the cache is available. If the cache is not available, the record is written directly to the DASD surface. A duplex write is issued to both the prime and duplicate modules.

DFW
DASD fast write access -- specifies that the record ID is to be placed in the nonvolatile storage cache when a file-type macro is issued and nonvolatile cache is available. If neither the cache nor the nonvolatile storage is available, the record is written directly to the DASD surface.

NO
Bypass cache -- specifies that the record ID is not a candidate for caching. All I/O requests for this ID result in the record being read or written directly from or to the DASD surface, bypassing caching for this record ID.

RCSP
This parameter specifies which record caching attributes apply to pool records with the given record ID. You can specify different options for RCSF and RCSP.

RET
Retentive access -- specifies that the record ID is to be placed on the DASD surface and cache when a file-type macro is issued.

CFWS
Cache fast write access (simplex write) -- specifies that the record ID is to be placed in the volatile control unit cache when a file-type macro is issued and the cache is available. If the cache is not available, the record is written directly to the DASD surface. A single write is issued to the prime module only.

CFWD
Cache fast write access (duplex write) -- specifies that the record ID is to be placed in the volatile control unit cache when a file-type macro is issued and the cache is available. If the cache is not available, the record is written directly to the DASD surface. A duplex write is issued to both the prime and duplicate modules.

DFW
DASD fast write access -- specifies that the record ID is to be placed in the nonvolatile storage cache when a file-type macro is issued and nonvolatile cache is available. If neither the cache nor the nonvolatile storage is available, the record is written directly to the DASD surface.

NO
Bypass cache -- specifies that the record ID is not a candidate for caching. All I/O requests for this ID result in the record being read or written directly from or to the DASD surface, thus bypassing caching for this record ID.

Entry Requirements

The macro must be coded in the sequence described previously, the RIATA START call, followed by RIATA ID calls, followed by a RIATA FINISH call.

Return Conditions

Output consists of either the RIAT table or MNOTEs (see Messages (Online)). If any of the parameters are coded incorrectly, the calls occur in the wrong order or duplicate IDs are coded. Careful understanding of the RIAT and RIATA input is required to properly interpret RIATA output.

Programming Considerations

Examples

RIATA START
RIATA ID=B'0000000100000001',RTP0=(S,ST,A),RTP1=(S,LD,A),   *
      VFAP=IMMED
RIATA ID=X'102',UEXIT=YES,XCP=NO,LOG=YES
RIATA ID=5008
RIATA ID=C'AA',RTP5=(4,LD,A),RTP8=(4,LT,A),VFAP=DELAY
RIATA ID=X'C1C3',VFAF=IMMED,VFAP=IMMED
RIATA ID=C'TC',VFAF=IMMED,VFAP=IMMED,RCSF=CFWD,RCSP=DFW
RIATA FINISH

References