As users, you must create an input file known as the local configuration definition file. This input file must be made up of individual lines that comply with the following syntax:
A line begins with an SVCU or BUFFER statement and specifies precisely one service or one subtype (=typed buffer).
Two operands are separated by a comma.
A statement is concluded by a semicolon (‘;’).
If the statement occupies more than one line, the continuation character ‘\’ (backslash) must appear at the end of each line.
A comment line begins with the ‘#’ character.
Blank lines can be inserted, e.g. to improve legibility.
Using the xatmigen
tool, you create the actual local configuration file ("The xatmigen tool") from the file which contains the local configuration definition.
The SVCU and BUFFER statements are described below.
SVCU statement: Define available service
In an SVCU statement, the characteristics required to call a service in the partner application are described for the client.
The SVCU statement can be omitted, if a default server is declared in the side information file of UPIC (upicfile
) with transaction-code = remote-service-name = internal-service-name.
Default-Server:
To simplify the client/server configuration openUTM client allows you to declare a default server using the statement DEST=.DEFAULT in the SVCU statement of the local configuration file.
If the calls tpcall, tpacall
or tpconnect
use a service svcname2 to which there is no SVCU entry in the local configuration file, the following entry is used automatically:
SVCU svcname2, RSN=svcname2, TAC=SCVname2, DEST=.DEFAULT, MODE=RR
In this case UPIC expects a suitable default server entry in the upicfile
, i.e.
LN.DEFAULT localname SD.DEFAULT servername ND.DEFAULT servername
Furthermore you are allowed to call a service svcname2@BRANCH9
using DEST=BRANCH9
without entering a declaration in the local configuration file. In such a case the following entry is assumed:
SVCU svcname2, RSN=svcname2, TAC=SCVname2, DEST=BRANCH9, MODE=RR
The partner, in this case BRANCH9, must be known to UPIC.
However, if the local configuration file contains an entry svcname2@BRANCH9
, this entry will be used.
Operator | Operand | Explanation |
|
| maximum 16 bytes |
| default: internal-service-name | |
| default: internal-service-name | |
| partner application | |
| RR=request/response, default CV=conversation | |
| default: no subtype |
internal-service-name
A name of up to 16 bytes under which a (remote) service can be addressed in the program. This name must be unique within the application, i.e. it can only appear once in the LCF.
Mandatory operand!
RSN=remote-service-name
A name of up to 16 bytes of a service in the remote application. This name is passed to the remote application (TPSVCINFO structure); it can appear repeatedly in the LCF.
If this operand is omitted, xatmigen
sets RSN=internal-service-name.
TAC=transaction-code
A transaction code of up to 8 bytes with which the service must be configured in the remote application.
If this operand is omitted, xatmigen
sets TAC=internal-service-name and, if necessary, truncates this to the first 8 bytes.
The transaction code KDCRECVR can be used to define a recovery service that sends the last output message of UTM to the client.
DEST=destination-name / .DEFAULT
A partner application identification of up to 8 bytes.
This name must be specified in the upicfile
as the symbolic destination name (see "Configuring UPIC").
.DEFAULT
A default server is used.
Mandatory operand!
MODE=RR / CV
Determines which communication paradigm is used for the service:
RR | request-response paradigm, default value |
CV | conversational paradigm |
BUFFERS=(subtype-1,...,subtype-n)
List of subtype names that can be sent to the service (type X_OCTET is allowed always). Each name can be up to 16 bytes long.
A separate BUFFER statement, which defines the characteristics of the particular subtype, must be specified for each of the subtypes listed here (see below).
The BUFFERS= operand is sensitive to position and must (if specified) be the last operand of the statement.
If BUFFERS= is omitted, only a buffer of type X_OCTET should be sent to the service (no type check is performed).
BUFFER statement
A BUFFER statement defines a typed buffer. Buffers of the same name must be defined in the same way on both the client side and the server side.
Multiple definitions are not checked. The first buffer entry is valid, while all others are ignored.
Buffers of type “X_OCTET” have no special features and therefore do not require definition. Typed buffers are defined with the following parameters:
Operator | Operand | Explanation |
|
| maximum 16 bytes |
| default: subtype-name | |
| default: xatmigen sets TYPE automatically |
subtype-name
A buffer name of up to 16 bytes; must also be specified in the BUFFERS= operand in the SVCU statement. The name must be unique in the application.
REC=referenced-record-name
Name of the data structure for the buffer, e.g. with C structures this is the name of “typedef” or the “struct name”.
If the operand is omitted, xatmigen sets REC=subtype-name.
TYPE=
Type of buffer; for further details on types see "Typed buffers".
If the operand is omitted, xatmigen sets the type to X_C_TYPE or X_COMMON, depending on which elementary data types were used.
During the configuration run, xatmigen
also creates two additional operands with the following meaning:
LEN=length | length of the data buffer |
SYNTAX=code | syntax description of the data structure in code representation, as specified in the table on "Typed buffers". |