Overview

The Open Communication Facility OCF and/or the Cross Coupling Facility XCF are recommended for making the BQL service available in a multi-CPU environment. One BQL system (BQL_MASTER) is in charge of serialization and caching. The BQL_SHARE_OPTION is set to NO (default).

Alternatively, the BQL service can be made available by setting BQL_SHARE_OPTION to ALL (or SPOOL) if OCF and XCF are not an option.

Requirements and recommendations

Our general recommendation is to work with BQL_SHARE_OPTION=NO, which is the default.

Database sharing with BQL_SHARE_OPTION=ALL requires GRS. BETABQL reserves must be converted into a global enqueue as described in "Activating IBM's Global Resource Serialization (GRS)".

BQL_SHARE_OPTION=ALL can also reduce performance because there is less caching and an increased overhead for data synchronization.

If OCF and XCF are not an option and you therefore consider to make use of BQL_SHARE_OPTION=ALL, you should contact support first.

Activating database sharing

Database sharing is activated by the master STC when it is started with the following LST parameters:

• BQL_SHARE_OPTION = SPOOL | ALL
• BQL_MASTER_SSID = ssid_of_the_master

If master and slave use different LST members, code the same parameters in each member.

Important: All database activities (master and slave STCs and all batch jobs) must be stopped before changing the BQL share option.

Please also be aware of the following before you change the BQL share option:

• The SYNC file holds the information that a database is shared, including the subsystem ID of the master.
• Database sharing is activated by the master STC when it is started with the appropriate BQL share option. Only the master can change the BQL share option in the SYNC file.
• When you clear the SYNC file, for example, by using job BnnCLSYN, the database sharing information will also be deleted.
• BQL_SHARE_OPTION = ALL disables BQL Speedmaster, which means that performance may suffer.
• Migrations and new installations should not take place when database sharing is active.
• We recommend that service programs such as CLEANUP and ARCHIVE be used exclusively on the master system.

LST parameters for the BQL share option

Parameter name	Value	Description	Default
BQL_SHARE_ OPTION	NO	Only the master system is allowed to access the database. All database requests (BQL and SPOOL) from a slave system are sent to the master system, which processes these requests. Code BnnDEF DD DUMMY for the slave STC if it is running on an LPAR that has no access to the database (because the corresponding disks are not shared). In a multi-CPU environment, an OCF or XCF connection is required to enable communication across LPAR boundaries.	NO
	SPOOL	Both master and slave are allowed to access the SPOOL files. All BQL database requests from the slave system are sent to the master system, which processes these requests. DD BnnDEF in the JCL of the master STC and the slave STC must reference the database definition dataset. In a multi-CPU environment, an OCF or XCF connection is required to enable communication across LPAR boundaries.
	ALL	Each system (master and slave) handles its database requests (BQL and SPOOL) by accessing the database directly. DD BnnDEF in the JCL of the master STC and the slave STC must reference the database definition dataset. An OCF or XCF connection is not required here. Note on _beta access: Although an OCF or XCF connection is not strictly required, its absence restricts shared functionality, and _beta access does not recommend using BQL_SHARE_ OPTION = ALL without OCF/XCF.
BQL_MASTER_SSID	ssid	This keyword specifies the subsystem ID of the master STC.	None

Notes

Always check the Beta product Installation and System Guide to find out whether there is product-specific information.