SLR to Tivoli Performance Reporter Migration Cookbook

SLR to Tivoli Performance Reporter for OS/390
Migration Cookbook
Mike Foster, Mauro Basile, Malcolm Pearse

International Technical Support Organization

http://www.redbooks.ibm.com

SG24-5128-00

SG24-5128-00

International Technical Support Organization

SLR to Tivoli Performance Reporter for OS/390
Migration Cookbook

February 1999

Take Note!
Before using this information and the product it supports, be sure to read the general information in
Appendix D, “Special Notices” on page 193.

First Edition (February 1999)

This edition applies to Version 1, Release Number 4 of Tivoli Performance Reporter for
OS/390, Program Number 5695-101 for use with OS/390, MVS/ESA or MVS/SP as it relates
to migration of information from Version 3, Release 3 of the IBM Service Level Reporter,
Program Number 5665-397.

Comments may be addressed to:
IBM Corporation, International Technical Support Organization
Dept. OSJB Building 045 Internal Zip 2834
11400 Burnet Road
Austin, Texas 78758-3493

When you send information to IBM, you grant IBM a non-exclusive right to use or distribute the
information in any way it believes appropriate without incurring any obligation to you.
© Copyright International Business Machines Corporation 1999. All rights reserved
Note to U.S Government Users – Documentation related to restricted rights – Use, duplication or disclosure is
subject to restrictions set forth in GSA ADP Schedule Contract with IBM Corp.

Contents

Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii

Tables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xi

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
The Team That Wrote This Redbook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Comments Welcome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv

Part 1. Migration Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Chapter 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Why Upgrade to Performance Reporter? . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Overview of Performance Reporter . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Introducing the Log Collector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.1 Log Collector Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4 Comparison between PR and SLR . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4.1 Summarize Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.4.2 Join/Merge Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.4.3 Directly Modify Log Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.4.4 Purging Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.4.5 Table Lookup During Collect. . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.4.6 Calculations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.4.7 Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.4.8 PR Data Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.4.9 SLR Data Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.5 How to Use This Redbook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Chapter 2. Migration Approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.1 Introduction to Performance Reporter Migration . . . . . . . . . . . . . . . . . 17
2.2 The Migration Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3 Developing a Migration Plan. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3.1 Analysis of What to Migrate . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.3.2 Elements of a Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.3.3 Assessment of the Importance of Data . . . . . . . . . . . . . . . . . . . . 22
2.3.4 Assessment of Possible Migration Approaches. . . . . . . . . . . . . . 23
2.3.5 Other Plan Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Part 2. Migration Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Chapter 3. Migrating Data from Predefined SLR Tables. . . . . . . . . . . . 31
3.1 Example of Data Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

© Copyright IBM Corp. 1999 iii

3.2 Deviation from Default Data Migration . . . . . . . . . . . . . . . . . . . . . . . . 45
3.3 Other Modifications to the Standard Migration . . . . . . . . . . . . . . . . . . 52
3.3.1 Addition or Modification of Computed Columns. . . . . . . . . . . . . . 53
3.3.2 Addition or Modification of Data Columns . . . . . . . . . . . . . . . . . . 53
3.3.3 Migrating User-Defined Tables . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Chapter 4. Migrating User-Defined A.L.L Based Tables and Data . . . . 57
4.1 The A.L.L. Table Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.2 Component Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.3 Populating Your New Tables with Migrated Data . . . . . . . . . . . . . . . . 81

Chapter 5. Migrating Parameter Table Data . . . . . . . . . . . . . . .. . .. . . 85
5.1 Reenter Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . .. . . 86
5.2 DB2 Load Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . .. . . 87
5.3 IXF Unload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . .. . . 93
5.4 Populate the Lookup Table Defined by the New Component .. . .. . . 96

Chapter 6. Migrating SLR Reports . . . . . . . .. . . . . . . . . . . . . . . . . . . . 99
6.1 SLR Report Description . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . 100
6.2 Setting Migration Parameters for Reports . .. . . . . . . . . . . . . . . . . . . 103
6.3 Example of Report Migration . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . 106

Chapter 7. Miscellaneous Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
7.1 Setting Purge Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
7.2 Executing Purge Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
7.2.1 Online Purge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
7.2.2 Batch Purge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
7.3 Parallel Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

Appendix A. The Key to Predefined Migration - DLRMIGRATION . . . 137
A.1 Viewing DLRMIGRATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
A.2 DRLMIGRATION Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
A.2.1 MVS_SYSTEM_M . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
A.2.2 MVS_ADDRSPACE_M. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
A.2.3 MVS_ADDRDISTR_M . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
A.2.4 MVS_PROGRAM_M . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
A.2.5 MVS_COMPCODE_M . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
A.2.6 MVS_WORKLOAD_M . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
A.2.7 MVS_PRINTER_M . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
A.2.8 MVS_TAPE_M . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
A.2.9 MVS_IPL_T . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
A.2.10 AVAILABILITY_M . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
A.2.11 DFSMS_DATASET_D/M . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
A.2.12 DFSMS_VOLUME_D/M . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

iv SLR to Tivoli Performance Reporter for OS/390

A.2.13 DFSMS_BACKUP_D/M . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
A.2.14 DFSMS_MIGRATION_D/M . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
A.2.15 DFSMS_DASD_CAP_D/M . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
A.2.16 DFSMS_TAPE_CAP_D/M . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
A.2.17 DFSMS_ACTIVITY_M . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
A.2.18 DFSMS_LAST_RUN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
A.2.19 DFSMS_MIGRATE_DAYS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
A.2.20 DFSMS_DS_OWNER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
A.2.21 DB2_TRANSACTION_W . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
A.2.22 DB2_USER_TRAN_W . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
A.2.23 DB2_APPL_DIST_W . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
A.2.24 DB2_USER_AP_DIST_W . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
A.2.25 DB2_TRAN_DIST_W . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
A.2.26 DB2_USER_DIST_W . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
A.2.27 DB2_APPLICATION_W . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
A.2.28 DB2_USER_APPL_W . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
A.2.29 EREP_DASD_M . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
A.2.30 EREP_VTAM_M . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
A.2.31 EREP_CPU_ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
A.2.32 EREP_DASD_GROUP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
A.2.33 VMACCT_SESSION_M . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
A.2.34 VMPRF_SYSTEM_M . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
A.2.35 VMPRF_PROCESSOR_M . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
A.2.36 VMPRF_USER_M . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
A.2.37 VMPRF_DASD_M . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
A.2.38 CICS_TRANSACTION_W . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
A.2.39 CICS_M_GLOBAL_D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
A.2.40 MSG_SYSLOG_TYPE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
A.2.41 MSG_SYSLOG_M . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
A.2.42 AVAILABILITY_W/M . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
A.2.43 NW_NPM_UTIL_W. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
A.2.44 NW_ALERT_BASIC_W . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
A.2.45 NW_ALERT_GENERIC_W . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
A.2.46 NW_SESSION_FAIL_W . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
A.2.47 NW_RTM_RESONSE_W/M . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
A.2.48 NW_SM_UTIL_W . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
A.2.49 NW_NCP_UTIL_W . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
A.2.50 NW_PU_UTIL_W . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
A.2.51 NW_LINE_UTIL_W. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
A.2.52 NW_NPM_TRANSIT_W/M . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
A.2.53 NW_X25LN_UTIL_W . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
A.2.54 NW_X25PU_UTIL_W . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
A.2.55 NW_X25NI_UTIL_W. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

v

A.2.56 NW_NTRIP_UTIL_W . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
A.2.57 NW_NTRIL_UTIL_W . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
A.2.58 NW_NEO_UTIL_W . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
A.2.59 IMS_TRANSACTION_W . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
A.2.60 OPC_AUTO_EVENT_M . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
A.2.61 OPC_MCP_M . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
A.2.62 OPC_MISSED_FB_M. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
A.2.63 OPC_OPER_EVENT_M . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
A.2.64 OPC_OPER_EVENT_T . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180

Appendix B. Predefined SLR Tables to PR Tables Cross Reference . 181
B.1 SLR to PR Cross Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
B.2 PR to SLR Cross Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185

Appendix C. Parameter Table to Lookup Table Cross Reference . . . 189

Appendix D. Special Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

Appendix E. Related Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
E.1 International Technical Support Organization Publications . . . . . . . . . . 197
E.2 Redbooks on CD-ROMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
E.3 Other Publications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

How to Get ITSO Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
How IBM Employees Can Get ITSO Redbooks . . . . . . . . . . . . . . . . . . . . . . . 199
How Customers Can Get ITSO Redbooks. . . . . . . . . . . . . . . . . . . . . . . . . . . 200
IBM Redbook Order Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201

Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203

List of Abbreviations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207

ITSO Redbook Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211

vi SLR to Tivoli Performance Reporter for OS/390

Figures

1. Performance Reporter Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Overview of Performance Reporter Data Collection Flow . . . . . . . . . . . . . 11
3. Overview of Service Level Reporter Data Collection Flow . . . . . . . . . . . . 13
4. Administrator Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5. Migration Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
6. SLR Parameter for Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
7. Cross Reference of Predefined SLR vs PR Tables . . . . . . . . . . . . . . . . . . 33
8. SLR Data Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
9. Migration Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
10. Migration Table List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
11. Migration Sample Job (Part 1 of 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
14. DRLW07A0 Member in hlq.SDRLDEFS (Part 1 of 2) . . . . . . . . . . . . . . . . 41
15. DRLW07A0 Member in hlq.SDRLDEFS (Part 2 of 2) . . . . . . . . . . . . . . . . 42
16. DRLWMVWO Member of hlq.SDRLDEFS (Part 1 of 2) . . . . . . . . . . . . . . 43
17. DRLWMVWO Member of hlq.SDRLDEFS (Part 2 of 2) . . . . . . . . . . . . . . 44
18. Modified Migration Sample Job (Part 1 of 3) . . . . . . . . . . . . . . . . . . . . . . . 46
21. Modified DRLW07A0 Member in hlq.LOCAL.DEFS (Part 1 of 2) . . . . . . . 49
22. Modified DRLW07A0 Member in hlq.LOCAL.DEFS (Part 2 of 2) . . . . . . . 50
23. Modified DRLWMVWO Member in hlq.LOCAL.DEFS (Part 1 of 2) . . . . . . 51
24. Modified DRLWMVWO Member in hlq.LOCAL.DEFS (Part 2 of 2) . . . . . . 52
25. Providing COMPCOL Function within a PR Report . . . . . . . . . . . . . . . . . . 53
26. Extract from Modified DRLW0500 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
27. Extract from Modified DRLWC101. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
28. The System Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
29. The Migration Panel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
30. Migration Parameters for Table Migration . . . . . . . . . . . . . . . . . . . . . . . . . 60
31. SLR V3 Table Conversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
32. A.L.L. Migration Sample Job (Part 1 of 6) . . . . . . . . . . . . . . . . . . . . . . . . . 61
38. Drop Log, Record, and Update Object. . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
39. PR Statements for Log Definition - DRLLS001 . . . . . . . . . . . . . . . . . . . . . 68
40. PR Statements for Record Definition - DRLRS001 . . . . . . . . . . . . . . . . . . 68

© Copyright IBM Corp. 1999 vii

41. PR Statements for Tablespace Definition - DRLSS001. . . . . . . . . . . . . . . 69
42. PR Table, Index, Lookup & Update Definition - DRLTS001 (Part 1 of 4) . 69
46. Component Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
47. New Component Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
48. Add Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
49. Created Component. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
50. Component Creation DRLIMS2P in hlq.LOCAL.DEFS (Part 1 of 2) . . . . . 79
51. Component Creation DRLIMS2P in hlq.LOCAL.DEFS (Part 2 of 2) . . . . . 80
52. Process Performance Reporter Statements . . . . . . . . . . . . . . . . . . . . . . . 81
53. Process Performance Reporter Statements . . . . . . . . . . . . . . . . . . . . . . . 82
54. Drop Migrated Temporary Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
55. Utility Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
56. Recalculate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
57. Selecting SAMPARM from Table List . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
58. QMF ADD SAMPARM Data Entry Window . . . . . . . . . . . . . . . . . . . . . . . . 87
59. Parameter Table Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
60. SAMPARM Report Listing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
61. SAMPARM Report after Correcting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
62. TABPROC DB2 Load Utility (Part 1 of 2). . . . . . . . . . . . . . . . . . . . . . . . . . 92
63. TABPROC DB2 Load Utility (Part 2 of 2). . . . . . . . . . . . . . . . . . . . . . . . . . 93
64. Unload and Load Using IXF File and QMF (Part 1 of 2) . . . . . . . . . . . . . . 94
65. Unload and Load Using IXF File and QMF (Part 2 of 2) . . . . . . . . . . . . . . 95
66. Load SQL Statement (MIGPARM). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
67. Member to Populate Lookup Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
68. Drop SAMPRM Temporary Lookup Table . . . . . . . . . . . . . . . . . . . . . . . . . 97
69. SLR Group and Report Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
70. SLR Command View for Report Generation . . . . . . . . . . . . . . . . . . . . . . 102
71. SLR Report Output (Part 1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
72. SLR Report Output (Part 2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
73. Migration Parameters for Report Migration Window . . . . . . . . . . . . . . . . 104
74. Migration Parameters for Reports Window (Part 1 of 2) . . . . . . . . . . . . . 105
75. Migration Parameters for Reports Window (Part 2 of 2) . . . . . . . . . . . . . 105
76. PR Report Migration Window (Part 1 of 2) . . . . . . . . . . . . . . . . . . . . . . . 107
77. PR Report Migration Window (Part 2 of 2) . . . . . . . . . . . . . . . . . . . . . . . 108
78. PR Job Created by ERMT Tool (Part 1 of 6) . . . . . . . . . . . . . . . . . . . . . . 110

viii SLR to Tivoli Performance Reporter for OS/390

84. Element Created in Local.DEFS after the Migration Job . . . . . . . . . . . . . 116
85. Contents of Member TESTSUMR before Modification . . . . . . . . . . . . . . 117
86. Contents of Member TESTSUMR after Modification . . . . . . . . . . . . . . . . 117
87. Contents of Member TXTQA001 before Modification . . . . . . . . . . . . . . . 118
88. Contents of Member TXTQA001 after Modification . . . . . . . . . . . . . . . . . 119
89. Other Pull-down from Main Administration Panel . . . . . . . . . . . . . . . . . . 120
90. Process PR Statements Panel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
91. Report Installation Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
92. Reports Windows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
93. Report View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
94. Form Panel (Part 1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
95. Form Panel (Part 2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
96. Report Output (Part 1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
97. Report Output (Part 2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
98. Component Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
99. Add Objects to a Component (Part 1 of 2). . . . . . . . . . . . . . . . . . . . . . . . 126
100.Add Objects to a Component (Part 2 of 2) . . . . . . . . . . . . . . . . . . . . . . . 128
101.Append to Member DRLIMS2P in hlq.LOCAL.DEFS . . . . . . . . . . . . . . . 128
102.Component List Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
103.PR Tables Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
104.Retention Period Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
105.Purge Condition Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
106.Purge Condition Window Showing Conditional Purge Conditions . . . . . 134
107.Online Purge Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
108.Non-comment Cards from DRLJPURG Job . . . . . . . . . . . . . . . . . . . . . . 136
109.DRLMIGRATION Table Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

ix

x SLR to Tivoli Performance Reporter for OS/390

Tables

1. Significant Differences in Key Functions.. . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2. Where to Find Data in SLR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3. Some Critical Data to Migrate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4. Comparison between SLR Tables and PR Definitions . . . . . . . . . . . . . . . 56
5. Comparison of SLR and PR Reporting Functions . . . . . . . . . . . . . . . . . . . 99
6. DRLJPURG Parameters to Check. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
7. DRLMIGRATION Table Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
8. MVS_ADDRSPACE_H Contents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
9. MVS_SYSTEM_M . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
10. MVS_ADDRSPACE_H . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
11. MVS_ADDRDISTR_M . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
12. MVS_PROGRAM_M . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
13. MVS_COMPCODE_M . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
14. MVS_WORKLOAD_M . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
15. MVS_PRINTER_M . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
16. MVS_TAPE_M. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
17. MVS_IPL_T . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
18. AVAILABILITY_M . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
19. DFSMS_DATASET_D/M . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
20. DFSMS_VOLUME_D/M. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
21. DFSMS_BACKUP_D/M . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
22. DFSMS_MIGRATION_D/M . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
23. DFSMS_DASD_CAP_D/M . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
24. DFSMS_TAPE_CAP_D/M . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
25. DFSMS_ACTIBVITY_M. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
26. DFSMS_LAST_RUN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
27. DFSMS_MIGRATE_DAYS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
28. DFSMS_DS_OWNER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
29. DB2_TRANSACTION_W. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
30. DB2_USER_TRAN_W. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
31. DB2_APPL_DIST_W . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
32. DB2_USER_AP_DIST_W . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
33. DB2_TRAN_W. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
34. DB2_USER_DIST_W . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
35. DB2_APPLICATION_W. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
36. DB2_USER_APPL_W . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
37. EREP_DASD_M . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
38. EREP_VTAM_M . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
39. EREP_CPU_ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
40. EREP_DASD_GROUP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

© Copyright IBM Corp. 1999 xi

41. VMACCT_SESSION_M. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
42. VMPRF_SYSTEM_M. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
43. VMPRF_PROCESSOR_M . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
44. VMPRF_USER_M . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
45. VMPRF_DASD_M . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
46. CICS_TRANSACTION_W . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
47. CICS_M_GLOBAL_D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
48. MSG_SYSLOG_TYPE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
49. MSG_SYSLOG_M . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
50. AVAILABILITY_W/M . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
51. NW_NPM_UTIL_W . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
52. NW_ALERT_BASIC_W . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
53. NW_ALERT_GENERIC_W . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
54. NW_SESSION_W . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
55. NW_RTM_RESONSE_W/M . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
56. NW_SM_UTIL_W . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
57. NW_NCP_UTIL_W . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
58. NW_PU_UTIL_W. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
59. NW_LINE_UTIL_W . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
60. NW_NPM_TRANSIT_W/M . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
61. NW_X25LN_UTIL_W. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
62. NW_X25PU_UTIL_W . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
63. NW_X25NI_UTIL_W . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
64. NW_NTRIP_UTIL_W . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
65. NW_NTRIL_UTIL_W . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
66. NW_NEO_UTIL_W . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
67. IMS_TRANSACTION_W . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
68. OPC_AUTO_EVENT_M . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
69. OPC_MCP_M . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
70. OPC_MISSED_FB_M . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
71. OPC_OPER_EVENT_M . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
72. OPC_OPER_EVENT_T. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
73. Predefined SLR Table to PR Table Cross Reference . . . . . . . . . . . . . . . 181
74. PR to Predefined SLR Table Cross Reference . . . . . . . . . . . . . . . . . . . . 185
75. SLR Parameter Table to PR Lookup Table Cross Reference . . . . . . . . . 189

xii SLR to Tivoli Performance Reporter for OS/390

Preface

This redbook will help you plan and perform the migration from Service Level
Reporter to Tivoli Performance Reporter for OS/390. Information presented in
this redbook about the migration process and the different approaches for
performing a migration can assist you in preparing for your migration and
selecting the best approach for performing your migration.

This redbook is intended to help the enterprise performance administrator
migrate Service Level Reporter information to Tivoli Performance Reporter for
OS/390 by providing detailed guidance on performing the migration steps
with knowledge gained by the authors while performing an actual migration.
The migration steps presented in this redbook are described using examples
that you can duplicate to perform your own migration. A working knowledge of
Service Level Reporter and Performance Reporter is assumed.

The Team That Wrote This Redbook
This redbook was produced by a team of specialists from around the world
working at the International Technical Support Organization, Austin Center.

Mike Foster is a senior programmer at the ITSO, Austin Center and holds a
bachelor of science degree in electrical engineering from the University of
Kansas. He writes extensively and teaches classes world wide on a variety
of topics including Tivoli products. Before joining the ITSO in 1995, he held
both management and technical position in IBM marketing and development
divisions supporting MVS, CICS and DB2 products world wide for over 25
years.

Mauro Basile is a system engineer at Rome Tivoli Laboratory in Italy. He has
over 30 years experience in both hardware and software with IBM and Tivoli.
He holds a diploma of Perito Elettrotenico Industriale in Italy. Before joining
IBM he was a electronic technician in the Italian Navy. For the past 15 years
he has been focusing on software including working with several large
accounts running TPF in Italy. For the past three years he has been a
member of the Tivoli development team working extensively with both
Service Level Reporter and Performance Reporter.

Malcolm Pearse is a senior IT specialist with IBM Global Services in South
Africa. He joined IBM Global Services in 1997 where he has worked
exclusively with Performance Reporter 1.2 and 1.3. Before joining IBM he
worked for a large mining company for 13 years in areas of operations,
helpdesk, systems programming/analysis, performance/capacity

© Copyright IBM Corp. 1999 xiii

management and chargeback, combining these roles with extensive use of
reporting and reporting tools.

Thanks to the following people for their invaluable contributions to this
project:

Marcus Brewer
International Technical Support Organization, Austin Center

Robert Haimowitz
International Technical Support Organization, Poughkeepsie Center

Nick Riches
IBM United Kindom

Judit Csapo
IBM Sweden

Bruce Cullen
IBM Sweden

Juliette Meinstein
Tivoli Systems, Performance Reporter Evangelist

Van Collins
Tivoli Systems Customer Support

Sharon Brower
IBM Software Migration Project Office, Tivoli Performance Team

Richard Orr
IBM Advanced Technical Support, Tivoli Systems Management

Al Hanna
IBM Software Migration Project Office, Tivoli Migration Team

Butch Rambish
IBM Software Migration Project Office, Tivoli Performance

Comments Welcome
Your comments are important to us!

We want our redbooks to be as helpful as possible. Please send us your
comments about this or other redbooks in one of the following ways:

xiv SLR to Tivoli Performance Reporter for OS/390

• Fax the evaluation form found in “ITSO Redbook Evaluation” on page 211
to the fax number shown on the form.
• Use the electronic evaluation form found on the Redbooks Web sites:
For Internet users http://www.redbooks.ibm.com
For IBM Intranet users http://w3.itso.ibm.com
• Send us a note at the following address: redbook@us.ibm.com

xv

xvi SLR to Tivoli Performance Reporter for OS/390

Part 1. Migration Overview

© Copyright IBM Corp. 1999 1

2 SLR to Tivoli Performance Reporter for OS/390

Chapter 1. Introduction

This chapter introduces the advantages of using Performance Reporter and
provides a brief introduction to Performance Reporter and an overview of the
Service Level Reporter (SLR) to Performance Reporter (PR) migration.

1.1 Why Upgrade to Performance Reporter?
Performance Reporter has many characteristics and functions that most
customers find as improvements over Service Level Reporter. In most, if not
all cases, customers find that their collect process is considerably faster with
Service Level Reporter. Some of the other benefits of converting to
Performance Reporter are:
• Improvements and enhancements to Performance Reporter are ongoing,
whereas, there is no development being done to Service Level Reporter.
• Performance Reporter is easier to use than Service Level Reporter.
Performance Reporter is based on DB2, meaning you do not have to learn
a proprietary data management system or query language as in Service
Level Reporter.
• Incorporation of new report requirements is facilitated. Performance
Reporter utilizes the DB2 capability allowing for columns to be added
dynamically to the database. This allows for the adding of new columns to
the database without having to export, delete, redefine, and reload the
database as would have to be done with Service Level Reporter.
• Computations can be altered dynamically in Performance Reporter without
any cumbersome redefinition as with Service Level Reporter.
• Performance Reporter takes advantage of improvements in DB2
technology. For example, when Distributed Relational Database
Architecture (DRDA) was implemented in DB2 V2.3, Performance
Reporter users gained the ability to access performance data from remote
systems. With the introduction of DB2 V3, Performance Reporter
databases were eligible for compression, greatly reducing the amount of
DASD resource consumption. The latest releases of DB2 provide Open
Database Connectivity (ODBC) and TCP/IP capabilities.
• Performance Reporter provides supported features for data collection and
reporting of information from Unix, Windows NT, and AS/400 systems.
• With version 1.4 of Performance Reporter, a JAVA viewer interface is
provided that allows graphical and tabular representations of Performance


Reporter data from any desktop environment. Service Level Reporter
reports and graphs are only displayed on the mainframe.
• Performance Reporter boasts a new feature specifically developed for the
accounting and chargeback analyst called The Accounting Workstation
Option. This option is a graphical user interface (GUI) based feature
designed to assist Information Technologist (IT) financial analyst
functions.
• The Performance Reporter table definitions are stored directly in DB2 in
contrast with Service Level Reporter, where the table definitions have to
be compiled and stored as load modules in a load library.
• With the QMF facility, the user can easily create ad hoc reports.
• The accounting feature in Performance Reporter has been enhanced and
expanded over the accounting feature in Service Level Reporter. In
addition with the data stored in DB2, the accounting feature in
Performance Reporter is easier to use and the data easier to handle
compared to Service Level Reporter where the accounting data is a
separate database.

1.2 Overview of Performance Reporter
Performance Reporter performs two basic functions:
• Collecting systems management data into a DB2 database.
• Reporting on the data stored in the database.

Performance Reporter consists of a base product and several optional
features:
• System Performance feature
• Network Performance feature
• CICS Performance feature
• IMS Performance feature
• AS/400 System Performance feature
• Workstation Performance feature
• Capacity Planner
• Accounting feature
• Accounting Workstation Option (AWO)


The Performance Reporter base can generate graphic and tabular reports
based on the information it has stored in its DB2 database based on the
systems management data it has collected. The base product includes the
administration dialog, the reporting dialog, and the log collector, all of which
interact with a standard DB2 database as shown in Figure 1 on page 5.

Administration Dialogs
Input
Reports
Datasets

DB2
Reports
Log
Collector Database Reporting

Optional Features

COLLECT SUMMARIZE REPORT

Figure 1. Performance Reporter Overview

Performance Reporter features provide DB2 table definitions and table
update instructions for collecting required systems management data. They
also provide predefined queries, forms, and reports for presenting that data.

The Performance Reporter features allow you to collect and report on
systems management data, such as systems management facilities (SMF)
data or IMS log data.

Each Performance Reporter performance feature has components that are
groups of related Performance Reporter definitions. For example, the MVS
Performance Management component consists of everything Performance
Reporter needs to collect log data and create reports showing MVS
performance characteristics.

Introduction 5

In addition, the Capacity Planner feature lets you download summarized data
from the Performance Reporter database to a workstation and analyze and
plan the usage of key MVS/ESA and MVS/XA resources.

1.3 Introducing the Log Collector
The central part of Performance Reporter is the log collector program that
reads performance data and processes it. Log collector tasks are controlled
by various definitions. These definitions are listed in Section 1.3.1 of this
chapter.

The log collector’s main function is to read data and store it in data tables in
the Performance Reporter database. The log collector groups the data by
time period, and computes sums, averages, minimums, maximums, and
calculates resource availability.

1.3.1 Log Collector Functions
Log Definitions: To collect log data, Performance Reporter needs log
descriptions. Performance Reporter gathers performance data about
systems from sequential datasets, such as those written by systems
management facilities (SMF) under MVS. These datasets are referred to as
log datasets or logs.

The log collector stores descriptions of logs as log definitions in the
Performance Reporter database. All log definitions used by Performance
Reporter features are provided with the Performance Reporter base. If,
however, you are migrating user defined table definitions, then you will have
to create the appropriate log definitions.

Record Definitions: Each record in a log belongs to a unique record type.
Examples of record types include SMF type 30, generated by MVS, and SMF
record type 110 generated by CICS. For Performance Reporter to process a
record, the record type must be defined. Detailed record layouts, field
formats and offsets within a record are described in Performance Reporter
record definitions. All record definitions used by Performance Reporter
features are provided with the Performance Reporter base, but again, the
appropriate record definitions for user defined tables will have to be created
when migrating from Service Level Reporter.

Update Definitions: Instructions for processing data and inserting it into
tables of the Performance Reporter database are provided in update
definitions. Each update definition describes how data from a source (either
a specific record type or a row of a table) is manipulated and inserted into a


row of the target table. All update definitions used by Performance Reporter
feature are provided with Performance Reporter. Any update definition for
user defined tables will have to be created when migrating from Service Level
Reporter.

Table Definitions: Performance Reporter stores data collected from log data
sets in database tables. A table definition identifies the database and table
space in which a table resides, as well as the columns that make up the table.
The table definitions used by the components in the Performance Reporter
features are provided with the feature. For user defined tables in Service
Level Reporter, the table definitions will have to be created when migrating to
Performance Reporter.

Log and Record Procedures: Log procedures and record procedures are
user-exit programs for specific data collection situations. They are similar to
record build exits provided with Service Level Reporter. Record procedures
work on specific record types. Log procedures work on an entire log. The log
and record procedures used by Performance Reporter features are provided
with the Performance Reporter base.

The Collect Process: When definitions for a log, its records, its update
instructions for record data, and target tables exist in Performance Reporter,
you can collect data from the log. The Performance Reporter log collector
retrieves these stored definitions and performs the data collection they
define.

1.4 Comparison between PR and SLR
In order to understand the need for migration, rather than a wholesale copy of
everything that existed in Service Level Reporter, you should look at the
similarities and differences between the two products. Table 1 on page 7
shows the major differences from a task perspective.
Table 1. Significant Differences in Key Functions.

TASK SLR PR

Summarize Data > Summary Table > Update Definition
> Total Pattern > DB2 View
> Report

Join/Merge data from > SLR Log Table > Update (2 + Records to
several input records > View (Summary tables one table)
only) > DB2 View
> Report

Introduction 7

TASK SLR PR

Directly modify Log Collect Exit (Record Build Record Procedures
Record Exit)

Delete data based on age Purge Command Purge Definition

Table Lookup during Parameter Table > Update Definition
Collect > Lookup Table

Calculations (excluding > Tables (COMPCOL) > Update Definition
Summarizations) > Views (DATACOL) > DB2 View
> Report

1.4.1 Summarize Data
Summarized Data is the major reason for using a product such as Service
Level Reporter or Performance Reporter. Service Level Reporter is biased
towards Collect time summarization based on total patterns. This means that
reporting requirements have to be anticipated early in the implementation
cycle with the appropriate total patterns (TOTPATS) verified or included.

In Performance Reporter a hierarchy of tables provides time level
summarization. A naming convention is used in many of the Performance
Reporter components to identify the level of data within a table. The addition
of a suffix to the table name identifies the level of the data in each table. For
example, the table MVS_SYSTEM_M contains information on the monthly
statistics of processor activity, paging and swapping activities, IPLs, and lost
SMF data. The naming convention suffixes used in Performance Reporter
are:
_T Timestamp level. It provides the same level of summarization as
the SLR log table. It is not present in all cases.
_H Hourly summary
_D Daily summary
_W Weekly summary
_M Monthly summary

Summarization for non-time key columns (e.g. MVS System ID) can be done
by SQL Select in a View or query. The choice is normally dependent on the
number of different values expected for a key column. For example, the
column containing MVS System ID would probably have a few distinct values,
therefore report time summarization would be OK, but a column, such as
CICS user ID, may have many distinct values, and so collect-time


summarization is used to avoid the risk of Performance Reporter reading tens
or hundreds of thousands of rows to make a one-page report.

1.4.2 Join/Merge Data
Some Service Level Reporter tables (like JOBLOG) are based on input from
several record types. This ’’joining’’ was accomplished using special Service
Level Reporter code. In Performance Reporter, the ability to use multiple
update definitions against tables circumvents this problem. This fact must be
borne in mind however, as tables such as MVS_ADDRSPACE_H contain
batch, started tasks, and TSO information, while in Service Level Reporter,
this would all have been held in separate tables.

With summary tables, it is possible to merge data with a Service Level
Reporter view. In addition, Service Level Reporter views are often used to
provide additional information about the data using calculations. A similar
function is provided within DB2 with the VIEW function, but with DB2 the
calculations can be done either in a view or through SQL in a Performance
Reporter report. In many cases, it is better to move calculations from a
Service Level Reporter view to a Performance Reporter report.

1.4.3 Directly Modify Log Records
Both products use similar techniques. Performance Reporter’s capabilities in
this area are a super-set of those in Service Level Reporter. In most cases,
where the function from a Record Build Exit is needed in Performance
Reporter, it will be possible to use the same logic as before in the
Performance Reporter record procedure.

All Service Level Reporter exits should be checked before implementation in
Performance Reporter because, in many cases where exits were previously
required with Service Level Reporter, the more powerful capabilities of
Performance Reporter can provide the desired results. For example, the
function provided by Record Build Exit DREEXOPC in Service Level Reporter
is no longer required with Performance Reporter.

1.4.4 Purging Data
Both Performance Reporter and Service Level Reporter allow the deletion of
data based on age. With Service Level Reporter, this can be a complicated
process because of the large data structure (Total Patterns). The purge
conditions from Service Level Reporter can not be readily migrated to
Performance Reporter, but they can be implemented quickly and easily at a
later stage. See Chapter 7.1, “Setting Purge Conditions” on page 131 for a
description of the setting of purge conditions.

Introduction 9

1.4.5 Table Lookup During Collect
The ability to enhance the information stored in Service Level Reporter by
using parameter tables is an important function. It allows for the substitution
of data and grouping of related data, such as applications and users. The
same capability is provided with Performance Reporter. Lookups are carried
out within an update definition, and it is therefore possible to provide
additional information to lower level summaries. For example, you may use a
Lookup to group transactions to applications in one table and then do another
Lookup to find the response time objective for that application from another
table. This process is used within the Performance Reporter IMS feature.

1.4.6 Calculations
In order to perform any calculation with Service Level Reporter, either
COMPCOLS had to be coded within the table definition or a Service Level
Reporter view created. Performance Reporter is much more flexible in this
area. Calculations can be carried out in update definitions if required, but
more commonly the SQL query used for reporting will contain most
calculation logic. This is an important point for migration, as Performance
Reporter does not have any equivalent function to COMPCOL. All columns in
DB2 tables must be "real". Because of this, the table migration tools provided
with Performance Reporter do not attempt to resolve COMPCOL macros.
They must be dealt with manually.

1.4.7 Reporting
Although the principles are the same in both products (the using data from
the database and presenting it to an end-user as information), Performance
Reporter has far superior facilities for selecting and formatting the data.
Calculations can be carried out within the SQL query, eliminating some of the
need for table modifications. In addition, Performance Reporter reports can
be based on more than one table without resorting to a view, and reports can
have meaningful column headings by using QMF forms.

1.4.8 PR Data Flow
A summarization of the Performance Reporter data collection process is
shown in Figure 2 on page 11 and is explained following the figure.


Input 3 4 5
1 Log Record Record
2 Definition Definitions Procedure
Logs

Update
6 Definitions 7 Lookup
Tables

Data Reports
8 Tables 11

9 Update
Definitions

11 Reports
10 Data
Tables

Figure 2. Overview of Performance Reporter Data Collection Flow

Performance Reporter processes data as follows:
1. The operating system, or other programs, write data to a log data set.

Note
Input log data set can be a sequential file or a member of a PDS. Also
the input data can be a group of concatenated data sets.

2. You initiate the collect either through the dialog or by using a Performance
Reporter language statement in a job. When you submit the collection,
you identify the log definition to be used in the collection.
3. Performance Reporter initiates log collection for the log specified.
4. Performance Reporter looks for record definitions associated with the log
definition in its system tables. It applies those record definitions to
specific record types from the log or log procedure.
5. Optionally, a record definition might require processing through a user-exit
program, a record procedure. If a record definition requires processing by
a record procedure:

Introduction 11

• The record procedure receives only a specific record type and is not
called for other record types.
• Output from a record procedure varies in format and is usually a record
mapped by a Performance Reporter record definition.
6. Performance Reporter applies a specific update definition to each known
record type and performs the data manipulations and database updates as
specified.
7. Performance Reporter often selects data from Lookup tables to fulfill the
data manipulations that the update definitions require.
8. Performance Reporter writes unsummarized and first-level summarized
data to data tables specified by the update definitions.
9. Performance Reporter uses updated tables as input for updating other,
similar tables that are for higher summary levels. If update definitions
specify data summarization, then Performance Reporter selects data from
a table as required by the update definitions and performs required data
summarization. (Performance Reporter might select data from Lookup
tables during this process, but this step is not shown in Figure 2 on page
11).
10.Performance Reporter updates other data tables as required by update
definitions.

Notes
• Normal summarization of updates from table to table is time related,
such as hourly, daily, weekly, monthly, and yearly.
• Data tables that are updated from other data tables, such as a
monthly table, will contain time to date values in the fields. Thus, the
current monthly table, if you report on its contents, will report
summary values to date for the month.

11.Reports are generated from the data in the tables.

1.4.9 SLR Data Flow
A summarization of the Service Level Reporter data collection process is
shown in Figure 3 on page 13 and is described following the figure.


Log data
1

SLR

Collect
SLR selection exit
2

4a
SLR record build exit SLR computation exit
3
4b

SLR log tables 6 SLR parameter tables
5

SLR summary tables
7

SLR report language 9
SLR parameter tables
8

SLR reports
10

Figure 3. Overview of Service Level Reporter Data Collection Flow

Service Level Reporter processes data as follows:

Introduction 13

1. The operating system or other programs write data to a sequential log
data set. These data sets are input to Service Level Reporter. Data
collection is initiated by using the SLR COLLECT statement in a batch job,
identifying a specific LOGSOURCE.
2. Each input record is passed to the Service Level Reporter record selection
exit where certain records can be spun off to other files, or the number of
records to be processed can be restricted.
3. Optionally, the log source might specify the use of a record build exit to
build a new record from the input record with additional or amended
information from the original input record.
4. Optionally, the log source might specify the use of a computation exit,
such as DRESXT1. If the log source requires the use of a computation
exit:
a. The computation exit receives each record in the log as input.
b. Output from the computation exit will be added to the input record and
written into the SCxUSER and SNxUSER columns in Service Level
Reporter log tables.
5. The built record is then used to create the rows in the appropriate Service
Level Reporter log tables.
6. Service Level Reporter can use data selected from parameter tables to
provide additional information in log tables.
7. Service Level Reporter uses the log table information to update the
appropriate summary tables. Summary table rows with totals are created
as the last stage of collect.
8. Once Service Level Reporter stores the data from a collect, reports can be
run against the data. Service Level Reporter uses a unique language to
select data for the report.
9. Optionally, Service Level Reporter might select data from parameter
tables specified in the query.
10.Service Level Reporter creates the report, displaying, printing, or saving it
as you requested.

1.5 How to Use This Redbook
This redbook is divided into two parts. Part 1, “Migration Overview” on page 1
contains Chapter 1, “Introduction” on page 3, and Chapter 2, “Migration
Approaches” on page 17 that give an overview of both Performance Reporter
and Service Level Reporter and the migration process for moving information


from Service Level Reporter to Performance Reporter. Part 2, “Migration
Examples” on page 29 gives detailed examples of actual migration steps
performed by the writers of this redbook showing how to migrate Service
Level Reporter information into Performance Reporter.

Depending on the migration approach you decide to perform from those
described in Chapter 2, “Migration Approaches” on page 17, you can use the
information in Chapters 3 though 7 to show you how to perform the specific
steps and actions required to complete the movement of information from
Service Level Reporter to Performance Reporter. Since not all readers will
select the same approach for migrating between Service Level Reporter and
Performance Reporter, you only need to focus on the information in the
chapters associated with the migration activity you need to perform.

The migration activities described in Chapters 3 through 7 are:
• Chapter 3, “Migrating Data from Predefined SLR Tables” on page 31
covers the migration of Service Level Reporter data from predefined
Service Level Reporter tables into Performance Reporter tables for one or
more Performance Reporter components using the Performance Reporter
migration utility.
• Chapter 4, “Migrating User-Defined A.L.L Based Tables and Data” on page
57 covers the migration of Service Level Reporter data, log and table
definitions from user-defined summary tables, and log tables into
• Chapter 5, “Migrating Parameter Table Data” on page 85 covers the
migration of data from Service Level Reporter parameter tables into
Performance Reporter Lookup tables.
• Chapter 6, “Migrating SLR Reports” on page 99 covers the migration of
Service Level Reporter reports to Performance Reporter reports using the
Performance Reporter migration utility.
• Chapter 7, “Miscellaneous Items” on page 131 covers others items that
the administrator needs to perform associated with the migration from
Service Level Reporter to Performance Reporter that fall outside the
actual movement of information between the two reporting systems.
• Appendix A, “The Key to Predefined Migration - DLRMIGRATION” on page
137 contains a complete cross reference of information from the
DLRMIGRATION table which the migration utility uses to guide and direct
the migration of predefined Service Level Reporter table data into
Performance Reporter tables.
• Appendix B, “Predefined SLR Tables to PR Tables Cross Reference” on
page 181 provides both a cross reference of predefined Service Level

Introduction 15

Reporter tables to Performance Reporter tables and Performance
Reporter tables to predefined Service Level Reporter tables that show
where the migration utility will get data from and where it will place the
data when migrating predefined Service Level Reporter tables.
• Appendix C, “Parameter Table to Lookup Table Cross Reference” on page
189 lists the predefined Service Level Reporter parameter tables and
which Performance Reporter Lookup table holds similar information.


Chapter 2. Migration Approaches

This chapter reviews the options available to you for migrating from a Service
Level Reporter to a Performance Reporter environment. The details on how
to perform the activities for each of the approaches discussed in this chapter
will be presented in Part 2, “Migration Examples” on page 29.

2.1 Introduction to Performance Reporter Migration
The elements you are wanting to protect your investment in by migrating
them to Performance Reporter are comprised of:
• Data in the database that is needed for historical information, trend
analysis, and capacity planning.
• Customized tables you have developed to support new data sources or
amend supplied code.
• Views you have developed that add function to tables and reports.
• Reports you have written.

Service Level Reporter and Performance Reporter perform essentially the
same tasks, although in slightly different manner. The task of migration
should therefore be to protect the investment that has been made in Service
Level Reporter data and provide the same or better information to end users
following the migration.

The differences in the products and their data structure means that tasks
have to be accomplished differently between Service Level Reporter and
Performance Reporter. This means that the operational procedures that
support the reporting process will need to be altered to accommodate these
differences following the migration.

Tools are provided with the Performance Reporter base product to assist you
in performing the migration from Service Level Reporter to Performance
Reporter. These tools automate the moving of data and tables between
Service Level Reporter and Performance Reporter. In order to get the most
benefit from using the Performance Reporter migration utilities, you will want
to develop a migration plan.


2.2 The Migration Tool
The migration tool is made up of several REXX execs located in
hlq.SDRLEXEC (DRLEMIGQ, DRLEMIGR,DRLEMIG0 and DRLEMIRX) and many
definitions members located in hlq.SDRLDEFS (DRLWxxxx).

The migration tool is accessed using the administration dialogs and supports
the following functions for migrating data from Service Level Reporter to
Performance Reporter:
• Migrate DATA from Service Level Reporter predefined set of tables to
Performance Reporter DB2 tables.
• Migrate user defined Service Level Reporter tables to Performance
Reporter definitions and DB2 tables and copy the data.
• Migrate user defined Service Level Reporter reports to Performance
Reporter.

There are three different functions provided by the migration tool, and you will
use some, or all, of these functions depending on what and how you to
choose to migrate.

The migration of data from the Service Level Reporter predefined table
occurs in two steps:
1. Performance Reporter unloads data from Service Level Reporter data
base to IXF data set.
2. Performance Reporter imports the unloaded data into a temporary
Performance Reporter DB2 table (using QMF or not using QMF) and
then Performance Reporter selects a subset of data from the
temporary DB2 table to be stored in the appropriate Performance
Reporter DB2 table.

All this process is controlled by the information in a Performance Reporter
system table called DRLMIGRATION that is able to guide the tool in choosing
the right definition members to perform the Unload (through Service Level
Reporter Report statements to an IXF file) and Load operation (through SQL
statements to populate the related Performance Reporter table). Refer to
Figure 109 on page 141 for the lay-out of DRLMIGRATION table.

In order to migrate user defined Service Level Reporter tables, the standard
process builds only a single summary table at the most detailed time key
available, so additional work will have to be undertaken to define any
summarization beyond this level.


Not all the Service Level Reporter keywords can be translated in table
columns in the DB2 Performance Reporter database. For example, COMPCOL
is one of the most important that is not translated. In the standard
Performance Reporter tables, this function is either part of the update
structure or is coded within the supplied reports. It is, therefore, very easy to
carry out the same modifications for any COMPCOL that have been added or
amended by the customer as will be covered in Chapter 6, “Migrating SLR
Reports” on page 99.

In order to help the migration of the reports, a tool has been developed,
called ERMT, to provide a conversion of Service Level Reporter Report
language statements to SQL queries.

The reports are migrated from Service Level Reporter ISPF tables (SLRTABL)
or from Service Level Reporter report command source data sets. During the
migration, QMF queries and forms are created, as well as Performance
Reporter report definitions. These are used to create Performance Reporter
report groups and reports.

2.3 Developing a Migration Plan
The need for planning your migration cannot be emphasized strongly enough.
There are many factors that have to be considered before undertaking what
could be a lengthy and complex process. The purpose of this cookbook is to
provide you with an understanding of the migration process and the factors
involved in performing a migration so that you will be able to better plan your
Service Level Reporter to Performance Reporter migration.

There may be skills that you can call upon within your own enterprise for help
in this area. Most customers have undertaken application migrations or
migrated from one release of software to another. Service Level Reporter to
Performance Reporter migration is not very different from these processes.
The migration should be treated as a project with the establishment of
objectives and timescales.

Any migration plan should consider and include the following areas:
• Identification of critical data
• Assessment of the importance of that data
• Assessment of possible migration approaches
• Skill requirements
• Priority

Migration Approaches 19

• Operational requirements
• New procedures

Expect to spend some time planning your migration before carrying out any
tasks, as migration from Service Level Reporter to Performance Reporter
should be taken as an opportunity to re-assess the reporting requirements of
the enterprise. The skills of the personnel involved in the migration will have
a bearing on the kind of tasks you are able or willing to undertake during the
migration.

Some customers have found that when they study the various reports
currently being produced in Service Level Reporter, that in some cases,
modifications have been made in the past to fulfill requirements that no longer
are needed or required in today’s environment. With good analysis and
planning, you may find that you can save time and effort in the migration
process by not migrating items that are no longer required.

2.3.1 Analysis of What to Migrate
Regardless of the approach you choose, you will need to determine what
data should be migrated and what data is not worthy of migration since there
is always some cost and effort associated with migration.

Some considerations in this regard are:
Audit Requirements There could, for instance, be a legal need
(contractual obligations) to keep data for certain
periods of time so that past usage and accounting
reports produced and sent out to customers could
be audited and results verified.
Need for Trend Data
for Capacity Planning Capacity planning is essential in any organization.
To this end, trend analysis to determine peaks and
troughs is vital.
Retention Periods
for Tables The retention periods for tables should only be
used as a reference for the setting of purge
parameters in Performance Reporter and would
not be migrated as such.
Total Patterns Profiles could be extremely important for trend
analysis.


User-Defined Tables Service Level Reporter may not have had a
pre-defined table for certain data types, and you
may have defined your own A.L.L table to collect
this data. Before migrating these table definitions,
check to see whether or not Performance
Reporter has a suitable equivalent.

2.3.2 Elements of a Plan
The key elements of a good migration plan and suggestions as to what to
look for in each element are discussed below.

2.3.2.1 Identification of Critical Data
Deciding what Service Level Reporter data is critical to an enterprise is the
first stage in a successful migration. To begin with, this should be a top down
approach. For example:
1. Identify the important sub-systems in the enterprise (eg. CICS, IMS,
Batch, TSO)
2. Identify measurement requirements (eg. CPU, DASD)
3. Identify the types of measurement required (eg. CPU busy, transaction
response, DASD utilization)
4. Identify the current uses of the data (eg. performance measurement,
capacity planning, service level reporting)
5. Document any known future requirements

Once the critical data has been identified, the next task is to map the
appropriate Service Level Reporter table to that data. Table 2 gives some
examples of Service Level Reporter tables and the kind of data they contain.
Table 2. Where to Find Data in SLR

Table Name Data Captured

ADDRSTAT Address Space Data

AVAILSTAT Resource Availability

CPULOAD CPU Measurements

CICSTRANSUM CICS Transaction Data

DB2ACCTSUM1/2 DB/2 Accounting Data

IMSTRANS IMS Transaction Data

JOBSTAT Batch Job Data


Table Name Data Captured

NR_NPMRESPS NPM Response Time Data

NR_NVRESPS NetView RTM Data

PAGESUM Paging Data

TSOSTAT TSO Session Data

WORKLOAD Data from RMF 72

There may be other tables beyond the predefined Service Level Reporter
tables that contain data critical to your enterprise. Tables that may not be in
the Service Level Reporter starter set but are user-defined. The number of
tables identified may also be surprisingly small. In many cases, a large
proportion of critical Service Level Reporter data can be found in 5 or 6
tables.

2.3.3 Assessment of the Importance of Data
The picture of what data to migrate to Performance Reporter is now
beginning to develop, but you still need to assess the importance of the data
at total pattern level. In addition to the detail information contained within
Service Level Reporter summary tables, there is also a wealth of information
held in total patterns, for example, Daily summaries.

When considering what data to migrate to Performance Reporter, you need to
assess its value. For example, normally there is no value in migrating hourly
detail measurements of CICS transactions to Performance Reporter. The
prime purpose of migrating data from Service Level Reporter to Performance
Reporter is to preserve the historical information that has been built up over a
number of months or years. Moving very detailed information does not meet
this goal. In addition, the resources required to move large amounts of detail
information can be expensive. As a guideline, monthly summary level data is
probably the most granular that should be considered for migration.

You should also be aware of other total patterns that may be important to
migrate, for example, profiles. These are the totals that allow you to report on
the hourly data, averaged by each day, across a month, or daily data,
averaged by each month, across a year. This kind of data allows you to
identify peak periods, such as month end processing or the peak hour for
capacity planning purposes.


Table 3 shows the level of information that should be considered for
migration.
Table 3. Some Critical Data to Migrate

Table Name Total Pattern

ADDRSTAT Monthly level, Project detail

AVAILSTAT Monthly level, Resource detail

CPULOAD Monthly level

CICSTRANSUM Monthly level, Transaction detail

DB2ACCTSUM1/2 Monthly level, Plan detail

IMSTRANS Monthly level, Transaction detail

JOBSTAT Monthly level, Project or Jobname detail

TSOSTAT Monthly level, Project detail

WORKLOAD Monthly level, Workload type detail

The data that you choose to migrate should be important and provide
indicators to the "health" of the Information Systems (IS) business in the
enterprise. Some examples of this are:
• Adequate availability and response time
• Adherence to schedules
• Sufficient capacity
• Cost effectiveness

2.3.4 Assessment of Possible Migration Approaches
The next stage in migration planning is to choose an approach. It is important
that the critical Service Level Reporter data be identified before this stage so
that an informed decision on how best to approach the migration of the
Service Level Reporter data can be made.

2.3.4.1 Do not perform migration
If the current Service Level Reporter system was largely unmodified and the
value of the data regarded as low, then a possible approach would be to not
migrate any data to Performance Reporter. It would be possible to collect
new data into Performance Reporter and 'run-down' the Service Level
Reporter database using the normal purge routines.


If this approach is adopted, then there are some disadvantages that must be
considered:
• Additional disk space requirements of Service Level Reporter database
and Performance Reporter
• Additional CPU time to perform purging of Service Level Reporter data
• Historical information would only be held in Service Level Reporter until
such time as the Performance Reporter database had collected enough
data.
• Two sets of reports would need to be produced. One from Performance
Reporter showing the current data, and the second from Service Level
Reporter showing historical information. This would complicate trend
analysis.

If, on the other hand, you decide not to keep Service Level Reporter data at
all, and you merely start collecting data into Performance Reporter, then
trend analysis could not be performed until such time as sufficient data had
been collected in Performance Reporter. You would also have an exposure,
if at a future date, somebody required a historical report for accounting or
audit purposes.

Because of these disadvantages, it is expected that some migration activity
will take place in all Service Level Reporter installations that are moving to

2.3.4.2 Migrate Everything
If a planning exercise were not being undertaken, then most Service Level
Reporter sites would adopt this approach. The cost of this approach will be
very high, and the value gained from migrating "just that little bit more" very
small. When assessing critical data and where it can be found within Service
Level Reporter, the number of tables identified should have been small, and
the appropriate total patterns should have reduced the amount of data further
still.

Because of the architectural differences between Service Level Reporter and
Performance Reporter, there will have to be a considerable amount of
manipulation in order to achieve a total migration. This approach negates
any value that might have been gained by re-assessing the reporting
requirements of the enterprise.

2.3.4.3 Selective Migration
By effective planning and assessment of critical Service Level Reporter data,
the natural conclusion is to perform a selective migration. To perform a


SLR to Tivoli Performance Reporter Migration Cookbook

SLR to Tivoli Performance Reporter Migration Cookbook

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (14)

En vedette

En vedette (10)

Similaire à SLR to Tivoli Performance Reporter Migration Cookbook

Similaire à SLR to Tivoli Performance Reporter Migration Cookbook (20)

Plus de Banking at Ho Chi Minh city

Plus de Banking at Ho Chi Minh city (20)

Dernier

Dernier (20)

SLR to Tivoli Performance Reporter Migration Cookbook