The application server support for DB2 for VSE allows DB2 for VSE to act as a server for DRDA application requesters. The application requester connected to a DB2 for VSE application server can be one of the following:
The following steps are required to establish the network connection to the VSE application server:
The DB2 for VSE application server communicates with its application requester via CICS LU 6.2 links. The CICS partition used for this purpose must have LU 6.2 links to the remote systems with the application requesters. The CICS/VSE Intercommunications Guide contains details on defining and establishing CICS LU 6.2 links with remote systems.
CICS installation and resource definition for LU 6.2 communications:
You must include the following modules in your system by using SIT or initialization overrides:
If the CICS Restart Resynchronization Support was not enabled when the CICS system was installed, you have to update the following CICS tables to enable the CICS Restart Resynchronization capability:
DFHJCT Journal Control Table
A journal used for the CICS system log must be
defined in the DFHJCT specifying JFILEID=SYSTEM in a
DFHJCT TYPE=ENTRY macro.
DFHPCT Program Control Table
To generate the DFHPCT entry to use the CICS Restart
Resynchronization capability, enter:
DFHPCT TYPE=GROUP,FN=RMI
DFHPPT Processing Program Table
To generate the DFHPPT entry to use the CICS Restart
Resynchronization capability, enter:
DFHPPT TYPE=GROUP,FN=RMI
DFHSIT System Initialization Table.
The DFHSIT macro must include the JCT parameter.
Specify JCT=YES or JCT=(jj<,....>) where jj is the
SUFFIX parameter value specified in th DFHJCT
TYPE=INITIAL macro defining the CICS system log
journal data set.
To support LU 6.2 connections, CICS must be defined to VTAM for VSE as a VTAM application major node. The application major node name coded in the VTAM APPL statement is the APPLID for the CICS partition specified in the SIT by the APPLID parameter. It is the LU name used by VTAM (and hence used by the CICS communication partners) to identify the CICS system.
See Figure 36.
Figure 36. Example VTAM APPL Definition for CICS
VBUILD TYPE=APPL
************************************************************************
* *
* LU Definition for Toronto VSE SQL/DS System *
* *
************************************************************************
VSEGATE APPL ACBNAME=VSEGATE,
AUTH=(ACQ,SPO,VPACE),
APPC=NO,
SONSCIP=YES,
ESA=30
MODTAB=RDBMODES,
PARSESS=YES,
VPACING=0
|
SPO allows CICS to issue the MODIFY vtamname USERVAR command.
VPACE allows pacing of the intersystem flows.
| Note: | SYNCLVL=SYNCPT is not required since APPC=NO is specified. CICS manages all SYNCPT syncpoint level activity for distributed units of work. |
Define all remote LUs using the CEDA DEFINE CONNECTION command on resource definition online online (RDO):
For more details on conversation and session level security, refer to Provide Security.
For each connection defined above, define groups of parallel sessions for each link to the remote LU using the CEDA DEFINE SESSIONS command:
Specify the values used by the DRDA Application Requester communications software, for example IBM Communications Server for OS/2.
Note that defining the SENDSize and RECEIVESize with a larger number may improve data transmission rate, however, more virtual storage will also be required across the network. 4 Kilobyte is the size that all layers in the SNA network support. Therefore, when setting up the DRDA Server, set send and receive buffer sizes to 4 Kilobyte. When connections can be made successfully from remote users, adjust these parameters to determine the optimum value.
Define all users in the CICS sign-on table (DFHSNT). You can test the validity of a user ID by performing a CESN logon at a CICS terminal. The local sign-on must be successful.
Refer to DRDA Connectivity Guide for sample definitions.
Add an entry to the DBNAME directory for each transaction defined above using the CEDA DEFINE TRANSACTION command. With LU 6.2 sessions established, a remote application requester can start a conversation with the DB2 for VSE Application Server. It does so by allocating an LU 6.2 conversation with the Application Server, specifying a TPN (transaction program name). This TPN must be the CICS transaction ID of the AXE transaction responsible for routing requests to or from the DB2 for VSE server. The TPN must be in the DB2 for VSE DBNAME directory mapped to the DB2 for VSE server to be accessed by the application requester. The DB2 for VSE database administrator is responsible for updating the DBNAME directory and informing the remote users of the TPN-to-server mapping.
Both the TPN and its corresponding server name (database name as defined in the DBNAME directory) must be identified to the application requester:
For more details, please see DB2 for VSE System Administration manual.
| Problem determination: |
|
The DB2 for VSE application server depends on CICS for intersystem communication security. CICS offers several levels of security:
The CICS implementation of the SNA LU 6.2 session-level LU-to-LU verification. The implementation of bind-time security is optional in the LU 6.2 architecture. On the application server side, it can be enabled by supplying a BINDPASSWORD in the CEDA DEFINE CONNECTION command when defining the connection to the Application Requester. On the application requester, the partner LU that serves the Application Requester must also support bind-time security and use the same password for partner-LU verification.
You can use bind-time security to stop unauthorized remote systems from establishing (binding) sessions with CICS.
Link security can be used to limit a remote system (and its resident DRDA application requester) to attach a certain set of AXE transactions only.
For example, you can define two AXE transactions: AXE2 with security key 2, and AXE3 with security key 3. Application requesters from a remote system can be assigned an operator security of 3 (for example, using the OPERSECURITY parameter in the CEDA DEFINE SESSION command), allowing them to attach AXE3 only. AXE3 might not have privileged access to the server while AXE2 has privileged access. Refer to DB2 for VSE System Administration for a description of privileged access to the application server by remote application requesters.
Refer to the CICS Intercommunication Guide for how to enable link security.
The CICS implementation of the SNA LU 6.2 conversation-level security providing end user verification.
User security validates the user ID with the CICS sign-on table (DFHSNT) before accepting a request to start a conversation. For example, DRDA application requesters not defined in the CICS sign-on table are not allowed to attach an AXE transaction to start a conversation with the DB2 for VSE server. User security level for a remote system can be selected in the CEDA DEFINE CONNECTION command using the ATTACHSEC parameter. The three levels of attach securities are:
Because the application server is responsible for managing the database resources, it dictates which network security mechanisms the application requester must provide. For example, with a DB2 for VM application requester, you must record the application server's conversation-level security requirements in the application requester's communications directory by setting the appropriate value in the :security tag, as in Figure 37:
Figure 37. Sample CMS Communication Directory entry
User ID translation is not supported by the VSE application server. CICS uses the user ID transmitted directly from the requester.
After being started by an application requester, the AXE transaction extracts the user ID from CICS and passes it on to the DB2 for VSE server. To set up the required level of user authority on database resources, you must update the user ID into the DB2 for VSE catalog SYSTEM.SYSUSERAUTH.
The DB2 for VSE application server verifies if the user ID given by CICS has CONNECT authority to access the database, and rejects the connection if it does not have authority.
As the owner of database resources, the DB2 for VSE Application Server controls the database security functions for SQL objects residing at the DB2 for VSE Application Server. Access to objects managed by DB2 for VSE is controlled through a set of privileges, which are granted to users by the DB2 for VSE system administrator or the owner of the particular object. The DB2 for VSE Application Server controls two classes of objects:
When an application is preprocessed on DB2 for VSE, the package contains the SQL statements contained in the application program. These SQL statements are classified as:
When an end user is granted the privilege to execute a package, that user automatically has the authority to execute each of the static SQL statements contained in the package. Thus, end users do not need any DB2 for VSE table privileges if the package contains only static SQL statements.
See Represent Data.
The following checklist summarizes the steps needed to enable a DRDA Application Server, starting with the assumption that your VSE system is installed with ACF/VTAM as its teleprocessing access method, and that VTAM definitions needed to communicate with the remote systems, such as NCP definitions are completed.
These statements should have all definitions under one group, for example, named IBMG. Install the group with: CEDA INSTALL GROUP(IBMG).