The OS/2 implementation of APPC uses a concept of the local TP, which represents a logical user of APPC functions on the local system. Any program that wants to use APPC functions must first call the APPC subsystem (using the startTP verb) to create a new local TP and to get a unique handle for it that will be used in subsequent APPC calls to create and manage conversations. In the APPC system layer, you can get the handle by creating a new instance of an APPCLocalTP class and sending it the message tpStarted. For example:

To simplify programming, basic VA Smalltalk creates and initializes an APPCLocalTP object when Smalltalk is started or when the APPC DLL is bound. You can use this instance of APPCLocalTP to create and manage conversations. Access the instance of APPCLocalTP by placing the following code in your application:

APPC sends and receives all messages from remote programs by establishing a conversation with the remote program and then issuing send and receive APPC verbs referencing the conversation.

A new APPC conversation is established by sending an allocate: or a mcAllocate: message to an existing instance of APPCLocalTP. The allocate: message is used to create a new basic conversation and the mcAllocate: message is used to create a new mapped conversation. Refer to the APPC documentation for an explanation of the differences and usage of these two types of conversation. The following example code shows how to create a new conversation.

For the meaning of all the options, refer to the APPC documentation.

Messages are sent to and received from a remote program by sending a send or receive message to an instance of APPCConversation, as in the following example code.

In the first line, the variable result indicates if the sendRecord: was successful. In the second line, the data received from the remote program is contained in the variable result.

After sending and receiving all the data required from a remote program, the conversation must be deallocated. The designers of the local and remote programs must decide which program will perform the deallocate and when. If the remote program deallocates, no action is required on the part of the local program. However, the local program can initiate the deallocate by sending the message deallocate: to the conversation object.

To complete all remote communications and free system resources you can end the local TP by sending the tpEnded: message to the TP.

Whenever a message is sent to a system layer object that results in a call to the APPC subsystem, the possibility exists for an error. Objects in the system layer signal errors to their callers by returning error objects instead of the normal message results. Therefore, after each message is sent to an APPC system layer object, it is a good practice to check whether the result represents an APPC error. To test for an error, send the message isCommunicationsError to the result, as in the following example code:

On the Windows environments APPC support in VA Smalltalk supports both the IBM and Attachmate products. The IBM product is set as the default support for both platforms. To change support between the two vendors, execute the following from the Smalltalk Transcript window:

In AIX, APPC support in VA Smalltalk supports both version 2.2 and version 3.1 of Communications Server. Version 3.11 is set as the default. To Change between the two libraries execute the following