Document revision date: 30 March 2001

## OpenVMS Record Management Services Reference Manual

Previous | Contents | Index

## $RAB

> The $RAB macro allocates storage for a RAB and initializes certain RAB fields with defaults and user-specified values. You cannot use this macro within a sequence of executable instructions. No value is returned for this assembly-time operation.

### Format

> $RAB BKT=bucket-code-number,

> CTX =user-context-value,
> FAB =fab-address,
> KBF =key-buffer-address,
> KRF =key-of-reference-number,
> KSZ =key-size,
> MBC =multiblock-count-number,
> MBF =multibuffer-count-number,
> PBF =prompt-buffer-address,
> PSZ =prompt-buffer-size,
> RAC ={KEY|RFA|SEQ},
> RBF =record-buffer-address,
> RHB =record-header-buffer-address,
> ROP =<ASY BIO CCO CDK CVT EOF EQNXT ETO FDL KGE KGT LIM LOA LOC NLK NXR NXT PMT PTA RAH REA REV RLK RNE RNF RRL TMO TPT UIF ULK WAT WBH>,
> ROP _2=<NQL NODLCKWT NODLCKBLK>,
> RSZ =record-size,
> TMO =time-out-number-of-seconds,
> UBF =user-record-buffer-address,
> USZ =user-record-buffer-size,
> XAB =xab-address

### Arguments

> For a description of the control block fields that correspond to the $RAB macro arguments, see Chapter 7. In some cases, specific default values are assigned automatically when you omit an argument. These specific defaults are noted in the text that explains each field in Chapter 7. If there is no specific default, RMS uses a default value of 0.

> Arguments fall into three categories: values, addresses, and keywords. Rules applicable to these argument categories are described in Appendix B.

> Note that multiple arguments can be specified for the ROP keyword, but the arguments must be enclosed within left angle (<) and right angle (>) brackets. Also note that the KGE and EQNXT arguments are logically synonymous, as are the KGT and NXT arguments.

## $RAB_STORE

> The $RAB_STORE macro moves user-specified values into fields of the specified RAB. The expanded $RAB_STORE code executes at run time on a previously initialized (allocated) RAB, in contrast to the $RAB macro, which allocates and initializes the RAB at assembly time. The $RAB_STORE macro must reside in a code program section.

### Format

> $RAB_STORE RAB=rab-address,

> BKT =#bucket-code-number,
> CTX =user-context-value,
> FAB =fab-address,
> KBF =key-buffer-address,
> KRF =#key-of-reference-number,
> KSZ =#key-size,
> MBC =#multiblock-count-number,
> MBF =#multibuffer-count-number,
> PBF =prompt-buffer-address,
> PSZ =#prompt-buffer-size,
> RAC ={KEY|RFA|SEQ},
> RBF =record-buffer-address,
> RFA =#record-file-address,
> RHB =record-header-buffer-address,
> ROP =<ASY BIO CCO CDK CVT EOF EQNXT ETO FDL KGE KGT LIM LOA LOC NLK NXR NXT PMT PTA RAH REA REV RLK RNE RNF RRL TMO TPT UIF ULK WAT WBH>,
> ROP _2=<NQL NODLCKWT NODLCKBLK>,
> RSZ =#record-size,
> TMO =#time-out-number-of-seconds,
> UBF =user-record-buffer-address,
> USZ =#user-record-buffer-size,
> XAB =xab-address

### Arguments

> For a description of the control block fields that correspond to the $RAB_STORE macro arguments, see Chapter 7.

> Arguments fall into many categories: values, addresses, keywords, and the address of the control block to receive the specified arguments. Rules applicable to these argument categories for the control block store macros are described in Appendix B.

> The RAB argument rab-address is required for the $RAB_STORE macro and is not present for the $RAB macro.

> The RFA argument record-file-address is a value (not an address), and it is not available for the $RAB macro. The value for the 3-word RAB$W_RFA field must be set before each RFA record access. This argument is specified by its symbolic address. If a register is used to contain a value for the RAB$W_RFA field, do not use R12, because two contiguous registers must be used to contain the value of this 3-word field. Note that you cannot use the byte, word, or longword displacements for an offset, or for indexed or deferred addressing.

> Note that multiple arguments can be specified for the ROP keyword, but the arguments must be enclosed within left angle (<) and right angle (>) brackets. Also note that the KGE and EQNXT arguments are logically synonymous, as are the KGT and NXT arguments.

> Note that R0 is usually used by the $RAB_STORE macro; thus, R0 is not preserved and does not contain a return status.

## $RAB64 (Alpha Only)

> On Alpha systems, the $RAB64 macro allocates storage for a RAB64 and initializes certain RAB64 fields with defaults and user-specified values. You cannot use this macro within a sequence of executable instructions. No value is returned for this assembly-time operation.

> The defaults unique to $RAB64 are as follows:

> - RAB64$B_BLN is initialized to RAB64$C_BLN64.
> - The original longword I/O buffers (KBF, RHB, RBF, and UBF) are initialized to -1 ; USZ and RSZ word sizes are initialized to 0.

> User-specified values using the CTX, KBF, RHB, RBF, RSZ, UBF, or USZ keywords are moved into the quadword fields for these keywords. In contrast, the $RAB macro moves them into the longword (or word) fields for these keywords.

### Format

> $RAB64 BKT=bucket-code-number,

> CTX =user-context-value,
> FAB =fab-address,
> KBF =key-buffer-address,
> KRF =key-of-reference-number,
> KSZ =key-size,
> MBC =multiblock-count-number,
> MBF =multibuffer-count-number,
> PBF =prompt-buffer-address,
> PSZ =prompt-buffer-size,
> RAC ={KEY|RFA|SEQ},
> RBF =record-buffer-address,
> RHB =record-header-buffer-address,
> ROP =<ASY BIO CCO CDK CVT EOF EQNXT ETO FDL KGE KGT LIM LOA LOC NLK NXR NXT PMT PTA RAH REA REV RLK RNE RNF RRL TMO TPT UIF ULK WAT WBH>,
> ROP _2=<NQL NODLCKWT NODLCKBLK>,
> RSZ =record-size,
> TMO =time-out-number-of-seconds,
> UBF =user-record-buffer-address,
> USZ =user-record-buffer-size,
> XAB =xab-address

### Arguments

> For a description of the control block fields that correspond to the $RAB64 macro arguments, see Chapter 8. In some cases, specific default values are assigned automatically when you omit an argument. These specific defaults are described above or noted in the text that explains each field in Chapter 8. If there is no specific default, RMS uses a default value of 0.

> Arguments fall into three categories: values, addresses, and keywords. Rules applicable to these argument categories are described in Appendix B.

> Note that multiple arguments can be specified for the ROP keyword, but the arguments must be enclosed within left angle (<) and right angle (>) brackets. Also note that the KGE and EQNXT arguments are logically synonymous, as are the KGT and NXT arguments.

## $RAB64_STORE (Alpha Only)

> On Alpha systems, the $RAB64_STORE macro moves user-specified values into fields of the specified RAB64. The expanded $RAB64_STORE code executes at run time on a previously initialized (allocated) RAB64. In contrast, the $RAB64 macro allocates and initializes the RAB64 at assembly time. The $RAB64_STORE macro must reside in a code program section.

> User-specified values that use the CTX, KBF, RHB, RBF, RSZ, UBF, or USZ keywords are moved into the quadword fields for these keywords. In contrast, the $RAB_STORE macro moves them into the longword (or word) fields for these keywords.

### Format

> $RAB64_STORE RAB=rab64-address,

> BKT =#bucket-code-number,
> CTX =user-context-value,
> FAB =fab-address,
> KBF =key-buffer-address,
> KRF =#key-of-reference-number,
> KSZ =#key-size,
> MBC =#multiblock-count-number,
> MBF =#multibuffer-count-number,
> PBF =prompt-buffer-address,
> PSZ =#prompt-buffer-size,
> RAC ={KEY|RFA|SEQ},
> RBF =record-buffer-address,
> RFA =#record-file-address,
> RHB =record-header-buffer-address,
> ROP =<ASY BIO CCO CDK CVT EOF EQNXT ETO FDL KGE KGT LIM LOA LOC NLK NXR NXT PMT PTA RAH REA REV RLK RNE RNF RRL TMO TPT UIF ULK WAT WBH>,
> ROP _2=<NQL NODLCKWT NODLCKBLK>,
> RSZ =#record-size,
> TMO =#time-out-number-of-seconds,
> UBF =user-record-buffer-address,
> USZ =#user-record-buffer-size,
> XAB =xab-address

### Arguments

> For a description of the control block fields that correspond to the $RAB64_STORE macro arguments, see Chapter 8.

> Arguments fall into many categories: values, addresses, keywords, and the address of the control block to receive the specified arguments. Rules applicable to these argument categories for the control block store macros are described in Appendix B.

> The RAB argument rab64-address is required for the $RAB64_STORE macro and is not present for the $RAB64 macro.

> The RFA argument record-file-address is a value (not an address), and it is not available for the $RAB64 macro. The value for the 3-word RAB64$W_RFA field must be set before each RFA record access. This argument is specified by its symbolic address. If a register is used to contain a value for the RAB64$W_RFA field, do not use R12, because two contiguous registers must be used to contain the value of this 3-word field. Note that you cannot use the byte, word, or longword displacements for an offset, or for indexed or deferred addressing.

> Note that multiple arguments can be specified for the ROP keyword, but the arguments must be enclosed within left angle (<) and right angle (>) brackets. Also note that the KGE and EQNXT arguments are logically synonymous, as are the KGT and NXT arguments.

> Note that R0 is usually used by the $RAB64_STORE macro; thus, R0 is not preserved and does not contain a return status.

## $XABALL

> The $XABALL macro allocates and initializes a XABALL, which allows extended control of file disk space allocation, both for initial allocation and later extension. No value is returned for this assembly-time operation.

### Format

> $XABALL AID=area-identification-number,

> ALN ={ANY|CYL|LBN|RFI|VBN},
> ALQ =allocation-quantity,
> AOP =<CBT CTG HRD ONC>,
> BKZ =bucket-size,
> DEQ =extension-quantity,
> LOC =location-number,
> NXT =next-xab-address,
> RFI =<f(1), f(2), f(3)>,
> VOL =volume-number

### Arguments

> For a description of the control block fields that correspond to the $XABALL macro arguments, see Chapter 9.

> Arguments fall into three categories: values, addresses, and keywords. Rules applicable to these argument categories are described in Appendix B.

> Note that multiple arguments can be specified for the AOP keyword, but the arguments must be enclosed within left angle (<) and right angle (>) brackets.

## $XABALL_STORE

> The $XABALL_STORE macro moves user-specified values into fields of the specified XABALL. The expanded $XABALL_STORE code executes at run time on a previously initialized (allocated) XABALL, in contrast to the $XABALL macro, which initializes a XABALL at assembly time. The $XABALL_STORE macro must reside in a code program section.

### Format

> $XABALL_STORE XAB=xaball-address,

> AID =#area-identification-number,
> ALN ={ANY|CYL|LBN|RFI|VBN},
> ALQ =#allocation-quantity,
> AOP =<CBT CTG HRD ONC>,
> BKZ =#bucket-size,
> DEQ =#extension-quantity,
> LOC =#location-number,
> NXT =next-xab-address,
> RFI =#related-file-identification,
> VOL =#volume-number

### Arguments

> For a description of the control block fields that correspond to the $XABALL_STORE macro arguments, see Chapter 9.

> Arguments fall into several categories: value, address, keyword, and the address of the control block to receive the specified arguments. Rules applicable to these argument categories for the control block store macros are described in Appendix B.

> The XAB argument xaball-address is required for the $XABALL_STORE macro and is not present for the $XABALL macro. Also, the RFI argument related file identification sets the XAB$W_RFI field, which is a 3-word field used when the XAB$B_ALN field XAB$V_RFI option is set. This argument is usually specified by its symbolic address. If a register is used to contain a value for the XAB$W_RFI field, do not use R12, because two contiguous registers must be used to contain the value of this 3-word field. Note that you cannot use the byte, word, or longword displacements for an offset, or for indexed or deferred addressing.

> Note that R0 is usually used by the $XABALL_STORE macro; thus, R0 is not preserved and does not contain a return status.

## $XABDAT

> The $XABDAT macro allocates and initializes a XABDAT. No value is returned for this assembly-time operation.

### Format

> $XABDAT EDT=date-time,

> NXT =next-xab-address

### Arguments

> For a description of the control block fields that correspond to the $XABDAT macro arguments, see Chapter 9.

> Rules applicable to arguments are described in Appendix B.

## $XABDAT_STORE

> The $XABDAT_STORE macro moves user-specified values into fields of the specified XABDAT. The expanded $XABDAT_STORE code executes at run time on a previously initialized (allocated) XABDAT, in contrast to the $XABDAT macro, which initializes a XABDAT at assembly time. The $XABDAT_STORE macro must reside in a code program section.

### Format

> $XABDAT_STORE XAB=xabdat-address,

> CDT =#creation-date-time,
> EDT =#expiration-date-time,
> RDT =#revision-date-time,
> RVN =#revision-number,
> NXT =next-xab-address

### Arguments

> For a description of the control block fields that correspond to the $XABDAT_STORE macro arguments, see Chapter 9.

> Arguments fall into several categories: values, addresses, keywords, and the address of the control block to receive the specified arguments. Rules applicable to these argument categories for the control block store macros are described in Appendix B.

> The XAB argument xabdat-address is required for the $XABDAT_STORE macro and is not present for the $XABDAT macro. Also, the arguments differ from the general rules.

> - The CDT argument creation-date-time sets the XAB$Q_CDT field, which is a quadword field. However, if a register is used to contain a literal value for the XAB$Q_CDT field, do not use R12, because two contiguous registers must be used to contain the value of this quadword field.
> - The EDT argument expiration-date-time sets the XAB$Q_EDT field, which is a quadword field. The rules for the other time fields also apply to this one.
> - The RDT argument revision-date-time sets the XAB$Q_CDT field, which is a quadword field. The rules for the other time fields also apply to this one.

> Note that R0 is usually used by the $XABDAT_STORE macro; thus, R0 is not preserved and does not contain a return status.

## $XABFHC

> The $XABFHC macro allocates and initializes a XABFHC. No value is returned for this assembly-time operation.

### Format

> $XABFHC NXT=next-xab-address

### Arguments

> For a description of the control block fields that correspond to the $XABFHC macro arguments, see Chapter 11.

> Rules applicable to arguments are described in Appendix B.

## $XABFHC_STORE

> The $XABFHC_STORE macro moves user-specified values into fields of the specified XABFHC. The expanded $XABFHC_STORE code executes at run time on a previously initialized (allocated) XABFHC, in contrast to the $XABFHC macro, which initializes a XABFHC at assembly time. The $XABFHC_STORE macro must reside in a code program section.

### Format

> $XABFHC_STORE XAB=xabfhc-address,

> NXT =next-xab-address

### Arguments

> For a description of the control block fields that correspond to the $XABFHC_STORE macro arguments, see Chapter 11.

> Arguments fall into several categories: values, addresses, keywords, and the address of the control block to receive the specified arguments. Rules applicable to these argument categories for the control block store macros are described in Appendix B.

> The XAB argument xabfhc-address is required for the $XABFHC_STORE macro and is not present for the $XABFHC macro.

> Note that R0 may be used by the $XABFHC_STORE macro; thus, R0 is not preserved and does not contain a return status.

## $XABITM

> The $XABITM macro allocates and initializes a XABITM. No value is returned for this assembly-time operation.

### Format

> $XABITM ITEMLIST=item-list-address,

> MODE ={sensemode|setmode},
> NXT =next-xab-address

### Arguments

> For a description of the control block fields that correspond to the $XABITM macro arguments, see Chapter 12.

> Rules applicable to arguments are described in Appendix B.

> ITEMLIST defaults to 0 but a valid pointer must be specified when you use a $XABITM macro. MODE defaults to sensemode.

## $XABKEY

> The $XABKEY macro allocates and initializes a XABKEY. No value is returned for this assembly-time operation.

### Format

> $XABKEY COLTBL=collating-table-address,

> DAN =data-bucket-area-number,
> DFL =data-bucket-fill-size,
> DTP ={BN2|DBN2|BN4|DBN4|BN8|DBN8|IN2 |DIN2|IN4|DIN4|IN8|DIN8|COL|DCOL |PAC|DPAC|STG|DSTG},
> FLG =<CHG DAT_NCMPR DUP IDX_NCMPR KEY_NCMPR NUL>,
> IAN =index-bucket-area-number,
> IFL =index-bucket-file-size,
> KNM =key-name-buffer-address,
> LAN =lowest-level-index-area-number,
> NUL =null-key-value,
> NXT =next-xab-address,
> POS =<position,...>,
> PROLOG =prolog-level,
> REF =key-of-reference-value,
> SIZ =<size,...>

### Arguments

> For a description of the control block fields that correspond to the $XABKEY macro arguments, see Chapter 14.

> Arguments fall into three categories: values, addresses, and keywords. Rules applicable to these argument categories are described in Appendix B.

> Multiple arguments can be specified for the FLG keyword, but the arguments must be enclosed within left angle (<) and right angle (>) brackets. Defaults are applied to the XAB$B_FLG field only if no FLG argument is specified. Consider the following:

>     KEY_1:  $XABKEY REF=1, POS=0, SIZ=10

> This line specifies the key for alternate index 1. Therefore the macro defaults the XAB$B_FLG field to allow duplicates and changes (the default for alternate keys). However, if an FLG argument is explicitly specified, the results are different, as shown in the following code example.

>     KEY_2:  $XABKEY REF=1, POS=0, SIZ=10, FLG=CHG

> In this case, the CHG bit is set in the XAB$B_FLG field and the DUP bit remains clear, to disallow duplicates on this key.

> Depending on whether the key being defined is simple or segmented, you would use one of the following two formats for the POS and SIZ arguments:

>     POS=position
>        .
>        .
>        .
>     SIZ=size

> or

>     POS=<position0,...,position7>
>        .
>        .
>        .
>     SIZ=<size0,...,size7>

> You must include the angle brackets for multiple argument key positions and sizes.

## $XABKEY_STORE

> The $XABKEY_STORE macro moves user-specified values into fields of the specified XABKEY. The expanded $XABKEY_STORE code executes at run time on a previously initialized (allocated) XABKEY, in contrast to the $XABKEY macro, which initializes the XABKEY at assembly time. The $XABKEY_STORE macro must reside in a code program section.

### Format

> $XABKEY_STORE XAB=xabkey-address,

> COLTBL =#collating-table-address,
> DAN =#data-bucket-area-number,
> DFL =#data-bucket-fill-size,
> DTP ={BN2|DBN2|BN4|DBN4|BN8|DBN8|IN2 |DIN2|IN4|DIN4|IN8|DIN8|COL|DCOL |PAC|DPAC|STG|DSTG},
> FLG =<CHG DAT_NCMPR DUP IDX_NCMPR KEY_NCMPR NUL>,
> IAN =#index-bucket-area-number,
> IFL =#index-bucket-fill-size,
> KNM =key-name-buffer-address,
> LAN =#lowest-level-index-area-number,
> NUL =#null-key-value,
> NXT =next-xab-address,
> POS =<position,...>,
> PROLOG =#prolog-level,
> REF =#key-of-reference-value,
> SIZ =<size,...>

### Arguments

> For a description of the control block fields that correspond to the $XABKEY_STORE macro arguments, see Chapter 14.

> Arguments fall into several categories: values, addresses, keywords, and the address of the control block to receive the specified arguments. Rules applicable to these argument categories for the control block store macros are described in Appendix B.

> The XAB argument xabkey-address is required for the $XABKEY_STORE macro and is not present for the $XABKEY macro. The POS and SIZ arguments can be either symbolic addresses or a list of up to eight values, where each value must be preceded by a number sign (#), and the entire list must be enclosed within left angle and right angle brackets (<#value,...,#value>). The number of POS and SIZ values must be equal. Alternatively, each POS and SIZ value can be specified as an argument, using the following form:

> `POS0 = #value, POS1 = #value, ..., POS7 = #value`

> `SIZ0 = #value, SIZ1 = #value, ..., SIZ7 = #value`

> Note that R0 is usually used by the $XABKEY_STORE macro; thus, R0 is not preserved and does not contain a return status.

Previous | Next | Contents | Index

| privacy and legal statement |
4523PRO_036.HTML