Unicenter CA-11 Restart and Tracking Release 3.0 Database Configuration Options

Transcription

1 Overview The purpose of this document is to assist you in choosing the best configuration options for your Unicenter Restart and Tracking environment. We will discuss the available sharing options and the advantage and disadvantage of each. We will look at possible release 2.2 configurations and how to best migrate those configurations to 3.0 to achieve the same results. We will also discuss failure and recovery. Recommended ervice Levels We recommend that you have CA-Datacom /AD P03 installed. P03 contained fixes for the XCF interface and re-incorporated the CAICCI interface into CA-Datacom/AD. If you decide that you need to use CAICCI, then P03 is no longer recommended but instead is a requirement. We also recommend that you are current on Unicenter Maintenance. Database Access Options CA-Datacom/AD provides for four access options. Local access via VC The fastest access to a CA-Datacom/AD database is through the product VC. This can only be used if you are running Unicenter on the same system image as the CA-Datacom/AD Multi-User Facility (MUF). Even if another access option is used to share the database the CA-Datacom/AD VC is required. On the system running the MUF the VC will be used for access. If you do not need to share the Unicenter Database, then this method is all that is needed. haring using XCF Almost as fast as the VC is XCF, IBM s Cross-ystem Coupling Facility. It should be noted that even though XCF has that word Coupling in it, this facility is a PLEX service and does not require a Coupling Facility. XCF is the best way to share the Unicenter database. XCF is fast, easy to configure in CA-Datacom/AD and provides an easy way to disconnect and re-connect from Unicenter if the MUF needs to be moved or a failure on the MUF system occurs. The disadvantage of XCF is that all systems that share the database using XCF must be in the same PLEX. XCF only occurs through PLEX connected systems. 1

2 haring using CAICCI CAICCI is CA s Common Communication Interface that can be defined to use various protocols to communicate between systems. CAICCI does not require that all systems be in the same PLEX. The disadvantage is the speed. CAICCI normally uses TCPIP or VTAM for communication, which does not perform as well as XCF. Depending on workload this may not be a concern. This option should only be used if you require sharing to systems where XCF is not available and the slower performance is not a concern. haring using the Coupling Facility CA-Datacom/AD is capable of sharing a database directly between two systems using Coupling Facility structure to synchronize the updates. This method, MUFPLEX, is the most complex and least performing of the options. Unicenter has not been certified to run in this environment, and we strongly recommend against using MUFPLEX. Though this may seem to provide better recovery, it in fact adds unnecessary complexity that will slow your recovery process and require Unicenter outages in some cases to resume after a failure. Once again, this method should not be used. Comparison Option peed Implementation Recovery VC Very Fast imple imple XCF Fast imple imple CAICCI lower imple imple Hierarchy etting aside MUFPLEX, the three remaining options can all be defined together. If defined the selection of which method to use will proceed as follows. 1. If the CA-Datacom/AD MUF is on the same LPAR, the VC will be used. 2. If the VC cannot be used, XCF is defined and the MUF is available on a XCF connected LPAR, the XCF connection will be used. 3. If neither of the previous methods is available, and CAICCI is defined, CAICCI will be used. This allows you to define all the protocols that will be used to access a CA-Datacom/AD MUF once in the DBIDPR and use that same module in all the systems that are sharing the MUF, no matter what method will be used for access. Even though the CA-Datacom/AD VC may not be used to access the database, it must be installed on each system that will run Unicenter. 2

3 Maintenance Task Considerations In Release 2.2 of Unicenter, batch jobs were run to perform JEHF and CMT maintenance. For the JEHF you ran the JEHF Purge job and for CMT U11D9015, with required a product outage. In release 3.0, the purging of old history and deletion of old CMT definitions, is done by the maintenance subtask, MANT, in the DBA address space. ince the MANT subtask performs this processing for all systems sharing a database, this task should only be run in one of the s that share the database. This should be the system that is local and uses the VC to access CA- Datacom/AD. This task is controlled by the MAINTTME= parameter in s Init Deck. If MAINTTME=0 is specified the MANT task will not be attached and will not run. If MAINTTME=1 or higher, the MANT task will be attached at startup, immediately begin processing and when complete, will wait the specified number of days before processing again. ou may choose to have finer control of when this task runs, by setting MAINTTME=0 in all systems, and issuing the comchar TART MANT command to when you want the maintenance to run. This will attach the subtask and perform the maintenance and then terminate the task. Previous Unicenter Configurations There are three basic sharing configurations that could be used in Unicenter Release ingle system (non-shared) Each Unicenter has its own CMT and JEHF with no contention. 2. hared access within a PLEX and JE Complex hared so that jobs submitted to the shared JE will update the single CMT and JEHF no matter which system in the complex the job executes. This allows reruns of jobs to run on different system than the production job. 3. hared access between systems that are not in the same PLEX or JE Complex was allowed if shared DAD was available. Was not recommended since separate JE environments meant there was no protection from duplicate job names being run at the same time. haring in Unicenter 2.2 was done using shared DAD to allow multiple systems to take turns accessing the PD CMT file and the VAM JEHF files. Periodic outages of Unicenter systems sharing the CMT and JEHF were required to Compress the PD and Reorganize the VAM file. topping Unicenter on all systems also required the initiators to be drained to eliminate the accesses to Unicenter. Migration Recommendations 3

4 ingle system If you currently have a separate CMT and JEHF for each of your systems or only have one system, then you should continue to use that configuration. Each system in this environment has its own JE environment and therefore can schedule jobs that are unique only to that one system. Attempting to share a Unicenter database in this environment would require that you maintain uniqueness in jobnames across your multiple JE environments. In Unicenter 3.0 this will require that you install and run a separate Multi-User Facility (MUF) on each system. Each system will also have a separate Unicenter Database with separate datasets. The VC is the only definition that will be defined. This configuration is depicted below. B DBA C DBA VC VC CA-Datacom/AD CA-Datacom/AD JOB TP DN JHF JOB TP DN JHF In this configuration each system, B and C, is self contained, requiring no sharing of the database. The access from Unicenter to CA-Datacom/AD is all done locally through the VC and each system has a separate set of Data Area datasets for the Unicenter Database. The DBIDPR module only specifies that VC and the UBID that will be used. This module is created and assembled by install job AXIN05 in the CA-Datacom/AD AMPJCL library. Changing the module is described in the CA-Datacom/DB Database and ystem Administrator Guide in section 3.4 Modifying DBIDPR Parameters. The member, DBIDPR, is added to 4

5 the CUMAC library and the assembled and linked into the CULIB LOADLIB. A sample definition for this module is shown below. TITLE 'DATACOM/DB - TEM ID BLOCK' DBID VC=246,UBID=0 END The startup parameters for CA-Datacom/AD, in the DBDATIN1 member of CUMAC, need to allow for enough tasks to support your Unicenter DBA task. This is specified in the TAK statement. The statement format is TAK num,32k,0,0,xcf,cci This means that num is the maximum number of requestors to use the MUF. The xcf and cci values do not need to be specified for this configuration and should each be set to zero. For Unicenter the minimum values can be calculated for each system using the DBTAK parameter value from the Unicenter Init Deck as follows. num = DBTAK + # of Unicenter Online Users + 1 (MANT task) + 4 (DB Utilities Batch Jobs) The xcf and cci must be set to zero. 5

6 Example In the following example, the Unicenter DBA system will only access the MUF locally. DBA will have 5 tasks accessing the database, and have a maintenance task that runs periodically (this is the +1, in the formula above). We will allow 10 connections from online users and 4 additional tasks to be available for CA-Datacom/AD batch utilities that may be run. Using the formula given above: num = DBTAK + # of Unicenter Online Users + 1 (MANT task) + 4 (DB Utilities Batch Jobs) num = = 20 The xcf and cci must be set to zero. In the CA-Datacom/AD DBDATIN1 tartup Parameters TAK 20,32K,0,0,0,0 In the DBIDPR TITLE 'DATACOM/DB - TEM ID BLOCK' DBID VC=246,UBID=0 END Failure and recovery Failure in this configuration only affects one system, since the database cannot be shared. In the event that CA-Datacom/AD fails, the Unicenter DBA task will suspend processing and hold all Unicenter processing until CA-Datacom/AD is restarted. The REUME command can then be issued to Unicenter to reconnect and continue processing. In the event that the system fails only that system is affected. Normal IPL start up will occur. Unicenter or your scheduling product should be queried to determine the status of jobs that were running at the time of failure. 6

7 Using one Unicenter Database within a PLEX If you are currently sharing the Unicenter 2.2 CMT and JEHF in a PLEX environment, this same arrangement can be accomplished with a ingle MUF and XCF connections. Using CA-Datacom/AD the database is not physically shared, using shared DAD, as it was in previous releases of Unicenter. haring a database uses IBM s XCF to access the data from a single CA-Datacom/AD Multi-User Facility (MUF) task. There can only be one MUF task in the shared environment. The diagram below shows how three systems share a single Unicenter database in a PLEX environment. PLEX 1 A DBA C DBA B DBA X C F VC CA-Datacom/AD X C F JOB TP DN JHF 7

8 In this environment, the CA-Datacom/AD MUF task only runs on one system in PLEX. All access to the data is through this task. In order to allow the MUF to be accessed from other systems in the PLEX, additional parameters must be specified in CA-Datacom/AD s start up parameters in the DBDATIN1 member of CUMAC. These parameters allow for the XCF connections to be established and are shown below. MUF mufname TAK num,32k,0,0,xcf,cci XCFFROM jobname,groupname The MUF parameter provides a unique name that will be used to connect to the MUF using XCF. The XCFFROM parameter identifies the jobname of the task that will be connecting and a XCF group name that will be used. The jobname name should be specified as an asterisk (*) to allow any jobname to access the database through XCF. ince access by both the Unicenter Tasks and TO users may use XCF for database access, the jobname cannot be set to a fixed value. We recommend that you specify XCFFROM *,groupname Both the mufname and the groupname are arbitrary names but must be unique in the PLEX. CA11MUF and CA11GRP, respectively, would be good choices for names. In addition, the TAK parameter must be changed to allow for XCF connections. The statement format is TAK num,32k,0,0,xcf,cci, where num is the maximum number of requestors to use the MUF from any system, xcf is the number of those requestors that can access through XCF, and cci is for CAICCI accesses. For Unicenter minimum values can be calculated using the DBTAK parameter value from the Unicenter Init Deck as follows. xcf = total of DBTAK values from all systems without a MUF + # of XCF Unicenter Online Users num = DBTAK from the system with a MUF + xcf + # of local Unicenter Online Users + 1 (MANT task) + 4 (DB Utilities Batch Jobs) cci must be set to 0. 8

9 Each Unicenter DBA address space uses a module, DBIDPR, to access CA-Datacom/AD. Changing the module is described in the CA-Datacom/DB Database and ystem Administrator Guide in section 3.4 Modifying DBIDPR Parameters. To utilize XCF, two keywords must be added as shown below. TITLE 'DATACOM/DB - TEM ID BLOCK' DBID VC=246,UBID=0,TOMUF=mufname,TOGROUP=groupname END The TOMUF= identifies the mufname of the MUF to be accessed and the TOGROUP= identifies the XCF GROUP that the communication belongs to. The mufname and groupname defined here must match the values added to the start up parameters for the MUF. Both the VC parameters and the XCF parameters are specified to allow the same DBIDPR to be used on all sharing systems. Example In the following example, three Unicenter DBA systems will be accessing the MUF, one locally, and two through XCF. We have chosen a muf name of CA11MUF and a XCF group name of CA11GRP. Each DBA will have 5 tasks accessing the database, and the local DBA will have a maintenance task that runs periodically (this is the +1, in the formula above). We will allow 10 local and 10 XCF connections from online users. We will add 4 additional local tasks to be available for CA-Datacom/AD batch utilities that may be run. Using the formulas above: xcf = total of DBTAK values from all systems without a MUF + # of XCF Unicenter Online Users xcf = (5 x 2) + 10 = 20 num = DBTAK from the system with a MUF + xcf + # of local Unicenter Online Users + 1 (MANT task) + 4 (DB Utilities Batch Jobs) num = = 40 cci must be set to 0. In the CA-Datacom/AD DBDATIN1 tartup Parameters MUF CA11MUF TAK 40,32K,0,0,20,0 XCFFROM *,CA11GRP 9

10 In the DBIDPR TITLE 'DATACOM/DB - TEM ID BLOCK' DBID VC=246,UBID=0,TOMUF=CA11MUF,TOGROUP=CA11GRP END Failure and recovery Please refer to the section below Relocating the MUF and operationally recovering from failure 10

11 Using one Unicenter Database with systems in a separate PLEX or MONOPLEX configurations ome Unicenter 2.2 clients have configured their CMT and JEHF to be shared between systems that run as separate JE complexes and separate PLEXs. In 2.2 this could be done since the datasets were physically shared on shared DAD, but required the systems share a resource control system such as CA-MIM or IBM s GR, or exclude Unicenter s access so that volume reserves could be used to serialize access. Operationally, unique job names had to be enforced using a standard to prevent different jobs with the same job name from accessing the same information in Unicenter. For this reason, we did not recommend that you use this configuration in 2.2, and still do not recommend it in 3.0. If you have this environment currently, and want to continue using Unicenter in this configuration, you may do so in 3.0 using CAICCI. Before making that decision you may want to verify your environment. In some sites you may have separate JE complexes running within a single PLEX. This configuration allows the use of the high speed XCF communications, as described in the previous section, while maintaining your multiple job submission environments. If you do have separate PLEXs or MONOPLEX, you can still share the MUF with Unicenter s in other PLEXs, by using CAICCI. CAICCI is the CA Common Communication Facility that is part of the CA Common ervices. CAICCI will allow you to define connections between your non-plexed system using TCPIP or VTAM connection. ince this is a network protocol, it does not have the PLEX restrictions that XCF does. If you have both same-plex systems and out-of- PLEX systems, then both XCF and CCI connections should be defined. While CAICCI is generally fast enough for most environments, the XCF connections are many times faster. Therefore, it would be a good practice to run the MUF on one of the machines in the PLEX with the largest batch workload, and use XCF connections within that PLEX. Then CAICCI connections can be defined to support the systems outside the PLEX. The Diagram below describes this environment. 11

12 PLEX 1 A DBA C DBA B DBA X C F VC CA-Datacom/AD X C F JOB TP DN JHF CAICCI Monoplex 2 Monoplex 3 CAICCI D DBA E DBA 12

13 In this environment, the CA-Datacom/AD MUF task only runs on one system. All access to the data is through this MUF region. In order to allow the MUF to be accessed from other systems in the PLEX, additional parameters must be specified in CA-Datacom/AD s start up parameters in the DBDATIN1 member of CUMAC. These parameters allow for the CAICCI and XCF connections to be established and are shown below. MUF mufname TAK num,32k,0,0,xcf,cci XCFFROM jobname,groupname The MUF parameter provides a unique name that will be used to connect to the MUF using CAICCI or XCF. The XCFFROM only applies if you have XCF connections also. If you have XCF connections you should add the XCFFROM parameter as described in the previous section. The mufname is an arbitrary name but must be unique in the system. CA11MUF would be good choice for a name. In addition, the TAK parameter must be changed to allow for XCF and CAICCI connections. The statement format is: TAK num,32k,0,0,xcf,cci Where, num is the maximum number of requestors to use the MUF from all systems, xcf is the number of those requestors that can access through XCF, and cci is for CAICCI accesses. For Unicenter minimum values can be calculated using the DBTAK parameter value from the Unicenter Init Deck as follows. xcf = total of DBTAK values from all systems without a MUF that will connect through XCF + # of XCF Unicenter Online Users cci = total of DBTAK values from all systems without a MUF that will connect through CAICCI + # of CAICCI Unicenter Online Users num = DBTAK from the system with a MUF + xcf + cci + # of local Unicenter Online Users + 1 (MANT task) + 4 (DB Utilities Batch Jobs) If you are using CAICCI only the xcf value will be zero. Each Unicenter DBA address space uses a module, DBIDPR, to access CA-Datacom/AD. Changing the module is described in the CA-Datacom/DB Database and ystem Administrator Guide in section 3.4 Modifying DBIDPR Parameters. To utilize CAICCI, keywords must be added as shown below. 13

14 TITLE 'DATACOM/DB - TEM ID BLOCK' DBID VC=246,UBID=0,CCIAPPL=mufname{,CCI=sysname} END The CCIAPPL= identifies the mufname of the MUF to be accessed. The CCI= identifies the CAICCI name of the system that the MUF is running on. If the CAI= is not specified, CAICCI will search the available CAICCI systems to locate the specified CCIAPPL. We recommend that you do not specify CCI. Omitting this parameter will provide more flexibility and allow you to move the MUF to another CAICCI connected system, without having to change the DBIDPR module. The mufname defined here must match the value added to the start up parameters for the MUF. Both the VC parameters and the CAICCI parameters are specified to allow the same DBIDPR to be used on all sharing systems. If you will be able to share the MUF using XCF also, your DBIDPR would include the TOMUF and TOGROUP keywords as describe in the prior section. In this case your DBIDPR will have the following format. TITLE 'DATACOM/DB - TEM ID BLOCK' DBID VC=246,UBID=0,TOMUF=mufname,TOGROUP=groupname, CCIAPPL=mufname{,CCI=sysname} END X Performance Considerations with CAICCI ince your access using CAICCI will be many times slower than local or xcf, it is recommended that online access to Unicenter not be done on systems that are connected to CA-Datacom/AD by CAICCI. TO performance groups reduce your performance even further if commands are slow to respond. In particular commands that look at the all or a large portion of the database, such as the LJOB *, can result in extremely long delays in online response. To avoid this, use the online interface only on local or XCF connected systems 14

15 Example 1 CAICCI Only In the following example, three Unicenter DBA systems will be accessing the MUF, one locally, and two through CAICCI. No XCF connections will be used. We have chosen a MUF name of CA11MUF, and we will not specify the CAICCI system name where the MUF will run. Each DBA will have 5 tasks accessing the database, and the local DBA will have a maintenance task that runs periodically (this is the +1, in the formula above). We will allow 10 local connections from online users, but since the fastest online access is local, we will only allow for 5 CAICCI accesses. We will add 4 additional local tasks to be available for CA-Datacom batch utilities that may be run. Using the formulas above: xcf = total of DBTAK values from all systems without a MUF that will connect through XCF + # of XCF Unicenter Online Users xcf = = 0 cci = total of DBTAK values from all systems without a MUF that will connect through CAICCI + # of CAICCI Unicenter Online Users cci = (5 x 2) + 5 = 15 num = DBTAK from the system with a MUF + xcf + cci + # of local Unicenter Online Users + 1 (MANT task) + 4 (DB Utilities Batch Jobs) num = = 35 In the CA-Datacom/AD DBDATIN1 tartup Parameters MUF CA11MUF TAK 35,32K,0,0,0,15 In the DBIDPR TITLE 'DATACOM/DB - TEM ID BLOCK' DBID VC=246,UBID=0,CCIAPPL=CA11MUF END 15

16 Example 2 CAICCI and XCF In the following example, five Unicenter DBA systems will be accessing the MUF, one locally, two through XCF and two through CAICCI. This is the same configuration shown in the picture near the beginning of this section. We have chosen a MUF name of CA11MUF, a XCF group name of CA11GRP and we will not specify the CAICCI system name where the MUF will run. Each DBA will have 5 tasks accessing the database, and the local DBA will have a maintenance task that runs periodically (this is the +1, in the formula above). We will allow 10 local, 10 XCF and 5 CAICCI connections from online users. We will add 4 additional local tasks to be available for CA-Datacom/AD batch utilities that may be run. Using the formulas above: xcf = total of DBTAK values from all systems without a MUF that will connect through XCF + # of XCF Unicenter Online Users xcf = (5 x 2) + 10 = 20 cci = total of DBTAK values from all systems without a MUF that will connect through CAICCI + # of CAICCI Unicenter Online Users cci = (5 x 2) + 5 = 15 num = DBTAK from the system with a MUF + xcf + cci + # of local Unicenter Online Users + 1 (MANT task) + 4 (DB Utilities Batch Jobs) num = = 55 In the CA-Datacom/AD DBDATIN1 tartup Parameters MUF CA11MUF TAK 55,32K,0,0,20,15 XCFFROM *,CA11GRP In the DBIDPR TITLE 'DATACOM/DB - TEM ID BLOCK' DBID VC=246,UBID=0,CCIAPPL=CA11MUF, TOMUF=CA11MUF,TOGROUP=CA11GRP END X Failure and recovery Please refer to the section below Relocating the MUF and operationally recovering from failure 16

17 Relocating the MUF and operationally recovering from failure cheduled CA-Datacom/AD Outage Periodically, there will be a need to take a system out of service. If a single CA-Datacom MUF is servicing multiple systems, and the system that is running the MUF is the one that needs to be taken out or IPL ed, then there is a need to move the MUF to another system to allow the remaining systems to continue processing. This can be accomplished with minimum impact, by using Unicenter s uspend and Resume commands. Before shutting down the MUF, issue the Unicenter UPEND command to each of the Unicenter DBA systems. Each Unicenter will then complete any in-flight processing and close access to CA-Datacom/AD. The CA-Datacom/AD MUF can then be shutdown on one system and restarted on another system. Once restarted the Unicenter REUME command can be issued to each of the Unicenter systems, allowing them to re-establish there database connection and continue processing where they left off. If you are planning to IPL the system that the MUF is on, you will need to shutdown the Unicenter DBA on that system instead of suspending it. Unicenter cannot be shutdown while in a suspended state. If you do suspend Unicenter you should restart the MUF on another system, and then resume Unicenter, followed by a normal shutdown. ome considerations for moving the MUF are: 1. The systems that the MUF can be moved to must share DAD. The CA- Datacom/AD files and data areas must be on that shared DAD. 2. The CA-Datacom/AD VC must be installed on the target system. This is done by the CA9 proc that runs during IPL. ee the CA-Datacom/AD installation guide for more information. 3. The same proc can be used if the systems share a PROCLIB. 4. If you are an Advantage CA-Datacom/DB customer and you may need to move the MUF to a system that is not licensed for DB, it is recommended that you install and use CA-Datacom/AD for Unicenter on all systems. Databases that are initialized and populated under Advantage CA-Datacom /DB are not useable in a CA-Datacom/AD MUF. 17

18 Here is an example where you have the MUF running on CPU1 and you need to IPL CPU1 without disrupting CPU2 batch processing: 1) CPU2: =UPEND (pause Unicenter processing on CPU2) 2) CPU1: =HUTDOWN AL (bring down Unicenter on CPU1) 3) CPU1: F muf,eoj (stop MUF on CPU1) 4) CPU1: - normal shutdown of CPU1 continues - 5) CPU2: TART muf (tart the MUF on CPU2) 6) CPU2: =REUME (tart Unicenter activity back up on CPU2) Note: where "=" is the Unicenter command character At step 1) above, you may want to route the command over to CPU2 with the MV command: RO cpu2,=upend or start some automation script to handle all of the transition commands automatically Unscheduled CA-Datacom/AD Outage Failure of the CA-Datacom/AD MUF will affect all systems that are connected to that MUF. In Unicenter, the absence of the MUF will cause the Unicenter DBA task to automatically enter a suspended state. Two messages will be issued to console, the second one being non-deleteable, for each sharing system: U11D UPENDING DATABAE ACTIVIT U11D ENTER 'REUME' COMMAND WHEN READ Processing will remain suspended until the MUF has been restarted on the same or another connected system and the Unicenter REUME command is issued to each of the Unicenter systems. The restart considerations for the MUF on a secondary system are the same as those discussed under cheduled Datacom Outage and should be addressed when installing the system.. 18