This section describes the SNA configuration requirements of the SPM, and explains the interdependencies between the SPM_NAME database manager configuration parameter and the communications configuration files.
SNA communications must be configured for SPM on the DB2 Connect workstation.
An LU6.2 Side Information profile and an LU6.2 Transaction Program Name profile must be defined to identify the SPM to the AIX SNA Server. The Side Information profile name and the Transaction Program Name profile name that SPM uses must match the SPM_NAME parameter of the database manager configuration. These profiles are used to allow DB2 to configure the syncpoint support. They are not used for any SNA communication.
Figure 21 shows the relationships between these entities.
Figure 21. SPM_NAME Usage with SNA Server for AIX. This diagram shows the relationships between SPM_NAME and SNA Server for AIX configuration objects.
In the examples which follow:
SPM_NAME can be set using the following command:
update database manager configuration using spm_name SPMNAME
Figure 22 illustrates the sample settings for defining the SPM LU in SMIT. The SPM Side Information profile identifies the local LU to be managed by the SPM. When a node directory entry is cataloged for a DRDA2 server, the Side Information profile (symbolic destination name) must use the same local LU alias as the local LU alias specified in the SPM Side Information profile.
This example uses SPMALIAS as the name of the SPM LU alias and SPMNAME as the profile name.
Figure 22. Side Information Profile for the SPM Local LU
+--------------------------------------------------------------------------------+ | Add LU 6.2 Side Information Profile | |Type or select values in entry fields. | |After making all desired changes, press Enter. | | | | [Entry Fields] | |* Profile name [SPMNAME] | | Local LU or Control Point alias [SPMALIAS] + | | Provide only one of the following: | | Partner LU alias [] + | | Fully qualified partner LU name [] | | Mode name [IBMRDB] + | | Remote transaction program name (RTPN) [] | | RTPN in hexadecimal? no + | | | | Comments [DB2 SyncPoint Profile] | +--------------------------------------------------------------------------------+
The SPM local LU cannot be the Control Point LU.
Figure 23 illustrates the sample settings for defining the SPM Transaction Program Name profile using SMIT. The SPM Transaction Program Name profile identifies that the SPM supports all sync level conversations. Also, multiple instances supported must be set to no. Each DB2 instance is required to have a unique SPM_NAME.
Figure 23. Transaction Program Name Profile Required for SPM (for AIX)
+--------------------------------------------------------------------------------+ | Add LU 6.2 TPN Profile | |Type or select values in entry fields. | |After making all desired changes, press Enter. | | | |[TOP] [Entry Fields] | | | |* Profile name [SPMNAME] | | Transaction program name (TPN) [] | | Transaction program name (TPN) is in hexadecimal? no + | | PIP data? no + | | If yes, Subfields (0-99) [0] #| | Use Command Line Parameters? no + | | Command Line Parameters [] | | Conversation type either + | | Sync level all + | | Resource security level none + | | If access, Resource Security Access List Prof. [] | | Full path to TP executable [/dev/sna] | | Multiple instances supported? no + | | User ID [100] #| | Server synonym name [] | | Restart action once + | | Communication type signals + | | If IPC, Communication IPC queue key [0] #| | Standard input file/device [/dev/console] | | Standard output file/device [/dev/console] | | Standard error file/device [/dev/console] | | | | Comment [DB2 SyncPoint TP] | | | | [BOTTOM] | +--------------------------------------------------------------------------------+
The SNA node profile must have recovery resource support enabled.
For SNA Server for AIX Version 3 this flag is moved to the local LU profile, and the recovery resource manager should be enabled for the local LU profile identified in the SPM side information profile.
Terminating SNA Server for AIX while the SPM is active causes the SPM to stop. Once SNA Server for AIX is restarted, you must issue db2stop and db2start on the DB2 Connect workstation in order to allow the SPM to reinitialize.
If a DB2 Connect workstation has Syncpoint Manager started and you want to use it as a DRDA1 AS or as a database server for clients accessing via APPC, you must do the following:
You can validate this by setting the SPM_NAME to the correct LU name and setting the DIAGLEVEL = 4 in the Database Manager Configuration. When you issue db2start to initiate the SPM you should NOT see the following message in the db2diag.log:
SPM0445 The Transaction Program TPname will not be listened for by DB2. This is not a severe error, but if you require this Transaction Program, you must ensure that it is not defined in the Transaction Profile of the AIX SNA configuration.
Ensure all clients use the LU specified on the SPM node in the Database Manager Configuration parameter SPM_NAME as their partner LU.
The following example assumes:
All these requirements must be met:
SPM_NAME can be set using the following command:
update database manager configuration using spm_name SPMNAME
Inspect the DEFINE_LOCAL_LU statement for the SPM LU in your NDF file, and, if necessary, edit it manually to ensure that it includes the following:
EXTERNAL_SUPPORT(SYNCPT_PROVIDER,REMOTE_TP_PROVIDER)
Figure 24 illustrates the format of the required statement, using the local LU name SPMNAME. Note that The LU name specified cannot be the Control Point LU.
Figure 24. Sample Communications Server Definition for SPM
DEFINE_LOCAL_LU LU_NAME(SPMNAME)
LU_ALIAS(SPMNAME)
EXTERNAL_SUPPORT(SYNCPT_PROVIDER,REMOTE_TP_PROVIDER)
NAU_ADDRESS(INDEPENDENT_LU)
|
This is a DRDA default service TP Name.
This is a DRDA default TP Name.
The Communications Server .NDF file should include for each of the above TPs the following definition (Service TP x'07'6DB is used as an example:
DEFINE_TP SNA_SERVICE_TP_NAME(X'07',6DB)
DESCRIPTION(ACCEPTS INBOUND SYNCPOINT CONVERSATIONS)
PIP_ALLOWED(NO)
FILESPEC(d:\dummy.exe)
CONVERSATION_TYPE(ANY_TYPE)
CONV_SECURITY_RQD(YES)
SYNC_LEVEL(SYNCPT_NEGOTIABLE)
TP_OPERATION(QUEUED_OPERATOR_PRELOADED)
PROGRAM_TYPE(BACKGROUND)
INCOMING_ALLOCATE_QUEUE_DEPTH(255)
INCOMING_ALLOCATE_TIMEOUT(INFINITE)
RECEIVE_ALLOCATE_TIMEOUT(INFINITE);
db2 update dbm cfg using tpname NYSERVER
You must then also ensure that a TP definition exists for this TP. An example follows:
DEFINE_TP TP_NAME(NYSERVER)
PIP_ALLOWED(NO)
FILESPEC(notused)
CONVERSATION_TYPE(ANY_TYPE)
CONV_SECURITY_RQD(NO)
SYNC_LEVEL(SYNCPT_NEGOTIABLE)
TP_OPERATION(QUEUED_OPERATOR_PRELOADED)
PROGRAM_TYPE(BACKGROUND)
INCOMING_ALLOCATE_QUEUE_DEPTH(255)
INCOMING_ALLOCATE_TIMEOUT(INFINITE)
RECEIVE_ALLOCATE_TIMEOUT(INFINITE);
| Note: | If all of the following apply to your environment:
then the DB2 Universal Database clients and the DRDA application requesters must:
|
Terminating IBM Communications Server for OS/2 Warp Version 4 while the SPM is active causes the SPM to stop. Once IBM Communications Server for OS/2 Warp Version 4 is restarted, you must issue a db2stop and db2start on the DB2 Connect workstation to allow the SPM to reinitialize.
Communications Server for OS/2 requires that syncpoint LUs be registered by the SPM before they can be used for DRDA2 calls. Thus DB2 must be started explicitly beforehand, in order that the SPM can register the syncpoint LU. Otherwise you may encounter the following message on DRDA2 calls:
SQL0859N Access to the Transaction Manager Database failed with SQLCODE "-1032". SQLSTATE=08502.
In order to execute DRDA1 calls successfully when DB2 is not started, the default LU should specify a non-SPM LU. You can use the APPCLLU environment variable to specify an LU name that does not have syncpoint support defined. Otherwise you may encounter the following message:
SQL30081N A communication error has been detected. Communication protocol being used: "APPC". Communication API being used: "CPI-C". Location where the error was detected: "". Communication function detecting the error: "xcstp". Protocol specific error code(s): "20", "*", "*". SQLSTATE=08001