Migrating to Tivoli Decision Support for z/os (TDSz) Version 1.8.2

Transcription

1 Migrating to Tivoli Decision Support for z/os (TDSz) Version This document contains instructions to migrate to TDSz Version Migration paths from TDSz V1.8.0 and V1.8.1 are provided. This document contains the following sections: 1. Migrating to TDSz V1.8.2 from TDSz V Migrating to TDSz V1.8.2 from TDSz V Migrating CIMS Mainframe to TDSz Section 1. Migrating from Version This section describes how to migrate to Tivoli Decision Support for z/os Version from Version Before you migrate to TDSz V Consider the following six steps before you migrate to TDSz V1.8.2: 1. It is highly recommended to take a backup of your TDSz database. 2. Apply the PTFs for the TDSz V1.8.0 GA APAR PK53572, following the HOLD actions carefully. 3. Tivoli Decision Support for z/os (excluding Usage and Accounting Collector) V1.8.2 requires DB2 V10. If you are already on DB2 V10+, skip this step. If not, you must migrate to DB2 V10 or higher prior to commencing the migration to TDSz Once you have migrated to DB2 V10+ your TDSz application runtime must be made compatible with DB2 V10+ by following these steps: a) Apply the PTFs for PI This APAR provides sample job DRLJDCVM in the DRL180.SDRLCNTL library. This job drops and recreates system views which are DB2 version dependent. Copy member DRLJDCVM from DRL180.SDRLCNTL to &HLQ.LOCAL.CNTL and follow the instructions in the DRLJDCVM member carefully to customize the JCL prior to running the job. b) DB2 V10+ no longer supports binding DBRMs directly into plans. Instead it supports the binding of packages into plans. Pre-existing plans that are bound from DBRMs may be rebound using the REBIND command specifying the COLLID option to create packages. The following sample REBIND command creates a package called DRLPLAN and binds that back into plan DRLPLAN: REBIND PLAN(DRLPLAN) COLLID(DRLPLAN) The plan name (DRLPLAN) and collection ID (DRLPLAN) shown here are just examples. You can use any plan name and collection ID that meet your system naming standards. For more information about the BIND and REBIND commands refer to the DB2 10 for z/os Command Reference (SC ). 4. If you have installed IMS components, please take note of the following: a) With TDSz V1.8.1 support for the collection of IMS version 7 was removed, and with TDSz V1.8.2 support for the collection of IMS version 8, 9 and 10 data is removed. If you have installed these components previously, you can continue to collect data to the data tables contained in the components, but further support for these objects will not be provided you should use the higher versions IMS components instead. If customers are still using these earlier IMS versions, we recommend that they migrate to a higher level of IMS prior to migrating to TDSz V b) Checkpoint record data sets (records output to DD name DRLICHKO during the IMS collect process) created before migrating to TDSz V1.8.2 may not be usable as DRLICHKI input to IMS collect processes run after the the migration is completed, and must therefore be discarded before you migrate. To minimize data loss the last collect run before migrating to TDSz V1.8.2 should specify WRITEPENDING=YES instead of saving incomplete transaction data as checkpoint records. 5. If you have installed the Tivoli Performance Modeler for z/os component, and you have not previously applied the PTFs for PM46135, you will need to discard or extract any existing data in the TPM_LPAR_T and TPM_WORKLOAD_T tables before migrating to TDSz V After migrating to TDSz V1.8.2 any existing data in these tables will cause extraction errors. 6. Test the installation of the Tivoli Decision Support for z/os base by following these three steps: 6.1 Install the Sample component 1

2 a) Invoke the TDSz dialog with this command: TSO %DRLEINIT [RESET] b) Display the Administration window by selecting 2 (Administration) on the Primary Menu c) From the Administration window select 2 (Components) to display the Components window. d) Find (scroll down) and select the Sample component with / and press F6 (Install) to display the Installation Options window. e) From the Installation Options window, select either 1 (Online) or 2 (Batch). If you selected Batch follow these steps: Submit the install JCL. Ensure the job completes with return code 0. If errors occur review the error messages, address the problems and install the component again. If you selected Online follow these steps: If errors occur review the error messages, address the problems and install the component again. When the component has installed successfully message DRLA763 Component 'Sample Component' is installed successfully will be displayed. Review the online install output and press F3 (Exit). The Lookup Tables window is displayed, listing the component's lookup tables Press F12 (Cancel) on the Lookup Tables window, as you do not need to customize the Sample component lookup tables to verify that TDSz is operational. 6.2 Collect the Sample log a) Select 3 (Logs) from the Administration window and press Enter. b) From the Logs window, select the Sample log with / and press F11 (Collect). c) Type DRL.SDRLDEFS(DRLSAMPL) in the Data set field and press F4 (Online). TDSz starts the online collect. Upon completion it displays statistics about the data it collected. 6.3 Run Sample report a) From the Administration window, select 5 (Reports) and press Enter to display the Reports window. b) From the Reports window, select Sample Report 1 with / and press Enter to display the Data Selection window. c) Press Enter to generate the report. 2. The migration process Migrating to TDSz v consists of the following 12 steps: Step 1: SMP/E installation Step 2: Initialize the DB2 database Step 3: Review dialog parameters Step 4: Test the installation of the Tivoli Decision Support for z/os base Step 5: Re-introduce customizations Step 6: Review TDSz supplied JCL Step 7: Consider partitioning with table space profiling Step 8: Update system tables Step 9: Run migation jobs if required Step 10: Re-install components Step 11: Migrating the Usage and Accounting Collector Step 12: Migrating the IMS light feature Each step is documented here in detail: Step 1: SMP/E installation Ensure that you include the TDSz V GA APARs PI37340 and PI41870 with the SMP/E installation. The SMP/E installation of the Tivoli Decision Support for z/os base and its features is described in the Tivoli Decision Support for z/os Program Directory. Confirm that the installation completed successfully by ensuring that the following data sets were created during SMP/E installation: Tivoli Decision Support for z/os data sets Data set name DRL182.SDRLCNTL DRL182.SDRLDEFS DRL182.SDRLEXEC DRL182.SDRLLOAD Description Sample jobs and DB2 DBRM module Definitions of records, tables, and other objects REXX execs Load modules 2

3 DRL182.SDRLSKEL DRL182.SDRLA400 DRL182.SDRLWS Local data sets Data set name &HLQ.LOCAL.ADMCFORM &HLQ.LOCAL.CHARTS &HLQ.LOCAL.CNTL &HLQ.LOCAL.DEFS &HLQ.LOCAL.EXEC &HLQ.LOCAL.MESSAGES &HLQ.LOCAL.REPORTS &HLQ.LOCAL.USER.DEFS ISPF skeletons OS/400 Workstation Description Local GDDM-Presentation Graphics Facility(GDDM-PGF) interactive chart utility (GDDM/ICU) formats Saved graphic reports (GDDM ADMGDF format) Local Tivoli Decision Support for z/os jobs Local Tivoli Decision Support for z/os definitions Local Tivoli Decision Support for z/os execs Messages sent through the dialog Saved tabular reports Local Tivoli Decision Support for z/os user/alter definitions Language-dependent Tivoli Decision Support for z/os data sets The last three letters in these data set names indicate the language version: ENU for English or JPN for Japanese. For example, SDRLRENU contains the English report definition files. The corresponding Japanese version is SDRLRJPN. Data set name DRL182.SDRLFxxx DRL182.SDRLMxxx DRL182.SDRLPxxx DRL182.SDRLRxxx DRL182.SDRLTxxx Description GDDM/ICU formats ISPF messages ISPF panels Definitions of reports ISPF tables Step 2 Initialize the database A new DBRM is supplied with Tivoli Decision Support for z/os Version Follow these instructions to rebind to the new DBRM: 1. Copy member DRLJDBND in the DRL182.SDRLCNTL library to the &HLQ.LOCAL.CNTL library. 2. Review the customization instructions in the job prolog. Note: A person with DB2 SYSADM authority (or someone with the authority to bind plans) must submit the job. 3. Submit the job Step 3 Review dialog parameters TDSz V1.8.2 contains APARs which introduce changes to the following dialog parameters: Dialog parameter Parameter description Description of change APAR def_db2plan def_drlshwid DB2 plan name Show TDSz system info These are new parameters. db2ver DB2 version This variable no longer allows alphabetical characters - only numerical values are allowed. For example, specify '10' for DB2 V10. If you have not previously installed the PTFs for these APARs listed above, review the changes in the new sample DRLFPROF from DRL182.SDRLCNTL and customize your userid.drlfprof accordingly. Refer to the Administration Guide and Reference for more information on these dialog parameters. If you made changes to your userid.drlfprof in this step, you must start TDSz specifying the RESET parameter in the next step to activate these DRLFPROF changes. PM07437 PI09853 Step 4 Test the installation of the Tivoli Decision Support for z/os base To test the TDSz base the Sample component must be installed. Follow the instructions documented in Step 6 of Before you migrate to TDSz V on page 1. 3

4 Step 5 Re-introduce customizations If you have previously made changes to TDSz supplied objects in your &HLQ.LOCAL.DEFS, you will need to manually apply the TDSz V changes to these objects in your &HLQ.LOCAL.DEFS. Identify the V182 changes by comparing each object in your &HLQ.LOCAL.DEFS with the DRL182.SDRLDEFS version. If you do not take this action, the V changes will not be installed when you re-install the components, as TDSz installs objects from &HLQ.LOCAL.DEFS instead of DRL182.SDRLDEFS, in effect bypassing the V changes. Step 6 Review TDSz supplied JCL The DRL182.SDRLCNTL library contains several batch jobs that you can copy to &HLQ.LOCAL.CNTL and customize with, for example, correct data set names or the DB2 subsystem ID. If you have previously customized sample JCL from DRL180.SDRLCNTL, review the V1.8.2 changes in the new sample JCL provided in DRL182.SDRLCNTL and manually apply these changes your customized versions in &HLQ.LOCAL.CNTL. Step 7 Consider partitioning with table space profiling Tivoli Decision Support for z/os v1.8.2 introduces table space profiles. A table space profile allow you to define in one place all the settings for the creation of DB2 table spaces, tables, and indexes. These settings could then be used at component install time for all the DB2 table spaces, tables, and indexes. The following components are table space profiling enabled: Key Performance Metric (KPM) CICS (default profile enabled: partitioning by growth) Key Performance Metric (KPM) DB2 (default profile enabled: partitioning by growth) Key Performance Metric (KPM) IMS (default profile enabled: partitioning by growth) Key Performance Metric (KPM) z/os (default profile enabled: partitioning by growth) All CICS partitioned components (default profile enabled: partitioning by range) Please take note of the following: A migration path is not provided to migrate previously installed components to partitioned data tables. The table space profiling allows you to implement partitioning by growth or range when installing any of the enabled components for the first time, without having to customize any of the object definitions. Although default table space profiles are provided for these components, you have the option to review and modify all the profile settings (which includes partitioning settings as well as table space and index parameters) before you install the components. When you are migrating to TDSz V you need to follow these steps to activate table space profiling before you install any of the components listed above: 1. Run job DRLJDBIP to create the DB2 storage groups required for partitioning support. Only run this job if you have not previously created the storage groups required for partitioning. 2. Run migration job DRLJGENL to insert the default supplied profiles into lookup tables GENERATE_PROFILES and GENERATE_KEYS. 3. Before you install the component review the contents of these lookup tables and amend if required. Refer to the component's customization chapter in the Reference manual for more information on this step. Step 8 Update system tables Follow these steps to update the system tables: a) Invoke the TDSz dialog with this command: TSO %DRLEINIT [RESET] b) Display the Administration window by selecting 2 (Administration) on the Primary Menu c) From the Administration window select 1 (System) to display the System window. d) From the System window select 2 (System tables). e) From the System Tables window press F6 to update the system tables. You can also create, update, and delete Tivoli Decision Support for z/os system tables by running TSO/ISPF in batch mode. Sample job DRLJCSTB shows an example of how to submit a request to program DRLEAPST to create system tables. You can update or delete system tables by passing a different request to DRLEAPST, as described in the comments in DRLJCSTB. 4

5 The TSO/ISPF batch job step must include: DRLFPROF DD referring to your DRLFPROF data set ISPPROF DD referring to a PDS with RECFM=F and LRECL=80. If you have made changes to the Tivoli Decision Support for z/os dialog parameters and have not also made those changes in your DRLFPROF data set, then the ISPPROF DD should refer to your ISPF profile data set and you should not specify the RESET parameter to DRLEINIT. ISPPLIB, ISPMLIB, ISPSLIB, and ISPTLIB DDs referring to your Tivoli Decision Support for z/os and ISPF panel, message, skeleton, and table data sets. SPLOG DD referring to a data set with RECFM=VA and LRECL=125. SYSTSIN DD referring to instream data, or a data set, containing a command to invoke DRLEINIT, for example: IPSTART CMD(%DRLEINIT RESET) DRLBIN (batch input) DD referring to instream data or a data set containing a command to invoke DRLEAPST with a request to perform the required function, for example: DRLEAPST CREATE DRLEAPST is the only program that can be invoked in this way. Step 9 Run migration jobs if required The following table lists all migration jobs which may need to be run to migrate to V Your service level will determine which migration jobs must be run to migrate to V Use this table as a checklist to plan the migration of the TDSz database. The Mandatory column indicates whether it is mandatory or optional to run the migration job. Optional migration jobs improve the accuracy of data previously collected. Mandatory migration jobs must be run to make your database compatible with the TDSz V definitions. The APAR column lists the V1.8.0 APARs with which the migration jobs were introduced. You only need to run a migration job if you have not previously installed the APAR in V For example, if you have the DB2 component installed, and you have not previously installed the PTFs for PK89999, you must run DRLJAGGR. Component Migration job Mandatory Y/N Description DB2 DRLJAGGR Y Create lookup table AGGR_VALUE for use in table DB2_PACKAGE_H update definitions. APAR PK89999 DRLJDB3 Y Change primary key of DB2_PACKAGE_* tables. PK52681 DRLJDB08 N Single table space replaced with multiple for this component's data tables. PK61570 DRLJDB09 Y Make table space DRLSDB2 available to all DB2 subcomponents. PK85596 DRLJDBAA N Fix IDAA time values in DB2 data tables. Only run this job if you have previously applied IDAA support APAR PM CICS Any DRLJC001 N If you have compression on and have records written to the DRLNDICT dataset that require reprocessing: this job resets the length of the DRLNDICT records in order for the record to be processed correctly on the subsequent collect. IMS V7, 8, 9 and 10 PM91971 PM03113 DRLJCSXX N Drop unused table spaces. PM77416 DRLJCIF1 Y Rebuild the CICS_FIELD table. If this table has been customized (member DRLTCIFI), these customizations must be re-applied before you run this migration job. See Step 5 above for instructions on reintroducing customizations. Although this job only needs to be run once during the migration, it needs to be run if the PTFs for any of the APARs have not previously been applied. DRLJMIC2 N These components are no longer supported. This optional job removes the component objects from the system tables. If you have installed any of these components previously, and wish to continue collecting data to the data tables, do not run this job as it will disable the collection of data. The job contains a step per IMS version only execute the steps relating to the versions you want to remove from your system tables. PM23679 PM40234 PM82516 Network VTAM DRLJNW01 N Delete the incorrect entries in the system tables which are causing PM

6 Statistics the -104 when doing an uninstall of the Network VTAM Statistics component. TCPIP DRLJTCP2 N Correct values in several TCPIP data tables PM09069 Websphere Message Broker z/os (MVS) System z/os Performance Management (MVSPM) DRLJWMB N Fix aggregation problem in tables WMB_NODE_W, WMB_MESSAGE_W, WMB_TERMINAL_W, WMB_THREAD_W. PK74898 DRLJMVPR N Fix aggregation problem in table MVS_PROCESSOR_M. PK74091 DRLJMVPH N Correct values in the MVS_7700_HBA_* tables. Only run this job if you have previously applied TS7700 support with PK PM30613 #DRLJMVAM Y Change primary key of table MVS_ACCNT_PGM_T. PM89335 *SQL N Set MSU_4HRA to null in tables MVS_LPAR_D and MVS_LPAR_M for all rows where it should not have been collected, using the following SQL statement as template: UPDATE &PREFIX.table_name SET MSU_4HRA = NULL WHERE FROM_LPAR_NO <> LPAR_NO OR PROCESSOR_TYPE <> 'CP'; Only run this SQL script if you have previously applied APAR PM61917 to add column MSU_4HRA. DRLJMVOM N Swap contents of column SYSCALL_NUMBER and CPU_TIME of tables MVS_OMVSADDR_T and MVS_OMVSADIS_T. *SQL N Set MSU_4HRA to null in table MVSPM_LPAR_H for all rows where it should not have been collected, using the following SQL statement as template: UPDATE &PREFIX.table_name SET MSU_4HRA = NULL WHERE FROM_LPAR_NO <> LPAR_NO OR PROCESSOR_TYPE <> 'CP'; Only run this SQL script if you have previously applied APAR PM61917 to add column MSU_4HRA. * No migration job is supplied for this data correction. You may use the optional sample SQL provided in the Description column for the data correction. # Step3 of this job will result in RC8 due to existing objects. Member DRLTMVAP is executed to recreate table MVS_ACCNT_PGM_T. However DRLTMVAP also contains the definition for table MVS_ACCNT23_PGM_T. If the RC8 in Step3 is due to the fact that MVS_ACCNT23_PGM_T exists already, you can ignore this return code. RC8 in Step3 will not halt the execution of this job. PI17092 PI20342 PI17092 Step 10 Re-install components Now re-install ALL previously installed components. Step 11 Migrating the Usage and Accounting Collector If you have not previously installed the PTFs for the APARs listed below, please consider the implications of the changes introduced with these APARs: UAC Utility Description of change APAR DRLCDTLD DRLCUN01 The UAC CICS dictionary must be rebuilt if you have not previously applied all of these APARs to V Refer to the Tivoli Decision Support for z/os Usage and Accounting Collector User Guide (Chapter 7: Dictionary - CIMSDTVS) for information on building the dictionary using the dictionary utility DRLCDTLD. If you want to to create DRLCUNIV Chargeback Records from IDMS v18 or higher SMF records, you must provide provide an additional control PM13229 PM63035 PM69394 PM98973 PI

7 statement to identify that DRLCUN01 is processing an IDMS v18 or higher SMF log. The control statement is IDMS SMF18 REC. Step 12 Migrating the IMS light feature TDSz V1.8.2 includes changes to the IMS Shared Queue Feature log procedures via the following APARS: PM22818 PM35939 PM62915 PM64657 PM68203 PM83774 PM91671 PM99061 PI17543 PI26186 If you have not installed all of these APARs previously, and you are using the IMS light feature to collect data remotely with program DRLSLOGP for subsequent transmission and processing at a central site, you must review and re-run your customized version of sample job DRLJCSQL. The re-created light feature load library must then be re-sent to all remote sites executing DRLSLOGP. The migration to TDSz Version is now completed. Section 2. Migrating from Version This section describes how to migrate to Tivoli Decision Support for z/os Version from Version Before you migrate to TDSz V Consider the following six steps before you migrate to TDSz V1.8.2: 1. It is highly recommended to take a backup of your TDSz database. 2. Apply the PTFs for the TDSz V1.8.1 GA APARs PM04508 & PM10178, following the HOLD actions carefully. 3. Tivoli Decision Support for z/os (excluding Usage and Accounting Collector) V1.8.2 requires DB2 V10. If you are already on DB2 V10+, skip this step. If not, you must migrate to DB2 V10 or higher prior to commencing the migration to TDSz Once you have migrated to DB2 V10+ your TDSz application runtime must be made compatible with DB2 V10+ by following these steps: a) Apply the PTFs for PI This APAR provides sample job DRLJDCVM in the DRL181.SDRLCNTL library. This job drops and recreates system views which are DB2 version dependent. Copy member DRLJDCVM from DRL181.SDRLCNTL to &HLQ.LOCAL.CNTL and follow the instructions in the DRLJDCVM member carefully to customize the JCL prior to running the job. b) DB2 V10+ no longer supports binding DBRMs directly into plans. Instead it supports the binding of packages into plans. Pre-existing plans that are bound from DBRMs may be rebound using the REBIND command specifying the COLLID option to create packages. The following sample REBIND command creates a package called DRLPLAN and binds that back into plan DRLPLAN: REBIND PLAN(DRLPLAN) COLLID(DRLPLAN) The plan name (DRLPLAN) and collection ID (DRLPLAN) shown here are just examples. You can use any plan name and collection ID that meet your system naming standards. For more information about the BIND and REBIND commands refer to the DB2 10 for z/os Command Reference (SC ). 4. If you have installed IMS components, please take note of the following: a) With TDSz V1.8.1 support for the collection of IMS version 7 was removed, and with TDSz V1.8.2 support for the collection of IMS version 8, 9 and 10 data is removed. If you have installed these components previously, you can continue to collect data to the data tables contained in the components, but further support for these objects will not be 7

8 provided you should use the higher versions IMS components instead. If customers are still using these earlier IMS versions, we recommend that they migrate to a higher level of IMS prior to migrating to TDSz V b) Checkpoint record data sets (records output to DD name DRLICHKO during the IMS collect process) created before migrating to TDSz V1.8.2 may not be usable as DRLICHKI input to IMS collect processes run after the the migration is completed, and must therefore be discarded before you migrate. To minimize data loss the last collect run before migrating to TDSz V1.8.2 should specify WRITEPENDING=YES instead of saving incomplete transaction data as checkpoint records. 5. If you have installed the Tivoli Performance Modeler for z/os component, and you have not previously applied the PTFs for PM46135, you will need to discard or extract any existing data in the TPM_LPAR_T and TPM_WORKLOAD_T tables before migrating to TDSz V After migrating to TDSz V1.8.2 any existing data in these tables will cause extraction errors. 6. Test the installation of the Tivoli Decision Support for z/os base by following these three steps: 6.1 Install the Sample component a) Invoke the TDSz dialog with this command: TSO %DRLEINIT [RESET] b) Display the Administration window by selecting 2 (Administration) on the Primary Menu c) From the Administration window select 2 (Components) to display the Components window. d) Find (scroll down) and select the Sample component with / and press F6 (Install) to display the Installation Options window. e) From the Installation Options window, select either 1 (Online) or 2 (Batch). If you selected Batch follow these steps: Submit the install JCL. Ensure the job completes with return code 0. If errors occur review the error messages, address the problems and install the component again. If you selected Online follow these steps: If errors occur review the error messages, address the problems and install the component again. When the component has installed successfully message DRLA763 Component 'Sample Component' is installed successfully will be displayed. Review the online install output and press F3 (Exit). The Lookup Tables window is displayed, listing the component's lookup tables Press F12 (Cancel) on the Lookup Tables window, as you do not need to customize the Sample component lookup tables to verify that TDSz is operational. 6.2 Collect the Sample log a) Select 3 (Logs) from the Administration window and press Enter. b) From the Logs window, select the Sample log with / and press F11 (Collect). c) Type DRL.SDRLDEFS(DRLSAMPL) in the Data set field and press F4 (Online). TDSz starts the online collect. Upon completion it displays statistics about the data it collected. 6.3 Run Sample report a) From the Administration window, select 5 (Reports) and press Enter to display the Reports window. b) From the Reports window, select Sample Report 1 with / and press Enter to display the Data Selection window. c) Press Enter to generate the report. 2. The migration process Migrating to TDSz v consists of the following 12 steps: Step 1: SMP/E installation Step 2: Initialize the DB2 database Step 3: Review dialog parameters Step 4: Test the installation of the Tivoli Decision Support for z/os base Step 5: Re-introduce customizations Step 6: Review TDSz supplied JCL Step 7: Consider partitioning with tablespace profiling Step 8: Update system tables Step 9: Run migation jobs if required Step 10: Re-install components Step 11: Migrating the Usage and Accounting Collector Step 12: Migrating the IMS light feature Each step is documented here in detail: 8

9 Step 1: SMP/E installation Ensure that you include the TDSz V GA APAR PI37340 and PI41870 with the SMP/E installation. The SMP/E installation of the Tivoli Decision Support for z/os base and its features is described in the Tivoli Decision Support for z/os Program Directory. Confirm that the installation completed successfully by ensuring that the following data sets were created during SMP/E installation: Tivoli Decision Support for z/os data sets Data set name DRL182.SDRLCNTL DRL182.SDRLDEFS DRL182.SDRLEXEC DRL182.SDRLLOAD DRL182.SDRLSKEL DRL182.SDRLA400 DRL182.SDRLWS Description Sample jobs and DB2 DBRM module Definitions of records, tables, and other objects REXX execs Load modules ISPF skeletons OS/400 Workstation Local data sets Data set name &HLQ.LOCAL.ADMCFORM &HLQ.LOCAL.CHARTS &HLQ.LOCAL.CNTL &HLQ.LOCAL.DEFS &HLQ.LOCAL.EXEC &HLQ.LOCAL.MESSAGES &HLQ.LOCAL.REPORTS &HLQ.LOCAL.USER.DEFS Description Local GDDM-Presentation Graphics Facility(GDDM-PGF) interactive chart utility (GDDM/ICU) formats Saved graphic reports (GDDM ADMGDF format) Local Tivoli Decision Support for z/os jobs Local Tivoli Decision Support for z/os definitions Local Tivoli Decision Support for z/os execs Messages sent through the dialog Saved tabular reports Local Tivoli Decision Support for z/os user/alter definitions Language-dependent Tivoli Decision Support for z/os data sets The last three letters in these data set names indicate the language version: ENU for English or JPN for Japanese. For example, SDRLRENU contains the English report definition files. The corresponding Japanese version is SDRLRJPN. Data set name DRL182.SDRLFxxx DRL182.SDRLMxxx DRL182.SDRLPxxx DRL182.SDRLRxxx DRL182.SDRLTxxx Description GDDM/ICU formats ISPF messages ISPF panels Definitions of reports ISPF tables Step 2 Initialize the database A new DBRM is supplied with Tivoli Decision Support for z/os Version Follow these instructions to rebind to the new DBRM: 1. Copy member DRLJDBND in the DRL182.SDRLCNTL library to the &HLQ.LOCAL.CNTL library. 2. Review the customization instructions in the job prolog. Note: A person with DB2 SYSADM authority (or someone with the authority to bind plans) must submit the job. 3. Submit the job Step 3 Review dialog parameters TDSz V1.8.2 contains APARs which introduce changes to the following dialog parameters: Dialog parameter Parameter description Description of change APAR def_db2plan def_drlshwid DB2 plan name Show TDSz system info These are new parameters. db2ver DB2 version This variable no longer allows alphabetical characters - only numerical values are allowed. For example, specify '10' for DB2 V10. PM07437 PI

10 If you have not previously installed the PTFs for these APARs listed above, review the changes in the new sample DRLFPROF from DRL182.SDRLCNTL and customize your userid.drlfprof accordingly. Refer to the Administration Guide and Reference for more information on these dialog parameters. If you made changes to your userid.drlfprof in this step, you must start TDSz specifying the RESET parameter in the next step to activate these DRLFPROF changes. Step 4 Test the installation of the Tivoli Decision Support for z/os base To test the TDSz base the Sample component must be installed. Follow the instructions documented in Step 6 of Before you migrate to TDSz V on page 8. Step 5 Re-introduce customizations If you have previously made changes to TDSz supplied objects in your &HLQ.LOCAL.DEFS, you will need to manually apply the TDSz V changes to these objects in your &HLQ.LOCAL.DEFS. Identify the V182 changes by comparing each object in your &HLQ.LOCAL.DEFS with the DRL182.SDRLDEFS version. If you do not take this action, the V changes will not be installed when you re-install the components, as TDSz installs objects from &HLQ.LOCAL.DEFS instead of DRL182.SDRLDEFS, in effect bypassing the V changes. Step 6 Review TDSz supplied JCL The DRL182.SDRLCNTL library contains several batch jobs that you can copy to &HLQ.LOCAL.CNTL and customize with, for example, correct data set names or the DB2 subsystem ID. If you have previously customized sample JCL from DRL181.SDRLCNTL, review the V1.8.2 changes in the new sample JCL provided in DRL182.SDRLCNTL and manually apply these changes your customized versions in &HLQ.LOCAL.CNTL. Step 7 Consider partitioning with table space profiling Tivoli Decision Support for z/os v1.8.2 introduces table space profiles. A table space profile allow you to define in one place all the settings for the creation of DB2 table spaces, tables, and indexes. These settings could then be used at component install time for all the DB2 table spaces, tables, and indexes. The following components are table space profiling enabled: Key Performance Metric (KPM) CICS (default profile enabled: partitioning by growth) Key Performance Metric (KPM) DB2 (default profile enabled: partitioning by growth) Key Performance Metric (KPM) IMS (default profile enabled: partitioning by growth) Key Performance Metric (KPM) z/os (default profile enabled: partitioning by growth) All CICS partitioned components (default profile enabled: partitioning by range) Please take note of the following: A migration path is not provided to migrate previously installed components to partitioned data tables. The table space profiling allows you to implement partitioning by growth or range when installing any of the enabled components for the first time, without having to customize any of the object definitions. Although default table space profiles are provided for these components, you have the option to review and modify all the profile settings (which includes partitioning settings as well as table space and index parameters) before you install the components. When you are migrating to TDSz V you need to follow these steps to activate table space profiling before you install any of the components listed above: 1. Run job DRLJDBIP to create the DB2 storage groups required for partitioning support. Only run this job if you have not previously created the storage groups required for partitioning. 2. Run migration job DRLJGENL to insert the default supplied profiles into lookup tables GENERATE_PROFILES and GENERATE_KEYS. 10

11 3. Before you install the component review the contents of these lookup tables and amend if required. Refer to the component's customization chapter in the Reference manual for more information on this step. Step 8 Update system tables Follow these steps to update the system tables: a) Invoke the TDSz dialog with this command: TSO %DRLEINIT [RESET] b) Display the Administration window by selecting 2 (Administration) on the Primary Menu c) From the Administration window select 1 (System) to display the System window. d) From the System window select 2 (System tables). e) From the System Tables window press F6 to update the system tables. You can also create, update, and delete Tivoli Decision Support for z/os system tables by running TSO/ISPF in batch mode. Sample job DRLJCSTB shows an example of how to submit a request to program DRLEAPST to create system tables. You can update or delete system tables by passing a different request to DRLEAPST, as described in the comments in DRLJCSTB. The TSO/ISPF batch job step must include: DRLFPROF DD referring to your DRLFPROF data set ISPPROF DD referring to a PDS with RECFM=F and LRECL=80. If you have made changes to the Tivoli Decision Support for z/os dialog parameters and have not also made those changes in your DRLFPROF data set, then the ISPPROF DD should refer to your ISPF profile data set and you should not specify the RESET parameter to DRLEINIT. ISPPLIB, ISPMLIB, ISPSLIB, and ISPTLIB DDs referring to your Tivoli Decision Support for z/os and ISPF panel, message, skeleton, and table data sets. SPLOG DD referring to a data set with RECFM=VA and LRECL=125. SYSTSIN DD referring to instream data, or a data set, containing a command to invoke DRLEINIT, for example: IPSTART CMD(%DRLEINIT RESET) DRLBIN (batch input) DD referring to instream data or a data set containing a command to invoke DRLEAPST with a request to perform the required function, for example: DRLEAPST CREATE DRLEAPST is the only program that can be invoked in this way. Step 9 Run migration jobs if required The following table lists all migration jobs which may need to be run to migrate to V Your service level will determine which migration jobs must be run to migrate to V Use this table as a checklist to plan the migration of the TDSz database. The Mandatory column indicates whether it is mandatory or optional to run the migration job. Optional migration jobs improve the accuracy of data previously collected. Mandatory migration jobs must be run to make your database compatible with the TDSz V definitions. The APAR column lists the V1.8.1 APARs with which the migration jobs were introduced. You only need to run a migration job if you have not previously installed the APAR in V For example, if you have the DB2 component installed, and you have not previously installed the PTFs for PM91971, you must run DRLJDBAA. Component Migration job Mandatory Y/N Description DB2 DRLJDBAA N Fix IDAA time values in DB2 data tables. Only run this job if you have previously applied IDAA support APAR PM CICS Any DRLJC001 N If you have compression on and have records written to the DRLNDICT dataset that require reprocessing: this job resets the length of the DRLNDICT records in order for the record to be processed correctly on the subsequent collect. APAR PM91971 PM11488 DRLJCSXX N Drop unused table spaces. PM77416 DRLJCIF1 Y Rebuild the CICS_FIELD table. If this table has been customized (member DRLTCIFI), these customizations must be re-applied before you run this migration job. See Step 5 above for instructions on reintroducing customizations. Although this job only needs to be run once during the migration, it needs to be run if the PTFs for any of the APARs have not previously been applied. PM23679 PM40234 PM

12 IMS V7, 8, 9 and 10 Network VTAM Statistics DRLJMIC2 N These components are no longer supported. This optional job removes the component objects from the system tables. If you have installed any of these components previously, and wish to continue collecting data to the data tables, do not run this job as it will disable the collection of data. The job contains a step per IMS version only execute the steps relating to the versions you want to remove from your system tables. DRLJNW01 N Delete the incorrect entries in the system tables which are causing the -104 when doing an uninstall of the Network VTAM Statistics component PM03940 TCPIP DRLJTCP2 N Correct values in several TCPIP data tables PM09069 z/os System (MVS) z/os Performance Management (MVSPM) DRLJMVPH N Correct values in the MVS_7700_HBA_* tables. PM30613 #DRLJMVAM Y Change primary key of table MVS_ACCNT_PGM_T. PM89335 *SQL N Set MSU_4HRA to null in tables MVS_LPAR_D and MVS_LPAR_M for all rows where it should not have been collected, using the following SQL statement as template: UPDATE &PREFIX.table_name SET MSU_4HRA = NULL WHERE FROM_LPAR_NO <> LPAR_NO OR PROCESSOR_TYPE <> 'CP'; Only run this SQL script if you have previously applied APAR PM61917 to add column MSU_4HRA. DRLJMVOM N Swap contents of column SYSCALL_NUMBER and CPU_TIME of tables MVS_OMVSADDR_T and MVS_OMVSADIS_T. *SQL N Set MSU_4HRA to null in table MVSPM_LPAR_H for all rows where it should not have been collected, using the following SQL statement as template: UPDATE &PREFIX.table_name SET MSU_4HRA = NULL WHERE FROM_LPAR_NO <> LPAR_NO OR PROCESSOR_TYPE <> 'CP'; Only run this SQL script if you have previously applied APAR PM61917 to add column MSU_4HRA. * No migration job is supplied for this data correction. You may use the optional sample SQL provided in the Description column for the data correction. # Step3 of this job will result in RC8 due to existing objects. Member DRLTMVAP is executed to recreate table MVS_ACCNT_PGM_T. However DRLTMVAP also contains the definition for table MVS_ACCNT23_PGM_T. If the RC8 in Step3 is due to the fact that MVS_ACCNT23_PGM_T exists already, you can ignore this return code. RC8 in Step3 will not halt the execution of this job. Step 10 Re-install components PI17092 PI20342 PI17092 Now re-install ALL previously installed components. Step 11 Migrating the Usage and Accounting Collector If you have not previously installed the PTFs for the APARs listed below, please consider the implications of the changes introduced with these APARs: UAC Utility Description of change APAR DRLCDTLD The UAC CICS dictionary must be rebuilt if you have not previously applied all of these APARs to V Refer to the Tivoli Decision Support for z/os Usage and Accounting Collector User Guide (Chapter 7: Dictionary - CIMSDTVS) for information on building the dictionary using the dictionary utility DRLCDTLD. PM13229 PM63035 PM69394 PM

13 DRLCUN01 If you want to to create DRLCUNIV Chargeback Records from IDMS v18 or higher SMF records, you must provide provide an additional control statement to identify that DRLCUN01 is processing an IDMS v18 or higher SMF log. The control statement is IDMS SMF18 REC. PI08264 Step 12 Migrating the IMS light feature TDSz V1.8.2 includes changes to the IMS Shared Queue Feature log procedures via the following APARS: PM22818 PM35939 PM62915 PM64657 PM68203 PM83774 PM91671 PM99061 PI17543 PI26186 If you have not installed all of these APARs previously, and you are using the IMS light feature to collect data remotely with program DRLSLOGP for subsequent transmission and processing at a central site, you must review and re-run your customized version of sample job DRLJCSQL. The re-created light feature load library must then be re-sent to all remote sites executing DRLSLOGP. The migration to TDSz Version is now completed. Section 3. Migrating CIMS Mainframe to TDSz If you have previously migrated CIMS Mainframe to TDSz you can ignore this section. As of TDSz Verion the CIMS Mainframe product is integrated into TDSz as the Usage and Accounting Collector (UAC) feature. Additional support and enhancements will be included in TDSz and not CIMS Mainframe. All CIMS Mainframe implementations must be migrated to TDSz. Note: Spectrum Writer is not included with UAC. Former CIMS Lab customershave a perpetual license for Spectrum Writer and should retain the CIMSLab data sets so that they can make use of it. For support of Spectrum Writer, contact Pacific Systems. Customers that require access to CIMSMainframe should contact IBM support. Processing Considerations CIMS Mainframe implemented new record types in These 79x record types are the preferred record types. In TDSz, the 79x records are the only types supported. The first thing to research for the TDSz migration is the current record type created by CIMS Mainframe. If the CIMS Mainframe subsystem programs (CIMSACCT, CIMSCMF2, CIMSDB2, CIMSDISK, CIMSTAPE, CIMSUNIV, and CIMSUN02) are creating DDNAME CIMSACT2 and this is the data set that is passed on to other processing. Then the 79x records are created and you are in an excellent position to migrate to TDSz (continue to JCL Considerations when using 79x records on the next page). Switching to 79x records The CIMSBILL program is not supported in TDSz. It has been replaced with the DRLCMONY program (the TDSz version of CIMSMONY). Executing program CIMSBILL is another indicator that the 79x records are not being created. The conversion from CIMSBILL to CIMSMONY is documented in the CIMS Mainframe Data Collector and Chargeback System Installation and Upgrade Guide. The documentation will explain the options available and decisions that must to be made to migrate to TDSz and use the DRLCMONY (CIMSMONY) program. TDSz will not produce the old 99x records. The default processing in TDSz is the creation of 79x records to the DDNAME CIMSACT2. Switching to the 79x records can be done with the migration to TDSz or it can be done while executing the CIMS Mainframe release. In either case, there are JCL changes that must be made and these are documented in the CIMS Mainframe Data Collector and Chargeback System Installation and Upgrade Guide. JCL Considerations when using 79x records The CIMS Mainframe programs were all renamed for TDSz. The program names start with DRLC instead of CIMS. For example, in CIMS Mainframe there is a CIMSEXTR program but in TDSz this is now called DRLCEXTR. The TDSz install links the new programs with an ALIAS of the CIMS Mainframe program name. Therefore, JCL that executes the 13

14 CIMS Mainframe program CIMSEXTR will also work with TDSz because the DRLCEXTR has an alias of CIMSEXT. TDSz has made very few changes to the control statements that are entered via the DDNAME CIMSCNTL. The CIMS Mainframe JCL that references CIMS.DATAFILE should also work with TDSz. The TDSz DDNAMEs have not changed. CIMS Mainframe JCLs should work with the new TDSz Usage and Accounting Collector as long as the 79x records are were being produced in the CIMS Mainframe JCLs. Changes should be limited to STEPLIB changes to point to the TDSz load library. TDSz no longer performs password checking. The DDNAME CIMSPASS can be removed from the TDSz JCL, but the presence of passwords will not cause a problem. Release Considerations This table outlines the release requirements for migrating to TDSz: The above release csonsiderations are general rules that take into account file conversions. The various files used by CIMS Mainframe must be converted to the 12.2/ level before migrating to TDSz. The CIMS Mainframe Data Collector and Chargeback System Installation and Upgrade Guide contains the detailed instructions for upgrading the CIMS Mainframe product. Use the instructions in these manuals to complete the upgrade. The upgrade procedures for the early releases (11.5 and 11.4) are documented in the 12.0 CIMS Mainframe Data Collector and Chargeback System Installation and Upgrade Guide. This manual is available from the CIMS Mainframe Information Center web page: All the procedures to convert the older CIMS Mainframe files are included in The 12.0 manual should be consulted to see the steps required to convert the older releases to Then the manual can be used to complete the upgrade from 12.0 to New name conventions The CIMS Mainframe parts are renamed in TDSz to use the TDSz naming conventions. As stated earlier, the load modules have a new name that starts with DRLC (example DRLCEXTR instead of CIMSEXTR). The CIMS.DATAFILE is no longer distributed with TDSz. The sample JCLs are now found in DRL182.SDRLCNTL. The number of JCL members was reduced by including most control statements as instream data instead of separate members. All CIMS.DATAFILE members were renamed by changing or adding a 4 character prefix. The prefixes are mapped as : Prefix DRLC DRLN DRLM DRLK Description CLIST or REXX Sample JCL Control statements, record definitions,...etc. DRLMR - Record descriptions Dictionary definition Use this table as a cross-reference to map the CIMS Mainframe CIMS.DATAFILE member names to the new names in TDSz: AAAALIST ALIAS ALIASACC ATMONJCL BUDGETIN BUDJCL1 DRLMLIST DRLMALS DRLMALSA DRLNATMN DRLMBGTI DRLNBDGT 14

15 CALENDAR CALNDR13 CICSASML CICSRC01 CICSRC02 CIMRCT54 CIMRECAD CIMRECCA CIMRECDC CIMRECFA CIMRECID CIMRECIF CIMRECIS CIMRECMN CIMRECMO CIMRECMQ CIMRECM2 CIMRECOR CIMRECRM CIMRECRO CIMRECSJ CIMRECSP DRLMCLDR DRLMCL13 DRLNUR01 DRLMRC01 DRLMRC02 DRLMRT54 DRLMRAD DRLMRCA DRLMRDC DRLMRFA DRLMRID DRLMRIF DRLMRIS DRLMRMN DRLMRMO DRLMRMQ DRLMRM2 DRLMROR DRLMRRM DRLMRRO DRLMRSJ DRLMRSP 15

16 CIMS Mainframe TDSz CIMRECTL DRLMRTL CIMRECTM DRLMRTM CIMRECVT DRLMRVT CIMRECZA DRLMRZA CIMRECZB DRLMRZB CIMRECZC DRLMRZC CIMREC01 DRLMR01 CIMREC02 DRLMR02 CIMREC03 DRLMR03 CIMREC04 DRLMR04 CIMREC06 DRLMR06 CIMREC10 DRLMR10 CIMREC11 DRLMR11 CIMREC12 DRLMR12 CIMREC14 DRLMR14 CIMREC15 DRLMR15 CIMREC16 DRLMR16 CIMREC28 DRLMR28 CIMREC29 DRLMR29 CIMREC30 DRLMR30 CIMSADA1 DRLNADA CIMSBETA DRLNBETA CIMSCICS DRLNCICS CIMSCLNT DRLNCLNT CIMSCMPL DRLNCMPL CIMSDB2 DRLNDB2 CIMSDB2L DRLNDB2L CIMSDCOL DRLNDCOL CIMSDISK DRLNDISK CIMSDTC DRLNDTC CIMSDTD DRLNDTD CIMSDTLD DRLNDTLD CIMSEOM DRLNEOM CIMSEXTR DRLNEXTR CIMSFALC DRLNFALC CIMSFTP DRLNFTP CIMSFTPG DRLNFTPG CIMSGDG DRLNGDG CIMSGDG1 DRLNGDG1 CIMSIMS DRLNIMS CIMSINFO DRLNINFO 16

17 CIMS Mainframe TDSz DCTNSPMU DRLKSPMU DCTNSPMW DRLKSPMW DCTNSTOD DRLKSTOD DCTNSTOO DRLKSTOO DCTNSTOU DRLKSTOU DCTNSTOW DRLKSTOW DCTNTAPE DRLKTAPE DCTNTLMS DRLKTLMS DCTNTMS DRLKTMS DCTNTSO DRLKTSO DCTNUNIV DRLKUNIV DCTNWEBS DRLKWEBS DCTNZARA DRLKZARA DCTNZASJ DRLKZASJ DCTNZASP DRLKZASP DCTNZDCB DRLKZDCB DCTNZDCC DRLKZDCC DCTNZIDB DRLKZIDB DCTNZIDC DRLKZIDC DCTNZIDL DRLKZIDL DCTNZIDO DRLKZIDO DCTNZZZZ DRLKZZZZ EDITJCL DRLNEDIT ETCICS DRLMECIC ETDASD DRLMEDSD ETDB2 DRLMEDB2 ETGLOBAL DRLMEGLB ETR791 DRLME791 ETR792 DRLME792 ETR793 DRLME793 ETR799 DRLME799 ETR999 DRLME999 ETTAPE DRLMETPE ETWEBS DRLMEWEB EXTERNAL DRLMTRAN FILELIST DRLMFLST FTP#READ DRLMFTP# FTPDATE DRLCFTPD FTPDATEG DRLCFTPE FTPID DRLMFTPI IDMSJCL1 DRLNIDM1

18 CIMS Mainframe IDMSJCL2 IDMSJCL3 MONYCTL3 NORMCPU SMFMERGE SMFREC04 SMFREC05 SMFREC06 SMFREC26 SMFREC30 SURCPU TDSz DRLNIDM2 DRLNIDM3 DRLMMNY DRLMNCPU DRLNSMFM DRLMRS04 DRLMRS05 DRLMRS06 DRLMRS26 DRLMRS30 DRLMSCPU

19 19