This topic describes considerations that affect how you can implement the sharing of a CSD that is accessed in a non-RLS mode, such as LSR or NSR. Sharing the CSD by several CICS® regions enables those regions to use the same definitions, and means there is no need for duplicate data sets. This is particularly important in a parallel sysplex environment where a CICSplex may comprise a number of cloned regions, in which case it is essential that they use the same CSD.
To optimize the sharing of a CSD, you should observe the following considerations:
For more information, see Multiple users of the CSD within a CICS region (non-RLS).
You may then use the CEDB transaction from any region to change the contents of the CSD, and use CEDA to INSTALL into the invoking region. You cannot use CEDA to change the CSD in region(s) that do not own the CSD.
If the CSD-owning region fails, the CSD is not available through the CEDB transaction until emergency restart of the CSD-owning region has completed (when any backout processing on the CSD is done). If you try to install a CSD GROUP or LIST that is the target of backout processing, before emergency restart, you are warned that the GROUP or LIST is internally locked to another user. Do not run an offline VERIFY in this situation, because backout processing removes the internal lock when emergency restart is invoked in the CSD-owning region.
If you do not want to use the above method, but still want the CSD to be defined as a recoverable resource, then integrity of the CSD cannot be guaranteed. In this case, you must not specify CSDBKUP=DYNAMIC, because the CSD would not be suitable for BWO.
For more information about shared CSD access within one MVS image, see Sharing a CSD by CICS regions within a single MVS image (non-RLS). For more information about shared CSD access across several MVS images, see Sharing a CSD in a multi-MVS environment (non-RLS). For information about sharing the CSD between different releases of CICS, see Sharing the CSD between different releases of CICS.
If you want to use the DFHCSDUP utility program in read/write mode to update the CSD, you must ensure that no CICS users are using any of the CEDA, CEDB, or CEDC transactions.
For information about other factors that can restrict access to a CSD, see Other factors restricting CSD access.
For information about the system initialization parameters for controlling access to the CSD, see Defining CSD attributes.
If you have specified read/write access for the CSD, all the CEDA users in a CICS region can perform read and write functions. CICS file control manages concurrent access for multiple users within a region, using the attributes specified in the CSDACC system initialization parameter.
CICS protects individual resource definitions against concurrent updates by a series of internal locks on the CSD. CICS applies these locks at the group level. While CICS is executing a command that updates any element in a group, it uses the internal lock to prevent other RDO transactions within the region from updating the same group. CICS removes the lock record when the updating command completes execution. Operations on lists are also protected in this way.
The number of concurrent requests that may be processed against the CSD is defined by the CSDSTRNO system initialization parameter. Each user of CEDA (or CEDB or CEDC) requires two strings, so calculate the CSDSTRNO value by first estimating the number of users that may require concurrent access to the CSD, and then multiply the number by two.
CEDA issues a diagnostic message if the CSDSTRNO value is too small to satisfy the instantaneous demand on the CSD for concurrent requests. A subsequent attempt to reissue the command succeeds if the conflict has disappeared. If conflicts continue to occur, increase the CSDSTRNO value.
The CSD may be shared by a number of CICS regions within the same MVS image. You can maintain the integrity of the CSD in this situation by coding SHAREOPTIONS(2) on the VSAM definition, as shown in the Figure 11. The CICS attributes of the CSD, as viewed by a given region, are defined in the system initialization parameters for that region.
You should consider defining:
If you define several CICS regions with read/write access to the CSD, those regions should all be at the latest level. Only one CICS region with read/write access can use a CEDA, CEDB, or CEDC transaction to access the CSD, because the VSAM SHAREOPTIONS(2) definition prevents other regions from opening the CSD.
If you are running CICS with the CSD defined as a recoverable resource (CSDRECOV=ALL), see Planning for backup and recovery for some special considerations.
You can use CEMT to change the file access attributes of the CSD, or you can use the EXEC CICS SET FILE command in an application program. However, ensure that the resulting attributes are at least equivalent to those defined either by CSDACC=READWRITE or CSDACC=READONLY. These parameters allow the following operations on the CSD:
If you need to share a CSD between CICS regions that are running in different MVS images, you should ensure that only one region has read/write access.
The VSAM SHAREOPTIONS(2) offers no integrity, because the VSAMs running in a multi-MVS environment do not know of each other.
Because of these limitations, active and alternate CICS regions running in different MVS images must not share the CSD with other CICS regions, unless you are using some form of global enqueuing (for example, with global resource serialization (GRS)).
These multi-MVS restrictions also apply to running the offline utility, DFHCSDUP.
The types of access needed in the four situations where the CSD are used are shown in Table 11.
Type of activity | Access | |
---|---|---|
1 | CICS region performing initialization (cold or initial start) | Read-only |
2 | CICS region running one or more CEDA, CEDB, or CEDC transactions | Read/write or read-only (as specified in the CSDACC parameter) |
3 | Batch region running utility program DFHCSDUP | Read/write or read only, depending on PARM parameter |
4 | CICS regions performing emergency restart, and CSD file backout is required | Read/write |
Note the following limitations when the activities listed in Table 11 are attempted concurrently:
A CICS region starting with an initial or cold start opens the CSD for read access only during initialization, regardless of the CSDACC operand. This enables a CICS region to be initialized even if a user on another region or the DFHCSDUP utility program is updating the CSD at the same time. After the group lists are installed, CICS leaves the CSD in a closed state.
On a warm or emergency start, the CSD is not opened at all during CICS initialization if CSDRECOV=NONE is coded as a system initialization parameter. However, if CSDRECOV=ALL is coded, and backout processing is pending on the CSD, the CSD is opened during CICS initialization on an emergency start.
Resource attributes become obsolete when they have no relevance for a new release of CICS. CICS continues to display these on CEDx panels, but they are displayed as protected fields, indicating that they are not supported by this release. Using the ALTER command on definitions that specify obsolete attributes does not cause the loss of these attributes, so you can safely update resource definitions using this release. If you are sharing the CSD with CICS regions at an earlier release, you can update the unsupported fields by using the PF2 function key to remove the protection when in ALTER mode. (PF2 is designated as the "compatibility" key (COM) on the CEDA or CEDB display panels.) Pressing PF2 converts protected fields to unprotected fields that can you can modify. If you want to use this facility to enable you to share common resource definitions, the rule for sharing between different release levels of CICS is that you must update the CSD from the highest release level.
For information about using the CEDA and CEDB ALTER commands to update resource definitions in compatibility mode, see the CICS Resource Definition Guide.
You can also use the CSD utility program, DFHCSDUP, to update resources that specify obsolete attributes. A compatibility option is added for this purpose, which you must specify on the PARM parameter on the EXEC PGM=DFHCSDUP statement. You indicate the compatibility option by specifying COMPAT or NOCOMPAT. The default is NOCOMPAT, which means that you cannot update obsolete attributes.
If you share your CSD between different releases of CICS that use DB2®, you must use the DB2 resource definitions appropriate for each release of CICS. With those releases of CICS that ship the CICS DB2 attachment facility, you must use the CICS-supplied group called DFHDB2. This group is included in the CICS-supplied startup list, DFHLIST, and specifies different program names from the attachment facility provided by DB2.
For earlier releases of CICS that do not provide the DFHDB2 group, you must use your own resource definitions that specify the resource names appropriate for the release of CICS and DB2.
If you are sharing the CSD between CICS Transaction Server for z/OS®, Version 3 Release 1 and an earlier release of CICS, you must ensure that the group list you specify (on the GRPLIST system initialization parameter) contains all the CICS-required standard definitions. When you upgrade the CSD to the CICS Transaction Server for z/OS, Version 3 Release 1 level, some of the IBM® groups referenced by your group list are deleted, and the contents transferred to one of the compatibility groups, DFHCOMPx. To ensure that these continue to be available to your CICS regions of earlier releases, add the compatibility groups after all the other CICS-supplied definitions.
For information about upgrading your CSD, and about the compatibility groups in CICS Transaction Server for z/OS, Version 3 Release 1, see the CICS Resource Definition Guide.
Access to the CSD may also be restricted if it is left open after abnormal termination of a CEDA, CEDB, or CEDC transaction. If the CSD is left open with write access, this prevents other address spaces from subsequently opening it for write access. This situation can be remedied by using CEMT to correct the status of the CSD.
Access to the CSD is not released until the RDO transaction using it is ended, so users of CEDA, CEDB, and CEDC should ensure that a terminal running any of these transactions is not left unattended. Always end the transaction with PF3 as soon as possible. Otherwise, users in other regions are unable to open the CSD.
There may be times when you cannot create definitions in a group or list. This situation arises if an internal lock record exists for the group or list you are trying to update. If you are running the DFHCSDUP utility program (or a CEDA transaction) when this occurs, CICS issues a message indicating that the group or list is locked. As described under Multiple users of the CSD within a CICS region (non-RLS), this is normally a transient situation while another user within the same region is updating the same group or list. However, if a failure occurs, preventing a CEDA transaction from completing successfully, and CSDRECOV=NONE is coded, the internal lock is not removed and is left in force. (If CSDRECOV=ALL is coded, the CSD is recoverable and file backout occurs and frees the lock.) This could happen, for example, if a system failure occurs while a CEDA transaction is running; it could also happen if the CSD becomes full. You can remedy this situation by running the DFHCSDUP utility program with the VERIFY command.
However, if you have coded CSDRECOV=ALL, make sure no backout processing is pending on the CSD before you run an offline VERIFY. The effect of coding CSDRECOV=ALL is discussed more fully under Planning for backup and recovery.
[[ Contents Previous Page | Next Page Index ]]