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.