The RTAS function ibm,get-indices is used to obtain the indices and location codes for a specified indicator or sensor token. It allows for obtaining the list of indicators and sensors dynamically and therefore assists in any Dynamic Reconfiguration operation that involves indicators and sensors being added or deleted from the platform (unlike the /rtas node “<vendor>,indicator-<token>”, “<vendor>,sensor-<token>”, and “ibm,environmental-sensor” properties). This call also allows discontiguous indices for a particular indicator or sensor type (unlike the “rtas-indicators”, “rtas-sensors”, and “ibm,environmental-sensor” properties). This RTAS call is not used for DR indicators (9001, 9002, and 9003) or DR sensors (9003). See the following sections in the DR chapter for more information: and . It may require several calls to the ibm,get-indices RTAS routine to get the entire list of indicators or sensors of a particular type. Each call may specify a different work area. The OS may not interleave calls to ibm,get-indices for different indicator or sensor types. Other standard RTAS locking rules apply. R1--1. For all DR options: The RTAS function ibm,get-indices must implement the argument call buffer defined by . Parameter Type Name Values In Token Token for ibm,get-indices Number Inputs 5 Number Outputs 2 Indicator or Sensor 0: indicator of given type 1: sensor of given type Indicator Type Indicator or sensor type (for example, 9006, 9007) Work Area Address Address of work area Work Area Size Size of work area Starting Number Integer representing first indicator number to return Out Status -1: Hardware error -3: Indicator type not supported -4: Optional: Indicator list changed, start again 0: Success 1: More data available; call again 990x:Extended Delay where x is a number 0-5 (see text below) Next Starting Number Integer to use as the Starting Number parameter on the next call, or 1 if no more calls are required When the 990x Status is returned, it is suggested that software delay for 10 raised to the x milliseconds (where x is the last digit of the 990x return code), before calling ibm,get-indices with the same Starting Number and Indicator Type. However, software may issue the ibm,get-indices call again either earlier or later than this. R1--2. The OS must not interleave calls to ibm,get-indices for different indicator or sensor types. R1--3. On the first call to get a particular Indicator Type, the caller must provide a Starting Number of 1 (32-bit integer) R1--4. When ibm,get-indices is called with a Starting Number of 1, firmware must refresh any stale data in previously cached firmware buffers for that indicator (for example, data made stale by a Dynamic Reconfiguration operation). R1--5. When calling ibm,get-indices with a Starting Number of 1, a previously returned Next Starting Number value must be discarded. R1--6. Optionally, if firmware detects a change in the indicator list before the entire list is returned, the ibm,get-indices call must return a -4 and the caller must start again with a Starting Number of 1. R1--7. The return data format in the work area for all sensors and indicators must be as follows: Number Returned: 32-bit integer representing the number of indicator indices returned on this call Sets of (32-bit integer index, 32-bit integer length of location code including NULLs, location code string (NULL terminated and padded to nearest 4 byte boundary)), one set per indicator or sensor, with the number of sets indicated by the first integer in this work buffer R1--8. If the Status returned is 1 (more data available, call again), then the caller must call ibm,get-indices again with the Starting Number parameter set to the Next Starting Number integer from the previously returned buffer. R1--9. The ibm,get-indices RTAS call must return the Status value of -3 for the following conditions: Indicator type not supported No indicators of specified Indicator Type available to caller R1--10. If the ibm,get-indices RTAS call returns a Status of anything other than 0 or 1 is returned, the caller must consider that the contents of the work area is not defined. R1--11. The work area specified in the ibm,get-indices RTAS call argument buffer must be contiguous in logical real memory and must reside below 4GB. R1--12. The ibm,get-indices RTAS call must only return the indicator or sensor indices to which the caller has authorized access at the time of the call. R1--13. The ibm,get-indices RTAS call must make no assumptions about the contents of the work area on the beginning of the call. R1--14. When the platform supports the ibm,get-indices RTAS call, the device tree must include the “ibm,get-indicator-indices-types” property in the /rtas node if the call is to be used for getting indicator information and must include the “ibm,get-sensor-indices-types” property in the /rtas node if the call is to be used for getting sensor information. R1--15. When an indicator token is provided in the “ibm,get-indicator-indices-types” property, it must not be included in the “<vendor>,indicator-<token>” property and must not be included in the “rtas-indicators” property. R1--16. When a sensor token is provided in the “ibm,get-sensor-indices-types” property, it must not be included in the “<vendor>,sensor-<token>” property and must not be included in the “rtas-sensors” property. R1--17. When an environmental sensor token is provided in the “ibm,get-sensor-indices-types” property, users of data in the “ibm,environmental-sensors” property for that sensor token must not assume that the indices are contiguous for that sensor token (that is, any of the indices between 0 and the maxindex, inclusive, may be missing). R1--18. When the value of any index returned is 0xFFFFFFFF, the OS must use the ibm,get-dynamic-sensor-state and ibm,set-dynamic-indicator RTAS functions for this sensor or indicator, using the location code to identify the sensor or indicator. R1--19. The OS must not call get-sensor-state or get-indicator with an index value of 0xFFFFFFFF.