CA Datacom Task Storage Options. User Key ECSA and Data Space

Transcription

1 CA Datacom Task Storage Options User Key ECSA and Data Space September 19, 2007

2 1. Overview z/os 1.9 default change that blocks user key CSA z/os option AllowUserKeyCSA CA Datacom default use of ECSA CA Datacom alternative to ECSA: Task Storage Data Space Characteristics Illustrations AllowUserKeyCSA Parameter Choices Options Evaluating the Options Recommendation Software Requirements CA Datacom/DB r Base Level SP SP SP CA Datacom/AD r SP CA Datacom/AD r SP SP SP Implementation CA Datacom with ECSA z/os AllowUserKeyCSA parameter CA Datacom Startup Options CA Datacom with Task Storage Data Space z/os AllowUserKeyCSA parameter CA Datacom Startup Options Data Space Owner Job Scheduling Messages Operational Considerations Additional Resources CA Datacom/DB Database System and Administrator Guide CA Datacom/AD Implementation Guide Product Home Pages CA Technical Support Glossary

3 1. Overview CA Datacom/DB or CA Datacom/AD sites running in z/os may choose to eliminate the use of user key Extended Common Storage Area (ECSA). IBM s AllowUserKeyCSA DIAG option was introduced in z/os 1.8 to deal with the potential security risk of unauthorized programs modifying CSA storage. In z/os 1.8 it defaults to YES (allowing user key CSA storage), but in z/os 1.9 it defaults to NO (disallowing user key CSA storage). CA Datacom applications communicate with the CA Datacom Multi-User Facility (MUF) through a task communications area called the Read/Write Task Storage Area (RWTSA). This can be allocated either in ECSA Key 8 storage or in a CA Datacom task storage data space for the LPAR. Some sites using the ECSA option today may choose to switch to the data space option. Those sites wishing to implement the data space option in their environments will need to take two actions: 1. Specify the DATASPACE 2048M,YES startup parameter in the Multi-User Facility (MUF) SYSIN input stream (see section 4.2.2). 2. Initialize the CA Datacom task storage data space before starting up the first MUF utilizing this option in the LPAR (see section 4.2.3). This document gives additional details about the IBM z/os AllowUserKeyCSA parameter and how CA Datacom should be tailored correspondingly to use either the ECSA option or the data space option. 2. z/os 1.9 default change that blocks user key CSA 2.1. z/os option AllowUserKeyCSA The AllowUserKeyCSA parameter resides in the system SYS1.PARMLIB(DIAGxx) member. This parameter is discussed in the MVS Initialization and Tuning Reference for z/os 1.8. It was introduced in z/os 1.8 with a default value: VSM ALLOWUSERKEYCSA(YES) This parameter controls whether applications can acquire user key storage in CSA/ECSA. Specifically, the value NO prevents user key CSA from being allocated by failing any attempt to obtain user key storage from a CSA subpool (through GETMAIN or STORAGE OBTAIN) with a B04-5C, B0A-5C, or B78-5C abend, but YES allows the use of such storage. IBM delivered this parameter defaulting to YES in z/os 1.8 to allow compatibility with various existing programs (whether IBM, CA, a third party, or userwritten) that use user key CSA/ECSA. IBM has indicated in their published literature that the default for AllowUserKeyCSA has changed to NO in z/os CA Datacom default use of ECSA By default, CA Datacom uses ECSA for storing its RWTSAs and a copy of the CA Datacom Master List. These control blocks are highly referenced across address spaces, database application regions (batch, CICS and CA Datacom Server) and the MUF region. In this mode, ECSA is used to facilitate cross-region communication. 3

4 2.3. CA Datacom alternative to ECSA: Task Storage Data Space Characteristics For several releases of CA Datacom, there has been an alternative to the use of ECSA for the execution of a CA Datacom MUF. CA Datacom/DB can execute in a mode where task-related storage (as described above) resides in an IBM data space. This data space designated for CA Datacom task storage is subject to modification only by CA Datacom programs as required to communicate with MUF. To date, the majority of our CA Datacom customers have chosen to use the ECSA default implementation rather than the alternate data space implementation. However, IBM s z/os 1.9 default of AllowUserKeyCSA(NO) may trigger additional customers to review the available options and possibly switch to the data space option. 4

5 Illustrations The following set of diagrams covers a number of sample task storage configurations for both methods: ECSA and data space. Basic Configurations These pictures describe simple MUF implementations that service database requests on a single LPAR. Note: Other data spaces are shown which are allocated to support memory resident data blocks, but they are independent of the data space acquired for CA Datacom taskrelated storage. One LPAR Two Active MUFs ECSA These MUFs are using the default ECSA task storage method. 5

6 Task Storage Data Space These MUFs have specified the startup parameter DATASPACE 2048M,YES to activate a data space to manage their task storage areas. Both In this example, MUF-X is using the default ECSA method, and MUF-Y is using the data space method to manage tasks. 6

7 Shadow MUF Configurations A Shadow MUF is a nearly identical copy of a primary (Active) MUF. Both MUFs work together as a pair to minimize any loss of data access if a failure of the primary MUF or some other unplanned outage occurs. For additional information about the implementation of a Shadow MUF, please see the Advantage CA-Datacom/DB Database and System Administrator Guide (section 3.14). Note: A Shadow MUF is not in a fully activated status. It does not use or acquire either task storage method until such time as it is actually activated. ECSA or data space storage must be available if and when a Shadow MUF is actually activated. One LPAR One Active MUF One Shadow MUF Task Storage Data Space This example shows a Shadow MUF which is standing by in case it needs to take over as the Active MUF. The Shadow MUF startup options mirror the Active MUF startup options so the data space method will be used in this case. 7

8 Two LPARs One Active MUF One Shadow MUF ECSA This is the standard setup for a multi-lpar Shadow MUF configuration. The Shadow MUF uses no task area storage until it is activated. The Shadow MUF startup options mirror the Active MUF startup options so the ECSA method will be used in this case. Task Storage Data Space In this example, both MUFs have startup options that have requested a data space to manage tasks. Note that the data space must be activated on LPAR 2 in case the Shadow MUF needs to transition to Active MUF status. 8

9 Data Sharing Configurations In a data sharing environment, there are two or more active MUFs that share a single set of database data, index, control and log files with full data integrity. Two LPARs Two Active MUFs Data Sharing Task Storage Data Space This example describes two active MUFs that are full data sharing members that utilize the data space method for task management. Both Task management for MUF-X is using a data space and MUF-Y is using ECSA. 9

10 2.4. AllowUserKeyCSA Parameter Choices Options Sites must make a decision regarding CA Datacom task storage methodology. The choices are: Accept the z/os 1.9 default of VSM ALLOWUSERKEYCSA(NO). With this setting, CA Datacom MUF regions must use the task storage data space option. Keep the z/os 1.8 default of VSM ALLOWUSERKEYCSA(YES). With this setting, CA Datacom MUF regions may use the task storage data space option or the user key ECSA option. The AllowUserKeyCSA parameter is set at the LPAR level as specified in SYS1.PARMLIB(DIAGxx) Evaluating the Options The factors to consider in making a decision about the value for AllowUserKeyCSA in z/os are security and ECSA availability. Security For a brief explanation of the AllowUserKeyCSA parameter introduced in z/os 1.8 and an IBM comment on security, see slide 24 at this link: /1.8/Ease_of_usezOS_simplification/zOS_V1R8_IBM_Health_Checker.pdf?dmuid= Note: Most CA Datacom sites use the default user key 8 ECSA method for task related storage, but both methods are supported by CA Datacom. ECSA Availability Some sites may experience shortages of contiguous ECSA storage in a given LPAR. Running MUF with a data space would be an appropriate option to consider at these sites. ECSA storage used by one or more CA Datacom MUF regions could be freed by the use of a data space, thus making additional ECSA available for other systems and applications Recommendation We suggest that individual sites should test representative workloads in their own environments before implementing a task storage methodology change for CA Datacom production systems. We continue to support both the user key ECSA option and the task storage data space option. 10

11 3. Software Requirements The following sections, by release and service pack level, contain the latest solutions to CA Datacom code resolving all known problems relating to the use of the data space methodology CA Datacom/DB r Base Level Apply following APARs: QO55018, QO73993, QO73994, QO80138, TB30025, TB30246, TB30384 Note: To obtain unconfirmed APARs (beginning with TB ), open an issue with Technical Support at SupportConnect.ca.com SP1 Apply following APARs: QO73993, QO73994, QO80138, TB30025, TB30246, TB30384 Note: For unconfirmed APARs (beginning with TB ), open an issue with Technical Support at SupportConnect.ca.com SP SP3 Apply following APARs: QO79372, QO80138 No additional maintenance necessary CA Datacom/AD r SP2 Apply following APAR: QO79372 Note: Apar QO80138 has already been applied to this product package CA Datacom/AD r SP SP SP4 Apply following APARs: QO45157, QO51001, QO90481, QO90494, QO90495 Apply following APARs: QO45157, QO51001, QO90481, QO90494, QO90495 Apply following APARs: QO51001, QO90481, QO90494, QO

12 4. Implementation 4.1. CA Datacom with ECSA z/os AllowUserKeyCSA parameter VSM ALLOWUSERKEYCSA(NO)prevents a CA Datacom MUF from coming up successfully if ECSA is the chosen mode of operation. If ECSA use is desired, this z/os option must be set to YES for the LPAR in question. This parameter is specified in SYS1.PARMLIB(DIAGxx). See the IBM z/os 1.8 MVS Initialization and Tuning Guide for specific instructions on modifying this parameter CA Datacom Startup Options The DATASPACE MUF startup option controls whether CA Datacom s task-related storage is placed in ECSA or the task storage data space. The syntax of the DATASPACE MUF startup option is: DATASPACE nnnnm,yes NO The nnnnm parameter relates to the size of covered and virtual data spaces involved with the Memory Resident Data Facility (MRDF). It does not relate to the data space CA Datacom uses for its task-related storage. If you do not specify the second parameter, it defaults to NO. Specifying NO or accepting the default indicates that ECSA is to be used for CA Datacom s task-related storage. If the DATASPACE startup option is not present, CA Datacom will use ECSA CA Datacom with Task Storage Data Space z/os AllowUserKeyCSA parameter VSM ALLOWUSERKEYCSA(NO)requires the use of the task storage data space with CA Datacom MUF regions CA Datacom Startup Options DATASPACE The DATASPACE MUF startup parameter controls whether CA Datacom s task-related storage is placed in ECSA or the task storage data space. The syntax of the DATASPACE MUF startup parameter is: DATASPACE nnnnm,yes NO The nnnnm parameter relates to the size of data spaces involved with the COVERED and VIRTUAL startup parameters (CA Datacom s Memory Resident Data Facility (MRDF)). It does not relate to the data space CA Datacom uses for its task-related storage. If you currently specify the DATASPACE startup option with the second parameter NO (or omitted), simply specify YES as the second parameter. 12

13 If you do not currently specify the DATASPACE startup option, CA recommends specifying this startup option as follows: DATASPACE 2048M,YES Specifying YES for the second parameter instructs MUF to enable using the data space for its task-related storage. The CA Datacom data space for the LPAR must have been previously initiated by the data space owner job for the MUF to enable without error. Specifying NO indicates that ECSA is to be used for CA Datacom s task-related storage. If you do not specify the second parameter, it defaults to NO. If the DATASPACE startup parameter is not present, CA Datacom will use ECSA. Relation to MRDF (COVERED and VIRTUAL) A data space is also used for the Memory Resident Data Facility (MRDF). Each area that has been specified in a COVERED or VIRTUAL startup option will occupy memory in a MRDF data space. The data spaces used for MRDF are independent of the data space used for task-related storage. This document does not discuss configuration of MRDF. For information on this topic, see the Advantage CA-Datacom/DB Database and System Administrator Guide for r11 (chapter 6). CSAFREE The CSAFREE MUF startup option controls how CA Datacom frees or retains ECSA storage at MUF termination. Sites that decide to continue using ECSA for CA Datacom task-related storage should continue to use the CSAFREE parameter as they have before. CSAFREE YES specifies that ECSA is to be freed upon termination of the MUF. CSAFREE NO specifies that MUF is not to release ECSA storage at MUF termination. When the LPAR is IPLed, ECSA can become fragmented over a period of time. It is possible that a MUF that frees its ECSA upon termination might not be able to allocate sufficient contiguous ECSA when it is restarted. This parameter, requesting MUF not to free the ECSA, is a means of ensuring that the ECSA in use will be saved and available for the next execution of this MUF. The next MUF execution will reuse the same storage that was left from the previous execution. This ensures that the MUF can come back up despite ECSA fragmentation. The only exception might be if the ECSA requirements are greater the next time MUF is restarted. For example, this can occur if the number of TASKS is increased in the MUF startup options. Sites that have been using ECSA and decide to use the data space option going forward may want to review the use of this parameter. If the data space option is used, taskrelated storage is moved to the data space, but a single 4K page of key 0, not key 8, ECSA will still be used. With a single 4K page of ECSA in use, the value of the CSAFREE parameter is minimal. Presumably 4K will always be available for the next MUF execution. After successfully implementing the data space option, it is suggested that CSAFREE be removed from the MUF startup options Data Space Owner Job Program DBDSPPR The data space owner job executes the DBDSPPR program to initiate the CA Datacom task storage data space. The program runs authorized and non-swappable. The program issues a console message to indicate its success in initiating the data space. Once initialized, the program simply waits. It will not end unless the operator issues the EOJ command (discussed in a following section), cancels the job, or performs an IPL. A TIME= parameter may be necessary on the EXEC statement in the following JCL examples. 13

14 Once started, this task storage data space will be available for use by all CA Datacom MUFs on the LPAR. In most cases, the data space can handle the task storage requirements for over 20 large CA Datacom MUF environments. Job versus started task You have the option of making the data space owner a standard batch job or a started task. Either is acceptable. Sample Job JCL The following is JCL for a sample job to start the data space: //DATASPAC JOB ( ),SYSTEMS-DEPT,CLASS=a,MSGCLASS=b //DSPACE EXEC PGM=DBDSPPR,REGION=0M //STEPLIB DD DSN=xxxxx.CUSLIB,DISP=SHR // DD DSN=xxxxx.CAILIB,DISP=SHR //SYSPRINT DD SYSOUT=* //SYSUDUMP DD SYSOUT=* //SNAPER DD SYSOUT=* //SYSOUT DD SYSOUT=* //SYSPUNCH DD SYSOUT=* Sample Started Task JCL The following example is for a PROC pointed to by the Started Task command: //DATASPAC PROC //DSPACE EXEC PGM=DBDSPPR,REGION=0M //STEPLIB DD DSN=xxxxx.CUSLIB,DISP=SHR // DD DSN=xxxxx.CAILIB,DISP=SHR //SYSPRINT DD SYSOUT=* //SYSUDUMP DD SYSOUT=* //SNAPER DD SYSOUT=* //SYSOUT DD SYSOUT=* //SYSPUNCH DD SYSOUT=* Scheduling You may want to initiate the CA Datacom task storage data space as part of the LPAR IPL process by using a started task for the data space owner. This approach would ensure the data space is present before any CA Datacom MUF regions are initiated Messages DBDSPPR successful initiation message If the CA Datacom task storage data space is not already present on this LPAR, the data space is initiated and the following message is issued. Then the program simply waits (never completes). DB02501I DATASPACE OWNER ENABLED DBDSPPR unsuccessful initiation messages If the CA Datacom data space is already present on this LPAR, DBSDPPR returns the following error message and exits with operating system condition code U0000: DB02507I ANOTHER DATA SPACE ALREADY ENABLED: JOBNAME xxxxxxxx It is possible to experience other general errors in the process of initializing a data space for CA Datacom. If this occurs, you will see the following message: 14

15 DB02502E DATASPACE OWNER ERROR nnnn The nnnn code indicates the specific error condition to be corrected. Status messages There are several status-related messages that appear in response to the STATUS command: DB02504I NO MUFS ENABLED USING THIS DATASPACE DB02505I JOBNAME xxxxxxxx SIZE 9,999,999K One line is printed per MUF currently using this data space. SIZE is the amount of contiguous memory being used by the MUF. DB02506I FREE SPACE SEGMENT(S) 9,999,999K 9,999,999K 9,999,999K This message indicates that free space is available to be used by a MUF. Multi-User Facility error messages relating to data spaces DB00205E MULTI-USER ERROR 1090 NO ROOM IN DATA SPACE There is insufficient room to enable this MUF. DB00205E MULTI-USER ERROR 1091 NO DATASPACE ENABLED No CA Datacom data space has been initialized for this LPAR for the MUF to use Operational Considerations Normal termination of the data space We provide a facility to terminate the data space used for CA Datacom task-related storage in a normal fashion. From the MVS console, issue the MVS MODIFY JOB using the EOJ option: F DATASPAC,EOJ (where DATASPAC is the data space owner job name) If there are no MUF regions using the data space, the data space will be terminated, an appropriate message will be issued and the DBDSPPR step of the data space owner job will end normally. If there are one or more MUF regions still accessing the data space, an error message is issued and the EOJ request is rejected. Normally, once the CA Datacom data space for task-related storage is initiated, it will remain until the next IPL. However, there could be a case where you would want to bring down all MUFs in the LPAR, bring down the data space and then reinitiate them without an IPL of the LPAR. See the discussion on maintenance below. Canceling the data space It is possible for the operator to cancel the data space owner job. Doing so will terminate the data space and free all storage to the operating system, of course, but it will also result in terminating all the MUFs using it on the LPAR. MUFs using the ECSA method on this LPAR would be unaffected. Any and all subsequent access to the storage within the former data space by any MUF in the LPAR using it, will fail. The MUF may not fail immediately, but it will fail on its next access to the data space storage. How to know if one or more MUFs are using the task storage data space 15

16 Issue the following MODIFY command to the data space owner region with the STATUS option: F DATASPAC,STATUS (where DATASPAC is the data space owner job name) The following is an example of output from the STATUS command for an LPAR with two MUF regions using the data space option: JOB30024 DB01311I - STATUS JOB30024 DB02505I - JOBNAME-PRODMUF1 SIZE-----2,240K JOB30024 DB02505I - JOBNAME-TESTMUFX SIZE-----2,632K JOB30024 DB02506I - FREE SPACE SEGMENT(S) 2,092,276K Using data space with mixed MUF environments Test and Production MUFs in a single LPAR Some users may have both test and production MUFs running in the same LPAR using the data space option. This is not a problem. Each MUF obtains its own storage that is segregated from all other MUFs on the LPAR. LPAR running multiple MUFs with different CA Datacom releases It is possible for a site to be running multiple CA Datacom releases. For example, while a site is upgrading from CA Datacom/AD r10 to CA Datacom/AD r11, both versions may be in use for a period of time. When this is the case, there is one restriction. The data space owner job must be running the later release, that is, r11 in the above example. Applying CA Datacom Maintenance Maintenance to DBDSPPR itself It is possible, but very unlikely, that maintenance might be needed to the DBDSPPR program. If there is maintenance to DBDSPPR, the data space must be stopped and restarted to implement the updated DBDSPPR module. Normally, you would install the maintenance into your libraries and then wait for the next IPL to implement it. If it were important to install the maintenance without performing an IPL, you would have to bring down all MUFs using the data space (determine which ones by issuing the STATUS command described above), bring down the data space (by issuing the EOJ command described above) and then rerun the job to start the data space. Maintenance to other CA Datacom modules If MUF maintenance were implemented by means of the NEWCOPY command, the storage in the data space persists and would be unaffected. If the MUF were recycled, its storage in the data space would be released as it came down and then reacquired as it came back up again. Problem resolution documentation Capturing data space storage When reporting a problem to technical support, MUF s task storage may be needed in order to diagnose the situation and resolve it. If ECSA is in use, the SNAP will dump both the MUF address space and its associated ECSA. Issue this MODIFY command from the MUF address space: F MUFJOB,SNAP (where MUFJOB is the MUF job name) 16

17 However, if a data space is in use for task storage, you would want to do a SNAP of the MUF region to get the MUF address space (including the 4K of key 0 ECSA) and then run a DBUTLTY job for the MUF region in question with the statement REPORT MEMORY=DS to get a dump of the data space storage in use for that given MUF. Thus a site switching from the use of ECSA to data space may need to get two dumps for problem resolution now instead of one as before. In some conditions perhaps diagnosing problems with products related to CA Datacom like CA Datacom CICS Services only the MUF task area storage is needed, not the MUF address space. If ECSA is in use, you would dump just the task storage by running the COMM OPTION=SNAPCSA function of DBUTLTY. However, a site switching to the use of data space would instead issue the REPORT MEMORY=DS request against the MUF of interest. SVC MUF dump parameters At the direction of CA support you may be asked to dump the content of the task storage in the data space along with other content in an SVC dump. If so, CA support can assist you in specifying the appropriate SDUMP options based on the jobname of the data space owner job. As always, CA recommends the use of the DUMP_OUTPUT SVC startup parameter to ensure that an SVC dump is taken upon any MUF failure. See the Advantage CA Datacom Database and System Administrator Guide, section for details on this startup parameter. We also recommend the use of RGN, ECSA and SQA to produce complete SVC dumps. 17

18 5. Additional Resources 5.1. CA Datacom/DB Database System and Administrator Guide The Advantage CA Datacom/DB Database and System Administrator Guide covers many of the topics discussed here. In particular, it discusses the ways to configure a MUF region and all MUF startup parameters. This manual is available on support.ca.com by following these steps: 1. Point your browser to SupportConnect.ca.com. 2. Login to SupportConnect. 3. Click on Documentation on the left side under Downloads. 4. Specify Brand CA, select CA Datacom/DB or CA Datacom/AD, select the appropriate release (r11 for DB, r10 or r11 for AD) and click Go. 5. Click on this manual or others of interest CA Datacom/AD Implementation Guide The CA Datacom/AD Implementation Guide is available with the rest of the CA Datacom/AD documentation on SupportConnect.ca.com. See the instructions just above. Be sure to select CA Datacom/AD as the product Product Home Pages The Product Home Pages are a primary source of information on how to use various CA products. To view these: 1. Point your browser to SupportConnect.ca.com. 2. Login to SupportConnect. 3. Click on Product Home Pages under Knowledge. 4. Specify CA Datacom for the product. 5. In the Technical Information section at the bottom of the page, find the Technical Document Index. 5.5 CA Technical Support CA s Technical Support organization is available for in person assistance for licensed customers. Please call CALL-CAI. 6. Glossary CA Datacom/DB Mainframe-based relational DBMS engine that is licensed for enterprisewide database services. CA Datacom/AD CA Datacom/DB package that is bundled as a database repository for a number of CA products including CA Disk, CA 11, CA Scheduler, CA Jobtrac and others. All references to CA Datacom/DB are applicable to CA Datacom/AD unless specifically noted. Multi-User Facility (MUF) The CA Datacom/DB address space that manages application database requests. Shadow MUF A nearly identical copy of a primary (Active) MUF. Both MUFs work together as a pair to minimize any loss of data access if a failure of the primary MUF, or some other unplanned outage, occurs. Read/Write Task Storage Area (RWTSA) The control block that is used to pass individual user task information from the application to the MUF. The database request area in the RWTSA contains the actual request issued by the application along with the result (error code). Common Storage Area (CSA) - The section of common area storage that is addressable by all applications. The CSA is often used to contain data frequently accessed across multiple address spaces. The size of the CSA area is established at system initialization time (IPL) and cannot change while the operating system is active. 18

19 Extended Common Storage Area (ECSA) This range of CSA, which lies above The Line (16 megabytes) but below The Bar (two gigabytes), is a kind of mirror image of the common storage area below The Line. ECSA has the same attributes as CSA, but because of the additional storage available above The Line, its size is much larger. z/os Data Space A common storage area used for data storage (no executable code) with a maximum 2 gigabyte (2 GB) allocation. Data stored in a z/os data space can be shared across multiple address spaces in the same LPAR. CA Datacom Task Storage Data Space A common storage area with maximum 2 gigabyte (2 GB) allocation that can be shared by all MUFs running on a given LPAR. CA Datacom Data Space Owner A job or started task that initiates the CA Datacom task storage data space and owns it thereafter. It can query the status of the data space, produce a snap dump of the data space contents and terminate the data space. CA Datacom Master List A CA Datacom control block that specifies the number and length of data buffers, the number of IXX buffers and the number of DXX buffers along with some additional control information. A copy of the Master List resides in ECSA. If ECSA is used for task storage, this resides in key 8 storage. If the CA Datacom data space is used for task storage, this resides in key 0 storage. 19