This section covers the following topics:
To open a conversation
Specify an OPEN
CONVERSATION statement on the client side.
In the OPEN CONVERSATION statement, specify a list of
services (subprograms) as members of this conversation.
The OPEN CONVERSATION statement assigns a unique
conversation identifier to the system variable
*CONVID.
More than one conversation may be open in parallel. If subprograms
interfere with each other, the application programs are responsible to manage
the various conversations by setting the appropriate
*CONVID, which is evaluated by the
CALLNAT
instruction.
If the subprogram is a member of the current conversation (referred to
by *CONVID), it will be executed at the server
task which is exclusively reserved for this conversation.
If it is not member of the current conversation, it will be executed in a different server task. This also applies to different conversations.
A conversation can be opened on any program level and
CALLNATs within this conversation can be executed on
any other program level below or above.
It is possible to open a client conversation within a remote
CALLNAT executed on a server so the server acts as
an agent. As the client only controls its own conversations, and not the
server's, it is the application programmer's responsibility to ensure that the
conversation on the server is closed properly before the main client is
closed.
The conversational RPC can still be tested locally. To keep the
behavior identical if you execute a conversational CALLNAT
remotely or locally, the following additional restrictions apply:
A CLOSE
CONVERSATION is not possible within an object which is
currently running as a member of this conversation. This corresponds to the
restriction that it is not possible to close a conversation from within a
remotely running program.
It is not possible to execute a conversational CALLNAT
which is member of the conversation from within another (or the same) member of
this conversation. This corresponds to the restriction that it is not possible
to execute a conversational CALLNAT which is member of the
client's conversation from a server subprogram.
It is not recommended to open a conversation from within another conversation's subprogram.
To close a conversation
Specify a CLOSE
CONVERSATION statement on the client side.
This enables the client to close a specific conversation or all conversations. All context variables of the closed conversation are then released and the server task will be available again for another client.
If you terminate Natural, you implicitly close all conversations.
When a server receives a CLOSE CONVERSATION request, it
issues a CLOSE CONVERSATION ALL statement so that all
conversations the server might have opened (as agent) are also closed.
BACKOUT TRANSACTION
(Rollback)
By default, when a CLOSE CONVERSATION statement is
executed, the Rollback option will be sent to the server together with the
CLOSE CONVERSATION statement. This will cause an implicit
BACKOUT TRANSACTION
on the server side at the end of the conversation processing.
END TRANSACTION
(Commit)
You can use the application programming interface USR2032N
available in library SYSEXT to cause an implicit END
TRANSACTION on the server side.
The application programming interface has to be called before the next
CLOSE CONVERSATION statement is executed. The result is that the
commit option is sent to the server together with the CLOSE
CONVERSATION statement and that the server executes an
END TRANSACTION
statement at the end of the conversation processing.
The commit option applies to the next CLOSE CONVERSATION
statement executed by the client application. After the conversation(s) has
(have) been closed, the default option is used again. This means, that the
following CLOSE CONVERSATION statements will result again in a
BACKOUT TRANSACTION statement.
During a conversation the subprograms that are members of this conversation may share a context area on this server.
To do so, declare a data area with the
DEFINE DATA
CONTEXT statement in each of the concerned subprograms.
The subprograms, using a context area, behave in the same way if the
conversation were local or remote. The DEFINE DATA CONTEXT
statement closely corresponds to the DEFINE DATA INDEPENDENT
statement. All rules which apply to the definition of AIV variables also apply
to context variables, with the exception that a context variable does not need
to be prefixed by a plus sign (+).
The compiler does not check format/length definition because this requires that the variables be created by running a program which includes all definitions for this application (as usual with AIVs). This makes no sense for context variables, because a library containing RPC service routines is usually not application-dependent.
In contrast to AIVs, the caller's context variables are not passed
across CALLNAT
boundaries. Context variables are referenced by their name and the context ID
they apply to. A context variable is shared by all service routines referring
to the same variable name within one conversation. Therefore each conversation
has its own set of context variables. Context variables cannot be shared
between different conversations even if they have the same variable name.
The context area will be reset to initial values when an OPEN
CONVERSATION statement or a non-conversational CALLNAT
statement is performed.
The system variable *CONVID
(format I4) is set by the OPEN
CONVERSATION statement and may be modified by the application
program.
Modifying *CONVID is only necessary if you
are using multiple conversations in parallel.