-
Critical sections
-
Exercise great caution when using critical sections, which are the parts of a program that must run without interruption. A TP must not issue an APPC verb within a critical section.
-
Data segments
-
Data is sent from and received in data buffers established by the TP. A data buffer must reside on an unnamed shared data segment and it must fit entirely within the data segment. Many data buffers can reside on the same data segment.
To allocate a data segment, use the DosAllocSeg function with Flags equal to 1.
To improve efficiency, a TP can reuse the same data segment each time it issues a verb requiring a data buffer. If necessary, the program can allocate a segment of up to 64K and then partition the segment into data buffers.
-
Limits
-
For more information about system limits, see your product documentation.
-
Load-time linking
-
For a TP to be dynamically linked to APPC at load time, you must do one of the following at link time:
-
Insert the following IMPORTS statement in the definition (.DEF) file used to link the TP:
IMPORTS APPC.APPC
-
Link the TP to APPC.LIB, which contains the entry point linkage information for various APIs, including APPC.
-
Multiple processes
-
Multiple processes cannot have the same TP identifier (tp_id). Only the process that issues TP_STARTED or RECEIVE_ALLOCATE can use the tp_id returned by the verb. Another process wanting to use APPC must issue TP_STARTED or RECEIVE_ALLOCATE to obtain its own tp_id.
Two or more instances of the same TP can be run as different processes, but each will be assigned a different tp_id.
One process can contain many TPs, each with its own tp_id. In this case, you may want to create a separate thread for each TP to avoid the possibility of a deadlock. (A deadlock occurs when an APPC verb that is hung blocks the execution of verbs in other conversations and TPs.)
A process containing many TPs can issue two or more verbs simultaneously, provided that each verb is for a different TP (specifies a different tp_id).
-
Multiple threads
-
A TP can have multiple threads that issue verbs. Windows APPC makes provisions for multithreaded processes. A process contains one or more threads of execution. All references to threads refer to actual threads in the multithreaded OS/2 environment.
With the exception of RECEIVE_AND_POST, MC_RECEIVE_AND_POST, RECEIVE_AND_WAIT, and MC_RECEIVE_AND_WAIT, only one conversation verb can be outstanding at a time on any conversation; however, other verbs can be issued for other conversations. This guideline also applies to TP verbs and TPs. Although multiple TP verbs can be issued, only one TP verb can be outstanding at a time on a TP. This applies to both multithreaded applications and single-threaded applications that use asynchronous calls.
-
Packing
-
VCBs are not packed. As a result, DWORDs and WORDs are on WORD boundaries, and BYTEs are on BYTE boundaries. This means, for example, that there is not a 2-byte gap between the primary and secondary return codes. VCBs should be accessed using the structures provided, and compiler options that change this packing method should be avoided.
-
Run-time linking
-
For a TP to be dynamically linked to APPC at run time, the TP must issue the following calls:
-
DosLoadModule to load APPC.DLL, the DLL for APPC.
-
DosGetProcAddr to specify APPC as the desired entry point to the DLL.
Unlinking (the DosFreeModule call) is not supported.
-
Simultaneous conversations
-
A TP can simultaneously participate in as many as 64 conversations for each OS/2 process.
-
SNA Server CSVs
-
SNA Server CSVs are compatible with the common services programming interface provided by IBM ES for OS/2 version 1.0, with the following exceptions:
-
VCBs are not packed. As a result, DWORDs and WORDs are on WORD boundaries, and BYTEs are on BYTE boundaries. This means, for example, that there is not a 2-byte gap between the primary and secondary return codes. VCBs should be accessed using the structures provided, and compiler options that change this packing method should be avoided.
-
Trace information for products is stored in trace files, not in a storage buffer. With the SNA Server implementation of COPY_TRACE_TO_FILE, the trace information in these files is copied to a single trace file.
-
The additional tracing features of DEFINE_TRACE are not applicable because of differences between the SNA Server product architecture and the IBM Communications Manager architecture. The tracing features provided in IBM OS/2 ES version 1.0 include event tracing, automatic tracing, and tracing support for the following:
| X.25 API verbs, frame data, and data link control (DLC) data |
| Twin axial data |
-
With the SNA Server implementation of GET_CP_CONVERT_TABLE, user-defined code pages are applicable only in an OS/2 environment. These code pages are supported for only the Windows NT, Windows 95, and OS/2 systems because of the additional memory occupancy in the MS-DOS and Windows environments. The new user-defined code pages are explained in the description of the verb.
-
With the SNA Server implementation of TRANSFER_MS_DATA, support for the PD_STATS subvector type is retained.
-
DEFINE_DUMP and SET_USER_LOG_QUEUE, provided in IBM OS/2 ES version 1.0, are not applicable because of differences between the SNA Server architecture and IBM Communications Manager architecture. If either verb is called, INVALID_VERB is returned.
-
Stack size
-
The recommended stack size for a TP is at least 3000 bytes.
When executing a verb, APPC uses the calling TP's stack. The combination of OS/2 and APPC requires 2560 bytes of stack space, and the TP requires additional stack space for its variables.
-
Translating service TP names to ASCII for SNA.INI
-
For service TPs on SNA Server clients running OS/2, a line must be added to the SNA.INI file, specifying the TP name in ASCII. For more information, see Translating SNA Service TP Names to ASCII for SNA.INI.
-
VCB segment
-
The segment containing the VCB must be a writable segment.