gtpd1m33 | Database Reference |
The CFVCTC macro allows you to perform the following functions on a list notification vector associated with a CF list structure:
When you issue the CFVCTC macro, you identify the list notification vector using the vector token returned in the CFCONC answer area (mapped by the ICFCAAVECTOK field of the CFCONC macro) when you issued the CFCONC macro to connect to the CF list structure. You receive a vector token from the CFCONC macro only if you coded the VECTORLEN parameter.
Coding REQUEST=MODIFYVECTORSIZE on the CFVCTC macro allows you to change the number of entries in the list notification vector so that you can monitor a different number of lists in the CF list structure.
Reducing the size of the list notification vector when it is larger than necessary frees storage for the list notification vectors of other users in the TPF system. Use the VECTORLEN parameter to indicate the new number of entries you would like the list notification vector to contain. If the value you specify is not a multiple of 32, the TPF system rounds up the value to a multiple of 32.
The number of entries the TPF system actually assigns to the list notification vector is returned to you as output through the ACTUALVECLEN parameter.
If you request a decrease in the number of entries in the list notification vector, your request will always be satisfied. When the size of a list notification vector is decreased, the number of entries is reduced by removing entries starting with the highest number. The remaining entries are unchanged and retain their original values (empty state or nonempty state).
Before eliminating any entries, you must ensure that the entries that will be deleted are not being used to monitor lists.
If multiple TPF systems could be accessing list notification vector entries at the same time, you should obtain exclusive serialized access to the list notification vector before decreasing its size. Otherwise, if you code REQUEST=LTVECENTRIES or REQUEST=TESTLISTSTATE must be prepared to handle the ICFRRCINVALIDINDEX return code, which indicates that the specified vector index is no longer valid.
If you request an increase in the number of entries in the list notification vector and the TPF system is unable to obtain enough storage to satisfy your request, the new number of entries may be unchanged or smaller than you requested. When this occurs, the number of entries returned through the ACTUALVECLEN parameter will be smaller than the requested number and you will receive the ICFRRCLESSTHAN return code to inform you of the result.
When the size of the list notification vector is increased, the number of entries is increased by adding additional entries after the current highest-numbered entry. Existing entries are unchanged and retain their original values (empty state or nonempty state). New entries are initialized to the nonempty state.
Coding REQUEST=TESTLISTSTATE on the CFVCTC macro allows you to test the entry representing a particular list to determine whether that list is empty. List notification vector updates are performed asynchronously by the TPF system, so a list notification vector entry may not show a particular list state change at the time you check it. However, the CF architecture ensures that the change in the list notification vector will be performed. The CF architecture also ensures that if the list transitions from an empty state to a nonempty state and then back to an empty state and so on multiple times, the final state reflected in the vector will match the final state of the list. However, individual transitions may not be applied to the vector if they are superseded by subsequent changes. For example, if the initial state of the list notification vector entry indicates that the list is empty and then the list transitions to a nonempty state and becomes empty again in a short period of time, the TPF system does not ensure that the interim nonempty state will be reflected in the vector. However, the TPF system ensures that the final state (an empty state, in this example) is correct.
Coding REQUEST=LTVECENTRIES on the CFVCTC macro allows you to test as many as 32 consecutive list notification vector entries to determine whether their associated lists are empty. The output from this request is a bit string with 1 bit for each list notification vector entry, starting with the vector entry you specify as the starting vector entry number and continuing until 32 bits are loaded. List notification vector entries range from 0 to n-1, where n is the number of entries in the list notification vector.
The bit values in the bit string are interpreted as follows: