To obtain a unique sender or receiver ID, use request code 60. This is useful when establishing a bidirectional conversation with another program. The other program can be a globally known program, with a known ID. However, this program cannot use a reserved, unique ID. In this case it can use this service to obtain a valid, unique ID.
This service is only supported by this product's implementation of PPI (known as SOLVE PPI).
The following RPB fields must be set up before the call:
|
Bytes |
Field Name |
Set to... |
|
00-03 |
RPLEN |
56 |
|
04-05 |
REQUEST |
24 |
|
12-15 |
WORKADDR |
address of 128 byte work area |
The following RPB Fields are returned after the call:
|
Bytes |
Field Name |
Set to... |
|
08-11 |
RETCODE |
see below |
|
24-31 |
RECVERID |
the returned unique ID |
The following return codes are possible:
Request completed successfully-a unique ID has been allocated
Invalid function (not the SOLVE PPI)
The requestor is not in primary addressing mode
PPI is not active
PPI requests are not supported
A processing error has occurred- this also indicates that no more unique IDs are available
The returned ID is in the format: pppp&nnn where pppp is the 1 to 4 character PPI name prefix, as set by one of the PPI SSI JCL parameters. If less than 4 characters, it is padded to 4 characters with ampersand (&) characters. Position 5 is always an ampersand. Positions 6 to 8 are allocated from the characters: 0-9, A-Z, @, #, $, and %. This allows up to 64000 unique IDs.
Unique IDs can be re-used. If an ID is obtained, defined, and then inactivated, and nothing is queued to it, then, subject to the PPIINATO and PPIREUSE SSI startup parameter values, the ID can be made available for later reuse.
If the PPI prefix is set to the same value as the product's associated domain ID, then these IDs are also unique across the connected network.