3.1.4.2.48 ApiGetGroupId (Opnum 47)

(Protocol Version 3) The ApiGetGroupId method returns the unique ID of the designated group.

The server SHOULD accept an ApiGetGroupId request if its protocol server state is read-only, and MUST accept the request for processing if it is in the read/write state, as specified in section 3.1.1.

The server SHOULD accept an ApiGetGroupId request if the access level associated with the hGroup context handle is at least "Read" (section 3.1.4).

 error_status_t ApiGetGroupId(
   [in] HGROUP_RPC hGroup,
   [out, string] LPWSTR *pGuid,
   [out] error_status_t *rpc_status
 );

hGroup: An HGROUP_RPC context handle that was obtained in a previous ApiOpenGroup, ApiOpenGroupEx, or ApiCreateGroup method call.

pGuid: The address of a pointer that receives a pointer to a Unicode string buffer where the server MUST return the unique ID of the group after successful completion of this method. The server MUST allocate as much memory as is required to return the ID. If the method fails, this parameter MUST be ignored.<79>

rpc_status: A 32-bit integer used to indicate success or failure. The RPC runtime MUST indicate, by writing to this parameter, whether it succeeded in executing this method on the server. The encoding of the value passed in this parameter MUST conform to encoding for  comm_status and fault_status, as specified in Appendix E of [C706].

Return Values: The method MUST return the following error codes for the specified conditions.

Return value/code

Description

0x00000000

ERROR_SUCCESS

Success.

0x00000006

ERROR_INVALID_HANDLE

The hGroup parameter does not represent a valid HGROUP_RPC context handle.

0x00001394

ERROR_GROUP_NOT_AVAILABLE

The group represented by the hGroup parameter no longer exists in the non-volatile cluster state.

For any other condition, this method MUST return a value that is not one of the values listed in the preceding table. The client MUST behave in one consistent, identical manner for all values that are not listed in the preceding table. The client SHOULD treat errors specified in 3.2.4.6 as recoverable errors and initiate the reconnect procedure as specified in section 3.2.4.6.