Connectivity Supplement

DB2 for VM Implementation

As shown in Figure 29, a VM application must go through the DB2 for VM application requester (resource adapter) to access any DB2 for VM or DRDA Application Server database. A DB2 for VM Application Server database can receive SQL requests from any DB2 for VM or DRDA Application Requester.

Figure 29. DB2 for VM Application Requester and Application Server

Options for Preprocessing or Running an Application

DB2 for VM supports three processing options on the sqlinit command that allow the user and the database administrator to enable the distributed database support. The user can specify one of the following SQLINIT options before preprocessing or running the application:

PROTOCOL(SQLDS)

Requests the use of the private SQLDS protocol. This is the default option. It can be used between a DB2 for VM application requester and server, in a local or remote environment. The DB2 for VM application server assumes that the requester uses the same CCSIDs as the server. The CCSID defaults ⁵ set up by the requester via SQLINIT are ignored, and no LU 6.2 LUWID is associated with the conversation. If you use only DB2 for VM systems, and the same default CCSID everywhere, then this is the most efficient option.

PROTOCOL(AUTO)

Requests the DB2 for VM application requester to find out if the application server is a like or unlike system. It then automatically selects the use of the private SQLDS protocol for a like system, or the DRDA protocol for an unlike system. It can be used between like (local and remote) and unlike systems. If the application server is not set with PROTOCOL=SQLDS, then the application requester and server can have different CCSID defaults. The requests and replies are converted appropriately. AUTO is the recommended option for any of the following cases:

If you need to access both like and unlike systems
If the CCSID defaults are different at the requester and server (and the PROTOCOL option of the application server is not SQLDS)
If you need an LU 6.2 LUWID associated with each conversation so that you can easily trace a task back to its originating site. This is useful if you manage a lot of remote DB2 for VM systems in your distributed database network.

PROTOCOL(DRDA)

Forces the DB2 for VM application requester to use only the DRDA protocol to communicate with the application server. You can use this option between like (local and remote) and unlike systems. If the application server is a like system, then DRDA protocol is used between the two DB2 for VM systems. The application requester and application server can have different CCSID defaults. The requests and replies are converted appropriately. You can use this option between two DB2 for VM systems for testing or for specific applications where the use of the DRDA protocol might provide better throughput due to the use of larger buffer size for sending and receiving data.

Table 3 compares functional characteristics of the DB2 for VM application requester SQLINIT processing options.

Table 3. Comparison of DB2 for VM Application Requester SQLINIT Processing Options

[SQLDS] [AUTO] [DRDA]
Both partners must be DB2 for VM systems Connects to any DRDA system Connects to any DRDA system
Can communicate with partner locally, through TSAF or AVS/VTAM Can communicate with a DB2 for VM system locally, or with a remote DB2 for VM system through TSAF or AVS. With an unlike system, must communicate through AVS. Can communicate with a DB2 for VM system locally, or with a remote DB2 for VM system through TSAF or AVS. With an unlike system, must communicate through AVS.
Supports static, dynamic, and extended dynamic SQL Supports static, dynamic, and extended dynamic SQL Supports static, dynamic, and extended dynamic SQL ⁶
CCSIDs defined by SQLINIT for the application requester are ignored by the DB2 for VM application server CCSIDs defined by SQLINIT for the Application Requester are honored by the DB2 for VM Application Server and proper conversion is performed (if the application server is set to AUTO as well) CCSIDs defined by SQLINIT for the Application Requester are honored by the DB2 for VM Application Server and proper conversion is performed
Fixed 8K blocksize; OPEN call returns no rows; Application Requester must explicitly close cursor DB2 for VM to DB2 for VM: SQLDS method; all others: DRDA method Variable 1K to 32K blocksize; more compact data packaging; OPEN call returns one block of rows; Application Server can implicitly close cursor saving Application Requester from sending a CLOSE call
Can use cursor INSERT and PUTs to insert a block of rows at a time using fixed 8K blocksize DB2 for VM to DB2 for VM: SQLDS method; all others: DRDA method PUTs are converted into regular single row inserts and sent out one row at a time
All DB2 for VM-unique commands are supported DB2 for VM to DB2 for VM: SQLDS method; all others: DRDA method DB2 for VM operator commands, some DB2 for VM statements, and some ISQL and DBSU commands are not supported (See the DB2 for VSE & VM SQL Reference).
LUWID is not supported LUWID is supported LUWID is supported

Options for Starting the Database Server Machine

This section describes various options for starting the Database Server Machine.

The PROTOCOL Parameter

The database administrator can specify one of the following options on the PROTOCOL parameter when starting the database server machine.

SQLDS

The default and recommended option if the application server needs to provide support only for DB2 for VM application requesters or DB2 for VSE application request taking advantage of VSE guest sharing. The application server only uses the private (SQLDS) flow.

The Application Server is sensitive to the processing option selected by the application requester. If a DB2 for VM requester specifies PROTOCOL(SQLDS), the processing on the DB2 for VM server continues normally with private flows. If the DB2 for VM requester specifies PROTOCOL(AUTO), the DB2 for VM server notifies the requester to switch to private flows. No CCSID information is exchanged between the application requester and the application server. The application server assumes that the application requester CCSIDs are the same as the application server CCSIDs. If the DB2 for VM requester specifies PROTOCOL(DRDA), the conversation is terminated. If an application requester other than DB2 for VSE & VM attempts to access the DB2 for VM server, the conversation is terminated.

AUTO

The recommended option if the application server needs to provide support for both the private protocol and the DRDA protocol. The DB2 for VM application requesters that specify PROTOCOL(SQLDS) or PROTOCOL(AUTO) communicate in the private flow. For an application requester that specifies SQLDS, no CCSID information is exchanged, and the application server assumes that the application requester CCSIDs are the same as the application server CCSIDs. For a requester that specifies AUTO, CCSID information is exchanged, and CCSID conversion of requests and replies are done appropriately. The DRDA flow is required by requesters other than DB2 for VM, or by any DB2 for VM requesters that specify PROTOCOL(DRDA).

The SYNCPNT Parameter

This parameter specifies whether or not a syncpoint manager (SPM) will be used to coordinate DRDA-2 multi-site-read, multi-site-write distributed unit of work activity.

If Y is specified, the server will use a syncpoint manager if possible, to coordinate two-phase commits and resynchronization activity. If N is specified, the application server will not use an SPM to perform two-phase commits. If N is specified, the application server is limited to multi-site-read, single-site-write distributed units of work and it can be the single write site. If Y is specified, but the application server finds that a syncpoint manager is not available, then the server will operate as if N was specified.

The default is SYNCPNT=Y when PROTOCOL=AUTO. When PROTOCOL=SQLDS, the SYNCPNT parameter is set to N.

Footnotes:

⁵: In DB2 for VM, the application requester and the application server specify the default CCSID by specifying a CHARNAME option for SQLINIT and SQLSTART respectively. The CHARNAME is a symbolic name that is mapped internally to the appropriate CCSIDs.
⁶: Extended dynamic SQL is supported with DRDA flows by converting into static or dynamic statements. Some restrictions apply.

[ Top of Page | Previous Page | Next Page ]

[SQLDS]	[AUTO]	[DRDA]
Both partners must be DB2 for VM systems	Connects to any DRDA system	Connects to any DRDA system
Can communicate with partner locally, through TSAF or AVS/VTAM	Can communicate with a DB2 for VM system locally, or with a remote DB2 for VM system through TSAF or AVS. With an unlike system, must communicate through AVS.	Can communicate with a DB2 for VM system locally, or with a remote DB2 for VM system through TSAF or AVS. With an unlike system, must communicate through AVS.
Supports static, dynamic, and extended dynamic SQL	Supports static, dynamic, and extended dynamic SQL	Supports static, dynamic, and extended dynamic SQL ⁶
CCSIDs defined by SQLINIT for the application requester are ignored by the DB2 for VM application server	CCSIDs defined by SQLINIT for the Application Requester are honored by the DB2 for VM Application Server and proper conversion is performed (if the application server is set to AUTO as well)	CCSIDs defined by SQLINIT for the Application Requester are honored by the DB2 for VM Application Server and proper conversion is performed
Fixed 8K blocksize; OPEN call returns no rows; Application Requester must explicitly close cursor	DB2 for VM to DB2 for VM: SQLDS method; all others: DRDA method	Variable 1K to 32K blocksize; more compact data packaging; OPEN call returns one block of rows; Application Server can implicitly close cursor saving Application Requester from sending a CLOSE call
Can use cursor INSERT and PUTs to insert a block of rows at a time using fixed 8K blocksize	DB2 for VM to DB2 for VM: SQLDS method; all others: DRDA method	PUTs are converted into regular single row inserts and sent out one row at a time
All DB2 for VM-unique commands are supported	DB2 for VM to DB2 for VM: SQLDS method; all others: DRDA method	DB2 for VM operator commands, some DB2 for VM statements, and some ISQL and DBSU commands are not supported (See the DB2 for VSE & VM SQL Reference).
LUWID is not supported	LUWID is supported	LUWID is supported