This section tells you how to define system resources for DBCTL.
The CICS® system initialization parameters contain information needed to initialize and control system functions and the initialization process. It also contains module suffixes to enable you to choose between different versions of CICS modules and tables. You can generate several SITs and select the one that best meets your current requirements at initialization time. If you have more than one CICS system, each can use a different SIT.
In CICS Transaction Server for z/OS®, Version 3 Release 1, there is no DLI system initialization parameter. Support for DBCTL is always present. Support for remote DL/I is included if the PDIR=YES|xx keyword is specified.
See CICS System Definition Guide for more details about these parameters.
With DBCTL, many CICS system initialization parameters are replaced by DBCTL generation parameters, and you will need to change what you specify for others because DL/I code has been removed from the CICS address space.
Table 1 lists the CICS system initialization parameters relevant to DL/I. It states whether each parameter applies to DBCTL or remote DL/I (in the D and R columns, respectively). Where applicable, it lists the corresponding IMS™ startup parameter that applies to DBCTL. Finally, it mentions special considerations for DBCTL.
See the CICS System Definition Guide for the syntax of CICS system initialization parameters. See Generating DBCTL for more information about the IMS and DBCTL parameters mentioned in this table. See Defining the IMS DRA startup parameter table for information about DRA startup table parameters.
System initialization parameter | D | R | IMS/DBCTL startup parameter | Comments |
---|---|---|---|---|
APPLID | Y | Y | N/A | The generic VTAM® application identifier for this CICS system. |
DBCTLCON | Y | N | N/A | YES specifies that you want CICS to
connect to a DBCTL subsystem automatically during CICS initialization.
This causes CICS to invoke the DBCTL attach program, DFHDBCON.
The other information CICS needs for starting the attachment,
such as the DRA startup table suffix or the DBCTL subsystem name,
is taken from an INITPARM system initialization parameter.
Specifying DBCTLCON=YES means you do not have to define the DBCTL attach program in the CICS post-initialization program list table (PLT), as described in Program list table (PLT). |
DSALIM | Y | Y | N/A | Upper limit of the total amount of storage within which CICS can allocate the individual dynamic storage areas (DSAs) below the 16M byte line. See the CICS System Definition Guide and the CICS Performance Guide for information about specifying DSALIM. See the IMS System Administration Guide for guidance on DBCTL storage estimates. |
EDSALIM | Y | Y | N/A | Upper limit of the total amount of storage within which CICS can allocate the individual dynamic storage areas (EDSAs) above the 16M byte line. For more information, see the CICS System Definition Guide and the CICS Performance Guide for information on specifying EDSALIM. See the IMS System Administration Guide for guidance on DBCTL storage estimates. |
INITPARM | Y | N | N/A | Used to pass parameters to programs (for example, PLT programs) during CICS startup. With DBCTL, you can use it to specify DRA startup parameter table suffix and DBCTL identifier to automate connection to a particular DBCTL. INITPARM applies to COLD, INITIAL, WARM, or EMERGENCY starts of CICS. With XRF, INITPARM applies only if the active CICS was not connected to DBCTL. Otherwise, the alternate CICS is automatically connected to the same DBCTL as the active. |
PDIR | N | Y | N/A--use APPLCTN | Suffix of the PDIR. With DBCTL, the PDIR is generated during DBCTL generation using the APPLCTN macro. |
PSBCHK | Y | Y | N/A | Requests PSB authorization checking of a remote terminal initiating a transaction using transaction routing. To obtain the check, you must also specify YES or name on the XPSB system initialization parameter. |
RST | Y | N | N/A | Suffix of recoverable service table (RST), which contains alternative DBCTL IDs to which CICS can try to connect, and which is used by CICS XRF with DBCTL. See Recovery and restart operations for DBCTL. |
XPSB | Y | Y | N/A | Security class name by which PSBs are defined to RACF®. For DBCTL, you specify the RACF resource class to be used to security check PSBs. (See the CICS RACF Security Guide for more information.) |
PSB directories (PDIRs) contain entries defining each PSB to be accessed using remote DL/I.
If you are using DBCTL exclusively, you do not need to generate a PDIR for CICS. Instead you must define PSBs and DMBs using the IMS macros APPLCTN and DATABASE respectively. (For information on the APPLCTN and DATABASE macros, see Generating DBCTL.)
If you want to function ship requests to a CICS system, at which the database manager may be DBCTL or remote DL/I (function shipping), you will need to generate a PDIR. See the CICS System Definition Guide and the CICS Resource Definition Guide for details about defining PDIRs.
CICS routes DL/I requests to remote DL/I or DBCTL according to the PSB that is named. If the PSB appears in the CICS PDIR, the request is routed to remote DL/I (that is, function shipped to another CICS system). If the PSB does not appear in the CICS PDIR, and CICS is connected to DBCTL, CICS routes the request to DBCTL. In addition, if the PSB appears in the PDIR and specifies a SYSID that matches the local SYSID, the request is routed to DBCTL.
You must put the following two modules, which appear in the IMS.RESLIB library, in the CICS STEPLIB data set concatenation:
You can do this by placing a DD statement for IMS.RESLIB in the CICS STEPLIB concatenation (which must be APF-authorized). For example:
//STEPLIB DD DSN=CICSTS31.CICS.SDFHAUTH,DISP=SHR
// DD DSN=IMS.RESLIB,DISP=SHR
IMS.RESLIB (which must also be APF-authorized) contains a default DRA startup table, in which the suffix is set to 00. You can generate your own versions into this library. If you decide to use a different library for your own versions, make sure it is APF-authorized, and is included in the CICS STEPLIB concatenation.
The DRA will dynamically allocate the IMS.RESLIB library using the DD name CCTLDD and the data set name IMS.RESLIB, unless either has been overridden in the DRA startup parameter table.
Program, transaction, and mapset entries for the CICS system definition (CSD) file to provide DBCTL support are supplied in the group DFHDBCTL. This includes the DBCTL connection and disconnection transaction, CDBC, the inquiry transaction, CDBI, and the operator transaction, CDBM. DFHDBCTL is in DFHLIST, which contains the CICS resource definitions needed to run IBM-supplied transactions that must be installed in your system. Also in DFHLIST is the DFHEDP group, which provides the program definition required to run EXEC DLI applications. The group DFHEDP must always be installed in the CICS system. If you need further information on DFHLIST, see the CICS Resource Definition Guide.
You may also want to specify the following options of the TRANSACTION definition for transactions using DBCTL:
This option defines whether or not CICS will attempt to restart a transaction that has been backed out after a failure. (See Deadlocks and interactions with automatic restart.)
Specify SPURGE(YES) so that the transaction can be purged using CEMT. Purging a transaction that is using DBCTL tells you how to use CEMT in this way.
All DBCTL-related information is sent to the IMS log, not the CICS system log. This method of logging uses the IMS log utilities and the online log data sets (OLDS) and write-ahead data sets (WADS). Because database change records are written to the IMS log, you do not need to retain the CICS system log for use by IMS database recovery utilities in a DBCTL-exclusive environment. IMS logging operations are described in IMS logging.
If you were using local DL/I when converting to DBCTL, you can remove the entries for the DL/I event monitoring points (EMPs) from the monitoring control table (MCT). However, you will need additional monitoring control table (MCT) entries if you want to provide support for the monitoring information returned from DBCTL. These MCT entries are in CICSTS31.CICS.SDFHSAMP in the copy member DFH$MCTD.
To connect CICS to DBCTL at CICS startup time, you can invoke it in the second stage of program list table postinitialization (PLTPI) processing (that is, the third stage of CICS initialization). You do this by including an entry for DFHDBCON (the DBCTL connection program) using the DFHPLT macro. See the CICS Resource Definition Guide for help on using the DFHPLT macro. If you are using XRF, you must also do this for your alternate CICS subsystems. CICS will then invoke DFHDBCON after takeover, passing the same DBCTL startup table suffix as was being used by the active CICS system when the failure occurred.
Including an entry for DFHDBCON in the PLT enables you to connect automatically to the same DBCTL as when the system was last shut down, or to a different one. For more information on doing this, see Connecting DBCTL to CICS automatically.
As an alternative, you may use the DBCTLCON system initialization parameter to make the automatic connection, see Table 1.
You will need a definition for the CDBC transient data queue. The CDBC transient data queue is used for messages issued by the CICS-DBCTL interface.
You can suppress or reroute messages sent to transient data queues such as CDBC. You can reroute from CDBC to a list of consoles, from CDBC to a different transient data queue, or reroute console messages to CDBC. For programming information about coding the CICS-supplied user exit used to re-route messages, and on the example user exit provided to help you do so, see CICS Customization Guide.