IBM Tivoli Operations Planning and Control
Installation Guide Version 2 Release 3
SH19-4379-02
IBM Tivoli Operations Planning and Control
Installation Guide Version 2 Release 3
SH19-4379-02
Note Before using this information and the product it supports, be sure to read the general information under “Notices” on page xv.
ISO 9001 Certification
This product was developed using an ISO 9001 certified quality system.
Certification has been awarded by the Italian quality system certification group, CSQ (Certification No. CISQ/CSQ 9150.IBM7).
CSQ is a member of the mutually recognized organization of European assessors, ITQS, which assesses and certifies quality systems in the field of information technology enterprises.
Third Edition (December 1999)
This is a major revision of, and obsoletes, SH19-4379-01.
This edition applies to Version 2 Release 3 Modification Level 0 of Tivoli Operations Planning and Control, Program Number 5697-OPC, and to all subsequent releases and modifications until otherwise indicated in new editions or technical newsletters. See the “Summary of Tivoli OPC Version 2 Release 3 Enhancements” on page xxvii for the changes made to this manual. Technical changes or additions to the text to describe the Tivoli Job Scheduling Console Support are indicated by a vertical line to the left of the change. Make sure you are using the correct edition for the level of the product.
Order publications through your IBM representative or the IBM branch office serving your locality. Publications are not stocked at the address below.
IBM welcomes your comments. A form for readers' comments appears at the back of this publication. If the form has been removed, address your comments to:
Tivoli OPC Information Development Rome Tivoli Laboratory IBM Italy S.p.A. Via Sciangai, 53 00144 Rome Italy
Fax Number (+39) 06 5966 2077
Internet ID: ROMERCF at VNET.IBM.COM
When you send information to IBM, you grant IBM a nonexclusive right to use or distribute the information in any way it believes appropriate without incurring any obligation to you.
Copyright International Business Machines Corporation 1991, 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
Notices ...... xv Programming Interface Information ...... xv Trademarks ...... xvi
Preface ...... xix Who Should Read This Guide ...... xix Required Product Knowledge ...... xix How to Use This Guide ...... xx How This Guide Is Organized ...... xx Tivoli OPC Publications ...... xxi Tivoli OPC Online Books ...... xxii Online Message Facility ...... xxii Required Publications ...... xxii Books about Related Products ...... xxiii
Summary of Tivoli OPC Version 2 Release 3 Enhancements ...... xxvii Job Scheduling Console ...... xxvii Catalog Management — Data Availability ...... xxvii OS/390 Workload Manager Support ...... xxvii OS/390 Automatic Restart Manager Support ...... xxviii Program Interface (PIF) Enhancements ...... xxviii Enhancements for Non-OS/390 Tracker Agents ...... xxviii Usability Enhancements ...... xxix New and Changed Installation Exits ...... xxix New and Changed Initialization Statements ...... xxix Version 2 Release 2 Summary ...... xxxi Version 2 Release 1 Summary ...... xxxiv
Part 1. Planning ...... 1
Chapter 1. Overview ...... 3 Tivoli OPC Parts and Their Relationships ...... 3 Tracker ...... 4 Controller ...... 4 | Server for Dialogs, PIFs, and Tivoli Job Scheduling Console ...... 4 | Data Store ...... 5 Tivoli OPC Configurations ...... 5 Controlling System ...... 5 Controlled Systems ...... 5 Tivoli OPC Subtasks ...... 6 Relationship between Tivoli OPC and MVS ...... 7 Using the Tivoli OPC Program Directory ...... 8 Sample Library ...... 8 The Installation Process ...... 9
Chapter 2. Planning Your Tivoli OPC Configuration ...... 11 Planning Considerations ...... 11 Trackers ...... 11 Initialization Statements ...... 11
Copyright IBM Corp. 1991, 1999 iii
Communication ...... 12 Ways to Connect Tivoli OPC Systems ...... 12 Shared DASD ...... 12 MVS Cross-System Coupling Facility ...... 13 VTAM (Network Communication Function) ...... 13 Workstation Destination ...... 13 Workload Restart ...... 14 JES Considerations ...... 14 Tivoli OPC Basic Configuration Examples ...... 15 DASD Connected ...... 16 VTAM Connected ...... 17 XCF Connected ...... 18 Tracker and Controller in a Single Address Space ...... 20 | Tivoli OPC Data Store Basic Configuration Examples ...... 21 | SNA Connected ...... 21 | XCF Connected ...... 23
Chapter 3. Planning Your Installation of Tivoli OPC ...... 25 Installation Considerations ...... 25 Configuring for Availability ...... 25 Hot Standby ...... 25 Starting an Event Writer with an Event Reader Function ...... 25 Checklist for Installing Tivoli OPC ...... 26
Part 2. Installing Tivoli OPC ...... 33
Chapter 4. Installing Tivoli OPC ...... 35 Loading Tracker Software ...... 36 Loading Controller Software ...... 36 Loading National Language Support Software for the Controller ...... 37 Loading Workload Monitor/2 Software to MVS ...... 37 Loading Workload Monitor/2 NLS Software to MVS ...... 38 Using the EQQJOBS Installation Aid ...... 38 Setting Up the EQQJOBS Installation Aid ...... 39 Creating the Sample Job JCL ...... 40 | Generating Tivoli OPC Data Store Samples ...... 43 Generating Tivoli OPC Batch-Job Skeletons ...... 45 Adding SMF and JES Exits for Event Tracking ...... 49 Updating SYS1.PARMLIB ...... 51 Defining Tivoli OPC Subsystems ...... 51 Calculating MAXECSA Values ...... 52 Authorizing the Tivoli OPC Load-Module Library ...... 54 Updating SMF Parameters ...... 54 Updating MVS Dump Options ...... 56 Updating the MVS Link-Library Definition ...... 56 Updating XCF Initialization Options ...... 57 Modifying TSO Parameters ...... 57 Performance Considerations ...... 59 Defining the DLF Exit for Hiperbatch Support ...... 59 Starting Tivoli OPC Automatically ...... 59 Updating APPC/MVS Options ...... 59 Implementing Support for Data Set Triggering ...... 59 Setting Up the Tivoli OPC RACF Environment ...... 60
iv Tivoli OPC Installation Guide
Controlling the User ID of the Tivoli OPC Address Space ...... 61 Controlling the User ID of Tivoli OPC-Submitted Jobs ...... 61 Normal Batch Jobs ...... 61 Tivoli OPC Batch Jobs ...... 62 Protecting Tivoli OPC Data Sets ...... 62 Controlling Access to Tivoli OPC Resources ...... 62 | Permitting Access to the Controller through the API ...... 64 | Controlling Access to Tivoli OPC Resources when Using Tivoli Job | Scheduling Console ...... 64 | Permitting Access to the Controller through the Tivoli Job Scheduling | Console ...... 65 Authorizing Tivoli OPC as a Job Submitter ...... 65 Authorizing Tivoli OPC to Issue JES Commands ...... 66 Allocating Tivoli OPC Data Sets ...... 67 Allocating the VSAM Data Sets ...... 68 Application Description Dataset (EQQADDS) ...... 71 Current Plan Datasets (EQQCPnDS) ...... 71 JCL Repository Datasets (EQQJSnDS) ...... 72 Allocating Tivoli OPC Non-VSAM Data Sets ...... 72 Internal Reader Dataset (EQQBRDS) ...... 75 Checkpoint Dataset (EQQCKPT) ...... 75 Diagnostic Datasets (EQQDMSG, EQQDUMP, and SYSMDUMP) .... 75 Event Dataset (EQQEVDS and EQQEVDnn) ...... 76 Job Library Dataset (EQQJBLIB) ...... 78 Job-Completion-Checker Datasets ...... 78 Job-Tracking Datasets (EQQJTARC, EQQJTnn, EQQDLnn) ...... 79 Message Log Dataset (EQQMLOG) ...... 80 Parameter Library (EQQPARM) ...... 80 PIF Parameter Dataset (EQQYPARM) ...... 80 Automatic-Recovery-Procedure Library (EQQPRLIB) ...... 80 Started-Task-Submit Dataset (EQQSTC) ...... 81 Submit/Release Dataset (EQQSUDS) ...... 81 | Allocating Tivoli OPC Data Store Data Sets ...... 81 | Creating JCL Procedures for Tivoli OPC Address Spaces ...... 82 Implementing Support for Started-Task Operations ...... 82 Required Data Sets ...... 83 Optional Data Sets ...... 85 Defining the Initialization Statements ...... 86 Creating the DB2 Database ...... 87 Setting Up the ISPF Environment ...... 87 Setting Up the Tivoli OPC CLIST Library ...... 87 Setting Up the ISPF Tables ...... 88 Setting Up the Default Dialog–Controller Connection Table ...... 88 Setting Up List Tables and Graphical Attribute Tables ...... 89 Allocating Dialog Data Sets to Your TSO Session ...... 89 Invoking the Tivoli OPC Dialog ...... 90 Using the EQQOPCAC Sample CLIST ...... 90 Modifying an Existing ISPF Selection Menu ...... 90 Selecting the Tivoli OPC Main Menu Directly from TSO ...... 91 Using the ISPF Select Service ...... 91 Using XCF for Communication ...... 91 Tivoli OPC XCF Groups ...... 91 XCF Run-Time Options ...... 92 Tivoli OPC Initialization Statements Used for XCF ...... 92
Contents v
Activating the Network Communication Function ...... 93 Adding NCF to the VTAM Network Definitions ...... 93 Adding NCF Session Parameters ...... 95 COS Table ...... 96 Activating Network Resources ...... 96 Diagnostic Data Set ...... 96 Controlling OPC/A Release 2 via a VTAM Link ...... 96 Activating Support for the Tivoli OPC API ...... 96 Defining VTAM Resources ...... 97 Defining a Local LU ...... 97 Defining Logon Modes ...... 98 Defining Cross-Domain Resources ...... 99 Updating APPC/MVS Options ...... 99 Activating Tivoli OPC Support for APPC/MVS ...... 100 | Activating Support for the Tivoli OPC APPC/MVS Server ...... 100 Defining VTAM Resources ...... 101 Defining a Local LU for the Server ...... 101 Defining Logon Modes for the Server ...... 102 Updating APPC/MVS Options for the Server ...... 103 Activating Tivoli OPC Server Support for APPC/MVS ...... 104 | Activating Support for the Tivoli Job Scheduling Console ...... 104 | Activating Tivoli OPC Server Support for TCP/IP ...... 104
Chapter 5. Verifying Tivoli OPC Installation ...... 105 Overview of Verification ...... 105 Verifying Installation of a Tracker ...... 105 Ensuring that All Installation Tasks Are Complete ...... 106 Checking the Message Log (EQQMLOG) ...... 106 Verifying Tracking Events ...... 107 The Event Writer ...... 107 The Event Dataset ...... 107 Performing Problem Determination for Tracking Events ...... 109 Verifying Installation of a Controller and Dialogs ...... 111 Ensuring that All Installation Tasks Are Complete ...... 112 Checking the Message Log (EQQMLOG) ...... 112 Checking the Server Message Log ...... 113 Checking Tivoli OPC Dialog Functions ...... 114 Performing Problem Determination ...... 114 Tivoli OPC Dialog Problems ...... 114 Tivoli OPC Authority Problems ...... 114 Verifying Installation of a Standby Controller ...... 115 Ensuring that All Installation Tasks Are Complete ...... 116 Checking the Message Log (EQQMLOG) ...... 116 Verifying Tivoli OPC Configuration ...... 118 Creating Entries in the Databases ...... 118 Running Tivoli OPC Batch Jobs ...... 118 Checking the Message Logs (EQQMLOG) ...... 118 Controller Message Log ...... 118 Tracker Message Log ...... 125 Verifying Workload Submission ...... 128 Controlling System ...... 128 Controlled Systems ...... 129 Verifying Job Submission ...... 129 Verifying Takeover by a Standby Controller ...... 130
vi Tivoli OPC Installation Guide
Part 3. Migrating ...... 131
Chapter 6. Planning for Migration ...... 133 Installation Considerations ...... 133 Customization Considerations ...... 134 Migration Strategies ...... 134 Controlled Tivoli OPC and OPC/A Systems ...... 134 JES and SMF Exits ...... 134 Migration Effect on Workload Monitor/2 Users ...... 135 Migrating to Existing Subsystem Definitions ...... 135 Migrating to New Subsystem Definitions ...... 135 Getting the Right Software Parts ...... 135 Load Modules ...... 136 The ISPF environment ...... 137 Migration Overview ...... 137 Tivoli OPC Version 2 Migration Overview ...... 137 Establishing the Required Environment ...... 137 Program Requirements ...... 138 Installation and Verification ...... 138 Parallel Testing ...... 139
Chapter 7. Migration Actions ...... 141 Migrating Data Sets to Tivoli OPC Version 2 ...... 141 EQQICTOP VSAM Dataset Conversion Program ...... 141 Example ...... 144 Data Sets that You Need to Convert ...... 145 Data Sets that Tivoli OPC Version 2 Can Use ...... 145 Empty Datasets ...... 146 Switching Tivoli OPC Version 2 into Production Mode ...... 146 Closing Down Your Production System ...... 147 Ensuring that LTP and NCP Data Sets Are Current ...... 147 Converting VSAM Files to Tivoli OPC Version 2 Format ...... 148 Starting the New System ...... 148 Validating the New System ...... 149 Performing Fallback from Tivoli OPC Version 2 ...... 149
Part 4. Appendixes ...... 153
Appendix A. Sample Library (SEQQSAMP) ...... 155 SMP/E Samples ...... 158 Environment Setup ...... 158 RECEIVE Processing ...... 159 APPLY Processing ...... 160 ACCEPT Processing ...... 160 SMF Exits ...... 161 Exit Installation ...... 161 Job Step Termination Exit ...... 162 Initialization Exit ...... 162 Record Write Exit ...... 162 JES Exits ...... 162 Exit Installation ...... 163 JES2 JCT I/O Exit ...... 163
Contents vii
JES3 OSE Modification Exit ...... 163 JES3 Input Service Final-User Exit ...... 163 RACF Samples ...... 164 Class Descriptor Table ...... 164 Router Table ...... 164 | MASS Update Samples ...... 164
Appendix B. Tivoli OPC Configuration Examples ...... 167 The Controlling System ...... 167 Tivoli OPC Version 2 Controller ...... 167 Automatic Restart Actions ...... 167 Initialization Statements ...... 167 Multi-Access Spool Systems Connected via Shared DASD ...... 168 Individual Systems Connected via Shared DASD ...... 170 An MVS Sysplex ...... 173 A Tivoli OPC PLEX Configuration ...... 175 Controlling an MVS System via a VTAM Link ...... 177 Controlling a JES2 MAS System via a VTAM Link ...... 179 Controlling an OPC/A Release 2 System via Shared DASD ...... 181 Controlling an OPC/A Release 2 System via a VTAM Link ...... 185
Appendix C. Invoking the EQQEXIT Macro ...... 189 Invoking EQQEXIT in SMF Exits ...... 189 Invoking EQQEXIT in JES Exits ...... 189 Macro Invocation Syntax for EQQEXIT ...... 190 Return Codes ...... 191
Appendix D. Invoking the EQQLSENT Macro ...... 193 Invoking EQQLSENT to Create EQQDSLST ...... 193 Macro Invocation Syntax for EQQLSENT ...... 193 Return Codes ...... 195
Appendix E. Tivoli OPC Hardware and Software Requirements ..... 197 Hardware Requirements ...... 197 Software Requirements and Optional Software ...... 199 Controlling System ...... 199 | Tivoli Job Scheduling Console ...... 200 | OPC Connector ...... 200 Workload Monitor/2 ...... 200 Controlled OS/390 Systems ...... 201 Controlled OS/2 Systems ...... 201 Controlled Windows NT Systems ...... 201 Controlled OS/400 Systems ...... 201 Controlled UNIX Systems ...... 201 Controlled Digital OpenVMS Systems ...... 202 | Controlled Silicon Graphics IRIX Systems ...... 202 | Controlled OS/390 UNIX System Services ...... 202 Controlled Digital UNIX Systems ...... 203 Optional Software ...... 203 Related Software ...... 204 Software Compatibility ...... 204
Appendix F. History of Changes Since OPC/ESA Version 1 Release 1 . 207 Changes to Initialization Statements ...... 207
viii Tivoli OPC Installation Guide
New Initialization Statements ...... 207 The APPCROUT Statement ...... 208 The EXITS Statement ...... 208 The INIT Statement ...... 208 The INTFOPTS Statement ...... 209 The JOBOPTS Statement ...... 209 The NOERROR Statement ...... 209 The RESOPTS Statement ...... 210 The RESOURCE Statement ...... 210 The RODMOPTS Statement ...... 210 The ROUTOPTS Statement ...... 210 The TRROPTS Statement ...... 211 The XCFOPTS Statement ...... 212 Deleted Initialization Statements ...... 212 Updates to Initialization Statements ...... 212 Changes to Commands ...... 216 MVS Commands ...... 216 TSO Commands ...... 217 Changes to Callable Services ...... 217 Changes to Programming Interfaces ...... 218 Changes to Installation Exits ...... 219 Exit Name Changes ...... 219 New and Changed Installation Exits ...... 219 Changes to Macros ...... 220 Changes to Messages ...... 220 Miscellaneous Changes ...... 220 Changes to ISPF Table Names ...... 220 Replacing OPC/A Batch-Job JCL ...... 220 Changes to Subsystem Data Sets ...... 220 OPC/ESA Release 1.0 Summary ...... 222 Control of Started Tasks ...... 222 Automatic JCL Handling ...... 222 Sysplex Exploitation ...... 222 Production Workload Restart ...... 223 Hot Standby ...... 223 Job Description Dialog ...... 223 Expanded NetView Communication ...... 223 Write-to-Operator Operations ...... 223 NetView Alerts ...... 223 Additional Enhancements ...... 223 Controlled Shutdown ...... 224 Global Display of Dependencies ...... 224 Time-Dependent Operations in an Interval ...... 224 Improved Handling of Submission Failures ...... 224 OPC/ESA Release 2.0 Summary ...... 224 Application Program Interface ...... 225 The Workload Monitor/2 ...... 225 Catalog Cleanup ...... 225 Automatic Successor Dependency Resolution ...... 225 Application Groups ...... 226 Dependency Loop Analysis ...... 226 Additional Enhancements ...... 226 LTP Extend and Trial Improvements ...... 226 On-Request Backup of CP and JS ...... 226
Contents ix
Audit Reporting ...... 226 NOERROR Constraints Removed ...... 227 Operability Enhancements ...... 227 Operation Feedback ...... 227 JT Logging Enhancements ...... 227 OPC/ESA Release 2.1 Summary ...... 227 Catalog-Management Extensions ...... 228 Data Set Triggering ...... 228 Open Systems Integration ...... 228 OPC/ESA Release 3.0 Summary ...... 228 Tracker Agents ...... 228 Special Resource Enhancements ...... 229 Monitoring Special Resources through RODM ...... 231 Programming Interface Enhancements ...... 231 Run Cycle Improvements ...... 232 Noncyclic Period Closed Interval Support ...... 232 Installability and Maintainability Improvements ...... 232 Reliability and Availability Improvements ...... 233 Security Changes ...... 233 Limitations Removed ...... 233 Update from the OPC/ESA Workload Monitor/2 ...... 234 Step-Level Restart Extensions ...... 234 Browse any Job Log and Interface to SYSOUT Archivers ...... 234 Smarter JCL Tailoring ...... 234 Changes to the Library ...... 235 ISPF Dialog Enhancements ...... 235 Miscellaneous Changes ...... 236 OPC/ESA Release 3.1 Summary ...... 236 Operations History Database ...... 236 Return Code Simulation ...... 236 OS/2 Tracker Agent ...... 236 Library Modifications ...... 236 21st Century Support ...... 237
Part 5. Glossary and Index ...... 239
Glossary ...... 241
Index ...... 253
x Tivoli OPC Installation Guide
Figures
1. An MVS System Connected via Shared DASD ...... 16 2. An MVS System with a VTAM Connection ...... 18 3. An MVS System with an XCF Connection ...... 19 4. A Tracker and Controller Configured in a Single Address Space ..... 21 | 5. Controller and Tracker in Same Address Space with Tracker Connected | via SNA ...... 22 | 6. Controller, Tracker, and Data Store Connected via XCF ...... 23 7. EQQJOBS0—EQQJOBS Application Menu ...... 39 8. EQQJOBS3—Create Sample Job JCL ...... 40 9. EQQJOBS4—Create Sample Job JCL ...... 41 | 10. EQQJOBS5—Create Data Store Samples ...... 43 | 11. EQQJOBS6—Create Data Store Samples ...... 44 | 12. EQQJOBS7—Create Data Store Samples ...... 44 13. EQQJOBS1—Generate Tivoli OPC Batch-Job Skeletons ...... 45 14. EQQJOBS2—Generate Tivoli OPC Batch-Job Skeletons ...... 47 15. Sample Message Log for a Standby Controller ...... 117 16. Sample Message Log for a Controller ...... 121 17. Sample Message Log for a Tracker ...... 127 18. Two MVS JES2 MAS Complexes Connected via Shared DASD .... 168 19. Individual Systems Connected via Shared DASD ...... 171 20. An MVS Sysplex ...... 173 21. A Tivoli OPC PLEX Environment ...... 176 22. Controlling an MVS System via a VTAM Link ...... 178 23. Controlling a JES2 MAS System via a VTAM Link ...... 180 24. Controlling an OPC/A Release 2 System via Shared DASD ...... 182 25. Controlling an OPC/A Release 2 System via a VTAM Link ...... 185
Copyright IBM Corp. 1991, 1999 xi
xii Tivoli OPC Installation Guide
Tables
1. The INCLUDE Statement ...... xxxvi 2. The INIT Statement ...... xxxvi 3. Changes to Installation Exits ...... xxxvii | 4. Tivoli OPC Subtasks ...... 6 5. These Stages Summarize the Tivoli OPC Installation Process ...... 9 6. Example EQQPARM Members for Figure 1 ...... 17 7. Example EQQPARM Members for Figure 2 ...... 18 8. Example EQQPARM Members for Figure 3 ...... 20 9. Example EQQPARM Members for Figure 4 ...... 21 | 10. Example Members for Figure 5 ...... 22 | 11. Example Members for Figure 6 ...... 23 12. Checklist for Installing Tivoli OPC ...... 26 13. Tivoli OPC Installation Tasks ...... 35 14. Tracker Libraries Loaded by SMP/E ...... 36 15. Controller Libraries Loaded by SMP/E ...... 37 16. NLS Libraries Loaded by SMP/E for the Controller ...... 37 17. Workload Monitor/2 Libraries Loaded by SMP/E ...... 38 18. NLS Libraries Loaded by SMP/E for Workload Monitor/2 ...... 38 19. Sample JCL Generated by the EQQJOBS Dialog ...... 42 | 20. Data Store Samples Generated by the EQQJOBS Dialog ...... 45 21. Controller Skeleton JCL Generated by the EQQJOBS Dialog ...... 48 22. Sample Exits for Tivoli OPC ...... 50 23. Examples of MAXECSA Storage Values ...... 53 24. Sample Library Members for Updating RACF Tables ...... 63 25. Tivoli OPC VSAM Datasets ...... 68 26. Calculations of VSAM Dataset Size ...... 69 27. Tivoli OPC Non-VSAM Datasets ...... 73 | 28. Data Store VSAM Datasets ...... 82 29. Tivoli OPC Required Datasets ...... 83 30. Tivoli OPC Optional Datasets ...... 85 31. ISPF and Tivoli OPC Dialog Datasets ...... 89 32. Problem Determination for Missing Tracking Events ...... 109 33. Datasets Needed for Table Space Conversion ...... 142 34. Datasets that You Need to Convert ...... 145 35. Datasets that Tivoli OPC Version 2 Can Use ...... 145 36. SEQQSAMP Library Members ...... 155 37. Example EQQPARM Members for Figure 13 ...... 169 38. Example EQQPARM Members for Figure 14 ...... 172 39. Example EQQPARM Members for Figure 15 ...... 174 40. Example EQQPARM Members for Figure 16 ...... 177 41. Example EQQPARM Members for Figure 17 ...... 179 42. Example EQQPARM Members for Figure 18 ...... 181 43. Example EQQPARM and DRKPARM for Figure 19 ...... 184 44. Example EQQPARM and DRKPARM for Figure 20 ...... 187 45. The APPCROUT Statement ...... 208 46. The EXITS Statement ...... 208 47. The INIT Statement ...... 208 48. The INTFOPTS Statement ...... 209 49. The JOBOPTS Statement ...... 209 50. The NOERROR Statement ...... 209
Copyright IBM Corp. 1991, 1999 xiii
51. The RESOPTS Statement ...... 210 52. The RESOURCE Statement ...... 210 53. The RODMOPTS Statement ...... 210 54. The ROUTOPTS Statement ...... 211 55. The TRROPTS Statement ...... 211 56. The XCF Statement ...... 212 57. Changes to the ALERTS Statement ...... 212 58. Changes to the AROPTS Statement ...... 212 59. Changes to the AUDIT Statement ...... 213 60. Changes to the AUTHDEF Statement ...... 213 61. Changes to the BATCHOPT Statement ...... 213 62. Changes to the EWTROPTS Statement ...... 214 63. Changes to the JCCOPTS Statement ...... 214 64. Changes to the JTOPTS Statement ...... 214 65. Changes to the OPCOPTS Statement ...... 215 66. Renamed Exits ...... 219 67. Changes to Installation Exits ...... 219
xiv Tivoli OPC Installation Guide
Notices
References in this publication to IBM products, programs, or services do not imply that IBM intends to make these available in all countries in which IBM operates. Any reference to an IBM product, program, or service is not intended to state or imply that only IBM’s product, program, or service may be used. Subject to IBM’s valid intellectual property or other legally protectable rights, any functionally equivalent product, program, or service may be used instead of the IBM product, program, or service. The evaluation and verification of operation in conjunction with other products, except those expressly designated by IBM, is the user’s responsibility.
IBM may have patents or pending patent applications covering subject matter in this document. The furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to:
IBM Director of Licensing IBM Corporation North Castle Drive Armonk, NY 10504-1785 U.S.A.
Licensees of this program who wish to have information about it for the purpose of enabling: (i) the exchange of information between independently created programs and other programs (including this one) and (ii) the mutual use of the information which has been exchanged, should contact:
IBM Corporation P.O. Box 12195 3039 Cornwallis Research Triangle Park, NC 27709-2195 U.S.A.
Such information may be available, subject to appropriate terms and conditions, including in some cases, payment of a fee.
Programming Interface Information This book is intended to help you install Tivoli Operations Planning and Control (Tivoli OPC).
This book also documents General-use Programming Interface and Associated Guidance Information, and Diagnosis, Modification, or Tuning Information provided by Tivoli OPC.
General-use programming interfaces allow the customer to write programs that obtain the services of Tivoli OPC.
Copyright IBM Corp. 1991, 1999 xv
General-use Programming Interface and Associated Guidance Information is identified where it occurs, either by an introductory statement to a chapter or section, or by the following marking:
General-use programming interface
General-use Programming Interface and Associated Guidance Information...
End of General-use programming interface
Diagnosis, Modification, or Tuning Information is provided to help you verify the Tivoli OPC environment is installed correctly.
Attention: Do not use this Diagnosis, Modification, or Tuning Information as a programming interface.
Diagnosis, Modification, or Tuning Information is identified where it occurs, either by an introductory statement to a chapter or section, or by the following marking:
Diagnosis, Modification, or Tuning Information
Diagnosis, Modification, or Tuning Information...
End of Diagnosis, Modification, or Tuning Information
Trademarks The following terms are trademarks of Tivoli Systems or IBM Corporation in the United States or other countries or both:
ACF/VTAM AIX AIX/6000 AS/400 BookManager CICS DATABASE 2 DB2 DFSMS/MVS DFSMShsm DFSORT Extended Services for OS/2 GDDM Hiperbatch Hiperspace IBM IBMLink IMS LoadLeveler MVS/DFP MVS/ESA MVS/SP MVS/XA NetView OPC Operating System/2 OS/2 OS/390 OS/400 Personal System/2 PS/2 RACF RISC System/6000 RS/6000 SAA Sysplex Timer Systems Application Architecture VM/ESA Tivoli TME TME 10 VTAM Workplace Shell
In Denmark, Tivoli is a trademark licensed from Kjøbenhavns Sommer
xvi Tivoli OPC Installation Guide
- Tivoli A/S
Microsoft, Windows, Windows NT, and the Windows logo are trademarks or registered trademarks of Microsoft Corporation.
UNIX is a registered trademark in the United States and other countries licensed exclusively through X/Open Company Limited.
C-bus is a trademark of Corollary, Inc.
| Java and all Java-based trademarks or logos are trademarks of Sun Microsystems, Inc.
PC Direct is a trademark of Ziff Communications Company and is used by IBM Corporation under license.
ActionMedia, LANDesk, MMX, Pentium, and ProShare are trademarks or registered trademarks of Intel Corporation in the United States and other countries.
Other company, product, and service names which may be denoted by a double asterisk (**), may be trademarks or service marks of others. DEC Digital Equipment Corporation Hewlett-Packard Hewlett-Packard Corp. HP-UX Hewlett-Packard Corp. Solaris Sun Microsystems, Inc. SPARC SPARC International, Inc. SPARCstation SPARC International, Inc. Sun Sun Microsystems, Inc. SunOS Sun Microsystems, Inc. VMS Digital Equipment Corporation
Notices xvii
xviii Tivoli OPC Installation Guide
Preface
Planning is the task of making fundamental decisions about the options a program offers. These decisions guide, set limits for, and identify requirements for the tasks of installation, customization, administration, and diagnosis. Installation is the task of making a program ready to do useful work. This task includes adding the materials on the IBM distribution tape to your system, initializing the program, and applying PTFs to the program. When you install a product, you are carrying out decisions you made in the planning step. Customization, an optional step, gives you the opportunity to tailor the program to the desired behavior or special needs of your site.
This guide complements the Tivoli OPC Program Directory, which covers adding the materials on the IBM distribution tape to your system.
The Program Directory comes with the Tivoli OPC installation tape. It describes all of the installation materials and gives installation instructions specific to the product release level or feature number. If any differences exist between this guide and the Program Directory, use the information in the Program Directory. This book covers the configuration planning and installation tasks.
Who Should Read This Guide This guide is for system programmers who are responsible for software on an MVS system. You should read this book if you will install Tivoli OPC Version 2.
Installation, configuration, and operation of OPC Tracker Agents for non-MVS environments are not described in this guide. These topics are covered in separate books, one for each operating system, that you receive when you order the controller enabling feature for the Tracker Agent.
Required Product Knowledge To use this book effectively, you must know job control language (JCL) and the IBM System Modification Program Extended (SMP/E). You also need sound working knowledge of MVS and JES concepts and facilities. You must be able to understand and write small code fragments in the Assembler H language. You should be familiar with the Interactive System Productivity Facility (ISPF), the Interactive System Productivity Facility/Program Development Facility (ISPF/PDF), and the Time-Sharing Option (TSO). A good working knowledge of Virtual Storage Access Method (VSAM) is desirable but not essential.
Tivoli OPC trackers can be connected to the controller by a variety of methods. Two of these methods, the Virtual Telecommunications Access Method (VTAM) and the cross-system coupling facility (XCF), require specialized skills. If you do not have these skills, you will need help from others in your organization who have these skills.
| The Tivoli OPC Application Programming Interface (API) uses advanced program-to-program communication (APPC) services. Defining and configuring the conversation partners requires some knowledge of APPC services. Installation of the Workload Monitor/2 requires knowledge of OS/2 and familiarity with the
Copyright IBM Corp. 1991, 1999 xix
Communications Manager product installed on the OS/2 workstation, either | Communications Manager in Extended Services for OS/2 or Communications | Manager/2 (CM/2).
How to Use This Guide Read all of “Part 1. Planning” first. It helps you to understand all of the decisions and steps involved in installing Tivoli OPC. Then follow the steps in the Tivoli OPC Program Directory to add the materials from the IBM distribution tape to your system. Then read “Part 2. Installing Tivoli OPC.”
If you are migrating to Tivoli OPC Version 2 from an earlier version or release of OPC/ESA or OPC/A, read the information in “Part 3. Migrating.” This part contains a conversion notebook documenting the installation-related changes between the version or release currently installed and Tivoli OPC Version 2. Step-by-step instructions for migration and fallback follow.
How This Guide Is Organized The information in this book is organized into these sections: Part 1. Planning Chapter 1, “Overview” describes the Tivoli OPC parts, subtasks, and introduces the Tivoli OPC configuration options. Chapter 2, “Planning Your Tivoli OPC Configuration” describes connections between Tivoli OPC systems and provides possible configurations to consider when planning your installation. Part 2. Installing Tivoli OPC Chapter 3, “Planning Your Installation of Tivoli OPC” presents considerations for the installation process and provides a checklist that you can use to perform the installation. Chapter 4, “Installing Tivoli OPC” guides you, step-by-step, through the installation process, from loading software to verifying that the product has been installed correctly. Chapter 5, “Verifying Tivoli OPC Installation” contains the installation verification process. Part 3. Migrating Chapter 6, “Planning for Migration” describes planning for migration from OPC/A Release 2 or OPC/ESA Version 1. Chapter 7, “Migration Actions” guides you, step-by-step, through the conversion process to Version 2 from earlier versions and releases of OPC/ESA or OPC/A. Part 4. Appendixes Appendix A, “Sample Library (SEQQSAMP)” describes the members of the sample library. Appendix B, “Tivoli OPC Configuration Examples” contains complex configuration examples for multiple systems and multiple data centers.
xx Tivoli OPC Installation Guide
Appendix C, “Invoking the EQQEXIT Macro” describes how you generate event-tracking code using the event-tracking-exits macro. Appendix D, “Invoking the EQQLSENT Macro” describes how to create a table of dataset names that you want to monitor for dataset close. Appendix E, “Tivoli OPC Hardware and Software Requirements” lists the hardware and software prerequisites. Appendix F, “History of Changes Since OPC/ESA Version 1 Release 1” summarizes the changes made in all releases of OPC/ESA Version 1.
Tivoli OPC Publications This book is part of an extensive Tivoli OPC library. These books can help you use Tivoli OPC more effectively:
Task Publication Order number Evaluating Tivoli OPC General Fact Sheet GH19-4370 Evaluating Tracker Agents Tracker Agent Features Fact Sheet GH19-4371 Planning Tivoli OPC Licensed Program Specifications GH19-4373 Understanding Tivoli OPC General Information GH19-4372 Learning Tivoli OPC concepts Getting Started with Tivoli OPC SH19-4481 and terminology | Using the Java GUI Tivoli Job Scheduling Console Guide for OPC Users GC32-0402 | Using the Java GUI Tivoli Job Scheduling Console Release Notes GI10-9233 Interpreting messages and Messages and Codes SH19-4480 codes Installing Tivoli OPC Installation Guide SH19-4379 Customizing and tuning Tivoli Customization and Tuning SH19-4380 OPC Planning and scheduling the Planning and Scheduling the Workload SH19-4376 workload Controlling and monitoring the Controlling and Monitoring the Workload SH19-4377 current plan Using Workload Monitor/2 Workload Monitor/2 User’s Guide SH19-4482 Writing application programs Programming Interfaces SH19-4378 Quick reference Quick Reference GH19-4374 Diagnosing failures Diagnosis Guide and Reference LY19-6405 Controlling the AIX, UNIX**, Tracker Agents for AIX, UNIX, VMS, OS/390 Open Edition SH19-4484 VMS, OS/390 Open Edition Installation and Operation workload Controlling the OS/2 and NT Tracker Agents for OS/2 and Windows NT SH19-4483 workload Installation and Operation Controlling the OS/400 Tracker Agent for OS/400 SH19-4485 workload Installation and Operation
A Master Index, SH19-4375, is published for the Tivoli OPC library.
Preface xxi
Maximizing Your OPC Throughput, SG24-2130, contains useful information for tuning the OPC installation.
Tivoli OPC Online Books All the books in the Tivoli OPC library, except the licensed publications, are available in displayable softcopy form on CD-ROM in the following Softcopy Collection Kit: OS/390, SK2T-6700
You can read the softcopy books on CD-ROMs using these IBM licensed programs: BookManager READ/2 (program number 5601-454) BookManager READ/DOS (program number 5601-453) BookManager READ/6000 (program number 5765-086)
All the BookManager programs need a personal computer equipped with a CD-ROM disk drive (capable of reading disks formatted in the ISO 9660 standard) and a matching adapter and cable. For additional hardware and software information, refer to the documentation for the specific BookManager product you are using.
Updates to books between releases are provided in softcopy only.
Online Message Facility The Online Message Facility (OMF) is an OS/2 program that provides online access to information from BookManager softcopy books. It helps you diagnose problems without interrupting your work. You can retrieve the description of a message by clicking on a message number in a Communications Manager emulator window. Additional information about OMF is available on the Messages and Codes CD-ROM.
Required Publications You should familiarize yourself with the information presented in these publications before you install Tivoli OPC:
Short title Publication Order number JCL Reference MVS JCL Reference GC28-1654 MVS SP5 JCL Reference GC28-1479 JCL User’s Guide MVS JCL User’s Guide GC28-1653 MVS SP5 JCL User’s Guide GC28-1473 SMP/E Reference System Modification Program Extended Reference SC28-1107 SMP/E User’s Guide System Modification Program Extended User’s Guide SC28-1302 SMP/E Messages System Modification Program Extended Messages and GC28-1108 Codes
xxii Tivoli OPC Installation Guide
Books about Related Products These publications are referred to in the text or contain information that you might need to reference when installing Tivoli OPC:
Short title Publication Order number DB2 Administration Guide IBM DATABASE 2 Version 2 Release 3 Administration SC26-4374 Guide DB2 SQL Reference IBM DATABASE 2 Version 2 Release 3 SQL Reference SC26-4380 DFSORT Getting Started Getting Started with DFSORT SC26-4019 Performance Reporter Performance Reporter for MVS Administration Guide SH19-6816 Administration Performance Reporter System Performance Reporter for MVS System Performance SH19-6819 Performance Reference Feature Reference GDDM General Information Graphical Data Display Manager General Information GC33-0319 Graphical Data Display Manager Version 3 General GC33-0866 Information DFHSM Command Reference Data Facility Hierarchical Storage Manager: System SH35-0083 Programmer’s Command Reference DFSMS/MVS Managing Your Own Data with DFSMS SH21-1077 Info Planning and Installation Information/Management Version 6 Planning and SC34-4455 Installation Guide and Reference ISPF Reference Summary ISPF/PDF Version 3 MVS Reference Summary SC34-4214 ISPF Version 4 Reference Summary SC34-4445 ISPF Planning and Customization ISPF and ISPF/PDF Planning and Customization SC34-4257 ISPF Version 4 Planning and Customization SC34-4433 ISPF Guide and Reference ISPF Dialog Management Guide and Reference SC34-4266 ISPF Dialog Developer’s Guide and Reference SC34-4486 ISPF Examples ISPF Dialog Management Services Examples SC34-4215 ISPF Version 4 Examples SC34-4415 MVS Assembler Guide MVS Application Development Guide: Assembler GC28-1644 Language Programs MVS SP5 Programming Assembler Services Guide GC28-1466 MVS Assembler Reference MVS Application Development Reference: Services for GC28-1642 Assembler Language Programs MVS SP5 Programming Assembler Services Reference GC28-1474 System Commands MVS/ESA System commands GC23-1626 MVS/ESA SP5 System commands GC23-1442 MVS Init and Tuning Guide MVS/ESA Initialization and Tuning Guide GC28-1634 MVS/ESA SP5 Initialization and Tuning Guide SC28-1451 MVS Init and Tuning Reference MVS/ESA Initialization and Tuning Reference GC28-1635 MVS/ESA SP5 Initialization and Tuning Reference SC28-1452
Preface xxiii
Short title Publication Order number APPC Management MVS/ESA Planning: APPC Management GC28-1110 MVS SP5 Planning: APPC Management GC28-1082 Security Planning MVS/ESA Planning: Security GC28-1604 MVS SP5 Planning: Security GC28-1439 Sysplex Management MVS/ESA Planning: Sysplex Management GC28-1620 MVS/ESA SP5 Setting up a Sysplex GC28-1449 MVS/ESA SMF MVS/ESA System Management Facility (SMF) GC28-1628 MVS/ESA SP5 System Management Facility (SMF) GC28-1457 DFP Services for ICF MVS/DFP: Access Method Services for the Integrated SC26-4562 Catalog Facility DFSMS/MVS Version 1 Access Method Services for the SC26-4905 Integrated Catalog Facility DFP Services for VSAM MVS/DFP: Access Method Services for VSAM Catalogs SC26-4570 DFSMS/MVS Version 1 Access Method Services for VSAM SC26-4906 Catalogs DFP Utilities MVS/DFP: Utilities SC26-4559 DFSMS/MVS Version 1 Utilities SC26-4926 JES2 Initialization and Tuning MVS/ESA JES2 Initialization and Tuning Guide SC23-0082 Guide MVS/ESA SP5 JES2 Initialization and Tuning Guide SC23-1453 JES2 Initialization and Tuning MVS/ESA JES2 Initialization and Tuning Reference SC23-0083 Reference MVS/ESA SP5 JES2 Initialization and Tuning Reference SC23-1454 JES2 Commands MVS/ESA JES2 commands GC23-0084 MVS/ESA SP5 JES2 commands GC23-1443 JES3 Init and Tuning Guide MVS/ESA JES3 Initialization and Tuning Guide SC23-0088 MVS/ESA SP5 JES3 Initialization and Tuning Guide SC23-0073 JES3 Init and Tuning Reference MVS/ESA JES3 Initialization and Tuning Reference SC23-0089 MVS/ESA SP5 JES3 Initialization and Tuning Reference SC23-1456 JES3 Commands MVS/ESA JES3 commands GC23-0090 MVS/ESA SP5 JES3 commands SC28-1444 NetView General Information NetView General Information and Planning GC31-7098 NetView User’s Guide NetView User’s Guide SC31-7067 OPC/A Installation and OPC/A Installation and Customization SH19-6445 Customization RACF Command Reference Resource Access Control Facility Command Language SC28-0733 Reference Resource Access Control Facility Version 2 Command SC23-3731 Language Reference RACF Administrator’s Guide Resource Access Control Facility Security Administrator’s SC28-1340 Guide Resource Access Control Facility Security Version 2 SC23-3726 Administrator’s Guide
xxiv Tivoli OPC Installation Guide
Short title Publication Order number SPL: RACF RACF System Programming Library: Resource Access SC28-1343 Control Facility SLR General Information Service Level Reporter Version 3 Release 3 General GH19-6529 Information SNA Formats SNA Formats GA27-3136 TCP/IP User’s Guide IBM Transmission Control Protocol/Internet Protocol for SC31-6088 MVS: User’s Guide TSO/E Customization TSO Extensions Version 2 Customization SC28-1872 VTAM Customization VTAM Customization LY43-0056 VTAM Version 4 Customization LY43-0048 VTAM Operation VTAM Operation SC31-6435 VTAM Version 4 Operation SC31-6420 VTAM Resource Definition VTAM Resource Definition Reference SC31-6438 Reference VTAM Version 4 Resource Definition Reference SC31-6427 VTAM Samples VTAM Version 4 Resource Definition Samples SC31-6428 Tivoli GEM Installation and User's Tivoli Global Enterprise Manager: Installation and User's GC31-8474 Guide Guide Tivoli GEM Application Policy Tivoli Global Enterprise Manager: Application Policy GC31-5108 Manager User's Guide Manager User's Guide Tivoli GEM Instrumentation Guide Tivoli Global Enterprise Manager: Instrumentation Guide GC31-5109 SAP R/3 User's Guide SAP R/3 User's Guide GC31-5147 Maestro Supplemental Unison Maestro Supplemental Documentation Set SK3T-3566 Documentation Set
Preface xxv
xxvi Tivoli OPC Installation Guide
Summary of Tivoli OPC Version 2 Release 3 Enhancements
Job Scheduling Console The new Tivoli Job Scheduling Console (JSC) is a Java-based, client/server application. The key advantages of the JSC are the ability to perform administration and operation tasks in a graphical manner and the ability to access multiple OPC controllers from a single console.
The JSC can: Display lists of objects already defined to OPC, from the database and from the current plan, by using flexible filtering criteria Work with application descriptions including jobs and their dependencies, time restrictions (input arrival time, deadline, duration), and run cycles Work with special resource and workstation definitions Modify occurrences, workstation status, and special resource information from the current plan.
The JSC retains the OPC security model. Each data access request is validated by the controller as it is done currently for ISPF users.
The JSC is a real-time interface with OPC and can be used concurrently with the ISPF interface. It is available for various UNIX platforms, Windows NT, and Windows 98. The OPC Connector, which is a backend component supporting the JSC, is available for various UNIX platforms and Windows NT.
Catalog Management — Data Availability The new Catalog Management – Data Availability feature improves OPC performance for job restart and job log retrieval functions. Job runtime information, for example, the sysout datasets, is maintained locally on the tracked system. The controller retrieves this information only when needed for catalog management actions, eliminating the network and processing overhead associated with the transmission of superfluous data. The runtime information at the tracked system is managed by a new component, the OPC Data Store. Using the OPC Data Store, OPC Tracker processes are bypassed and are dedicated to the time-critical job submission and tracking tasks. A new feature is provided to selectively determine how long job runtime information is kept in the Data Store. This new feature is especially useful when a joblog archiving product is used concurrently with OPC.
OS/390 Workload Manager Support OS/390 Workload Manager, when used in goal mode, provides a new, policy-based management of deadlines for critical jobs. Some CPU-type operations can now be marked as critical in OPC. When such a critical operation is late, according to the specified policy, OPC interfaces with Workload Manager to move the associated job to a higher performance service class. Thus the job receives appropriate additional system resource to reduce or eliminate the delay. Several policies are available to
Copyright IBM Corp. 1991, 1999 xxvii
decide when a job is late, considering characteristics such as duration, deadline time, and latest start time.
OS/390 Automatic Restart Manager Support OS/390 Automatic Restart Manager increases the availability of OPC components. In the event of program failure, OPC components, for example, the Controller, the OS/390 Tracker and the Server can now be restarted automatically by the Automatic Restart Manager.
Program Interface (PIF) Enhancements The Program Interface (PIF) has been extended to increase the flexibility of OPC, allowing users to have extended access to OPC data from other application programs. Tivoli OPC Version 2 Release 3 significantly enhances the ability to access current plan data from the PIF by providing: Full support for special resources data Read access to special resource usage information for operations The ability to modify the workstation open intervals The ability to modify the successor information for an operation.
New resource codes have been added to the Program Interface (PIF): CPOPSRU Current plan operation segment with information for the operation in relation to a special resource CPSUC Current plan successor segment CSR Current plan special resources CSRCOM Current plan special resource common segment IVL Current plan workstation interval segment
Enhancements for Non-OS/390 Tracker Agents The OPC Tracker Agents for non-OS/390 platforms have been enhanced: A new version of the OPC Tracker Agent for OpenVMS is available. This new version runs in the native OpenVMS environment, thus removing the requirement to install the POSIX shell. The security features for the UNIX OPC Tracker Agents have been enhanced. Stricter file permissions are now used for temporary work files. The installation process of the OPC Tracker Agent for OS/390 UNIX System Services has been simplified.
xxviii Tivoli OPC Installation Guide
Usability Enhancements New features increase the overall usability of the product, thus increasing user productivity: OPC can perform variable substitution within inline procedures, thus increasing the flexibility of the job setup feature. It is possible to customize OPC so that jobs are submitted also when variables are not defined in the OPC variable tables. This means that, when variables are substituted outside OPC, duplicate variable definitions are avoided. During Catalog Management actions, OPC can delete datasets with an expiration date. A new Modify command (JSUACT) has been provided to start or stop the job submission function. This feature enables automation products, for example, Tivoli NetView to have control over the OPC job submission activity. The Mass Update utility has been enhanced with a new sample job This downloads all the applications belonging to a group in a sequential file for use as input to the Batch Loader utility, thus easing the management of group applications from the batch administration. The sample library now contains the DSECT sections for the Program Interface (PIF) data areas. This eases the process of writing PIF applications and the migration of existing PIF applications to new OPC releases.
New and Changed Installation Exits User exit EQQUX001 has three new parameters: NEWREC Number of JCL lines in new JCLAREA NEWJCL New JCLAREA USDREC Number of JCL lines used in new JCLAREA
User exit EQQUX007 has the new extended status (PEXSTAT) as part of its parameters set.
The Job Submission exit (installation exit 1) now allows changes to the size of JCL being processed. This enhancement gives users more flexibility to customize their operating environment.
The Operation Status Change exit (installation exit 7) has been enhanced to receive extended status information. This means that full status information is available within this exit to allow more detailed processing.
The samples set has two new samples: EQQCMX01 and EQQCMX05.
New and Changed Initialization Statements Two initialization statements have been added to enhance the JCL variable substitution: VARFAIL If VARFAIL is specified, JCL variable substitution error is bypassed for the specified types and variables are left unresolved in the submitted JCL.
Summary of Tivoli OPC Version 2 Release 3 Enhancements xxix
VARPROC Specifies whether or not the variables must be resolved also in the inline procedures.
Three initialization statements have been added to handle the OPC Data Store options: FLOPTS Defines the options for the FL (Fetch Job Log) task. A Controller uses this statement when OPCOPTS DSTTASK (YES) is specified. DSTOPTS Specifies options for the OPC Data Store. DSTUTIL Specifies options for the Data Store batch utilities and the clean up subtask.
Parameters have been added to, or changed in, the JOBOPTS statement so as to handle the new Data Store options: JOBLOGRETRIEVAL A new value DELAYEDST has been added to this keyword for specifying that the job log is to be retrieved by means of the OPC Data Store. DSTCLASS A new parameter to define the reserved held class that is to be used by the OPC Data Store associated with this tracker. DSTFILTER A new parameter to specify if the job-completion checker (JCC) requeues to the reserved Data Store classes only the sysouts belonging to these classes.
Parameters have been added to, or changed in, the OPCOPTS statement so as to handle the new catalog management functions: DSTTASK Specifies whether or not the OPC Data Store is to be used. JCCTASK A new DST value has been added to specify if the JCC function is not needed, but the Data Store is used.
A parameter has been added to the OPCOPTS and the SERVOPTS statements: ARM Activates automatic restart (via the Automatic Restart Manager) of a failed OPC component.
A parameter has been added to the OPCOPTS statement for the Workload Manager (WLM) support: WLM Defines the WLM options, that is, the generic profile for a critical job. The profile contains the WLM service class and policy.
xxx Tivoli OPC Installation Guide
Version 2 Release 2 Summary Instrumentation for Tivoli Global Enterprise Manager Tivoli Global Enterprise Manager (GEM) is the industry's first solution for unifying the management of cross-platform business applications that run businesses and make them competitive. Tivoli GEM helps you to manage strategic applications from a unique business systems perspective, focusing your IT resources on keeping these systems working properly and productively. Tivoli OPC has been enhanced to support the Job Scheduling Business System of the Tivoli GEM Systems Management Business System. From the Tivoli GEM console, which provides a single point of management, a Tivoli OPC user has complete control of all the Tivoli OPC components, regardless of the platform on which they run. In more detail, the Tivoli OPC instrumentation for Tivoli GEM enables you to do the following: Show all the Tivoli OPC components, including controllers, stand-by controllers, OS/390 trackers, AS/400 tracker agents, TCP/IP connected tracker agents. Show the different links between the above components. This provides, at a glance, a check on the health of the connections. For example, an OS/390 tracker might be running but might have no connection to the controller. For each component, manage a set of status parameters (monitors) specific to that component. These monitors might report the status of some vital OPC controller data sets such as database, current plan, and long-term plan) Manage this set of monitors graphically. You can: – Ask for value of the monitor – Be notified when the value of the monitor changes – Associate a severity (such as normal, warning, severe, or critical) with each monitor value Start or stop Tivoli OPC trackers without logging them on. Know at a glance, in a sysplex environment, which is the active controller and which the stand-by. Execute commands on Tivoli OPC components, from a single point of control, regardless of the platform and operating system used for that component. SAP R/3 support Tivoli OPC has been enhanced to exploit the Extended Agent technology of the Tivoli Workload Scheduler product. This technology enables Tivoli OPC to interface with a number of third party applications that can perform scheduling. By using this technology, you can now start and track a SAP R/3 job from Tivoli OPC. You can also retrieve and display the job log at the Tivoli OPC controller. This function requires the Tivoli OPC Tracker Agent for one of the following platforms: AIX Digital UNIX Sun Solaris Windows NT HP–UX
Summary of Tivoli OPC Version 2 Release 3 Enhancements xxxi
TCP/IP communication improvements The TCP/IP communication component that enables the controller to communicate with the TCP/IP connected tracker agents has been restructured to use the standard TCP/IP C–Socket interface. This change enables Tivoli OPC for the latest OS/390 releases and provides for the use of the standard TCP/IP features, such as the KEEPALIVE option. Catalog management enhancements The logic that Tivoli OPC uses when determining which catalog management actions to perform has been extended to manage the following situations: Some steps in a job are not executed, but are flushed. The datasets referred to in those steps are ignored by the catalog management function. A dataset referred to with disposition NEW in one step is also referred to in other steps. Logic to determine the action to perform in these cases has been added to the Catalog Management function. Dataset Delete function (EQQDELDS) improvements The Dataset Delete function has been enhanced to determine the correct action when a dataset referred to with disposition NEW in one step is also referred to in other steps. Logic to determine the correct action to perform in these cases has been added to the Dataset Delete function. The Dataset Delete function has also been improved to do the following: Delete datasets for which an expiration date was specified. Issue diagnostic information when the IDCAMS DELETE command or the DFHSM ARCHDEL command fails to delete a dataset. Current plan occurrence limit removal The maximum number of occurrences in the current plan has been increased from 32767 to 9999999. This enhancement enables you to manage the current plan more flexibly when you have large workloads. Operations in AD limit removal You can now define up to 255 operations in each Application Description. This enhancement provides for more flexibility in the definition of the workload. AD and OI consistency check The consistency between the Application Description and the Operator Instruction OPC databases is now enforced by OPC. For instance, whenever an operation is deleted the associated operator instructions is also deleted. Some usability enhancements have also been implemented in the Application Description dialogs when defining operator instructions. For instance, you can now also access temporary operator instructions. JCL editing from Application Description dialogs You can now customize the Tivoli OPC dialogs so that a library management application used in the customer's environment to manage the production jobs can be invoked from the Application Description OPC dialogs, thus increasing user productivity. New row commands have been added to invoke such an application from the Operation List panel while working with an Application Description. OPC Control Language tool The OPC Control Language (OCL) tool enables you to access and manipulate Tivoli OPC data by using a REXX-like language. Several xxxii Tivoli OPC Installation Guide
macro-functions are made available that perform, in a single action, what would require several invocations of the OPC Program Interface functions. The OCL tool acts as an extension to the REXX language processor. Therefore, normal REXX statements can be coded together with OCL statements. This tool runs in a batch TSO session. Tracker agents New Tracker Agents are provided to control the workload on: Digital UNIX OS/390 Open Edition SmartBatch coexistence Tivoli OPC has been extensively tested to make sure that all the features continue to work correctly when the production workload is under SmartBatch control. Other enhancements to functions EQQZSUBX 16 MB limit removal: because it is no longer necessary to move the JCL buffer below the 16 MB line before submitting it to JES2 or JES3, this processing has been removed from Tivoli OPC. To improve the robustness of Tivoli OPC, the STIMERM macro is now invoked, wherever the STIMER macro was previously invoked. Tivoli OPC Job-Submit user exit (EQQUX001) has been improved by adding two new parameters: WorkstationID and ErrorCode. When ErrorCode is set, Tivoli OPC will not submit the job. Tivoli OPC Operation-Status-Change user exit (EQQUX007) has been improved by adding the procstep name to the JOBAREA parameter. This enhancement provides for fully automated problem management. Debugging aids for performance problems: new statistics are now produced by Tivoli OPC to trace all the activities performed during the job submission process. These statistics are especially useful when you tune your systems to maximize job throughput in Tivoli OPC. You can dynamically activate and deactivate these statistics by means of new MODIFY commands. New and changed installation exits User exit EQQUX001 has two new parameters: RETCO The error code WSNAME The workstation name of submission process User Exit EQQUX007 has a new field in the JobArea called procedure step name. Changes to commands The following modify commands have been added: CPQSTA Activates or deactivates CP lock statistic messaging EVELIM Sets a new value for the EVELIM keyword of the JTOPTS statement EVESTA Activates or deactivates EVENT statistic messaging GENSTA Activates or deactivates GS task statistic messaging HB Issues a heartbeat message for an OPC controller or for all trackers connected to that controller JCLDBG Activates or deactivates the JCL debugging trace
Summary of Tivoli OPC Version 2 Release 3 Enhancements xxxiii
QUELEN Sets a new value for the QUEUELEN keyword of the JTOPTS statement STATIM Sets a new value for the STATIM keyword of the JTOPTS statement STATUS Returns status information about the OPC controller and the tracker agents connected to it. WSASTA Activates or deactivates WSA task statistic messaging New and changed initialization statements The following values have been added to the STATMSG keyword of the JTOPTS statement: EVELIM Makes customizable the event number criterion for statistic messaging. STATIM Uses an interval time criterion to issue statistics messaging. WSATASK Activates new statistics for WSA task. The following new values have been added to the SUBFAILACTION keyword of the JTOPTS statement: XC, XE and XR To specify how OPC must handle values returned by the Job Submission Exit (EQQUX001) for the RETCO parameter. A new keyword has been added to the BATCHOPT statement: MAXOCCNUM Set the maximum number of occurrences in the current plan for the daily planning function. A new keyword has been added to the JTOPTS statement: MAXOCCNUM Set the maximum number of occurrences in the Current Plan for the dialog, ETT, Automatic Recovery and PIF functions. Changes to programming interfaces The OPC Programming Interface (PIF) has been extended as follows: A new subsegment has been added to the Workstation record called the Workstation Access Method Information (WSAM). A new keyword, ADOICHK, has been added to the OPTIONS request to activate the consistency check between Application Description and Operator Instruction records.
Version 2 Release 1 Summary Tivoli OPC Version 2 Release 1 became generally available in March 1997. Major enhancements compared to OPC/ESA Release 3.1 are described in the following sections. Tracker agents New Tracker Agents are provided to control the workload on: Digital OpenVMS Pyramid MIPS ABI Shared parm library in Sysplex environment MVS controllers and trackers can share common controller and tracker initialization statements and started task JCLs, making it easier to install many OPC subsystems inside an MVS/ESA sysplex environment. xxxiv Tivoli OPC Installation Guide
Controller configuration in Sysplex environment Tivoli OPC support of MVS/ESA sysplex (base and parallel) has been extended to enable any one of many cloned controllers on different MVS images to switch from standby to active status. An OPC controller is started on each member of the XCF group. The first potential controller that becomes active is the active controller and the others are standby controllers. If the active controller fails, a standby controller running in another MVS/ESA image of the sysplex environment takes over automatically as the active controller. Single system image This enhancement allows OPC TSO dialog users and PIF users to be on a different MVS/ESA image from the OPC controller. Dialog users and PIF applications can also be on MVS systems outside the sysplex where the controller runs. Remote communication is based on APPC. Extended dialog filter The dialog filter has been extended to allow more specific search arguments and to define the interpretation of wildcard characters. Reparsing of NOERROR New operator commands allow the operator to dynamically update the NOERROR table using the NOERROR initialization statements defined by the OPC PARMLIB member, and to read the statements from a member of the EQQPARM DD concatenated libraries. In addition a new initialization statement allows the inclusion of NOERROR statements from members of the EQQPARM DD concatenated libraries. PIF extension Program Interface has been greatly extended to support almost all OPC database record types. Job tracking log This enhancement provides to user exit 11 job tracking records on which an effective disaster recovery procedure can be based. The customer through exit 11 receives job tracking records, and can send this data to a remote controller that, in case of failure of the active controller, will take over as controller. GMT clock support improvement The GMTOFFSET keyword in the OPCOPTS statement lets the user define an offset between the GMT time set in the MVS system and the actual GMT time. The OPC controller uses the GMT clock to validate an OPC Tracker Agent trying to connect; this improvement addresses the need of some users to have the MVS GMT clock independent of the actual GMT time, while keeping the ability to use Tracker Agents. Batch command interface tool A batch command interface tool is supplied to perform most of the actions supported by the PIF interface by means of a batch command interface. New and changed initialization statements Initialization statements have been added and changed in Tivoli OPC Version 2. The following sections summarize the differences. The INCLUDE statement Added in Tivoli OPC Version 2, the INCLUDE statement lets you reduce the size of the parameter library member that contains the
Summary of Tivoli OPC Version 2 Release 3 Enhancements xxxv
OPCOPTS and JTOPTS statements and reduce the associated maintenance activities.
Table 1. The INCLUDE Statement Keyword Short description NOERROR Specifies to read NOERROR information from other members of the EQQPARM library.
The INIT statement Added in OPC/ESA Release 3.1, the INIT statement lets you define run-time options for processing requests from a PIF application. These settings override the values set by the INTFOPTS statement in EQQPARM. The statement is defined in a second parameter file that is identified by the EQQYPARM DD statement in the JCL procedure of the PIF application. In Tivoli OPC Version 2 the LUNAME keyword has been added.
Table 2. The INIT Statement Keyword Short description CWBASE Specifies the origin for the century window used by the PIF application HIGHDATE Specifies the high date presented to the PIF application in valid-to fields LUNAME Specifies a server or controller LU name for the PIF application SUBSYS Identifies the Tivoli OPC subsystem controller TRACE Specifies the level of trace information to write to the diagnostic file.
Changes to commands These modify commands have been added: NEWNOERR Requests that the NOERROR statements be reprocessed. NOERRMEM (member) Requests that the NOERROR information be read from the specified member. The MODIFY command has been extended to accept stop and start of the server started tasks: F ssname, P=SERV S ssname, P=SERV Changes to programming interfaces The Programming Interface is extended as follows: UPDATE is supported for calendars, periods, workstations, and all workstations closed. BROWSE and UPDATE are supported for ETT and special resources.
xxxvi Tivoli OPC Installation Guide
The LIST request has been extended to support a new keyword, MATCHTYP, to specify whether generic search arguments (* and % are to be treated as normal characters. A new keyword, ADVERS, has been added to the OPTIONS request, to activate the support of AD versioning. New and changed installation exits Table 3 summarizes the changes to installation exits in Tivoli OPC Version 2.
Table 3. Changes to Installation Exits Exit name Short description of change EQQUX001 Tivoli OPC Version 2 now also supports the addressing modes RMODE(24) and AMODE(31). EQQUX011 Sample job tracking log write exit.
Messages Messages have been changed, deleted, and added in Tivoli OPC Version 2. Refer to Tivoli OPC Messages and Codes for the complete message text and descriptions. Note that in Version 2 the message text and explanations refer to the product as OPC/ESA.
Summary of Tivoli OPC Version 2 Release 3 Enhancements xxxvii
xxxviii Tivoli OPC Installation Guide
Part 1. Planning
Copyright IBM Corp. 1991, 1999 1
2 Tivoli OPC Installation Guide
Chapter 1. Overview
Tivoli OPC Operations Planning and Control (Tivoli OPC) can plan, control, and automate the entire production workload in your enterprise, not just the MVS/ESA batch subset. It automatically plans, controls, and monitors your production workload to maximize the throughput and optimize resource use, but lets you intervene manually when required.
This chapter introduces Tivoli OPC and its implementation. Later chapters describe the installation and migration tasks in greater detail.
If you are not familiar with Tivoli OPC terminology or functions, read Tivoli OPC General Information.
Tivoli OPC Parts and Their Relationships Tivoli OPC consists of a base product, the tracker, and a number of features. Every MVS image where Tivoli OPC is required to monitor and control the workload requires the base product. One MVS system in your complex is designated the controlling system and runs the controller feature. Only one controller feature is required, even when you want to start standby controllers on other MVS systems in a sysplex.
The Workload Monitor/2 is a feature that runs on a personal workstation, such as a | Personal System/2 (PS/2), that lets you view and update the Tivoli OPC current | plan.
You can control work that runs on non-MVS operating environments from a central Tivoli OPC controller. You need the appropriate OPC Tracker Agent feature on the non-MVS system, and the enabler feature on the controlling Tivoli OPC system. Refer to the Tracker Agent Fact Sheet for a list of supported operating environments.
The workload on other operating environments can also be controlled using the open interfaces provided with Tivoli OPC. Sample programs show you how you can control the workload on environments that have no Tracker Agent feature today.
Additionally, national language features let you see the Tivoli OPC dialogs, both ISPF and Workload Monitor/2, in the language of your choice. These languages are available: English German Japanese Spanish
This section describes the MVS tracker and controller, their relationship, and the ways in which you can configure them.
Copyright IBM Corp. 1991, 1999 3 Overview
Tracker A tracker is required for every MVS system in a Tivoli OPC configuration. The tracker handles the submission of jobs and tasks on the system, and keeps track of the status of the workload. In conjunction with standard interfaces to JES and SMF, Tivoli OPC records the relevant information about the workload by generating event records. The event records are captured and stored by the tracker. The tracker then communicates event information to the Tivoli OPC controller for further processing. The log where events are written by the tracker is called the event dataset.
Tivoli OPC address spaces are defined as MVS subsystems. Tivoli OPC routines that execute during subsystem initialization establish services that enable event information to be generated and stored in common storage (ECSA) even when an address space is not active.
| You can optionally install an OPC Data Store for each JES spool in a system. In a | simple JES configuration this would mean one Data Store for each Tracker. In | systems with shared spools (for example, JES2 MAS), there is a Data Store for | each spool, and there are fewer Data Stores than Trackers.
Controller The controller is the focal point of your Tivoli OPC configuration. It contains the controlling functions, the ISPF dialogs, the databases, and the plans. The system that the controller is started on is called the Tivoli OPC controlling system. Tivoli OPC systems that communicate with the controlling system are called controlled, or tracker systems. You need to install at least one controller for your production systems. It can control the entire Tivoli OPC configuration, the OPCplex, both local and remote.
You can use the Tivoli OPC controller to provide a single, consistent, control point for submitting and tracking the workload on any operating environment. Tivoli OPC provides tracker agents and open interfaces to let you integrate the planning, scheduling, and control of work units such as online transactions, file transfers, or batch processing in any operating environment that can communicate with MVS/ESA.
| Server for Dialogs, PIFs, and Tivoli Job Scheduling Console Tivoli OPC provides a server that enables you to access the controller remotely | from ISPF dialogs, PIFs, and from the Tivoli Job Scheduling Console interface. Connections with the server run through advanced program-to-program | communications APPC/MVS sessions, or just for the Tivoli Job Scheduling Console | using TCP/IP connections. The server runs in its own address space; however, it is optional if you do not access the controller remotely.
A Started Task JCL enables you to start and stop one or more servers either individually, using the Start and Stop operator commands, or automatically with the controller, using a keyword in the OPCOPTS statement. A server must start on the same MVS image as its controller.
| The PIF dialog connection to the controller, whether via server or subsystem | interface, is only allowed when the code is at the same level on both sides of the | interface.
4 Tivoli OPC Installation Guide Overview
| Data Store | Tivoli OPC provides a SYSOUT archiver by means of an OPC DATA Store address | space. It is used when JOBLOG retrieval (DELAYEDDST) is specified. The | controller and Data Stores can be connected either via XCF or via SNA.
Tivoli OPC Configurations You can configure Tivoli OPC to control virtually any combination of operating environments. Tivoli OPC can automatically schedule, submit, and track batch jobs, started tasks, and write-to-operator (WTO) messages. You can also use Tivoli OPC to coordinate manual activities in your production workload.
Your Tivoli OPC configuration can include: A controlling system Controlled systems: – Local and remote controlled MVS systems, including a parallel sysplex – Standby controller systems – Controlled OPC/ESA and OPC/A Release 2 systems – Controlled systems that run OPC Tracker Agents – Other operating environments that do not support an OPC Tracker Agent
Chapter 2, “Planning Your Tivoli OPC Configuration” on page 11 explains connections between Tivoli OPC systems and shows examples of configurations.
Controlling System A controlling Tivoli OPC system requires both a tracker and a controller. If you install only one Tivoli OPC system, this is the controlling system. The controlling Tivoli OPC system can communicate with controlled MVS systems using shared DASD, the MVS/ESA SP Version 4 Release 1 (or later) cross-system coupling facility (XCF), and the network communication function (NCF).
Controlled Systems A controlled MVS system requires a tracker. Communication with the controlling system is through shared DASD, XCF, or NCF. The tracker writes event records to an event dataset, and transfers the records to the controlling system if connected via XCF or NCF. NCF uses ACF/VTAM to link Tivoli OPC systems.
If you use XCF for communication, you can include a standby controller on one or more controlled systems. A standby controller is started in its own address space. It can take over the functions of the controller if MVS fails or if the controller itself fails. It cannot perform the functions of a tracker while in standby mode.
Tivoli OPC can control OPC/A Release 2 systems via shared DASD or a VTAM link. A system connected by shared DASD must have an OPC/A Release 2 Event Manager Subsystem (EMS) installed. A system connected via a VTAM link also requires the OPC/A Release 2 Network Event Communication (NEC) product. Events are sent to the Tivoli OPC controller using one of these connections. The controller cannot send work to an OPC/A Release 2 system via a VTAM link. If the OPC/A Release 2 system does not share DASD with the Tivoli OPC controller, work must be transmitted through a Network Job Entry (NJE) connection.
You can use Tivoli OPC to control workloads on operating environments that have OPC Tracker Agents. Controlled AS/400 systems connect to the controlling system
Chapter 1. Overview 5 Overview
using advanced program-to-program communication (APPC) services, and other controlled systems connect to the controlling system using transmission control protocol/internet protocol (TCP/IP) services.
The Tivoli OPC controller can also control the workload in other operating environments, such as VM/ESA. Tivoli OPC Customization and Tuning publication describes in detail controlling other operating environments.
Tivoli OPC Subtasks A Tivoli OPC address space consists of many MVS subtasks. Some of these subtasks are always attached when the Tivoli OPC address space is started, others are conditionally attached according to initialization parameters specified for the OPC options (OPCOPTS) statement in the Tivoli OPC parameter library. Table 4 describes the subtasks.
| Table 4 (Page 1 of 2). Tivoli OPC Subtasks | Subtask Component Description Component Activated by Function | ID code of FMID OPCOPTS parm | APPC PP APPC functions JOPC302 APPCTASK(YES) Starts APPC support | AR AR Automatic JOPC302 RECOVERY(YES) Manages failing operations | recovery | A4 A4 APPC tracker JOPC302 APPC keyword of Handles communications with | router ROUTOPTS APPC-connected Tracker | Agents | DC DC Catalog HOPC300 CATMGT(YES) Performs dataset cleanup for | management failed jobs or started tasks | DRT DX Data router HOPC300 Always activated Routes data to other subtasks | or Tivoli OPC subsystems | EMGR EM Event manager JOPC302 OPCHOST(YES) Processes job-tracking events | ERDR ER Event reader HOPC300 ERDRTASK(n) Reads events from an event | dataset | EWTR EW Event writer HOPC300 EWTRTASK(YES) Writes events to an event | dataset | EXA EX External router JOPC302 OPCHOST(YES) Calls EQQUX009 to route | submit requests to a | user-defined destination ID | FL FL Fetch joblog JOPC302 DSTTASK(YES) Retrieves joblog from data | store | GEN GS General service JOPC302 OPCHOST(YES) Processes Tivoli OPC dialog | requests | JCC JC Job completion HOPC300 JCCTASK(YES), Scans SYSOUT datasets | checker or | CATMLVL(STEP) | JLA JL JT log archiver JOPC302 OPCHOST(YES) Copies JT logs to the archive | dataset, EQQJTARC | NMM NM Normal mode JOPC302 OPCHOST(YES) Maintains the current plan | manager | RODM RM RODM support HOPC300 RODMTASK(YES) Starts RODM support
6 Tivoli OPC Installation Guide Overview
| Table 4 (Page 2 of 2). Tivoli OPC Subtasks | Subtask Component Description Component Activated by Function | ID code of FMID OPCOPTS parm | SUB SU Submit task HOPC300 Always activated Initiates work (job submit, job | release, and WTO and STC | operations) | TA TA TCP/IP router JOPC302 TCP keyword of Handles communications with | ROUTOPTS TCP/IP-connected Tracker | Agents | VTAM CB Network HOPC300 NCFTASK(YES) Transmits/receives Tivoli OPC | communication data through a VTAM link | function (NCF) | WSA WA Workstation JOPC302 OPCHOST(YES) Schedules work for processing | analyzer | Note: The subtask ID is the same identifier used to control the subtask using the MVS MODIFY command.
When a controller is started in standby mode, only the Tivoli OPC mother task (EQQMAJOR) is started. The subtasks that comprise an active controller are attached when a takeover is performed.
Relationship between Tivoli OPC and MVS Tivoli OPC is an MVS subsystem, initialized during IPL. Routines executed during subsystem initialization establish basic Tivoli OPC services, such as an event queue in ECSA. Tivoli OPC uses standard interfaces to SMF and JES to gather relevant information about the workload on the MVS system.
The functions of the Tivoli OPC controller are available when an address space has been created for it, and the required subtasks have been successfully initialized. The controller can execute either as a started task or batch address space. Normally, the address space is started during the IPL process, that is by an MVS start command in COMMNDnn, or by console automation. Alternatively, an MVS operator can issue a START command from the operator console. The MVS operator can also stop or modify the Tivoli OPC address space, using the STOP and MODIFY commands.
A TSO user accesses Tivoli OPC services using the Tivoli OPC dialogs. A Tivoli OPC dialog is a sequence of ISPF panels. Many of the functions supported by the Tivoli OPC dialogs pass service requests from the TSO user's address space to the controller address space for processing.
Before performing any function requested by a Tivoli OPC user, the dialog function passes the request to the system authorization facility (SAF) router. If RACF, or a functionally equivalent security product, is installed and active on the MVS system, the SAF router passes the verification request to RACF to perform this authority check.
A typical request for service from the dialog is a request for access to one or more records in VSAM files that are maintained and controlled by Tivoli OPC. Such a request is passed to Tivoli OPC through the MVS subsystem interface (SSI). This interface invokes a Tivoli OPC routine that resides in common storage. This routine must be invoked in APF-authorized mode. All Tivoli OPC dialogs require
Chapter 1. Overview 7 Overview
ISPF Version 3 Release 4, or later, and TSO/E Version 2 Release 1 to execute successfully.
| Consider that all LTP and CP batch planning jobs have to be excluded from | SMARTBATCH DA (Data Accelerator) processing. When the SMARTBATCH | DATA ACCELERATOR is used with the OPC LTP and CP batch planning jobs, the | normal I/O to EQQCKPT is delayed until END OF JOB (or at least END OF | JOBSTEP). This interferes with the normal exchange of data between the batch | job and the Tivoli OPC controller started task so that when the batch job signals the | controller to check the EQQCKPT to determine whether a new current plan has | been created, the required updates to the CKPT have not yet been made. This | causes the controller to conclude that no NCP has been created, and no turnover | processing is done. As a result, even if the plan jobs run successfully, the NCP is | not taken into production by the controller unless a CURRPLAN(NEW) restart is | performed.
| The OPC Data Store uses the MVS/JES SAPI functions to access sysout data sets, | allowing concurrent access to multiple records from a single address space. This | means that, if you want to install the OPC Data Store, you need an MVS version | from OS/390 V1R3 onwards.
Using the Tivoli OPC Program Directory The Program Directory provided with your Tivoli OPC distribution tape may include technical information that is more recent than the information provided in this guide. In addition, the Program Directory describes the program temporary fix (PTF) level of the Tivoli OPC licensed program that is shipped to you. It is an important document when you install Tivoli OPC.
The Program Directory contains instructions for unloading the Tivoli OPC software and information about additional maintenance for your level of the distribution tape.
Before you start installing Tivoli OPC, check the preventive service planning (PSP) bucket for recommendations added by the service organizations after your Program Directory was produced. The PSP includes a recommended service section that includes high impact or pervasive (HIPER) APARs. Ensure the corresponding PTFs are installed before you start a Tivoli OPC subsystem.
Sample Library Take special note of one of the files included on the distribution tape. SEQQSAMP is a library containing samples of exits, application programs, and the job control language (JCL). You can use the samples for specific installation tasks. Appendix A, “Sample Library (SEQQSAMP)” on page 155 describes the members of the SEQQSAMP library. Familiarize yourself with the contents of the SEQQSAMP library before you begin installation.
8 Tivoli OPC Installation Guide Overview
The Installation Process To understand the flow of the installation, migration, and customization processes, read through this guide before you begin to install Tivoli OPC.
Here is the installation process:
Table 5. These Stages Summarize the Tivoli OPC Installation Process Stage Description For more information ... 1 Plan your Tivoli OPC configuration. You might Chapter 2, “Planning Your Tivoli OPC create a diagram of your own Tivoli OPC Configuration” on page 11 gives examples of configuration—to refer to during the installation common Tivoli OPC configurations. process. 2 Plan your software installation. Chapter 3, “Planning Your Installation of Tivoli OPC” on page 25 describes considerations for installing Tivoli OPC and provides a checklist for the installation tasks. 3 Install the software. Chapter 4, “Installing Tivoli OPC” on page 35 describes the installation tasks in detail. 4 Verify your Tivoli OPC installation. Chapter 5, “Verifying Tivoli OPC Installation” on page 105 describes how you can verify that Tivoli OPC is correctly installed.
If you are currently using OPC/A Release 2 or OPC/ESA Version 1, follow the instructions in “Part 3. Migrating” on page 131.
When you have installed Tivoli OPC, you might want to include more functions. Tivoli OPC Customization and Tuning explains how you can update your Tivoli OPC systems to include extra functions.
Chapter 1. Overview 9
10 Tivoli OPC Installation Guide
Chapter 2. Planning Your Tivoli OPC Configuration
This chapter describes several areas to consider when planning the configuration for your installation. It explains connections between Tivoli OPC systems and provides some examples of basic Tivoli OPC configurations.
Planning Considerations Tivoli OPC must recognize when events occur; for example, when a started task or job begins to execute or terminates, or when a dataset has been printed. Tivoli OPC uses JES and SMF exits to obtain this information from MVS and to create event records describing the changes in the system. The event records are stored in a sequential file called the event dataset identified by the EQQEVDS ddname.
Tivoli OPC also uses the event dataset to write checkpoint information for submission requests. The first record of the dataset is used for this purpose. So the EQQEVDS ddname must be specified for all Tivoli OPC address spaces. The same dataset can be used for both submit checkpointing and the event-writer subtask.
Trackers A tracker must be installed on every MVS system that you want Tivoli OPC to control. The tracker on each Tivoli OPC system writes events to the event dataset. A subtask of the tracker, called the event writer performs this function. For the Tivoli OPC current plan to be updated, the event information must be communicated to, and processed by, the controller. The events are routed to the controller through the connection linking the tracker and the controller, either by an event reader subtask, or by requesting the event writer to queue the events immediately to the data router subtask, when the connected type is not shared DASD.
Initialization Statements Tivoli OPC initialization statements specified in the Tivoli OPC parameter library describe, among other things, the configuration of your installation. In a shared DASD environment, an event reader subtask started at the controller reads the events from the event dataset. The events are then used to update the current plan. A sequence number, specified on the ERSEQNO of the ERDROPTS initialization statement, identifies each event reader subtask. This number is used to build a ddname in the JCL procedure of the address space where the event reader is started. This ddname identifies the event dataset that the event reader should process. The ddname has the format EQQEVDnn, where nn is the sequence number of the event reader that services this event dataset.
When a tracker has a non-DASD connection with the controller (that is, an XCF or NCF connection) or the tracker and controller are executing in the same address space, the event writer can be used to forward events directly to the controller. When an event writer is started with the EWSEQNO keyword on the EWTROPTS initialization statement, the event writer logs event information on the event dataset and adds the event concurrently to the data router queue. The event is not read back from the event dataset each time as it is by an event reader subtask. In this configuration, events are only read back from DASD if they need to be resent to the
Copyright IBM Corp. 1991, 1999 11 Planning the Configuration
controller during restart processing, for example when the communication link to the controller becomes active after an outage.
Refer to Tivoli OPC Customization and Tuning for more information on the ERDROPTS and EWTROPTS initialization statements. Also see page 76, which provides important information about allocating event datasets.
Communication The data router subtask is responsible for communicating the event to the controller event manager subtask, either by XCF, NCF, or by adding directly to the queue when the tracker and controller are started in the same address space. This eliminates the need for a separate event-reader function, saves time, and saves I/O operations. The EWSEQNO value is not used to build a ddname, as happens with the event reader subtask. The event writer uses the EQQEVDS ddname to identify the event dataset.
If a connection is lost between a tracker and the controller, the event writer continues to record events. When the connection is restored, the event dataset is processed from the last event received by the controller before the outage.
Note that controllers scheduling work (for a given MVS image) must have unique subsystem names.
Ways to Connect Tivoli OPC Systems Tivoli OPC systems can be connected through any of these methods: Shared DASD XCF communication links VTAM link
The Tivoli OPC controller uses any of these methods to transmit work to a tracker system. The tracker system uses the same connection to transmit events back to the controller.
OPC Tracker Agents in operating environments other than MVS communicate with the controller using APPC or TCP/IP services.
Shared DASD When two Tivoli OPC systems are connected through shared DASD, they share two datasets for communication: Event dataset Submit/release dataset
The tracker writes the event information it collects to the event dataset. An event reader, started in the controller, reads the dataset and adds the events to the data router queue.
12 Tivoli OPC Installation Guide Planning the Configuration
A submit/release dataset is one method that the controller uses to pass work to a controlled system. When two Tivoli OPC systems share a submit/release dataset, the dataset can contain these records: Release commands Job JCL Started-task JCL procedures Dataset cleanup requests WTO message text Both the host and the controlled system must have access to the submit/release dataset. The EQQSUDS ddname identifies the submit/release dataset in the tracker address space. At the controller, the ddname is user-defined, but it must be the same name as that specified in the DASD keyword of the ROUTOPTS statement. The controller can write to any number of submit/release datasets.
MVS Cross-System Coupling Facility Tivoli OPC uses the MVS cross-system coupling facility (XCF), introduced in MVS/ESA SP Version 4, to connect Tivoli OPC systems using XCF communication links.
When one or more trackers are connected to the controller via XCF communication links, the Tivoli OPC systems form an XCF group. The systems use XCF group, monitoring, and signaling services to communicate. The controller submits work and control information to the trackers using XCF signaling services. The trackers use XCF services to transmit events back to the controller.
XCF connections let Tivoli OPC support a hot standby controller and automatic-workload-restart functions.
VTAM (Network Communication Function) Tivoli OPC uses the network communication function (NCF) to connect a tracker to the controller using a VTAM link. The controller transmits work to the tracker via NCF, and the same connection is used to pass back event information.
Workstation Destination The various physical and logical locations where tasks are performed at your installation are represented in Tivoli OPC by workstations. Each workstation groups related activities. Every operation in the application description database and the current plan is associated with a workstation. You define workstations in the workstation description database.
The destination field is one attribute of a workstation description. It identifies the system in your Tivoli OPC configuration that operations scheduled for this workstation should be submitted to. The field can contain either the ddname of a submit/release dataset, an XCF member name, the VTAM LU of a tracker, or a user-defined destination.
If the destination field is not blank, the same name must also be present in the APPC, DASD, SNA, TCP, USER, or XCF keywords of the ROUTOPTS statement, depending on the connection method. If the destination represents an OPC/A Release 2 system, specify the OPCAV1R2 keyword on the ROUTOPTS statement.
Chapter 2. Planning Your Tivoli OPC Configuration 13 Planning the Configuration
The destination field can also remain blank. A blank destination field means that operations at this workstation will be submitted by the controller.
User-defined destinations represent operating environments that do not support an OPC Tracker Agent. The operation-initiation exit, EQQUX009, handles routing of the workload to user-defined destinations.
Workload Restart You can use workload restart (WLR) to restart and reroute work in your Tivoli OPC configuration. WLR tracks the status of workstations. It can be invoked when a workstation becomes inactive; that is, when the controller cannot communicate with the tracker at the destination that the workstation represents. If an operation is restartable, it can be started again by Tivoli OPC after a workstation failure. If an operation is reroutable, it can be moved to an alternative workstation for execution when its workstation is no longer active.
For WLR purposes, the status of a workstation can be either active or inactive. An inactive workstation has a status of offline, failed, or unknown. The actions that WLR performs depend on the new status of the workstation and on the values you specify on the WSFAILURE and WSOFFLINE keywords of the JTOPTS initialization statement. The inactive status that a workstation can have depends on the type of connection between the tracker and the controller. The connection type and the new workstation status determine whether workload restart actions can be invoked automatically. You can use the full capabilities of WLR on systems that are connected by XCF. Note: JES also has restart functions, which can be used when the system is restarted after a failure. JES can restart jobs that were active when the failure occurred. To prevent jobs from being started twice, ensure that both JES and WLR do not perform restart actions for jobs on the failing system.
JES Considerations The JES type and configuration in your installation has implications on your Tivoli OPC configuration. Consider these situations: 1. On system where JES2 5.1.0 or later is installed, a Tivoli OPC Tracker must be installed on each system in the JES2 Multi-Access Spool (MAS) complex. If all systems in the complex have JES2 prior to 5.1.0 installed, and if you do not install Tivoli OPC on all systems, you must, for the workload that is to be tracked by Tivoli OPC, ensure that: Jobs are submitted, whether by Tivoli OPC or outside Tivoli OPC, to a system where a tracker is installed. JES input and output services for a job are performed on a system where a tracker is active. Use JES2 system affinity, either explicitly in JCL through the /*JOBPARM statement, or issue the command $T,INTRDR,S=(sys1,sys2,...) on systems where JES2 4.2 is installed. Use the $T,RDI,S=(sys1,sys2,...) command on systems prior to JES2 4.2. If you use the NOTIFY parameter on a JOB card, ensure the specified user does not log on to a system where a tracker is not installed. The notify message is sent to the system where the user is logged on. It can cause all output from a job to be sent to the same system. If Tivoli OPC is not
14 Tivoli OPC Installation Guide Planning the Configuration
installed on this system, output will not be tracked, and JCC (job completion checker) processing will be impossible. JES2 system affinity (SYSAFF) controls where a job will convert, run, and go through output processing; it does not affect input or purge processing. So a conflict can occur between SYSAFF and NOTIFY for output processing because NOTIFY forces an affinity (for output only) to the MAS system where the user is defined. If this system is not the same as for SYSAFF, the job will hang in AWAITING OUTPUT until the affinity matches NOTIFY or until the job is canceled. If you track print operations, that output is printed only on those systems where a tracker is installed. When PRTCOMPLETE(YES) is specified on the JTOPTS initialization statement of the controller, you do not purge jobs on a system where a tracker is not installed. Otherwise, print operations for the jobs remain in ready status. 2. If you do not install Tivoli OPC on all systems in a JES3 complex, ensure that: A tracker is installed on the global. Jobs are submitted, whether by Tivoli OPC or outside Tivoli OPC, to a system where a tracker is installed. Use the //*MAIN SYSTEM=sysid statement in the JCL, or start job classes used by these jobs only on those systems where a tracker is installed. If you track print operations, output is printed only on those systems where a tracker is installed.
Tivoli OPC Basic Configuration Examples This section gives examples of Tivoli OPC configurations using the various connection methods. The examples are based on a single-image MVS environment. Appendix B, “Tivoli OPC Configuration Examples” on page 167 contains examples of more complex configurations.
The examples in this section show: All Tivoli OPC address spaces as Version 2 subsystems. Sample initialization statements that you can use to create the configuration. Only initialization statements that specifically relate to the configuration are included. The Tivoli OPC components that are required, the flow of automatic work submission, and event collection in various system combinations.
Chapter 2. Planning Your Tivoli OPC Configuration 15 Planning the Configuration
DASD Connected Figure 1 shows two Tivoli OPC address spaces with a DASD connection on an MVS system running MVS/SP Version 3 or later.
You represent this system to Tivoli OPC by defining a computer workstation with a destination field that specifies a submit/release ddname. The controller writes JCL, release commands, WTO messages, and catalog-management requests into the submit-release dataset. The tracker reads the submit-release dataset and: Submits JCL for batch jobs to the JES internal reader Writes the JCL for started tasks into the EQQSTC dataset and issues START procname MVS commands Issues JES release commands for jobs in HOLD status Performs catalog-management actions.
The event-tracking routines create event records to describe activities that occur on the system. These records are added to the tracker event writer queue in ECSA. The tracker processes the queue and writes the events into the event dataset. An event-reader subtask started in the controller address space reads the event dataset, and the current plan is updated.
Figure 1. An MVS System Connected via Shared DASD
You can also configure this system without a submit-release dataset. When the workstations destination is blank; batch jobs, started tasks, release commands, and WTO messages, are processed by the submit subtask automatically started in the controller address space. The event-tracking process remains unchanged. Note that catalog-management actions cannot be performed in this configuration.
You must include a submit-release dataset if you will use catalog management. You can continue to start operations from the controller address space; that is, the workstation destination remains blank, but the ROUTOPTS keywords DESTID and SYSID must be defined to identify the system name and submit-release ddname.
Table 6 shows the initialization statements you can use to create the configuration in Figure 1.
16 Tivoli OPC Installation Guide Planning the Configuration
Table 6. Example EQQPARM Members for Figure 1
Members for the controller Members for the tracker
OPCECNT TRKA OPCOPTS OPCHOST(YES) OPCOPTS OPCHOST(NO) ERDRTASK(1) ERDRTASK(ð) ERDRPARM(STDERDR) EWTRTASK(YES) ROUTOPTS DASD(EQQSYSA) EWTRPARM(STDEWTR) TRROPTS HOSTCON(DASD)
STDERDR STDEWTR ERDROPTS ERSEQNO(ð1) EWTROPTS SUREL(YES)
Note: In this example, EQQSYSA is used for the user-defined ddname of the submit/release dataset. This ddname appears in the JCL procedure of the controller and in the destination field of the workstation.
VTAM Connected Figure 2 on page 18 shows two Tivoli OPC address spaces with a VTAM connection on an MVS system running MVS/SP Version 3 or later.
You represent this system to Tivoli OPC by defining a computer workstation with a destination field that specifies the LU name of the tracker. The controller transmits JCL, release commands, WTO messages, and catalog-management requests across the LU-LU link using the NCF component. The tracker receives data across the VTAM link and: Submits JCL for batch jobs to the JES internal reader Writes the JCL for started tasks into the EQQSTC dataset and issues START procname MVS commands Issues JES release commands for jobs in HOLD status Performs catalog-management actions.
The event-tracking routines create event records to describe activities that occur on the system. These records are added to the tracker event writer queue in ECSA. The tracker processes the queue, transmits the records to the controller across the VTAM link, and writes the events into the event dataset. The VTAM subtask in the controller receives the event records, and the current plan is updated. Note: You must specify EQQEVDS for a controller, even if an event writer is not started in the controller address space. The EQQEVDS dataset is used for submit checkpointing. It can be the same dataset that is used by an event-writer function. Use a unique EQQEVDS for each OPC/ESA address space.
Chapter 2. Planning Your Tivoli OPC Configuration 17 Planning the Configuration
Figure 2. An MVS System with a VTAM Connection
Table 7 shows the initialization statements you can use to create the configuration in Figure 2.
Table 7. Example EQQPARM Members for Figure 2
Members for the controller Members for the tracker
OPCECNT TRKA OPCOPTS OPCHOST(YES) OPCOPTS OPCHOST(NO) ERDRTASK(ð) ERDRTASK(ð) NCFTASK(YES) EWTRTASK(YES) NCFAPPL(CNTSYS) EWTRPARM(STDEWTR) ROUTOPTS SNA(TRKSYS) NCFTASK(YES) NCFAPPL(TRKSYS) TRROPTS HOSTCON(SNA) SNAHOST(CNTSYS)
STDEWTR EWTROPTS EWSEQNO(ð1)
Note: In this example, the LU name of the controller is CNTSYS and the tracker uses TRKSYS. The tracker LU is defined in the destination field of the workstation.
XCF Connected Figure 3 on page 19 shows two Tivoli OPC address spaces with an XCF connection in an MVS monoplex running MVS Version 4 Release 2 or later.
You represent this system to Tivoli OPC by defining a computer workstation with a destination field that specifies the XCF member name of the tracker. The controller uses XCF services to transport JCL, release commands, WTO messages, and catalog-management requests to members in the sysplex. The tracker receives data from XCF and:
18 Tivoli OPC Installation Guide Planning the Configuration
Submits JCL for batch jobs to the JES internal reader Writes the JCL for started tasks into the EQQSTC dataset and issues START procname MVS commands Issues JES release commands for jobs in HOLD status Performs catalog-management actions.
The event-tracking routines create event records to describe activities that occur on the system. These records are added to the tracker event writer queue in ECSA. The tracker processes the queue, transports the records to the controller across the XCF link, and writes the events into the event dataset. The data router subtask in the controller receives the event records from XCF, and the current plan is updated.
Figure 3. An MVS System with an XCF Connection
Table 8 on page 20 shows the initialization statements you can use to create the configuration in Figure 3.
Chapter 2. Planning Your Tivoli OPC Configuration 19 Planning the Configuration
Table 8. Example EQQPARM Members for Figure 3
Members for the controller Members for the tracker
OPCECNT TRKA OPCOPTS OPCHOST(YES) OPCOPTS OPCHOST(NO) ERDRTASK(ð) ERDRTASK(ð) ROUTOPTS XCF(OPCTRK) EWTRTASK(YES) XCFOPTS MEMBER(OPCCNT) EWTRPARM(STDEWTR) GROUP(PLEXSYSA) TRROPTS XCF(OPCCNT) XCFOPTS MEMBER(OPCTRK) GROUP(PLEXSYSA)
STDEWTR EWTROPTS EWSEQNO(ð1)
Note: In this example, the name of the monoplex is PLEXSYSA. The members in that group are: OPCCNT—the controller OPCTRK—the tracker. The tracker member name is defined in the destination field of the workstation.
Tracker and Controller in a Single Address Space Figure 4 on page 21 shows one Tivoli OPC address space performing the function of both the tracker and the controller. For availability reasons, we recommend you do not use this configuration in your production environment. However, at least one of your Tivoli OPC test environments will probably use this configuration.
You represent this system to Tivoli OPC by defining a computer workstation with a blank destination field. The submit subtask: Submits JCL for batch jobs to the JES internal reader Writes the JCL for started tasks into the EQQSTC dataset and issues START procname MVS commands Issues JES release commands for jobs in HOLD status The data router subtask posts the catalog-management subtask directly with catalog-management actions. The event-tracking routines create event records to describe activities that occur on the system. These records are added to the subsystem event writer queue in ECSA. The event writer subtask processes the events and: Adds the event to the data router queue, and the current plan is updated Writes the events into the event dataset.
20 Tivoli OPC Installation Guide Planning the Configuration
Figure 4. A Tracker and Controller Configured in a Single Address Space
Table 9 shows initialization statements to create the configuration in Figure 4.
Table 9. Example EQQPARM Members for Figure 4 EQQPARM members for the address space
OPCECNT STDEWTR OPCOPTS OPCHOST(YES) EWTROPTS EWSEQNO(ð1) ERDRTASK(ð) EWTRTASK(YES) EWTRPARM(STDEWTR)
Appendix B, “Tivoli OPC Configuration Examples” on page 167 contains Tivoli OPC configuration examples for more complex environments.
| Tivoli OPC Data Store Basic Configuration Examples
| SNA Connected | Figure 5 on page 22 shows a Controller with a Tracker in the same address space | and Tracker connected via SNA. The JES is a JES2 MAS (shared spool). In this | situation only one Data Store is needed. The Controller will ask the Job Log to the | Data Store by means of the FL subtask. The FL subtask attaches the FN subtask | to communicate with Data Store.
Chapter 2. Planning Your Tivoli OPC Configuration 21 Planning the Configuration
Controller/Tracker Tracker NCF NCF
FL FN Data Store
| Figure 5. Controller and Tracker in Same Address Space with Tracker Connected via SNA
| Key: | FL Fetch Job Log Task | FN Data Store Communication Task | NCF | Network Communication function
| Table 10 shows the initialization statements you can use to create the configuration | in Figure 5.
| Table 10. Example Members for Figure 5 | Controller members Tracker members Data Store members | OPCECNT TRKA DSTA | OPCOPTS FLTASK(YES) OPCOPTS JCCTASK(DST) DSTOPTS HOSTCON(SNA) | JCCTASK(DST) CATMGT(YES) SYSCLASS(Z) | CATMGT(YES) DSTLUNAM(LUðððDSA) | CTLLUNAM(LUðððDSC)
| FLOPTS | CTLLUNAM(LUðððDSC) | SNADEST(ᑍᑍᑍᑍᑍᑍᑍᑍ.LUðððDSA, | LUððTRTA.LUðððDSA)
| JOBOPTS JOBOPTS | JOBLOGRETRIEVAL(DELAYEDDST) JOBLOGRETRIEVAL(DELAYEDDST) | DSTCLASS(Z) DSTCLASS(Z)
|
| Note: In this example the LU name of Controller in the Tracker communication is | LU000TRC and the Tracker uses LU00TRTA. While the LU name of the Controller | in Data Store Communication is LU000DSC and the Data Store uses LU000DSA. | The Data Store reserved class is Z.
22 Tivoli OPC Installation Guide Planning the Configuration
| XCF Connected | Figure 6 shows a Controller with a Tracker in the same address space and Tracker | connected via SNA. The JES is a JES2 MAS (shared spool). In this situation only | one Data Store is needed. The Controller will ask the Job Log to the Data Store by | means of FL subtask. FL subtask attaches the FN subtask to communicate with | Data Store.
Controller Tracker CTC XCF XCF
CTC FL Data Store
| Figure 6. Controller, Tracker, and Data Store Connected via XCF
| Table 11. Example Members for Figure 6 | Controller members Tracker members Data Store members | OPCECNT TRKA DSTA | OPCOPTS FLTASK(YES) OPCOPTS JCCTASK(DST) DSTOPTS HOSTCON(XCF) | JCCTASK(NO) CATMGT(YES) SYSCLASS(Z) | DSTGROUP(OPCXCFD2) | DSTMEM(XCFA1) | CTLMEM(XCFC2)
| FLOPTS | CTLMEM(XCFC2) | DSTGROUP(OPCXCFD2) | XCFDEST(XCFT1.XCFA1)
| JOBOPTS | JOBLOGRETRIEVAL(DELAYEDDST) | DSTCLASS(Z)
| XCFOPTS XCFOPTS | GROUP(OPCXCFD1) GROUP(OPCXCFD1) | MEMBER (XCFC1) MEMBER (XCFT1)
| ROUTOPTS TRROPTS | XCF(XCFT1) HOSTCON(XCF)
|
| Note: In this example the Controller and Tracker communication is realized by the | XCF group OPCXCFD1, with Controller member name XCFC1 and Tracker | member name XCFT1. The Controller and Data Store XCF communication is
Chapter 2. Planning Your Tivoli OPC Configuration 23
| realized by the XCF group OPCXCFD2, with Controller member name XCFC2 and | Data Store member name XCFA1. The Data Store reserved class is Z.
24 Tivoli OPC Installation Guide
Chapter 3. Planning Your Installation of Tivoli OPC
This chapter presents considerations for installing Tivoli OPC and provides a checklist that you can use as you work through the installation process. Chapter 4, “Installing Tivoli OPC” on page 35 describes the installation tasks in detail.
Installation Considerations During the planning stage of your Tivoli OPC project, consider carefully how you want to install Tivoli OPC to control your production workload. The installation of Tivoli OPC consists of installing the tracker and controller in combinations to suit your processing environment, and connecting them using one or more of the communication methods described in Chapter 2, “Planning Your Tivoli OPC Configuration” on page 11. Later, you can customize your Tivoli OPC systems to include more functions.
Before you start the installations tasks, ensure that you have all the resources you need to complete your installation.
Configuring for Availability It is recommended that you install the tracker and controller as separate subsystems on a Tivoli OPC controlling system. The tracker can then continue to collect events if the controller is stopped. Events are created by SMF and JES exits, and added to a queue in MVS extended common service area (ECSA). If the event writer is not active while work is executing in the system, the queue might fill up, and new events might be lost. Tivoli OPC cannot recover these lost events.
| You can improve Tivoli OPC availability using the OS/390 Automatic Restart | Manager (ARM). Automatic restart management can reduce the impact of an | unexpected error to Tivoli OPC because OS/390 can restart it automatically, without | operator intervention.
Hot Standby If you connect your Tivoli OPC systems using the MVS cross-system coupling facility (XCF), you can include one or more standby controllers in your configuration. A standby system can take over the functions of the controller if the controller fails or if the MVS system that it was active on fails. You can create a standby controller on one or more Tivoli OPC controlled systems within the XCF group. Each standby system must have access to the same resources as the controller. These include datasets and VTAM cross-domain resources. The standby system is started the same way as the other Tivoli OPC address spaces, but is not activated unless a failure occurs or unless it is directed to take over via an MVS operator modify command.
Starting an Event Writer with an Event Reader Function In situations where a tracker does not have a DASD connection with the controller, use an event writer that is started with an event-reader function. This can improve performance because events are not written to the event dataset and then read back again, which requires an event-reader task to continually check the event
Copyright IBM Corp. 1991, 1999 25 Planning the Installation
dataset for new events. Instead, the event writer writes events to the event dataset and forwards them directly to the controller via an XCF or NCF link.
Checklist for Installing Tivoli OPC You can use the following checklist to guide you through the installation tasks for a tracker, a controller, a standby controller, or the ISPF dialogs. Note: Always install the tracker first on the controlling system or on a system where a standby controller will be installed.
In the checklist, the task numbers are arranged in a recommended order but are not meant to imply a required order. You perform the tasks suited to your own configuration.
The Applies to column indicates for which Tivoli OPC address space you should perform that particular task. You might not need to perform every task outlined in the list. Skip those tasks or actions that do not apply to your installation.
A check mark (√) in the IPL column means that an IPL of the MVS system is needed for the change to take effect. It does not indicate how many IPLs are needed. You can install Tivoli OPC with only one IPL of the MVS system by performing all the required steps before a scheduled IPL.
The Page column indicates the page in this guide where the task is described.
Table 12 (Page 1 of 6). Checklist for Installing Tivoli OPC Task Description Applies to IPL Page 1 Load tracker software. Tracker 36 Perform these actions on each system in your Tivoli OPC configuration: Run SMP/E to receive tracker software. Apply tracker maintenance. 2 Load controller software. Controller 36 Perform these actions on each system where you are installing a Standby controller, standby controller, or dialogs: controller Run SMP/E to receive controller software. Apply controller maintenance. Dialogs 3 Load national language support (NLS) software for the controller. Controller 37 Perform these actions on each system where you are installing a Standby controller standby controller, or dialogs: controller Run SMP/E to receive NLS software. Apply NLS maintenance. Dialogs 4 Load Workload Monitor/2 software to MVS. Controller 37 Perform these actions if you will use the Workload Monitor/2: Standby Run SMP/E to receive Workload Monitor/2 software. controller Apply Workload Monitor/2 maintenance. Refer to Tivoli OPC Workload Monitor/2 User's Guide for information about Workload Monitor/2 installation on a personal computer.
26 Tivoli OPC Installation Guide Planning the Installation
Table 12 (Page 2 of 6). Checklist for Installing Tivoli OPC Task Description Applies to IPL Page 5 Load Workload Monitor/2 NLS software to MVS. Controller 38 Perform these actions on each MVS system where you load Workload Standby Monitor/2 software: controller Run SMP/E to receive NLS software. Apply NLS maintenance. Refer to Tivoli OPC Workload Monitor/2 User's Guide for information about Workload Monitor/2 installation on a personal computer. | 6 Execute the EQQJOBS installation aid. Tracker 38 You can execute EQQJOBS as soon as the tracker software is Controller loaded. It helps you install Tivoli OPC: Set up EQQJOBS. Standby Create the sample job JCL. controller Do this to generate tailored samples via the EQQJOBS dialog. Dialogs Generate Tivoli OPC batch job skeletons. Use EQQJOBS to generate skeletons for the ISPF dialogs. | Generate the Data Store samples if you want to install the OPC | Data Store (optional) 7 Add SMF and JES event tracking exits. Tracker √ 49 Perform this task on every MVS system in your Tivoli OPC configuration. Note: If you place exits in a link-pack-area (LPA) library, you must perform an IPL of the MVS system with the CLPA option.
Chapter 3. Planning Your Installation of Tivoli OPC 27 Planning the Installation
Table 12 (Page 3 of 6). Checklist for Installing Tivoli OPC Task Description Applies to IPL Page 8 Update SYS1.PARMLIB. Tracker √ 51 On each system where you are installing Tivoli OPC, perform the Controller actions that are applicable to your installation: Define Tivoli OPC subsystems (IEFSSNnn). Standby This is required for each system where Tivoli OPC is installed. controller Authorize the Tivoli OPC load module library (IEAAPFnn). Do this if you install Tivoli OPC in a separate load module library. Dialogs Update SMF parameters (SMFPRMnn). Do this when installing a tracker. Update dump-content definitions. Consider this on each system where you are installing Tivoli OPC. Update the MVS link-library definition (LNKLSTnn). Consider this on each system where you are installing Tivoli OPC. Update XCF initialization options (COUPLEnn). Review this section if you use XCF connections. Modify TSO parameters (IKJTSOnn). Do this when installing a controller, a standby controller, or the ISPF dialogs. Update PPT for performance (SCHEDnn). Consider this on each system where you are installing Tivoli OPC. Define the DLF exit for Hiperbatch support (COFDLFnn). Do this if you use Hiperbatch support. Consider starting Tivoli OPC automatically (COMMNDnn). Consider this on each system where you are installing Tivoli OPC. Update APPC/MVS options (APPCPMnn). Consider this action if you intend to use the Tivoli OPC API, or Tivoli OPC server. Define VTAM resources before you update SYS1.PARMLIB. Coordinate this action with task 18 or 19. 9 Set up the RACF environment. Tracker √ 60 Perform these actions on each system in your Tivoli OPC Controller configuration: Update RACF for Tivoli OPC started tasks (ICHRIN03). Standby Do this for all Tivoli OPC started tasks on each system. controller Update RACF for a controller. Do this for a controller or standby controller. Use functions of RACF 1.9 or later. Consider this action if you use RACF 1.9 or later. At this point, you can IPL to activate all Tivoli OPC options requiring an IPL of the MVS system.
28 Tivoli OPC Installation Guide Planning the Installation
Table 12 (Page 4 of 6). Checklist for Installing Tivoli OPC Task Description Applies to IPL Page 10 Allocate datasets. Tracker 67 Perform these actions if you are installing a tracker or a controller: Controller Review the section on allocating Tivoli OPC datasets. Do this before you allocate datasets. Allocate VSAM datasets for a controller. Perform this action to create new datasets for a controller. Allocate non-VSAM datasets. Perform this action for each Tivoli OPC address space. | Allocate the VSAM Data Store data sets if you want to install the | OPC Data Store (optional) 11 Update SYS1.PROCLIB. Tracker 82 Perform these actions for each Tivoli OPC address space. Controller Create a JCL procedure for each Tivoli OPC address space. Do this on all MVS systems where you are installing Tivoli OPC. Standby If you will use Tivoli OPC to schedule started-task operations, controller ensure that the started-task-submit dataset (EQQSTC) is in the JES PROCLIB concatenation. 12 Define initialization statements. Tracker 86 Perform this task for each Tivoli OPC address space: Controller Define initialization statements. Create members in the parameter library (EQQPARM) for each Standby Tivoli OPC address space. controller 13 Create a DB2 database. Controller 87 Perform this task if you need history support: Standby Update initialization statements. controller Create a DB2 database. If you are not using NCF or XCF connections you can now start a tracker and continue with the verification task. 14 Set up the ISPF environment. Dialogs 87 Perform these actions on the system where you are installing the ISPF dialogs. Set up the Tivoli OPC CLIST library. Set up the ISPF tables. Allocate ISPF and Tivoli OPC datasets to your TSO session. Invoke the Tivoli OPC dialog. If you are not using NCF or XCF connections, the Tivoli OPC API, or the Tivoli OPC server, you can now start a controller and continue with the verification task.
Chapter 3. Planning Your Installation of Tivoli OPC 29 Planning the Installation
Table 12 (Page 5 of 6). Checklist for Installing Tivoli OPC Task Description Applies to IPL Page 15 Using XCF for local communications. Tracker 91 You might have already specified XCF initialization statements in Task Controller 12 and updated the COUPLEnn member in Task 7. But still consider these actions if you use XCF: Standby Update XCF initialization options. controller Ensure that XCF initialization options are suitable for your Tivoli OPC configuration. Add initialization statement options for XCF. Specify XCF run-time options in the parameter library for all Tivoli OPC started tasks. 16 Activate NCF for VTAM connections. Tracker 93 Perform these actions for each Tivoli OPC address space that is Controller connected via NCF. Ensure that a standby controller has the same tracker connections as the controller and that each tracker can Standby connect to all standby controllers: controller Add NCF network definitions. Define VTAM applications on each system where a Tivoli OPC started task uses NCF. Add NCF session parameters. Do this on each MVS system where Tivoli OPC is installed. Update the COS table. Consider this action if you will not use the VTAM COS default entry. Activate network resources. Check that all the required VTAM resources are active. Add NCF initialization options. Include initialization statement options in the parameter library for all Tivoli OPC started tasks that use NCF. 17 Activate support for the Tivoli OPC API. Tracker 96 Note: You must activate API support for the controller before you can Controller use the Tivoli OPC Workload Monitor/2. To use the API, perform these actions for each Tivoli OPC address Standby space that you want to send requests to: controller Define VTAM resources. Define a local LU for Tivoli OPC, logon modes, and cross-domain resources, as required. Update APPC/MVS options. Update the APPCPMnn member of SYS1.PARMLIB. Activate Tivoli OPC support for APPC/MVS. In the Tivoli OPC parameter library, include APPCTASK(YES) on the OPCOPTS statement.
30 Tivoli OPC Installation Guide Planning the Installation
Table 12 (Page 6 of 6). Checklist for Installing Tivoli OPC Task Description Applies to IPL Page | 18 Activate support for the Tivoli OPC APPC/MVS Server. Server 100 Note: Include this task when activating a Tivoli OPC Server. Controller To activate the Server, perform these actions in the order shown: Define VTAM resources. Standby Define a local LU for Tivoli OPC, logon modes, and cross-domain controller resources, as required. Update APPC/MVS options. Update the APPCPMnn member of SYS1.PARMLIB. Activate Tivoli OPC support for APPC/MVS. In the Tivoli OPC parameter library, include SERVERS on the OPCOPTS statement. | 19 Activate Support for the Tivoli Job Scheduling Console Server 104 | Note: Include this task when activating a Tivoli OPC TCP/IP Server | Controller | and you intend to use the Tivoli Job Scheduling Console. | To activate the Server, perform these actions: Standby | Install the Connector controller | In the Tivoli OPC parameter library, include SERVERS on the | OPCOPTS statement. | Refer to Tivoli Job Scheduling Console Guide for OPC Users for | information about installing the Java GUI on a personal computer. 20 Verify your installation of Tivoli OPC Tracker 105 Perform initial verification for the Tivoli OPC address space that you Controller are installing: Verify tracker installation. Standby Verify controller installation. controller Verify standby controller installation. When a current plan has been created, perform verification of your Tivoli OPC configuration.
Chapter 3. Planning Your Installation of Tivoli OPC 31
32 Tivoli OPC Installation Guide
Part 2. Installing Tivoli OPC
Copyright IBM Corp. 1991, 1999 33
34 Tivoli OPC Installation Guide
Chapter 4. Installing Tivoli OPC
This chapter describes the tasks you perform to install Tivoli OPC. Before you begin these tasks, you must determine the Tivoli OPC configuration you want to create and the functions you want to use. Table 13 summarizes the installation tasks and identifies the Tivoli OPC address space type for each task. Depending on your configuration, you might not need to perform every task indicated in the table. Skip those sections that are not relevant to your installation.
Table 13. Tivoli OPC Installation Tasks
Perform for Standby Installation task Tracker Controller controller Dialogs Page Loading Tracker Software √ √ √ √ 36 Loading Controller Software √ √ √ 36 Loading National Language Support Software for the √ √ √ 37 Controller Loading Workload Monitor/2 Software to MVS √ √ 37 Loading Workload Monitor/2 NLS Software to MVS √ √ 38 | Using the EQQJOBS Installation Aid √ √ 38 Adding SMF and JES Exits for Event Tracking √ 49 Updating SYS1.PARMLIB √ √ √ √ 51 Setting Up the Tivoli OPC RACF Environment √ √ √ 60 Allocating Tivoli OPC Data Sets 67 Allocating the VSAM Data Sets √ 68 Allocating Tivoli OPC Non-VSAM Data Sets √ √ 72 Creating JCL Procedures for Tivoli OPC Address √ √ √ 82 Spaces Defining the Initialization Statements √ √ √ 86 Creating the DB2 Database √ √ 87 Setting Up the ISPF Environment √ 87 Using XCF for Communication √ √ √ 91 Activating the Network Communication Function √ √ √ 93 Activating Support for the Tivoli OPC API √ √ 96 Activating Support for the Tivoli OPC APPC/MVS √ √ 100 Server | Activating Support for the Tivoli Job Scheduling √ √ 104 | Console Verifying Tivoli OPC installation 105 Verifying Installation of a Tracker √ 105 Verifying Installation of a Controller and Dialogs √ 111 Verifying Installation of a Standby Controller √ 115 Verifying Tivoli OPC Configuration √ √ √ 118
Copyright IBM Corp. 1991, 1999 35 Installing Tivoli OPC
Loading Tracker Software Perform this task for a tracker.
You must load tracker software on each MVS system in your Tivoli OPC configuration. Process the software distribution tape using the facilities of System Modification Program Extended (SMP/E) Release 7 with the PTF UR40251 applied, or later. This creates or updates the necessary software libraries on your system. Table 14 describes the distribution and target libraries that are created or updated by SMP/E.
Table 14. Tracker Libraries Loaded by SMP/E SMP/E ddname Distribution Target Description AEQQPNL0 SEQQPNL0 Panels for the EQQJOBS installation aid AEQQMOD0 SEQQLMD0 Tracker modules (object) (load) AEQQMSG0 SEQQMSG0 Messages AEQQMAC0 SEQQMAC0 Assembler macros AEQQCLIB SEQQCLIB Tivoli OPC CLISTs AEQQSAMP SEQQSAMP Sample exits, programs, and JCL AEQQSKL0 SEQQSKL0 JCL skeletons, input to EQQJOBS AEQQTBL0 SEQQTBL0 ISPF tables AEQQDATA SEQQDATA Sample Tivoli OPC databases AEQQMISC SEQQMISC DBRM files
It is recommended that you place all the Tivoli OPC load modules in a separate library. Use the same library for both the tracker and the controller. Create the library before you run the SMP/E jobs.
Alternatively, you can place the Tivoli OPC load modules in one of your existing load-module libraries, for example SYS1.LINKLIB. The remaining datasets loaded by SMP/E are new datasets that you must create before running the SMP/E jobs. The Program Directory contains the JCL and instructions for loading the software.
When you have loaded the tracker software, apply any recommended maintenance described in the PSP.
Loading Controller Software Perform this task for a controller, a standby controller, or the dialogs.
To load controller software, process the software distribution tape using SMP/E. This creates or updates the necessary disk-resident libraries on your system. Table 15 on page 37 describes the dataset that is created or updated by SMP/E.
36 Tivoli OPC Installation Guide Installing Tivoli OPC
Table 15. Controller Libraries Loaded by SMP/E SMP/E ddname Distribution Target Description AEQQMOD0 SEQQLMD0 Controller modules (object) (load) AEQQMISC SEQQMISC Batch command interface tool modules and OPC Control Language tool modules
It is recommended that you install the controller in the same library that you are using for the tracker.
When you have loaded the controller software, apply any recommended maintenance described in the PSP.
Loading National Language Support Software for the Controller Perform this task for a controller, a standby controller, or the dialogs.
To load national language support (NLS) software for the controller, process the software distribution tape using SMP/E. This creates or updates the necessary disk-resident libraries on your system. Table 16 describes the datasets that are created or updated by SMP/E.
Table 16. NLS Libraries Loaded by SMP/E for the Controller SMP/E ddname Distribution Target Description AEQQPxxx SEQQPxxx Panels AEQQMxxx SEQQMxxx Messages Note: The suffix xxx is the NLS identifier. It is recommended that you place NLS software in the same library that you are using for the tracker and controller.
When you have loaded the national language support software, apply any recommended maintenance described in the PSP.
Loading Workload Monitor/2 Software to MVS Perform this task if you intend to use the Workload Monitor/2.
To load the Workload Monitor/2 software to MVS, process the software distribution tape using SMP/E. This creates or updates the necessary disk-resident libraries on your system. Table 17 on page 38 describes the datasets that are created or updated by SMP/E.
Refer to Tivoli OPC Workload Monitor/2 User's Guide for information about how to install the Workload Monitor/2 on your personal workstation.
Chapter 4. Installing Tivoli OPC 37 Installing Tivoli OPC
Table 17. Workload Monitor/2 Libraries Loaded by SMP/E SMP/E ddname Distribution Target Description AEQQEXE0 SEQQEXE0 Executable modules (load) (load) AEQQDLL0 SEQQDLL0 Dynamic link libraries (DLLs)
When you have loaded the Workload Monitor/2 software, apply any recommended maintenance described in the PSP.
Loading Workload Monitor/2 NLS Software to MVS Perform this task if you intend to use Workload Monitor/2.
To load national language support (NLS) software for the Workload Monitor/2, process the software distribution tape using SMP/E. This creates or updates the necessary disk-resident libraries on your system. Table 18 describes the datasets that are created or updated by SMP/E.
Refer to Tivoli OPC Workload Monitor/2 User's Guide for information about how to install the Workload Monitor/2 on your personal workstation.
Table 18. NLS Libraries Loaded by SMP/E for Workload Monitor/2 SMP/E ddname Distribution Target Description AEQQRxxx SEQQRxxx Resource DLLs Note: The suffix xxx is the NLS identifier.
When you have loaded the national language support software for Workload Monitor/2, apply any recommended maintenance described in the PSP.
Using the EQQJOBS Installation Aid Perform this task on the system where you are installing the controller or the dialogs.
EQQJOBS is a CLIST-driven ISPF dialog that can help you install Tivoli OPC. You can set up EQQJOBS as soon as the tracker software has been installed. EQQJOBS assists in the installation of the tracker and controller by building batch-job JCL that is tailored to your requirements. You can use this JCL to: Install the Tivoli OPC tracking exits Set up Tivoli OPC RACF security Create Tivoli OPC datasets Create Tivoli OPC started-task JCL Perform Tivoli OPC planning functions. Set up EQQJOBS now so that it is ready to use when needed.
38 Tivoli OPC Installation Guide Installing Tivoli OPC
Setting Up the EQQJOBS Installation Aid EQQJOBS reads skeleton JCL from the SEQQSAMP or SEQQSKL0 libraries, tailors the JCL, and then writes the tailored JCL to an output library that you specify. The output library must be a partitioned dataset with record length 80 and record format FB, and must be allocated before you run EQQJOBS. The components of EQQJOBS reside in these libraries: SEQQCLIB CLIST to drive the dialog SEQQPNL0 EQQJOBS panels SEQQSAMP Sample JCL SEQQSKL0 Tivoli OPC batch-job skeletons.
To make EQQJOBS executable, allocate these libraries to the DD statements in your TSO session: SEQQCLIB to SYSPROC SEQQPNL0 to ISPPLIB SEQQSKL0 and SEQQSAMP to ISPSLIB.
To invoke EQQJOBS, enter the TSO command %EQQJOBS from an ISPF environment. This panel appears:
à ð EQQJOBSð ------EQQJOBS application menu ------
| Select option ===> | Userid - SYSPROG | Time - 15:ð4 | 1 - Create sample job JCL Terminal - 3278
| 2 - Generate OPC batch-job skeletons
| 3 - Generate OPC Data Store samples
| X - Exit from the EQQJOBS dialog
á ñ
Figure 7. EQQJOBS0—EQQJOBS Application Menu
The following pages describe options 1 and 2.
Chapter 4. Installing Tivoli OPC 39 Installing Tivoli OPC
Creating the Sample Job JCL To create the sample job JCL: 1. Select option 1 from the EQQJOBS application menu. This panel appears:
à ð EQQJOBS3 ------Create sample job JCL ------Command ===>
The dataset names specified on this panel should be fully qualified names without any enclosing apostrophes.
Enter the name of the output library:
Sample job JCL ===> CCOPC.OPCE.INSTJCL______.1/
Job statement information:
===> //SYSPROG1 JOB (111111,2222),'OPCESA BATCH',CLASS=B,MSGCLASS=H,______.2/ ===> // MSGLEVEL=(1,1),NOTIFY=SYSPROG______===> //ᑍ______===> //ᑍ______
The following dataset names are used by one or more of the generated job
Message library name ===> OPC.SEQQMSGð______.3/ Parameter library ===> CCOPC.OPCE.PARM______.4/ Checkpoint dataset ===> CCOPC.OPCE.CKPT______.5/
Press ENTER to continue á ñ Figure 8. EQQJOBS3—Create Sample Job JCL
The dataset names that you specify on this panel must be fully qualified and without enclosing apostrophes. .1/ Required input. Enter the name of a library where you want the generated JCL samples written to. The library must be allocated before you generate the batch JCL samples. Ensure that the library that you specify has sufficient directory blocks to store all the sample members that are generated by EQQJOBS (see Table 19 on page 42). .2/ Required input. Enter a JOB statement that follows standard JCL syntax and your installation standards. .3/ Required input. Enter the name of the library that contains the Tivoli OPC messages (SMP/E target DDNAME SEQQMSG0). .4/ Required input. Enter the name of a library that will contain the initialization statements. This library will be allocated by the EQQPCS01 batch job. .5/ Required input. Enter the name of the checkpoint dataset. This library will also be allocated by the EQQPCS01 batch job. 2. Press Enter, and this panel appears:
40 Tivoli OPC Installation Guide Installing Tivoli OPC
à ð EQQJOBS4 ------Create sample job JCL ------Command ===>
Enter the following required job stream parameters:
non-VSAM dsn prefix ===> CCOPC.OPCE______.1/ VSAM dsn prefix ===> CCOPC.OPCEV______.2/ Unit name ===> 339ð____ Default unit name .3/ Primary volume serial ===> PRODð1 Primary volume serial for VSAM .4/ Backup volume serial ===> PRODð2 Secondary volume serial for VSAM .5/ SYSOUT class ===> ᑍ SYSOUT class for reports .6/
The following information is optional:
STEPLIB dsname ===> OPC.SEQQLMDð______.7/ VSAMCAT dsname ===> ______.8/ VSAM password ===> ______.9/ Dsn prefix of old VSAM files ===> CCOPC.OPCAV______.1ð/ non-VSAM files ===> CCOPC.OPCA______.11/
Press ENTER to create sample job JCL á ñ Figure 9. EQQJOBS4—Create Sample Job JCL
.1/ Required input. Enter the qualifiers that prefix the non-VSAM dataset names. Tivoli OPC adds a low-level qualifier to the prefix to uniquely identify the non-VSAM datasets. For example, it adds EV for the event dataset. The full name will be CCOPC.OPCE.EV in this example. Note: Tivoli OPC does not use the prefix for the parameter library or checkpoint dataset. You entered the names of these datasets, fully qualified, on the previous panel. .2/ Required input. Enter the qualifiers that prefix the VSAM dataset names. Tivoli OPC adds a low-level qualifier to the prefix to uniquely identify each Tivoli OPC VSAM dataset. For example, it adds AD for the application description dataset. The full name will be CCOPC.OPCEV.AD in this example. .3/ Required input. Enter an esoteric device name that is valid at your installation. This could be a device type, for example 3380, or a group name, for example PROD or TEST. .4/ Required input. Enter a volume that will be used by sample job EQQPCS01 to allocate the primary datasets. Some Tivoli OPC logical files are implemented as two physical datasets, a primary and an alternate; for example, the current plan dataset. To minimize the potential impact of errors on a particular device, allocate the primary and alternate datasets on different physical devices. .5/ Required input. Enter a volume that will be used by sample job EQQPCS01 to allocate the alternate datasets. Specify a different volume from the one specified for the primary volume, although the volume can be the same if this is required at your installation. .6/ Required input. Enter the SYSOUT class that you want to use for the reports that are generated by the sample jobs. .7/ Optional. Enter the name of the Tivoli OPC load module library if the load modules are not in a dataset included in an active LNKLST member.
Chapter 4. Installing Tivoli OPC 41 Installing Tivoli OPC
.8/ Optional. Enter the name of a catalog in which VSAM datasets are to be defined if they will not be defined in the master catalog. .9/ Optional. Enter the password for the VSAM catalog if the catalog is password-protected. .1ð/ Optional. Enter the qualifiers that prefix your existing Tivoli OPC VSAM dataset names. These are used to create the dataset-conversion sample JCL. .11/ Optional. Enter the qualifiers that prefix your existing Tivoli OPC non-VSAM dataset names. These are used to create the dataset-conversion sample JCL. 3. Press Enter when you have entered the information on panel EQQJOBS4. The dialog now generates several members in the output library that you specified. These members, which are described in Table 19, will be used at various stages in the installation.
Table 19. Sample JCL Generated by the EQQJOBS Dialog Member Description of job EQQAUDIT Installs the AUDIT package sample EQQBSCAN Uses the batch loader to scan an application description EQQBSUBS Uses the batch loader to create three application descriptions and operator instructions EQQBVSAM Deletes/defines an application description dataset and creates an application description and operator instructions, using the batch loader EQQDPCOP JCL and usage notes for copy VSAM function EQQICNVS Migrates VSAM files EQQJES2 Assembles and link-edits the JES2 EXIT7 EQQJES2U Installs the JES2 usermod EQQJES3 Assembles and link-edits a JES3 exit EQQJES3U Installs the JES3 usermod EQQOPCA Sample started-task procedure for a tracker EQQOPCB Sample started-task procedure for a tracker and controller EQQOPCS Sample started-task procedure for a server EQQPCS01 Allocates unique datasets within the sysplex EQQPCS02 Allocates nonunique datasets EQQPCS03 Generates a job that allocates VSAM copy dataset EQQSAMPI Copies sample databases from the sample library to VSAM datasets EQQSMF Updates SMF exits for Tivoli OPC EQQ9SMDE Updates the RACF 1.9 class-descriptor table (ICHRRCDE) EQQ9SM01 Updates the RACF 1.9 router table (ICHRFR01)
42 Tivoli OPC Installation Guide Installing Tivoli OPC
| Generating Tivoli OPC Data Store Samples | To create the OPC Data Store samples: | 1. Select option 3 from the EQQJOBS application menu. This panel appears:
| à ð | EQQJOBS5 ------Create Data Store samples ------| Command ===>
| The dataset names specified on this panel should be fully qualified | names without any enclosing apostrophes.
| Enter the name of the output library:
| Sample job JCL ===> CCOPC.OPCE.JCLDS______(1)__
| Job statement information:
| ===> //SYSPROG1 JOB (111111,2222),'OPCESA BATCH',CLASS=B,MSGCLASS=H,__(2)__ | ===> // MSGLEVEL=(1,1),NOTIFY=SYSPROG______| ===> ______| ===> ______
| The following dataset names are used by one or more of the generated jobs. | Message library name ===> OPC.SEQQMSGð______(3)__ | Parameter library ===> CCOPC.OPCEDS.PARM______(4)__
| Press ENTER to continue | á ñ | Figure 10. EQQJOBS5—Create Data Store Samples
| a. Required input. Enter the name of a library where you want the generated | Data Store samples written to. The library must be allocated before you | generate the Data Store samples. Ensure that the library that you specify | has sufficient directory blocks to store all the sample members that are | generated by EQQJOBS (Table 20 on page 45). | b. Required input. Enter a JOB statement that follows standard JCL syntax | and your installation standards. | c. Required input. Enter the name of the library that contains the Tivoli OPC | messages (SMP/E target DDNAME SEQQMSG0). | d. Required input. Enter the name of a library that will contain the initialization | statements. This library must be allocated by the user. Use a name | different from the one of the Controller/Tracker parameter library. | 2. Press Enter, and this panel appears:
Chapter 4. Installing Tivoli OPC 43 Installing Tivoli OPC
| à ð | EQQJOBS6 ------Create Data Store samples ------| Command ===>
| Enter the following required job stream parameters: | Non-VSAM dsn prefix ===> CCOPC.OPCE______(1) | VSAM dsn prefix ===> CCOPC.OPCEV______(2) | Unit name ===> 339ð____ Default unit name (3) | Primary volume serial ===> PRODð1 Primary volume serial for VSAM(4)
| The following information is optional: | STEPLIB dsname ===> OPC.SEQQLMDð______(5) | VSAMCAT dsname ===> ______| VSAM password ===> ______
| Press ENTER to create sample job JCL | á ñ | Figure 11. EQQJOBS6—Create Data Store Samples
| a. Required input. Enter the qualifiers that prefix the non-VSAM dataset | names. | b. Required input. Enter the qualifiers that prefix the VSAM dataset names. | Tivoli OPC adds a low-level qualifier to the prefix to uniquely identify each | Tivoli Data Store VSAM dataset. | c. Required input. Enter an esoteric device name that is valid at your | installation. This could be a device type, for example 3380, or a group | name, for example PROD or TEST. | d. Required input. Enter a volume that will be used by sample job | EQQPCS04 to allocate the primary datasets. | e. Optional. Enter the name of the Tivoli OPC load module library if the load | modules are not in a dataset included in an active LNKLST member. | 3. Press Enter, and this panel appears:
| à ð | EQQJOBS7 ------Create Data Store samples ------| Command ===>
| Enter the parameters to build DSTOPTS and DSTUTIL options samples:
| Reserved class ===> X | Default requeue class ===> A | Connection type ===> SNA (SNA/XCF) | SNA Data Store luname ===> I9PC45AC (only for SNA connection) | SNA FN task luname ===> I9PC45RC (only for SNA connection) | Xcf Group ===> ______(only for XCF connection) | Xcf Data store member ===> ______(only for XCF connection) | Xcf FL task member ===> ______(only for XCF connection) | Tracker name ===> XXXXXXXX (Tracker luname or member name) | Max n. lines to store ===> ð______| Jlog retention period ===> 5_ (number of days)
| Press ENTER to create sample job JCL
| á ñ | Figure 12. EQQJOBS7—Create Data Store Samples
44 Tivoli OPC Installation Guide Installing Tivoli OPC
| The above is a sample with the required input parameters. Refer to | Customization and Tuning for the description of their meaning. | 4. Press Enter when you have entered the information on panel EQQJOBS7. The | dialog now generates several members in the output library that you specified. | These members, which are described in Table 20 will be used at various | stages in the installation:
| Table 20. Data Store Samples Generated by the EQQJOBS Dialog | Member Sample Description | EQQPCS04 Defines Data Store VSAM files and initializes them | EQQCLNUP Runs batch clean-up utility | EQQEXPOR Runs batch export utility | EQQIMPOR Runs batch import utility | EQQRCVIX Runs batch recover index utility | EQQREORG Runs batch reorg utility | EQQARCPA Contains Data Store initial parameters | EQQCTLPA Contains FL task initial parameters | EQQCLNPA Contains Data Store clean-up sample parameters | EQQEXPPA Contains Data Store export sample parameters | EQQIMPPA Contains Data Store import sample parameters | EQQRCVPA Contains Data Store recover sample parameters | EQQARCH Sample Data Store startup procedure
Generating Tivoli OPC Batch-Job Skeletons Several controller functions, such as daily planning, are performed by batch jobs that are submitted from the Tivoli OPC dialog. To generate the skeleton JCL for these jobs: 1. Select option 2 from the EQQJOBS main menu. This panel appears:
à ð EQQJOBS1 ------Generate OPC/ESA batch-job skeletons ------Command ===>
Enter the name of the output library. This should be a fully qualified dataset name without any enclosing apostrophes. This library should be allocated to ISPSLIB.
Batch-job skeletons ===> CCOPC.OPCE.JCLSKELS______.1/
The following dataset names are used by one or more of the generated job You can specify an asterisk (ᑍ) to indicate the name of the subsystem.
Message library name ===> OPC.SEQQMSGð______.2/ Parameter library ===> CCOPC.ᑍ.PARM______.3/ Member in parameter library ===> BATCHOPT .4/ Checkpoint dataset ===> CCOPC.ᑍ.CKPT______.5/
Press ENTER to continue á ñ Figure 13. EQQJOBS1—Generate Tivoli OPC Batch-Job Skeletons
Chapter 4. Installing Tivoli OPC 45 Installing Tivoli OPC
.1/ Required input. Enter the name of the library that the JCL skeletons will be placed in. Before you use the Tivoli OPC dialogs to submit batch jobs, allocate this library to the ISPSLIB DD statement in the TSO session of Tivoli OPC dialog users. “Setting Up the ISPF Environment” on page 87 explains setting up the Tivoli OPC dialog. You can create a new library for the skeleton JCL members or put them into an existing skeleton-JCL library. In the following fields, you can enter &XOPCNM. as one of the qualifiers for the dataset names. This is an ISPF variable that is stored in the profile and is the same variable that you specify in option 0.1 (SUBSYSTEM NAME) in the Tivoli OPC dialogs. When a skeleton is then used by an OPC/ESA dialog, &XOPCNM. is substituted with the name of the OPC/ESA subsystem that is being used. Ensure that &XOPCNM. ends with a period if it is not the low-level qualifier. For example, you could enter CCOPC.&XOPCNM..PARMLIB but CCOPC.&XOPCNM.PARMLIB results in a JCL error. If you enter an asterisk (*) as a dataset qualifier, the generated skeletons will contain &XOPCNM. in place of the asterisk. .2/ Required input. Enter the name of the library that contains the Tivoli OPC messages (SMP/E target ddname SEQQMSG0). .3/ Required input. Enter the name of the library that will contain the initialization statements. .4/ Required input. Enter the name of a member in the parameter library that will contain the BATCHOPT initialization statement. The Tivoli OPC batch jobs will use this member. If you have not already created the BATCHOPT statement, you can still generate the batch skeletons, but remember to create a member with the same name when you create the initialization statements. .5/ Required input. Enter the name of the checkpoint dataset. 2. Press Enter, and this panel appears:
46 Tivoli OPC Installation Guide Installing Tivoli OPC
à ð EQQJOBS2 ------Generate OPC/ESA batch-job skeletons ------Command ===>
Enter the following required job stream parameters:
| Non-VSAM dsn prefix ===> CCOPC.ᑍ______.1/ | VSAM dsn prefix ===> CCOPC.ᑍV______.2/ Unit name ===> 339ð____ Default unit name .3/ Unit name (temp ds) ===> SYSDA___ Unit name for temporary datasets .4/ Unit name (sort ds) ===> SYSDA___ Unit name for sort work datasets .5/ SYSOUT class ===> ᑍ SYSOUT class for reports .6/
The following information is optional:
STEPLIB dsname ===> OPC.SEQQLMDð______.7/ STEPCAT dsname ===> ______.8/ EQQMLOG dsname ===> CCOPC.ᑍ.MLOGBAT______.9/
The following information is REQUIRED WITH DBCS support:
KJSRTBL dsname ===> ______.1ð/
Press ENTER to generate OPC/ESA batch-job skeletons á ñ Figure 14. EQQJOBS2—Generate Tivoli OPC Batch-Job Skeletons
.1/ Required input. Enter the qualifiers that prefix the non-VSAM dataset names. Tivoli OPC adds a low-level qualifier to the prefix to uniquely identify the non-VSAM datasets. For example, it adds JTARC for the job-tracking archive dataset. If the subsystem name is OPCE, the dataset name will be CCOPC.OPCE.JTARC when the skeleton is used by the dialogs. .2/ Required input. Enter the qualifiers that prefix the VSAM dataset names. Tivoli OPC adds a low-level qualifier to the prefix to uniquely identify each Tivoli OPC VSAM dataset. For example, it adds WS for the workstation description dataset. If the subsystem name is OPCE, the dataset name will be CCOPC.OPCEV.WS when the skeleton is used by the dialogs. .3/ Required input. Enter an esoteric device name that is valid at your installation. This can be a device type, for example 3380, or a group name, for example PROD or TEST. .4/ Required input. Enter an esoteric device name that can be used for temporary datasets. .5/ Required input. Enter an esoteric device name that can be used for sort-work datasets. .6/ Required input. Specify the SYSOUT class that you want to use for the reports that are generated by the batch jobs. .7/ Optional. Enter the name of the Tivoli OPC load module library if the load modules are not in a dataset included in an active LNKLST member. .8/ Optional. Enter the name of a private catalog if one or more datasets cannot be reached via the master catalog. .9/ Optional. Enter the name of a message log dataset if messages are not sent to SYSOUT. This must not be the same dataset that is used by a tracker or controller. .1ð/ Required if you use the Japanese language feature. Enter the name of a dataset that will be used when sorting fields containing DBCS data.
Chapter 4. Installing Tivoli OPC 47 Installing Tivoli OPC
3. Press Enter when you have entered the information on panel EQQJOBS2. The dialog now generates the batch-job skeleton members.
If you are not sure at this stage what some of the values will be, it does not matter. You can rerun the dialog as many times as you want to regenerate the skeletons. You can also edit the generated skeletons manually.
This table shows the JCL skeleton members that EQQJOBS generates:
Table 21. Controller Skeleton JCL Generated by the EQQJOBS Dialog Member Batch job description EQQADCOS Calculate and print run dates of an application. EQQADDES Application cross-reference of external dependencies. EQQADPRS Application print program. EQQADXRS Application cross-reference program. EQQADX1S Application cross-reference of selected fields. EQQAMUPS Application description mass update. EQQAPARS Procedure to gather diagnostic information. EQQDPEXS Daily planning—plan next period. EQQDPPRS Daily planning—print current period results. EQQDPRCS Daily planning—replan current period. EQQDPSJS Daily planning—DBCS sort step. EQQDPSTS Daily planning—normal sort step. EQQDPTRS Daily planning—plan a trial period. EQQJVPRS Print JCL variable tables. EQQLEXTS Long-term planning—extend the long-term plan. EQQLMOAS Long-term planning—modify all occurrences. EQQLMOOS Long-term planning—modify one occurrence. EQQLPRAS Long-term planning—print all occurrences. EQQLPRTS Long-term planning—print one occurrence. EQQLTRES Long-term planning—create the long-term plan. EQQLTRYS Long-term planning—trial. EQQOIBAS Operator instructions—batch program. EQQOIBLS Operator instructions—batch input from a sequential dataset. EQQTPRPS Print periods. EQQTPRTS Print calendars. EQQWPRTS Print workstation descriptions.
48 Tivoli OPC Installation Guide Installing Tivoli OPC
Adding SMF and JES Exits for Event Tracking Perform this task if you are installing a tracker.
Tivoli OPC tracks the progress of jobs and started tasks through the MVS system by using JES and SMF exit points. Add all these exits on each MVS system where you will start Tivoli OPC.
To simplify the installation of Tivoli OPC event tracking, several sample event-tracking exits can be found in your sample library, SEQQSAMP. To assemble and install exits, you can use the sample JCL provided to install the exits as SMP/E usermods or alternatively you can assemble and link-edit the exits yourself. For JES exits, apply usermods in the CSI where JES is included—this is the best method. It has the advantage that SMP automatically reassembles the exits if maintenance is applied to the JES control blocks that Tivoli OPC is dependent on.
If you install a new release of Tivoli OPC in a new CSI, and the JES usermod is already installed in the same CSI as a previous release of Tivoli OPC, follow these steps: 1. Apply any necessary tolerance PTFs so that the previous release of Tivoli OPC can run with the new exit code. 2. Change the DDDEFs for JES so that they point to the SEQQSAMP and SEQQMAC0 libraries of the new release. 3. APPLY REDO the JES usermod. This will reassemble the exits with the new code.
The sample exits all use the EQQEXIT macro to create event-generating code. For more information on the EQQEXIT macro, see Appendix C, “Invoking the EQQEXIT Macro” on page 189.
Table 22 on page 50 describes the samples that you can use to generate and install the exits. The sample exit, skeleton JCL, and usermod entries identify members of the SEQQSAMP library. The event types in the table are prefixed with A for JES2, or B for JES3, when they are created by the exit. (See “Verifying Tracking Events” on page 107 for more information about event types.)
Chapter 4. Installing Tivoli OPC 49 Installing Tivoli OPC
Table 22. Sample Exits for Tivoli OPC Exit name Exit Sample exit Sample JCL/ Event supported Event type usermod type IEFACTRT SMF EQQACTR1 EQQSMF Job and step completion 3J,3S IEFUJI SMF EQQUJI1 EQQSMF Job start 2 IEFU83 SMF EQQU831 EQQSMF End of print group and purge, and 4,5,S dataset triggering support EXIT7 JES2 EQQXIT72 EQQJES2/ JCT I/O exit for JES2 level prior to 1,3P EQQJES2U SP Version 4 Release 1 EXIT7 JES2 EQQXIT74 EQQJES2/ JCT I/O exit for JES2 level SP 1,3P EQQJES2U Version 4 Release 1 and later IATUX19 JES3 EQQUX191 EQQJES3/ Output processing complete 3P EQQJES3U IATUX29 JES3 EQQUX291 EQQJES3/ On job queue 1 EQQJES3U
The EQQU831 sample generates type 4 and type 5 events and also generates resource availability events when a dataset is closed after read or update processing. See “Implementing Support for Data Set Triggering” on page 59 for more information.
You must tailor the sample JCL to the requirements of your installation. If you have already run EQQJOBS, tailored versions of the JCL will already exist in the EQQJOBS output library. Alternatively, you can copy any of the members from the SEQQSAMP library to one of your own libraries and manually tailor the JCL.
The load module names are the same as the exit names, with one exception. The JES2 exit (EXIT7) load module is called OPCAXIT7 and has an entry point called OPCAENT7.
If your MVS system is a JES2 system, include these records in the JES2 initialization member:
JES2 initialization statements LOAD(OPCAXIT7) /ᑍ Load Tivoli OPC exit mod ᑍ/ EXIT(7) ROUTINES=OPCAENT7,STATUS=ENABLED /ᑍ Define EXIT7 entry point ᑍ/
For more information on JES2 initialization statements, refer to JES2 Initialization and Tuning Reference.
To activate the exits for a JES3 system, you can link them to a library that is concatenated ahead of SYS1.JES3LIB. Alternatively, you can replace the existing exits in SYS1.JES3LIB with the Tivoli OPC-supplied IATUX19 and IATUX29 exits. For more information, refer to JES3 Initialization and Tuning. Avoiding Some Errors When Using Compiler Version IEV90: If version IEV90 of the compiler reports errors, remove the RMODE=ANY statement from the sample exit.
50 Tivoli OPC Installation Guide Installing Tivoli OPC
If you are unfamiliar with how to activate SMF exits, see “Updating SMF Parameters” on page 54 and MVS/ESA SMF.
Updating SYS1.PARMLIB Perform this task for a tracker, a controller, a standby controller, or the dialogs.
Defining Tivoli OPC Subsystems You must define the name of every new Tivoli OPC subsystem in the active subsystem-name-table member of SYS1.PARMLIB. It is advisable to install at least two Tivoli OPC controlling systems, one for testing and one for your production environment. Note: It is recommended that you install the tracker and the controller in separate address spaces on the controlling system.
To define the subsystems, update the active IEFSSNnn member in SYS1.PARMLIB. Include records as in the following example:
| Subsystem definition record | SUBSYS SUBNAME(subsystem name) INITRTN(module name) INITPARM ('maxecsa,suffix')
| subsystem name is the name assigned to a Tivoli OPC subsystem. The name must | be 2–4 characters. All the Tivoli OPC subsystem names, as defined in the | SYS1.PARMLIB member IEFSSNnn, must be unique within a GRS complex. Also, | the Tivoli OPC subsystem names of the OPC controllers must be unique within | your OPCplex/OPC network, both local and remote systems. Tivoli OPC requires | the started task name or jobname used for a Tivoli OPC address space to exactly | match the name of the associated subsystem.
module name is the name of the subsystem initialization module, EQQINITD.
maxecsa defines the maximum amount of extended common service area (ECSA) that is used to queue Tivoli OPC job-tracking events. The value is expressed in kilobytes (1 KB equals 1024 bytes). The default is 4, which means that a maximum of 4 KB (4096 bytes) of ECSA storage is needed to queue Tivoli OPC job-tracking events. Tivoli OPC does not limit the ECSA storage you can allocate.
| suffix is the module name suffix for the EQQSSCM module that EQQINITD loads into common storage. EQQSSCM is the subsystem communication module. The suffix must be a single character. Because the name of the module shipped with | Tivoli OPC is EQQSSCMD, you should specify a suffix value of D. If you do not | provide a suffix, EQQINITD will attempt to load module name EQQSSCMD. You | can also specify a module name in the EQQSSCMD keyword of the OPCOPTS initialization statement.
“Updating the MVS Link-Library Definition” on page 56 provides more information about EQQSSCM modules.
Chapter 4. Installing Tivoli OPC 51 Installing Tivoli OPC
This example illustrates a record you can include in the SYS1.PARMLIB IEFSSNnn member:
Subsystem definition example | SUBSYS SUBNAME(OPCE) INITRTN(EQQINITD) INITPARM ('1ðð,D')
The record defines a Tivoli OPC subsystem called OPCE. This represents a | tracker. Its initialization module is EQQINITD. The amount of ECSA that is allocated, 101104 bytes, is enough for 1136 job-tracking events. Because suffix | value D is specified, EQQINITD loads module EQQSSCMD.
Diagnosis, Modification, or Tuning Information
Calculating MAXECSA Values Tivoli OPC allocates ECSA storage for job-tracking events in blocks of 1424 bytes. Each block is equivalent to 16 events. Table 23 on page 53 gives examples of the storage asked for, the storage actually allocated, and the events accommodated for several maxecsa values. The number of events created for each job or started task in your environment is influenced by the definitions in the EWTROPTS initialization statement. Every job or started task creates a minimum of six events. If the job or started task generates output and PRINTEVENTS(ALL) or PRINTEVENTS(END) is specified, an event is created when each output group is purged. If STEPEVENTS(ALL) is specified, an event is created for every step in the job or started task.
If you want to calculate values that are not shown in the table for a given MAXECSA value, use this method: Space requested = MAXECSA * 1024 Blocks = space requested / 1424 (round down to a whole number) Space allocated = blocks * 1424 Events accommodated = blocks * 16
52 Tivoli OPC Installation Guide Installing Tivoli OPC
Table 23. Examples of MAXECSA Storage Values MAXECSA Amount of Blocks of ECSA Number of events value MAXECSA space space allocated accommodated requested (bytes) 0 0 0 (0) 0 4 4096 2 (2848) 32 8 8192 5 (7120) 80 16 16384 11 (15664) 176 36 36864 25 (35600) 400 72 73728 51 (72624) 816 100 102400 71 (101104) 1136 200 204800 143 (203632) 2288 400 409600 287 (408688) 4592 500 512000 359 (511216) 5744
The catalog-management function does not use the ECSA storage that is specified for job-tracking events. Instead, ECSA storage outside this specification will be obtained when Tivoli OPC detects datasets in a job that will be created, cataloged, or uncataloged. About 150 bytes of ECSA storage is allocated for each dataset. The event writer releases this storage when the dataset information and the job-start event (type 2) have been stored on the event dataset.
Notes: 1. Allocate enough ECSA storage so that job-tracking events are not lost when the Tivoli OPC event-writer subtask is not active. When the event writer is active, the number of queued events in ECSA is almost always 0. Allocate enough ECSA for the maximum amount of time you expect the event writer to be inactive. For example, after the IPL of an MVS system, job-tracking events can occur before the Tivoli OPC tracker address space has become active. If you expect a maximum of 50 events to occur during this time, you should a MAXECSA value of 8 according to the preceding table. When the event writer becomes active, the queued events are processed and removed from ECSA. If events are lost, message EQQZ035E is written to the message log. See Tivoli OPC Messages and Codes for a description of this message. 2. ECSA storage for job-tracking events is required only if the Tivoli OPC started task includes an event-writer subtask. On a Tivoli OPC controlling system, you can have one Tivoli OPC address space running only an event writer subtask, and another one running the controller functions and the remaining tracker | functions. In this situation, you must specify a maxecsa value of 0 for the | subsystem that contains the controller functions. 3. All ECSA storage is allocated above the 16 MB line. 4. Except for the catalog-management function, Tivoli OPC does not perform FREEMAIN on ECSA.
End of Diagnosis, Modification, or Tuning Information
Chapter 4. Installing Tivoli OPC 53 Installing Tivoli OPC
Authorizing the Tivoli OPC Load-Module Library You must update the active authorized-program-facility member (IEAAPFnn, or PROGnn) to make the load-module library authorized. Each record, except the last, ends with a comma. For the following example, assume that you have installed Tivoli OPC load modules in the dataset OPC.SEQQLMD0 and that this dataset is on volume ABC123. To authorize this library, insert this record before the last entry in the IEAAPFnn: OPC.SEQQLMDð ABC123, or update the PROGnn member, if you have MVS SP5 or later. Note: Libraries that are defined in the IEAAPFnn or PROGnn member are authorized only if they remain on the volume specified. If DFHSM is used in your system, change DFHSM parameters so that the new authorized library is not migrated by DFHSM.
Updating SMF Parameters The SMFPRMnn member defines parameters for the System Management Facilities (SMF). You must verify that the active SMF parameter member, SMFPRMnn, specifies that all SMF exits used by Tivoli OPC event tracking are activated, and that the required SMF records are being collected. If this is not the case, you must update the active SMF parameter member. Tivoli OPC event tracking requires these SMF exits: IEFUJI Job initiation exit IEFACTRT Job-end and step-end exits IEFU83 Record write exit
Tivoli OPC also requires that SMF record types 6, 26, and 30 be collected.
Tivoli OPC requires that more SMF records are collected if you install the SMF IEFU83 exit with SRREAD set to YES on the EQQEXIT invocation. Specify this if you want special resource availability events automatically generated when a dataset is closed after being opened for: Read processing, or Output processing, or Either read or output processing
These SMF records are needed: Type 14 records are required for non-VSAM datasets opened for INPUT or RDRBACK processing. Type 15 records are required for non-VSAM datasets opened for output. Type 64 records are required for VSAM datasets. You can specify if the SMF records used by the exit should not be written to the SMF log. If your installation does not currently collect SMF records 14, 15 or 64, but you want resource availability events automatically generated, change the EQQU831 sample so that these records are not written through to the SMF log.
54 Tivoli OPC Installation Guide Installing Tivoli OPC
To avoid dataset triggering, and thus to improve performance, specify SRREAD=NONE in the IEFU83 SMF exit on invocation of the EQQEXIT macro. The SRREAD=NO parameter prevents dataset triggering for only SMF record type 14.
Active exits are defined by the EXITS parameter of the SYS and SUBSYS keywords. An example of these keywords is:
SYS and SUBSYS keywords SYS(TYPE(6,26,3ð),EXITS(IEFU83,IEFACTRT,IEFUJI)) SUBSYS(STC,EXITS(IEFUJI,IEFACTRT,IEFU83)) SUBSYS(JESn,EXITS(IEFUJI,IEFACTRT,IEFU83))
Notes: 1. JESn is either JES2 or JES3. This parameter does not refer to JES itself, but to batch jobs handled by JES. So do not suppress exit invocation. Ensure that you do not specify TYPE6=NO and TYPE26=NO on the JOBCLASS and STCCLASS statements of the JES2 initialization parameters. 2. You might find it useful during installation to code two SMFPRMnn members, one with the exits active and the other with the exits inactive. You can then use the SET SMF=nn MVS command to switch your current SMF parameters to the new member. By switching back, using the SET SMF=nn command, you avoid the need to re-IPL, if you encounter a problem. 3. Exits for SUBSYS STC are required by Tivoli OPC. They were not required by OPC/A.
If you have MVS SP5 or later, the PROGnn parmlib member allows you to specify installation exits and control their use. Through PROGnn, you can associate multiple exit routines with installation exits at IPL, or while the system is running. IBM recommends that you use PROGnn in addition to SMFPRMnn to specify exits, whether or not you want to take advantage of these functions.
The following example shows how you can specify SMF exits in a PROGxx parmlib member. If you specify this in SMFPRMnn: SYS(...EXITS(IEFU83,IEFACTRT,IEFUJI)) you would add this to get the equivalent processing in PROGnn: EXIT ADD EXITNAME(SYS.IEFU83) MODNAME(IEFU83) EXIT ADD EXITNAME(SYS.IEFACTRT) MODNAME(IEFACTRT) EXIT ADD EXITNAME(SYS.IEFUJI) MODNAME(IEFUJI)
When you associate new exit routines with SMF exits through PROGnn or the SETPROG command, you must use the following naming conventions: For exits listed on the EXITS keyword of the SYS statement in SMFPRMnn, each exit will have the name SYS.xxxx (where xxxx is one of the exits listed). For exits listed on the EXITS keyword of the SUBSYS statement of SMFPRMnn, each exit will have the name SYSzzzzz.xxxx (where zzzz is the name of the subsystem and xxxx is one of the exits listed).
| WARNING for CUSTOMERS using FTP at OS/390 V2R5 and above. The following | statement must be added to the SMFPRMxx member:
Chapter 4. Installing Tivoli OPC 55 Installing Tivoli OPC
| SUBSYS(OMVS,EXITS(IEFUJI,IEFU83)) | and these statements must be added to the PROGxx member: | EXIT ADD EXITNAME(SYSOMVS.IEFU83) MODNAME(EQQU831) | EXIT ADD EXITNAME(SYSOMVS.IEFUJI) MODNAME(EQQUJI1)
For information on using PROGnn to control the use of exits and exit routines, refer to MVS Initialization and Tuning Reference.
Updating MVS Dump Options The sample JCL procedure for a Tivoli OPC address space includes a SYSMDUMP DD statement and a dump dataset is allocated by the EQQPCS02 JCL created by EQQJOBS. SYSMDUMP is the dump format preferred by the service organization.
Ensure that the dump options for SYSMDUMP include RGN, LSQA, TRT, CSA, and GRSQ on systems where a Tivoli OPC address space will execute. To display the current SYSMDUMP options, issue the MVS command DISPLAY DUMP,OPTIONS. You can use the CHNGDUMP command to alter the SYSMDUMP options. Note that this will only change the parameters until the next IPL is performed.
To dump a Tivoli OPC address space using the MVS DUMP command, the SDUMP options should specify RGN, LSQA, TRT, CSA, and GRSQ. Consider defining these options as your system default.
Updating the MVS Link-Library Definition If you installed Tivoli OPC in a separate load-module library, it is recommended that you define this library in the active LNKLSTnn member. Alternatively, you can define the load-module library on the STEPLIB DD statement of the Tivoli OPC started-task JCL and TSO logon procedures of Tivoli OPC dialog users.
If you have installed Tivoli OPC load modules in the dataset OPC.SEQQLMD0 and this dataset is cataloged in the master catalog, insert this record before the last entry in the LNKLSTnn member to add this library to the link library concatenation:
Adding LINKLIB OPC.SEQQLMDð,
If you choose not to define the Tivoli OPC load-module library in the LNKLSTnn member, you must: | Copy the tracker modules, EQQINITD and EQQSSCMD, to a library in the MVS | link-library concatenation. EQQINITD is used by the master-scheduler-initialization function when the MVS system is being IPLed. | EQQINITD then loads EQQSSCMD into common storage. EQQSSCMD is | about 23KB and is placed above the 16MB line. Remember to copy the | modules again whenever they are updated by Tivoli OPC maintenance. This is | especially important for the EQQSSCMD module, which must be at the same update level as the rest of the Tivoli OPC code. Define the Tivoli OPC load-module library on a STEPLIB DD statement in the Tivoli OPC started-task JCL. Define the Tivoli OPC load-module library on a STEPLIB DD statement in the TSO logon procedure of all Tivoli OPC dialog users.
56 Tivoli OPC Installation Guide Installing Tivoli OPC
Load the dialog module, EQQMINOR, from an APF-authorized library. If you define the Tivoli OPC load-module library on a TSO STEPLIB DD statement, and any of the other libraries defined on this DD statement are not authorized, you must copy EQQMINOR to another library in the LNKLST concatenation so that it is loaded APF authorized. You must also remember to copy the module again whenever it is updated by Tivoli OPC maintenance.
Updating XCF Initialization Options Consider this information if you use XCF for communication:
XCF initialization options are specified in the COUPLEnn member of SYS1.PARMLIB. If you have not specified your own COUPLEnn member, the system uses the default member, COUPLE00. The IBM-supplied COUPLE00 member causes the system to be IPLed in XCF-LOCAL mode. This mode is not supported by Tivoli OPC. So ensure that your system uses a COUPLEnn member that does not IPL the system in XCF-LOCAL mode. The COUPLEnn member must include the PCOUPLE keyword of the COUPLE statement. If this is omitted, XCF is initialized in XCF-LOCAL mode. For Tivoli OPC purposes, you can use the default values for the remaining XCF options. However, it is recommended that you set up a transport class for Tivoli OPC. Specify a class length of 152 for the Tivoli OPC transport class.
COUPLEnn example COUPLE SYSPLEX(PLEXV2ð1) /ᑍ SYSPLEX name ᑍ/ PCOUPLE(IM2.PLEXV2ð1.CDS1,VOLðð1) /ᑍ Primary couple dataset ᑍ/ ACOUPLE(IM2.PLEXV2ð1.CDS2,VOLðð1) /ᑍ Alternate couple datasetᑍ/ CLASSDEF CLASS(TCOPC) /ᑍ OPC transport class ᑍ/ CLASSLEN(152) /ᑍ Message length ᑍ/ GROUP(OPCGRP) /ᑍ OPC group name ᑍ/ MAXMSG(5ðð) /ᑍ No of 1K message buffersᑍ/
Note: You can change XCF options while the system is active by using the SETXCF operator command.
For more information about XCF, refer to Sysplex Management.
Modifying TSO Parameters You must define the EQQMINOR module to TSO on each system where you install the OPC dialogs. Also, you should authorize the Tivoli OPC TSO commands on every system where you install Tivoli OPC. If you do not authorize the Tivoli OPC TSO commands, they will work only on the system where the controller is installed.
Chapter 4. Installing Tivoli OPC 57 Installing Tivoli OPC
To request services from the Tivoli OPC subsystem on behalf of a TSO user, the Tivoli OPC dialog invokes the EQQMINOR module using the TSO service facility. EQQMINOR is the dialog interface module. It must execute as an APF-authorized program. To achieve this, define EQQMINOR to TSO. If you are installing the OPC dialogs, include EQQMINOR in the list of programs defined by the AUTHTSF statement in the IKJTSOnn member of SYS1.PARMLIB. This statement defines programs to be authorized when invoked via the TSO service facility. Here is an example of such a statement:
IKJTSOnn AUTHTSF example AUTHTSF NAMES(IKJEFF76 + IEBCOPY + EQQMINOR)
If you prefer, you can put EQQMINOR in CSECT IKJEFTAP instead of IKJTSOnn. Refer to TSO/E Customization for more information on using IKJEFTAP.
Tivoli OPC supports the BACKUP, OPINFO, OPSTAT, SRSTAT, and WSSTAT TSO commands. Update the IKJTSOnn member on each system where you are installing Tivoli OPC to define these commands as authorized commands. To do this, add them to the list of commands defined by the NAMES keyword of the AUTHCMD statement. Here is an example of such a statement:
IKJTSOnn AUTHCMD example AUTHCMD NAMES(BACKUP + OPINFO + OPSTAT + SRSTAT + WSSTAT)
If the default entry in the ISPF TSO command table ISPTCM is set for unauthorized TSO commands, then ISPTCM must be updated. The ISPTCM can be updated using the ISPMTCM macro. Define the BACKUP, OPINFO, OPSTAT, SRSTAT, and WSSTAT commands like this:
ISPTCM example ISPMTCM FLAG=62,ENTNAME=BACKUP ISPMTCM FLAG=62,ENTNAME=OPINFO ISPMTCM FLAG=62,ENTNAME=OPSTAT ISPMTCM FLAG=62,ENTNAME=SRSTAT ISPMTCM FLAG=62,ENTNAME=WSSTAT
No update is needed to ISPTCM if the default entry is set up for authorized TSO commands. For more information about the ISPMTCM macro statements refer to ISPF Planning and Customization.
58 Tivoli OPC Installation Guide Installing Tivoli OPC
Performance Considerations To improve performance, you might want to define the tracker address space as nonswappable. To do this, include the definition of the tracker top load module, EQQMAJOR, in the program properties table (PPT). This PPT entry example is defined in a SCHEDnn member of SYS1.PARMLIB:
SCHEDnn example PPT PGMNAME(EQQMAJOR) NOSWAP
The EQQMAJOR program must run in storage key 8, the default value.
To ensure prompt processing by Tivoli OPC and to avoid delays in the handling of event records, the tracker subsystem performance rating (that is, its dispatching priority) should match that of the JES subsystem.
Defining the DLF Exit for Hiperbatch Support If you want to include Hiperbatch support for Tivoli OPC controlled jobs, specify the DLF exit name in the COFDLFnn member of SYS1.PARMLIB. A DLF exit sample is supplied with the SEQQSAMP library. The exit must reside in an authorized library in the LNKLST concatenation. This example of a COFDLFnn member defines a DLF exit called OPCDLF:
COFDLFnn example CLASS MAXEXPB(nnnn) PCTRETB(nnn) CONEXIT(OPCDLF)
For more information on including Hiperbatch support in Tivoli OPC, refer to Tivoli OPC Customization and Tuning.
Starting Tivoli OPC Automatically The COMMNDnn member of SYS1.PARMLIB list MVS commands automatically issued during system initialization. To avoid delays in starting Tivoli OPC when the MVS system is started, consider including the names of your Tivoli OPC started tasks in this member. Refer to MVS/ESA Initialization and Tuning Reference for information on how to include start commands for your Tivoli OPC address spaces.
Updating APPC/MVS Options If you want to use the API, or the server, to communicate with Tivoli OPC, you must update APPC/MVS options. See “Activating Support for the Tivoli OPC API” on page 96, or “Activating Support for the Tivoli OPC APPC/MVS Server” on page 100, for a detailed description of what you need to do.
Implementing Support for Data Set Triggering The Tivoli OPC dataset triggering function lets you start dependent processing or schedule unplannable work by automatically generating special resource availability events when a dataset is closed after being opened for: Read processing Output processing Either read or output processing.
Chapter 4. Installing Tivoli OPC 59 Installing Tivoli OPC
Tivoli OPC uses the SMF exit IEFU83 to generate a resource availability event when IEFU83 is called for SMF record types 14, 15, or 64. The dataset activity SMF records are generated when a dataset is closed or processed by EOV. Tivoli OPC will generate resource availability events only when the dataset is closed. When a VSAM dataset is closed, two SMF 64 records are created, one each for the DATA and INDEX components. When resource availability events are requested for VSAM datasets, the event will be created when the DATA component is closed, Tivoli OPC will not generate an event when the INDEX component is closed.
SMF dataset activity records are written when the dataset is closed—regardless of whether the JOB/STEP/TASK/USER completed successfully. For more information about the datasets that generate SMF record types 14, 15, or 64 refer to MVS/ESA SMF.
Use the EQQLSENT macro to define the datasets for which you want events to be generated. The selection table created, EQQDSLST, resides in ECSA. It is automatically loaded from the dataset referred to by the EQQJCLIB ddname when the event writer is started in a Tivoli OPC tracker if a table has not previously been loaded since IPL. To reload the table at any time, issue the MVS modify command: F subsystemname,NEWDSLST
Note: No support is available for the dataset triggering function before the event writer is started immediately after an MVS IPL. Once the event writer has started after IPL, dataset triggering functions are available if the event writer is subsequently stopped. To stop dataset triggering at any time issue the NEWDSLST modify command to load a table that contains only the end-of-table indicator.
To implement support for the dataset triggering function, perform these actions: Update SYS1.PARMLIB member SMFPRMnn to include record types 14 and/or 15 and/or 64. Install SMF exit IEFU83 using the EQQU831 sample. See “Macro Invocation Syntax for EQQEXIT” on page 190 on how to specify the SRREAD parameter. Define the dataset selection criteria using the EQQLSENT macro. Use the EQQLSJCL sample to invoke the macro correctly. The resulting table must be stored as member EQQDSLST in the dataset referenced by the EQQJCLIB ddname in the tracker JCL procedure.
Appendix D, “Invoking the EQQLSENT Macro” on page 193 describes the macro in detail.
Setting Up the Tivoli OPC RACF Environment Consider this task for a tracker, controller, or standby controller.
If your installation protects data and resources from unauthorized use, you must define Tivoli OPC to your security system. This section assumes that the Resource Access Control Facility (RACF) is installed and active on your MVS system. It describes the activities you must perform to define and enable the security environment for Tivoli OPC.
60 Tivoli OPC Installation Guide Installing Tivoli OPC
Tivoli OPC Customization and Tuning contains detailed plans and instructions for establishing a security strategy for your Tivoli OPC resources.
Controlling the User ID of the Tivoli OPC Address Space If you run Tivoli OPC as a started task, you must associate the cataloged procedure name with a suitably authorized RACF user. If you have RACF Version 2 Release 1 installed, you can define the user ID in the STARTED resource class. In RACF Version 1, you need to update the started procedures table, ICHRIN03. RACF supplies a default ICHRIN03 table, which you can modify. Refer to SPL: RACF for more information about this table and how you can add the default entry.
If your ICHRIN03 table contains the default entry, you need not update the table, but you must define a RACF user with the same name as the catalog procedure.
If your ICHRIN03 does not contain the default entry (or you choose not to set the default entry), you must update the table with an entry that contains the cataloged procedure name and its associated RACF user. This RACF user need not have the same name as the cataloged procedure.
Whether your ICHRIN03 table contains the default entry or a specific entry you have defined, the RACF user identified through ICHRIN03 must have the necessary access authority to the datasets in the cataloged procedure.
If you run Tivoli OPC as a batch job, you need not update ICHRIN03.
Controlling the User ID of Tivoli OPC-Submitted Jobs Two types of Tivoli OPC batch jobs are: Production batch jobs, which Tivoli OPC submits when their prerequisites in the current plan are fulfilled Tivoli OPC batch jobs, which you can submit directly from a panel in the Tivoli OPC dialogs.
Normal Batch Jobs Tivoli OPC submits production jobs to the internal reader, or starts started tasks, when all prerequisites are fulfilled. The JCL comes from the JS file (EQQJSnDS), the JCL job library (EQQJBLIB), or the job-library-read exit (EQQUX002). You can determine the authority given to a job or started task in several ways: You can submit work with the authority of the Tivoli OPC address space. The job or started task is given the same authority as the controller or tracker whose submit subtask actually submits the work. For example, work that is transmitted from the controller and then submitted by the tracker is given the authority of the tracker. Another method is to use the job submit exit, EQQUX001. This exit is called when Tivoli OPC is about to submit work. – You can use the RUSER parameter of the EQQUX001 exit to cause the job or started task to be submitted with a specified user ID. The RUSER name is supported even if the job or started task is first sent to a tracker before being started. – In certain circumstances you might need to include a password in the JCL to propagate the authority of a particular user. You can use the job-submit
Chapter 4. Installing Tivoli OPC 61 Installing Tivoli OPC
exit (EQQUX001) to modify the JCL and include a password. This can occur, for example, if your Tivoli OPC configuration includes an OPC/A Release 2 system. Work is submitted on the controlling system and is then transmitted via NJE to the OPC/A Release 2 system. The JCL is saved in the JCL repository (JSn) dataset before the exit is called, thus avoiding the need to store JCL with specific passwords. This method prevents the password from being visible externally. Refer to Tivoli OPC Customization and Tuning for more information about the job-submit exit.
Tivoli OPC Batch Jobs When you submit Tivoli OPC batch jobs from your TSO address space, they go through normal TSO functions. This means that you can submit any job allowed by TSO/E. Tivoli OPC makes no authority checks when the job is submitted.
For the Tivoli OPC batch job to run successfully, it must be authorized to reference the datasets it uses. The submitting TSO user may also need authorization to use a specific function. For example, a user could have update authority to the AD file but not have the authority to use the AD mass update function.
Protecting Tivoli OPC Data Sets For basic security of Tivoli OPC data, you should restrict access to all Tivoli OPC datasets.
Two categories of Tivoli OPC users need different levels of access to Tivoli OPC datasets: Tivoli OPC system support people must be able to debug problems and reorganize VSAM files. You might give them alter access to all Tivoli OPC datasets. Tivoli OPC administrators and operators must be able to use the Tivoli OPC dialogs. They need read access to Tivoli OPC ISPF-related datasets (such as the panel and message libraries), but they do not access the Tivoli OPC databases (such as the workstation database) directly: these files are accessed by the Tivoli OPC subsystem, not by any Tivoli OPC code in the TSO user's address space. Authority to access the data for a Tivoli OPC dialog user is given via the Tivoli OPC authorization functions.
The Tivoli OPC started task needs: Alter access to VSAM datasets Read access to input datasets, such as the message library (EQQMLIB) and parameter library (EQQPARM) Update access to all other Tivoli OPC datasets Update access to catalogs and alter access to datasets for all work that Tivoli OPC tracks, if you use the catalog management function.
Controlling Access to Tivoli OPC Resources Before Tivoli OPC executes any request initiated by a user, a security verification check is passed to the system authorization facility (SAF) to ensure that the user is authorized to access all resources needed to execute the request. A user can request Tivoli OPC services from: An ISPF dialog session
62 Tivoli OPC Installation Guide Installing Tivoli OPC
The Workload Monitor/2 TSO commands The program interface (PIF) The application programming interface (API) | Tivoli Job Scheduling Console.
Any security software that interfaces with SAF will work with Tivoli OPC. For this description, the security product is assumed to be RACF.
The MVS router service calls RACF to perform authority checks. It provides an installation exit that you can use instead of—or in addition to—RACF to perform resource control functions.
If you have RACF Version 2 Release 1 installed, use the Tivoli OPC reserved resource class IBMOPC. In earlier versions of RACF, you must update the RACF router table (ICHRFR01) and the RACF class-descriptor table (ICHRRCDE) to include the general resource class used by Tivoli OPC. Table 24 lists the members that you can use to update ICHRFR01 and ICHRRCDE. These members can be found in your EQQJOBS output library or in the SEQQSAMP library. Note: Changes to the RACF router and descriptor tables do not take effect until you perform an IPL of the MVS system.
Table 24. Sample Library Members for Updating RACF Tables Member RACF Type Description EQQ9RF01 1.9 Source Defines what action to take for the new resource class in the class descriptor table (ICHRFR01) EQQ9RFDE 1.9 Source Adds a new resource class to the ICHRRCDE table EQQ9SM01 1.9 JCL JCL to assemble and update the ICHRFR01 table EQQ9SMDE 1.9 JCL JCL to assemble and update the ICHRRCDE table
For more information about the router table, and the class descriptor table refer to SPL: RACF.
The default class for Tivoli OPC is OPCCLASS. If you use a different class name, you must specify this name on the AUTHDEF statement. If you are running more than one Tivoli OPC system, for example a test system and production system, you might want to define more than one RACF class. By using different CLASS parameters on each AUTHDEF statement, you can specify a different authorization scheme for each system.
To control access to Tivoli OPC functions, give at least one TSO user-class authority to the Tivoli OPC resource class. This TSO user can then allow other Tivoli OPC users to access Tivoli OPC resources as needed.
Tivoli OPC also uses the APPL resource class. Define the subsystem name as a resource in the APPL class. The easiest way to do this is to have the RACF administrator give class authority to the APPL resource class to one TSO user.
Chapter 4. Installing Tivoli OPC 63 Installing Tivoli OPC
This TSO user defines the subsystem name (for example, OPCC) to the APPL resource class by entering:
Define subsystem resource RDEFINE APPL OPCC UACC(NONE)
Refer to RACF Command Reference and RACF Administrator's Guide if you are unfamiliar with this process.
When the subsystem name is defined to RACF, you can give other TSO users access to Tivoli OPC. For example, to allow the TSO user OPCUGRP to access OPCC with an update access authority by default, enter:
Permit access to Tivoli OPC PERMIT OPCC ID(OPCUGRP) ACCESS(UPDATE) CLASS(APPL)
For remote dialog users and remotely executed PIF applications, the server will do the authority checking; it will check both the APPL class subsystem name resource and the OPC fixed resources. The user for which the server does authority checking is: For dialog users, the TSO user ID. For PIF applications, the user ID defined in the security environment of the PIF job.
| Permitting Access to the Controller through the API | If you use Tivoli OPC API, you can control access to the controller through the security functions of both APPC/MVS and Tivoli OPC. Ensure that you consider both these environments when you update RACF. Refer to Tivoli OPC | Customization and Tuning for more information about controlling access to Tivoli | OPC through the API.
| Controlling Access to Tivoli OPC Resources when Using Tivoli Job | Scheduling Console | Tivoli Framework performs a security check when a user tries to use the Tivoli OPC | Tivoli Job Scheduling Console, checking the user ID and password. The Tivoli | Framework associates each user ID and password to an Administrator.
| OPC resources are currently protected by RACF.
| The Tivoli Job Scheduling Console user should only have to enter a single user | ID/password combination, and not provide two levels of security checking (at the | Tivoli Framework level and the again at the Tivoli OPC level).
| The security model is based on having the Tivoli Framework security handle the | initial user verification, while at the same time obtaining a valid corresponding | RACF user ID. This makes it possible for the user to work with the security | environment in MVS.
64 Tivoli OPC Installation Guide Installing Tivoli OPC
| MVS security is based on a table mapping the Tivoli Administrator to a RACF user | ID. When a Tivoli Framework user tries to initiate an action on MVS, the Tivoli | Administrator ID is used as a key to obtain the corresponding RACF user ID.
| The Server uses the RACF user ID to build the RACF environment to access Tivoli | OPC services, so the Tivoli Administrator must relate, or map, to a corresponding | RACF user ID.
| Refer to Tivoli OPC Customization and Tuning, Controlling Access to Tivoli OPC | using the Tivoli Job Scheduling Console, for information on how to get the RACF | user ID.
| Permitting Access to the Controller through the Tivoli Job | Scheduling Console | If you use Tivoli Job Scheduling Console, you can control access to the controller | through the security functions of both Tivoli Framework and Tivoli OPC. Ensure | that you consider both these environments when you update RACF. Refer to Tivoli | OPC Customization and Tuning for more information about controlling access to | Tivoli OPC through the Tivoli Job Scheduling Console.
Authorizing Tivoli OPC as a Job Submitter If your system has RACF Version 1 Release 9 or later and JES2 or JES3 Version 3 Release 1 Modification Level 3 or later, consider the following resource classes when implementing security for Tivoli OPC. The examples assume that the RACF user for the Tivoli OPC address space is OPCAPPL, which is the name specified in the started-procedure table. JESJOBS If your installation has activated the JESJOBS class, you must permit Tivoli OPC to submit all jobs that are defined in the current plan. One way of doing this is to permit Tivoli OPC to submit all jobs. You can do this by: 1. Defining the submit resource: RDEFINE JESJOBS SUBMIT.ᑍ.ᑍ.ᑍ UACC(NONE) OWNER(OPCAPPL) 2. Authorizing Tivoli OPC: PERMIT SUBMIT.ᑍ.ᑍ.ᑍ CLASS(JESJOBS) ID(OPCAPPL) ACC(READ) SURROGAT A surrogate job submission occurs when all the following conditions are met: 1. USER=xxxx is specified on the job card of the submitted job. 2. The xxxx is not the same as the submitting (RACF) user. 3. No password is specified on the job card. If you use the job-submit exit (EQQUX001) to return a submitting user in the RUSER field and this is the only reason you use this exit, you can replace it with surrogate job submission. To do this, you must activate the SURROGAT resource class. You must also authorize Tivoli OPC to submit jobs for a particular RACF user or user group. The following example demonstrates how you could use surrogate job submission. The example assumes that the job Tivoli OPC will submit contains USER=APLUSER on the job card. To permit Tivoli OPC to submit this job, perform the following steps: 1. Activate the surrogate class:
Chapter 4. Installing Tivoli OPC 65 Installing Tivoli OPC
SETROPTS CLASSACT(SURROGAT) 2. Define the submit resource: RDEFINE SURROGAT APLUSER.SUBMIT UACC(NONE) OWNER(APLUSER) 3. Authorize Tivoli OPC: PERMIT APLUSER.SUBMIT CLASS(SURROGAT) ID(OPCAPPL) ACC(READ)
If the PRIVILEGED or TRUSTED attribute is set in the Started Procedure Table (SPT) entry for Tivoli OPC, then Tivoli OPC is authorized to submit jobs under any user regardless of what is defined in the resource rules.
For further information, refer to RACF Administrator's Guide.
Authorizing Tivoli OPC to Issue JES Commands If your system has RACF Version 1 Release 9 or later, and JES2 or JES3 Version 3 Release 1 Modification Level 3 or later, consider the following resource classes when implementing security for Tivoli OPC. The examples assume that the RACF user for the Tivoli OPC address space is OPCAPPL, which is the name specified in the started-procedure table. OPERCMDS If the OPERCMDS class is active and you have specified HOLDJOB(YES) or HOLDJOB(USER) for an event writer, the Tivoli OPC address space where the event writer is started must be authorized to issue the JES release command. One method is to permit Tivoli OPC to issue all JES commands. To permit Tivoli OPC to issue JES commands on a JES2 system, perform the following steps: 1. Define the resource: RDEFINE OPERCMDS JES2.ᑍ UACC(NONE) 2. Authorize Tivoli OPC: PERMIT JES2.ᑍ CLASS(OPERCMDS) ID(OPCAPPL) ACC(UPDATE) On a JES3 system, replace JES2.* with JES3.* in the example. Alternatively, you could specify the JES%.* resource name for either a JES2 or JES3 system. If you use Tivoli OPC to schedule started tasks, the Tivoli OPC address space must be authorized to issue the MVS start command. One way of doing this is to permit Tivoli OPC to issue all MVS commands. To permit Tivoli OPC to issue MVS commands, perform the following steps: 1. Define the resource: RDEFINE OPERCMDS MVS.ᑍ UACC(NONE) 2. Authorize Tivoli OPC: PERMIT MVS.ᑍ CLASS(OPERCMDS) ID(OPCAPPL) ACC(UPDATE) Authority to use the MVS start command is also required if you use Hiperbatch support for Tivoli OPC operations. JESSPOOL If the JESSPOOL class is active and you use the Tivoli OPC JCC function, you must authorize Tivoli OPC to access SYSOUT datasets for all jobs in the current plan. One way of doing this is to
66 Tivoli OPC Installation Guide Installing Tivoli OPC
permit Tivoli OPC to access all SYSOUT datasets. To permit Tivoli OPC to access all SYSOUT datasets, perform these steps on each system where the JCC is started: 1. Define the resource: RDEFINE JESSPOOL ᑍ.ᑍ UACC(NONE) 2. Authorize Tivoli OPC: PERMIT ᑍ.ᑍ CLASS(JESSPOOL) ID(OPCAPPL) ACC(ALTER)
If the PRIVILEGED or TRUSTED attribute is set in the Started Procedure Table (SPT) entry for Tivoli OPC, then the address space is authorized to issue any commands and to process spool datasets regardless of what is defined in the resource rules.
For further information, refer to RACF Administrator's Guide.
Allocating Tivoli OPC Data Sets Perform this task for a tracker or a controller. Note: A standby controller uses the same datasets as the controller.
At this stage of the installation of your Tivoli OPC system, you allocate the datasets that your Tivoli OPC JCL procedures refer to. You can create the datasets by using the jobs created by the EQQJOBS installation aid.
If you are using the EQQJOBS installation aid, you will already have generated several members in the output library that you specified. Members EQQPCS01 and EQQPCS02 contain JCL to allocate all Tivoli OPC datasets, tailored with the values you entered in the dialog. EQQPCS01 allocates datasets that need to be unique within the sysplex. EQQPCS02 allocates datasets that need to be unique to each MVS image in the sysplex. EQQPCS03 generates a job that allocates VSAM copy datasets. If you do not have a sysplex environment, run EQQPCS01 and EQQPCS02 on the system where the controller will run. You can tailor the EQQPCS01 and EQQPCS02 members further to remove datasets that you do not need.
Consider carefully where Tivoli OPC datasets are allocated in your production environment. Some datasets can be highly active. Avoid placing these datasets on DASD volumes with high activity because this can result in poor performance due to contention. Also consider the ability to recover datasets if a DASD volume becomes unusable. If you place all your Tivoli OPC datasets on the same volume, you must recover many datasets before you can continue your Tivoli OPC service. Tivoli OPC Customization and Tuning describes recovery of Tivoli OPC datasets in detail.
The space to allocate for your datasets depends upon the workload at your installation. It is difficult to give precise figures for the amount of space you will need. The space allocated by the sample JCL should give you enough space to at least get started. These amounts will be enough for the Tivoli OPC service for many installations. Use Table 26 on page 69 as a guide to allocate space for VSAM datasets.
The following sections describe the Tivoli OPC datasets and include examples of the JCL needed to create them.
Chapter 4. Installing Tivoli OPC 67 Installing Tivoli OPC
“Required Data Sets” on page 83 contains a table that associates controller, tracker, and server tasks with the datasets allocated by EQQPCS01 and EQQPCS02.
Allocating the VSAM Data Sets Perform this task if you are installing a controller.
Table 25 shows the Tivoli OPC VSAM datasets and their characteristics. The JCL procedure for the controller uses all of these datasets except for EQQLDDS and EQQLTBKP, which are used only in the planning batch jobs. Allocate all these VSAM datasets for a controller.
Table 25. Tivoli OPC VSAM Datasets Sample ddname Record Attributes Share Keys Record Dataset type option size EQQPCS01 EQQADDS KSDS UNIQUE 3 25 0 1000 Application SPANNED 131072 description EQQPCS01 EQQCP1DS KSDS REUSE 3 19 0 200 Current plan 1 NSPND 32000 EQQPCS01 EQQCP2DS KSDS REUSE 3 19 0 200 Current plan 2 NSPND 32000 EQQPCS01 EQQCXDS KSDS REUSE 3 64 0 500 Current plan NSPND 32000 extension EQQPCS01 EQQJS1DS KSDS REUSE 3 28 0 800 JCL repository 1 SPANNED 180000 EQQPCS01 EQQJS2DS KSDS REUSE 3 28 0 800 JCL repository 2 SPANNED 180000 EQQPCS01 EQQLDDS KSDS REUSE 2 28 0 440 Long-term-plan SPANNED 131072 work EQQPCS01 EQQLTBKP KSDS REUSE 3 28 0 200 Long-term-plan SPANNED 131072 backup EQQPCS01 EQQLTDS KSDS REUSE 3 28 0 200 Long-term plan SPANNED 131072 EQQPCS01 EQQNCPDS KSDS REUSE 3 19 0 200 New current plan NSPND 32000 EQQPCS01 EQQNCXDS KSDS REUSE 3 64 0 500 New current plan NSPND 32000 extension EQQPCS01 EQQOIDS KSDS UNIQUE 3 28 0 800 Operator NSPND 32000 instruction EQQPCS01 EQQRDDS KSDS UNIQUE 3 64 0 400 Special resource NSPND 32000 descriptions EQQPCS01 EQQSIDS KSDS UNIQUE 3 64 0 110 Side information NSPND 220 file: ETT and configuration information EQQPCS01 EQQWSDS KSDS UNIQUE 3 10 0 100 Workstation, NSPND 32000 calendar, and period descriptions.
68 Tivoli OPC Installation Guide Installing Tivoli OPC
You can allocate the VSAM datasets by submitting the EQQPCS01 job. This job allocates the datasets in Table 25 on page 68. Alternatively, you can allocate one or more of the VSAM datasets by running a job like this:
Allocating a VSAM dataset //ALOCVSAM JOB STATEMENT PARAMETERS //ᑍ------ᑍ //ᑍ ALLOCATE AN OPC/ESA VSAM DATASET ᑍ //ᑍ------ᑍ //ALLOC EXEC PGM=IDCAMS,REGION=512K //SYSPRINT DD SYSOUT=Q //EQQVOL1 DD DISP=OLD,VOL=SER=volser,UNIT=339ð //SYSIN DD ᑍ DEFINE + CLUSTER ( + NAME('OPC.INST.AD') UNIQUE + SPANNED + SHR(3) VOL(volser) CYLINDERS(2 2) + )+ DATA ( + NAME('OPC.INST.ADDATA') + KEYS(25 ð) RECORDSIZE(1ððð 132ð72) + )+ INDEX ( + NAME('OPC.INST.ADINDEX') + ) /ᑍ
This example allocates the application description database.
You can allocate VSAM datasets on different device types.
Allocate enough space for your datasets, depending upon the amount of work Tivoli OPC processes at your installation. You can use Table 26 as a guide to allocate space for VSAM datasets.
Table 26 (Page 1 of 3). Calculations of VSAM Dataset Size Size in bytes is total of: Dataset Number of Multiplied by Application description Application and group definitions 208 (EQQADDS) Run cycles 120 Offsets 3 Operations 110 Internal dependencies 16 External dependencies 84 Special resources 64 Variable tables 98 Variables 476 Variable dependencies 88
Chapter 4. Installing Tivoli OPC 69 Installing Tivoli OPC
Table 26 (Page 2 of 3). Calculations of VSAM Dataset Size Size in bytes is total of: Dataset Number of Multiplied by Current plan Header record (one only) 188 (EQQCPnDS) Workstations 212 Workstation open intervals 48 Workstation access method data 72 Occurrences 270 Operations 328 Dependencies 14 Special resource references 64 Jobs 116 Executed steps 20 Print operations 20 Unique application names 64 Operations currently in error 264 Reruns of an operation 264 Potential predecessor occurrences 32 Potential successor occurrences 24 Operations for which CM actions are stored 134 ddnames stored for CM operations 28 Dataset names stored for CM operations 104 Operations for which job log information has been collected 107 JCL repository Number of jobs and started tasks 80 (EQQJSnDS) Total lines of JCL 80 Operations for which job log information has been collected 107 Total lines of job log information 143 Note: As a base, calculate a figure for all your jobs and started tasks controlled by Tivoli OPC. Add to this figure the expected space required for jobs and started tasks in the current plan. Long-term plan Header record (one only) 92 (EQQLTDS) Occurrences 160 External dependencies 35 Operations changed in the LTP dialog 58 Operator instruction Instructions 78 (EQQOIDS) Instruction lines 72 Special resource Resource definitions 216 database Defined intervals 48 (EQQRDDS) Entries in the WS connect table 8 Side information file ETT requests 128 (EQQSIDS)
70 Tivoli OPC Installation Guide Installing Tivoli OPC
Table 26 (Page 3 of 3). Calculations of VSAM Dataset Size Size in bytes is total of: Dataset Number of Multiplied by Workstation/calendar Calendars 96 (EQQWSDS) Calendar dates 52 Periods 94 Period origin dates 6 Workstation closed dates 80 Workstations 124 Workstation access method data 72 Interval dates 52 Intervals 32 Note: 1. Use the current plan dataset calculation (EQQCPnDS) for the new current plan dataset (EQQNCPDS). 2. Use the long-term-plan dataset calculation (EQQLTDS) for the long-term-plan work dataset (EQQLDDS) and the long-term-plan backup (EQQLTBKP). 3. Use the special resource database calculation (EQQRDDS) for the current plan extension dataset (EQQCXDS) and the new current plan extension (EQQNCXDS).
Consider the following information when allocating VSAM datasets.
Application Description Dataset (EQQADDS) The application description dataset contains application descriptions and JCL variable tables. This dataset is allocated as a spanned dataset by EQQPCS01. It has a maximum record size of 131 072. This allocation limits the variable definitions in a variable table to 275 (131 072/476 = 275), provided there are no variable dependencies. If you also use variable dependencies, the number of variables in a JCL variable table is less than 275.
If you will use a greater number of variable definitions in a variable table, allocate the application description dataset with a greater record size. To calculate how great the record size should be, use this method: LRECL = 86 + (maximum number of variables in one table ᑍ 476) + (number of variable dependencies ᑍ 88)
where 86 is the length of the header record, 476 is the length of each variable record and 88 is the length of each variable dependency record.
Current Plan Datasets (EQQCPnDS) The current plan VSAM files are opened and closed many times by Tivoli OPC during normal processing. If Tivoli OPC is unable to open one of the files, for example if the file is already opened by another job or TSO user, the normal mode manager (NMM), is terminated. The NMM issues message EQQN027E which reports the reason for the unexpected termination. You can issue a MODIFY command to restart the NMM subtask.
It is recommended that you do not access the current plan files from outside the Tivoli OPC address space. Backups of current plan information should be taken from the new current plan (EQQNCPDS). You should shutdown the controller address space if full-pack backups are taken of the volumes where the datasets reside.
Chapter 4. Installing Tivoli OPC 71 Installing Tivoli OPC
JCL Repository Datasets (EQQJSnDS) Take special care when allocating the JCL repository datasets. The following information describes the allocation and use of these datasets.
Tivoli OPC maintains its own copy of JCL in the JCL repository dataset for every job that it submits in the current plan. Tivoli OPC uses a primary and alternate dataset for the JCL repository, EQQJS1DS and EQQJS2DS. It reorganizes the JCL repository dataset that is in use by copying it to the alternate dataset and then switching over to use the newly copied dataset. The value you specify on the MAXJSFILE keyword defines whether the JCL repository should be automatically copied and determines how often the automatic copy process should occur.
Use the EQQPCS01 sample job created by the EQQJOBS installation aid to allocate the JS datasets. This job allocates the JS datasets with the SPANNED attribute and maximum record size 180 000. This limits the maximum number of JCL statements to 2 249 for any one job. If you run jobs with a greater number of JCL statements, increase the record size. Calculate the required record size, in bytes, by multiplying the number of JCL statements in your largest job by 80, and add an extra 80 bytes for the header record. If you define your JS file without SPANNED, the greatest maximum record size that you can specify is 32 760 bytes. This lets you store a job with up to 408 JCL records. If you define the JS datasets with SPANNED, the maximum record size you can specify is slightly less than a control area (CA). If you use the EQQUX002 exit, the largest job that can be returned by this exit is 3 200 JCL records. In this case, do not allocate the datasets with a record size of more than 256 080 bytes.
If you specify a JOBLOGRETRIEVAL value other than NONE in the JOBOPTS initialization statement for a tracker, Tivoli OPC copies job log information from the job or started task MSGCLASS output to facilitate step-level restart for catalog-managed operations. The job log information is compressed and appended to the job termination event record. When the job log reaches the controller it is stored in the JCL repository, as record type 14. Old job log information is deleted from the JCL repository when the job or started task is next submitted.
Allocating Tivoli OPC Non-VSAM Data Sets Perform this task if you are installing a tracker or a controller.
This section describes the physical sequential (PS) and partitioned (PDS) Tivoli OPC datasets. Table 27 on page 73 shows the Tivoli OPC non-VSAM datasets and their characteristics. Before you allocate the non-VSAM datasets, review the following sections, which contain important information about each of these datasets.
72 Tivoli OPC Installation Guide Installing Tivoli OPC
Table 27. Tivoli OPC Non-VSAM Datasets Sample ddname RECFM LRECL BLKSIZE DSORG Dataset EQQPCS01 – U – 6300 PS CLIST library EQQPCS01 EQQCKPT U – 8200 PS Checkpoint EQQDLnn U – 6300 PS Dual job-tracking-log EQQPCS01 EQQDMSG VBA 84 3120 PS Tivoli OPC diagnostic message and trace EQQPCS02 EQQDUMP FB 80 3120 PS Tivoli OPC diagnostic EQQPCS02 EQQEVDS/ F 100 100 PS Event EQQEVDnn EQQPCS02 EQQINCWK FB 80 3120 PS JCC incident work EQQPCS01 EQQJBLIB FB 80 3120 PDS Job library EQQPCS01 EQQJCLIB FB 80 3120 PDS JCC message table EQQPCS01 EQQJTARC U – 6300 PS Job-tracking archive EQQPCS01 EQQJTnn U – 6300 PS Job-tracking-log EQQPCS02 EQQMLOG VBA 125 1632 PS Message log EQQPCS01 EQQPARM FB 80 3120 PDS Initialization-statement library EQQPCS01 EQQPRLIB FB 80 3120 PDS Automatic-recovery-procedure library EQQPCS01 EQQSTC FB 80 3120 PDS Started-task submit EQQPCS01 EQQSUDS/ F 820 820 PS Submit/release user-defined – EQQYPARM PDS/PS PIF EQQPCS01 SYSMDUMP F 4160 4160 PS System dump dataset EQQPCS02 – – FB 80 3120 PS Job-completion-checker incident log
Chapter 4. Installing Tivoli OPC 73 Installing Tivoli OPC
You can allocate these datasets using the EQQPCS01 and EQQPCS02 members that are generated by the EQQJOBS installation aid. | Note: The data sets cannot be defined as compressed SMS data sets. If you have not tailored the members as described on page 67, you can allocate a partitioned dataset by running a job like this:
Allocating a Tivoli OPC partitioned dataset //ALLOCPDS JOB STATEMENT PARAMETERS //ᑍ------ᑍ //ᑍ ALLOCATE AN OPC/ESA PARTITIONED DATASET ᑍ //ᑍ------ᑍ //ALLOC EXEC PGM=IEFBR14 //SYSUT1 DD DSN=OPCESA.INST.EQQSTC, // DISP=(,CATLG), // VOL=SER=volser, // SPACE=(TRK,(5,ð,1)), // UNIT=338ð, // DCB=(RECFM=FB,LRECL=8ð,BLKSIZE=312ð)
This example allocates a started-task-submit dataset (EQQSTC).
To allocate a Tivoli OPC sequential dataset, you can run a job like the this:
Allocating a Tivoli OPC sequential dataset //ALLOCPS JOB STATEMENT PARAMETERS //ᑍ------ᑍ //ᑍ ALLOCATE AN OPC/ESA SEQUENTIAL DATASET ᑍ //ᑍ------ᑍ //ALLOC EXEC PGM=IEBGENER //SYSPRINT DD DUMMY //SYSUT1 DD DUMMY,DCB=(RECFM=F,BLKSIZE=1ðð,LRECL=1ðð) //SYSUT2 DD DSN=OPCESA.INST.EVENTS, // DISP=(NEW,CATLG), // UNIT=338ð, // VOL=SER=volser, // SPACE=(CYL,3,,CONTIG), // DCB=(RECFM=F,BLKSIZE=1ðð,LRECL=1ðð,DSORG=PS) //SYSIN DD DUMMY
This example allocates an event dataset (EQQEVDS). The IEBGENER utility ensures that the allocated dataset has an end-of-file marker in it. Note: If you allocate Tivoli OPC datasets using your own jobs, ensure that they have an end-of-file marker in them.
The following sections describe the Tivoli OPC non-VSAM datasets. They contain important information to consider when allocating your datasets:
74 Tivoli OPC Installation Guide Installing Tivoli OPC
Internal Reader Dataset (EQQBRDS) When a Tivoli OPC subsystem is used to submit work, specify the internal reader dataset, EQQBRDS, in your started-task procedures. The DD statement must contain the external-writer-dataset name, INTRDR, and the class of the internal reader. The class you specify is used as a default message class for jobs that do not have a MSGCLASS parameter specified on their job cards.
Example internal reader DD statement //EQQBRDS DD SYSOUT=(A,INTRDR)
Checkpoint Dataset (EQQCKPT) Tivoli OPC uses the checkpoint dataset to save the current status of the Tivoli OPC system. If the controller is stopped and then restarted, Tivoli OPC uses the checkpoint dataset to return the Tivoli OPC system to the same state as when it was stopped, ready to continue execution.
Tivoli OPC automatically formats the checkpoint dataset the first time it is used. In its initial state, the checkpoint dataset specifies that a new current plan exists. The new current plan is defined by ddname EQQNCPDS. Tivoli OPC attempts to copy the new plan and make it the current plan. If the copy is successful, Tivoli OPC is fully operational. If the copy is not successful, Tivoli OPC has become active without a current plan.
Attention: A strong relationship exists between the Tivoli OPC checkpoint dataset and the current plan dataset. Ensure that you do not accidentally delete or overwrite the checkpoint dataset.
The space allocation for the dataset must be at least 15 tracks. That allocation can accommodate 1000 workstation destinations.
Diagnostic Datasets (EQQDMSG, EQQDUMP, and SYSMDUMP) Allocate diagnostic datasets for Tivoli OPC address spaces, dialog users, batch jobs, and server.
Diagnostic Message and Trace Dataset (EQQDMSG): You should allocate EQQDMSG for each dialog user. You can allocate EQQDMSG either as a SYSOUT dataset or as a DASD dataset. Usually only a small volume of diagnostic information exists, so an initial allocation of two tracks of DASD should be enough. If EQQDMSG is not defined, output is written to EQQDUMP.
Diagnostic Dataset (EQQDUMP): The tracker, controller, and server write debugging information to diagnostic datasets when validity checking discovers internal error conditions. When diagnostic information is logged, a 3999 user abend normally accompanies it. For service purposes, always include an EQQDUMP DD statement for every Tivoli OPC address space, dialog user, batch job, and server.
Diagnostic datasets are usually allocated as DASD datasets, but they can also be allocated to SYSOUT. Usually only a small volume of diagnostic information exists, so an initial allocation of two tracks on DASD should be enough.
Chapter 4. Installing Tivoli OPC 75 Installing Tivoli OPC
Dump Dataset (SYSMDUMP): EQQPCS02 contains two allocations for the SYSMDUMP dataset. For a Tivoli OPC address space, the dataset is allocated with the low-level qualifier SYSDUMP. Allocate a unique SYSMDUMP dataset for every Tivoli OPC address space. For Tivoli OPC server jobs, SYSMDUMP is allocated with the low-level qualifier SYSDUMPS. EQQPCS01 contains the allocation for the SYSMDUMP dataset for Tivoli OPC batch jobs; this dataset is allocated with the low-level qualifier SYSDUMPB. The Tivoli OPC batch jobs can use the same dataset. It is allocated with a disposition of MOD in the JCL tailored by EQQJOBS.
| Furthermore, SYSMDUMP datasets should be defined with a UACC of UPDATE, | that is, WRITE-ENABLED to all userids under which an OPC-scheduled job might | possibly be submitte. This is because the SUBMIT SUBTASK of the controller or | of the tracker which is submitting a given job may abend while executing under the | OPC user exit EQQUX001 supplied userid (RUSER userid) rather than under the | userid associated with the OPC started task. If this should occur, DUMPTASK may | fail with an ABEND913 if the userid in control does not have WRITE access to the | OPC SYSMDUMP dataset.
Event Dataset (EQQEVDS and EQQEVDnn) Every Tivoli OPC address space requires a unique event dataset. The dataset is device dependent and must have only a primary space allocation. Do NOT allocate any secondary space. The dataset is formatted the first time it is used. Each time you use the dataset, Tivoli OPC keeps a record of where to start. When the last track of the dataset is written, Tivoli OPC starts writing on the first track again. Note: The first time Tivoli OPC is started with a newly allocated event dataset, an SD37 error occurs when Tivoli OPC formats the event dataset. Do not treat this as an error.
The dataset contains records that describe events created by Tivoli OPC job-tracking functions. An event-writer task writes to this dataset; an event-reader task reads from it. The job-submit task also uses the event dataset to checkpoint its activities, using the first record in the dataset (the header record). The submit task in a controller address space takes these checkpoints when the computer workstation is the same system (the workstation destination is blank), so the address space needs the EQQEVDS event dataset allocated even if there is no event writer task. When an event writer task is started in the controller address space, it shares the dataset with the submit task.
The header record contains checkpoint information for up to 13 workstations per destination. If you plan to have more than 13 workstations defined to use a single destination, you can allocate the event dataset with a large logical record length to accommodate the required number. To calculate the record length required, use this formula: LRECL = (No-of-WS-with-this-destination ᑍ 6) + 22
Because the event dataset provides a record of each event, events will not be lost if an event-processing component of Tivoli OPC must be restarted. The submit checkpointing process ensures that submit requests are synchronized with the controller, thereby preventing lost requests caused by communication failures.
Define enough space for a single extent dataset so that it does not wrap around and write over itself before an event is processed. Two cylinders are enough at
76 Tivoli OPC Installation Guide Installing Tivoli OPC
most installations. The space allocation must be at least 2 tracks when the record length is 100. There must be sufficient space in the event dataset to accommodate 100 records. Consider this requirement if you will define the event dataset with a record length greater than 100. For example if you define an LRECL of 15 000, the minimum space allocation is 34 tracks, which equates to 102 records and an event dataset that would wrap around very quickly in most installations.
To aid performance, place the event dataset on a device that has low activity. If you run programs that use the RESERVE macro, try to allocate the event dataset on a device that is not reserved or where only short reserves are taken. The reserve period must be less than 5 minutes.
If you will use the catalog management function, consider allocating the event dataset with a greater LRECL value than that in Table 27 on page 73. This will improve performance because input/output (I/O) operations will be reduced because fewer continuation (type NN) events will be created. Continuation events are created to record dataset information and to record the job log for jobs and started tasks that are candidates for catalog management. You can specify 0, or a value from 100 to 32 000 bytes for LRECL. Any other value will cause the event writer to end, and message EQQW053E will be written to the message log. If you do not specify a value for LRECL or specify 0, the dataset will be forced to have an LRECL of 100 when it is opened by Tivoli OPC. However, the data set must be unblocked: the block size must be equal to the logical record length. If you intend to activate catalog management, use one of the these formulas to estimate the LRECL that you should specify:
Calculating the optimum LRECL LRECL=((NN/EV) ᑍ 2ð) + 1ðð OR LRECL=(4 ᑍ N) + 1ðð
In the first formula, NN is the number of continuation events, and EV is the number of all other events. Event types are found in position 21 of the event records. In the second formula, N is the average number of NN events per job. If your calculation yields a value of less than 110, there will be little or no improvement in performance. In this case, you should specify an LRECL value of 100.
You will probably need to test your system first to get an idea of the number and event types that are created. You can then reallocate the event dataset when you have gathered information about the events created at your installation. But, before you reallocate an event dataset, ensure that the current plan is completely up-to-date. You must also stop the event writer, and any event reader, that uses the dataset.
Attention: Do not move Tivoli OPC event datasets once they are allocated. They contain device-dependent information and cannot be copied from one device type to another, or moved on the same volume. An event dataset that is moved will be reinitialized. This causes all events in the dataset to be lost. If you have DFHSM or a similar product installed, you should specify that Tivoli OPC event datasets are not migrated or moved.
Chapter 4. Installing Tivoli OPC 77 Installing Tivoli OPC
Job Library Dataset (EQQJBLIB) The job library dataset contains the JCL for the jobs and started tasks that Tivoli OPC will submit. It is required by a controller. If you already have a job library that you will use for Tivoli OPC purposes, specify this dataset on the EQQJBLIB statement. If not, allocate one before you start the controller.
Attention: Allocate the job library dataset with a only primary space allocation. If a secondary allocation is defined and the library goes into an extent when Tivoli OPC is active, you must stop and start Tivoli OPC. Also, do not compress members in this PDS. For example, do not use the ISPF PACK ON command, because Tivoli OPC does not use ISPF services to read it.
| The limitation of allocating the job library data set with only a primary space | allocation is nota applicable for PDSE data sets.
Job-Completion-Checker Datasets You can optionally use the job completion checker (JCC) to scan SYSOUT for jobs and started tasks. Depending on the JCC functions you want to use, allocate at least one of the three datasets associated with the JCC: EQQJCLIB Message table library (Internally generated ddname) Incident log dataset EQQINCWK Incident work file
JCC-Message-Table Library (EQQJCLIB): If the success or failure of a job or started task cannot be determined by system completion codes, the JCC function can be used to scan the SYSOUT created and set an appropriate error code. You determine how the SYSOUT data is scanned by creating JCC message tables. A general message table (EQQGJCCT) must be defined. Job-specific message tables can be created to search for specific data strings in particular jobs. These tables are stored in the PDS with a member name that matches the job name.
Every Tivoli OPC subsystem where you start the JCC task must have access to a message table library. If you want, you can use the same message table library for all Tivoli OPC systems.
If you use the dataset-triggering function, the dataset-selection table (EQQDSLST) must be stored in EQQJCLIB.
| Warning: Allocate the JCC message table data set with only primary space | allocation. The limitation is not applicable for PDSE data sets.
JCC-Incident-Log Dataset: You can optionally use the JCC to write records to an incident log dataset. This dataset is defined by the INCDSN keyword of the JCCOPTS statement.
When scanning SYSOUT datasets, the JCC recognizes events that you define as unusual. If the EQQUX006 exit is loaded by Tivoli OPC, the JCC records these events in the incident log dataset. The incident log dataset can be shared by several JCC tasks executing on the same system or on different systems. The dataset can also be updated manually or even reallocated while the JCC is active. If the JCC is unable to write to the incident log, the incident work dataset is used instead.
78 Tivoli OPC Installation Guide Installing Tivoli OPC
JCC-Incident Work Dataset (EQQINCWK): Occasionally, the JCC cannot allocate the incident log dataset. This can happen if another subsystem or a Tivoli OPC user has already accessed the dataset. In this case, the JCC writes to the incident work file, EQQINCWK, instead. If it is not empty, the work file is copied and emptied each time the incident log dataset is allocated.
Job-Tracking Datasets (EQQJTARC, EQQJTnn, EQQDLnn) Job-tracking datasets are a log of updates to the current plan. They optionally contain audit trail records. Job-tracking datasets comprise: Job-tracking logs (EQQJTnn) Dual job-tracking logs (EQQDLnn) Job-tracking archive (EQQJTARC)
You must allocate EQQJTARC and at least two job-tracking logs (EQQJT01 and EQQJT02) for a controller. The actual number of JT logs that you should allocate is determined by the value that you specify on the JTLOGS keyword of the JTOPTS initialization statement. If you decide to allocate three job-tracking logs, specify the ddnames EQQJT01, EQQJT02, and EQQJT03. If you specified EQQJT01, EQQJT02, and EQQJT04, an error occurs and Tivoli OPC terminates. Tivoli OPC uses the job-tracking logs in turn. When a current plan backup is performed, the active log is appended to EQQJTARC dataset.
The JTLOG keyword default defines five job-tracking logs. It is recommended that you specify at least three job-tracking logs. Job-tracking logs are switched at every current plan backup. If the interval between backups is very low and JTLOGS(2) is specified, the previously used job-tracking log might not have been archived before Tivoli OPC must switch again. If Tivoli OPC cannot switch successfully, the normal-mode-manager (NMM) subtask is automatically shut down—preventing further updates to the current plan.
You can optionally allocate dual JT logs. These logs are identified by the EQQDLnn ddnames in the controller started-task JCL. Allocate the same number of dual JT logs as JT logs. The numeric suffixes, nn, must be the same as for the JT logs, because Tivoli OPC uses the logs with the same number: EQQJT01 and EQQDL01, EQQJT02 and EQQDL02, and so on. Tivoli OPC writes job-tracking information to both logs, so that if the active JT log is lost it can be restored from the dual log, and Tivoli OPC can be restarted without losing any events. To achieve the maximum benefit from dual JT logs, you should allocate them: With the same attributes as the JT logs With at least the same amount of space as the JT logs On alternate I/O paths and physical volumes than their corresponding JT logs Tivoli OPC will try to use dual JT logs if you specify DUAL(YES) on the JTOPTS initialization statement of a controller.
The job-tracking-archive dataset accumulates all job-tracking data between successive creations of a new current plan (NCP). So allocate EQQJTARC with enough space for all job-tracking records that are created between daily planning jobs; that is, extend or replan of the current plan. When the daily planning batch job is run, the active job-tracking log is appended to EQQJTARC, and the JT log is switched. The archive log, EQQJTARC, is then copied to the track log dataset referenced by the EQQTROUT ddname during the daily planning process. When Tivoli OPC takes over the NCP, the archive dataset is emptied.
Chapter 4. Installing Tivoli OPC 79 Installing Tivoli OPC
Tivoli OPC recovery procedures that use the job-tracking datasets are described in Tivoli OPC Customization and Tuning.
Message Log Dataset (EQQMLOG) The message log dataset can be written to SYSOUT or a dataset. The data control block (DCB) for this dataset is defined by Tivoli OPC as follows:
EQQMLOG DCB attributes DCB=(RECFM=VBA,LRECL=125,BLKSIZE=1632)
If the message log dataset becomes full during initialization, or when a subtask is restarted, Tivoli OPC will abend with error code SD37. In either case, you must stop Tivoli OPC and reallocate the message log dataset with more space. In all other circumstances, if the dataset fills, Tivoli OPC redirects messages to the system log instead.
EQQPCS02 contains two allocations for the EQQMLOG dataset. For a Tivoli OPC address space, the dataset is allocated with the low-level qualifier MLOG. For Tivoli OPC Server jobs, the dataset is allocated with the low-level qualifier MLOGS. Note: If you allocate the message log dataset on DASD, define a different dataset for Tivoli OPC batch programs from the one used by the Tivoli OPC address space and the one used by the Tivoli OPC server. The dataset cannot be shared.
Parameter Library (EQQPARM) Each Tivoli OPC subsystem reads members of a parameter library when it is | started. Parameter library members (residing in library extent), that have been | created, cannot be accessed after they have been opened. To avoid this problem, | the data set that defines the EQQPARM library should be allocated without any | secondary extents. The limitation is not applicable for PDSE data sets. The library contains initialization statements that define run-time options for the subsystem. Allocate at least one parameter library for your Tivoli OPC systems. You can keep the parameters for all your Tivoli OPC subsystems in one library, as long as it resides on a DASD volume that is accessible by all systems.
PIF Parameter Dataset (EQQYPARM) Allocate the PIF parameter dataset if you intend to use a programming interface to Tivoli OPC. The dataset can be sequential or partitioned. In the PIF parameter file you specify how requests from the programming interface should be processed by Tivoli OPC. By defining an INIT initialization statement in the PIF parameter dataset, you override the global settings of the INTFOPTS statement.
The initialization statements are described in Tivoli OPC Customization and Tuning.
Automatic-Recovery-Procedure Library (EQQPRLIB) Allocate a dataset for the automatic-recovery-procedure library if you intend to use the Tivoli OPC automatic-recovery function. The library is used by the ADDPROC JCL rebuild parameter of the JCL recovery statement. This parameter lets you include JCL procedures in a failing job or started task before it is restarted.
80 Tivoli OPC Installation Guide Installing Tivoli OPC
Started-Task-Submit Dataset (EQQSTC) The started-task-submit dataset is used by Tivoli OPC to temporarily store JCL when a started task is to be started. Use these attributes for this dataset:
EQQSTC attributes SPACE=(TRK,(5,ð,1)), DCB=(RECFM=FB,LRECL=8ð,BLKSIZE=312ð)
Include an EQQSTC in the JES PROCLIB concatenation on each system where Tivoli OPC schedules started-task operations. The dataset is used as a temporary staging area for the started-task JCL procedure. When the start command has been issued for the task and control for the task has passed to JES, Tivoli OPC deletes the JCL by resetting the PDS. This means that you never need to compress the dataset. For more information, see “Implementing Support for Started-Task Operations” on page 82. Note: Tivoli OPC does not support partitioned dataset extended (PDSE) libraries for a started-task-submit dataset.
Submit/Release Dataset (EQQSUDS) The submit/release dataset is device dependent and must have only a primary space allocation. Do not allocate any secondary space. The dataset is formatted the first time it is used. Each time you use the dataset, Tivoli OPC keeps a record of where to start. When the last track of the dataset is written, Tivoli OPC starts writing on the first track again.
Two cylinders are enough at most installations. Note: The first time Tivoli OPC is started with a newly allocated submit/release dataset, an SD37 error occurs when Tivoli OPC formats the dataset. Expect this, do not treat it as an error.
Attention: Do not move Tivoli OPC submit/release datasets once they are allocated. They contain device-dependent information and cannot be copied from one device type to another, or moved on the same volume. A submit/release dataset that is moved will be reinitialized. This causes all information in the dataset to be lost. If you have DFHSM or a similar product installed, define Tivoli OPC submit/release datasets so that they are not migrated or moved.
| Allocating Tivoli OPC Data Store Data Sets | Perform this task for each Data Store you are installing.
| At this stage of your installation, use the EQQPCS04 member generated by the | EQQJOBS installation aid. It is contained in the output library specified on the | Create Data Store samples panel (EQQJOBS5). Submit the EQQPCS04 job to | define and initialize the Data Store VSAM files and initialize them. They are listed | and described in the following table:
Chapter 4. Installing Tivoli OPC 81 Installing Tivoli OPC
| Table 28. Data Store VSAM Datasets | Sample ddname Rec. Type Attributes Share Keys Record Dataset | Option Size | EQQPCS04 EQQUDFxx LINEAR N/A 2 , 3 N/A N/A Data files | EQQPCS04 EQQPKIxx KSDS UNIQUE 2 , 3 34 0 77 77 Primary | INDEXED Index
| Refer to Customization and Tuning, for information about how to estimate the size | of the Data Store VSAM files.
| Creating JCL Procedures for Tivoli OPC Address Spaces Perform this task for a tracker, controller, or standby controller.
| You must define a JCL procedure or batch job for each Tivoli OPC address space.
| Refer to “Defining Tivoli OPC Subsystems” on page 51 for details.
The EQQJOBS dialog generates several members in the output library that you specified. Members EQQOPCA, EQQOPCB, and EQQOPCS contain started-task JCL that is tailored with the values you entered in the dialog. Tailor these members further, according to the datasets you require. Alternatively, you can copy a member from the SEQQSAMP library to one of your own libraries, and tailor it manually.
If you create a new library for your Tivoli OPC started-task procedures, remember to specify the library in the JES PROCLIB concatenation. Then you must restart JES to include the new library.
If you prefer, you can run Tivoli OPC as a batch job rather than as a started task. Here, the JCL can reside in any library and will require a job card—besides the JCL requirements in Table 29 on page 83.
Implementing Support for Started-Task Operations The JCL procedures for started-task operations started by Tivoli OPC must be stored in a PDS concatenated on the EQQJBLIB ddname. You can include existing datasets, such as SYS1.PROCLIB, if you prefer. Preparation, tailoring, and variable substitution are handled the same way as for batch job operations. When a started-task operation is started by Tivoli OPC, the JCL procedure is written to the started-task-submit dataset (EQQSTC) on the system where the operation is to be run. Tivoli OPC issues a START command for this procedure and then removes the JCL procedure from the EQQSTC dataset.
JES2 users should specify the started-task-submit dataset on the PROCnn DD statement of the JES2 JCL procedure on each MVS system. The suffix nn is the value specified for the PROCLIB parameter of the STCCLASS statement in JES2PARM. To ensure that the correct version of the JCL procedure is started, place the EQQSTC dataset first in the concatenation.
JES3 users should specify the started-task-submit dataset on the IATPLBnn DD statement of the JES3 global system. The suffix nn is the value specified in the JES3 standards parameter STCPROC. To ensure that the correct JCL procedure
82 Tivoli OPC Installation Guide Installing Tivoli OPC
will be started, place the EQQSTC dataset first in the concatenation. For each submit task that is running on a JES3 local system in the JES3 complex, also include that dataset in the JES3 global concatenation.
Notes: 1. To include EQQSTC, you must restart JES. 2. Do not use the BLDL parameter of the JES3 PROC statement to specify the procedure name of a started task that is to be scheduled by Tivoli OPC. The EQQSTC dataset can be shared by Tivoli OPC subsystems that execute on the same MVS/ESA image. If you use global resource serialization (GRS), the EQQSTC dataset can be shared by all MVS/ESA systems defined in the GRS ring if you propagate requests for the resource. To propagate the resource requests to all systems in the ring, define the resource SYSZDRK.datasetname in the SYSTEM inclusion RNL of the GRSRNLnn member of SYS1.PARMLIB. Refer to MVS/ESA Initialization and Tuning Reference for more information about defining the GRS resource name list.
Required Data Sets Table 29 shows the datasets required by a controller and a tracker. Include the datasets in your JCL procedures as indicated in this table.
Table 29 (Page 1 of 2). Tivoli OPC Required Datasets
Required by
ddname Controller Tracker Server Defines EQQADDS √ Application descriptions and JCL variable tables EQQBRDS √ √ A JES internal-reader EQQCKPT √ Checkpoint dataset EQQCP1DS √ Primary current plan EQQCP2DS √ Alternate current plan EQQCXDS √ Current plan extension EQQEVDS √ √ Event dataset for the submit checkpointing function and for the event-writer task EQQJBLIB √ JCL PDS libraries EQQJS1DS √ Primary JCL repository EQQJS2DS √ Alternate JCL repository EQQJTARC √ Job-tracking archive EQQJTnn √ Job-tracking logs EQQLTDS √ Long-term plan EQQMLIB √ √ √ Message library EQQMLOG √ √ √ Output message log EQQNCPDS √ New current plan EQQNCXDS √ New current plan extension EQQOIDS √ Operator instructions
Chapter 4. Installing Tivoli OPC 83 Installing Tivoli OPC
Table 29 (Page 2 of 2). Tivoli OPC Required Datasets
Required by
ddname Controller Tracker Server Defines EQQPARM √ √ √ Parameter library EQQRDDS √ Special resource descriptions EQQSIDS √ Side information; ETT criteria and configuration data EQQWSDS √ Workstation, calendar and period descriptions
Notes: 1. The datasets that are required for a controller are also required for a standby controller. 2. The number of job-tracking-log datasets to include depends on the value that you specify in the JTLOGS keyword of the JTOPTS initialization statement. Specify at least 3 job-tracking logs. The default value is 5. 3. You must specify EQQEVDS for a controller even if an event writer is not started in the controller address space. The EQQEVDS dataset is used for submit checkpointing. It can be the same dataset that is used by an event-writer function. Use a unique EQQEVDS for each Tivoli OPC address space. | 4. In order to set the TCP/IP task up correctly, you need to change the OPC start | procedure to include the C runtime libraries (CEE.SCEERUN in the STEPLIB | DD statement). | If you have multiple TCP/IP stacks, or if the name you used for the procedure | that started up the TCPIP address space was not the default (TCPIP), then you | need to change the OPC start procedure to include the SYSTCPD DD card to | point to a data set containing the TCPIPJOBNAME parameter. | The standard method to determine the connecting TCP/IP image is: | Connect the TCP/IP specified by TCPIPJOBNAME in the active | TCPIP.DATA | Locate TCPIP.DATA using the SYSTCPD DD card.
84 Tivoli OPC Installation Guide Installing Tivoli OPC
Optional Data Sets Table 30 shows the datasets that you can optionally include in your Tivoli OPC JCL procedures. Specify these datasets only if you want to use the function that they are associated with.
Table 30. Tivoli OPC Optional Datasets
Can be used by
ddname Controller Tracker Server Defines EQQDLnn √ Dual job-tracking logs EQQDUMP √ √ √ Diagnostic dump output EQQEVDnn √ √ Event dataset for an event-reader task EQQINCWK √ JCC incident work file EQQJCLIB √ JCC library for message tables and for dataset triggering selection table EQQPRLIB √ √ Automatic-recovery procedures EQQSTC √ √ Started-task-submit dataset EQQSUDS √ Submit/release dataset for an event-writer task STEPLIB √ √ √ Load-module library SYSMDUMP √ √ √ Dump dataset user-defined √ Submit/release dataset for the controller submit task Note: 1. The optional datasets that you specify for a controller must also be specified for a standby controller. 2. If you use dual job-tracking, the number of dual job-tracking logs (EQQDLnn) must be the same as the number of job-tracking logs (EQQJTnn). 3. Include EQQDUMP and SYSMDUMP for diagnostic purposes. 4. The EQQEVDnn ddname identifies the event dataset for an event-reader task. The nn value is the sequence number specified in the ERSEQNO keyword of the event reader that will process this dataset. It is always a 2-digit number. That is, if the sequence number is less than 10, a leading 0 must be added. 5. Specify the EQQSTC dataset if you use Tivoli OPC to schedule started-task operations. 6. Use the standard JCL naming conventions for each user-defined ddname; that is, 1–8 alphanumeric or national characters, of which the first character must be alphabetic or national. 7. The submit/release dataset is identified by a controller, with a user-defined ddname. The same name must appear in the procedure JCL, the DASD keyword of the ROUTOPTS statement, and the destination field of the workstation representing the system that work is to be sent to. The same dataset is identified in a tracker, by the EQQSUDS ddname.
Chapter 4. Installing Tivoli OPC 85 Installing Tivoli OPC
Defining the Initialization Statements Perform this task for a tracker, controller, or standby controller.
In this step of your Tivoli OPC installation, you define the initialization statements.
When Tivoli OPC starts executing, it reads the Tivoli OPC parameter library to determine initialization options and parameters. The parameter library is specified by the EQQPARM DD statement in the Tivoli OPC started-task procedure.
The PARM parameter on the EXEC JCL statement specifies the name of a member in the Tivoli OPC parameter library that contains the initialization statements. This member can contain these initialization statements: ALERTS AUDIT AUTHDEF DBCSOPTS EXITS INTFOPTS INCLUDE JOBOPTS JTOPTS NOERROR OPCOPTS RESOPTS ROUTOPTS TRROPTS XCFOPTS These statements are used to define execution-time options and parameters for Tivoli OPC.
The OPCOPTS statement defines additional member names that are used to specify run-time parameters for the possible subtasks. These members can contain these initialization statements: AROPTS ERDROPTS EWTROPTS JCCOPTS RODMOPTS Each of these is kept in its own member in the library.
The BATCHOPT statement defines run-time options for Tivoli OPC batch jobs. Create the BATCHOPT statement in its own member in the library. The RESOURCE statement must be defined in the same member as the BATCHOPT statement.
The SERVOPTS statement defines run-time options for Tivoli OPC servers. Create the SERVOPTS statement in its own member in the library.
The initialization statements that you should define depend on the functions of Tivoli OPC that you want to use. For details about how to define initialization statements refer to Tivoli OPC Customization and Tuning.
86 Tivoli OPC Installation Guide Installing Tivoli OPC
Creating the DB2 Database Perform this task for a controller or standby controller.
In this optional step, required only if you need the history function, you create the DB2 database, tables, and indexes. You can use the history function to rerun operations after they have completed and are no longer in the current plan. When the history function is active, details about completed operations are copied to the DB2 database when you extend the current plan, and remain in the database for a period that you specify. Refer to Controlling and Monitoring the Workload for a description of how to use the history function, and to Customization and Tuning for a description of the necessary initialization parameters.
Edit and run the supplied sample job EQQINIDB. This job: 1. Binds the DB2 plan. 2. Grants authorities. 3. Creates the database. 4. Creates the tablespace. 5. Creates the tables and indexes.
Save the output of this job, because this lists the objects that were created, with their parameters. Ensure that you bind the plan and grant the necessary authorities after applying service to Tivoli OPC.
Setting Up the ISPF Environment Perform this task if you are installing the OPC dialogs.
Because Tivoli OPC dialogs run under ISPF, you must set up an ISPF environment. If you are not familiar with ISPF dialogs, refer to ISPF Guide and Reference and ISPF Examples.
To set up your ISPF environment, perform these steps: 1. Set up the Tivoli OPC CLIST library. 2. Set up the ISPF tables. 3. Allocate ISPF and Tivoli OPC datasets to the TSO session. 4. Invoke the Tivoli OPC dialog.
These steps are described in the following sections.
Setting Up the Tivoli OPC CLIST Library When you ran the SMP/E apply job, the Tivoli OPC CLIST library was copied to a dataset allocated to ddname SEQQCLIB. Allocate this dataset to the SYSPROC ddname of the TSO logon procedure JCL. This library includes the EQQXSUBC CLIST, which is used by the Tivoli OPC dialog when a user requests a Tivoli OPC background batch job to be submitted.
Chapter 4. Installing Tivoli OPC 87 Installing Tivoli OPC
Setting Up the ISPF Tables These are the tables in the SEQQTBL0 library that you must allocate to the ISPF table library (ISPTLIB). These are: EQQACMDS ISPF command table EQQAEDIT Default ISPF edit profile EQQELDEF Default ended-in-error-list layouts EQQEVERT Ended-in-error-list variable-entity read table EQQLUDEF Default dialog connect table EQQRLDEF Default ready-list layouts EQQXVART Dialog field definitions
If you use the ISPF command table EQQACMDS, invoke Tivoli OPC as a separate ISPF application with the name EQQA. “Invoking the Tivoli OPC Dialog” on page 90 describes this in more detail. If you want to use a different ISPF application name, for example EQQB, create a command table with the name EQQBCMDS.
If necessary, you can modify or create an ISPF command table, using ISPF/PDF option 3.9. Note that ISPF/PDF option 3.9 writes the created or modified table to the dataset allocated to the ISPTABL.
Setting Up the Default Dialog–Controller Connection Table Table EQQLUDEF contains values used when establishing the connection between the OPC dialog user and the OPC controller. These are default values set initially for your installation by the system programmer. Individual users can then modify the values to suit their requirements. Modify the table, adding the following information: The names of the controllers in your installation When a controller is accessed remotely, the combination of the controller name and the LU name of a server set up to communicate with it The set of dialog–controller connections that are to be available to all dialog users
When a user enters OPC dialog 0.1, OPC first tries to read the connection table EQQLUOUT in the ISPF profile library ISPPROF. If it cannot find the table, it reads the default connection table EQQLUDEF from the ISPTLIB allocation.
When a user modifies the connection table (through OPC dialog option 0.1) the changes are written to the EQQLUOUT table of ISPPROF.
To change the distributed EQQLUDEF table: 1. Choose OPC dialog option 0.1. 2. Set up the proper dialog–controller connections for the installation. 3. Copy the connection table EQQLUOUT from your ISPF profile library to the OPC table library allocated to ISPTLIB, renaming the copy to the default connection table name EQQLUDEF.
88 Tivoli OPC Installation Guide Installing Tivoli OPC
Setting Up List Tables and Graphical Attribute Tables The ISPF tables for list layouts, EQQRLDEF and EQQELDEF, are the default tables displayed for all Tivoli OPC dialog users in your installation. They can be modified to suit an individual user's requirements or you can create new defaults for all users in your installation. Modified tables are stored in the user's ISPF profile library under another member name. Tivoli OPC Customization and Tuning describes how to modify the default tables for your installation.
GDDM default values are used for graphical attributes. The defaults can be modified to suit the requirements of an individual user or you can create default values for all users. Modified defaults are stored in the EQQAXGRC member of the ISPF profile dataset.
When setting up these tables for dialog users, keep the following points in mind: When a user requests a graphical display using the GRAPH command, Tivoli OPC first searches through the ISPPROF library for the EQQAXGRC ISPF table. If it cannot find the table there, Tivoli OPC then searches the ISPTLIB library for the table. When a user modifies the graphical display attributes (using the ATTR command from within a Tivoli OPC dialog), the EQQAXGRC ISPF table is written to the ISPPROF library. When a user displays an ended-in-error list, Tivoli OPC first searches for the layout in the EQQELOUT table on ISPPROF. If it cannot find the layout there, Tivoli OPC uses the layout from the EQQELDEF table on ISPTLIB. When a user modifies an ended-in-error list layout, the changes are written to the EQQELOUT table. When a user displays a ready list, Tivoli OPC first searches for the layout in the EQQRLOUT table of ISPPROF. If it cannot find the layout there, Tivoli OPC uses the layout from the EQQRLDEF table on ISPTLIB. When a user modifies a ready list layout, the changes are written to the EQQRLOUT table.
Allocating Dialog Data Sets to Your TSO Session Table 31 describes the ISPF and Tivoli OPC datasets that you must allocate to the TSO session to execute the Tivoli OPC dialog.
Table 31. ISPF and Tivoli OPC Dialog Datasets ddname Tivoli OPC use Created by SYSPROC CLIST library SMP/E run (SEQQCLIB) ISPPROF User-session defaults, read/write Your existing ISPPROF dataset tables ISPPLIB Panel library SMP/E run (SEQQPxxx) ISPMLIB Message library SMP/E run (SEQQMxxx) ISPSLIB Skeleton JCL library EQQJOBS option 2 ISPTLIB Read tables (default) SMP/E run (SEQQTBL0) EQQMLIB Message library SMP/E run (SEQQMxxx)
Chapter 4. Installing Tivoli OPC 89 Installing Tivoli OPC
Notes: 1. The xxx suffix represents the national language version supplied with your distribution tape. 2. If you did not install the Tivoli OPC load modules in a library defined in the LNKLSTnn member of SYS1.PARMLIB, also allocate the Tivoli OPC load-module library to either the STEPLIB or ISPLLIB DD statements. Except for the EQQMINOR module, the Tivoli OPC dialog modules need not run APF-authorized. So if EQQMINOR is not in the LNKLSTnn concatenation, you must copy it to another library so that it can be loaded APF-authorized. 3. Consider allocating EQQDMSG and EQQDUMP to the TSO session for diagnostic purposes. 4. Ensure that the library containing Tivoli OPC batch job skeletons, generated by EQQJOBS, is allocated to the ISPSLIB DD statement. 5. You need the EQQMLIB library to execute the Tivoli OPC TSO commands.
Invoking the Tivoli OPC Dialog The following section outlines ways of invoking the Tivoli OPC dialog.
Using the EQQOPCAC Sample CLIST You can invoke the Tivoli OPC dialog by using the sample CLIST EQQOPCAC. When you run the sample CLIST in TSO READY mode, EQQOPCAC allocates the Tivoli OPC dialog datasets and invokes ISPF with the initial master panel EQQ@MSTR. The EQQ@MSTR panel, which is in the Tivoli OPC panel library, lets you select the applications ISPF/PDF or Tivoli OPC.
Modifying an Existing ISPF Selection Menu You can invoke the Tivoli OPC dialog by including Tivoli OPC as an option on your existing ISPF master application menu, or on any other selection menu. The following example shows how to do this. The statements that you insert are marked on the right with an arrow (<====).
ISPF-selection-menu modification for Tivoli OPC )BODY . . 1 ...... - ...... 2 ...... - ...... - ...... O OPC/ESA - Operations Planning and Control/ESA <==== ...... - ...... )PROC . . &ZSEL = TRANS(TRUNC(&ZCMD,'.') 1 , .... 2 , .... . , .... O , 'PANEL(EQQOPCAP) NEWAPPL(EQQA)' <==== . , ...... )END
90 Tivoli OPC Installation Guide Installing Tivoli OPC
Before you can invoke the Tivoli OPC dialog, allocate the Tivoli OPC datasets. You can allocate these datasets through the TSO logon procedure, or by executing a CLIST after TSO logon.
Although you can use any name that follows the guidelines already established at your installation, the sample ISPF command table, EQQACMDS, is valid only if you use the ISPF application name EQQA. If you change the application name on the ISPSTART command, remember to create the corresponding ISPF command table in the table library.
Selecting the Tivoli OPC Main Menu Directly from TSO You can invoke the Tivoli OPC dialog by selecting the Tivoli OPC main menu directly from TSO. You do this from TSO by entering this TSO command:
Invoking the Tivoli OPC dialog directly from TSO ISPSTART PANEL(EQQOPCAP) NEWAPPL(EQQA)
Using this method to invoke the dialog means that the Tivoli OPC main menu, panel EQQOPCAP, is the first ISPF panel displayed. If you enter the ISPF command SPLIT, EQQOPCAP is displayed on the alternate screen. With this method, you cannot use ISPF/PDF and Tivoli OPC dialogs at the same time. This method is therefore suitable for users who require only Tivoli OPC.
Using the ISPF Select Service You can invoke the Tivoli OPC dialog by using the SELECT command from a CLIST or from a program. Refer to your ISPF publications to review these procedures.
Using XCF for Communication | Include this task when installing a tracker, controller, standby controller, or Data | Store that will use XCF for communication.
If you want to use the cross-system coupling facility (XCF) for communication between Tivoli OPC systems, you must: Ensure that XCF startup options are suitable for your Tivoli OPC configuration Include the necessary initialization-statement options for each Tivoli OPC started task.
Tivoli OPC XCF Groups A Tivoli OPC XCF system consists of one controller and one or more trackers defined as members in the Tivoli OPC XCF group. You can include one or more standby controllers in the group. You can also specify more than one Tivoli OPC group in a sysplex. For example, you might want to have a test and production | Tivoli OPC group in your sysplex. If you want to connect the data store and | controller via XCF, you need a separate XCF group for them.
Tivoli OPC supports these sysplex configurations: MULTISYSTEM XCF services are available to Tivoli OPC started tasks residing on different MVS systems.
Chapter 4. Installing Tivoli OPC 91 Installing Tivoli OPC
MONOPLEX XCF services are available only to Tivoli OPC started tasks residing on a single MVS system. Note: Because Tivoli OPC uses XCF signaling services, group services, and status monitoring services with permanent status recording, a couple dataset is required. Tivoli OPC does not support a local sysplex.
For more information about setting up and running a sysplex, refer to Sysplex Management.
With XCF communication links, the Tivoli OPC controller can submit workload and control information to trackers that use XCF signaling services. The trackers use XCF services to transmit events to the controller. Tivoli OPC systems are either ACTIVE, FAILED, or NOT-DEFINED for the Tivoli OPC XCF complex.
Each active member tracks the state of all other members in the group. If a Tivoli OPC group member becomes active, stops, or terminates abnormally, the other active members are notified. This list describes the actions taken by each Tivoli OPC started task in the group: Controller When the controller detects that a tracker member changes to failed state, it stops sending work to the tracker. When it detects that a tracker has become active, it sends work to the tracker system and instructs the tracker to start transmitting event information. Standby When a standby controller that is enabled for takeover detects that the controller has changed to failed state, it attempts to become the new controller. If there is more than one standby controller in the group, the first one to detect failure of the controller attempts to take over the controller functions. Tracker When a tracker member detects that the controller or standby controller has failed, it stops sending event information. The tracker member continues to collect events and writes them to the event dataset. When the controller or standby controller becomes active again it informs the tracker that it is ready to receive events.
XCF Run-Time Options You specify XCF run-time options in the COUPLEnn member of SYS1.PARMLIB and change them using SETXCF operator commands. “Updating XCF Initialization Options” on page 57 describes how to change the options in the COUPLEnn member.
Tivoli OPC Initialization Statements Used for XCF Tivoli OPC started tasks use these initialization statements for XCF. for controller/tracker connections: XCFOPTS Identifies the XCF group and member name for the Tivoli OPC started task. Include XCFOPTS for each Tivoli OPC started task that should join an XCF group. ROUTOPTS Identifies all XCF destinations to the controller or standby controller. Specify ROUTOPTS for each controller and standby controller. TRROPTS Identifies the controller for a tracker. TRROPTS is required for each tracker on a controlled system. On a controlling system, TRROPTS is not required if the tracker and the controller are
92 Tivoli OPC Installation Guide Installing Tivoli OPC
started in the same address space, or if they use shared DASD for event communication. Otherwise, specify TRROPTS.
| Tivoli OPC started tasks use these initialization statements for XCF. for | controller/data store connections: | CTLMEM Defines the XCF member name identifying the Controller in the XCF | connection between Controller and Data Store. | DSTGROUP It defines the XCF group name identifying the Data Store in the | XCF connection with the Controller. | DSTMEM XCF member name, identifying the Data Store in the XCF | connection between Controller and Data Store. | DSTOPTS Defines the runtime options for the OPC Data Store. | FLOPTS Defines the options for Fetch Job Log (FL) task. | XCFDEST It is used by the FL (Fetch Job Log) task to decide from which Data | Store the Job Log will be retrieved.
If you did not include these run-time options when you defined the initialization statements, do this now. “Defining the Initialization Statements” on page 86 and Tivoli OPC Customization and Tuning describe the initialization statements.
Activating the Network Communication Function Include this task when installing a tracker, controller, or standby controller that will use NCF for communication.
If you want to use a VTAM link to connect a tracker to the controller, activate NCF. The controller can then send work to the tracker and receive event information back, using the VTAM link. To achieve this connection, activate NCF in both the controller and the tracker. To do this: Add NCF to the VTAM network definitions. Add NCF session parameters. Activate network resources.
| If you want to connect a controller and data store via SNA you need different VTAM | definitions. NCF is involved only in the tracker connection; the equivalent task in | the data store connection is the FN task.
Adding NCF to the VTAM Network Definitions You must define NCF as a VTAM application on both the controlling system and each controlled system. Before defining NCF, select names for the NCF applications that are unique within the VTAM network.
To define NCF as an application to VTAM: 1. Add the NCF applications to the application node definitions, using APPL statements. 2. Add the application names that NCF is known by, in any partner systems, to the cross-domain resource definitions. Use cross-domain resource (CDRSC) statements to do this. You must do this for all systems that are linked by NCF.
Chapter 4. Installing Tivoli OPC 93 Installing Tivoli OPC
The application node and the cross-domain resource definitions are stored in the SYS1.VTAMLST dataset, or in members of a dataset that is in the same concatenation as SYS1.VTAMLST. Refer to VTAM Resource Definition Reference for a detailed description of defining application program major nodes and cross-domain resources.
The following example illustrates the definitions needed for a cross-domain setup between a controller and a tracker.
Notes: 1. Tivoli OPC requires that the application name and the ACBNAME are the same. 2. IS1MVS1 and IS1MVS2 are only sample names.
At the controller: 1. Define the NCF controller application. Add a VTAM APPL statement like this to the application node definitions:
Controller VTAM applications VBUILD TYPE=APPL OPCCONTR APPL VPACING=1ð, C ACBNAME=OPCCONTR
2. Define the NCF tracker application. Add a definition like this to the cross-domain resource definitions: Controller VTAM cross-domain resources VBUILD TYPE=CDRSC OPCTRK1 CDRSC CDRM=IS1MVS2
At the tracker: 1. Define the NCF tracker application. Add a VTAM APPL statement like this to the application node definitions:
Tracker VTAM applications VBUILD TYPE=APPL OPCTRK1 APPL ACBNAME=OPCTRK1, C MODETAB=EQQLMTAB, C DLOGMOD=NCFSPARM
2. Define the NCF controller application. Add a CDRSC statement like this to the cross-domain resource definitions: Tracker VTAM cross-domain resources VBUILD TYPE=CDRSC OPCCONTR CDRSC CDRM=IS1MVS1
IS1MVS1 and IS1MVS2 are the cross-domain resource managers for the controller and the tracker, respectively.
94 Tivoli OPC Installation Guide Installing Tivoli OPC
Adding NCF Session Parameters You can define the session parameters for NCF either by adding the sample EQQLMTAB logon-mode table or by using your own table. If you use the sample table, assemble and link-edit the EQQLMTAB table into the SYS1.VTAMLIB library concatenation for all trackers where an NCF transmitter application is defined.
Note that the APPL statement that defines an NCF application at a tracker must contain the logon-mode-table information in the MODETAB and DLOGMOD parameters.
| The EQQLMTAB member of the SEQQSKL0 library contains this logon table definition plus the JCL necessary to assemble and link-edit the table:
EQQLMTAB //LOGON JOB STATEMENT PARAMETERS //ASM EXEC PGM=IEV9ð,PARM='NOLOAD,DECK' //SYSLIB DD DSN=SYS1.MACLIB,DISP=SHR //SYSUT1 DD UNIT=SYSDA,SPACE=(17ðð,(4ðð,5ð)) //SYSPUNCH DD DSN=&LOADSET,UNIT=SYSDA,SPACE=(8ð,(25ð,5ð)), // DISP=(,PASS) //SYSPRINT DD SYSOUT=A //SYSIN DD ᑍ EQQLMTAB MODETAB MODEENT LOGMODE=NCFSPARM, C FMPROF=X'ð4', C TSPROF=X'ð4', C PRIPROT=X'F3', C SECPROT=X'F3', C COMPROT=X'ðððð', C PSERVIC=X'ðððððððððððððððððððððððð', C RUSIZES=X'8787' MODEEND END //LINK EXEC PGM=IEWL,PARM='XREF,LIST,LET,NCAL' //SYSPRINT DD SYSOUT=A //SYSLMOD DD DSN=SYS1.VTAMLIB(EQQLMTAB),DISP=SHR //SYSUT1 DD UNIT=SYSDA,SPACE=(17ðð,(4ðð,5ð)) //SYSLIN DD DSN=&LOADSET,DISP=(OLD,DELETE)
If you choose to provide session parameters in another table or entry, modify the APPL definitions for the transmitter applications accordingly. Note that NCF uses an LU-type 0 protocol with a recommended minimum RU-size of 500 bytes. Do not specify an RU-size of 0. NCF does not modify the session parameter specified in the LOGMODE table entry in any way.
For a complete description of logon mode tables and the macros that define them, refer to VTAM Customization.
Chapter 4. Installing Tivoli OPC 95 Installing Tivoli OPC
COS Table No class of service (COS) table entry is specified for EQQLMTAB in the sample. Specify a COS entry that is valid in your VTAM environment unless you intend to use the default provided by VTAM.
The routing you specify in the COS entry should be fast and reliable so that unnecessary delays are not introduced in the Tivoli OPC remote job-tracking function.
Activating Network Resources The VTAM network must be active when the NCF application is started so that network resources are available for the NCF sessions. All participating NCF-application minor nodes must be activated before the NCF application is started by the tracker.
You activate VTAM resources by entering the VARY NET command or by specifying automatic activation in the VTAM network-definition procedure used during VTAM startup. You can activate NCF-application minor nodes and CDRSC minor nodes directly, using the VARY ACT command. You can also activate them indirectly by activating their major nodes. Refer to VTAM Operation for further information.
Diagnostic Data Set If you have not already allocated the EQQDUMP diagnostic dataset for the tracker or controller, do this now. NCF writes debugging information to this diagnostic dataset when internal error conditions are detected. When diagnostic information is logged, the information is normally accompanied by a user abend.
Note: Update the Tivoli OPC started-task procedure with ddname EQQDUMP if this ddname is not already defined.
Controlling OPC/A Release 2 via a VTAM Link You can connect one or more OPC/A Release 2 Event Manager Subsystem (EMS) address spaces to a Tivoli OPC controller via a VTAM link. NCF must be started at the controller, and the OPC/A Network Event Communicator (NEC) must be started on the OPC/A Release 2 system. The controller does not send requests to the OPC/A system via the VTAM link, but can receive events from it via this link. Requests are sent using NJE.
Activating Support for the Tivoli OPC API Include this task when installing a tracker, controller, or standby controller that you want to communicate with through the Tivoli OPC API. If you intend to use the Workload Monitor/2, you must also perform this task.
Tivoli OPC uses LU to LU communication to pass data between an ATP and a Tivoli OPC subsystem through the API. To use API requests GET, PUT, and DELETE, or to use the Workload Monitor/2, the LU that the ATP sends requests to (the target LU) must be owned by the controller. For CREATE requests, if the target LU is not owned by a Tivoli OPC address space where an event-writer task is started, the ATP must send requests so that the events are broadcast on the target MVS system. Tivoli OPC Programming Interfaces and Tivoli OPC Customization and Tuning describe when a request is broadcast.
96 Tivoli OPC Installation Guide Installing Tivoli OPC
To activate support for the API, perform these actions in the order shown: 1. Define VTAM resources. 2. Update APPC/MVS options. 3. Activate Tivoli OPC support for APPC/MVS. If you are installing a standby controller, perform corresponding actions on the standby system.
You might need to refer to one or more of these publications: VTAM Resource Definition Reference APPC Management MVS Initialization and Tuning Reference Tivoli OPC Programming Interfaces, which documents the Tivoli OPC API
The actions described here are based on MVS 4.2.2 systems. If you use a later MVS release, check for enhancements that might make some actions unnecessary.
Defining VTAM Resources Start by defining the associated VTAM resources.
Defining a Local LU Define a local LU in a member in the SYS1.VTAMLST concatenation on the system where you are installing Tivoli OPC. This example shows how a VTAM APPL statement might be defined:
Local LU definition VBUILD TYPE=APPL IS4MEOP4 APPL ACBNAME=IS4MEOP4, C APPC=YES, C AUTOSES=5, C DMINWNL=3, C DMINWNR=6, C DSESLIM=9, C MODETAB=APPCMODE, C SECACPT=CONV, C SRBEXIT=YES, C VERIFY=OPTIONAL, C VPACING=2
The LU is called IS4MEOP4 and uses the logon-mode table APPCMODE.
Before you can establish a session with Tivoli OPC, a partner LU must be defined. If a partner TP is run at a different node, ensure that an LU is defined at that node.
The OPC Controller subsystem currently have tasks utilizing APPC/MVS. The subsystem is defined as one LU node to APPC/MVS and VTAM.
Chapter 4. Installing Tivoli OPC 97 Installing Tivoli OPC
Defining Logon Modes The logon-mode table, which you specify in the LU APPL definition statement, must be in the SYS1.VTAMLIB concatenation. To enable LU 6.2 communication for MVS, you need the VTAM logon-mode SNASVCMG. For applications, APPC/MVS also requires at least one logon-mode entry other than SNASVCMG. You can create a new logon-mode table or add logon modes to an existing table. The name of the logon-mode table that is used by the Tivoli OPC LU and the partner LU need not be the same, but both LUs must use the same logon-mode names. That is, the logon modes used by these LUs must appear in each table, and they must have the same names. This example of an uncompiled logon-mode table contains three logon modes:
Example logon-mode table APPCMODE MODETAB EJECT ᑍ------ᑍ ᑍ Logmode table entry for resources capable of acting as LU 6.2 ᑍ ᑍ devices required for LU management. ᑍ ᑍ------ᑍ SNASVCMG MODEENT C LOGMODE=SNASVCMG, C FMPROF=X'13', C TSPROF=X'ð7', C PRIPROT=X'Bð', C SECPROT=X'Bð', C COMPROT=X'DðB1', C RUSIZES=X'8585', C ENCR=B'ðððð', C PSERVIC=X'ð6ð2ððððððððððððððððð3ðð' ᑍ------ᑍ ᑍ Logmode table entry for resources capable of acting as LU 6.2 ᑍ ᑍ devices for PC target. ᑍ ᑍ------ᑍ LU62SYS1 MODEENT C LOGMODE=LU62SYS1, C RUSIZES=X'8989', C SRCVPAC=X'ðð', C SSNDPAC=X'ð1' ᑍ------ᑍ ᑍ Logmode table entry for resources capable of acting as LU 6.2 ᑍ ᑍ devices for host target. ᑍ ᑍ------ᑍ APPCHOST MODEENT C LOGMODE=APPCHOST, C RUSIZES=X'8F8F', C SRCVPAC=X'ðð', C SSNDPAC=X'ð1' MODEEND END
98 Tivoli OPC Installation Guide Installing Tivoli OPC
Defining Cross-Domain Resources If the Tivoli OPC TP and the partner TP are not running in the same VTAM domain, ensure that their respective LUs can communicate by defining cross-domain resources. In this example, LU name IS1MVS1 is used for the system where the controller is activated, and IS1MVS2 for the system that the partner TP is running on.
On the Tivoli OPC controlling system:
Partner LU cross-domain resources VBUILD TYPE=CDRSC LUMVS2 CDRSC CDRM=IS1MVS2
On the partner system:
Tivoli OPC LU cross-domain resources VBUILD TYPE=CDRSC LUOPC CDRSC CDRM=IS1MVS1
Updating APPC/MVS Options You must update APPC/MVS options to associate the Tivoli OPC scheduler (the subsystem) with the local LU that you defined earlier. Do this by updating the APPCPMnn member of SYS1.PARMLIB. Here is an example of an APPCPMnn member:
APPCPMnn example LUADD /ᑍ Add local LU to APPC config. ᑍ/ ACBNAME(IS4MEOP4) /ᑍ Name of LU ᑍ/ SCHED(EOP4) /ᑍ Scheduler name/OPC subsys name ᑍ/ TPDATA(SYS1.APPCTP) /ᑍ Profile dataset for this LU ᑍ/ TPLEVEL(SYSTEM) /ᑍ TP level for which LU searches ᑍ/
The scheduler name must be the same as the Tivoli OPC subsystem name. In this example, the Tivoli OPC subsystem name is EOP4. A side information file is not used by Tivoli OPC. However, the LU must be associated with a TP profile dataset; you need not specify a profile for Tivoli OPC in the dataset because Tivoli OPC does not use TP profiles.
Chapter 4. Installing Tivoli OPC 99 Installing Tivoli OPC
If you must allocate a TP profile dataset, you can run a job such as:
Allocating a TP profile dataset //ALTPDSET JOB STATEMENT PARAMETERS //TPSAMPLE EXEC PGM=IDCAMS //VOLOUT DD DISP=OLD,UNIT=338ð,VOL=SER=volser //SYSPRINT DD SYSOUT=ᑍ //SYSIN DD ᑍ DEFINE CLUSTER (NAME(SYS1.APPCTP) - VOLUMES(volser)- INDEXED REUSE - SHAREOPTIONS(3 3) - RECORDSIZE(3824 7ð24) - KEYS(112 ð) - RECORDS(3ðð 15ð)) - DATA - (NAME(SYS1.APPCTP.DATA)) - INDEX - (NAME(SYS1.APPCTP.INDEX))
TP profile datasets are VSAM KSDS datasets.
Activating Tivoli OPC Support for APPC/MVS When you have defined the necessary VTAM resources and updated APPC/MVS options, you can activate Tivoli OPC support for APPC/MVS. Do this by specifying APPCTASK(YES) on the OPCOPTS statement. Perform this action when you have completed all other actions and before you start to use the Tivoli OPC API.
| Activating Support for the Tivoli OPC APPC/MVS Server Include this task when activating a Tivoli OPC server. To use the Tivoli Job Scheduling Console see “Activating Support for the Tivoli Job Scheduling Console” on page 104 .
If you intend to use the Tivoli OPC programming interface or the Tivoli OPC dialog from a remote system, you need to activate the APPC/MVS support on the remote system.
The Tivoli OPC dialog and Tivoli OPC programming interface use the default APPC/MVS support defined on the system on which the functions are used. To activate this support: 1. Define a default VTAM APPL supporting APPC: VBUILD TYPE=APPL APPCOUT APPL APPC=YES ACBNAME=APPCOUT ...
100 Tivoli OPC Installation Guide Installing Tivoli OPC
2. Update the APPCPMnn member of SYS1.PARMLIB for the default VTAM APPL defined above: LUADD /ᑍ Add local LU to APPC config.ᑍ/ ACBNAME(APPCOUT) /ᑍ Name of LU ᑍ/ NOSCHED /ᑍ No scheduler associated ᑍ/ BASE /ᑍ default LU for the system ᑍ/ TPDATA(SYS1.APPCTP) /ᑍ Profile dataset for this LU ᑍ/ TPLEVEL(SYSTEM) /ᑍ TP level for which LU searchᑍ/ 3. Add any cross-domain resource definition needed to resolve VTAM addressing.
For further information, refer to the following publications: VTAM Resource Definition Reference APPC Management MVS/ESA Initialization and Tuning Reference
The actions described here are based on MVS 4.2.2 systems. If you use a later MVS release, check for enhancements that might make some actions unnecessary.
Defining VTAM Resources Start by defining the associated VTAM resources.
Defining a Local LU for the Server Define a local LU in a member in the SYS1.VTAMLST concatenation on the system where you are installing Tivoli OPC. This example shows how a VTAM APPL statement might be defined:
Local LU for the server definition VBUILD TYPE=APPL IS4MEOP5 APPL APPC=YES, C AUTOSES=5, C DMINWNL=3, C DMINWNR=6, C DSESLIM=9, C MODETAB=APPCMODE, C SECACPT=ALREADYV, C SRBEXIT=YES, C VERIFY=OPTIONAL, C VPACING=2
The LU is called IS4MEOP5 and uses the logon-mode table APPCMODE.
| The maximum number of TSO dialog users and PIF programs that can | simultaneously acces a Tivoli OPC controller via a single server depends on the | DSESLIM parameter of the VTAM LU for that server. Once the specified number | of sessions has been established, all subsequent users and PIF programs that try | to use that server will hang until one of the existing sessions ends.
The number of servers required by an installation depends on how extensive PIF applications are used. While it may be sufficient with one server for the dialogs, a number of Servers may be required for the PIF applications. PIF applications that are frequently used and with long execution time may need separate servers.
Chapter 4. Installing Tivoli OPC 101 Installing Tivoli OPC
In an installation with a parallel sysplex where OPC can start on any of a number of MVS images, each MVS image within the parallel sysplex should have the same local LU name for a given server. The same LU name must not exist in any other network interconnected to the parallel sysplex network; identical LU names within network, unique LU names across networks.
Refer to “Using XCF for Communication” on page 91 for details on the parallel sysplex installation.
For installations with VTAM Version 4 Release 3 the LU name (the APPL statement name) should be given with a wildcard character, in case OPC works in a parallel sysplex and is not set up to run on a specific MVS image. The APPL statement will then become a Model Application Program Definition, for the identically named LUs on the MVS images where OPC may start. The wildcard character should be chosen such that one model definition is set up for the controller and one model definition for each of the servers. The optional ACBNAME parameter must be omitted, the name of the APPL statement is then used as the ACBNAME.
For example, say OPC can start on MVS images MVS1 and MVS2 in a parallel sysplex. The LU name for controller OPCB is IS4MOPCB, and there are three servers to handle the communication to OPCB, OPCBCOM1, OPCBCOM2 and OPCBCOM3, with LU names IS4MSV1B, IS4MSV2B and IS4MSV3B. VTAM Version 4 Release 3 is available. The following model definitions could then be used (a '?' in the APPL statement name represents a single unspecified character): IS4MOP?B APPL APPC=YES,... IS4MS?1B APPL APPC=YES,... IS4MS?2B APPL APPC=YES,... IS4MS?3B APPL APPC=YES,... Note that the wildcard character must be chosen such that the no other VTAM LU name than the intended OPC LU name matches the model definition.
Defining Logon Modes for the Server The logon-mode table, which you specify in the LU APPL definition statement, must be in the SYS1.VTAMLIB concatenation.
The server support requires a logon-mode table entry, as specified in the following uncompiled example.
Example logon-mode table for server ᑍ------ᑍ ᑍ Logmode table entry for dialogs ᑍ ᑍ------ᑍ APPCDIA MODEENT C LOGMODE=APPCDIA, C RUSIZE=X'8888', C SRCVPAC=X'ðð', C SSNDPAC=X'ð1', C MODEENT C
The RUSIZE gives a user size for sending buffer of 2048 bytes and a receiving buffer of 4096 bytes.
102 Tivoli OPC Installation Guide Installing Tivoli OPC
Updating APPC/MVS Options for the Server You must update APPC/MVS options to associate the Tivoli OPC server (and controller) with the scheduler that you defined earlier. Do this by updating the a LUADD statement in the APPCPMnn member of SYS1.PARMLIB. Here is an example of an APPCPMnn member:
APPCPMnn example LUADD /ᑍ Add local LU to APPC config. ᑍ/ ACBNAME(IS4MEOP5) /ᑍ Name of LU ᑍ/ SCHED(EOP5) /ᑍ Scheduler name/OPC subsys name ᑍ/ TPDATA(SYS1.APPCTP) /ᑍ Profile dataset for this LU ᑍ/ TPLEVEL(SYSTEM) /ᑍ TP level for which LU searches ᑍ/
Each server identifies itself to APPC/MVS as an APPC/MVS scheduler with the name specified by the SCHEDULER keyword of the SERVOPTS statement. If this keyword is omitted, then the started task name is used.
The scheduler name must be the same as the Tivoli OPC server. In this example, the Tivoli OPC server name is EOP5.
| Take the following into consideration to correctly use the Tivoli OPC server: | 1. The Server tasks run on the same system as the Controller. | 2. On the system wherethe Servers and Controller run, you must define the | following LUs: | One LU for the server 'without' the BASE keyword, and specifying the | Server started task as SCHEDULER. | An APPC MASTER LU 'with' the BASE keyword, and specifying | SCHED(ASCH). This LU is not for Tivoli OPC; it is an APPC requirement | that there be a BASE LU with SCHED(ASCH) on every system where | APPC is used. | 3. On the system where you want to enable TSO users to communicate with Tivoli | OPC via the Server interface, you must define one LU as listed above. | 4. When the Tivoli OPC Controller and Servers, and the APPC address space are | all started, you will see messages in the SYSLOG and Controller and Server | EQQMLOGs, stating that communication has been established between the | server and APPC. | 5. The dialog user then selects option 1.0 and specifies the name of the Controller | subsystem with which he wants to communicate, and the LUNAME of the | Server via which that communication is to be routed. For more information os | specifying these values, press the PF1 (help) on panel EQQXLUSL.
| The Tivoli OPC dialog code in the TSO logon address space then sends an APPC | request which is picked up by the APPC BASE LU on that system and routed to | the (Server) LU specified in the request. The Server then passes the dialog data to | the Controller across the MVS Subsystem interface, serving as a local proxy for the | dialog user. The Controller cannot tell whether it is talking to a local ISPF dialog | user, or to a remote user via a Server.
Chapter 4. Installing Tivoli OPC 103 Installing Tivoli OPC
Activating Tivoli OPC Server Support for APPC/MVS You can start the server by using the MVS START command, or you can have the controller start and stop the server automatically. In the latter case, include the servers (srv1, srv2, ...) on the OPCOPTS statement in the Tivoli OPC parameter library.
| Activating Support for the Tivoli Job Scheduling Console | Include this task when activating the OPC TCP/IP server support for the Tivoli Job | Scheduling Console.
| To use Tivoli Job Scheduling Console, you need to initialize the Tivoli OPC | Connector. The Connector forms the bridge between the Tivoli Job Scheduling | Console and the Tivoli OPC product.
| Tivoli Job Scheduling Console communicates with the Tivoli OPC Server using the | TCP/IP protocol. The Tivoli OPC TCP/IP Server communicates with OPC and | passes the data and return codes back to the Connector.
| The security model implemented for Tivoli Job Scheduling Console is similar to that | already implemented by other Tivoli products that have been ported to MVS | (namely Tivoli User Administration and Tivoli Security Management). The Tivoli | Framework security handles the initial user verification, but it is necessary to obtain | a valid corresponding RACF user ID to be able to work with the security | environment in MVS.
| Activating Tivoli OPC Server Support for TCP/IP | You can start the server by using the MVS START command, or you can have the | controller start and stop the server automatically. In the latter case, include the | servers (srv1, srv2, ...) on the OPCOPTS statement in the Tivoli OPC parameter | library. The OPC Server with TCP/IP support requires access to the C language | runtime library (either as STEPLIB or as LINKLIST). If you have multiple TCP/IP | stacks, or a TCP/IP started task with a name different from 'TCPIP', then a | SYSTCPD DD card is required pointing to a TCP/IP data set containing the | TCPIPJOBNAME parameter.
| If you are running on OS/390 2.5 or later, then you have to define OMVS segments | for OPC server started tasks.
104 Tivoli OPC Installation Guide
Chapter 5. Verifying Tivoli OPC Installation
Perform this task for a tracker controller or standby controller.
Use the following procedures to verify your installation of a single Tivoli OPC address space, or to verify your Tivoli OPC configuration.
Overview of Verification When you have installed a tracker, controller, standby controller, or server, you should start it and perform initial verification procedures. To fully verify Tivoli OPC, start all Tivoli OPC address spaces in your configuration, and create database entries, a long-term plan, and a current plan. This is required to verify job submission and connections between systems, and requires some knowledge of the product. Therefore, verification is divided into two parts: initial verification of individual Tivoli OPC address spaces, and verification of your Tivoli OPC configuration. You can therefore perform some verification tasks without needing to know more detailed aspects of Tivoli OPC. When you are more familiar with Tivoli OPC components and functions, you can perform further testing.
The following topics are described: “Verifying Installation of a Tracker” “Verifying Installation of a Controller and Dialogs” on page 111 “Verifying Installation of a Standby Controller” on page 115 “Verifying Tivoli OPC Configuration” on page 118
If you are installing a tracker and controller in the same address space, review the initial verification procedures for both a tracker and a controller.
Verifying Installation of a Tracker When you have completed the installation tasks for a tracker, perform initial verification of the tracker. Because connections and the submission of work cannot be verified in isolation, you can perform further verification of the tracker when you have installed the controlling system, established connections between Tivoli OPC systems, and created a current plan. These verification tasks are described in “Verifying Tivoli OPC Configuration” on page 118.
To initially verify the tracker, perform these tasks: 1. Follow the appropriate procedures for the Tivoli OPC subsystem that you are installing. 2. Ensure that you have completed all the necessary installation tasks. 3. Start the tracker and check the message log (EQQMLOG). 4. Verify that tracking events are created in the event dataset (EQQEVDS). 5. Perform problem determination for tracking events if events are missing from the event dataset.
Copyright IBM Corp. 1991, 1999 105 Verifying the Installation
Ensuring that All Installation Tasks Are Complete Ensure that you have performed all the installation tasks that are needed for your Tivoli OPC service. That is, you should have: Followed the appropriate procedures for the Tivoli OPC subsystem that you are installing Installed the required JES and SMF exits, and verified that they are active Created a JCL procedure for the tracker Allocated required datasets Given the security access for the subsystem to access the datasets Specified the initialization statements in the parameter library (EQQPARM) Included the tracker in the same XCF group as the controller, if the tracker uses an XCF connection Defined a VTAM LU name for the tracker and activated the VTAM resources, if the tracker uses an NCF connection.
Checking the Message Log (EQQMLOG) Start the tracker.
When the tracker is started, check the message log: Check that the return code for all initialization options is 0 (message EQQZ016I). Ensure that all required subtasks are active. – The data-router and submit tasks are always started. You should see these messages: Active data-router-task messages EQQZðð5I OPC SUBTASK DATA ROUTER TASK IS BEING STARTED EQQFðð1I DATA ROUTER TASK INITIALIZATION IS COMPLETE
Active submit-task messages EQQZðð5I OPC SUBTASK JOB SUBMIT TASK IS BEING STARTED EQQSUð1I THE SUBMIT TASK HAS STARTED
– Also, verify that the tracker has started an event writer. You should see these messages: Active event-writer messages EQQZðð5I OPC SUBTASK EVENT WRITER IS BEING STARTED EQQWð65I EVENT WRITER STARTED
– If you have specified that catalog management should be active, you should see these messages: Active catalog-management messages EQQZðð5I OPC SUBTASK CATALOG MGT TASK IS BEING STARTED EQQD1ð1I CATALOG MANAGEMENT INITIALIZATION COMPLETE
106 Tivoli OPC Installation Guide Verifying the Installation
Examine error messages. Note: The first time the event writer is started, it formats the event dataset. Ignore the SD37 abend code that is issued during the formatting process. If you see error messages in the message log for an event reader or an NCF connection, this is because you cannot fully verify an event-reader function or NCF connection until the controller is active and a current plan exists. Active tracker-connection messages for XCF connections are written to the controller message log when the controller is started. If you have specified any of these functions, follow the procedures in “Verifying Tivoli OPC Configuration” on page 118 when you have completed initial verification procedures. Check that your log is complete. Figure 17 on page 127 shows an example of the MLOG for a tracker. If your log seems to be incomplete, information might be in a buffer. If you are unsure whether the log is complete, issue a dummy modify command like this: F ssname,xx. Message EQQZ049E is written to the log when the command is processed. This message will be the last entry in the log.
Verifying Tracking Events The next verification phase is to check that the tracker is collecting tracking-event information and writing it to the event dataset (EQQEVDS).
Tivoli OPC job tracking works correctly only if it receives information about status changes for all jobs or started tasks to be tracked. Job tracking gets this information from SMF and JES exits. These exits gather the necessary information, and an exit record is added to the Tivoli OPC event-writer queue via ECSA buffers.
The Event Writer The event writer removes the event from its queue and creates an event record that is written to an event dataset. The event writer also forwards the event if it has been started with an event-reader function. If a separate event reader is used, the event is read from the event dataset. In either case, the reader task uses the connection with the controller to transfer the event to a queue at the controller. The event-manager subtask then processes the event and the current plan is updated.
The Event Dataset The event dataset is needed to even out any difference in the rate that events are being generated and processed, and to prevent events from being lost if the Tivoli OPC address space, or a Tivoli OPC subtask, must be restarted. The first byte in an exit record is A if the event is created on a JES2 system, or B if the event is created on a JES3 system. This byte is found in position 21 of a standard event record, or position 47 of a continuation (type N) event. Bytes 2 and 3 in the exit record define the event type. These event types are generated by Tivoli OPC for jobs and started tasks: 1 Reader event. A job has entered the JES system. 2 Job-start event. A job has started to execute. 3S Step-end event. A job step has finished executing. 3J Job-end event. A job has finished executing. 3P Job-termination event. A job has been added to the JES output queues. 4 Print event. An output group has been printed. 5 Purge event. All output for a job has been purged from the JES system.
Chapter 5. Verifying Tivoli OPC Installation 107 Verifying the Installation
If any of these event types are not being created in the event dataset (EQQEVDS), a problem must be corrected before Tivoli OPC is started in production mode.
Notes: 1. The creation of step-end events (3S) depends on the value you specify in the STEPEVENTS keyword of the EWTROPTS statement. The default is to create a step-end event only for abending steps in a job or started task. 2. The creation of print events depends on the value you specify in the PRINTEVENTS keyword of the EWTROPTS statement. By default, print events are created.
Perform these actions to verify that events are being created on your system: 1. Run a job: a. Submit a job like the following, ensuring that the output is written to a non-held output class: Test job //VERIFY1 JOB STATEMENT PARAMETERS //VERIFY EXEC PGM=IEBGENER //ᑍ //SYSPRINT DD DUMMY //SYSUT2 DD SYSOUT=A //SYSIN DD DUMMY //SYSUT1 DD ᑍ SAMPLE TEST OUTPUT STATEMENT 1 //ᑍ
b. Verify that the job has executed, printed, and purged. c. Browse the EQQEVDS dataset using the ISPF/PDF browse facility. You should find these events on the event dataset: Type 1 event Type 2 event Type 3J event Type 3P event Type 4 event Type 5 event. The events are prefixed with A for JES2 or B for JES3. You might also find type 3S events, depending on the value specified on the STEPEVENTS keyword of the EWTROPTS initialization statement. 2. Repeat step 1 for a started task.
108 Tivoli OPC Installation Guide Verifying the Installation
Performing Problem Determination for Tracking Events Problem determination depends on which event is missing and whether the events are created on a JES2 or JES3 system. In Table 32, the first column refers to the event type that is missing, and the second column tells you what action to perform. Events created on a JES2 system are prefixed with A, and events created on a JES3 system with B. The first entry in the table applies when all event types are missing (when the event dataset does not contain any tracking events).
Diagnosis, Modification, or Tuning Information
Table 32 (Page 1 of 3). Problem Determination for Missing Tracking Events Type Problem determination actions All 1. Verify in the EQQMLOG dataset that the event writer has started successfully. 2. Verify that the definition of the EQQEVDS ddname in the Tivoli OPC started-task procedure is correct (that is, events are written to the correct dataset). 3. Verify that the required exits have been installed. 4. Verify that the IEFSSNnn member of SYS1.PARMLIB has been updated correctly, and that an IPL of the MVS system has been performed since the update. A1 If both A3P and A5 events are also missing: 1. Verify that the Tivoli OPC version of the JES2 exit 7 routine has been correctly installed. Use the $T EXIT(7) JES command. 2. Verify that the JES2 initialization dataset contains a LOAD statement and an EXIT7 statement for the Tivoli OPC version of JES2 exit 7 (OPCAXIT7). 3. Verify that the exit has been added to a load module library reachable by JES2 and that JES2 has been restarted since this was done. If either A3P or A5 events are present in the event dataset, call an IBM service representative for programming assistance. B1 1. Verify that the Tivoli OPC version of the JES3 exit IATUX29 routine has been correctly installed. 2. Verify that the exit has been added to a load-module library that JES3 can access. 3. Verify that JES3 has been restarted.
Chapter 5. Verifying Tivoli OPC Installation 109 Verifying the Installation
Table 32 (Page 2 of 3). Problem Determination for Missing Tracking Events Type Problem determination actions A2/B2 1. Verify that the job for which no type 2 event was created has started to execute. A type 2 event will not be created for a job that is flushed from the system because of JCL errors. 2. Verify that the IEFUJI exit has been correctly installed: a. Verify that the SMF parameter member SMFPRMnn in the SYS1.PARMLIB dataset specifies that the IEFUJI exit should be called. b. Verify that the IEFUJI exit has not been disabled by an operator command. c. Verify that the correct version of IEFUJI is active. If SYS1.PARMLIB defines LPALIB as a concatenation of several libraries, MVS uses the first IEFUJI module found. d. Verify that the library containing this module was updated by the Tivoli OPC version of IEFUJI and that MVS has been IPLed since the change was made. A3S/B3S If type 3J events are also missing: 1. Verify that the IEFACTRT exit has been correctly installed. 2. Verify that the SMF parameter member SMFPRMnn in the SYS1.PARMLIB dataset specifies that the IEFACTRT exit should be called. 3. Verify that the IEFACTRT exit has not been disabled by an operator command. 4. Verify that the correct version of IEFACTRT is active. If SYS1.PARMLIB defines LPALIB as a concatenation of several libraries, MVS uses the first IEFACTRT module found. 5. Verify that this library was updated by the Tivoli OPC version of IEFACTRT and that MVS has been IPLed since the change was made. If type 3J events are not missing, verify, in the EQQMLOG dataset, that the event writer has been requested to generate step-end events. Step-end events are created only if the EWTROPTS statement specifies STEPEVENTS(ALL) or STEPEVENTS(NZERO) or if the job step abended. A3J/B3J If type 3S events are also missing, follow the procedures described for type 3S events. If type 3S events are not missing, call an IBM service representative for programming assistance. A3P If A1 events are also missing, follow the procedures described for A1 events. If A1 events are not missing, call an IBM service representative for programming assistance. B3P 1. Verify that the Tivoli OPC version of the JES3 exit IATUX19 routine has been correctly installed. 2. Verify that the exit has been added to a load-module library that JES3 can access. 3. Verify that JES3 has been restarted.
110 Tivoli OPC Installation Guide Verifying the Installation
Table 32 (Page 3 of 3). Problem Determination for Missing Tracking Events Type Problem determination actions A4/B4 1. If you have specified PRINTEVENTS(NO) on the EWTROPTS initialization statement, no type 4 events are created. 2. Verify that JES has printed the job for which no type 4 event was created. Type 4 events will not be created for a job that creates only held SYSOUT datasets. 3. Verify that the IEFU83 exit has been correctly installed: a. Verify that the SMF parameter member SMFPRMnn in the SYS1.PARMLIB dataset specifies that the IEFU83 exit should be called. b. Verify that the IEFU83 exit has not been disabled by an operator command. c. Verify that the correct version of IEFU83 is active. If SYS1.PARMLIB defines LPALIB as a concatenation of several libraries, MVS uses the first IEFU83 module found. d. Verify that the library containing this module was updated by the Tivoli OPC version of IEFU83 and that MVS has been IPLed since the change was made. e. For JES2 users (A4 event), ensure that you have not specified TYPE6=NO on the JOBCLASS and STCCLASS statements of the JES2 initialization parameters. A5 1. Verify that JES2 has purged the job for which no A5 event was created. 2. Ensure that you have not specified TYPE26=NO on the JOBCLASS and STCCLASS statements of the JES2 initialization parameters. 3. If A1 events are also missing, follow the procedures described for A1 events. 4. If A1 events are not missing, call an IBM service representative for programming assistance. B5 1. Verify that JES3 has purged the job for which no B5 event was created. 2. If B4 events are also missing, follow the procedures described for B4 events. 3. If B4 events are not missing, call an IBM service representative for programming assistance.
End of Diagnosis, Modification, or Tuning Information
Verifying Installation of a Controller and Dialogs When you have completed the installation tasks for a controller, perform initial verification of the controller. Because connections and the submission of work cannot be verified in isolation, you can perform further verification of the controller when you have installed the controlling system, established connections between Tivoli OPC systems, and created a current plan. “Verifying Tivoli OPC Configuration” on page 118 describes these verification tasks.
Chapter 5. Verifying Tivoli OPC Installation 111 Verifying the Installation
To initially verify the controller, perform the following steps: 1. Ensure that you have completed the installation tasks. 2. Start the controller, and check the message log (EQQMLOG). 3. Check that you can access Tivoli OPC data via the dialogs, and that authority checking is functioning as required.
If you encounter an error during verification, see “Performing Problem Determination” on page 114.
Ensuring that All Installation Tasks Are Complete Check that you have: Created a started-task procedure for the controller Allocated datasets Given security authority to the started task to access its datasets Specified the initialization statements in the parameter library (EQQPARM) Included the controller in an XCF group, if it uses an XCF connection Defined a VTAM application ID for the controller and activated the VTAM resources, if it uses an NCF connection Updated SYS1.PARMLIB and defined VTAM resources, if users communicate with the controller through the Tivoli OPC API or if the Tivoli OPC server is used. Set up the ISPF environment for Tivoli OPC dialog users.
Checking the Message Log (EQQMLOG) Start the controller. Refer to Tivoli OPC Controlling and Monitoring the Workload for information on starting and stopping Tivoli OPC.
When the controller is started, check the message log: Ensure that the return code for all initialization options is 0 (message EQQZ016I). Check that all required subtasks are active. Look for these messages when the controller is started: Active general-service messages EQQZðð5I OPC SUBTASK GENERAL SERVICE IS BEING STARTED EQQZð85I OPC SUBTASK GS EXECUTOR ð1 IS BEING STARTED EQQGðð1I SUBTASK GS EXECUTOR ð1 HAS STARTED . . EQQGðð1I SUBTASK GENERAL SERVICE HAS STARTED
Note: The preceding messages, EQQZ085I and EQQG001I, are repeated for each general service executor that is started. The number of executors started depends on the value you specified on the GSTASK keyword of the OPCOPTS initialization statement. The default is to start all five executors.
112 Tivoli OPC Installation Guide Verifying the Installation
Active data-router-task messages EQQZðð5I OPC SUBTASK DATA ROUTER TASK IS BEING STARTED EQQFðð1I DATA ROUTER TASK INITIALIZATION IS COMPLETE
Active submit-task messages EQQZðð5I OPC SUBTASK JOB SUBMIT TASK IS BEING STARTED EQQSUð1I THE SUBMIT TASK HAS STARTED
When you start a controller and no current plan exists, you will still see a number of EQQZ005I messages each indicating that a subtask is being started. But these subtasks will not start until a current plan is created. You will also see this message:
Current plan message EQQN1ð5W NO VALID CURRENT PLAN EXISTS. CURRENT PLAN VSAM I/O IS NOT POSSIBLE
If you have specified an event-reader function or NCF connections, these tasks will end if no current plan exists. You can verify the remaining tasks when you have created a current plan and connections can be established. “Verifying Tivoli OPC Configuration” on page 118 describes these tasks. Check that the log is complete. Figure 16 on page 121 shows an example of the MLOG for a controller. Note: If your log seems to be incomplete, information might be in a buffer. If you are unsure whether the log is complete, issue a dummy modify command like this: F ssname,xx. Message EQQZ049E is written to the log when the command is processed. This message will be the last entry in the log.
Checking the Server Message Log After the controller is started, it starts the servers automatically if you specified the SERVERS keyword on the OPCOPTS statement. Otherwise, you must start them, using the MVS/ESA START command. When the server is started, check the message log: Ensure that the return code for all the initialization options is 0 (message EQQZ016I) Look for these messages when the server is started: Active server messages EQQZðð51 OPC SUBTASK SERVER IS BEING STARTED EQQPHðð1 SERVER TASK HAS STARTED
Chapter 5. Verifying Tivoli OPC Installation 113 Verifying the Installation
Checking Tivoli OPC Dialog Functions Before invoking the Tivoli OPC dialog, ensure that you have set up the ISPF environment as described in “Setting Up the ISPF Environment” on page 87. Then invoke the Tivoli OPC dialog, and select an option from 1 to 9 on the main menu. If a new panel appears, you have established communication with the Tivoli OPC subsystem. You can further test the dialogs by performing functions, such as creating an application description. Refer to Tivoli OPC Controlling and Monitoring the Workload and Tivoli OPC Planning and Scheduling the Workload for more information on specific dialog functions.
If you have used RACF to protect controller resources from unauthorized access, verify that the protection mechanism works as expected.
Performing Problem Determination If you encounter problems during your verification of the controller, correct the errors and verify that the problem has been fixed. For more information on problem determination, refer to Tivoli OPC Diagnosis Guide and Reference.
Tivoli OPC Dialog Problems Various errors can occur when you are executing Tivoli OPC dialogs. These errors cause the terminal alarm to sound and a short message to appear in the upper-right corner of your terminal screen. If this happens when you are trying to verify that Tivoli OPC dialogs are correctly installed, press the Help key (usually PF1) in ISPF. ISPF then displays a more complete error message in the long message area on your terminal. The following examples show two dialog error messages. The message number in each example is followed by the long message text and an explanation of the error. The examples highlight two errors. They are related to the dialog interface module, EQQMINOR. EQQX115 EQQX115E TSO Service Facility RC: 2ð, RSNC: 4ð The EQQMINOR load module is not installed in a library that can be reached by TSO. EQQMINOR must be present either in the STEPLIB library of the current TSO session or in a library in the current LINKLIB LNKLSTnn concatenation. If EQQMINOR has been installed in a LINKLIB library, either an LLA refresh process or an IPL is required to make the module accessible by MVS users. EQQX120 The EQQMINOR program can only be called by an APF-authorized task The EQQMINOR load module must be APF authorized. It must reside in a dataset that is defined in SYS1.PARMLIB as being an APF-authorized library. Also, EQQMINOR must be defined to TSO as being an APF-authorized program. Ensure that you have followed the instructions in “Modifying TSO Parameters” on page 57.
Tivoli OPC Authority Problems It is easiest to verify that the controller has been correctly installed without activating authority checking. Then, when authority checking is activated, some TSO users should no longer be able to do what they could do before. A Tivoli OPC dialog message should be issued, specifying that they are not authorized to execute a particular dialog function, or that they are not authorized to use any Tivoli OPC dialog.
114 Tivoli OPC Installation Guide Verifying the Installation
If the controller authority functions have not been correctly installed, this will usually enable TSO users to use dialog functions that they are not authorized to use. The symptom of this problem is the absence of an expected error message. If this happens, follow this procedure which assumes the security monitor being used is RACF. 1. Verify the APPL class. If the user should not be able to use any Tivoli OPC dialog, verify that the APPL class is active and that the Tivoli OPC controller is defined as a resource in the APPL class. Also, verify that the user is not present in the access list to any of these resources and that universal access NONE has been specified. Use the SETR LIST command to display active classes, and use the RLIST command to display access lists in the APPL resource class. 2. Verify that the name of the Tivoli OPC RACF resource class has been defined to the Tivoli OPC started task in the AUTHDEF statement. You can check this by browsing the controller message log (EQQMLOG). 3. Verify the definition of the Tivoli OPC resource class. Check the source of the RACF class descriptor table, and compare this with the definition supplied by the ICHRRCDE sample in the SEQQSAMP library (see page 63). 4. Verify fixed resources. If the user should not be able to use a specific dialog, such as the Calendar dialog, verify that the Tivoli OPC RACF resource class is active and that CL is defined as a resource in this class. Also, verify that the user is not present in the access list to the CL resource and that universal access NONE has been specified. 5. Verify subresources. If, for example, the user should be able to update only a subset of all applications in the Application Description dialog, but is instead able to update all applications, verify that the SUBRESOURCES keyword has been correctly specified for the controller in the AUTHDEF statement. Also verify that the controller has been restarted since the AUTHDEF statement was changed, and that Tivoli OPC RACF profiles have been refreshed since the Tivoli OPC subresource profiles were updated.
Verifying Installation of a Standby Controller When you have completed the installation tasks for a standby controller, perform initial verification. Because connections cannot be verified in isolation, you can perform further verification of the standby controller when you have installed the controlling system, established connections between Tivoli OPC systems, and created a current plan. “Verifying Tivoli OPC Configuration” on page 118 describes these verification tasks.
To initially verify the standby controller, perform these tasks: 1. Ensure that you have completed all the necessary installation tasks. 2. Start the standby controller, and check the message log (EQQMLOG).
Chapter 5. Verifying Tivoli OPC Installation 115 Verifying the Installation
Ensuring that All Installation Tasks Are Complete Check the installation tasks to make sure that you have performed the following actions: Created a JCL procedure for the standby controller Given the security authority for the address space to access the same datasets as the controller Specified the initialization statements in the parameter library (EQQPARM) Included the standby controller in the same XCF group as the controller Defined a VTAM application ID for the standby controller, and activated the VTAM resources, if the standby controller will use NCF connections Updated SYS1.PARMLIB and defined VTAM resources, if the Tivoli OPC API or the Tivoli OPC server is used.
Checking the Message Log (EQQMLOG) Start the standby controller.
When the controller has started, you should check the message log.
When you browse the message log: Ensure that the return code for all initialization options is 0 (message EQQZ016I). Check that this message appears: Standby controller message EQQZ128I OPC ACTIVE IN STANDBY MODE
Figure 15 on page 117 shows an example of the MLOG for a standby controller.
116 Tivoli OPC Installation Guide Verifying the Installation
ð4/ð8 13.42.33 EQQZð13I NOW PROCESSING PARAMETER LIBRARY MEMBER STANDBY ð4/ð8 13.42.33 EQQZð15I INIT STATEMENT: OPCOPTS OPCHOST(STANDBY) ð4/ð8 13.42.33 EQQZð15I INIT STATEMENT: APPCTASK(YES) ð4/ð8 13.42.33 EQQZð15I INIT STATEMENT: RECOVERY(YES) ð4/ð8 13.42.33 EQQZð15I INIT STATEMENT: ERDRTASK(ð) ð4/ð8 13.42.33 EQQZð15I INIT STATEMENT: EWTRTASK(NO) ð4/ð8 13.42.33 EQQZð15I INIT STATEMENT: GTABLE(JOBCARD) ð4/ð8 13.42.33 EQQZð15I INIT STATEMENT: NCFTASK(YES) ð4/ð8 13.42.33 EQQZð15I INIT STATEMENT: NCFAPPL(NCFFNðð2) ð4/ð8 13.42.33 EQQZð15I INIT STATEMENT: CATMGT(YES) ð4/ð8 13.42.33 EQQZð15I INIT STATEMENT: SERVERS(OSR1,OSR2) ð4/ð8 13.42.33 EQQZð15I INIT STATEMENT: BUILDSSX(REBUILD) ð4/ð8 13.42.33 EQQZð15I INIT STATEMENT: VARSUB(SCAN) ð4/ð8 13.42.33 EQQZð15I INIT STATEMENT: SSCMNAME(EQQSSCMC,TEMPORARY) ð4/ð8 13.42.33 EQQZð15I INIT STATEMENT: ð4/ð8 13.42.33 EQQZð16I RETURN CODE FOR THIS STATEMENT IS: ðððð ð4/ð8 13.42.33 EQQZð15I INIT STATEMENT: ALERTS MLOG(DURATION,ERROROPER,OPCERROR,QLIMEXCEED) ð4/ð8 13.42.33 EQQZð15I INIT STATEMENT: ð4/ð8 13.42.33 EQQZð16I RETURN CODE FOR THIS STATEMENT IS: ðððð ð4/ð8 13.42.33 EQQZð15I INIT STATEMENT: AUTHDEF CLASS(IBMOPC) SUBRESOURCES(CP.CPGDDEF LT.LTGDDEF) ð4/ð8 13.42.33 EQQZð15I INIT STATEMENT: ð4/ð8 13.42.33 EQQZð16I RETURN CODE FOR THIS STATEMENT IS: ðððð ð4/ð8 13.42.33 EQQZð15I INIT STATEMENT: EXITS CALLðð(NO) ð4/ð8 13.42.33 EQQZð15I INIT STATEMENT: CALLð1(NO) ð4/ð8 13.42.33 EQQZð15I INIT STATEMENT: CALLð2(YES) ð4/ð8 13.42.33 EQQZð15I INIT STATEMENT: CALLð3(NO) ð4/ð8 13.42.33 EQQZð15I INIT STATEMENT: CALLð4(NO) ð4/ð8 13.42.33 EQQZð15I INIT STATEMENT: CALLð5(NO) ð4/ð8 13.42.33 EQQZð15I INIT STATEMENT: CALLð6(NO) ð4/ð8 13.42.33 EQQZð15I INIT STATEMENT: CALLð7(NO) ð4/ð8 13.42.33 EQQZð15I INIT STATEMENT: CALLð8(NO) ð4/ð8 13.42.33 EQQZð15I INIT STATEMENT: CALLð9(YES) ð4/ð8 13.42.33 EQQZð15I INIT STATEMENT: ð4/ð8 13.42.33 EQQZð16I RETURN CODE FOR THIS STATEMENT IS: ðððð ð4/ð8 13.42.33 EQQZð15I INIT STATEMENT: ROUTOPTS DASD(SUBCPU1) ð4/ð8 13.42.33 EQQZð15I INIT STATEMENT: SNA(NCFFNðð3) ð4/ð8 13.42.33 EQQZð15I INIT STATEMENT: USER(OS2LAN1,OS2LAN2) ð4/ð8 13.42.33 EQQZð15I INIT STATEMENT: XCF(OPC) ð4/ð8 13.42.33 EQQZð15I INIT STATEMENT: ð4/ð8 13.42.33 EQQZð16I RETURN CODE FOR THIS STATEMENT IS: ðððð ð4/ð8 13.42.33 EQQZð15I INIT STATEMENT: XCFOPTS MEMBER(SMOPC) ð4/ð8 13.42.33 EQQZð15I INIT STATEMENT: GROUP(PLEXM1ð1) ð4/ð8 13.42.33 EQQZð16I RETURN CODE FOR THIS STATEMENT IS: ðððð ð4/ð8 13.42.34 EQQZð14I MAXIMUM RETURN CODE FOR PARAMETER MEMBER STANDBY IS: ðððð ð4/ð8 13.42.35 EQQZ172I SSX BLOCK OF VERSION ð2HOPC2ðð SUCCESSFULLY BUILT ð4/ð8 13.42.35 EQQZð73I OPC HAS RECOGNIZED THAT THIS IS A JES2 SYSTEM WITH ð4/ð8 13.42.35 EQQZð73I COMMAND CHARACTER $ AND THAT THE NJE NODE NAME IS ROMEMVS ð4/ð8 13.42.35 EQQZ128I OPC ACTIVE IN STANDBY MODE
Figure 15. Sample Message Log for a Standby Controller
Chapter 5. Verifying Tivoli OPC Installation 117 Verifying the Installation
Verifying Tivoli OPC Configuration Perform this task for a tracker, controller, or standby controller.
When you have installed your Tivoli OPC controlling system, or when you install a controlled system, review this section to complete the verification of Tivoli OPC. These topics are described: Creating entries in the databases Running Tivoli OPC batch jobs Checking the message logs (EQQMLOG) Verifying workload submission Verifying takeover by a standby controller
Creating Entries in the Databases You cannot fully verify Tivoli OPC until you have created a current plan. Before you can do this, you must create entries in the databases and then produce a long-term plan. If you are not familiar with Tivoli OPC, refer to Tivoli OPC Planning and Scheduling the Workload for information about updating the databases and producing a long-term plan and a current plan.
Sample Tivoli OPC databases come with Tivoli OPC. They are loaded into the SMP/E target library with ddname SEQQDATA when the tracker software tape is processed. You can load the sample databases by submitting the EQQSAMPI JCL, which is generated by EQQJOBS.
Running Tivoli OPC Batch Jobs When you have created database entries, invoke the LTP dialog and create a long-term plan. Check that the batch job completed successfully, and browse the long-term plan to check that the entries are correct. Next, use the Daily Planning dialog to create a current plan. When this job has ended, browse the current plan to check that the expected application occurrences are present.
You can further test Tivoli OPC batch jobs by, for example, printing information about the entries you have created in the databases. Table 21 on page 48 lists the Tivoli OPC batch jobs.
Checking the Message Logs (EQQMLOG) When you have created a current plan and have started all Tivoli OPC address spaces in your configuration, check the message log of the controller and of all trackers.
Controller Message Log Look for these messages in the message log of the controller:
Active normal-mode-manager messages EQQZðð5I OPC SUBTASK NORMAL MODE MGR IS BEING STARTED EQQNð13I OPC JOB TRACKING IS NOW ACTIVE AND CURRENT PLAN DD-NAME IS EQQCP1DS
Note: In the preceding message, the active current plan ddname is either EQQCP1DS or EQQCP2DS.
118 Tivoli OPC Installation Guide Verifying the Installation
Active event-manager messages EQQZðð5I OPC SUBTASK EVENT MANAGER IS BEING STARTED EQQEð25I THE EVENT MANAGER HAS STARTED
Active job-tracking-log-archiver messages EQQZðð5I OPC SUBTASK JT LOG ARCHIVER IS BEING STARTED EQQNð8ðI THE LOG ARCHIVER TASK HAS STARTED
Active general-service messages EQQZðð5I OPC SUBTASK GENERAL SERVICE IS BEING STARTED EQQZð85I OPC SUBTASK GS EXECUTOR ð1 IS BEING STARTED EQQGðð1I SUBTASK GS EXECUTOR ð1 HAS STARTED . . EQQGðð1I SUBTASK GENERAL SERVICE HAS STARTED
Note: The preceding messages, EQQZ085I and EQQG001I, are repeated for each general service executor that is started. The number of executors started depends on the value you specified on the GSTASK keyword of the OPCOPTS initialization statement. The default is to start all five executors.
Active workstation-analyzer-task messages EQQZðð5I OPC SUBTASK WS ANALYZER IS BEING STARTED EQQW5ð5I THE WORK STATION ANALYZER TASK HAS STARTED
Active data-router-task messages EQQZðð5I OPC SUBTASK DATA ROUTER TASK IS BEING STARTED EQQFðð1I DATA ROUTER TASK INITIALIZATION IS COMPLETE
Active submit-task messages EQQZðð5I OPC SUBTASK JOB SUBMIT TASK IS BEING STARTED EQQSUð1I THE SUBMIT TASK HAS STARTED
If you have specified that APPC/MVS support should be started, check that these messages appear:
Active APPC-task messages EQQZðð5I OPC SUBTASK APPC TASK IS BEING STARTED EQQOðð1I APPC TASK INITIALIZATION IS COMPLETE
Chapter 5. Verifying Tivoli OPC Installation 119 Verifying the Installation
This message must be issued for the first Tivoli OPC controller or server start after APPC/MVS starts; it is issued by APPC/MVS to the system log:
APPC scheduler active — system log messages ATBð5ðI LOGICAL UNIT IS4MEOP4 FOR TRANSACTION SCHEDULER EOP4 HAS BEEN ADDED TO THE APPC CONFIGURATION.
If you have specified an event-reader function, check that these messages appear:
Active event-reader messages EQQZðð5I OPC SUBTASK EVENT READER IS BEING STARTED EQQRð25I ERDR ð1 STARTED
The numeric value on message EQQR025I indicates which event reader is started. The same value cannot be specified on more than one ERSEQNO keyword at the same node. No more than 16 event-reader tasks can be specified at the same node.
If the controller uses XCF connections, the XCF group is activated when the controller is started. Several messages can appear in the message log, indicating that a tracker or standby controller has started and that it has joined the group. If the controller communicates with a tracker via XCF, check for this message to verify the connection:
Active tracker-connection message EQQFðð7I XCF MEMBER TRACK2 HAS JOINED THE GROUP. THE DESTINATION WILL BE EQQFðð7I REPORTED ACTIVE
If a standby controller is started, check for this message:
Active standby-controller-connection message EQQFðð8I XCF MEMBER CTRSTBY1 HAS JOINED THE GROUP AS STANDBY FOR THE EQQFðð8I OPC CONTROLLER
If the controller uses an NCF connection, check that these messages appear (where NCFCON01 is the VTAM application ID of the controller, and NCFTRK01 is the VTAM application ID of the tracker):
Active NCF-connection messages EQQZðð5I OPC SUBTASK VTAM I/O TASK IS BEING STARTED EQQVðð1I NCF APPLICATION STARTED EQQVð24I ACB SUCCESSFULLY OPENED EQQVð36I SESSION NCFCONð1-NCFTRKð1 ESTABLISHED
Figure 16 on page 121 shows an example of the MLOG for a controller. The controller is connected to three trackers through shared DASD, XCF, and NCF. A standby controller is also started in this configuration.
120 Tivoli OPC Installation Guide Verifying the Installation
ð4/ð8 12.13.19 EQQZð13I NOW PROCESSING PARAMETER LIBRARY MEMBER CONTROLR ð4/ð8 12.13.19 EQQZð15I INIT STATEMENT: OPCOPTS OPCHOST(YES) ð4/ð8 12.13.19 EQQZð15I INIT STATEMENT: APPCTASK(YES) ð4/ð8 12.13.19 EQQZð15I INIT STATEMENT: RECOVERY(YES) ð4/ð8 12.13.19 EQQZð15I INIT STATEMENT: RODMTASK(YES) RODMPARM(RODM) ð4/ð8 12.13.19 EQQZð15I INIT STATEMENT: ERDRTASK(ð) ð4/ð8 12.13.19 EQQZð15I INIT STATEMENT: EWTRTASK(NO) ð4/ð8 12.13.19 EQQZð15I INIT STATEMENT: GTABLE(JOBCARD) ð4/ð8 12.13.19 EQQZð15I INIT STATEMENT: STORELOG(ALL) ð4/ð8 12.13.19 EQQZð15I INIT STATEMENT: NCFTASK(YES) ð4/ð8 12.13.19 EQQZð15I INIT STATEMENT: NCFAPPL(NCFFNðð2) ð4/ð8 12.13.19 EQQZð15I INIT STATEMENT: CATMGT(YES) ð4/ð8 12.13.19 EQQZð15I INIT STATEMENT: SERVERS(OSR1,OSR2) ð4/ð8 12.13.19 EQQZð15I INIT STATEMENT: BUILDSSX(REBUILD) ð4/ð8 12.13.19 EQQZð15I INIT STATEMENT: VARSUB(SCAN) ð4/ð8 12.13.19 EQQZð15I INIT STATEMENT: SSCMNAME(EQQSSCMC,TEMPORARY) ð4/ð8 12.13.19 EQQZð15I INIT STATEMENT: ð4/ð8 12.13.19 EQQZð16I RETURN CODE FOR THIS STATEMENT IS: ðððð ð4/ð8 12.13.19 EQQZð15I INIT STATEMENT: ALERTS MLOG(DURATION,ERROROPER,OPCERROR,QLIMEXCEED,RESCONT) ð4/ð8 12.13.19 EQQZð15I INIT STATEMENT: ð4/ð8 12.13.19 EQQZð16I RETURN CODE FOR THIS STATEMENT IS: ðððð ð4/ð8 12.13.19 EQQZð15I INIT STATEMENT: AUTHDEF CLASS(IBMOPC) SUBRESOURCES(CP.CPGDDEF LT.LTGDDEF) ð4/ð8 12.13.19 EQQZð15I INIT STATEMENT: ð4/ð8 12.13.19 EQQZð16I RETURN CODE FOR THIS STATEMENT IS: ðððð ð4/ð8 12.13.19 EQQZð15I INIT STATEMENT: EXITS CALLðð(NO) ð4/ð8 12.13.19 EQQZð15I INIT STATEMENT: CALLð1(NO) ð4/ð8 12.13.19 EQQZð15I INIT STATEMENT: CALLð2(YES) ð4/ð8 12.13.19 EQQZð15I INIT STATEMENT: CALLð3(NO) ð4/ð8 12.13.19 EQQZð15I INIT STATEMENT: CALLð4(NO) ð4/ð8 12.13.19 EQQZð15I INIT STATEMENT: CALLð5(NO) ð4/ð8 12.13.19 EQQZð15I INIT STATEMENT: CALLð6(YES) ð4/ð8 12.13.19 EQQZð15I INIT STATEMENT: CALLð7(NO) ð4/ð8 12.13.19 EQQZð15I INIT STATEMENT: CALLð8(NO) ð4/ð8 12.13.19 EQQZð15I INIT STATEMENT: CALLð9(YES) ð4/ð8 12.13.19 EQQZð15I INIT STATEMENT: CALL1ð(NO) ð4/ð8 12.13.19 EQQZð15I INIT STATEMENT: ð4/ð8 12.13.19 EQQZð16I RETURN CODE FOR THIS STATEMENT IS: ðððð ð4/ð8 12.13.19 EQQZð15I INIT STATEMENT: ROUTOPTS DASD(SUBCPU1) ð4/ð8 12.13.19 EQQZð15I INIT STATEMENT: SNA(NCFFNðð3) ð4/ð8 12.13.19 EQQZð15I INIT STATEMENT: USER(OS2LAN1,OS2LAN2) ð4/ð8 12.13.19 EQQZð15I INIT STATEMENT: XCF(SMOPC) ð4/ð8 12.13.19 EQQZð15I INIT STATEMENT: APPC(ROMEAS1:ITIBM2ðð.S44D1288) ð4/ð8 12.13.19 EQQZð15I INIT STATEMENT: TCP(ROM2:9.52.52.11) ð4/ð8 12.13.19 EQQZð15I INIT STATEMENT: TCPIPID(TCPIPROC) ð4/ð8 12.13.19 EQQZð15I INIT STATEMENT: ð4/ð8 12.13.19 EQQZð16I RETURN CODE FOR THIS STATEMENT IS: ðððð ð4/ð8 12.13.19 EQQZð15I INIT STATEMENT: XCFOPTS MEMBER(OPC) ð4/ð8 12.13.19 EQQZð15I INIT STATEMENT: GROUP(PLEXM1ð1) ð4/ð8 12.13.19 EQQZð16I RETURN CODE FOR THIS STATEMENT IS: ðððð ð4/ð8 12.13.19 EQQZð14I MAXIMUM RETURN CODE FOR PARAMETER MEMBER CONTROLR IS: ðððð ð4/ð8 12.13.2ð EQQZð13I NOW PROCESSING PARAMETER LIBRARY MEMBER RODM ð4/ð8 12.13.2ð EQQZð15I INIT STATEMENT: RODMOPTS RODMSYSTEM(EKGXRODM) ð4/ð8 12.13.2ð EQQZð15I INIT STATEMENT: OPCRESOURCE(TAPE) ð4/ð8 12.13.2ð EQQZð15I INIT STATEMENT: OPCFIELD(QUANTITY) ð4/ð8 12.13.2ð EQQZð15I INIT STATEMENT: RODMCLASS(TAPE) ð4/ð8 12.13.2ð EQQZð15I INIT STATEMENT: RODMFIELD(NUMBEROF) ð4/ð8 12.13.2ð EQQZð15I INIT STATEMENT: RODMLOST(LAST) ð4/ð8 12.13.2ð EQQZð16I RETURN CODE FOR THIS STATEMENT IS: ðððð ð4/ð8 12.13.2ð EQQZð14I MAXIMUM RETURN CODE FOR PARAMETER MEMBER RODM ð4/ð8 12.13.21 EQQZ172I SSX BLOCK OF VERSION ð2HOPC2ðð SUCCESSFULLY BUILT ð4/ð8 12.13.21 EQQZð73I OPC HAS RECOGNIZED THAT THIS IS A JES2 SYSTEM WITH
Figure 16 (Part 1 of 5). Sample Message Log for a Controller
Chapter 5. Verifying Tivoli OPC Installation 121 Verifying the Installation
ð4/ð8 12.13.21 EQQZð73I COMMAND CHARACTER $ AND THAT THE NJE NODE NAME IS ROMEMVS ð4/ð8 12.13.22 EQQZðð5I OPC SUBTASK VTAM I/O TASK IS BEING STARTED ð4/ð8 12.13.22 EQQZðð5I OPC SUBTASK NORMAL MODE MGR IS BEING STARTED ð4/ð8 12.13.22 EQQZðð5I OPC SUBTASK TCP/IP TASK IS BEING STARTED ð4/ð8 12.13.22 EQQZðð5I OPC SUBTASK APPC TRACKER IS BEING STARTED ð4/ð8 12.13.22 EQQZðð5I OPC SUBTASK JOB SUBMIT TASK IS BEING STARTED ð4/ð8 12.13.22 EQQZðð5I OPC SUBTASK DATA ROUTER TASK IS BEING STARTED ð4/ð8 12.13.22 EQQZðð5I OPC SUBTASK RODM TASK IS BEING STARTED ð4/ð8 12.13.22 EQQZðð5I OPC SUBTASK APPC TASK IS BEING STARTED ð4/ð8 12.13.23 EQQVðð1I NCF APPLICATION STARTED ð4/ð8 12.13.23 EQQZð13I NOW PROCESSING PARAMETER LIBRARY MEMBER CONTROLR ð4/ð8 12.13.23 EQQZð15I INIT STATEMENT: AUDIT ACCESS(UPDATE) AMOUNT(KEY) FILE(ALL) ð4/ð8 12.13.23 EQQZð16I RETURN CODE FOR THIS STATEMENT IS: ðððð ð4/ð8 12.13.23 EQQZð15I INIT STATEMENT: AUDIT ACCESS(UPDATE) AMOUNT(DATA) FILE(JS) ð4/ð8 12.13.23 EQQZð15I INIT STATEMENT: ð4/ð8 12.13.23 EQQZð16I RETURN CODE FOR THIS STATEMENT IS: ðððð ð4/ð8 12.13.23 EQQZð15I INIT STATEMENT: JTOPTS BACKUP(NO) ð4/ð8 12.13.23 EQQZð15I INIT STATEMENT: STATMSG(CPLOCK EVENTS GENSERV) ð4/ð8 12.13.23 EQQZð15I INIT STATEMENT: ETT(YES) ð4/ð8 12.13.23 EQQZð15I INIT STATEMENT: HIGHRC(ð) ð4/ð8 12.13.23 EQQZð15I INIT STATEMENT: JOBCHECK(SAME) ð4/ð8 12.13.23 EQQZð15I INIT STATEMENT: JTLOGS(5) ð4/ð8 12.13.23 EQQZð15I INIT STATEMENT: OPINFOSCOPE(ALL) ð4/ð8 12.13.23 EQQZð15I INIT STATEMENT: JOBSUBMIT(YES) ð4/ð8 12.13.23 EQQZð15I INIT STATEMENT: MAXJSFILE(NO) ð4/ð8 12.13.23 EQQZð15I INIT STATEMENT: NEWOILIMIT(3ð) ð4/ð8 12.13.23 EQQZð15I INIT STATEMENT: OFFDELAY(3) ð4/ð8 12.13.23 EQQZð15I INIT STATEMENT: PLANSTART(7) ð4/ð8 12.13.23 EQQZð15I INIT STATEMENT: PRTCOMPLETE(YES) ð4/ð8 12.13.23 EQQZð15I INIT STATEMENT: DUAL(NO) ð4/ð8 12.13.23 EQQZð15I INIT STATEMENT: SHUTDOWNPOLICY(75) ð4/ð8 12.13.23 EQQZð15I INIT STATEMENT: SUBFAILACTION(E) ð4/ð8 12.13.23 EQQZð15I INIT STATEMENT: SUPPRESSACTION(C) ð4/ð8 12.13.23 EQQZð15I INIT STATEMENT: SUPPRESSPOLICY(75) ð4/ð8 12.13.23 EQQZð15I INIT STATEMENT: TRACK(JOBOPT) ð4/ð8 12.13.23 EQQZð15I INIT STATEMENT: WSFAILURE(ERROR,REROUTE,IMMED) ð4/ð8 12.13.23 EQQZð15I INIT STATEMENT: WSOFFLINE(ERROR,REROUTE,IMMED) ð4/ð8 12.13.23 EQQZð15I INIT STATEMENT: ð4/ð8 12.13.23 EQQZð16I RETURN CODE FOR THIS STATEMENT IS: ðððð ð4/ð8 12.13.23 EQQZð15I INIT STATEMENT: NOERROR LIST(MYJOB.ᑍ.STEP4.ððð2 ð4/ð8 12.13.23 EQQZð15I INIT STATEMENT: HISJOB.ᑍ.STEP6.ððð4 ð4/ð8 12.13.23 EQQZð15I INIT STATEMENT: HERJOB.ᑍ.STEP9.ðð16) ð4/ð8 12.13.23 EQQZð15I INIT STATEMENT: ð4/ð8 12.13.23 EQQZð16I RETURN CODE FOR THIS STATEMENT IS: ðððð ð4/ð8 12.13.23 EQQZð14I MAXIMUM RETURN CODE FOR PARAMETER MEMBER CONTROLR IS: ðððð ð4/ð8 12.13.23 EQQSU12I MAX NUMBER OF WORKSTATIONS CHECKPOINTED BY THIS SUBMIT TASK: ðð46 ð4/ð8 12.13.23 EQQOðð1I APPC TASK INITIALIZATION IS COMPLETE ð4/ð8 12.13.23 EQQFðð7I XCF MEMBER SMOPC HAS JOINED THE GROUP. THE DESTINATION WILL BE ð4/ð8 12.13.23 EQQFðð7I REPORTED ACTIVE ð4/ð8 12.13.23 EQQFðð8I XCF MEMBER SBOPC HAS JOINED THE GROUP AS STANDBY FOR THE ð4/ð8 12.13.23 EQQFðð8I OPC CONTROLLER ð4/ð8 12.13.23 EQQFðð1I DATA ROUTER TASK INITIALIZATION IS COMPLETE ð4/ð8 12.13.23 EQQTAð1I THE TCP/IP COMMUNICATION TASK HAS STARTED ð4/ð8 12.13.24 EQQSUð1I THE SUBMIT TASK HAS STARTED ð4/ð8 12.13.24 EQQATð1I THE APPC TRACKER TASK HAS STARTED ð4/ð8 12.13.26 EQQQ5ð2I SPECIAL RESOURCE DATASPACE HAS BEEN CREATED ð4/ð8 12.13.26 EQQQ5ð2I ððððð2ð PAGES ARE USED FOR ððððð1ðð SPECIAL RESOURCE RECORDS ð4/ð8 12.13.45 EQQNð18I VSAM LSR BUFFERS HAVE BEEN SUCCESSFULLY ALLOCATED FOR VSAM FILE EQQCP1DS
Figure 16 (Part 2 of 5). Sample Message Log for a Controller
122 Tivoli OPC Installation Guide Verifying the Installation
ð4/ð8 12.13.45 EQQNð18I NUMBER OF INDEX BUFFERS ARE ððððð6 WITH SIZE ð16384 ð4/ð8 12.13.45 EQQNð18I NUMBER OF DATA BUFFERS ARE ðððð1ð WITH SIZE ð32768 ð4/ð8 12.13.45 EQQNð12I OPC JOB TRACKING EVENTS ARE NOW BEING LOGGED ON FILE EQQJTð1 ð4/ð8 12.13.45 EQQNð13I OPC JOB TRACKING IS NOW ACTIVE AND CURRENT PLAN DD-NAME IS EQQCP1DS ð4/ð8 12.13.45 EQQZðð5I OPC SUBTASK EVENT MANAGER IS BEING STARTED ð4/ð8 12.13.45 EQQZðð5I OPC SUBTASK GENERAL SERVICE IS BEING STARTED ð4/ð8 12.13.45 EQQZðð5I OPC SUBTASK AUTO RECOVERY IS BEING STARTED ð4/ð8 12.13.45 EQQZðð5I OPC SUBTASK JT LOG ARCHIVER IS BEING STARTED ð4/ð8 12.13.45 EQQZðð5I OPC SUBTASK EXTERNAL ROUTER IS BEING STARTED ð4/ð8 12.13.45 EQQZðð5I OPC SUBTASK WS ANALYZER IS BEING STARTED ð4/ð8 12.13.45 EQQNð8ðI THE LOG ARCHIVER TASK HAS STARTED ð4/ð8 12.13.46 EQQZð13I NOW PROCESSING PARAMETER LIBRARY MEMBER STDAR ð4/ð8 12.13.46 EQQZð15I INIT STATEMENT: AROPTS PREDWS(CPUᑍ) ð4/ð8 12.13.46 EQQZð16I RETURN CODE FOR THIS STATEMENT IS: ðððð ð4/ð8 12.13.46 EQQZð14I MAXIMUM RETURN CODE FOR PARAMETER MEMBER STDAR IS: ðððð ð4/ð8 12.13.46 EQQW5ð5I THE WORK STATION ANALYZER TASK HAS STARTED ð4/ð8 12.13.46 EQQZð85I OPC SUBTASK GS EXECUTOR ð1 IS BEING STARTED ð4/ð8 12.13.46 EQQCðð1I THE AUTOMATIC RECOVERY SUBTASK HAS STARTED ð4/ð8 12.13.46 EQQZð85I OPC SUBTASK GS EXECUTOR ð2 IS BEING STARTED ð4/ð8 12.13.46 EQQEXð1I THE EXTERNAL ROUTER TASK HAS STARTED ð4/ð8 12.13.46 EQQZð85I OPC SUBTASK GS EXECUTOR ð3 IS BEING STARTED ð4/ð8 12.13.46 EQQZð85I OPC SUBTASK GS EXECUTOR ð4 IS BEING STARTED ð4/ð8 12.13.46 EQQZð85I OPC SUBTASK GS EXECUTOR ð5 IS BEING STARTED ð4/ð8 12.13.46 EQQGðð1I SUBTASK GENERAL SERVICE HAS STARTED ð4/ð8 12.13.46 EQQEð25I THE EVENT MANAGER HAS STARTED ð4/ð8 12.13.46 EQQEð17I THE ETT FUNCTION IS ACTIVATED ð4/ð8 12.13.46 EQQGðð1I SUBTASK GS EXECUTOR ð1 HAS STARTED ð4/ð8 12.13.46 EQQGðð1I SUBTASK GS EXECUTOR ð2 HAS STARTED ð4/ð8 12.13.46 EQQGðð1I SUBTASK GS EXECUTOR ð3 HAS STARTED ð4/ð8 12.13.46 EQQGðð1I SUBTASK GS EXECUTOR ð4 HAS STARTED ð4/ð8 12.13.46 EQQGðð1I SUBTASK GS EXECUTOR ð5 HAS STARTED ð4/ð8 12.17.29 EQQVð24I ACB SUCCESSFULLY OPENED ð4/ð8 12.17.59 EQQVð36I SESSION NCFFNðð2-NCFFNðð3 ESTABLISHED ð4/ð8 12.2ð.35 EQQNð51I A CURRENT PLAN BACKUP PROCESS HAS STARTED. TRIGGER WAS: BACKUP CMD ð4/ð8 12.2ð.35 EQQNð12I OPC JOB TRACKING EVENTS ARE NOW BEING LOGGED ON FILE EQQJTð2 ð4/ð8 12.2ð.35 EQQQ5ð7I A SPECIAL RESOURCE DATASPACE BACKUP PROCESS HAS STARTED ð4/ð8 12.2ð.35 EQQQ5ð8I A SPECIAL RESOURCE DATASPACE BACKUP PROCESS HAS ENDED ð4/ð8 12.2ð.35 EQQQ5ð8I ððððððð3 RECORDS WERE WRITTEN TO CX ð4/ð8 12.2ð.38 EQQNð56I A CURRENT PLAN COPY PROCESS HAS STARTED ð4/ð8 12.2ð.4ð EQQNð57I A CURRENT PLAN DATA SET WAS SUCCESSFULLY COPIED: FROMDD=EQQCP1DS, TODD=EQQCP2DS ð4/ð8 12.2ð.4ð EQQNð23I VSAM LSR BUFFERS HAVE BEEN SUCCESSFULLY DELETED FOR VSAM FILE EQQCP2DS ð4/ð8 12.2ð.41 EQQNð18I VSAM LSR BUFFERS HAVE BEEN SUCCESSFULLY ALLOCATED FOR VSAM FILE EQQCP2DS ð4/ð8 12.2ð.41 EQQNð18I NUMBER OF INDEX BUFFERS ARE ððððð6 WITH SIZE ð16384 ð4/ð8 12.2ð.41 EQQNð18I NUMBER OF DATA BUFFERS ARE ðððð1ð WITH SIZE ð32768 ð4/ð8 12.2ð.41 EQQNð9ðI THE JOB TRACKING LOG DATA SET DEFINED BY DDNAME EQQJTð1 HAS BEEN ð4/ð8 12.2ð.41 EQQNð9ðI COPIED TO THE JOB TRACKING LOG ARCHIVE DATA SET ð4/ð8 12.2ð.57 EQQZðððI A STOP OPC COMMAND HAS BEEN RECEIVED ð4/ð8 12.2ð.57 EQQNðððI THE NORMAL MODE MANAGER TASK HAS BEEN REQUESTED TO TERMINATE ð4/ð8 12.2ð.57 EQQSUð2I THE SUBMIT TASK HAS ENDED ð4/ð8 12.2ð.57 EQQEXð2I THE EXTERNAL ROUTER TASK HAS ENDED ð4/ð8 12.2ð.57 EQQZð34I OPC SUBTASK DATA ROUTER TASK HAS ENDED. ð4/ð8 12.2ð.57 EQQZð34I SUBTASK WAS ACTIVE 453 SECONDS AND USED ð.1 CPU SECONDS ð4/ð8 12.2ð.57 EQQZð34I OPC SUBTASK APPC TASK HAS ENDED. ð4/ð8 12.2ð.57 EQQZð34I SUBTASK WAS ACTIVE 453 SECONDS AND USED ð.ð CPU SECONDS ð4/ð8 12.2ð.57 EQQZð34I OPC SUBTASK JOB SUBMIT TASK HAS ENDED. ð4/ð8 12.2ð.57 EQQZð34I SUBTASK WAS ACTIVE 453 SECONDS AND USED ð.1 CPU SECONDS ð4/ð8 12.2ð.57 EQQEðððI TOTAL NUMBER OF EVENTS PROCESSED BY THE EVENT MANAGER TASK IS: 34 ð4/ð8 12.2ð.57 EQQEðððI NUMBER OF EVENTS SINCE THE PREVIOUS MESSAGE IS: 34
Figure 16 (Part 3 of 5). Sample Message Log for a Controller
Chapter 5. Verifying Tivoli OPC Installation 123 Verifying the Installation
ð4/ð8 12.2ð.57 EQQEðððI EVENT MANAGER QUEUE LENGTH STATISTICS FOLLOW: ð4/ð8 12.2ð.57 EQQEðððI TOTAL Q1 Q2 Q5 Q1ð Q2ð Q5ð Q1ðð >1ðð ð4/ð8 12.2ð.57 EQQEðððI 31 2821ððððð ð4/ð8 12.2ð.57 EQQEðð6I EVENT MANAGER EVENT TYPE STATISTICS FOLLOW: ð4/ð8 12.2ð.57 EQQEðð6I TYPE NTOT NNEW TTOT TNEW TAVG NAVG NSUS ð4/ð8 12.2ð.57 EQQEðð7I ALL 34 34 ð.2 ð.2 ð.ðð ð.ðð ð ð4/ð8 12.2ð.57 EQQEðð7I 1 3 3 ð.ð ð.ð ð.ð3 ð.ð3 ð ð4/ð8 12.2ð.57 EQQEðð7I 2 3 3 ð.ð ð.ð ð.ð2 ð.ð2 ð ð4/ð8 12.2ð.57 EQQEðð7I 3S ð ð ð.ð ð.ð ð.ðð ð.ðð ð ð4/ð8 12.2ð.57 EQQEðð7I 3J 4 4 ð.ð ð.ð ð.ðð ð.ðð ð ð4/ð8 12.2ð.57 EQQEðð7I 3P 4 4 ð.1 ð.1 ð.ð2 ð.ð2 ð ð4/ð8 12.2ð.57 EQQEðð7I 4 ð ð ð.ð ð.ð ð.ðð ð.ðð ð ð4/ð8 12.2ð.57 EQQEðð7I 5 12 12 ð.ð ð.ð ð.ðð ð.ðð ð ð4/ð8 12.2ð.57 EQQEðð7I USER ð ð ð.ð ð.ð ð.ðð ð.ðð ð ð4/ð8 12.2ð.57 EQQEðð7I CATM ð ð ð.ð ð.ð ð.ðð ð.ðð ð ð4/ð8 12.2ð.57 EQQEðð7I OTHR 8 8 ð.ð ð.ð ð.ðð ð.ðð ð ð4/ð8 12.2ð.57 EQQEðð4I CP ENQ LOCK STATISTICS SINCE PREVIOUS MESSAGE FOLLOW: ð4/ð8 12.2ð.57 EQQEðð4I NAME NEXCL NSHRD THELD TWAIT AHELD AWAIT ð4/ð8 12.2ð.57 EQQEðð5I NORMAL MODE MGR 18 ð 7.ð ð.ð ð.39 ð.ðð ð4/ð8 12.2ð.57 EQQEðð5I WS ANALYZER 7 ð ð.7 ð.1 ð.1ð ð.ð2 ð4/ð8 12.2ð.57 EQQEðð5I EVENT MANAGER 31 ð ð.2 5.6 ð.ðð ð.18 ð4/ð8 12.2ð.57 EQQVð37I SESSION NCFFNðð2-NCFFNðð3 ENDED ð4/ð8 12.2ð.57 EQQCðð3I THE AUTOMATIC RECOVERY SUBTASK HAS ENDED NORMALLY ð4/ð8 12.2ð.57 EQQTAð2I THE TCP/IP COMMUNICATION TASK HAS ENDED ð4/ð8 12.2ð.57 EQQATð1I THE APPC TRACKER TASK HAS ENDED ð4/ð8 12.2ð.57 EQQGð1ðI GENERAL SERVICE REQUEST STATISTICS FOLLOW: ð4/ð8 12.2ð.57 EQQGð1ðI TYPE TOTAL NEWRQS TOTTIME NEWTIME TOTAVG NEWAVG ð4/ð8 12.2ð.57 EQQGð11I ALL ð ð ð.ð ð.ð ð.ðð ð.ðð ð4/ð8 12.2ð.57 EQQVð2ðI ACB SUCCESSFULLY CLOSED ð4/ð8 12.2ð.57 EQQZð34I OPC SUBTASK EXTERNAL ROUTER HAS ENDED. ð4/ð8 12.2ð.57 EQQZð34I SUBTASK WAS ACTIVE 431 SECONDS AND USED ð.ð CPU SECONDS ð4/ð8 12.2ð.57 EQQEð23I THE EVENT MANAGER ENDED NORMALLY ð4/ð8 12.2ð.57 EQQW5ð3I THE WORK STATION ANALYZER ENDED NORMALLY ð4/ð8 12.2ð.57 EQQGðð3I SUBTASK GS EXECUTOR ð1 HAS ENDED ð4/ð8 12.2ð.57 EQQGðð3I SUBTASK GS EXECUTOR ð2 HAS ENDED ð4/ð8 12.2ð.57 EQQVðð6I NCF APPLICATION ENDED ð4/ð8 12.2ð.57 EQQZð34I OPC SUBTASK AUTO RECOVERY HAS ENDED. ð4/ð8 12.2ð.57 EQQZð34I SUBTASK WAS ACTIVE 431 SECONDS AND USED ð.ð CPU SECONDS ð4/ð8 12.2ð.57 EQQZð34I OPC SUBTASK TCP/IP TASK HAS ENDED. ð4/ð8 12.2ð.57 EQQZð34I SUBTASK WAS ACTIVE 431 SECONDS AND USED ð.ð CPU SECONDS ð4/ð8 12.2ð.57 EQQZð34I OPC SUBTASK APPC TRACKER HAS ENDED. ð4/ð8 12.2ð.57 EQQZð34I SUBTASK WAS ACTIVE 431 SECONDS AND USED ð.ð CPU SECONDS ð4/ð8 12.2ð.57 EQQGðð3I SUBTASK GS EXECUTOR ð3 HAS ENDED ð4/ð8 12.2ð.57 EQQGðð3I SUBTASK GS EXECUTOR ð4 HAS ENDED ð4/ð8 12.2ð.57 EQQGðð3I SUBTASK GS EXECUTOR ð5 HAS ENDED ð4/ð8 12.2ð.57 EQQEð18I THE ETT FUNCTION IS DEACTIVATED ð4/ð8 12.2ð.57 EQQZð34I OPC SUBTASK VTAM I/O TASK HAS ENDED. ð4/ð8 12.2ð.57 EQQZð34I SUBTASK WAS ACTIVE 454 SECONDS AND USED ð.ð CPU SECONDS ð4/ð8 12.2ð.57 EQQZð34I OPC SUBTASK WS ANALYZER HAS ENDED. ð4/ð8 12.2ð.57 EQQZð34I SUBTASK WAS ACTIVE 431 SECONDS AND USED ð.4 CPU SECONDS ð4/ð8 12.2ð.57 EQQZð34I OPC SUBTASK EVENT MANAGER HAS ENDED. ð4/ð8 12.2ð.57 EQQZð34I SUBTASK WAS ACTIVE 431 SECONDS AND USED ð.ð CPU SECONDS ð4/ð8 12.21.ð3 EQQZð34I OPC SUBTASK GS EXECUTOR ð1 HAS ENDED. ð4/ð8 12.21.ð3 EQQZð34I SUBTASK WAS ACTIVE 431 SECONDS AND USED ð.ð CPU SECONDS ð4/ð8 12.21.ð3 EQQZð34I OPC SUBTASK GS EXECUTOR ð2 HAS ENDED. ð4/ð8 12.21.ð3 EQQZð34I SUBTASK WAS ACTIVE 431 SECONDS AND USED ð.ð CPU SECONDS
Figure 16 (Part 4 of 5). Sample Message Log for a Controller
124 Tivoli OPC Installation Guide Verifying the Installation
ð4/ð8 12.21.ð3 EQQZð34I OPC SUBTASK GS EXECUTOR ð3 HAS ENDED. ð4/ð8 12.21.ð3 EQQZð34I SUBTASK WAS ACTIVE 431 SECONDS AND USED ð.ð CPU SECONDS ð4/ð8 12.21.ð3 EQQZð34I OPC SUBTASK GS EXECUTOR ð4 HAS ENDED. ð4/ð8 12.21.ð3 EQQZð34I SUBTASK WAS ACTIVE 431 SECONDS AND USED ð.ð CPU SECONDS ð4/ð8 12.21.ð3 EQQZð34I OPC SUBTASK GS EXECUTOR ð5 HAS ENDED. ð4/ð8 12.21.ð3 EQQZð34I SUBTASK WAS ACTIVE 431 SECONDS AND USED ð.ð CPU SECONDS ð4/ð8 12.21.ð3 EQQGðð3I SUBTASK GENERAL SERVICE HAS ENDED ð4/ð8 12.21.ð3 EQQZð34I OPC SUBTASK GENERAL SERVICE HAS ENDED. ð4/ð8 12.21.ð3 EQQZð34I SUBTASK WAS ACTIVE 437 SECONDS AND USED ð.ð CPU SECONDS ð4/ð8 12.21.ð5 EQQNð81I THE LOG ARCHIVER TASK HAS ENDED ð4/ð8 12.21.ð5 EQQZð34I OPC SUBTASK JT LOG ARCHIVER HAS ENDED. ð4/ð8 12.21.ð5 EQQZð34I SUBTASK WAS ACTIVE 439 SECONDS AND USED ð.ð CPU SECONDS ð4/ð8 12.21.ð5 EQQN1ð7I THE NORMAL MODE MANAGER TASK HAS ENDED ð4/ð8 12.21.ð5 EQQZð34I OPC SUBTASK NORMAL MODE MGR HAS ENDED. ð4/ð8 12.21.ð5 EQQZð34I SUBTASK WAS ACTIVE 461 SECONDS AND USED 7.ð CPU SECONDS ð4/ð8 12.21.ð6 EQQZ173I SSX BLOCK OF VERSION ð6HSPC21ð SUCCESSFULLY RESTORED ð4/ð8 12.21.ð8 EQQZðð6I NO ACTIVE OPC SUBTASKS. OPC IS ENDING
Figure 16 (Part 5 of 5). Sample Message Log for a Controller
Tracker Message Log Look for these messages in the message log of each tracker:
Active data-router-task messages EQQZðð5I OPC SUBTASK DATA ROUTER TASK IS BEING STARTED EQQFðð1I DATA ROUTER TASK INITIALIZATION IS COMPLETE
Active submit-task messages EQQZðð5I OPC SUBTASK JOB SUBMIT TASK IS BEING STARTED EQQSUð1I THE SUBMIT TASK HAS STARTED
Also, verify that the tracker has started an event writer. You should see these messages:
Active event-writer messages EQQZðð5I OPC SUBTASK EVENT WRITER IS BEING STARTED EQQWð65I EVENT WRITER STARTED
If you have specified that catalog management should be active, you should see these messages:
Active catalog-management messages EQQZðð5I OPC SUBTASK CATALOG MGT TASK IS BEING STARTED EQQD1ð1I CATALOG MANAGEMENT INITIALIZATION COMPLETE
If the tracker forwards events to the controller, ensure that an event-reader function is specified. This can be a separate event-reader task or an event writer that has been started with the EWSEQNO keyword. In some configurations, both functions can be started in a tracker. See Figure 23 on page 180.
Chapter 5. Verifying Tivoli OPC Installation 125 Verifying the Installation
Although no messages are issued if you use EWSEQNO to start the reader function, check that EWSEQNO appears on the EWTROPTS statement and that the return code for this statement is 0. If you have specified a separate event-reader function, check that these messages appear: Active event-reader messages EQQZðð5I OPC SUBTASK EVENT READER IS BEING STARTED EQQRð25I ERDR ð1 STARTED
The numeric value on message EQQR025I indicates which event reader is being started. The same value cannot be specified on EWSEQNO and ERSEQNO keywords at the same node, and no more than 16 reader tasks can be specified at this node. Note: If the tracker uses an XCF connection, no messages appear in the tracker message log unless an error has occurred. To verify XCF connection messages, check the message log of the controller.
If the tracker uses an NCF connection, check that these messages appear (where NCFTRK01 and NCFCON01 represent the VTAM application IDs of the tracker and controller):
Active NCF-connection messages EQQZðð5I OPC SUBTASK VTAM I/O TASK IS BEING STARTED EQQVðð1I NCF APPLICATION STARTED EQQVð24I ACB SUCCESSFULLY OPENED EQQVð36I SESSION NCFTRKð1-NCFCONð1 ESTABLISHED EQQVð4ðI CURRENTLY RUNNING WITH 'NCFCONð1' AS CONTROLLER
Figure 17 on page 127 shows an example of the MLOG for a tracker. The tracker is connected to the controller via a VTAM link. The VTAM application IDs are NCFTRK01 for the tracker and NCFCON01 for the controller. The controller is active.
126 Tivoli OPC Installation Guide Verifying the Installation
ð4/ð8 12.14.ð8 EQQZð13I NOW PROCESSING PARAMETER LIBRARY MEMBER TRKV ð4/ð8 12.14.ð8 EQQZð15I INIT STATEMENT: OPCOPTS OPCHOST(NO) ð4/ð8 12.14.ð8 EQQZð15I INIT STATEMENT: NCFTASK(YES) ð4/ð8 12.14.ð8 EQQZð15I INIT STATEMENT: NCFAPPL(NCFFNðð3) ð4/ð8 12.14.ð8 EQQZð15I INIT STATEMENT: CATMGT(YES) ð4/ð8 12.14.ð8 EQQZð15I INIT STATEMENT: JCCTASK(NO) ð4/ð8 12.14.ð8 EQQZð15I INIT STATEMENT: EWTRTASK(YES) ð4/ð8 12.14.ð8 EQQZð15I INIT STATEMENT: EWTRPARM(WTRPARMS) ð4/ð8 12.14.ð8 EQQZð15I INIT STATEMENT: ERDRTASK(ð) ð4/ð8 12.14.ð8 EQQZð15I INIT STATEMENT: SSCMNAME(EQQSSCMC,TEMPORARY) ð4/ð8 12.14.ð8 EQQZð15I INIT STATEMENT: BUILDSSX(REBUILD) ð4/ð8 12.14.ð8 EQQZð15I INIT STATEMENT: ð4/ð8 12.14.ð8 EQQZð16I RETURN CODE FOR THIS STATEMENT IS: ðððð ð4/ð8 12.14.ð8 EQQZð15I INIT STATEMENT: JOBOPTS CHSMWAIT(1) ð4/ð8 12.14.ð8 EQQZð15I INIT STATEMENT: CATMCLAS(J) ð4/ð8 12.14.ð8 EQQZð15I INIT STATEMENT: JOBLOGRETRIEVAL(DELAYED) ð4/ð8 12.14.ð8 EQQZð16I RETURN CODE FOR THIS STATEMENT IS: ðððð ð4/ð8 12.14.ð8 EQQZð15I INIT STATEMENT: AUTHDEF CLASS(IBMOPC) SUBRESOURCES(RL.WSNAME SR.SRNAME) ð4/ð8 12.14.ð8 EQQZð15I INIT STATEMENT: ð4/ð8 12.14.ð8 EQQZð16I RETURN CODE FOR THIS STATEMENT IS: ðððð ð4/ð8 12.14.ð8 EQQZð15I INIT STATEMENT: EXITS CALLðð(NO) ð4/ð8 12.14.ð8 EQQZð15I INIT STATEMENT: CALLð1(NO) ð4/ð8 12.14.ð8 EQQZð15I INIT STATEMENT: CALLð2(NO) ð4/ð8 12.14.ð8 EQQZð15I INIT STATEMENT: CALLð3(NO) ð4/ð8 12.14.ð8 EQQZð15I INIT STATEMENT: CALLð4(NO) ð4/ð8 12.14.ð8 EQQZð15I INIT STATEMENT: CALLð5(NO) ð4/ð8 12.14.ð8 EQQZð15I INIT STATEMENT: CALLð6(NO) ð4/ð8 12.14.ð8 EQQZð15I INIT STATEMENT: CALLð7(NO) ð4/ð8 12.14.ð8 EQQZð15I INIT STATEMENT: CALLð8(NO) ð4/ð8 12.14.ð8 EQQZð15I INIT STATEMENT: CALLð9(NO) ð4/ð8 12.14.ð8 EQQZð15I INIT STATEMENT: CALL1ð(NO) ð4/ð8 12.14.ð8 EQQZð15I INIT STATEMENT: ð4/ð8 12.14.ð8 EQQZð16I RETURN CODE FOR THIS STATEMENT IS: ðððð ð4/ð8 12.14.ð8 EQQZð15I INIT STATEMENT: TRROPTS HOSTCON(SNA) ð4/ð8 12.14.ð8 EQQZð15I INIT STATEMENT: SNAHOST(NCFFNðð2) ð4/ð8 12.14.ð8 EQQZð15I INIT STATEMENT: ð4/ð8 12.14.ð8 EQQZð16I RETURN CODE FOR THIS STATEMENT IS: ðððð ð4/ð8 12.14.ð8 EQQZð14I MAXIMUM RETURN CODE FOR PARAMETER MEMBER TRKV IS: ðððð ð4/ð8 12.14.ð8 EQQZ172I SSX BLOCK OF VERSION ð1HOPC2ðð SUCCESSFULLY BUILT ð4/ð8 12.14.ð8 EQQZð73I OPC HAS RECOGNIZED THAT THIS IS A JES2 SYSTEM WITH ð4/ð8 12.14.ð8 EQQZð73I COMMAND CHARACTER $ AND THAT THE NJE NODE NAME IS ROMEMVS ð4/ð8 12.14.ð8 EQQZðð5I OPC SUBTASK EVENT WRITER IS BEING STARTED ð4/ð8 12.14.ð8 EQQZðð5I OPC SUBTASK VTAM I/O TASK IS BEING STARTED ð4/ð8 12.14.ð8 EQQZðð5I OPC SUBTASK JOB SUBMIT TASK IS BEING STARTED ð4/ð8 12.14.ð8 EQQZðð5I OPC SUBTASK DATA ROUTER TASK IS BEING STARTED ð4/ð8 12.14.ð8 EQQZðð5I OPC SUBTASK CATALOG MGT TASK IS BEING STARTED ð4/ð8 12.14.ð9 EQQZð13I NOW PROCESSING PARAMETER LIBRARY MEMBER WTRPARMS ð4/ð8 12.14.ð9 EQQZð15I INIT STATEMENT: EWTROPTS HOLDJOB(USER) ð4/ð8 12.14.ð9 EQQZð15I INIT STATEMENT: EWWAIT(7) ð4/ð8 12.14.ð9 EQQZð15I INIT STATEMENT: SUREL(NO) ð4/ð8 12.14.ð9 EQQZð15I INIT STATEMENT: EWSEQNO(ð1) ð4/ð8 12.14.ð9 EQQZð15I INIT STATEMENT: STEPEVENTS(NZERO) ð4/ð8 12.14.ð9 EQQZð15I INIT STATEMENT: RETCODE(HIGHEST)
Figure 17 (Part 1 of 2). Sample Message Log for a Tracker
Chapter 5. Verifying Tivoli OPC Installation 127 Verifying the Installation
ð4/ð8 12.14.ð9 EQQZð16I RETURN CODE FOR THIS STATEMENT IS: ðððð ð4/ð8 12.14.ð9 EQQZð14I MAXIMUM RETURN CODE FOR PARAMETER MEMBER WTRPARMS IS: ðððð ð4/ð8 12.14.ð9 EQQZð64I OPC WILL USE THE NJE NODE NAME ROMEMVS FOR JOBS HELD ON THIS NODE ð4/ð8 12.14.ð9 EQQVðð1I NCF APPLICATION STARTED ð4/ð8 12.14.ð9 EQQZð65I OPC WILL RELEASE HELD JOBS USING THE JES2 COMMAND CHARACTER $ ð4/ð8 12.14.ð9 EQQWð26I THE JOB COMPLETION CHECKER STARTED ð4/ð8 12.14.ð9 EQQFðð1I DATA ROUTER TASK INITIALIZATION IS COMPLETE ð4/ð8 12.14.ð9 EQQD1ð1I CATALOG MANAGEMENT INITIALIZATION COMPLETE ð4/ð8 12.14.ð9 EQQSU12I MAX NUMBER OF WORKSTATIONS CHECKPOINTED BY THIS SUBMIT TASK: ðð46 ð4/ð8 12.14.ð9 EQQSUð1I THE SUBMIT TASK HAS STARTED ð4/ð8 12.14.14 EQQWð65I EVENT WRITER STARTED ð4/ð8 12.15.59 EQQVð33E ACB OPEN FAILED FOR THE LAST 2 MINUTES - NCF APPLICATION NOT ACTIVE ð4/ð8 12.17.49 EQQVð24I ACB SUCCESSFULLY OPENED ð4/ð8 12.17.59 EQQVð36I SESSION NCFFNðð3-NCFFNðð2 ESTABLISHED ð4/ð8 12.18.ð9 EQQVð4ðI CURRENTLY RUNNING WITH 'NCFFNðð2' AS CONTROLLER ð4/ð8 12.22.23 EQQZðððI A STOP OPC/ESA COMMAND HAS BEEN RECEIVED ð4/ð8 12.22.23 EQQWð11I THE EVENT WRITER ENDED NORMALLY ð4/ð8 12.22.23 EQQVð37I SESSION NCFFNðð3-NCFFNðð2 ENDED ð4/ð8 12.22.23 EQQSUð2I THE SUBMIT TASK HAS ENDED ð4/ð8 12.22.23 EQQZð34I OPC SUBTASK DATA ROUTER TASK HAS ENDED. ð4/ð8 12.22.23 EQQZð34I SUBTASK WAS ACTIVE 494 SECONDS AND USED ð.ð CPU SECONDS ð4/ð8 12.22.23 EQQZð34I OPC SUBTASK CATALOG MGT TASK HAS ENDED. ð4/ð8 12.22.23 EQQZð34I SUBTASK WAS ACTIVE 494 SECONDS AND USED ð.ð CPU SECONDS ð4/ð8 12.22.23 EQQZð34I OPC SUBTASK EVENT WRITER HAS ENDED. ð4/ð8 12.22.23 EQQZð34I SUBTASK WAS ACTIVE 494 SECONDS AND USED ð.1 CPU SECONDS ð4/ð8 12.22.23 EQQZð34I OPC SUBTASK JOB SUBMIT TASK HAS ENDED. ð4/ð8 12.22.23 EQQZð34I SUBTASK WAS ACTIVE 494 SECONDS AND USED ð.2 CPU SECONDS ð4/ð8 12.22.27 EQQVð2ðI ACB SUCCESSFULLY CLOSED ð4/ð8 12.22.27 EQQVðð6I NCF APPLICATION ENDED ð4/ð8 12.22.27 EQQZð34I OPC SUBTASK VTAM I/O TASK HAS ENDED. ð4/ð8 12.22.27 EQQZð34I SUBTASK WAS ACTIVE 498 SECONDS AND USED ð.ð CPU SECONDS ð4/ð8 12.22.28 EQQZ173I SSX BLOCK OF VERSION ð6HSPC21ð SUCCESSFULLY RESTORED ð4/ð8 12.22.3ð EQQZðð6I NO ACTIVE OPC SUBTASKS. OPC IS ENDING
Figure 17 (Part 2 of 2). Sample Message Log for a Tracker
Verifying Workload Submission Now verify that Tivoli OPC can submit work and that the work is sent to the correct destination.
Controlling System You can use this procedure for the controlling system: 1. Create a workstation description, leave the destination field blank. This means that operations will be submitted to the system where the controller is started. 2. Create an application description. Define at least one operation on the workstation you have created. Submit a daily planning extend or replan batch job to include the new workstation in the current plan. Add an occurrence of this application to the current plan. 3. Verify that the operations run successfully on this system and that they are reported as complete in the current plan. 4. Check that submit events are created in the event dataset for the controlling system (see “Verifying Job Submission” on page 129).
128 Tivoli OPC Installation Guide Verifying the Installation
Controlled Systems If you have controlled Tivoli OPC systems in your configuration, you can use this procedure to check that work is sent to these destinations, that it is submitted, and that events are returned to the controller: 1. Create a workstation description for each destination. In the destination field, remember to specify the submit/release dataset name, the XCF member name of the tracker, or the tracker VTAM application ID, depending on the connection. Ensure that the trackers are active. 2. Add an application occurrence to the current plan with operations defined on each of the workstations. 3. Verify that the operations run successfully on the correct system and that they are reported as complete in the current plan. 4. Check that submit events are created in the event dataset for each controlled system (see “Verifying Job Submission”).
If your configuration includes a MAS complex, you can specify only one workstation description to represent all systems in the complex. If this is the case, ensure that a job is run on each system in the complex. Verify that events are received at the controller by checking that the operations are reported as complete in the current plan.
Notes: 1. If you create a workstation description after the current plan has been created, you must either replan or extend the current plan to use this workstation. 2. You must also specify workstation destinations in the ROUTOPTS initialization statement. You must restart the controller if you update ROUTOPTS.
Verifying Job Submission When Tivoli OPC submits work, a submit event is written to the event dataset. A submit event is prefixed with an I, and can be one of these: IJ1 Job JCL. A job has been submitted. IJ2 Started-task JCL. A started task has been started. IWTO An operation has been initiated for a general workstation with the WTO option. The submit task causes message EQQW775I to be issued. Check each system on which Tivoli OPC is installed to ensure that the destination can be reached by the controller and that the relevant submit events are being created in the event dataset. That is, if Tivoli OPC will submit jobs, start started tasks, and initiate WTO operations, verify that all the event types are created in the event dataset. You need not test all these functions if Tivoli OPC will not be used for a particular operation.
Chapter 5. Verifying Tivoli OPC Installation 129 Verifying the Installation
To perform this test for all type I events, start an operation on each of three workstations, all of which specify the destination of the system you are testing. The workstations must be a computer automatic workstation for IJ1 events, a computer automatic workstation with the started-task option for IJ2 events, and a general WTO workstation for IWTO events. Follow this procedure to verify workload submission: 1. Ensure that you have the correct workstations specified in the workstation description database. 2. Create a test application with an operation for each workstation you want to test, and add it to the current plan. 3. When the application has completed, browse the event dataset, and verify that the required type I events have been created. 4. If the operations are not started, check that the workstation status is ACTIVE and that the workstation is not WAITING FOR CONNECTION, which means that the Tivoli OPC controller is waiting for the corresponding tracker to communicate.
Verifying Takeover by a Standby Controller To verify that a standby controller can take over the functions of the controller, perform these actions: 1. Stop the controller. 2. Order the standby controller to take over the functions of the controller, using this command: MODIFY ssname,TAKEOVER. 3. Check that this message appears in the message log: Standby controller message EQQZ129I TAKEOVER IN PROGRESS
When the standby controller has taken over the functions of the controller, more messages will appear in the message log. These are the same messages that appear when a controller is started. Verify that the takeover was successful by following the procedures used in the verification of the controller.
130 Tivoli OPC Installation Guide
Part 3. Migrating
Copyright IBM Corp. 1991, 1999 131
132 Tivoli OPC Installation Guide
Chapter 6. Planning for Migration
This chapter provides information to help you plan your installation’s migration to Tivoli OPC. Before attempting to perform a migration, you should develop a migration plan to ensure a smooth and orderly transition. A well thought-out and documented migration plan can help minimize any interruption of service. Your migration plan should address topics such as: Identifying which required and optional products are needed Evaluating new, changed, and deleted functions Defining which Tivoli OPC functions you want to add, delete, or modify Defining necessary changes to: – The configuration – The initialization statements – Installation modifications – Operational procedures – Other related products Determining any restrictions during the conversion period Estimating the amount of time the conversion will take Defining education requirements for operators and end users Preparing your staff and users for migration.
The content and extent of a migration plan can vary significantly from installation to installation. For example, installations that have many installation-specific modifications may require extensive planning due to the added complexity.
You should also consider the following areas when defining your installation’s migration plan: Installation Initialization Customization Operation
Installation Considerations IBM attempts to make the installation of new releases as easy as possible. Initially, you should install Tivoli OPC without taking any customization actions in order to achieve a stable environment. Refer to the Program Directory for specific instructions about using System Modification Program/Extended (SMP/E) to install Tivoli OPC.
From OPC/ESA Release 3 or later, you can migrate from or fall back to previous releases without IPLing MVS.
Copyright IBM Corp. 1991, 1999 133 Planning for Migration
Customization Considerations Tivoli OPC is designed as a general-purpose workload automation subsystem. As such, it may not meet all the requirements for your specific installation. IBM allows installations to implement installation exits and provides many callable services that can be used to supplement Tivoli OPC processing.
Carefully examine any customization that your site has installed. Determine whether the function is now provided in the product or if you need to modify the logic based on changes made to Tivoli OPC.
When new functions are added to Tivoli OPC, installation exits and macros used within installation exits can change. New installation exits or macros may also be introduced in a Tivoli OPC release. If a release provides a new installation exit, determine if your installation needs to implement the exit. A release can change an existing exit by modifying: What the installation exit expects on entry Return codes Tivoli OPC expects when the exit returns control to Tivoli OPC The function that the installation exit performs The processing that is performed before or after the exit.
Migration Strategies You need to consider these points when deciding the appropriate migration strategy for your enterprise: Controlled systems JES and SMF exits Migrating to existing subsystem definitions Migrating to new subsystem definitions Installation and verification Parallel testing
Controlled Tivoli OPC and OPC/A Systems Tivoli OPC supports connections between OPC/ESA Release 3 tracker systems, or Tivoli OPC Version 2 and the controller via shared DASD, XCF, and VTAM links. You can also connect OPC/A Release 2 EMS subsystems by VTAM or shared DASD. This means that you can migrate your subsystems gradually, starting with the controlling system or the controlled systems. If you choose to migrate the controlling system before the controlled systems, certain Tivoli OPC Version 2 functions will not be available on the OPC/ESA Release 3 and OPC/A controlled systems.
If you have installed a standby controller on one or more of your controlled OPC/ESA Release 3 systems, you should not start the standby controller until it has also been migrated to Tivoli OPC.
JES and SMF Exits JES and SMF exits supplied with Tivoli OPC Version 2 can also track work for OPC/A Release 2 and OPC/ESA Release 3 systems. The exits are always downward compatible. On OPC/A Release 2, systems you must have applied the fix for PN34198.
134 Tivoli OPC Installation Guide Planning for Migration
If you have the OPC/ESA Version 1 Release 3 Modification Level 1 controller installed and want to run a Tivoli OPC Version 2 Release 2 Tracker Agent, make sure that the fixes for the following APARs are installed: PN75247 PQ13241
If you have the Tivoli OPC Version 2 Release 1 controller installed and want to run a Tivoli OPC Version 2 Release 2 Tracker Agent, make sure that the fix for APAR PQ15072 is installed.
If you will migrate the controller before any trackers you do not need to be at any specific maintenance level.
Consider installing the Version 2 of the JES and SMF exits in your current production environment at least a week before you plan to migrate any of the address spaces to Tivoli OPC.
Migration Effect on Workload Monitor/2 Users OPC/ESA. Workload Monitor/2 users running an OPC/ESA Release 3 level of the feature can continue to use their current software level to communicate with a Tivoli OPC controller. You do not have to migrate the Workload Monitor/2 software at the same time as you migrate the controller.
Migrate your OPC/ESA Workload Monitor/2 users to the Tivoli OPC Version 2 level | of the software after you have migrated the controller.
Migrating to Existing Subsystem Definitions From Release 3 or later, you can migrate from or fall back to your current subsystems without having to IPL the MVS system.
By continuing to use your current subsystem names, you do not need to consider the effect of migration on these users of Tivoli OPC services: Host dialog users PIF programs API programs Callable services Console automation software
Keeping the same subsystem names reduces the installation effort of a new level of Tivoli OPC.
Migrating to New Subsystem Definitions If you want to parallel-test the new level of Tivoli OPC with your current level, you must create new subsystems for the Tivoli OPC Version 2 address space.
Getting the Right Software Parts The Tivoli OPC Version 2 load modules, panels, messages, and other software parts have the same name as they had in previous OPC/ESA Version 1 releases. You must ensure that the users of Tivoli OPC services execute the same level of software as the subsystem address space.
Chapter 6. Planning for Migration 135 Planning for Migration
This requirement does not apply to installations migrating from OPC/A, because the prefix of all software parts, except for OPSTAT and SRSTAT, is different in Tivoli OPC.
Load Modules Whether you choose to use the same dataset name for the Tivoli OPC Version 2 load modules as your previous environment is up to you. However, you need to consider the additional effort required on your part to coordinate the JCL changes required for callers of Tivoli OPC services such as: EQQEVPGM EQQUSINx EQQYCOM EQQYLTOP
If you do not currently STEPLIB to the Tivoli OPC load library, you need only ensure that the Tivoli OPC Version 2 library is listed first in the LNKLST concatenation and that the library remains empty until you are ready to cut over to Tivoli OPC Version 2 on the production system. Then you should copy the load modules into the library and perform an LLA refresh.
Two Tivoli OPC load modules must always be in a LNKLST library: EQQINITn The subsystem initialization module EQQSSCMn The subsystem communication module. However, this does not mean that you must reinitialize the subsystem to cut over Tivoli OPC Version 2 to production. The module names defined for EQQINIT and EQQSSCM in the SYS1.PARMLIB subsystem name table (IEFSSNnn) can be overridden when a Tivoli OPC Version 2 address space is created.
The BUILDSSX keyword of the OPCOPTS initialization statement can be used to rebuild the environment created during subsystem initialization at the new software level. When the address space is terminated, the previous environment is reinstated, thereby ensuring fallback to a previous release of OPC/ESA Version 1, or to OPC/A Release 2 if required.
The SSCMNAME keyword of the OPCOPTS initialization statement can be used to permanently, or temporarily, replace the EQQSSCMn module that was loaded into common storage at IPL. When the TEMPORARY value is defined, the named module is loaded into private storage of the Tivoli OPC address space, therefore events created while the address space is not active will use the EQQSSCMn from the previous IPL. When PERMANENT is specified, the old EQQSSCMn in common storage is replaced.
Permanent replacement of the EQQSSCMn module effects the SSX and prevents reinstatement of the subsystem to a previous release or version.
Attention: Do not specify PERMANENT in the SSCMNAME keyword and BUILDSSX(REBUILD) until you are certain that you will not need to fall back to a previous version or release.
Create backup copies of the old load module library before you replace the objects.
136 Tivoli OPC Installation Guide Planning for Migration
The ISPF environment Tivoli OPC ISPF dialog users must execute software parts that are at the same level as the Tivoli OPC controller address space. Again, using the same dataset names for software parts libraries, such as messages and panels, negates the requirement to change TSO logon procedures.
If you use the same dataset names, instruct dialog users to return to the TSO READY prompt after you have replaced the software parts and before they try to communicate with a Tivoli OPC controller.
The Tivoli OPC ISPF profile is automatically reinitialized when the EQQOPCAP panel (the Tivoli OPC main menu) is first displayed for a new release. Dialog users must enter the Tivoli OPC options dialog and redefine required values, such as the subsystem name.
Be sure to create backup copies of the old libraries before you replace the objects.
Migration Overview This section summarizes the steps you must perform before installing a new release of Tivoli OPC. You should plan for the migration by installing and stabilizing the new Tivoli OPC release without incorporating the new functions provided. Installing a new Tivoli OPC release without initially exploiting new functions allows you to create a stable environment.
Tivoli OPC Version 2 Migration Overview To install and activate Tivoli OPC Version 2, you must: 1. Ensure you have the required environment for Tivoli OPC Version 2 2. Make the necessary modifications 3. Stop the OPC/ESA or OPC/A release you are currently running 4. Convert the datasets 5. Start Tivoli OPC Version 2 Only summary information appears in this section. Detailed instructions about how to make specific changes are in the chapters that follow or in referenced publications.
Establishing the Required Environment You use SMP/E to install the Tivoli OPC Version 2 software. Refer to the Program Directory for specific instructions about using SMP/E to install Tivoli OPC Version 2.
Tivoli OPC Version 2 must run in the MVS, or OS/390 environments. The base control program must be at the MVS System Product Version 4 Release 1 level or later to support Tivoli OPC Version 2. XCF connections require MVS Version 4 Release 1, and APPC services require MVS Version 4 Release 2 Modification Level 2.
Chapter 6. Planning for Migration 137 Planning for Migration
Program Requirements Before installing Tivoli OPC Version 2, check INFOSYS and the preventive service bucket for a current list of the required products, their maintenance levels, and recommendations from the service organizations. When you are using INFOSYS, you can search for conversion information by using any of the following keywords: Tivoli OPC | HOPC300 Conversion The PSP for this release can be found in the TMEOPC2 upgrade. Read this document carefully before you start to install Tivoli OPC Version 2.
Your installation must have at least OPC/A Release 2 or OPC/ESA Release 2 installed.
Installation and Verification If you are migrating to existing subsystem definitions, you must perform these installation tasks: 1. Load the tracker software (“Loading Tracker Software” on page 36). 2. Load the controller software (“Loading Controller Software” on page 36). 3. Load the NLS software (“Loading National Language Support Software for the Controller” on page 37). 4. Execute the EQQJOBS CLIST (“Using the EQQJOBS Installation Aid” on page 38). 5. Install JES and SMF exits at Tivoli OPC Version 2 level (“Adding SMF and JES Exits for Event Tracking” on page 49). 6. Update PARMLIB (“Updating SYS1.PARMLIB” on page 51). OPC/A customers must update SMF and TSO parameters and the PPT. OPC/ESA Version 1 Release 3 customers need to update TSO parameters. 7. Allocate VSAM and non-VSAM datasets (“Allocating Tivoli OPC Data Sets” on page 67). 8. Update the JCL procedure for the Tivoli OPC address space (“Creating JCL Procedures for Tivoli OPC Address Spaces” on page 82). 9. Update the initialization statements (“Defining the Initialization Statements” on page 86). 10. OPC/A customers must update the ISPF environment (“Setting Up the ISPF Environment” on page 87).
Ensure you follow the subsystem verification procedures outlined in Chapter 5, “Verifying Tivoli OPC Installation” on page 105.
You can use the conversion program for both migration and fallback. You should consider testing your installation by migrating in the production environment and then falling back.
138 Tivoli OPC Installation Guide Planning for Migration
Parallel Testing If you want to perform the migration and then continue immediately into parallel testing in a job-tracking environment, you can use the following procedure as a guide. However, you should carefully consider the applicability of this procedure in your own Tivoli OPC Version 2 configuration. 1. Stop your production system. 2. Perform dataset conversion and copying. 3. Start your production system. 4. Start Tivoli OPC Version 2. You should also consider: If you start the JCC in both the production system and Tivoli OPC Version 2, the two JCCs cannot delete or requeue SYSOUT from the same SYSOUT class. You cannot start the catalog-management subtask for step-level restart in the Version 2 subsystem if the old subsystem is already running the subtask unless the Version 2 system uses the job-log-retrieval exit, EQQUX010, to retrieve the job logs. Do not specify HOLDJOB(YES) or HOLDJOB(USER) for more than one of the two systems. If you do, one system might incorrectly release jobs that are held by the other system. When you convert the VSAM datasets, it is recommended that you run the conversion of the JS file to verify that conversion has been done correctly. Then, before running the parallel test, reallocate empty JS files. (Otherwise, the test system might find valid production JCL on the active JS file and submit it to the JES subsystem.) You should start with an empty JCL library dataset (EQQJBLIB). Otherwise, the test system might submit production JCL incorrectly. To test that Tivoli OPC Version 2 submits jobs correctly, you should create test applications with job names that are not known to the production system. JCL for those jobs could then safely be inserted into EQQJBLIB. On the test system you should specify TRACK(ALL) and SUBFAILACTION(R) on the JTOPTS initialization statement. TSO commands or subroutines that have a specific name for the subsystem parameter will not report events to the test system. You should update any procedures, which are dependent on TSO commands or subroutines, if events should also be reported to the test system. If you are migrating from OPC/ESA Release 2 or later and you use NetView or a similar product to intercept messages, make sure that WTO (write-to-operator) messages are not issued by the test system. Otherwise, the test system might trigger some processing that impacts the production system. You should not use alert WTOs, deadline WTOs, or WTO operations on the test system. | If you start the Data Store in Tivoli OPC Version 2 Release 3, you should not | run the JCC function operating on the same class reserved to Data Store. If | you need to run JCC task in the production system, you have to prevent sysout | handling overlap. To do this reserve another class to filter the sysout that will | be handled by Data Store (see DSTFILTER parameter). Both the filter class | and the Data Store class must not be used by the production system.
Chapter 6. Planning for Migration 139 Planning for Migration
Using the preceding notes as a guide, you will be able to run one production system and one Tivoli OPC Version 2 test system in parallel. The work with the database dialogs and the long-term-planning functions can be fully tested this way. The job-tracking functions of the test system will be incomplete because only the specially created test jobs will be submitted by the test system. However, the tracking of work, including the tracking of applications and jobs in the production area, will be done normally.
140 Tivoli OPC Installation Guide
Chapter 7. Migration Actions
Migrating Data Sets to Tivoli OPC Version 2 For migration purposes, datasets fall into three categories: VSAM datasets that are copied and converted by the EQQICTOP migration program Non-VSAM datasets that you can copy, or use unchanged, in Version 2 VSAM and non-VSAM datasets that must be empty when you migrate to Tivoli OPC Version 2
Each of these categories is described on the following pages. First the EQQICTOP conversion program is outlined.
EQQICTOP VSAM Dataset Conversion Program With the EQQICTOP conversion program, you can migrate VSAM datasets from earlier releases of OPC/A and OPC/ESA to Tivoli OPC Version 2. You can also use the program to reverse the procedure in case you need to fall back to your old system. However, migration between OPC/ESA Release 1 and Tivoli OPC Version 2 must be done in two separate steps.
The EQQJOBS program creates JCL tailored to your installation specifications in the EQQICNVS member.
EQQICTOP is controlled by CONVERT statements in the SYSIN file. You can supply any number of these statements to EQQICTOP.
Syntax
55──CONVERT──FILE(─┬─AD─ ┬ ─ ) ──FROMREL(─┬─OPCAR2── ┬ ─ ) ──TOREL(─┬─OPCAR2── ┬ ─ ) ─ ─5% ├┤─CP─ ├─ESAR1─── ┤ ├─ESAR1─── ┤ ├┤─CX─ ├─ESAR2─── ┤ ├─ESAR2─── ┤ ├┤─JS─ ├─ESAR21── ┤ ├─ESAR21── ┤ ├┤─LT─ ├─ESAR3─── ┤ ├─ESAR3─── ┤ ├┤─OI─ ├─ESAR31── ┤ ├─ESAR31── ┤ ├┤─RD─ ├─OPCV2R1─ ┤ ├─OPCV2R1─ ┤ ├┤─SI─ ├─OPCV2R2─ ┤ ├─OPCV2R2─ ┤ | ├┤─TB─ └─OPCV2R3─ ┘ └─OPCV2R3─ ┘ └┘─WS─
Parameters FILE(file identifier) Defines the dataset to be converted. You can specify one of the following file identifiers on each CONVERT statement: AD Application descriptions and JCL variable tables CP The current plans, EQQCPnDS and EQQNCPDS CX The current plan extension, EQQCXDS and EQQNCXDS JS JCL repository and retrieved job logs LT Long-term plan OI Operator instructions
Copyright IBM Corp. 1991, 1999 141 Migration Actions
RD Special resource definitions SI Side information file, ETT criteria and Tivoli OPC configuration information TB Table space—used as input to the Release 3 migration; output is written to RD and SI WS Workstation descriptions, calendars, and periods Your conversion JCL should contain ddnames EQQxxIN and EQQxxOUT for each dataset that you want to convert, where xx is the file identifier. Table 33 shows the datasets needed when converting to or from the table space (TB) dataset.
Table 33. Datasets Needed for Table Space Conversion To V1 R2.1 and earlier To V1 R3 or later From R2.1 FILE(TB) with files TBIN FILE(TB) with files TBIN, and earlier and TBOUT RDOUT, and SIOUT From R3 or FILE(RD) with files RDIN, FILE(RD) with files RDIN later CXIN, and TBOUT, and and RDOUT, and FILE(SI) FILE(SI) with files SIIN and with files SIIN and SIOUT TBOUT
FROMREL(product identifier) Defines the product and release level of the input dataset. You can specify one of the following: OPCAR2 OPC/A Release 2 ESAR1 OPC/ESA Release 1 ESAR2 OPC/ESA Release 2.0 ESAR21 OPC/ESA Release 2.1 ESAR3 OPC/ESA Release 3 ESAR31 OPC/ESA Release 3.1 OPCV2R1 Tivoli OPC Version 2 Release 1 OPCV2R2 Tivoli OPC Version 2 Release 2 | OPCV2R3 Tivoli OPC Version 2 Release 3 TOREL(product identifier) Defines the product and release level of the output dataset. You can specify one of the following: OPCAR2 OPC/A Release 2 ESAR1 OPC/ESA Release 1 ESAR2 OPC/ESA Release 2 Release 2.0 ESAR21 OPC/ESA Release 2 Release 2.1 ESAR3 OPC/ESA Release 3 ESAR31 OPC/ESA Release 3.1. OPCV2R1 Tivoli OPC Version 2 Release 1 OPCV2R2 Tivoli OPC Version 2 Release 2 | OPCV2R3 Tivoli OPC Version 2 Release 3 Notes: 1. The conversion program does not support a direct migration between OPC/ESA Release 1 and Release 3 or later. You must use an intermediate step, Release 2 or Release 2.1. For example: Step 1: CONVERT FILE(file) FROMREL(ESAR1) TOREL(ESAR2) | Step 2: CONVERT FILE(file) FROMREL(ESAR2) TOREL(OPCV2R3)
142 Tivoli OPC Installation Guide Migration Actions
Other than this exception, you can specify FROMREL and TOREL values in any combination. If you specify the same value for FROMREL and TOREL, this reduces the migration job to a copy operation. 2. Conversion stops if there is a VSAM I/O error on one of the files. One such error is a duplicate key on the output file. This can occur if the output dataset is not empty. 3. You should migrate the currently active JCL-repository dataset. You can check whether the primary or alternate dataset is in use by selecting option 6 in the Query Current Plan dialog. You should do this when no more work is running and before you stop the OPC/A production control system (PCS) or Tivoli OPC controller. 4. Unless an error occurred when you stopped your production system, the table-space datasets will be equal. Use the EQQTB1DS dataset as input for the migration if you are migrating from OPC/ESA Release 1.2.1 or earlier. Output from this conversion is to EQQRDDS and EQQSIDS. Therefore, make sure that you include the EQQRDOUT and EQQSIOUT ddnames when you convert the table-space dataset. 5. You can use one of two methods to convert the current plan: If no error occurred when you stopped your production system, both primary and alternate current plans will be equal. Use EQQCP1DS as input to the conversion program. If the last action performed on your production system was to extend the current plan, use the new-current-plan dataset that was created on this system as input to the conversion program. This is the preferred method as it ensures you will not lose any job-tracking records, this is relevant if you use the tracklog (EQQTROUT) as an audit trail. In both cases, the output file must be the new-current-plan dataset (EQQNCPDS) on your Tivoli OPC Version 2 system. You can convert the current plan extension dataset using the same methods. 6. In addition to input and output ddnames for each VSAM file, the migration JCL should also contain the EQQMLOG and EQQMLIB ddnames. EQQMLOG is an output file for messages. EQQMLIB is an input file that contains the Tivoli OPC message library. 7. If you migrate from OPC/ESA 3.0 or earlier, after migration to Tivoli OPC Version 2, the original valid-to date and the run-cycle-out-of-effect date 99/12/31 will be moved to the new Tivoli OPC default valid-to date 71/12/31. If you have defined the ETTRCY1 period with the origin date 99/12/31, the origin date will be converted to the new Tivoli OPC high date 71/12/31.
Chapter 7. Migration Actions 143 Migration Actions
Example
| //OPCMIG JOB (777777,777),'Migrate to Tivoli OPC V2R3, MSGLEVEL=(1,1), // NOTIFY=&SYSUID,MSGCLASS=H,CLASS=A //ᑍ //CONVERT EXEC PGM=EQQICTOP,REGION=2ð48K //STEPLIB DD DISP=SHR,DSN=OPC.INST.LOADLIB //EQQMLIB DD DISP=SHR,DSN=OPC.INST.SEQQMSGð //EQQMLOG DD SYSOUT=ᑍ //EQQADIN DD DISP=SHR,DSN=CCOPC.OPCC.R3.AD //EQQADOUT DD DISP=OLD,DSN=CCOPC.OPCC.AD //EQQWSIN DD DISP=SHR,DSN=CCOPC.OPCC.R3.WS //EQQWSOUT DD DISP=OLD,DSN=CCOPC.OPCC.WS //EQQCPIN DD DISP=SHR,DSN=CCOPC.OPCC.R3.CP1 //EQQCPOUT DD DISP=OLD,DSN=CCOPC.OPCC.NCP //EQQCXIN DD DISP=SHR,DSN=CCOPC.OPCC.R3.CX //EQQCXOUT DD DISP=OLD,DSN=CCOPC.OPCC.NCX //EQQLTIN DD DISP=SHR,DSN=CCOPC.OPCC.R3.LT //EQQLTOUT DD DISP=OLD,DSN=CCOPC.OPCC.LT //EQQJSIN DD DISP=SHR,DSN=CCOPC.OPCC.R3.JS1 //EQQJSOUT DD DISP=OLD,DSN=CCOPC.OPCC.JS1 //EQQOIIN DD DISP=SHR,DSN=CCOPC.OPCC.R3.OI //EQQOIOUT DD DISP=OLD,DSN=CCOPC.OPCC.OI //EQQSIIN DD DISP=SHR,DSN=CCOPC.OPCC.R3.SI //EQQSIOUT DD DISP=OLD,DSN=CCOPC.OPCC.SI //EQQRDIN DD DISP=SHR,DSN=CCOPC.OPCC.R3.RD //EQQRDOUT DD DISP=OLD,DSN=CCOPC.OPCC.RD //SYSIN DD ᑍ | /ᑍ MIGRATION FROM OPCV2R2 TO Tivoli OPC V2R3 IS ASSUMED ᑍ/ | CONVERT FILE(AD) FROMREL(OPCV2R2) TOREL(OPCV2R3) | CONVERT FILE(CP) FROMREL(OPCV2R2) TOREL(OPCV2R3) | CONVERT FILE(CX) FROMREL(OPCV2R2) TOREL(OPCV2R3) | CONVERT FILE(WS) FROMREL(OPCV2R2) TOREL(OPCV2R3) | CONVERT FILE(LT) FROMREL(OPCV2R2) TOREL(OPCV2R3) | CONVERT FILE(JS) FROMREL(OPCV2R2) TOREL(OPCV2R3) | CONVERT FILE(OI) FROMREL(OPCV2R2) TOREL(OPCV2R3) | CONVERT FILE(RD) FROMREL(OPCV2R2) TOREL(OPCV2R3) | CONVERT FILE(SI) FROMREL(OPCV2R2) TOREL(OPCV2R3)
In this example, all VSAM files are converted from OPC/ESA Release 3 to Tivoli OPC Version 2 format. The tasks performed immediately before this job was submitted are listed here in order: 1. Verified JS1 as the active JCL repository in option 6.6 on the Release 3 controller. If JS2 is the active JCL repository, use that as input but be sure to use JS1 as output because Tivoli OPC by default uses JS1 as the active JCL repository when you start a subsystem with an empty checkpoint dataset. 2. The Release 3 controller was shut down normally, as verified in the message log. Check that a current plan backup process was completed after the stop command was received by the subsystem. 3. A batch job was submitted to allocate and backup the Release 3 datasets to new DSNs.
144 Tivoli OPC Installation Guide Migration Actions
4. EQQPCS01 from Tivoli OPC Version 2 EQQJOBS was submitted to allocate the VSAM clusters required for Tivoli OPC Version 2. 5. A daily plan batch process had not been submitted on the Release 3 system prior to shut down, therefore the old CP1 is used as input. Output is the Tivoli OPC Version 2 NCP.
Data Sets that You Need to Convert Allocate new VSAM datasets for Tivoli OPC Version 2. Existing data can then be migrated using EQQICTOP. Keep a copy of the old datasets for backup and fallback purposes. The following datasets must be migrated to Tivoli OPC Version 2 format:
Table 34. Datasets that You Need to Convert OPC/A Tivoli OPC Description DRKADDS EQQADDS Application descriptions and JCL variable tables DRKJSnDS EQQJSnDS JCL repository (currently active) DRKLTDS EQQLTDS Long-term plan DRKNCPDS, or EQQNCPDS, or The current plan, but use the NCP as input if a daily DRKCPnDS EQQCPnDS plan process created an NCP after the old system was shut down. — EQQNCXDS, or The current plan extension, but use the NCX as input if EQQCXnDS a daily plan process created an NCX after the old system was shut down. DRKOIDS EQQOIDS Operator instructions — EQQRDDS Special resource definitions — EQQSIDS Side information, ETT criteria and Tivoli OPC configuration information DRKTBnDS EQQTBnDS Table space, output to RD and SI DRKWSDS EQQWSDS Workstation descriptions, calendars, and periods
Data Sets that Tivoli OPC Version 2 Can Use Tivoli OPC Version 2 can use unchanged data from the following datasets:
Table 35. Datasets that Tivoli OPC Version 2 Can Use OPC/A Tivoli OPC Description DRKJBLIB EQQJBLIB (see Note) JCL library DRKJCLIB EQQJCLIB Job-completion-checker (JCC) message-table library DRKINCWK EQQINCWK JCC incident work file DRKPRLIB EQQPRLIB Automatic-recovery-procedure library — — JCC incident log
Note: If this library contains jobs for OPC planning, the JCL must be modified to reflect the new installation.
Chapter 7. Migration Actions 145 Migration Actions
Empty Datasets When you have completed your testing of Tivoli OPC Version 2 and have performed dataset migration, ensure that the following datasets are empty before you start Tivoli OPC Version 2 for the first time in production: EQQCKPT Checkpoint EQQCXDS The current plan extension EQQDLnn Dual job-tracking logs EQQEVDS Event datasets EQQJTARC Job-tracking archive EQQJTnn Job-tracking logs EQQMLOG Message log EQQSTC Started-task submit EQQSUDS Submit release
EQQCPnDS and EQQCXDS do not have to be empty, although they can be. When the Tivoli OPC Version 2 is started for the first time, you must specify CURRPLAN(NEW) on the JTOPTS statement. Therefore, any data in the EQQCPnDS and EQQCXDS datasets will immediately be replaced by the contents of the EQQNCPDS and EQQNCXDS. Similarly, the inactive EQQJSnDS dataset (EQQJS2DS in this example) does not have to be empty, although it can be.
Switching Tivoli OPC Version 2 into Production Mode When you have completed the migration steps and tested your Tivoli OPC Version 2 system, you should be able to switch Tivoli OPC Version 2 into production with a minimum interruption to your normal processing. This process is referred to as cutover in the following explanation. An example explains the process in the following steps: 1. Closing down your production system 2. Ensuring that LTP and NCP datasets are current 3. Converting VSAM files to Tivoli OPC Version 2 format 4. Starting the new system 5. Validating the new system
In the example, all systems are assumed to be OPC/A systems, although you can use the same process when migrating from OPC/ESA Release 3. Because Tivoli OPC Version 2 is able to communicate with earlier systems, you can—if you like—migrate your systems gradually, starting with the controlling system and then migrating each controlled system.
Consider this scenario: An installation is running three MVS systems: MVS1, MVS2, and MVS3. MVS1 is an MVS system. It is connected to MVS2 via shared DASD, and to MVS3 via a VTAM link. The production control system (OPCA) and an event manager subsystem (OPCB) are started on MVS1. OPCA is started with a Network Event Communicator (NEC) task. MVS2 and MVS3 are controlled systems. An EMS (OPCC) is started on MVS2. The EMS on MVS3 (OPCD) is started with a NEC task.
146 Tivoli OPC Installation Guide Migration Actions
The objective is to stop the OPCA and OPCB and migrate them to Tivoli OPC Version 2 with as little impact on users as possible. One possible method is described here. Modify it as required to suit the specific needs of your installation.
In the example, you should first make sure that: 1. You prepared JCL to: Back up the OPC/A environment. Allocate the Tivoli OPC Version 2 VSAM and non-VSAM files. 2. All event-writer systems (OPCC, OPCD, and OPC2) are active at the beginning of the cutover process. The sequence that the event writers are started and stopped is the key to a successful cutover to a new Tivoli OPC Version 2 system.
Closing Down Your Production System If your event writers have a large CSA area defined, you do not have to worry about losing events. It is assumed here that area is quite small, so you should deliberately slow down the event-generating rate as much as possible. To do this, perform the following actions: 1. From the Service Functions dialog on the production system (OPCA), deactivate job submission. 2. After all jobs in the current plan that are currently active have completed, stop the two controlled systems, OPCC and OPCD. If there are many jobs still on the JES job queues, or if many new jobs are still arriving from non-OPC processes, hold the job queues on MVS2 and MVS3.
Ensuring that LTP and NCP Data Sets Are Current Before creating VSAM datasets for the Tivoli OPC Version 2 system, you need to make sure that input datasets are fully up-to-date. You can do this as follows: 1. From the Daily Plan dialog on the production system (OPCA), create a replan or plan-extend batch job. Change the job card to contain TYPRUN=HOLD, and submit the job. Save the JCL in a dataset in case you have to resubmit it to correct an error. 2. If you specified CHECKSUBSYS(YES) on the BATCHOPT statement used by the batch job, change it to CHECKSUBSYS(NO). 3. Using the Query Current Plan dialog on the production system (OPCA), check which JS file is currently in use on this system. 4. Stop the OPCA and OPCB systems. Release the daily plan job from hold, and make sure that it runs successfully. 5. When the daily plan job has finished, verify that it ran successfully—indicated by a return code of 0 or 4. If required, correct any problems and rerun the job until a new current plan (NCP) dataset has been created.
Chapter 7. Migration Actions 147 Migration Actions
Converting VSAM Files to Tivoli OPC Version 2 Format The next step is to create VSAM files for the new system. You can do this as follows: 1. Create a backup copy of the OPC/A VSAM files. 2. Allocate VSAM clusters for Tivoli OPC Version 2 using the EQQPCS01 job. 3. Review the EQQICNVS sample job. Ensure that input and output dataset names are correctly specified. Make sure to select the current JS file. When defining input and output files for the CP file conversion, use the NCP file, as a new current plan has just been created. 4. Run EQQICNVS to convert the VSAM data to Tivoli OPC Version 2 format. 5. Verify that the conversion program ran successfully. If there are any problems converting the VSAM files, you should abandon the cutover process here. 6. Backup the OPC/A non-VSAM datasets. 7. If you migrate from OPC/ESA Release 3, you can use your old non-VSAM datasets. Otherwise, allocate Tivoli OPC Version 2 non-VSAM datasets using the EQQPCS01 and EQQPCS02 jobs. 8. If you have abandoned cutover, start OPCA, OPCB, and OPCC. Release any held queues and restart any drained initiators. Remember to reallocate the VSAM files using cluster definitions for OPC/A, see DRKPCS01 and copy from the most recent backup.
Starting the New System In the following procedure, it is assumed that VSAM file conversion was successful. To start the new system, perform the following actions: 1. Modify the JCL procedure for OPCA to include the new ddnames and datasets added in Tivoli OPC Version 2. Use ISPF browse to ensure that all job-tracking logs (EQQJTnn), the job-tracking archive (EQQJTARC), and the checkpoint (EQQCKPT) are empty datasets. If you use dual job-tracking logs (EQQDLnn), they should also be empty datasets. 2. Modify initialization parameters for OPCA. The CKPT data set is not yet initialized the first time you start OPCA after migration, and hence you must | specify CURRPLAN(NEW) in JTOPTS. Specify BUILDSSX(REBUILD) and | SSCMNAME(EQQSSCMD,TEMPORARY) on the OPCOPTS initialization statement. Specify the PIFHD keyword on the INTFOPTS initialization statement. As soon as OPCA has started, you should change back to CURRPLAN(CURRENT), to prevent OPCA from recovering from the new current plan each time it is started. Note: You might find it useful to specify JOBSUBMIT(NO) on the JTOPTS initialization statement so that work is not submitted when you start OPCA. When you have checked that OPCA has started without errors, you can activate job submission using the Service Functions dialog. 3. Start OPCA. Verify that no errors occurred during initialization. If required, correct any errors and restart OPCA. | 4. Modify initialization parameters for OPCB. Specify BUILDSSX(REBUILD) and | SSCMNAME(EQQSSCMD,TEMPORARY) on the OPCOPTS initialization
148 Tivoli OPC Installation Guide Migration Actions
statement. Specify the PIFHD keyword on the INTFOPTS initialization statement. 5. Start the OPCB. 6. Restart drained initiators on the MVS1 system. 7. Enter the Service Functions dialog on OPCA, and activate job submission (if it is not already active). 8. Start the OPCC and OPCD systems. Release held queues, and restart drained initiators if required. 9. Change JTOPTS CURRPLAN(NEW) to CURRPLAN(CURRENT). 10. Submit a daily plan replan or extend as soon as possible after migration. Until a new current plan is created, any references to special resources will cause the resource object to be copied from the EQQRDDS to the current-plan-extension data space. This processing has some performance overheads. The new-current-plan-extension dataset (EQQNCXDS) is built during daily planning to contain all special resources referenced by operations in the new current plan.
After the next IPL of the system, remove the BUILDSSX and SSCMNAME keywords from OPCA and OPCB initialization statements if the subsystem name | table (IEFSSNnn) in SYS1.PARMLIB has been updated to correctly specify | EQQINITD and EQQSSCMD.
Validating the New System All that remains is to validate that your new system works as expected. To do this, perform the following steps: 1. From the Ready List dialog, review the status of active operations. 2. Check that the operations that are becoming ready on the workstations representing the three MVS systems are successfully submitted to the intended system. Also check that the ending status is correctly reflected in the ready lists. 3. Verify that the current plan and the long-term plan can be extended successfully. 4. Verify that other Tivoli OPC-related processes (for example, the dialogs, batch programs, and PIF-based programs) work as expected.
Performing Fallback from Tivoli OPC Version 2 If a problem occurs after Tivoli OPC Version 2 has been active as a production system for some time—and the problem is serious enough—you might need to stop the new system and return the workload to the previous system. You can do this using a procedure called fallback, if the Tivoli OPC Version 2 datasets are usable. The procedure is: 1. Run the EQQPCS01 and EQQPCS02 jobs to allocate new datasets for the old production system. The current datasets, or a copy, used by the Tivoli OPC Version 2 systems should be kept for problem determination purposes.
Chapter 7. Migration Actions 149 Migration Actions
2. If required, close down the systems in the same way as during cutover. This is required if the current plan on the OPCA system is intact and job tracking is working normally. 3. If possible, create up-to-date datasets for the long-term plan and new current plan for the OPCA system. 4. Build VSAM datasets for the old system by running the EQQICNVS job to | convert Tivoli OPC Version 2 files to their previous format. Note that the job | log to be retrieved by the data store will be left as it is. 5. Start the OPCA and OPCB systems again using the converted files. Note: You might find it useful to specify JOBSUBMIT(NO) on the JTOPTS initialization statement so that work is not submitted when you start OPCA. When you have checked that old system has started without errors, you can activate job submission using the Service Functions dialog. 6. If the new current plan (NCP) dataset is not fully up-to-date because you could not run the daily plan program, use the MCP dialog to update the status of operations to make the current plan up-to-date. 7. Start the OPCC and OPCD systems again. Use the SSCMNAME keyword on the JTOPTS initialization to load the current subsystem communication module for the release you are falling back to. Activate MVS systems as required. Note: If you experience problems with your Tivoli OPC Version 2 system and you need to migrate back to an earlier release, you must consider the impact that this will have on all aspects of your configuration. This is especially important for connectivity items. Consider the following: If it is necessary to perform fallback to an OPC/A system, then: – If you have NCF connections, you must reverse the migration procedure and run NEC instead. – If you used an event writer with an event-reader function, you need to remove the EWSEQNO keyword and specify a separate event-reader task. – Work that is planned for a Tivoli OPC system (such as started-task or WTO operations) will not process on an OPC/A system. – When you have performed fallback, the current plan will not contain application group information, but all occurrences that were members of application groups will still process as normal. However, the applications in the AD database will not contain any run cycles. You should, therefore, specify run-cycle information for these applications so that they are scheduled and, if you are performing fallback to OPC/ESA Release 2, so that any JCL variables can be resolved. If you are performing fallback to OPC/ESA Release 3.0 or earlier, the valid-to date and run-cycle-out-of-effect dates that are defined as 71/12/31 in your Tivoli OPC Version 2 applications will be changed to 99/12/31 upon fallback. Applications that have a valid-from date in the 21st century will be ignored. If you have defined the ETTRCY1 period with origin date 71/12/31, the origin date will be converted to the old high date 99/12/31.
It will not be possible to perform fallback from Tivoli OPC Version 2 after 31 December 1999. Be sure to complete the migration of your system before that
150 Tivoli OPC Installation Guide Migration Actions
date. In the second half of 1999, OPC/ESA Release 3.0 or earlier might encounter problems with handling dates.
You should consider all possible migration actions when planning the migration and fallback procedures for your installation.
In the following example, all VSAM files are converted from Tivoli OPC Version 2 to OPC/ESA Release 2 format. The tasks to perform immediately before this job are listed here in order: 1. Verify JS1 as the active JCL repository in option 6.6 on the Tivoli OPC Version 2 controller. If JS2 is the active JCL repository, use that as input but be sure to use JS1 as output because Tivoli OPC by default uses JS1 as the active JCL repository when you start a subsystem with an empty checkpoint dataset. 2. Shut down the Tivoli OPC Version 2 controller normally. Verify this using the message log. Check that a current plan backup process was completed after the stop command was received by the subsystem. 3. Submit a EQQPCS01 job (from Release 2 EQQJOBS) to reallocate the VSAM clusters required for Release 2. 4. Check that a daily plan batch process had not been submitted on the Tivoli OPC system prior to shut down. Therefore the Tivoli OPC CP1 is used as input, and the output is the Release 2 NCP.
Chapter 7. Migration Actions 151 Migration Actions
//OPCBAK JOB (777777,777),'Fallback to R2',MSGLEVEL=(1,1), // NOTIFY=&SYSUID,MSGCLASS=H,CLASS=A //ᑍ //CONVERT EXEC PGM=EQQICTOP,REGION=2ð48K //STEPLIB DD DISP=SHR,DSN=OPCESA.INST.LOADLIB //EQQMLIB DD DISP=SHR,DSN=OPCESA.INST.SEQQMSGð //EQQMLOG DD SYSOUT=ᑍ //EQQADIN DD DISP=SHR,DSN=CCOPC.OPCC.AD //EQQADOUT DD DISP=OLD,DSN=CCOPC.OPCC.R2.AD //EQQWSIN DD DISP=SHR,DSN=CCOPC.OPCC.WS //EQQWSOUT DD DISP=OLD,DSN=CCOPC.OPCC.R2.WS //EQQCPIN DD DISP=SHR,DSN=CCOPC.OPCC.CP1 //EQQCPOUT DD DISP=OLD,DSN=CCOPC.OPCC.R2.NCP //EQQLTIN DD DISP=SHR,DSN=CCOPC.OPCC.LT //EQQLTOUT DD DISP=OLD,DSN=CCOPC.OPCC.R2.LT //EQQJSIN DD DISP=SHR,DSN=CCOPC.OPCC.JS1 //EQQJSOUT DD DISP=OLD,DSN=CCOPC.OPCC.R2.JS1 //EQQOIIN DD DISP=SHR,DSN=CCOPC.OPCC.OI //EQQOIOUT DD DISP=OLD,DSN=CCOPC.OPCC.R2.OI //EQQSIIN DD DISP=OLD,DSN=CCOPC.OPCC.SI //EQQCXIN DD DISP=OLD,DSN=CCOPC.OPCC.CX //EQQRDIN DD DISP=OLD,DSN=CCOPC.OPCC.RD //EQQTBOUT DD DISP=SHR,DSN=CCOPC.OPCC.R2.TB1 //SYSIN DD ᑍ | /ᑍ FALLBACK FROM Tivoli OPC V2R3 TO OPC V2R3 IS ASSUMED ᑍ/ | CONVERT FILE(AD) FROMREL(OPCV2R3) TOREL(OPCV2R2) | CONVERT FILE(CP) FROMREL(OPCV2R3) TOREL(OPCV2R2) | CONVERT FILE(WS) FROMREL(OPCV2R3) TOREL(OPCV2R2) | CONVERT FILE(LT) FROMREL(OPCV2R3) TOREL(OPCV2R2) | CONVERT FILE(JS) FROMREL(OPCV2R3) TOREL(OPCV2R2) | CONVERT FILE(OI) FROMREL(OPCV2R3) TOREL(OPCV2R2) | CONVERT FILE(TB) FROMREL(OPCV2R3) TOREL(OPCV2R2) .1/
Notes: 1. You can either define FILE(TB) or the individual files that comprised the old TB file. If you define the individual files, the same DD statements are required but you should use these SYSIN statements instead of the statement at .1/: | CONVERT FILE(SI) FROMREL(OPCV2R3) TOREL(OPCV2R2) | CONVERT FILE(RD) FROMREL(OPCV2R3) TOREL(OPCV2R2) Converting the RD automatically converts the CX file also. 2. If you are falling back because of problems experienced on Tivoli OPC, be sure to keep the Tivoli OPC datasets for diagnostic purposes. 3. If you migrate to and fallback from Tivoli OPC to test the environment before your official cutover, ensure you reallocate all Tivoli OPC datasets before the next migration exercise or cutover.
152 Tivoli OPC Installation Guide
Part 4. Appendixes
Copyright IBM Corp. 1991, 1999 153
154 Tivoli OPC Installation Guide
Appendix A. Sample Library (SEQQSAMP)
The SEQQSAMP library contains samples to help you install, migrate, and customize Tivoli OPC. In most cases, you need only add installation-specific JCL to adapt a member in SEQQSAMP to your requirements. Table 36 lists all members in the SEQQSAMP library and provides a brief description of each member. The following pages describe the samples relating to installing Tivoli OPC in more detail. Descriptions of other sample-library members are included in the book that describes the function demonstrated by the sample. For example, program-interface samples are described in Tivoli OPC Programming Interfaces.
Some of the samples provided address a specific function and you might be able to use the sample unchanged in your environment. If you need to change a sample member, it is advisable to copy the source to a separate library. The original sample member is then available for reference. It is also recommended that you create an SMP/E usermod for each sample member you execute in the production environment. Changes to the sample source code will then be flagged for your attention, and subsequent updates can be reflected in the production code as soon as possible.
Table 36 (Page 1 of 4). SEQQSAMP Library Members Member Brief description EQQACTR1 Sample SMF exit IEFACTRT, written in assembler, to enable job-tracking EQQACPTx Sample SMP/E ACCEPT JCL for the Tivoli OPC controller software, where the value of x depends on the language EQQALDDF Sample job to allocate OPC DDDEFs in SMP/E EQQALOPC JCL to allocate the Tivoli OPC distribution and target libraries. EQQALSMP Sample JCL to allocate and initialize the SMP/E environment needed to install Tivoli OPC EQQAPISM ASCII file containing a sample API application EQQAPPLx Sample SMP/E APPLY JCL for the Tivoli OPC controller software, where the value of x depends on the language EQQAUDIT An audit package consisting of panels, JCL, and a CLIST, which you can use to generate reports from job-tracking and track log records EQQAIXST Parameters used by the EQQX9AIX and EQQAIXTR samples EQQAIXTR Sample tracker running on AIX, used with EQQX9AIX | EQQARCH Sample Data Store startup procedure | EQQARCPA Contains Data Store initial parameters EQQBSCAN Batch loader sample to validate an application description EQQBSUBS Batch loader sample to create four application descriptions and two operator instructions. Output is directed to a subsystem. EQQBVSAM Batch loader sample to create an application description and two operator instructions. Output is directed to a VSAM dataset that is allocated by the sample. | EQQCLNPA Contains Data Store clean-up sample parameters | EQQCLNUP Runs batch clean-up utility | EQQCTLPA Contains FL task initial parameters EQQCVM Sample to enable job-tracking facilities on VM systems
Copyright IBM Corp. 1991, 1999 155 Sample Library
Table 36 (Page 2 of 4). SEQQSAMP Library Members Member Brief description EQQCVM2 Sample to enable submission and tracking on VM systems using EQQUX009 EQQDELDI JCL and usage notes for the dataset deletion function EQQDLFX Assembler installation sample of DLF connect/disconnect exit EQQDPCOP JCL and usage notes for copy VSAM function | EQQEXPOR Runs batch export utility | EQQEXPPA Contains Data Store export sample parameters | EQQIMPOR Runs batch import utility | EQQIMPPA Contains Data Store import sample parameters EQQINIDB Sample to create the history data base EQQJCCTB JCL to assemble a JCC message table macro definition EQQJCLIN Sample JCL to start program EQQPDLF EQQJES2 JCL to assemble and link-edit a JES2 exit EQQJES2U JCL to install a JES2 exit as an SMP/E usermod EQQJES3 JCL to assemble and link-edit a JES3 exit EQQJES3U JCL to install a JES3 exit as an SMP/E usermod EQQJVXIT Sample assembler JCL-variable-substitution exit EQQLSJCL Sample JCL to invoke the EQQLSENT macro EQQNETW1 REXX EXEC that receives Tivoli OPC WTO messages and issues MVS commands EQQNETW2 PL/I NetView command processor that uses EQQUSINT to change the status of operations EQQNETW3 REXX EXEC that uses EQQEVPGM to change the status of operations EQQOPCA Started-task-procedure JCL for a tracker EQQOPCAO Initialization parameters for sample EQQOPCA EQQOPCB Started-task-procedure JCL for a controller EQQOPCBP Initialization parameters for sample EQQOPCB EQQOPCS Sample started-task procedure for a server EQQOPCSP Sample initialization statement for sample EQQOPCS EQQOS2ST Parameters used by the EQQX9OS2 and EQQOS2TR samples EQQOS2TR Sample tracker running on OS/2, used with EQQX9OS2 EQQOUTL Contains panels and a CLIST to invoke ISPF OUTLIST functions from the Tivoli OPC dialog EQQPCS01 Allocates datasets that need to be unique within the SYSPLEX EQQPCS02 Allocates datasets that need to be unique to each MVS image in the SYSPLEX EQQPCS03 Generates a job that allocates VSAM copy datasets | EQQPCS04 Defines Data Store VSAM files and initializes them EQQPIFAP Program-interface PL/I sample that resolves JCL variables EQQPIFAD Program-interface PL/I sample that creates a two-operation application in the AD database EQQPIFCB Program-interface assembler samples for various current plan or long-term plan actions EQQPIFCL Program-interface assembler sample that uses the DAYSTAT command to return work or free status for a particular date EQQPIFDJ Program-interface assembler sample, deletes JCL for completed occurrences from JS dataset
156 Tivoli OPC Installation Guide Sample Library
Table 36 (Page 3 of 4). SEQQSAMP Library Members Member Brief description EQQPIFJC Program-interface COBOL sample to manipulate JCL variable tables EQQPIFJD Program-interface PL/I sample that can either list or delete records in the JCL repository dataset (JS) EQQPIFJV Program-interface PL/I sample to manipulate JCL variable tables EQQPIFOP Program-interface REXX sample to modify an operation in the current plan EQQPIFPR Program-interface REXX sample to list all cyclic periods EQQPIFWI Program-interface PL/I sample to modify capacity values in an open interval of a current plan workstation EQQPROC Sample procedure, started by Tivoli OPC, to initiate purge of DLF objects | EQQRCVIX Runs batch recover index utility | EQQRCVPA Contains Data Store recover sample parameters EQQRECVx Sample SMP/E RECEIVE JCL for the Tivoli OPC controller software, where the value of x depends on the language EQQRE300 Sample SMP/E RECEIVE JCL for the Tivoli OPC tracker software EQQRE1AC Sample SMP/E RECEIVE JCL for the English language panels | EQQREORG Runs batch reorg utility EQQRMDS Usage notes for the job-log-retrieval exit object code to interface to RMDS EQQRXSTG An assembler routine to get and free storage for the REXX program-interface samples. EQQSAMPI JCL to load sample data for application descriptions, operator instructions, and workstation descriptions to the databases EQQSMF JCL to assemble and install the SMF exits EQQUJI1 Sample SMF exit IEFUJI to enable job-tracking EQQUSIN1 EQQUSIN subroutine sample to change the status of an operation EQQUSIN2 EQQUSIN subroutine sample to change the availability of a special resource EQQUSIN3 EQQUSIN subroutine sample to change the status of a workstation EQQUSIN4 EQQUSIN subroutine sample to backup a Tivoli OPC resource dataset EQQUSIN5 EQQUSIN subroutine sample to update the USERDATA field of an operation. EQQUX0N Sample PL/I start/stop exit, EQQUX000 EQQUX001 Sample job-submit exit EQQUX002 Sample job-library-read exit EQQUX004 Sample event-filtering exit EQQUX011 Sample Job-Tracking log write exit EQQUX191 Sample JES3 exit IATUX19 to enable job tracking EQQUX291 Sample JES3 exit IATUX29 to enable job tracking EQQUX9N Sample PL/I operation-initiation exit, communicating with VM (EQQUX009) EQQU831 Sample SMF exit IEFU83 to enable job tracking and optionally include dataset triggering support EQQXIT72 Sample JES2 exit7 to enable job tracking for JES2 level prior to Version 4 Release 1 EQQXIT74 Sample JES2 exit7 to enable job tracking for JES2 level Version 4 Release 1 and later EQQX5ASM Sample SYSOUT archiving exit
Appendix A. Sample Library (SEQQSAMP) 157 Sample Library
Table 36 (Page 4 of 4). SEQQSAMP Library Members Member Brief description EQQX6ASM Sample incident-record-create exit EQQX6JOB Sample batch-job skeleton JCL used by EQQX6ASM EQQX7ASM Sample change-of-status exit EQQX7JOB Sample batch-job skeleton JCL used by EQQX7ASM EQQX9AIX Sample assembler operation-initiation exit, communicating with AIX EQQX9OS2 Sample assembler operation-initiation exit, communicating with OS/2 EQQYCBAT Link edit and run the Batch Command Interface tool EQQYRJCL Sample JCL to run the OPC Control Language tool EQQYRPRC Sample procedure to run the OPC Control Language tool EQQYRPRM Sample initialization parameter file for the OPC Control Language tool EQQYRMSG Messages used by the OPC Control Language tool EQQ9RFDE Sample RACF class descriptor entry to enable security environment EQQ9RF01 Sample RACF router table entry to enable security environment EQQ9SMDE JCL to install RACF class descriptor update EQQ9SM01 JCL to install RACF router table update | EQQPCS04 Defines Data Store VSAM files and initializes them | EQQCLNUP Runs batch clean-up utility | EQQEXPOR Runs batch export utility | EQQIMPOR Runs batch import utility | EQQRCVIX Runs batch recover index utility | EQQREORG Runs batch reorg utility | EQQARCPA Contains Data Store initial parameters | EQQCTLPA Contains FL task initial parameters | EQQCLNPA Contains Data Store clean-up sample parameters | EQQEXPPA Contains Data Store export sample parameters | EQQIMPPA Contains Data Store import sample parameters | EQQRCVPA Contains Data Store recover sample parameters | EQQARCH Sample Data Store startup procedure
SMP/E Samples The following SEQQSAMP members relate to SMP/E processes.
Environment Setup You can use the sample library members EQQALSMP, EQQALDDF, and EQQALOPC to create and initialize the SMP/E environment and the Tivoli OPC product libraries that are needed to support the installation and continuing maintenance of Tivoli OPC.
The EQQALSMP job performs the following functions:
158 Tivoli OPC Installation Guide Sample Library
| Initializes an SMP/E CSI, adding a global zone, and the OPC FMID.
The EQQALDDF job sets up DDDEFs for all Tivoli OPC datasets to provide for basic JCL requirements for RECEIVE, APPLY, and ACCEPT processing.
The EQALOPC job allocates all Tivoli target and distribution libraries. The JCL also contains a number of steps, which are currently commented out. You can use those steps to delete the OPC libraries if you need to reinstall Tivoli OPC.
RECEIVE Processing The sample library members EQQRECVE, EQQRECVS, EQQRECVJ, and EQQRECVD contain JCL that you can use to execute SMP/E RECEIVE processing for Tivoli OPC datasets. These library members enable you to receive the following Tivoli OPC features: Tracker Controller TCP/IP Communication WLM/2 | Tracker Enabler and Tracker agents Certain NLS features contained in the Controller, WLM/2, and the Tracker agents for AIX, Windows NT, and OS/2.
Each of these jobs performs RECEIVE processing for a particular NLS feature: | EQQRECVE | Receives all the Tivoli OPC base and tracker components (FMIDs | HOPC300, JOPC301-JOPC303, and JOPC3C0-JOPC3CB), plus the | English features for the controller and WLM/2 (FMIDs JOPC3A4 and | JOPC3B4) | EQQRECVS | Receives all the Tivoli OPC base and tracker components (FMIDs | HOPC300, JOPC301-JOPC303, and JOPC3C0-JOPC3CB) plus the | Spanish features for the controller and WLM/2 (FMIDs JOPC3A1 and | JOPC3B1). | EQQRECVJ | Receives all the Tivoli OPC base and tracker components (FMIDs | HOPC300, JOPC301-JOPC303, JOPC3C0-JOPC3C4, and | JOPC3C8-JOPC3CB), plus the Japanese features for the controller | and WLM/2 (FMIDs JOPC3A2 and JOPC3B2) and the Japanese | Tracker agents for AIX, Windows NT, and OS/2 (FMIDs | JOPC3E5-JOPC3E7) | EQQRECVD | Receives all the Tivoli OPC base and tracker components (FMIDs | HOPC300, JOPC301-JOPC303, JOPC3C0-JOPC3C4, and | JOPC3C8-JOPC3CB), plus the German features for the controller and | WLM/2 (FMIDs JOPC3A3 and JOPC3B3) and the German Tracker | agents for AIX, Windows NT, and OS/2 (FMIDs JOPC3F5-JOPC3F7)
You may need to change the distribution library and zone name to reflect those defined in the Tivoli OPC CSI.
Appendix A. Sample Library (SEQQSAMP) 159 Sample Library
APPLY Processing The sample library members EQQAPPLE, EQQAPPLS, EQQAPPLJ, and EQQAPPLD contain JCL that you can use to execute SMP/E APPLY processing for Tivoli OPC. These members enable you to apply the following Tivoli OPC features: Tracker Controller TCP/IP Communication WLM/2 | Tracker Enabler and Tracker agents Certain NLS features contained in the controller, WLM/2, and the Tracker agents for AIX, Windows NT, and OS/2.
Each of these jobs performs APPLY processing for a particular NLS feature: | EQQAPPLE | Applies all the Tivoli OPC base and tracker components (FMIDs | HOPC300, JOPC301-JOPC303, and JOPC3C0-JOPC3CB), plus the | English features for the controller and WLM/2 (FMIDs JOPC3A4 and | JOPC3B4) | EQQAPPLS | Applies all the Tivoli OPC base and tracker components (FMIDs | HOPC300, JOPC301-JOPC303, and JOPC3C0-JOPC3CB), plus the | Spanish features for the controller and WLM/2 (FMIDs JOPC3A1 and | JOPC3B1). | EQQAPPLJ Applies all the Tivoli OPC base and tracker components (FMIDs | HOPC300, JOPC301-JOPC303, JOPC3C0-JOPC3C4, and | JOPC3C8-JOPC3CB), plus the Japanese features for the controller | and WLM/2 (FMIDs JOPC3A2 and JOPC3B2) and the Japanese | Tracker agents for AIX, Windows NT, and OS/2 (FMIDs | JOPC3E5-JOPC3E7). | EQQAPPLD | Applies all the Tivoli OPC base and tracker components (FMIDs | HOPC300, JOPC301-JOPC304, JOPC3C0-JOPC3C4, and | JOPC3C8-JOPC3CB), plus the German features for the controller and | WLM/2 (FMIDs JOPC3A3 and JOPC3B3) and the German Tracker | agents for AIX, Windows NT, and OS/2 (FMIDs JOPC3F5-JOPC3F7).
You may need to change the distribution library and zone name to reflect those defined in the Tivoli OPC CSI.
ACCEPT Processing The sample library members EQQACPTE, EQQACPTS, EQQACPTJ, and EQQACPTD contain JCL that you can use to execute SMP/E ACCEPT processing for Tivoli OPC. These members enable you to accept the following Tivoli OPC features: Tracker Controller TCP/IP Communication WLM/2 | Tracker Enabler and the Tracker agents
160 Tivoli OPC Installation Guide Sample Library
Certain NLS features contained in the Controller, WLM/2, and the Tracker agents for AIX, Windows NT, and OS/2.
Each of these jobs performs RECEIVE processing for a particular NLS feature: | EQQACPTE | Accepts all the Tivoli OPC base and tracker components (FMIDs | HOPC300, JOPC301-JOPC303, and JOPC3C0-JOPC3CB), plus the | English features for the controller and WLM/2 (FMIDs JOPC3A4 and | JOPC3B4). | EQQACPTS | Accepts all the Tivoli OPC base and tracker components (FMIDs | HOPC300, JOPC301-JOPC303, and JOPC3C0-JOPC3CB), plus the | Spanish features for the controller and WLM/2 (FMIDs JOPC3A1 and | JOPC3B1). | EQQACPTJ | Accepts all the Tivoli OPC base and tracker components (FMIDs | HOPC300, JOPC301-JOPC303, JOPC3C0-JOPC3C4, and | JOPC3C8-JOPC3CB), plus the Japanese features for the controller | and WLM/2 (FMIDs JOPC3A2 and JOPC3B2) and the Japanese | Tracker agents for AIX, Windows NT, and OS/2 (FMIDs | JOPC3E5-JOPC3E7) | EQQACPTD | Accepts all the Tivoli OPC base and tracker components (FMIDs | HOPC300, JOPC301-JOPC303, JOPC3C0-JOPC3C4, and | JOPC3C8-JOPC3CB), plus the German features for the controller and | WLM/2 (FMIDs JOPC3A3 and JOPC3B3) and the German Tracker | agents for AIX, Windows NT, and OS/2 (FMIDs JOPC3F5-JOPC3F7).
You may need to change the distribution library and zone name to reflect those defined in the Tivoli OPC CSI.
SMF Exits The following text provides details of the SEQQSAMP members relating to SMF exits. Note: If version IEV90 of the compiler reports errors, remove the RMODE=ANY statement from the sample exit.
Exit Installation The sample library member EQQSMF contains the JCL needed to assemble the SMF exits required for Tivoli OPC. The job also defines an SMP/E usermod to connect the SMF exits to your MVS/ESA target zone.
A single usermod is used to define the three SMF exits. You can, if you prefer, define usermods for each exit.
Appendix A. Sample Library (SEQQSAMP) 161 Sample Library
Job Step Termination Exit The sample library member EQQACTR1 contains the assembler source code of an SMF job/step termination exit, IEFACTRT. The sample contains two subroutines: OPCASUB provides the necessary Tivoli OPC code to track job- and step-end events. LOCALSUB generates WTO messages for step- and job-end.
If you are already using an IEFACTRT, you need only incorporate the code from the OPCASUB subroutine into your existing exit and reassemble.
Initialization Exit The sample library member EQQUJI1 contains the assembler source code of an SMF initialization exit, IEFUJI. Tivoli OPC uses events generated from the exit to track job start information.
If your installation is already using an IEFUJI, incorporate the code into your existing exit and reassemble.
Record Write Exit The sample library member EQQU831 contains the assembler source code of an SMF initialization exit, IEFU83. Tivoli OPC uses events generated from the exit to track print group and purge information.
If your installation is already using an IEFU83, incorporate the code into your existing exit and reassemble.
You can optionally include support for both the dataset triggering and job-tracking functions using the EQQU831 sample. This provides you with a method to automatically generate a special resource availability when a dataset is closed. The event can be used by Tivoli OPC to change the status of a special resource to make it available for operations and/or to trigger an application to be added to the current plan. You specify the datasets you want special resource availability events for using the EQQLSENT macro to create a dataset selection table, EQQDSLST. See “Implementing Support for Data Set Triggering” on page 59 for more information about dataset triggering. Use the EQQSMF sample to install EQQU831.
If you do not track print operations through Tivoli OPC, and you do not want to include dataset triggering support, you need not change IEFU83.
JES Exits The following text provides details of the SEQQSAMP members relating to JES exits. Note: If version IEV90 of the compiler reports errors, remove the RMODE=ANY statement from the sample exit.
162 Tivoli OPC Installation Guide Sample Library
Exit Installation The sample library contains a number of members to assemble and link-edit JES exits. EQQJES2 and EQQJES3 provide sample JCL for assembly and link-editing of JES2 and JES3 exits respectively. However, it is recommended that you use members EQQJES2U and EQQJES3U. These samples provide the JCL to install the JES exits as SMP/E usermods. The usermods are defined so that both the JES and Tivoli OPC target zones are informed of the dependencies. This ensures that future maintenance, to either the JES component or the Tivoli OPC component, will be handled correctly.
JES2 JCT I/O Exit The sample library members EQQXIT72 and EQQXIT74 contain the assembler source code of a JES2 JCT I/O exit, JESEXIT7. EQQXIT72 should be used if your level of JES2 is at SP3, or earlier. EQQXIT74 is used for JES2 SP4.1, or later. Tivoli OPC uses JESEXIT7 to detect new jobs on the internal reader and also to detect output group purge.
If you are already using a JESEXIT7, and want to keep the Tivoli OPC job-tracking support in a separate load module, you can specify that JES use multiple EXIT7 modules in your JES2 parameters.
JES3 OSE Modification Exit The sample library member EQQUX191 contains the assembler source code of a JES3 OSE modification exit, IATUX19. Tivoli OPC uses events generated from the exit to detect output group purge.
If you are already using an IATUX19, you should include the code in your existing exit and reassemble.
JES3 Input Service Final-User Exit The sample library member EQQUX291 contains the assembler source code of a JES3 input service final-user exit, IATUX29. Tivoli OPC uses events generated from the exit to detect new jobs on the internal reader.
If you are already using an IATUX29, then you should incorporate the code into your existing exit and reassemble.
Appendix A. Sample Library (SEQQSAMP) 163 Sample Library
RACF Samples The following text provides details of the SEQQSAMP members relating to RACF changes, which are required for Tivoli OPC security.
Class Descriptor Table The sample library member EQQ9RFDE provides the class descriptor entry required to define the Tivoli OPC security environment to RACF, or a functionally equivalent product.
Use this sample if you are running RACF Release 1.7, 1.8, or 1.9. Each class descriptor contains control information needed by RACF to validate class names and is a CSECT in the load module ICHRRCDE.
You can use member EQQ9SMDE to install ICHRRCDE as an SMP/E usermod on the RACF target zone.
Router Table The sample library member EQQ9RF01 provides the router table entry required to define the Tivoli OPC security environment to RACF, or a functionally equivalent product.
Use this sample if you are running RACF Release 1.7, 1.8, or 1.9. This is a sample RACF router table that provides action codes to determine if RACF is invoked on behalf of the RACROUTE macro.
You can use member EQQ9SM01 to install ICHRFR01 as an SMP/E usermod on the RACF target zone.
| MASS Update Samples | The EQQYCBAG member of the EQQSAMP library provides a sample in which the | Batch Command Interface Tool (BCIT) is used to unload a group application, and | all applications belonging to it, into a sequential file in batchloader control statement | format.
| The group applications, as well as other applications, can be modified via the | batchloader control statements. The sequential file can therafter be used as input | to the batchloader run.
| This sample consists of two jobs: | 1. The 'unload' job, that uses the batch command interface tool | 2. The 'load' job, that uses the batchloader.
| Before running the job, you need to customize it with correct values for the job card | name, data set names, subsystem name, and so on.
164 Tivoli OPC Installation Guide
Appendix A. Sample Library (SEQQSAMP) 165
166 Tivoli OPC Installation Guide
Appendix B. Tivoli OPC Configuration Examples
This appendix gives examples of Tivoli OPC configuration. The examples are based on MVS JES2, but they are also valid for MVS JES3 systems, or a combination of JES2 and JES3 systems. Each example shows: The controlling system—with the controller and the tracker started in separate address spaces All Tivoli OPC address spaces as Tivoli OPC systems A summary of actions that the workload restart function could take automatically Sample initialization statements that you can use to create the configuration The Tivoli OPC components that are required, the flow of automatic work submission, and event collection in various system combinations.
The Controlling System The controlling system is shown in the examples only with the controller and the tracker connected via either shared DASD or XCF. But you can connect them via NCF if you prefer this method.
Tivoli OPC can support remote systems that are in different time zones from the controlling system. Refer to Tivoli OPC Planning and Scheduling the Workload for more information on time zone support and daylight saving time changes.
Tivoli OPC Version 2 Controller A Tivoli OPC controller can control the workload on systems where an OPC/ESA Release 3 tracker is installed, but some step-level restart and job log retrieval functions will not be available on those systems. On OPC/A Release 2 controlled systems no catalog management or job log retrieval functions are available. Also, OPC/A systems have no support for started task or WTO operations.
An OPC/ESA Release 3 standby controller cannot take over the functions of a Tivoli OPC Version 2 controller.
Automatic Restart Actions The possible actions vary according to the type of connection between the controller and the tracker.
Initialization Statements Default values are used for statements that do not specifically relate to the configuration. The statements are specified in one or more parameter library members.
Copyright IBM Corp. 1991, 1999 167 Configuration Examples
Multi-Access Spool Systems Connected via Shared DASD Figure 18 shows two MVS JES2 multi-access spool (MAS) complexes that are connected through shared DASD. All systems are running MVS/ESA System Product Version 4 or later.
Systems A and B form a MAS complex. System A is the Tivoli OPC controlling system. It shares spool with System B, which is a controlled Tivoli OPC system. Work is sent directly to this complex by the controller on System A. The work is processed on one of these two systems, depending on installation parameters. You represent this complex to Tivoli OPC by defining a computer workstation with a blank destination field. That is, all work for this workstation is submitted to the system that the controller is started on.
Figure 18. Two MVS JES2 MAS Complexes Connected via Shared DASD
Systems C and D, which are both Tivoli OPC controlled systems, form a second MAS complex. Work is sent to this complex via a submit/release dataset. The destination field in the workstation description that represents this complex contains the ddname of the submit/release dataset. The tracker on System C reads this dataset and passes any new work to the complex for processing.
168 Tivoli OPC Installation Guide Configuration Examples
A tracker is installed on each system in the configuration. The event writer subtask of the tracker on each system writes events to an event dataset on that system. Four event-reader subtasks, one for each of the event datasets, are started in the controller on System A. The controller reads the event datasets and updates the current plan.
When the controller is started on system A, it attempts to open the submit/release dataset. If an I/O error occurs, the status of the workstation that represents the controlled MAS complex is set to offline. Tivoli OPC can then take automatic-workload-restart actions for operations at this workstation. These actions depend on the values that you specified on the WSOFFLINE keyword of the JTOPTS initialization statement.
Table 37 shows the initialization statements you can use to create the configuration in Figure 18 on page 168. This example assumes that some of the planned Tivoli OPC work on System C is submitted by a non-Tivoli OPC process. To control this work, the hold/release function is used. HOLDJOB(USER) is specified on the EWTROPTS statement for the tracker on System C. The RELDDNAME keyword is specified on the ERDROPTS statement of the event reader that reads event dataset C. This keyword identifies the ddname of the submit/release dataset that the controller should write release commands to.
Table 37 (Page 1 of 2). Example EQQPARM Members for Figure 13
EQQPARM members for System A
CONTROLR TRACKERA OPCOPTS OPCHOST(YES) OPCOPTS OPCHOST(NO) ERDRTASK(4) ERDRTASK(ð) ERDRPARM(ERDRA,ERDRB, EWTRTASK(YES) ERDRC,ERDRD) EWTRPARM(TRKAEW) ROUTOPTS DASD(SUDSC) TRROPTS HOSTCON(DASD)
ERDRA TRKAEW ERDROPTS ERSEQNO(1) EWTROPTS
ERDRB ERDROPTS ERSEQNO(2)
ERDRC ERDROPTS ERSEQNO(3) RELDDNAME(SUDSC)
ERDRD ERDROPTS ERSEQNO(4)
EQQPARM members for System B
TRACKERB TRKBEW OPCOPTS OPCHOST(NO) EWTROPTS ERDRTASK(ð) EWTRTASK(YES) EWTRPARM(TRKBEW) TRROPTS HOSTCON(DASD)
Appendix B. Tivoli OPC Configuration Examples 169 Configuration Examples
Table 37 (Page 2 of 2). Example EQQPARM Members for Figure 13
EQQPARM members for System C
TRACKERC TRKCEW OPCOPTS OPCHOST(NO) EWTROPTS SUREL(YES) ERDRTASK(ð) HOLDJOB(USER) EWTRTASK(YES) EWTRPARM(TRKCEW) TRROPTS HOSTCON(DASD)
EQQPARM members for System D
TRACKERD TRKDEW OPCOPTS OPCHOST(NO) EWTROPTS ERDRTASK(ð) EWTRTASK(YES) EWTRPARM(TRKDEW) TRROPTS HOSTCON(DASD)
Note: In this example, SUDSC is used for the user-defined ddname of the submit/release dataset. This ddname appears in the started-task JCL of the controller, and in the destination field of the workstation that represents the controlled MAS system.
Individual Systems Connected via Shared DASD Figure 19 on page 171 shows three MVS systems connected via shared DASD. All systems are running MVS/ESA System Product Version 4 or later.
System A is the Tivoli OPC controlling system. Systems B and C are controlled systems, each of which shares a submit/release dataset with the controlling system. Each of the three systems is represented by a computer workstation. The destination field in the workstation description for System A is left blank, indicating that Tivoli OPC should submit work to the system that the controller is started on. The destination field in the workstation descriptions for Systems B and C contains the ddname of the submit/release dataset connecting them to the controller. Work is sent to the correct submit/release dataset and is then passed to the corresponding system for processing by the event writer on that system.
170 Tivoli OPC Installation Guide Configuration Examples
Figure 19. Individual Systems Connected via Shared DASD
The event writer subtask on each system writes event information to its event dataset. Three event-reader subtasks, one for each of the event datasets, are started in the controller on System A. The controller reads the event datasets and updates the current plan.
Automatic workload restart can be invoked in this configuration if an I/O error occurs when the controller attempts to open a submit/release dataset. The workstation that has this submit/release dataset as a destination is given the offline status, and WLR actions are taken according to the options specified on the WSOFFLINE keyword of the JTOPTS initialization statement.
Table 38 on page 172 shows the initialization statements you can use to create the configuration in Figure 19.
Appendix B. Tivoli OPC Configuration Examples 171 Configuration Examples
Table 38. Example EQQPARM Members for Figure 14
EQQPARM members for System A
CONTROLR TRACKERA OPCOPTS OPCHOST(YES) OPCOPTS OPCHOST(NO) ERDRTASK(3) ERDRTASK(ð) ERDRPARM(ERDRA,ERDRB, EWTRTASK(YES) ERDRC) EWTRPARM(TRKAEW) ROUTOPTS DASD(SUDSB,SUDSC) TRROPTS HOSTCON(DASD)
ERDRA TRKAEW ERDROPTS ERSEQNO(1) EWTROPTS
ERDRB ERDROPTS ERSEQNO(2)
ERDRC ERDROPTS ERSEQNO(3)
EQQPARM members for System B
TRACKERB TRKBEW OPCOPTS OPCHOST(NO) EWTROPTS SUREL(YES) ERDRTASK(ð) EWTRTASK(YES) EWTRPARM(TRKBEW) TRROPTS HOSTCON(DASD)
EQQPARM members for System C
TRACKERC TRKCEW OPCOPTS OPCHOST(NO) EWTROPTS SUREL(YES) ERDRTASK(ð) EWTRTASK(YES) EWTRPARM(TRKCEW) TRROPTS HOSTCON(DASD)
Note: In this example, SUDSB and SUDSC are used for the user-defined ddnames of the submit/release datasets. Both of these ddnames appear in the JCL procedure of the controller. They also appear in the destination field of the respective workstations.
172 Tivoli OPC Installation Guide Configuration Examples
An MVS Sysplex Figure 20 shows four systems, each running MVS/ESA System Product Version 4, and connected by cross-system coupling facility (XCF) communication links.
System A is the controlling Tivoli OPC system and Systems B, C, and D are controlled systems. You represent each system in the systems complex (sysplex) by a computer workstation. The destination field contains the XCF-group-member name of the Tivoli OPC started task. On the controlling system, you can leave the destination field of the workstation that represents System A blank, or you can specify the XCF-group-member name of the tracker on that system. If you leave the field blank, the controller passes work to the system for processing. If you specify the tracker XCF-group-member name, the controller transmits work to the tracker, which in turn passes the work to this system. The way that you define this workstation depends on the recovery strategy you want to use.
Figure 20. An MVS Sysplex
Appendix B. Tivoli OPC Configuration Examples 173 Configuration Examples
A tracker is installed on each system in the sysplex. Each tracker event-writer subtask is started with a reader function, EWSEQNO is defined in the EWTROPTS statement. This means that the event writer passes the events to XCF for transfer to the controller at the same time as they are written to the event dataset. This eliminates the need for separate event-reader subtasks.
XCF services let you define standby controllers, which act as a backup to the controller in case a failure occurs on the controlling system. This support is referred to as the hot standby function. In Figure 20 on page 173, a Tivoli OPC address space is started on System B in standby mode. It is a copy of the controller but does not perform any functions unless the controller fails or System A fails. The standby controller must have access to all Tivoli OPC data, because it becomes the controller in the event of a failure.
The full functions of workload restart are available in this configuration. If an MVS system failure occurs, the workstation that represents that destination is set to failed. Actions are taken according to the WSFAILURE keyword of the JTOPTS initialization statement. If a tracker fails or if the communication link between the controller and the tracker fails, the workstation is set to offline. Tivoli OPC takes actions according to the WSOFFLINE keyword of JTOPTS.
Table 39 shows the initialization statements you can use to create the configuration in Figure 20 on page 173.
Table 39 (Page 1 of 2). Example EQQPARM Members for Figure 15
EQQPARM members for System A
CONTROLR TRACKERA OPCOPTS OPCHOST(YES) OPCOPTS OPCHOST(NO) ERDRTASK(ð) ERDRTASK(ð) ROUTOPTS XCF(SYSATRK,SYSBTRK, EWTRTASK(YES) SYSCTRK,SYSDTRK) EWTRPARM(TRKAEW) XCFOPTS GROUP(OPCGRP) XCFOPTS GROUP(OPCGRP) MEMBER(CONTR) MEMBER(SYSATRK) TRROPTS HOSTCON(XCF)
TRKAEW EWTROPTS EWSEQNO(1)
EQQPARM members for System B
TRACKERB STBYCONT OPCOPTS OPCHOST(NO) OPCOPTS OPCHOST(STANDBY) ERDRTASK(ð) ERDRTASK(ð) EWTRTASK(YES) ROUTOPTS XCF(SYSATRK,SYSBTRK, EWTRPARM(TRKBEW) SYSCTRK,SYSDTRK) XCFOPTS GROUP(OPCGRP) XCFOPTS GROUP(OPCGRP) MEMBER(SYSBTRK) MEMBER(STBYCTRB) TRROPTS HOSTCON(XCF)
TRKBEW EWTROPTS EWSEQNO(1)
174 Tivoli OPC Installation Guide Configuration Examples
Table 39 (Page 2 of 2). Example EQQPARM Members for Figure 15
EQQPARM members for System C
TRACKERC TRKCEW OPCOPTS OPCHOST(NO) EWTROPTS EWSEQNO(1) ERDRTASK(ð) EWTRTASK(YES) EWTRPARM(TRKCEW) XCFOPTS GROUP(OPCGRP) MEMBER(SYSCTRK) TRROPTS HOSTCON(XCF)
EQQPARM members for System D
TRACKERD TRKDEW OPCOPTS OPCHOST(NO) EWTROPTS EWSEQNO(1) ERDRTASK(ð) EWTRTASK(YES) EWTRPARM(TRKDEW) XCFOPTS GROUP(OPCGRP) MEMBER(SYSDTRK) TRROPTS HOSTCON(XCF)
Note: In this example, the XCF group is called OPCGRP. This group has members CONTR, SYSATRK, SYSBTRK, SYSCTRK, SYSDTRK, and STBYCTRB.
A Tivoli OPC PLEX Configuration Figure 21 on page 176 shows four systems running in an MVS/ESA SP Version 5.2.2 sysplex environment, connected using cross-system coupling facility (XCF) communication links.
One controller and one tracker are started on each MVS image of the sysplex; one controller becomes the active one, while the others start as standby controllers. One server is started on the MVS image where the active controller runs, to handle requests from dialogs and PIF applications.
The &SYSCLONE system variable is assumed to be set to KA, KB, KB, and KC on systems A, B, C, and D respectively.
Appendix B. Tivoli OPC Configuration Examples 175 Configuration Examples
Controller System A SSI data System B Tracker Server Controller Shared Standby Tracker EW DASD controller EW
LU6.2 XCF XCF LU6.2
Event Event dataset dataset A B
LU6.2XCF XCF LU6.2
Tracker Tracker ISPF Standby Standby EW Dialogs controller controller EW System C System D
Event Event dataset dataset C D
Key: XCF communication link XCF Cross-system coupling facility EW Event writer LU6.2 APPC communication link SSI MVS/ESA subsystem interface
Figure 21. A Tivoli OPC PLEX Environment
Table 40 on page 177 shows the initialization statements you can use to create the configuration in Figure 21.
176 Tivoli OPC Installation Guide Configuration Examples
Table 40. Example EQQPARM Members for Figure 16
EQQPARM members, shared among MVS images
CONTROLR SERVER OPCOPTS OPCHOST(PLEX) SERVOPTS SUBSYS(OPCC) ERDRTASK(ð) SCHEDULER(OSRV) SERVERS(OSRV) ROUTOPTS XCF(TRKA,TRKB, TRKC,TRKD) XCFOPTS GROUP(OPCGRP) MEMBER(CONTR)
TRACKER TRKEW OPCOPTS OPCHOST(NO) EWTROPTS EWSEQNO(1) ERDRTASK(ð) EWTRTASK(YES) EWTRPARM(TRKBEW) XCFOPTS GROUP(OPCGRP) MEMBER(TR&SYSCLONE.) TRROPTS HOSTCON(XCF)
Controlling an MVS System via a VTAM Link Figure 22 on page 178 shows an MVS system connected to the Tivoli OPC host via a VTAM link. Both systems are running MVS/ESA System Product Version 4 or later.
You represent each system by a computer workstation. The destination field in the workstation description for System A is left blank. Work for this workstation is started on System A. The destination field for the System B workstation contains the VTAM application ID of the tracker at this node. Work is transmitted from the host to the tracker and is then initiated on System B.
Appendix B. Tivoli OPC Configuration Examples 177 Configuration Examples
Figure 22. Controlling an MVS System via a VTAM Link
On System A, an event writer writes events to event dataset A, which is read by an event reader subtask at the controller. On system B the tracker event-writer subtask is started with a reader function, EWSEQNO is defined in the EWTROPTS statement. This means that the event writer passes the events to NCF for transfer to the controller at the same time as they are written to the event dataset.
Automatic workload restart can be used in this configuration if the controller cannot communicate with the tracker on system B. The status of the workstation for System B is set to offline if MVS is stopped or fails, if the tracker is stopped or fails, or if the VTAM link is lost. WLR actions are taken according to the WSOFFLINE keyword of the JTOPTS initialization statement.
Table 41 on page 179 shows the initialization statements you can use to create the configuration in Figure 22.
178 Tivoli OPC Installation Guide Configuration Examples
Table 41. Example EQQPARM Members for Figure 17
EQQPARM members for System A
CONTROLR TRACKERA OPCOPTS OPCHOST(YES) OPCOPTS OPCHOST(NO) ERDRTASK(1) ERDRTASK(ð) ERDRPARM(ERDR1) EWTRTASK(YES) NCFTASK(YES) EWTRPARM(TRKAEW) NCFAPPL(NCFAPPL1) TRROPTS HOSTCON(DASD) ROUTOPTS SNA(NCFAPPL2)
ERDR1 TRKAEW ERDROPTS ERSEQNO(1) EWTROPTS
EQQPARM members for System B
TRACKERB TRKBEW OPCOPTS OPCHOST(NO) EWTROPTS EWSEQNO(1) ERDRTASK(ð) EWTRTASK(YES) EWTRPARM(TRKBEW) NCFTASK(YES) NCFAPPL(NCFAPPL2) TRROPTS HOSTCON(SNA) SNAHOST(NCFAPPL1)
Note: In this example, the controller has VTAM application ID NCFAPPL1, and the tracker on System B has VTAM application ID NCFAPPL2.
Controlling a JES2 MAS System via a VTAM Link Figure 23 on page 180 shows an MVS JES2 MAS system connected to the Tivoli OPC host via a VTAM link. All systems are running MVS/ESA System Product Version 4 or later.
System A and the systems in the JES2 MAS complex (System B and System C) are each represented by a computer workstation. The destination field for the workstation on System A is left blank so that work is initiated by the controller on that system. The destination field of the workstation descriptions for the MAS complex contains the VTAM application ID of the tracker on System B. The controller sends work to the tracker on System B via the network communication function. The tracker passes the work to the complex, and the work then processes on either System B or System C, depending on installation parameters.
Appendix B. Tivoli OPC Configuration Examples 179 Configuration Examples
Figure 23. Controlling a JES2 MAS System via a VTAM Link
A tracker is started on each system in the configuration. An event-reader subtask in the controller reads events from System A. The event-reader on System B reads the event information from System C and passes the events to NCF for transmission to the controller. This event-reader is required because System C does not have its own link to the controller. The event-writer subtask on system B is started with a reader function—EWSEQNO is defined in the EWTROPTS statement. This means that the event writer passes the events for System B to NCF for transfer to the controller at the same time as they are written to the event dataset.
Note: This figure demonstrates the need for an event reader task where System C does not have a direct link to the controller. But if the required resources are available, try to give each tracker its own link to the controller.
Automatic workload restart can be used in this configuration if the controller cannot communicate with the tracker on System B. The status of the workstation for System B is set to offline if MVS is stopped or fails, if the tracker is stopped or fails, or if the VTAM link is lost. WLR actions are taken according to the WSOFFLINE keyword of JTOPTS. Workload restart is not affected by failures on System C, because the controller has no direct link with this system.
Table 42 on page 181 shows the initialization statements you can use to create the configuration in Figure 23.
180 Tivoli OPC Installation Guide Configuration Examples
Table 42. Example EQQPARM Members for Figure 18
EQQPARM members for System A
CONTROLR TRACKERA OPCOPTS OPCHOST(YES) OPCOPTS OPCHOST(NO) ERDRTASK(1) ERDRTASK(ð) ERDRPARM(ERDR1) EWTRTASK(YES) NCFTASK(YES) EWTRPARM(TRKAEW) NCFAPPL(NCFAPPL1) TRROPTS HOSTCON(DASD) ROUTOPTS SNA(NCFAPPL2)
ERDR1 TRKAEW ERDROPTS ERSEQNO(1) EWTROPTS
EQQPARM members for System B
TRACKERB TRKBEW OPCOPTS OPCHOST(NO) EWTROPTS EWSEQNO(1) ERDRTASK(1) ERDRPARM(ERDR2) EWTRTASK(YES) EWTRPARM(TRKBEW) NCFTASK(YES) NCFAPPL(NCFAPPL2) TRROPTS HOSTCON(SNA) SNAHOST(NCFAPPL1)
ERDR2 ERDROPTS ERSEQNO(2)
EQQPARM members for System C
TRACKERC TRKCEW OPCOPTS OPCHOST(NO) EWTROPTS HOLDJOB(NO) ERDRTASK(ð) EWTRTASK(YES) EWTRPARM(TRKCEW) TRROPTS HOSTCON(DASD)
Note: In this example, the controller has VTAM application ID NCFAPPL1, and the tracker on System B has VTAM application ID NCFAPPL2.
Controlling an OPC/A Release 2 System via Shared DASD Figure 24 on page 182 shows an OPC/A Release 2 system connected to an MVS sysplex. Here shared DASD is used for communication with the OPC/A Release 2 Event Manager Subsystem (EMS). Systems A and B are running MVS/ESA System Product Version 4 Release 1 or later; System C is running MVS/SP Version 1 Release 3 or later.
Appendix B. Tivoli OPC Configuration Examples 181 Configuration Examples
The Tivoli OPC started tasks on Systems A and B form an XCF group and use XCF services for work and event communication. An OPC/A Release 2 EMS is started on System C. The destination field in the workstation description for System C contains the DDNAME of the submit/release dataset. The Tivoli OPC controller sends work for this system to the submit/release dataset, which is read by the EMS event-writer function. The work is then passed to System C for processing.
Figure 24. Controlling an OPC/A Release 2 System via Shared DASD
System C writes event information to an event dataset, which is read by an event-reader subtask that is started on the controller.
The full functions of workload restart are available for System B in this configuration. If System B fails, the workstation that represents this destination is set to failed, and actions are taken according to the WSFAILURE keyword of the JTOPTS initialization statement. If the tracker on system B fails or if the communication link fails between the controller and the tracker, the workstation is set to offline. Actions are taken according to the WSOFFLINE keyword of JTOPTS. Automatic workload restart is available for System C if an I/O error occurs on the submit/release dataset when the controller is started. The workstation representing System C is set to offline, and actions are taken according to the WSOFFLINE keyword of JTOPTS.
182 Tivoli OPC Installation Guide Configuration Examples
Catalog management cannot be used on System C in Figure 24. OPC/A Release 2 does not support the catalog management function. Note: When a Tivoli OPC controller is connected by a submit/release dataset to an OPC/A Release 2 system, only the job JCL and release requests can be sent. Other Tivoli OPC record types are not valid. The controller recognizes the connection to an OPC/A Release 2 system by the DASD and the OPCAV1R2 keywords of the ROUTOPTS initialization statement. If these are not specified correctly, the controller will transmit data that the EMS cannot process.
Table 43 on page 184 shows the initialization statements you can use to create the configuration in Figure 24 on page 182.
Appendix B. Tivoli OPC Configuration Examples 183 Configuration Examples
Table 43. Example EQQPARM and DRKPARM for Figure 19
EQQPARM members for System A
CONTROLR TRACKERA OPCOPTS OPCHOST(YES) OPCOPTS OPCHOST(NO) ERDRTASK(1) ERDRTASK(ð) ERDRPARM(ERDR1) EWTRTASK(YES) ROUTOPTS DASD(SUDSC) EWTRPARM(TRKAEW) OPCAV1R2(SUDSC) TRROPTS HOSTCON(XCF) XCF(SYSATRK,SYSBTRK) XCFOPTS GROUP(OPCGRP) XCFOPTS GROUP(OPCGRP) MEMBER(SYSATRK) MEMBER(CONTR)
ERDR1 TRKAEW ERDROPTS ERSEQNO(2) EWTROPTS EWSEQNO(1) RELDDNAME(SUDSC)
EQQPARM members for System B
TRACKERB TRKBEW OPCOPTS OPCHOST(NO) EWTROPTS EWSEQNO(1) ERDRTASK(ð) EWTRTASK(YES) EWTRPARM(TRKBEW) TRROPTS HOSTCON(XCF) XCFOPTS GROUP(OPCGRP) MEMBER(SYSBTRK)
DRKPARM members for System C
OPCA2EMS EMSEW OPCOPTS OPCHOST(NO) EWTROPTS ERDRTASK(ð) EWTRTASK(YES) EWTRPARM(EMSEW)
Note: In this example, SUDSC is used for the user-defined ddname of the submit/release dataset. This ddname appears in the started-task JCL of the controller and in the destination field of the workstation that represents the controlled OPC/A Release 2 EMS system. Because this destination is an OPC/A Release 2 system, SUDSC must also be specified in the OPCAV1R2 keyword of the ROUTOPTS statement. The XCF group is called OPCGRP, It has members CONTR, SYSATRK, and SYSBTRK.
184 Tivoli OPC Installation Guide Configuration Examples
Controlling an OPC/A Release 2 System via a VTAM Link Figure 25 shows an OPC/A Release 2 system connected to a Tivoli OPC sysplex via a VTAM link. Systems A and B are running MVS/ESA System Product Version 4 or later. System C is running MVS/SP Version 1 Release 3 or later.
Figure 25. Controlling an OPC/A Release 2 System via a VTAM Link
The Tivoli OPC started tasks on Systems A and B form an XCF group and use XCF services for work and event communication. An OPC/A Release 2 EMS system is started on System C with an OPC/A Release 2 network event communicator (NEC) task. Unlike NCF, NEC cannot receive work from the controller. Jobs must be sent via a network job entry (NJE) link between the job entry subsystem (JES) on System A and System C. The controller submits the jobs to System A. The jobs must contain NJE JCL cards.
The EMS event-writer subtask writes events to its event dataset on System C. An event-reader subtask reads the event dataset and passes event information to NEC for transmission to the controller. Events are received at the controller by an NCF subtask and are then processed.
Appendix B. Tivoli OPC Configuration Examples 185 Configuration Examples
The full functions of workload restart are available for System B in this configuration. If System B fails, the workstation that represents this destination is set to failed, and actions are taken according to the WSFAILURE keyword of the JTOPTS initialization statement. If the tracker on system B fails or if the communication link fails between the controller and the tracker, the workstation is set to offline. Actions are then taken according to the WSOFFLINE keyword of JTOPTS. Note that operations for System B cannot be rerouted to System C. Limited workload-restart functions are available for System C. If the VTAM link is lost, the workstation that represents this destination is set to offline. Operations can be restarted on this workstation, but they cannot be rerouted. Restart actions are taken according to the value you specified on the WSOFFLINE keyword.
Catalog management cannot be used on System C in Figure 25 on page 185. OPC/A Release 2 does not support the catalog management function.
Table 44 on page 187 shows the initialization statements you can use to create the configuration in Figure 25 on page 185.
186 Tivoli OPC Installation Guide Configuration Examples
Table 44. Example EQQPARM and DRKPARM for Figure 20
EQQPARM members for System A
CONTROLR TRACKERA OPCOPTS OPCHOST(YES) OPCOPTS OPCHOST(NO) ERDRTASK(ð) ERDRTASK(ð) NCFTASK(YES) EWTRTASK(YES) NCFAPPL(NCFAPPL1) EWTRPARM(TRKAEW) ROUTOPTS SNA(NECAPPL) TRROPTS HOSTCON(XCF) OPCAV1R2(NECAPPL) XCFOPTS GROUP(OPCGRP) XCF(SYSATRK,SYSBTRK) MEMBER(SYSATRK) XCFOPTS GROUP(OPCGRP) MEMBER(CONTR)
TRKAEW EWTROPTS EWSEQNO(1)
EQQPARM members for System B
TRACKERB TRKBEW OPCOPTS OPCHOST(NO) EWTROPTS EWSEQNO(1) ERDRTASK(ð) EWTRTASK(YES) EWTRPARM(TRKBEW) TRROPTS HOSTCON(XCF) XCFOPTS GROUP(OPCGRP) MEMBER(SYSBTRK)
DRKPARM members for System C
OPCA2EMS EMSEW OPCOPTS OPCHOST(NO) EWTROPTS ERDRTASK(1) ERDRPARM(ERDR1) EWTRTASK(YES) EWTRPARM(EMSEW) NECTASK(YES) NECPARM(SYSCNEC)
ERDR1 SYSCNEC ERDROPTS ERSEQNO(1) NECDEFS NECHOME(NECAPPL) NECDEST(NCFAPPL1)
Note: In this example, the controller has VTAM application ID NCFAPPL1, and the OPC/A Release 2 NEC system has VTAM application ID NECAPPL. NECAPPL appears in the destination field of the workstation that represents the OPC/A Release 2 system. It must also be specified in the SNA and OPCAV1R2 keywords of the ROUTOPTS statement. The XCF group is called OPCGRP. It has members CONTR, SYSATRK, and SYSBTRK.
Appendix B. Tivoli OPC Configuration Examples 187
188 Tivoli OPC Installation Guide
Appendix C. Invoking the EQQEXIT Macro
The sample event-tracking exits shipped with Tivoli OPC are written in assembler language. The event-tracking code in these exits is generated by an assembler macro called EQQEXIT. The following sections describe how you invoke the EQQEXIT macro. This appendix contains General-use Programming Interface and Associated Guidance Information.
Invoking EQQEXIT in SMF Exits EQQEXIT establishes its own addressability in SMF exits. It saves and restores all used registers. To do this, it expects Register 13 to point to a standard MVS save area.
There are two ways to invoke the EQQEXIT macro in an SMF exit: Invoke EQQEXIT with all registers unchanged since the exit was called (except Register 15). Save all registers on entry to the exit and then invoke EQQEXIT by specifying the address of the initial save area.
In both cases, the EQQEXIT macro must be invoked in Supervisor state, PSW key 0.
Invoking EQQEXIT in JES Exits In JES exits, EQQEXIT must be invoked in Supervisor state, PSW key 1. EQQEXIT expects code addressability to be already established. It also expects registers to be set up as follows: EXIT7 R0 JCT read/write indicator (JES2 SP Version 3 and earlier); address of a parameter list mapped by the JES2 $XPL macro (JES2 SP Version 4 and later) R1 Address of the JCT being read or written R13 Address of the current PCE IATUX19 R8 Address of the current JDS entry R9 Address of the current RESQUEUE entry R11 Address of the current FCT entry R12 Address of the TVTABLE entry IATUX29 R11 Address of the current FCT entry R13 Address of the input-service data area for the current function. Note that these register conventions are already set up when the exit is called. You must invoke EQQEXIT while these registers are unchanged.
If a shipped JES exit example (or the EQQEXIT macro) has been user–modified, make sure that it does not prevent or filter the tracking of Tivoli OPC itself.
Copyright IBM Corp. 1991, 1999 189 Invoking EQQEXIT
Refer to the NOTES section of the EQQEXIT prologue for information about the register contents that are destroyed by EQQEXIT in JES exits.
Macro Invocation Syntax for EQQEXIT EQQEXIT produces Tivoli OPC event-tracking exit code by generating assembler code to perform in an SMF or JES exit.
Syntax EXIT=exit name REG13=address of save area MAPMAC={YES|NO} SETUID={YES|NO} SRREAD={YES|NO|NONE} SNA={YES|NO}
Parameters EXIT=exit name A required keyword defining the name of the exit in which the macro is used. The following names can be specified: IEFACTRT, IEFUJI, IEFU83, EXIT7, IATUX19, and IATUX29. Except for the EXIT7 exit, a warning message is issued if the name of the current CSECT differs from the name specified by the EXIT keyword. REG13=address of save area An optional keyword defining the address of the current-register save area when the SMF or JES exit was called. The default for this keyword depends on the name specified by the EXIT keyword. If the current exit is EXIT7, the default is PCELPSV. If the current exit is IATUX19 or IATUX29, the default is FCTSAVCH. In all other cases, the default is the second fullword in the current save area (if the current save area is properly chained, and the previous save area contains the registers at entry to the exit). If the default does not apply, the REG13 keyword must be specified. Its value must be a fullword pointing to the save area that was used to store all the registers when the exit was entered. MAPMAC={YES!NO} An optional keyword specifying whether the macro should generate the required assembler mapping macros. The default is to generate these mapping macros. The following mapping macros are required by EQQEXIT code: CVT, IEFJESCT, IEFJSSOB, and IEFJSSIB. The IEFACTRT exit also requires the IEFJMR macro. If you specify NO, the IEFU83 exit requires mapping of the SMF records IFASMFR 14 and IFASMFR 64. You must label them SMF14REC and SMF64REC, respectively. For example: SMF14REC DSECT ᑍ SMF RECORD 14 MAPPING IFASMFR 14 ᑍ DATA SET ACTIVITY RECORD SETUID={YES|NO} An optional keyword specifying whether the macro should generate code to place the current user ID in the JMRUSEID field when the IEFUJI exit is taken. Specify YES to generate this code. If you specify NO, which is the default, the JMRUSEID field is not updated. You are recommended to specify YES if you use the current user ID to filter dataset close events. You need these mapping macros when you specify YES: IHAPSA, IHAASCB, IHAASXB, and IHAACEE.
190 Tivoli OPC Installation Guide Invoking EQQEXIT
SRREAD={YES|NO|NONE} An optional keyword defining whether a resource availability event should be generated when a dataset is closed after being opened for read processing. When YES is specified or defaulted, an SR event is generated each time a dataset is closed after being opened for either read or output processing. When you specify NO, the SR event is generated only when a dataset has been opened for output processing. The event is not generated if the dataset has been opened for read processing. When you specify NONE, no dataset triggering is performed. See “Implementing Support for Data Set Triggering” on page 59 for more information about the dataset triggering function. SNA={YES|NO} An optional keyword specifying whether JES3 SNA NJE is supported.
Return Codes The following return codes can be generated at assembly time: 4 Input invalid, check for warning messages. 12 Unsupported exit specified for the EXIT keyword.
Messages The following messages can be generated at assembly time: WARNING: SNA KEYWORD IS ONLY USED FOR EXIT = IATUX19 WARNING: SNA VALUE SNA IS NOT RECOGNIZED WARNING: EXIT NAME DIFFERS FROM CURRENT CSECT NAME WARNING: MAPMAC VALUE MAPMAC IS NOT RECOGNIZED WARNING: SRREAD KEYWORD IS ONLY USED FOR EXIT=IEFU83 WARNING: SRREAD VALUE NOT RECOGNIZED, YES OR NO ARE THE ONLY VALID VALUES EXIT NAME EXIT IS NOT SUPPORTED.
Appendix C. Invoking the EQQEXIT Macro 191
192 Tivoli OPC Installation Guide
Appendix D. Invoking the EQQLSENT Macro
When the dataset triggering function is used, you specify the datasets for which you want events generated by building a dataset selection table—EQQDSLST. The EQQDSLST is created by invoking the EQQLSENT macro. The following sections describe how you invoke the EQQLSENT macro. This appendix contains General-use Programming Interface and Associated Guidance Information.
Invoking EQQLSENT to Create EQQDSLST The EQQLSENT macro is used to create entries in the dataset triggering selection table. The selection table is loaded into ECSA when the Tivoli OPC event writer is started.
The sample EQQLSJCL in the SEQQSAMP library can be used to invoke the EQQLSENT macro.
Macro Invocation Syntax for EQQLSENT EQQLSENT produces an entry in the dataset triggering selection table, EQQDSLST. EQQDSLST is used in SMF exit IEFU83 by the dataset triggering function to decide which SMF records to process. When an SMF 14, 15, or 64 record matches a condition in EQQDSLST, a special resource availability event is created and broadcast to all Tivoli OPC subsystems defined on the system where the SMF record was created.
Syntax STRING= string|LASTENTRY POS= numeric position USERID= user ID filter criteria JOBNAME= jobname filter criteria AINDIC={Y|N}
Parameters STRING=string|LASTENTRY A required keyword specifying the character string to be searched for. The string can be 1 to 44 characters long. To identify the fully-qualified last level of a dataset name, add a space as the last character and enclose the string in single quotes. Consider this example. You have two datasets: DSN.NAME.AB DSN.NAME.ABC Specify STRING=DSN.NAME.AB,POS=1 if you want SR availability events created for both datasets. Specify STRING='DSN.NAME.AB ',POS=1 if you want events created only for the first dataset. When EQQLSENT is invoked with STRING=LASTENTRY it generates an end of table indicator. After having invoked EQQLSENT with keyword parameters STRING and POS a number of times, EQQLSENT must be invoked one last time with STRING=LASTENTRY in order to complete the table.
Copyright IBM Corp. 1991, 1999 193 EQQLSENT Macro
To create an empty EQQDSLST, just invoke EQQLSENT once, with STRING=LASTENTRY. When an empty list is used by IEFU83, no SR events are created. POS=numeric position A required keyword specifying the numeric position where the string begins. USERID=string An optional keyword specifying a generic character string to be compared with the SMFxxUID field, which contains the user identification associated with the job, started task, or TSO user that requested the activity against the dataset that resulted in the dataset close. The string can be 1 to 8 characters long. Note: The SMF userid field may contain a blank value. Refer to MVS/ESA SMF for more information about the SMFxxUID or SMFxxUIF field. If you need to control SR availability events based on the userid and the SMF value is blank in your installation, consider using the IEFUJI exit to insert the userid. You are recommended to specify SETUID=YES on the EQQEXIT macro when you generate the IEFUJI exit: this sets the JMRUSEID field, which SMF then copies to the SMF userid field. If you want to update the JMRUSEID field yourself, the userid is most easily taken from the ACEEUSRI field in the ACEE, pointed to from the ASXB, pointed to from the ASCB. This can be located as follows:
PSAAOLD ===> ASCB ACSBASXB ===> ASXB ASXBSENV ===> ACEE ACEEUSRI ===> userid The DSECTs needed are mapped by these macros:
Area Macro Library PSA IHAPSA SYS1.MACLIB ASCB IHAASCB SYS1.MACLIB ASXB IHAASXB SYS1.MODGEN ACEE IHAACEE SYS1.MACLIB
The JMR, mapped by IEFJMR, is already available in the EQQEXIT expansion in IEFUJI. JOBNAME=string An optional keyword specifying a generic character string to be compared with the SMF14JBN, SMF15JBN, or SMF64JMN field, which contains the name of the job, started task or TSO user that requested the activity against the dataset that resulted in the dataset close. The string can be 1 to 8 characters long. | WARNING for CUSTOMERS using FTP at OS/390 V2R5 and above. | There is no longer one started task under which all file transfer takes | place, but many STCs called FTPD1 through FTPD9. So if a data set | needs to be triggered based on the jobname, its EQQLSENT invocation | must be coded nine times.
194 Tivoli OPC Installation Guide EQQLSENT Macro
AINDIC={Y|N} An optional keyword specifying if the special resource should be set to available (Y) or unavailable (N). The default is to make the resource available.
Notes: 1. The output from assembling the EQQLSENT macro must be placed in the EQQDSLST member in the dataset referenced by the ddname EQQJCLIB. 2. Generation Data Group datasets are specified by the group name. For example, when a GDG dataset with the name 'DSN.OPCSUBS.GDG.G0001V00' is closed the special resource event contains resource name 'DSN.OPCSUBS.GDG'. 3. For a partitioned dataset, the member name is not part of the resource name in the SR event. 4. For VSAM datasets the resource name in the SR event is the cluster name (without the DATA or INDEX suffix).
Example
EQQLSENT STRING=SYS1.MAN,POS=1 EQQLSENT STRING='TEST.DSCLOSE ',POS=1,USERID=SYSOP EQQLSENT STRING=CP2,POS=12 EQQLSENT STRING=EQQDATA.EXCL,POS=5 EQQLSENT STRING=LASTENTRY END
In this example, SMF records with: A dataset name beginning with SYS1.MAN, or Dataset name TEST.DSCLOSE and userid SYSOP Records with CP2 in position 12, such as DSN.OPCSUB.CP2, or Records that have EQQDATA.EXCL starting in position 5 will cause SR availability events to be generated.
Return Codes The following return code can be generated at assembly time: 12 Input invalid, check error messages.
Messages The following messages can be generated at assembly time: KEYWORD STRING IS REQUIRED KEYWORD POS IS REQUIRED POSITION MUST BE BETWEEN 1 AND 43 NULL NAME INVALID NAME (STRING) GREATER THAN 44 CHARACTERS POSITION INVALID FOR NAME (STRING) INVALID USERID STRING SPECIFIED INVALID JOBNAME STRING SPECIFIED AINDIC MUST BE EITHER Y OR N
Appendix D. Invoking the EQQLSENT Macro 195
POSITION TOO LARGE FOR NAME (STRING).
196 Tivoli OPC Installation Guide
Appendix E. Tivoli OPC Hardware and Software Requirements
This appendix describes the hardware and software requirements of Tivoli OPC and includes optional and related software.
Hardware Requirements Tivoli OPC operates on any IBM hardware configuration supported by one of the following: OS/390 Version 2 (program number 5647-A01) OS/390 Version 1 (program number 5645-001) MVS/ESA SP Version 5 (program numbers 5655-068, 5655-069) | Note: If you want to install the OPC Data Store, your IBM hardware configuration | must be supprted by one of the following: | OS/390 Version 2 (program number 5647-A01) | OS/390 Version 1.3 (program number 5645-001)
Tivoli OPC needs a minimum region of 8 MB below the 16 MB line; at least 32 MB must be available above the 16 MB line. The region value depends strictly on the Tivoli OPC customization and workload. For Tivoli OPC to work correctly, you may need to specify a region value of 64 MB, which gives you all the available space below the 16 MB line plus 64 MB above the 16 MB line.
A Tivoli OPC dialog user needs a region of 3 MB below the 16 MB line; Tivoli OPC report programs need a region of 3 MB below the 16 MB line.
Tivoli OPC uses less than 1 KB of 24-bit Common Service Area (CSA) storage. The amount of 31-bit Extended Common Service Area (ECSA) used is approximately 30 KB, plus 2 KB per active dialog user. In addition, the Tivoli OPC catalog management function uses approximately 160 bytes per dataset, and approximately 60 bytes per line, in the JESJCL and JESYSMSG datasets in ECSA while processing catalog updates and job log information respectively.
| The Job Scheduling Console requires one of the following: | A Pentium 233 computer with 64 MB of RAM and 30 MB of disk space plus | 2MB for each installed language capable of running one of the following | operating systems: | – Windows 95 | – Windows 98 | – Windows NT 4.0 (Service Pack 4 or 5) | 128 MB of RAM is recommended for performance reasons. | An RS/6000 computer with a minimum of 128 MB of RAM capable of running | AIX/6000 Version 4.2.1 | A SPARC** computer with a minimum of 64 MB of RAM capable of running | Solaris Version 2 Release 6.
| The OPC Connector requires one of the following:
Copyright IBM Corp. 1991, 1999 197
| A Pentium 233 computer capable of running Windows NT 4.0 (Service Pack 4 | or 5). | 128 MB of RAM is recommended for performance reasons. | An RS/6000 computer capable of running AIX/6000 Version 4.2.1 | An 700-series or 800-series computer capable of running HP-UX Version 10 or | Version 11. | A SPARC computer capable of running Solaris Version 2 Release 6.
| One Job Scheduling Console OPC Connector can be used to communicate with | multiple OPC controllers, and can serve multiple machines running Job Scheduling | Console. The Job Scheduling Console and the Job Scheduling Console OPC | Connector can be installed on the same machine.
Workload Monitor/2 requires a personal computer with a minimum of 8 MB of RAM, | and 2 MB of disk space for use by Workload Monitor/2, capable of running OS/2 | Warp Version 3 or Version 4, with Communications Manager/2 or Extended Services for OS/2. 12 MB of RAM is recommended for performance reasons.
| The Tracker Agent for OS/2 requires a computer capable of running OS/2 Warp | Version 3 or Version 4. The Tracker Agent uses about 1 MB of RAM.
The Tracker Agent for Windows NT requires an Intel-based computer (486 or higher) capable of running Windows NT Version 3 Release 5.1 or Version 4.0. The Tracker Agent uses about 1 MB of RAM.
The Tracker Agent for OS/400 requires an AS/400 computer with a minimum of | 3 MB of storage capable of running OS/400 Version 3 Release 2 or later, or an AS/400 RISC computer with a minimum of 6 MB of storage capable of running | OS/400 Version 3 Release 7, Version 4, or later. 8 MB of storage is recommended for performance reasons.
The Tracker Agent for AIX/6000 requires an RS/6000 computer with a minimum of | 3 MB of RAM, capable of running AIX/6000 Version 4. 8 MB of RAM is recommended for performance reasons.
| The Tracker Agent for HP-UX requires a 700-series computer capable of running | HP-UX Version 10 or Version 11. The Tracker Agent uses between 500 KB and 1 MB of memory.
The Tracker Agent for Sun Solaris requires a SPARC computer capable of running Solaris Version 2 Release 3. The Tracker Agent uses between 500 KB and 1 MB of memory.
The Tracker Agent for SunOS requires a SPARC computer capable of running | SunOS Version 4.1.3_u1 Version B. The Tracker Agent uses between 500 KB and 1 MB of memory.
The Tracker Agent for Digital OpenVMS requires a DEC VAX computer with at least 16 MB of memory or a DEC Alpha computer with at least 32 MB of memory, | capable of running OpenVMS Version 7.1. The Tracker Agent uses about 1 MB of memory.
198 Tivoli OPC Installation Guide Hardware and Software Requirements
| The Tracker Agent for Silicon Graphics IRIX requires an SGI Infigo2 Family | computer, capable of running Silicon Graphics IRIX Version 5.3. The Tracker Agent uses about 1 MB of memory.
The Tracker Agent for Digital UNIX requires a DEC Alpha computer with at least | 32 MB of memory, capable of running Digital UNIX 4.0D or later. The Tracker Agent uses about 1 MB of memory.
| The Tracker Agent for OS/390 Open Edition (OS/390 UNIX System Services) operates on any IBM hardware configuration supported by OS/390 Version 1 Release 3.
| A display terminal supported by ISPF Version 4.2 or later is required to invoke and run the OPC host dialogs.
The graphic function requires a terminal supporting Graphic Data Display Manager (GDDM/MVS) Version 2 Release 2 or later.
Software Requirements and Optional Software Tivoli OPC requires the functions provided by an MVS control program that is run in MVS/ESA mode. The Job Entry Subsystem may be either JES2 or JES3. Tivoli OPC requires one of the following environments: OS/390 Version 2 (program number 5647-A01) OS/390 Version 1 (program number 5645-001) MVS/ESA SP Version 5 (program numbers 5655-068, 5655-069)
| Installing and maintaining Tivoli OPC requires one of the following: | OS/390 Version 2 Release 7 (5647-A01) or later | OS/390 Version 2 Release 5 (5647-A01) or Release 6 with PTF UR51068 | installed | OS/390 Version 2 Release 4 (5647-A01) with PTF UR51067 installed | OS/390 Version 1 Release 3 (5645-001) with PTF UR51067 installed | OS/390 Version 1 Release 2 (5645-001) with PTF UR51071 installed | OS/390 Version 1 Release 1 (5645-001) with PTF UR51070 installed | System Modification Program Extended (SMP/E) Release 8.1 (program number | 5668-949) with PTF UR51070 installed or later.
Controlling System The following IBM licensed programs are required on the Tivoli OPC controlling system: | Tivoli OPC Version 2 Release 3 (program number 5697-OPC). Both the base product (the tracker) and the controller feature are required. The Tracker Agent enabler feature is required if any Tracker Agents are used. | Time Sharing Options/Extensions (TSO/E) Version 2 Release 5 (program | number 5685-025), or OS/390 Version 1 (5645-001), or OS/390 Version 2 | (5647-A01).
Appendix E. Tivoli OPC Hardware and Software Requirements 199 Hardware and Software Requirements
| Data Facility Sort (DFSORT*) Release 9 (program number 5740-SM1) or later, | or equivalent product. | Interactive System Productivity Facility (ISPF) for MVS, Version 4.2 (program | number 5655-042) or OS/390 Version 1 (5645-001) or OS/390 Version 2 | (5647-A01). ACF/VTAM* Version 3 Release 4.2 for MVS/ESA (program number 5685-085) or later, or Version 4 Release 3 for MVS/ESA (program number 5695-117) or later, or Communication Server for OS/390 Release 1 (program number | 5645-001) or later is required if Workload Monitor/2, the Tracker Agent for OS/400, remote dialogs, or remote PIF applications are used. TCP/IP for MVS Version 3 Release 2 (program number 5655-HAL) with C | socket API support, OS/390 Version 1 (5645-001), or OS/390 Version 2 | (5647-A01) is required if the Job Scheduling Console or any Tracker Agent for systems other than OS/400 is used.
| Tivoli Job Scheduling Console | One of the following operating systems is required by the Tivoli Job Scheduling | Console: | Windows 95, Windows 98 | Windows NT 4.0 (Service Pack 4 or 5) | AIX/6000 Version 4.2.1, or later, with | – JDK 1.1.8 (available to customers from | http://www.ibm.com/java/jdk/download/Index.html) | Solaris Version 2 Release 6 or later
| OPC Connector | One of the following operating systems is required by OPC Connector: | Windows NT 4.0 (Service Pack 4 or 5) | AIX/6000 Version 4.2.1, or later, with | – JDK 1.1.8 (available to customers from | http://www.ibm.com/java/jdk/download/Index.html) | HP-UX 10.2 or later | Solaris Version 2 Release 6 or later
| The Tivoli Framework (5697-FRA) Version 3.6.1, supplied with Tivoli OPC Version | 2 Release 3, or later is required to install and operate the OPC Connector.
Workload Monitor/2 The following IBM licensed programs are required by Workload Monitor/2: | Operating System/2 (OS/2) Warp Version 3 (program number 5622-601), or Operating System/2 (OS/2) Warp Version 4 (program number 5622-851), with Communications Manager/2 (program number 5622-078) or Communications Server Version 4 (program number 5622-878)
200 Tivoli OPC Installation Guide Hardware and Software Requirements
Controlled OS/390 Systems On each Tivoli OPC-controlled OS/390 system, one of the following IBM licensed programs is required: Tivoli OPC Version 2 (program number 5697-OPC). Only the base product (the tracker) is required. OPC/ESA Version 1 Release 3 Modification Level 1 (program number 5695-007). Only the base product (the tracker) is required.
Controlled OS/2 Systems To manage workloads from Tivoli OPC on OS/2, the following IBM licensed programs and features are required: OPC Tracker Agent for OS/2 in Tivoli OPC Version 2. One Tracker Agent feature is required on each OS/2 machine with workload managed by Tivoli OPC. | OS/2 Warp 3.0 (program number 5622-601), or OS/2 Warp 4.0 (program number 5622-851). TCP/IP for OS/2 Version 2 (5622-086) or later.
Controlled Windows NT Systems To manage workloads from Tivoli OPC on Windows NT, the following programs and features are required: OPC Tracker Agent for Windows NT in Tivoli OPC Version 2. One Tracker Agent feature is required on each machine with workload managed by Tivoli OPC. | Windows NT Version 3 Release 5.1, or Version 4.0
Controlled OS/400 Systems To manage workloads from Tivoli OPC on OS/400, the following IBM licensed programs and features are required: OPC Tracker Agent for OS/400 in Tivoli OPC Version 2. One Tracker Agent feature is required on each AS/400 machine with workload managed by Tivoli OPC. | OS/400 Version 3 Release 2 (program number 5738-SS1) or later, or OS/400 | Version 3 Release 7 (program number 5716-SS1) or later, or OS/400 Version 4 | (program number 5769-SS1) or later.
Controlled UNIX Systems To manage workloads from Tivoli OPC on UNIX systems, the following programs and features are required on the managed UNIX system: AIX/6000 Tracker Agent for AIX in Tivoli OPC Version 2. One Tracker Agent feature is required for each RS/6000 machine with workload managed by Tivoli OPC. | AIX/6000 Version 4.2 (5765-655) with the optional TCP/IP feature installed.
Appendix E. Tivoli OPC Hardware and Software Requirements 201 Hardware and Software Requirements
HP-UX Tracker Agent for HP-UX in Tivoli OPC Version 2. One Tracker Agent feature is required on each machine with workload managed by Tivoli OPC. | HP-UX Version 10 or Version 11. Sun Solaris Tracker Agent for Sun Solaris in Tivoli OPC Version 2. One Tracker Agent feature is required on each SPARC workstation with workload managed by Tivoli OPC. | Sun Solaris Version 2 Release 3 or later. SunOS Tracker Agent for SunOS in Tivoli OPC Version 2. One Tracker Agent feature is required on each SPARC workstation with workload managed by Tivoli OPC. If your machines have LoadLeveler Version 1 Release 2 for Sun SPARCstation systems (program number 5765-227) installed, only one OPC Tracker Agent feature is required. | Solaris Version 1.1.1b (SunOS 4.1.3_u1 Version B) or Solaris Version 1.1.2 | (SunOS 4.1.4).
Controlled Digital OpenVMS Systems To manage workloads from Tivoli OPC on a Digital OpenVMS system, the following programs and features are required: OPC Tracker Agent for Digital OpenVMS in Tivoli OPC Version 2. One Tracker Agent feature is required on each machine with workload managed by Tivoli OPC. | OpenVMS Version 7.1.
| Controlled Silicon Graphics IRIX Systems | To manage workloads from Tivoli OPC on Silicon Graphics IRIX, the following | programs and features are required: | OPC Tracker Agent for Silicon Graphics IRIX in Tivoli OPC Version 2. One | Tracker Agent feature is required on each machine with workload managed by | Tivoli OPC. | SGI IRIX Version 5.3 or later.
| Controlled OS/390 UNIX System Services | To manage workloads from Tivoli OPC on OS/390 UNIX System Services, the following programs and features are required: OPC Tracker Agent for OS/390 Open Edition in TME 10 OPC Version 2. One Tracker Agent feature is required on each machine with workload managed by Tivoli OPC. | OS/390 Version 1 Release 3 (program number 5645-001) or later with UNIX | System Services.
202 Tivoli OPC Installation Guide Hardware and Software Requirements
Controlled Digital UNIX Systems To manage workloads from Tivoli OPC on Digital UNIX, the following programs and features are required: OPC Tracker Agent for Digital UNIX in TME 10 OPC Version 2. One Tracker Agent feature is required on each machine with workload managed by Tivoli OPC. | Digital UNIX Version 4.0D or later.
Optional Software The following Tivoli OPC functions require specific IBM programs: Tracking resource availability requires the Resource Object Data Manager | (RODM) in NetView Version 2 Release 4 or later (program number 5685-111), or NetView Version 3 (program number 5655-007), or Tivoli NetView for OS/390 (program number 5697-B82). Graphical functions require GDDM/MVS Version 2 Release 2 (program number | 5665-356), or Version 3.1.1 (program number 5695-167), or OS/390 Version 1 | (5645-001), or OS/390 Version 2 (5647-A01). Application transaction programs (ATP) that use OPC's application programming interface (API) require ACF/VTAM Version 3 Release 4.2 for MVS/ESA (program number 5685-085) or later, or ACF/VTAM Version 4 Release 3 for MVS/ESA (program number 5695-117) or later, or Communication Server for OS/390 Release 1 (program number 5645-001) or later. | Connecting a controller and a tracker via VTAM* requires ACF/VTAM Version 3 | Release 4.2 for MVS/ESA (program number 5685-085) or later, or ACF/VTAM | Version 4 Release 3 for MVS/ESA (program number 5695-117) or later, or Communication Server for OS/390 Release 1 (program number 5645-001) or later. Remote processing with RJE requires ACF/VTAM Version 3 Release 4.2 for | MVS/ESA (program number 5685-085) or later, or ACF/VTAM Version 4 | Release 3 for MVS/ESA (program number 5695-117) or later, or Communication Server for OS/390 Release 1 (program number 5645-001) or later. Remote dialogs and remote PIF applications require ACF/VTAM Version 3 | Release 4.2 for MVS/ESA (program number 5685-085) or later, or ACF/VTAM | Version 4 Release 3 for MVS/ESA (program number 5695-117) or later, or Communication Server for OS/390 Release 1 (program number 5645-001) or later. | NetView Version 2 Release 4 for MVS/ESA (program number 5685-111) or | later or Tivoli NetView for OS/390 (5697-B82) is required to enable Tivoli OPC to schedule generic alerts as defined by that NetView release. | NetView Version 2 Release 4 for MVS/ESA (program number 5685-111) or | later or Tivoli NetView for OS/390 (5697-B82) is required to specify an alert receiver ID other than the default receiver. User-authority-support functions require Resource Access Control Facility | (RACF) Version 2 (program number 5695-039) or later, or OS/390 Release 1 | (5645-001) Security Server or later.
Appendix E. Tivoli OPC Hardware and Software Requirements 203 Hardware and Software Requirements
| DFSMS/MVS (5695-DF1) with Hierarchical Storage Management component is required for the catalog management function to recall migrated datasets. LoadLeveler for RISC System/6000* Release 2 (program number 5765-145) is required if you want to submit AIX tasks through LoadLeveler. LoadLeveler Version 1 Release 2 for Hewlett-Packard** systems (program number 5765-287) is required if you want to submit HP-UX tasks through LoadLeveler. LoadLeveler Version 1 Release 2 for Sun SPARCstation systems (program number 5765-227) is required if you want to submit Sun Solaris or SunOS tasks through LoadLeveler. | DB2 for MVS Version 3 (program number 5685-DB2), or DB2 for MVS Version 4 (program number 5695-DB2), or DB2 for OS/390 Version 5 (program number 5655-DB2) is required to use the History function (restart of old operations). | Scheduling SAP R/3 jobs requires the Tivoli Workload Scheduler Extended | Agent for SAP R/3 Version 3 (program number 5697-WKB) feature, and the Tivoli OPC Tracker Agent for one of the following platforms: – AIX – Digital UNIX – Sun Solaris – Windows NT – HP-UX. The OPC Control Language tool requires the IBM Compiler Library for REXX/370 Version 1 Release 3 (program number 5695-014).
Related Software These IBM licensed programs can be used with Tivoli OPC to provide comprehensive, integrated DP operations: NetView Version 2 Release 2 for MVS/ESA (program number 5685-111) or Tivoli NetView for OS/390 (program number 5697-B82) | Data Facility Storage Management Subsystem (DFSMS/MVS) (5695-DF1) | Report Management and Distribution System (RMDS) Version 2 Release 3 | (program number 5648-048) Tivoli Performance Reporter for OS/390 Version 1 Release 3 (program number 5695-101) System Automation for OS/390 Release 2 (program number 5645-005). Tivoli Global Enterprise Manager Version 1 (program number 5697-B83) or Version 2 (program number 5697-GEM)
Software Compatibility Tivoli OPC Version 2 Release 3 uses only existing attachment interfaces to other IBM products. | Tivoli OPC Version 2 Release 3 can coexist with Tivoli OPC Version 2 Release | 2, Tivoli OPC Version 2 Release 1 or with OPC/ESA Version 1 Release 3
**Hewlett-Packard is a trademark of Hewlett-Packard Corp.
204 Tivoli OPC Installation Guide Hardware and Software Requirements
Modification Level 1, but the products cannot share program libraries, files or datasets. | Event datasets containing events created by Tivoli OPC Version 2 Release 1, | Tivoli OPC Version 2 Release 2, or by OPC/ESA Version 1 Release 3 Modification Level 1 can be used as input to Tivoli OPC Version 2 Release 2. A Tivoli OPC Version 2 Release 3 system can be used to transmit work to a | Tivoli OPC Version 2 Release 1, Tivoli OPC Version 2 Release 2, or OPC/ESA Version 1 Release 3 Modification Level 1 system using shared submit/release dataset, Network Job Entry (NJE), OPC Network Communications Facility (NCF), cross-system coupling facility (XCF), or by transmitting events on an | established session between Tivoli OPC Version 2 Release 3 and Tivoli OPC | Version 2 Release 2 or Tivoli OPC Version 2 Release 1 or OPC/ESA Version 1 | Release 3 Modification Level 1. | Previous definitions made in OPC/ESA or Tivoli OPC Version 2 Release 1 or | Tivoli OPC Version 2 Release 2 behave as before after upgrading to Tivoli OPC Version 2 Release 3. | JES and SMF exits used to create Tivoli OPC Version 2 Release 3 events can | also be used to create Tivoli OPC Version 2 Release 1 or Tivoli OPC Version 2 | Release 2 events after upgrading to Tivoli OPC Version 2 Release 3. | Existing PIF application programs that work with Tivoli OPC Version 2 Release | 2 can be used unchanged on Tivoli OPC Version 2 Release 3. Existing PIF | application programs that work with Tivoli OPC Version 2 Release 1 or | OPC/ESA Version 1 Release 3 Modification Level 1 can be used unchanged on | Tivoli OPC Version 2 Release 3, unless Access Method information is stored in | a workstation record, in which case that workstation record will include a new | sub-segment. Refer to the Tivoli Programming Interfaces manual. The Workload Monitor/2 code shipped with OPC/ESA Version 1 Release 3 Modification Level 1 and Tivoli OPC Version 2 Release 1 and Tivoli OPC Version 2 Release 2 can communicate with a Tivoli OPC Version 2 Release 3 controller.
Appendix E. Tivoli OPC Hardware and Software Requirements 205 Hardware and Software Requirements
206 Tivoli OPC Installation Guide
Appendix F. History of Changes Since OPC/ESA Version 1 Release 1
This appendix summarizes changes made to the OPC/ESA Version 1 product since OPC/A Release 2.
The tables of changed interfaces summarize the new, changed, and deleted end-user and programming interfaces for OPC/ESA Each of the following interfaces has a summary table: Initialization statements Commands Callable routines Programming interfaces Executable macros Installation exits Messages Miscellaneous changes Note: The information in this chapter will be updated only for new editions of this publication. That is, there will be no documentation changes for this section as a result of service to OPC/ESA.
Changes to Initialization Statements Initialization statements have been added, deleted, and changed in OPC/ESA Version 1 releases. The following sections summarize the differences.
New Initialization Statements These initialization statements have been added in OPC/ESA Version 1: APPCROUT Defines additional routing options for APPC-connected tracker agents. EXITS Defines which installation exits should be loaded. INIT Defines run-time options for processing requests from PIF applications. Overrides the settings of the INTFOPTS statement. INTFOPTS Specified at the controller. Defines global options for processing requests from programming interfaces. A required statement. JOBOPTS Specified at the tracker. Defines the dataset cleanup and job-log-retrieval options. NOERROR Documents acceptable non-zero return codes and error codes. The statement can be specified multiple times, each statement containing up to 455 lines. Conditions can be specified generically. RESOPTS Defines options used by the controller when processing special resources defined by operations for scheduling and tracking purposes. RESOURCE Identifies the resource names for which daily planning will create detailed reports.
Copyright IBM Corp. 1991, 1999 207 OPC/ESA Version 1 Summary
RODMOPTS Specified at the controller. Identifies a special resource that you want to monitor using RODM (resource object data manager). ROUTOPTS Specified at the controller. Identifies the connection method to each tracker. TRROPTS Specified at the tracker. Identifies the connection method to the controller. XCFOPTS When XCF is used as the connection method, defines the member name and the sysplex name. The APPCROUT Statement: Added in OPC/ESA Release 3, the APPCROUT statement defines additional routing information for APPC-connected tracker agents. Routing options defined on the statement are used by the receiving focal point node to distribute work to other nodes in the network. A statement is defined for each unique network address that the focal point should direct OPC/ESA-submitted jobs. The statement is not required if OPC/ESA-submitted jobs are to be started on the focal point node.
Table 45. The APPCROUT Statement Keyword Short description ADDR Defines the fully qualified network address for the workstations referenced by this statement. WORKSTATIONS List of the OPC/ESA workstations for which operations should be directed to the node identified by the ADDR keyword.
The EXITS Statement: Added in OPC/ESA Release 1, the EXITS statement lets you define the installation exits in use. By default, OPC/ESA will attempt to load all installation exits.
Table 46. The EXITS Statement Keyword Short description CALLxx Specifies whether an installation exit should be loaded. LOADxx Defines an alternate load module name for an installation exit.
The INIT Statement: Added in OPC/ESA Release 3.1, the INIT statement lets you define run-time options for processing requests from a PIF application. These settings override the values set by the INTFOPTS statement in EQQPARM. The statement is defined in a second parameter file that is identified by the EQQYPARM DD statement in the JCL procedure of the PIF application.
Table 47. The INIT Statement Keyword Short description CWBASE Specifies the origin for the century window used by the PIF application HIGHDATE Specifies the high date presented to the PIF application in valid-to fields SUBSYS Identifies the OPC/ESA subsystem controller TRACE Specifies the level of trace information to write to the diagnostic file.
208 Tivoli OPC Installation Guide OPC/ESA Version 1 Summary
The INTFOPTS Statement: Added in OPC/ESA Release 3.1, the INTFOPTS statement defines global run-time options for processing requests from programming interfaces. The statement is required.
Table 48. The INTFOPTS Statement Keyword Short description PIFCWB Specifies the origin for the century window used by the programming interface PIFHD Specifies the high date presented in valid-to fields of applications and run cycles.
The JOBOPTS Statement: Added in OPC/ESA Release 3, the JOBOPTS statement specifies options for dataset cleanup information and job-log retrieval used by the tracker. Some of the keywords on JOBOPTS were previously defined on OPCOPTS in OPC/ESA Release 2.
Table 49. The JOBOPTS Statement Keyword Short description CATMCLAS Defines the SYSOUT classes for retrieval of job log information. Added in OPC/ESA Release 2.1. CATMDISP Defines the disposition of the job log output. Added in OPC/ESA Release 2.1. CHSMWAIT Defines how long catalog management waits for HSM to recall a migrated dataset. Added in OPC/ESA Release 2. JOBLOGRETRIEVAL Determines how and when OPC/ESA collects job-log output required for step-level restart or job-log browse requests. Added in OPC/ESA Release 3. MAXNUMUSYS Determines the amount of user SYSOUT that OPC/ESA collects with the job log. Added in OPC/ESA Release 3.
The NOERROR Statement: Added in OPC/ESA Release 2, the NOERROR statement identifies job error codes that should not be treated as error conditions by the controller. The statement is functionally equivalent to the NOERROR keyword of the JTOPTS statement.
Multiple NOERROR statements can be defined; each statement may consist of up to 455 input lines. Conditions can be specified generically.
Table 50. The NOERROR Statement Keyword Short description LIST A list of error conditions that will not be treated as errors by the controller.
Appendix F. History of Changes Since OPC/ESA Version 1 Release 1 209 OPC/ESA Version 1 Summary
The RESOPTS Statement: Added in OPC/ESA Release 3, the RESOPTS statement defines options which determine the behavior of OPC/ESA resources.
Table 51. The RESOPTS Statement Keyword Short description CONTENTIONTIME Determines how long an operation waits to allocate a special resource before alert message EQQQ515W is issued if alerts have been requested for special resource contention. DYNAMICADD Determines if OPC/ESA creates special resources dynamically in the plan if there is no special resource description defined. LOOKAHEAD Specifies, as a percentage of the operation estimated duration, how long a resource must be available before OPC/ESA will start an operation that needs it. Introduced with APAR PN64340. ONERROR Previously defined on the JTOPTS statement, defines when resources should remain allocated if an operation ends in error.
The RESOURCE Statement: Added in Release 3, the RESOURCE statement identifies the special resource names for which daily planning will create detailed reports. By default, OPC/ESA will not create detailed reports for special resources. Resource names can be specified generically. The statement is defined in the same member of the parameter library as the BATCHOPT statement.
Table 52. The RESOURCE Statement Keyword Short description FILTER A list of special resource names for which daily planning will create detailed reports.
The RODMOPTS Statement: Added in OPC/ESA Release 3, the RODMOPTS statement lets you associate fields of special resources in the current plan with fields in RODM classes or RODM objects. You can use this support to track the status of real resources used by OPC/ESA operations. RODM notifies OPC/ESA of changes to field values and OPC/ESA updates the associated special resources. Multiple statements can be defined.
Table 53. The RODMOPTS Statement Keyword Short description DESTINATION Identifies the destination ID of a tracker. OPCFIELD Identifies a field name in the special resource. OPCRESOURCE Identifies the special resource that requires monitoring. RODMCLASS Identifies a RODM class. RODMFIELD Identifies a field name in the RODM class or RODM object, which is used to monitor the special resource. RODMLOST Determines the field value when communication with RODM is lost. RODMOBJECT Identifies a RODM object. RODMSYSTEM Identifies the RODM subsystem. TRANSLATE Defines translation of values returned by RODM.
The ROUTOPTS Statement: Added in OPC/ESA Release 1, the ROUTOPTS statement defines the controlled systems and the method used to communicate with the controlled systems.
210 Tivoli OPC Installation Guide OPC/ESA Version 1 Summary
Table 54. The ROUTOPTS Statement Keyword Short description APPC Identifies the LUs of APPC-connected tracker agents. Added in OPC/ESA Release 3. CODEPAGE Defines the host codepage. Required when Tracker Agents execute on operating environments that use the ASCII character set. Added in OPC/ESA Release 3. DASD Identifies the tracker destinations connected by shared DASD. DESTID Identifies the destination for catalog-management actions when the system cannot be identified by the workstation. Added in OPC/ESA Release 2. OPCAV1R2 Identifies the OPC/A Release 2 EMS subsystems connected to the controller by shared DASD or NEC. PULSE Defines the time between handshakes for the controller and the trackers, or Tracker Agents. If a tracker or Tracker Agent does not respond to two successive handshake requests, the controller sets the destination offline. Added in OPC/ESA Release 3. SNA Identifies trackers and OPC/A Release 2 NEC subsystems with a VTAM connection to the controller. SYSID Identifies the MVS system for catalog-management actions when the system cannot be identified by the workstation. Added in OPC/ESA Release 2. TCP Identifies the TCP/IP-connected tracker agents. Added in OPC/ESA OPC/ESA Release 3. TCPIPID The name of the TCP/IP address space on the MVS system where the controller is started. Added in OPC/ESA OPC/ESA Release 3. TCPIPPORT The TCP/IP port number of the controller. Added in OPC/ESA Release 3. TCPTIMEOUT Specifies the interval, in minutes, within which the controller expects the TCP/IP-connected Tracker Agent to respond to a submit request. The session is terminated, and the workstation set offline, if the Tracker Agent does not respond in two consecutive intervals. Specify 0 if no time-out is required. Added in OPC/ESA Release 3. with APAR PN64030. USER Identifies the user-defined destinations. Operation-initiation exit, EQQUX009, is called to start operation for user-defined destinations. Added in OPC/ESA Release 2.1. XCF Identifies the sysplex member name of trackers connected by XCF.
The TRROPTS Statement: Added in OPC/ESA Release 1, the TRROPTS statement defines at the controlled system how to communicate with the controlling system.
Table 55. The TRROPTS Statement Keyword Short description HOSTCON Defines how the tracker is connected to the controller. SNAHOST When the connection method is VTAM, defines the LU of the controller.
Appendix F. History of Changes Since OPC/ESA Version 1 Release 1 211 OPC/ESA Version 1 Summary
The XCFOPTS Statement: Added in OPC/ESA Release 1, the XCFOPTS statement defines the sysplex name and the member name when the cross-system coupling facility is used as the connection method.
Table 56. The XCF Statement Keyword Short description GROUP Defines the name of the sysplex. MEMBER Defines the member name of the tracker or controller in the sysplex. TAKEOVER On a standby controller, defines the conditions under which a takeover will be initiated.
Deleted Initialization Statements
The NECDEFS initialization statement is not used in OPC/ESA. Instead, you now specify the NECHOME keyword value in the NCFAPPL keyword of the OPCOPTS statement. For a controller or standby controller, specify the NECDEST keyword value in the SNA keyword of the ROUTOPTS statement. For a tracker, specify the NECDEST keyword value in the SNAHOST keyword of the TRROPTS statement. You must also specify HOSTCON(SNA) for this tracker.
Updates to Initialization Statements
This section summarizes the new, deleted, and changed keywords and keyword values.
Table 57. Changes to the ALERTS Statement Keyword Short description of change TYPE Replaced by GENALERT, MLOG, and WTO keywords in Release 1. GENALERT Defines the conditions when a generic alert is sent to NetView. Added in Release 1. MLOG Defines alert conditions for which a message is written to EQQMLOG. Added in Release 1. RESCONT value added in Release 3 to request alerts for special resource contention. RECEIVERID Defines the NetView alert receiver identifier. Added in Release 3. WTO Defines alert conditions for which a WTO message is generated. Added in Release 1. RESCONT value added in Release 3 to request alerts for special resource contention.
Table 58. Changes to the AROPTS Statement Keyword Short description of change AUTHUSER Defines where OPC/ESA retrieves the name that is used for authority checking. Added in Release 1 by PN16531. JCLEDITOR value added in Release 3 so that if the JCL has not been updated through the dialogs or PIF, OPC/ESA does not perform authority checking. USERREQ Determines if AR can update the current plan when the userid cannot be determined. Added in Release 1 by PN16531.
212 Tivoli OPC Installation Guide OPC/ESA Version 1 Summary
Table 59. Changes to the AUDIT Statement Keyword Short description of change FILE JV and VAR values are added in Release 1 for JCL variable tables and JCL variable settings. The RD value is added for special resource definitions in Release 3.
Table 60. Changes to the AUTHDEF Statement Keyword Short description of change LISTLOGGING Defines how data is logged for accesses to resources. Added in Release 1 by PN12549. SUBRESOURCES These subresources have been added: AD.ADGDDEF CP.CPGDDEF JV.OWNER JV.TABNAME LT.LTGDDEF RD.RDNAME RL.WSSTAT TRACE Activates a trace of RACROUTE requests to enable more effective problem determination of security-related problems. Added in Release 3.
Table 61. Changes to the BATCHOPT Statement Keyword Short description of change CHECKSUBSYS Defines if daily planning should process when communication with the controller via ENQs is not possible. Added in Release 1 by PN46061. CONTROLLERTOKEN Used as a key by the history function. Added in Release 1.3.1. DB2AVAIL Specifies action to take if the DB2 system is not available. Added in Release 1.3.1. DB2SYSTEM Specifies the DB2 subsystem. Added in Release 1.3.1. DYNAMICADD Defines if the installation allows dynamic creation of special resources. Added in Release 3. LTPDEPRES Defines if LTP extend batch processing should modify the entire LTP or only the extended part. Added in Release 2 by PN09855. MAXOCCNUM Used by daily planning extend and create. It limits the number of occurrences that can be added to the current plan. Added in Version 2 Release 2. NCPTROUT Defines if daily planning should write the new current plan information to the EQQTROUT ddname. Added in Release 2.1. OCPTROUT Defines if daily planning should write the old current plan information to the EQQTROUT ddname. Added in Release 2.1. OPERHISTORY Defines if the history function is active. Added in Release 1.3.1. RETAINOPER Used by the history function, it specifies how long an operation is kept in the database. Added in Release 1.3.1.
Appendix F. History of Changes Since OPC/ESA Version 1 Release 1 213 OPC/ESA Version 1 Summary
Table 62. Changes to the EWTROPTS Statement Keyword Short description of change EWSEQNO Defines if the event writer should add events directly to the data router queue when the connection method ID NCF, XCF, or when the controller and tracker are started in the same address space. Added in Release 1. PRINTEVENTS Defines if and when OPC/ESA should create type 4 events. Added in Release 1 by PN23805.
Table 63. Changes to the JCCOPTS Statement Keyword Short description of change UMAXLINE Defines the number of records of user SYSOUT to be scanned by the JCC. Added in Release 3. USYSOUT Defines if and when the JCC should scan user SYSOUT datasets. Added in Release 3.
Table 64 (Page 1 of 2). Changes to the JTOPTS Statement Keyword Short description of change BACKUP A new value, NO, added in Release 2 which means that OPC/ESA does not automatically reorganize the active current-plan dataset. You can request a reorganization on demand. CURRPLAN Defines whether the controller should start from the NCP or the current current plan. Must have the value NEW when OPC/ESA Release 3 is first started after migration. DUAL Defines if dual logging of job-tracking records is required. Added in Release 2. JCLEXIT Deleted in Release 1. The controller will attempt to load EQQUX002. Override the default using the EXITS statement. JTLOGS Defines the number of job-tracking log datasets, default is 5. Added in Release 2. MAXJSFILE A new value, NO, added in Release 2 which means that OPC/ESA does not automatically reorganize the JCL repository dataset. You can request a reorganization on demand. MAXOCCNUM Sets a limit on the number of new occurrences that can be added to the current plan. Added in Version 2 Release 2. OFFDELAY Defines the time between when a destination is reported as offline and when OPC/ESA initiates offline actions. Added in Release 1. OPINFOSCOPE Defines if events updating an operation user data field can be matched only for operations in an in-progress status, or if completed and waiting operations are also considered. Added in Release 3. ONERROR Keyword moved to the RESOPTS statement in Release 3. OPREROUTEDEFAULT Defines if operations are reroutable if the reroute value specified at operation level is blank. Added in Release 2 by PN42976. OPRESTARTDEFAULT Defines if operations are restartable if the restart value specified at operation level is blank. Added in Release 2 by PN42976. OVERCOMMIT Defines the number of operations that can be started on automatic workstations in addition to the parallel server ceiling. Previously defined by the QUEUELEN keyword. Added in Release 1 by PN30690.
214 Tivoli OPC Installation Guide OPC/ESA Version 1 Summary
Table 64 (Page 2 of 2). Changes to the JTOPTS Statement Keyword Short description of change QUEUELEN Defines the maximum number of operations the WSA will start each time it has control of the current plan. The keyword previously had a dual function; see OVERCOMMIT. SHUTDOWNPOLICY Determines whether operations will start if the workstation closes before the estimated duration elapses. Added in Release 1. SUBFAILACTION Determines the operation status if an error during job submission is encountered. Added in Release 1. SUPPRESSACTION Determines the operation status of late time-dependent operations. Added in Release 1. SUPPRESSPOLICY Identifies the submission window for time-dependent operations. Added in Release 1. TRACK The keyword now has two values: the second value determines how events for operations submitted outside OPC/ESA will be matched. Changed in Release 2 by PN51937. WSFAILURE Defines the actions when a destination is reported in failed status. Added in Release 1. WSOFFLINE Defines the actions when a destination is reported in offline status. Added in Release 1.
Table 65 (Page 1 of 2). Changes to the OPCOPTS Statement Keyword Short description of change APPCTASK Defines if APPC/MVS services are required in a tracker or a controller. Added in Release 2. BUILDSSX Causes the SSX built at subsystem initialization to be rebuilt at the current software level when the address space starts. Added in Release 3. CATACT Defines whether catalog management should delete or uncatalog datasets. Added in Release 2. CATMGT At the tracker and the controller, defines if dataset cleanup is required for operations that end in error or are rerun. Added in Release 2. CATMLVL Defines if the catalog-management function is required at job-level or step-level. Added in Release 2.1 and removed in Release 3. CONTROLLERTOKEN Used as a key by the history function. Added in Release 1.3.1. DB2SYSTEM Specifies the DB2 subsystem used for the history function. Added in Release 1.3.1. GTABLE Defines the name of the global JCL variable table. Added in Release 1. JES2CMDCHAR Deleted in Release 1. JOBLOGDEST Defines the destination pairs for job-log retrieval if the output has been routed off the system where the job was executed. Added in Release 3. NJENODE Deleted in Release 1. NECTASK Replaced by NCFTASK keyword in Release 1. NECPARM Deleted in Release 1. NCFAPPL Defines the name of the LU used by the address space when the NCF task is used as a connection method. Added in Release 1.
Appendix F. History of Changes Since OPC/ESA Version 1 Release 1 215 OPC/ESA Version 1 Summary
Table 65 (Page 2 of 2). Changes to the OPCOPTS Statement Keyword Short description of change NCFTASK Defines if the NCF task should be started. Added in Release 1. OPCHOST Supports the value STANDBY to start a controller address space in standby mode. Changed in Release 1. OPERHISTORY Defines if the history function is active. Added in Release 1.3.1. RODMPARM Defines a member name in the parameter library where the RODMOPTS statement is defined. Added in Release 3. RODMTASK Defines if OPC/ESA RODM support is required in a tracker or a controller. Added in Release 3. SSCMNAME This keyword now has two values: the second value determines if the SSCM module to be loaded should replace the one loaded at IPL. Added in Release 3. STORELOG Determines if job logs sent from a tracker using immediate retrieval will be stored by the controller. Added in Release 3. VARSUB Defines is JCL variable substitution is used. Added in Release 1.
Refer to Customization and Tuning for detailed information about the changes to initialization statements.
Changes to Commands
MVS Commands These modify commands have been added: NEWDSLST Requests the dataset triggering selection table be rebuilt. Added in Release 2.1. TAKEOVER Requests a standby controller to take over the functions of the controller. Added in Release 1.
These subtasks have been added to the list of subtasks which can be stopped and started using the MODIFY ssname,S=subtask and MODIFY ssname,P=subtask commands: APPC APPC subtask. Added in Release 2. AR Automatic recovery subtask. Added in Release 1. A4 APPC tracker router subtask. Added in Release 3. DC Catalog-management subtask. Added in Release 2. EXA External router subtask. Added in Release 2.1. RODM RODM subtask. Added in Release 3. SUB Submit subtask. Added in Release 1. TA TCP/IP router subtask. Added in Release 3.
Refer to Planning and Scheduling the Workload for detailed information about the changes to the MVS commands.
216 Tivoli OPC Installation Guide OPC/ESA Version 1 Summary
TSO Commands New TSO commands have been added, and new parameters have been added to the existing TSO commands: OPSTAT The TOKEN parameter has been added, and the STATUS parameter now accepts values Q and T. From Release 2.1, OPSTAT can be used for any workstation type, except nonreporting. In addition, authorization checking for OPSTAT can be performed at the tracker using the RL.WSNAME subresource from Release 2.1. SRSTAT In Release 3, the QUANTITY and DEVIATION parameters have been added. Also, the AVAIL parameter has two new values, RESET and KEEP, and the default is changed from NO to KEEP. These TSO commands are new: OPINFO Lets you feed back information to a current plan operation. Added in Release 2. BACKUP Lets you request a current plan or JCL repository backup. Added in Release 2. WSSTAT Lets you set the status of a current-plan workstation. Added in Release 2.1.
Refer to Planning and Scheduling the Workload for detailed information about the changes to the TSO commands.
Changes to Callable Services These callable services have been renamed in OPC/ESA: CSYYCOM The OPC/A program interface (PIF) module, CSYYCOM, has been renamed EQQYCOM. The SMP/E JCLIN shipped with OPC/ESA defines CSYYCOM as an alias of EQQYCOM. Therefore, your PIF jobs can continue to call CSYYCOM, but you must first relink your programs. Alternatively, you can change your programs to call EQQYCOM and then recompile and link-edit them. CSYYLTOP The batch loader program, CSYYLTOP, has been renamed in OPC/ESA to EQQYLTOP. If you use the batch loader, change your jobs to call EQQYLTOP. CSYCASEM The automatic-recovery case-code load module, CSYCASEM, has been changed in OPC/ESA to EQQCASEM. If you use this module, rename it EQQCASEM. DRKGJCCT The JCC general-message table, DRKGJCCT, has been changed in OPC/ESA to EQQGJCCT. If you use the JCC, rename the table EQQGJCCT. DRKEVPGM The event-generating batch program, DRKEVPGM, has been renamed in OPC/ESA to EQQEVPGM. However, support has been added to OPC/ESA allowing you to continue using DRKEVPGM JCL unchanged. You should change the program name and ddnames in the JCL as a post-migration task.
Appendix F. History of Changes Since OPC/ESA Version 1 Release 1 217 OPC/ESA Version 1 Summary
DRKUSINS The subroutine DRKUSINS has been renamed EQQUSINS. If you use this subroutine, change the call to the subroutine accordingly, and recompile and link-edit your programs. OPC/ESA defines DRKUSINS as an alias of EQQUSINS. Therefore you can continue to call DRKUSINS. This will save you from coordinating JCL changes for the migration. You must relink the program that calls DRKUSINS and ensure you top-concatenate the OPC/ESA library. The parameters remain unchanged. DRKUSINT The subroutine DRKUSINT has been renamed EQQUSINT. If you use this subroutine, change the call to the subroutine accordingly, and recompile and link-edit your programs. OPC/ESA defines DRKUSINT as an alias of EQQUSINT. Therefore you can continue to call DRKUSINT. This will save you from coordinating JCL changes for the migration. You must relink the program that calls DRKUSINT and ensure you top-concatenate the OPC/ESA library. The parameters remain unchanged; however, the TYPE parameter may now pass the additional values Q and T.
The following callable routines have been added: EQQUSINB Request a backup of the CP or JS files. Added in Release 2. EQQUSINO Request to feed back data to a current plan operation. Added in Release 2 by PN36780. EQQUSINW Request to vary the workstation status of a user-defined workstation. Added in Release 2.1. EQQUSIN Multipurpose user interface that performs the same functions provided by EQQUSINx, plus additional functions. Added in Release 3.
Refer to Customization and Tuning for detailed information about the callable services.
Changes to Programming Interfaces Release 2 added support for communication with APPC transaction programs through an LU 6.2 application programming interface (API). Through the OPC/ESA API, transaction programs can request information about current-plan operations and workstations.
Support added in Release 3 lets you make these requests: GET Extract information about the current plan PUT Update or add current-plan operations DEL Delete operations in the current plan CREATE Report events to OPC/ESA.
Release 3.1 added support for handling dates in the 21st century through the programming interfaces. The INIT and INTFOPTS initialization statements were introduced to let you define options for processing PIF requests.
218 Tivoli OPC Installation Guide OPC/ESA Version 1 Summary
Changes to Installation Exits
Exit Name Changes OPC/A exits have been renamed in OPC/ESA:
Table 66. Renamed Exits Old name New name Exit description DRKUX000 EQQUX000 OPC/ESA start/stop DRKSUBUS EQQUX001 Job submit DRKJPLUS EQQUX002 Job library read DRKNMADU EQQUX003 AD feedback DRKUX004 EQQUX004 Event filtering DRKUX005 EQQUX005 JCC SYSOUT archiving DRKUX006 EQQUX006 JCC incident-record create DRKUX007 EQQUX007 Operation status change CSYDPUE1 EQQDPUE1 Daily planning report
In OPC/ESA, all installation exits are separate load modules.
New and Changed Installation Exits Table 67 summarizes the changes to installation exits in OPC/ESA.
Table 67. Changes to Installation Exits Exit name Short description of change EQQUX002 MCAUSERF has been added to the parameter list. From Release 3 OCCPTR, OPRPTR, and WSPTR are added to the parameter list. EQQUX004 New parameters added to let you discard catalog-management information. EQQUX007 USERDATA field added to the parameter list in Release 2. The parameter list is extended in Release 3 to pass information about the reason for the restart to the exit. EQQUX008 Pre-catalog-management exit added in Release 2. Gets control before the tracker initiates catalog-management actions. Allows you to discard the action. Opportunity to interface to tape-management systems added in Release 2.1. EQQUX009 Operation-initiation exit added in Release 2.1. Handles the submission of operations on workstations that specify a user-defined destination. EQQUX010 Job-log-retrieval exit added in Release 3. Delayed retrieval of job-log information that does not reside on the JES spool. Allows you to interface to archivers and report-management systems. user-defined JCL-embed exit added in Release 1. Lets you include JCL in the current job stream at either job setup or job submit. Invoked by the FETCH JCL directive. user-defined JCL-variable-substitution exit added in Release 1. Lets you supply the value of an OPC/ESA JCL variable at either job setup or job submit.
Appendix F. History of Changes Since OPC/ESA Version 1 Release 1 219 OPC/ESA Version 1 Summary
Changes to Macros These macro names have been changed: DRKEXIT The macro to generate event-tracking code has been renamed EQQEXIT. DRKJCCT The JCC message-table-assembler macro has been renamed EQQJCCT. CSYCASEC The case-code assembler macro has been renamed EQQCASEC.
These macros are new in OPC/ESA: EQQLSENT Creates the dataset selection table for the dataset triggering function. Added in Release 2.1. EQQSREVT Used in IEFU83, enables the dataset triggering function. Added in Release 2.1 and removed in Release 3.
Changes to Messages Messages have been changed, deleted, and added since OPC/ESA first became available. Refer to Messages and Codes for information about the complete message text and descriptions that have been added, changed, or deleted.
Miscellaneous Changes
Changes to ISPF Table Names The prefix of ISPF table names has changed from CSY to EQQ. You should install the new tables that are supplied with OPC/ESA Release 3. Do not rename OPC/A tables and try to use them with OPC/ESA Release 3. If you created your own ready-list layouts, you should recreate them in OPC/ESA Release 3. OPC/ESA Release 2 ready and error-list layouts can be used unchanged in OPC/ESA Release 3.
Replacing OPC/A Batch-Job JCL If you currently run your OPC/A or OPC/ESA batch jobs by scheduling them as applications in the current plan, ensure you replace, or update, the JCL for these jobs. Replace the job skeletons using EQQJOBS, create the new JCL using the Release 3 dialogs, and copy it into your EQQJBLIB library.
Changes to Subsystem Data Sets These datasets referenced by the subsystem and the batch processing have changed in OPC/ESA: EQQADDS JCL variable tables are stored as type 02 records, and the cluster is now SPANNED. Changed in Release 1. EQQCKPT The DCB of the checkpoint dataset has been changed in Release 3. The dataset must be defined with: DSORG=PS,LRECL=82ðð,BLKSIZE=82ðð,RECFM=U The space recommendation to accommodate 1000 destinations is 15 tracks. Changed in Release 3.
220 Tivoli OPC Installation Guide OPC/ESA Version 1 Summary
EQQCXDS A VSAM KSDS extension to the current plan, backed by a data space and refreshed to DASD during the current plan backup process. The daily planning process references the data as input. Output resource objects from daily planning are written to the EQQNCXDS, which is copied to EQQCXDS when a new current plan is taken over by the controller. Added in Release 3. EQQDLxx Optional dual job-tracking logs. Activated by the DUAL keyword of JTOPTS. Added in Release 2. EQQJSxDS When job logs are retrieved by OPC/ESA the information collected from the MSGCLASS SYSOUT of jobs and started tasks is stored as type 14 records in the JCL repository. Changed in Release 2.1. EQQJTARC The accumulated job-tracking information. Contains all job-tracking records created since a new current plan was last created. The dataset is referenced by the controller and daily planning batch processing. Added in Release 2. EQQJTxx OPC/ESA supports up to 99 job tracking logs, used in sequence and switched at every current backup. The number of logs in use is determined by the JTLOGS keyword of JTOPTS. Use at least 3; the default JTLOGS value is 5. Note that EQQJTnn ddnames are no longer required in the daily planning batch JCL. EQQLDDS From Release 3, the cluster is SPANNED. EQQLTBKP A VSAM KSDS containing a backup of the long-term plan as at the most recent long-term planning or daily planning batch process. Added in Release 3. EQQLTDS From Release 3, the cluster is SPANNED. EQQNCPDS VSAM LSR buffering technique is now used by the daily planning batch processing. Changed in Release 2. EQQNCXDS A VSAM KSDS containing resource objects from daily planning. The EQQNCXDS is copied to EQQCXDS when a new current plan is taken over by the controller. EQQNCXDS is used for recovery of the current plan resource objects. EQQRDDS A VSAM KSDS containing the OPC/ESA special resource data base objects. Referenced by the controller and the daily-plan batch processing. Added in Release 3. EQQSIDS A VSAM KSDS containing relatively static, unplanned data objects requiring high-speed access. The file contains: ETT criteria Configuration information. EQQTBxDS Deleted in Release 3. EQQYPARM A sequential or a member in a partitioned dataset containing the INIT initialization statement. Defined in the JCL stream of a PIF application. Added in Release 3.1.
The Tivoli OPC controller address space maintains special-resource plan objects and calendars in separate data spaces.
EQQCXDS is used to load a data space when the NMM subtask starts. When EQQCXDS is empty, the data space is allocated by default with ten 4K pages. The
Appendix F. History of Changes Since OPC/ESA Version 1 Release 1 221 OPC/ESA Version 1 Summary
NMM will recreate the data space if and when a larger area is required. The data space is refreshed to DASD at every current plan backup.
The calendars, now referenced by many dialog functions, batch jobs, and OPC/ESA subtasks, are maintained in a separate data space.
OPC/ESA Release 1.0 Summary OPC/ESA has been restructured and improved when compared to its predecessor product, OPC/A. OPC/ESA is a single program product with a base (the tracker) and a feature (the controller). The tracker performs functions similar to those provided by EMS and NEC; the controller performs functions similar to those provided by the PCS. The prefixes DRK CSY and CSZ have been replaced in OPC/ESA with EQQ.
The major new functions in OPC/ESA are: Control of start-task operations Automatic JCL tailoring Sysplex exploitation Automatic workload restart and reroute Hot standby Job description dialog Enhanced NetView communication.
Release 1 became generally available on 25 April 1991. A description of these new functions and other enhancements follows.
Control of Started Tasks OPC/ESA provides facilities for scheduling, starting, tracking, and recovering started tasks. These facilities extend your ability to automate started-task operations and to integrate them with OPC/ESA's control of the production workload.
Automatic JCL Handling OPC/ESA provides automatic JCL tailoring facilities, which enables JCL to be automatically edited. Supplied JCL variables enable date processing to be handled with no intervention. JCL can be dynamically included or excluded based on variable run conditions.
Sysplex Exploitation OPC/ESA supports local system communication using cross-system coupling facility (XCF) communication links. The controller can transport work to trackers using this connection method. Connected trackers use the same facility to transport event information back to the controller.
Using XCF monitoring services, OPC/ESA can track the operational status of the connected subsystems, and respond to system or connection failures.
222 Tivoli OPC Installation Guide OPC/ESA Version 1 Summary
Production Workload Restart OPC/ESA has the facility to automatically restart and reroute operation that have been, or would have been, started on a system that has failed. If a connected tracker is stopped, loses communication links, or terminates abnormally, the controller will stop submitting work to that system. Instead, the work can be redirected to an alternate system. This enables the production workload processing to continue smoothly, even during system outages.
Hot Standby Using the hot standby function, OPC/ESA enables you to maintain control of the production workload processing in the event of a failure on the OPC/ESA controlling system. Any controlled system connected to the controlling system using XCF can start a controller in standby mode. The standby system can automatically take over and continue to perform the controlling functions if an OPC/ESA controller failure or system failure occurs on the controlling system.
Job Description Dialog The new job description dialog enables users to define single-job or WTO applications quickly and easily. All the information required for job applications can be entered on a single panel. A JCL-setup and manual step can also be specified for each job or WTO, and the dialog automatically defines the operations and internal dependencies for you.
Expanded NetView Communication Integration with NetView has been enhanced in OPC/ESA. NetView is the IBM platform for automated operations and network management.
Write-to-Operator Operations OPC/ESA lets you schedule communication with NetView as an operation. A message to be sent to NetView can be defined and is automatically issued as a write-to-operator (WTO) message when the operation is started.
The concepts of run cycles, dependencies, and resources apply to WTO operations in the same way that they apply to jobs, started tasks, or other OPC/ESA operations.
NetView Alerts OPC/ESA can send generic alerts to NetView in response to problems detected in the production workload. OPC/ESA now supports the following alert actions: Write a message to the OPC/ESA message log. Issue a WTO message. Send a generic alert to NetView. Any or all of these actions can be used in an alert situation.
Additional Enhancements The following enhancements were also made to OPC/ESA in Release 1: Controlled shutdown Global dependency display Time-dependent operations in an interval Improved handling of submission failures and late time-dependent processing.
Appendix F. History of Changes Since OPC/ESA Version 1 Release 1 223 OPC/ESA Version 1 Summary
Controlled Shutdown With OPC/ESA, you can achieve a controlled shutdown of a destination. Before work is started by the controller, a check is performed to ensure that the operation can be completed within the current workstation open interval. If the planned duration of the operation is greater than the time the workstation will remain open, an installation policy determines whether OPC/ESA starts the operation.
Global Display of Dependencies In OPC/ESA, support for the display of dependencies between operations is extended to include all dependencies rather than only direct dependencies. This means that dependencies of dependent operations can now be displayed on a single panel. You can specify whether you see: All predecessor dependencies All successor dependencies Only uncompleted predecessor dependencies Only nonwaiting successor dependencies. A level indicator field provides information on the depth of dependent operations shown, up to 999 levels can be displayed. You can also display global dependencies graphically.
Time-Dependent Operations in an Interval With OPC/ESA, you can specify the start time of time-dependent operations as an interval instead of a precise time. This provides an input-arrival buffer for time-dependent operations.
Improved Handling of Submission Failures Sometimes OPC/ESA cannot start an operation, for example, because the JCL cannot be found, or because the operation is late and the suppress-if-late option is set. To handle these situations, you can specify that the operations be: Set to ended-in-error status Set to completed status Kept on the ready list.
OPC/ESA Release 2.0 Summary The major new functions in OPC/ESA Release 2 are: An LU 6.2 application program interface The Workload Monitor/2 Catalog cleanup Automatic successor dependency resolution Application groups Automatic dependency loop analysis.
Release 2 became generally available on 25 September 1992. A description of the new functions and other enhancements follows.
224 Tivoli OPC Installation Guide OPC/ESA Version 1 Summary
Application Program Interface Beginning with MVS SP Version 4 Release 2, the MVS base control program supports advanced program-to-program communication (APPC). APPC allows MVS systems to participate in a cooperative processing environment. APPC is an implementation of Systems Network Architecture (SNA) LU 6.2 protocol that permits interconnected systems to communicate and share the processing of programs.
APPC support is extended to OPC/ESA with an LU 6.2 API based on the Common Programming Interface for Communications (CPI-C). As a result, APPC transaction programs can exploit certain OPC/ESA functions, such as information about current-plan operations and workstations. This information can be distributed to any SAA-compliant platform.
The Workload Monitor/2 The Workload Monitor/2, a new feature of the OPC/ESA product, communicates with and presents data from the controller on a personal workstation, such as an IBM Personal System/2 (PS/2). You can tailor the amount and appearance of the information, making it available for viewing or printing at your desk. The Workload Monitor/2 functions let you: Filter and display data about operations in the current plan. Filter and display workstation data. Display detailed data about individual operations and workstations. Display detailed information about the current plan. Tailor and display graphical views of the workload. Define alerts for operations that you want to monitor. Monitor your service level agreements thresholds with current plan alerts. The data displayed can be refreshed automatically at regular intervals or on request.
The Workload Monitor/2 complies with CUA91, which means that the OPC/ESA Workload Monitor/2 has the same attributes as other SAA compliant products.
Catalog Cleanup You can use the catalog-management function to catalog, delete, or uncatalog datasets when an operation ends in error, or when you need to rerun an operation. The function can be initiated automatically, or manually by a dialog user. OPC/ESA will reset the catalog to the status that it had before the job started to execute for all DD allocated datasets, including GDG datasets.
Catalog management can, in conjunction with the automatic recovery functions, perform actions at a job-step level. OPC/ESA provides you with enterprise-wide dataset-cleanup capability by also supporting catalog management on remotely connected systems. JCL changes are not required to use the catalog-management function.
Automatic Successor Dependency Resolution Automatic dependency resolution is an optional facility for resolving dependencies when occurrences are added to the current plan. This function significantly reduces the amount of time involved for adding work to the plan and reduces the risk of manual errors.
Appendix F. History of Changes Since OPC/ESA Version 1 Release 1 225 OPC/ESA Version 1 Summary
Application Groups An application group lets you group related applications as a unit. The group shares run cycle and calendar information. Using application groups means you can: Perform current plan actions at a group level, such as add, delete, and complete. Logically group more than 99 operations. Maintain a single source for run cycle and calendar information. Maintaining the application data base is simplified and less prone to user error.
Dependency Loop Analysis To help you identify the source of a dependency loop, the daily planning programs analyze dependency loops and reports on those operations directly involved in the loop. Dependencies suspected of causing the problem are identified. This function eliminates lost time analyzing operation networks when daily planning detects a dependency loop.
Additional Enhancements The following enhancements were also made to OPC/ESA in Release 2: LTP extend and trial improvements On-request backup of the CP or JS Auditing reporting NOERROR constraints removed Operability enhancements Operation feedback JT logging enhancements.
LTP Extend and Trial Improvements An extension of the long-term plan can be specified as a number of days instead of as a specific date. You can produce a trial long-term plan for any time span to forecast workloads without extending the long-term plan.
On-Request Backup of CP and JS The BACKUP command can be used to initiate a backup of the current plan or JCL repository. This allows you to schedule current plan backups to establish coordinated recovery points for disaster recovery purposes and to schedule JCL repository backups when the workload is low.
Audit Reporting An audit package is provided to analyze and report on job tracking information. A dialog interface enables accurate and timely problem determination assistance. The package can be used to provide historical information about the OPC/ESA processing, either in batch or from the OPC/ESA dialog.
226 Tivoli OPC Installation Guide OPC/ESA Version 1 Summary
NOERROR Constraints Removed A new initialization statement, NOERROR, removes the restriction of the number of no-error cases that can be defined. You can now group together and specify any number of no-error cases with one or more NOERROR initialization statements.
Operability Enhancements New commands have been added to improve usability and productivity. These commands are valid for operations in the current plan: Manually hold or release an operation. If you need to delay an operation from starting because of a situation beyond OPC/ESA's control, you can do so, and then release the operation when required. Request immediate execution of an operation. This command causes OPC/ESA to start an operation immediately, provided predecessor operations are complete, even if: – Job submission is not active. – Job options for the operation do not specify automatic submit. – Time dependency for the operation has not yet been satisfied. – Required resources are not available. Suppress an operation. That is, set the status to complete for an operation that is ready to be started. You can do this to prevent an operation from running rather than deleting the operation from the occurrence. Operation dependencies remain intact.
In addition, the ended-in-error list display can now be tailored in the same way that ready lists can be tailored.
Operation Feedback Use the OPINFO command to feed back information to a current plan operation. You can, for example, use this function to feed back the number of a problem record created by Information/Management to an operation that has ended in error.
JT Logging Enhancements The logging of job-tracking records has been extended to provide: Dual job-tracking logs Automatic recovery from DASD read or write errors Device independent logs Up to 99 logs, which provide performance improvements and increase recovery options of current plan information.
OPC/ESA Release 2.1 Summary The major new functions added to OPC/ESA in Modification Level 1 of Release 2 were: Catalog management extensions Dataset triggering support Open systems integration.
Appendix F. History of Changes Since OPC/ESA Version 1 Release 1 227 OPC/ESA Version 1 Summary
A number of minor enhancements were also implemented. The EQQSSCMn module is now loaded above the 16M line, reducing the private storage usage of the OPC/ESA address space by approximately 23K.
Release 2 Modification Level 1 became generally available on 24 September 1993.
Catalog-Management Extensions Step-level restart is now provided by the-catalog management function. This includes GDG reset and resolution at step level. OPC/ESA builds the JCL for restart from the job log captured at the last execution of the job or started task. Validation of the tailored JCL ensures that errors that could result in a failure at restart are identified.
You do not need to make changes to your current JCL to use these functions.
Data Set Triggering You can trigger subsequent processing to be started, or you can schedule unplannable activities when a dataset has been closed after read or update processing. You can use this function to coordinate the transfer of data to MVS from other operating environments.
Open Systems Integration You can use the OPC/ESA controller to provide a single, consistent control point for the submission and tracking of the workload on any operating environment. The facilities provided enable you to integrate the planning, scheduling, and control of units of work such as online transactions, file transfers, or processing on any operating environment that can establish communication with an MVS system.
Sample programs demonstrating how you can exploit the open interfaces provided by OPC/ESA include: TCP/IP-connected AIX and OS/2 trackers A tracker for VM using NJE and RSCS as the communication vehicles.
OPC/ESA Release 3.0 Summary
Tracker Agents The OPC/ESA product now includes Tracker Agent features to plan, control, and monitor the workload on non-MVS operating environments from a single point of control—the OPC/ESA controller.
Release 3 includes these new features: Tracker Agent for OS/400 to control an AS/400 workload Tracker Agent for AIX to control an AIX/6000 UNIX workload Tracker Agent for HP-UX to control an HP-UX UNIX workload Tracker Agent for Sun Solaris to control a Sun Solaris UNIX workload Tracker Agent for SunOS to control a SunOS UNIX workload.
Tracker Agents provide essentially the same functions as the MVS tracker, including: automatic workload reroute and recovery, input tailoring, and job log
228 Tivoli OPC Installation Guide OPC/ESA Version 1 Summary
browse, along with the more traditional submission and tracking functions. Dataset cleanup and triggering functions are not available for Tracker Agents.
The Tracker Agent for OS/400 uses APPC services to communicate with the OPC/ESA controller. If you have several networked AS/400 systems, you can designate one system as the focal point Tracker. The focal point system routes the work to the target destination based on the submitting workstation name. When you use Tracker Agent for OS/400 features you must also install the Tracker Agent for OS/400 enabler feature on the controlling system.
The UNIX Tracker Agents use TCP/IP services to communicate with the OPC/ESA controller. When you use a UNIX feature you must also install the AIX/UNIX enabler feature (previously called the OPC Tracker Agent for AIX enabler feature) on the controlling MVS system.
Special Resource Enhancements Everything you ever wanted in special resources, and more. OPC/ESA Release 3 includes these extensions to special resources: Numeric resources: you can specify that a special resource actually comprises up to 999 999 individual units. At operation level, you can define how many units of the special resource are allocated by the operation. Special resources can be connected to one or more workstations. Only operations on connected workstations, and their alternate workstations, can allocate the resource. Interval support is provided so that you can define availability, quantity, or different connected workstations for different times of the day, days of the week, or specific dates. Real resource tracking is available by connecting a special resource to a Resource Object Data Manager (RODM) object. A resource monitor in the Modify Current Plan dialog lets you manage, query, and update special resources in the current plan while maintaining the integrity of the resource definition in the special resource database. Ability to specify special resources, or parallel servers, to be used only by planning, only in control, in both, or in neither. Full consideration of special resource allocations by daily planning. You can also choose for which resources you would like planned and actual utilization histograms created. Contention alerts created when an operation has been waiting to allocate a special resource for an installation-defined time without success. Ability to display the in-use list and the waiting queue for a special resource. Dialog, TSO command, and callable routine support to adjust the currently available number of a special resource using either absolute or relative values. Control over when special resource definitions are dynamically created.
After migration to Release 3, OPC/ESA will plan and control the workload exactly as before for special resource usage. You can update your resource definitions later to take advantage of the enhancements.
Special resources have this structure:
Appendix F. History of Changes Since OPC/ESA Version 1 Release 1 229 OPC/ESA Version 1 Summary
Main body Describes the special resource. Intervals Dates and times that specify the availability and quantity of the special resource. A special resource has at least 1 interval, the default interval, which is in effect all day, every day. Workstations A list of workstations that operations must run on to allocate the special resource. You can specify a workstation list for each interval. Intervals with a blank list use the workstation list in the default interval.
When the dataset migration program runs to convert the table space (EQQTBnDS) to special resource descriptions (EQQRDDS), each special resource has these values after conversion: Special resource As special resource name. Text Blank. Specres group ID Blank. Hiperbatch As DLF field of the special resource. Used for C (control). OPC/ESA does not use the special resource for planning. On error As Keep on error field of the special resource. Available Blank. The available indicator is set in the default interval. You use this field to override the value in all intervals. It is updated by special resource events and is also used by OPC/ESA to monitor availability through RODM. Deviation Blank. You use this field to make temporary adjustments to the quantity of the special resource. OPC/ESA adds together quantity and deviation to determine the total amount that operations can allocate concurrently. Last updated by The existing date, time, and user ID at conversion time. Intervals Only the default interval is created. It has these values: Quantity 1. Operations that specify 1 or blank (the entire quantity) can allocate the special resource. Available As the special resource availability at conversion time. Workstations The list of connected workstations for the default interval contains *, which means all workstations.
When the dataset migration program runs to convert application descriptions (EQQADDS) or the current plan (EQQNCPDS), operations have these details for special resources: Special resource name As in the previous release. Qty Blank. The operation requires the entire quantity of the special resource. Keep On Error Blank. The operation uses the value defined for the resource.
230 Tivoli OPC Installation Guide OPC/ESA Version 1 Summary
Shr Ex As allocation type, S or X, in the operation details at conversion time.
The daily plan process creates special resource plan objects in the new-current-plan extension (EQQNCXDS) dataset. During turnover processing the EQQNCXDS is copied to the EQQCXDS and the data is loaded into a data space. EQQCXDS is refreshed to DASD at every current plan backup.
The migration process does not create special resource plan objects. The default value of the DYNAMICADD keyword of the RESOPTS statement allows dynamic creation of resource objects resulting from current plan operation allocations or SRSTAT/EQQUSINS requests that do not specify CREATE(NO). If referenced special resources do not exist in the database, the controller will add them to the current plan dynamically. If you use a lot of dynamically added resources, performance will be suffering. To reduce the performance overhead, you should submit a daily plan extend or replan as soon as possible after migrating to Release 3.
Monitoring Special Resources through RODM RODM (Resource Object Data Manager) provides a central location for storing, retrieving, and managing the operational resource information needed for network and system management. It stores configuration data, status information, execution information, and other details about resources or classes of resources in an object-oriented structure.
OPC/ESA support for RODM lets you exploit established resource monitoring. Through a subscription to RODM, fields in OPC/ESA special resources are associated with fields in RODM classes or RODM objects. RODM notifies OPC/ESA if the value of a field changes, and OPC/ESA updates the associated field of the special resource in the current plan. Through RODM you can monitor the quantity, availability, and deviation of special resources.
An OPC/ESA address space must be started on the same MVS image as the target RODM subsystem. Communication with RODM is through the subsystem interface. You must start the OPC/ESA RODM subtask at the controller. If the target RODM is not on the controlling system, you must also start the RODM subtask for the tracker on that system.
OPC/ESA can communicate with several RODM subsystems.
Programming Interface Enhancements The application programming interface (API) to OPC/ESA is enhanced. In addition to requesting current plan information through the API, you can also update the current plan and report events. You can issue these requests: GET Extract information about the current plan. PUT Update or add current-plan operations. DEL Delete operations in the current plan. CREATE Report events to OPC/ESA.
The buffer returned by OPC/ESA now includes reason codes and return codes, and an offset indicator that OPC/ESA updates if a verification error occurs. For GET, PUT, and DEL requests, OPC/ESA also returns the user access authority to the OPC/ESA fixed resource that protects the requested object.
Appendix F. History of Changes Since OPC/ESA Version 1 Release 1 231 OPC/ESA Version 1 Summary
From Release 3, you provide TP name EQQAPI when sending requests from your own program to OPC/ESA. This value is the default if you do not provide a TP name.
A general-purpose callable routine, EQQUSIN, is provided. This routine encompasses all functions provided by the EQQUSINx routines plus additional function. EQQUSIN can also be invoked in an APPC TP. The existing subroutines will continue to be supported.
The INTFOPTS and INIT initialization statements have been introduced. With the INTFOPTS statement, you can specify the run-time options for processing PIF requests. The INIT statement enables you to override the INTFOPTS settings from a PIF program.
Run Cycle Improvements Run-cycle definitions for your applications have just become a lot easier. Additionally, you no longer have to maintain noncyclic period definitions to describe common calendar intervals like weeks and months.
You can still define run cycles using the combination or user-defined periods and offsets, but you will quickly modify them to take advantage of OPC/ESA's new rule-based run cycles. Rule-based run cycles are easier to implement and easier to maintain. You can specify the scheduling policy for the application, such as: ONLY the SECOND TUESDAY of every MONTH EVERY FRIDAY in the user-defined period SEMESTER1 when the words in capitals are selected from lists of ordinal numbers, names of days, and common calendar intervals or period names, respectively. You can define exclusion rules using the same method.
From the run cycle definition dialog you can use the GENDAYS command to generate a calendar display indicating the dates on which an occurrence will be generated by the rule-based run cycle. GENDAYS takes the free-day-rule specification and the calendar work-day-end time into consideration when calculating run dates for the run cycle.
The program interface and the batch loader functions include support for rule-based run cycles.
Noncyclic Period Closed Interval Support From Release 3, you can specify the end date of intervals in a noncyclic period. Combined with the rule-base run-cycle definitions, this option gives you the ability to schedule any operation exactly when you need to.
Refer to Planning and Scheduling the Workload for more details.
Installability and Maintainability Improvements You can migrate to or fallback from Release 3 without IPLing. Installability for new users of OPC/ESA is easier too, because of changes to security handling. And maintainability is improved by letting you replace the SSCM module when the address space is started. This ensures that events created while the subsystem is inactive will still be in the format required. Refer to Customization and Tuning and the migration section in this book for more details.
232 Tivoli OPC Installation Guide OPC/ESA Version 1 Summary
Reliability and Availability Improvements The real status of DASD-connected trackers is now known by OPC/ESA and as a result workload restart and reroute for operations on DASD-connected workstations can be automatically invoked. If the tracker is not started, or the event writer subtask is not active, the workstation will be reported in OFFLINE status.
Security Changes If your installation has RACF Version 2 Release 1 installed, you can use the IBM reserved resource class IBMOPC. Additionally, you can now define the userid for started tasks in the STARTED resource class.
You can redefine your existing OPCCLASS resource to specify 60-byte entity names.
To migrate from your current resource class to the IBMOPC resource class you can use the RACF SEARCH command to generate the REDEFINE statements. If you enter: SEARCH CLASS(current_class) CLIST('REDEFINE IBMOPC ' ' FROM(xxx) FCLASS(current_class)') RACF will build a CLIST of RDEFINE commands. You can then edit the CLIST and on each line replace the xxx with the profile name that was generated on the same line. Then run the clist. The editing step can even be done with a REXX EXEC that finds the profile name (3rd word on the line) and replaces the xxx (5th word on the line) automatically. The exec can even execute the commands after it rebuilds them.
The resource entity length supported for OPC/ESA is now 60 bytes, so you can specify a complete special resource name in a RACF resource rule.
Limitations Removed These previous limitations have been removed: 100 external predecessors for an operation in an application description 12 positive and 12 negative run cycle offsets in a run cycle 100 occurrence predecessors in the long-term plan 400 occurrence successors in the long-term plan 50 lines of user SYSOUT scanned by the JCC.
The amount of user SYSOUT scanned by the JCC is defined by a new keyword on the JCCOPTS initialization statement. The other items have no practical limit. If the logical record length of the cluster is great enough, any number can be defined.
Using the default EQQADDS record size of 128K, there is sufficient space to store 99 operations each with 5 special resources, 10 run cycles (24 offsets each), 1000 internal dependencies, and 843 external dependencies.
Using the default EQQLTDS record size of 128K, and reserving space for 100 changed operations in the occurrence, results in a maximum 3574 dependencies per occurrence.
Appendix F. History of Changes Since OPC/ESA Version 1 Release 1 233 OPC/ESA Version 1 Summary
Update from the OPC/ESA Workload Monitor/2 Update of planned operations in the current plan is now supported from the OPC/ESA Workload Monitor/2. Refer to Workload Monitor/2 User's Guide for more details.
Step-Level Restart Extensions Any MVS job or started task can be step restarted from the OPC/ESA dialog whether catalog updates were made or not.
You can specify not only the step to restart from, but also the last step to be executed in the rerun, as well as being able to exclude intervening steps from the rerun.
The R row command in the error handling panel has been replaced by the SR and JR commands, representing step restart and job restart respectively. When you select the step restart command, OPC/ESA automatically checks restartability for each step and indicates on panel EQQMERSL whether restart is possible from each step.
A reason for restart confirmation panel has been included for both step and job restart. This lets you define free-format text for logging purposes.
Browse any Job Log and Interface to SYSOUT Archivers Imagine being able to see the job log for any operation in the enterprise from a single point. The browse job log function lets you see the job log for your MVS, AS/400, or AIX/6000 jobs from the OPC/ESA dialog.
You can choose when and how job logs are retrieved by OPC/ESA. You can take them all immediately, or request retrieval only when a dialog user requests a function that requires the job log. Additionally, if you use an archiver product to store your job logs the job-log-retrieval exit, EQQUX010, can be used to interface with the archiver. An interface to RMDS is provided with OPC/ESA.
Smarter JCL Tailoring You can perform arithmetic operations on variable values, such as the current date plus three calendar days. Additionally, you can now specify date values using any format or any delimiter that you need and more OPC/ESA-supplied variables are provided.
Variable values may now contain embedded blanks. Variable substitution error messages are inserted into the JCL to aid problem determination and an online cross-reference between variable tables and variable names is provided. You can also specify in the variable definition that any value supplied for the variable be automatically converted to uppercase.
The program interface (PIF) has been enhanced to provide variable substitution simulation to let you interface with JCL syntax checkers with a completed JCL image.
Refer to Planning and Scheduling the Workload for more information.
234 Tivoli OPC Installation Guide OPC/ESA Version 1 Summary
Changes to the Library The OPC/ESA library has been restructured and extended. Installation and Customization has been split into two books: – The Installation Guide covers installation and migration topics. – Customization and Tuning covers all customization topics (including the initialization statement), tuning, data backup and recovery, and disaster recovery. The User's Guide has been split into two books: – Planning and Scheduling the Workload for the OPC/ESA administrator – Controlling and Monitoring the Workload for the operators. PIF and the API are documented in Programming Interfaces. Getting Started with OPC/ESA has been added to the library. This book shows new OPC/ESA users how to perform basic functions such as defining simple applications, creating plans, and making changes to the plans. These books have been added to the library for the new Tracker Agents: – Tracker Agent for OS/400 Installation and Operation – Tracker Agent for AIX Installation and Operation – Tracker Agent for HP-UX Installation and Operation – Tracker Agent for Sun Solaris Installation and Operation – Tracker Agent for SunOS Installation and Operation.
ISPF Dialog Enhancements These updates have been made in the dialog: Lists Lists can be sorted in chronological order. Graphical displays Calendars and run cycles can be previewed graphically. Service dialog The current status of job submission, automatic recovery, and event-triggered tracking is displayed. Options dialog The default calendar specification has been moved from the long-term plan dialog to the date and time options panel. The default calendar is now used by the long-term plan dialog, JCL variable substitution at setup, and the GENDAYS function of rule-based run cycles. Selecting operations MCP and QCP selecting operation criteria panels include the manual hold indicator to let you select operations that have been manually held. Ready list Owner ID has been included as selection criteria. WS information System information display added to show you the mapping between the workstation name, destination, and the system where the operations for this workstation are actually started. The display includes an indication of the functions used by the OPC/ESA tracker or Tracker Agent responsible for the destination. JCL variables Variable name included as selection criteria. OPC/ESA changes Information about the enhancements made to OPC/ESA is included.
Appendix F. History of Changes Since OPC/ESA Version 1 Release 1 235 OPC/ESA Version 1 Summary
Miscellaneous Changes EQQUX002 parameter list has been extended to include three new fields. OCCPTR, OPRPTR, and WSPTR contain occurrence, operation, and workstation information for the operation when the associated occurrence is not part of the current plan. The existing VAROCCP, VAROPRP, and VARWSP are retained and contain valid addresses when the occurrence is included in the current plan. Tracing of RACROUTEs using the TRACE keyword of the AUTHDEF initialization statement is provided for diagnostic purposes. All job-tracking records are logged using GMT. You can connect up to 1000 NCF, XCF, APPC, or TCP-IP destinations directly to the controller. The dataset close triggering function installation has been simplified. Special resource availability events created by dataset triggering are broadcast to all defined subsystems. OPINFOSCOPE keyword added to the JTOPTS initialization statement to enable operation information to be fed back to an operation in C or W status. The LATEOPER ALERT processing now reports on late operations whether or not any operation in the application has changed status, and the performance overhead of this function is significantly reduced. The EQQAPARC CLIST is added, so that you can generate the JCL to create an APAR tape even if the subsystem is not started. The EQQUX007 parameter list now lets you pass information about the reason for a restart to the exit.
OPC/ESA Release 3.1 Summary
Operations History Database The history function lets you store information about completed operations in a DB/2 database and makes them available for rerunning.
Return Code Simulation You can now simulate the return codes from bypassed steps on step-level restart. Refer to Controlling and Monitoring the Workload for more information.
OS/2 Tracker Agent The OS/2 Tracker Agent is a new feature that lets you control work on OS/2 from an OPC/ESA or Job Scheduler controller. There is a corresponding enabler feature for the OPC/ESA controller.
Library Modifications The installation and operation information for the AIX and UNIX platform Tracker Agents was previously in 4 books. All this information has been combined in one book which describes the AIX and UNIX Tracker Agents for OPC/ESA and Job Scheduler.
236 Tivoli OPC Installation Guide OPC/ESA Version 1 Summary
21st Century Support OPC/ESA Release 3.1 supports dates in the 21st century. The new default valid-to date is 31 December 2071.
You can now specify dates in the CCYYMMDD format for your dialogs and reports.
Appendix F. History of Changes Since OPC/ESA Version 1 Release 1 237
238 Tivoli OPC Installation Guide
Part 5. Glossary and Index
Copyright IBM Corp. 1991, 1999 239
240 Tivoli OPC Installation Guide
Glossary
entity that an application can be broken down into is an A operation. Generally, several related operations make up an application. ABARS. See Aggregate Backup and Recovery Support. application description (AD). A database description of an application. active application description. An application description that is complete and ready for use in application group. Type of application description planning or scheduling. which holds run cycle and calendar information for standard applications or job descriptions which have actual duration. At a workstation, the actual time in been defined as a member of the group. hours and minutes it takes to process an operation from start to finish. application ID. The name of an application. (For example, PAYROLL or DAILYJOBS.) adjusted quantity. The current quantity of a special resource, taking the deviation into account. application programming interface (API). A formally-defined programming language interface AD. See application description. between an IBM system control program or a licensed program and the user of a program. Aggregate Backup and Recovery Support (ABARS). A DFHSM facility that manages backup and application transaction program (ATP). A program recovery of user-defined data set groups (aggregates). that uses the Advanced Program-to-Program Aggregate backup copies and related control Communications (APPC) application programming information are written as portable data and control files interface (API) to communicate with a partner program on 3480 or 3420 volumes. at a remote node.
Advanced Program-to-Program Communications application version. See versions. (APPC). An implementation of the Systems Network Architecture (SNA), logical unit (LU) 6.2 protocol that ATP. See application transaction program. allows interconnected systems to communicate and share the processing of programs. authority. The ability to access a protected resource. all-days cyclic period. A cyclic period where all days authority group. A name used to generate a RACF are counted when calculating the interval. resource name for authority checking. alert. Two Workload Monitor/2 objects, Operations List automatic events. Events recognized by or triggered and Workstations List, can be used to monitor a Tivoli by an executing program. Automatic events are usually OPC subsystem and notify you if alert conditions are generated by Tivoli OPC tracking programs but can also met. The alert can be a sound (Beep), or a message in be created by a user-defined program. a window (Message). The Details view of the Plan object must be open to monitor for plan alerts. The List automatic hold/release. Function used to control jobs or Icons views of the Operations List object must be that are submitted outside Tivoli OPC. It allows you to open to monitor for operation alerts. define whether such jobs should be automatically released at the appropriate time if placed in HOLD APAR. Authorized program analysis report. A report status when submitted. of a problem that is suspected to be caused by a defect in a current, unaltered release of a program. automatic job and started-task recovery. A Tivoli OPC function that lets you specify, in advance, API. See application programming interface. alternative recovery strategies for operations that end in error. APPC. See Advanced Program-to-Program Communications. automatic-reporting workstation. A workstation (for example, a processor or printer) that reports events (the application. A measurable and controllable unit of starting and stopping of operations) in real time to Tivoli work that completes a specific user task, such as the OPC. running of payroll or financial statements. The smallest
Copyright IBM Corp. 1991, 1999 241
availability. The degree to which a system (and in computer workstation. (1) A workstation that Tivoli OPC, an application) or resource is ready when performs MVS processing of jobs and started-task needed to process data. operations, and that usually reports status to Tivoli OPC automatically. (2) A processor used as a workstation. It can refer to single processors or multiprocessor B complexes serving a single job queue (for example, JES2 or JES3 systems). batch loader. A Tivoli OPC batch program that you can use to create and update information in the contingency plan. A plan for emergency response, application-description and operator-instruction backup procedures, and post-disaster recovery. databases. Synonymous with disaster recovery plan, emergency plan. buffer. A memory area reserved for performing input/output (I/O) operations. controller. The Tivoli OPC component that runs on the controlling system, and that contains the Tivoli OPC BMP. Batch message processing. tasks that manage the Tivoli OPC plans and databases.
controlling system. The system that the controller C runs on. calendar. The data that defines the operation control on servers. If a workstation is defined with department's work time in terms of work days and free control on servers, OPC/ESA will not start more days. operations at the workstation than there are available servers. capacity. The actual number of parallel servers and workstation resources available during a specified open conversation. In Advanced Program-to-Program interval. Communications (APPC), a connection between two transaction programs over a logical unit-logical unit capacity ceiling. The maximum number of operations (LU-LU) session that allows them to communicate with that a workstation can handle simultaneously. each other while processing a transaction. catalog. A directory of files and libraries, with conversation verb. In Advanced Program-to-Program reference to their locations. A catalog may contain Communications (APPC), one of the verbs a transaction other information such as the types of devices in which program issues to perform transactions with a remote the files are stored, passwords, blocking factors. program. catalog management. Catalog management is a CP. See current plan. recovery function of Tivoli OPC, which handles the deleting or uncataloging of datasets created in a job CPI. See Common Programming Interface. operation that ends in error. CPI-C. Common Programming Interface for CICS. Customer Information Control System. Communications. See also Common Programming Interface. closed workstation. A workstation that is unavailable to process work for a specific time, day, or period. cross-system coupling facility (XCF). MVS components and licensed programs use the XCF Common Programming Interface (CPI). A consistent services to provide additional functions in a SYSPLEX. set of specifications for languages, commands, and calls to enable applications to be developed across all critical path. The route, within a network, with the Systems Application Architecture (SAA) environments. least slack time. complete (C). The status of an operation indicating current plan (CP). A detailed plan of system activity that it has finished processing. that covers a period of at least 1 minute, and not more than 21 days. A current plan typically covers 1 or 2 completion code. A Tivoli OPC system code that days. indicates how the processing of an operation ended at a workstation. See error code. cyclic interval. The number of days in a cyclic period. complex of processors. A JES2 Multi-Access Spool cyclic period. A period that represents a constant system or a JES3 system with more than one number of days. There are two types of cyclic periods: processor.
242 Tivoli OPC Installation Guide
Work-days-only cyclic period, where only the work deadline WTO message. You can specify that Tivoli days are counted when calculating the number of OPC issue an operator message (EQQW776I) when a days in the period. started operation has not been marked as completed All-days cyclic period, where all days are counted. before the deadline time. In addition to the standard message, the user-defined text that describes the D operation is issued as part of the WTO. default calendar. (1) A calendar that you have daily planning. The process of creating a current defined for Tivoli OPC to use when you do not specify a plan. calendar in an application description. (2) A calendar that Tivoli OPC uses if you have neither specified a DASD. Direct access storage device. calendar in an application description, nor defined your own default calendar. database. A collection of data that is fundamental to a system. Tivoli OPC uses six databases: calendar, dependency. A relationship between two operations in period, workstation description, JCL variable table, which the first operation must successfully finish before application description, and operator instruction. the second operation can begin.
Data Facility Hierarchical Storage Manager descriptive text. User-written text describing the (DFHSM). A licensed MVS program which provides operation. This text is also issued as part of the automatic and command functions that manage user write-to-operator message if the operation has been storage space and data recovery. started, exceeds its deadline, and has the deadline write-to-operator (WTO) option specified. Data Facility Systems Management Subsystem/MVS (DFSMS/MVS). A group of licensed MVS programs Details notebook. See Details view. which transform system environments from user-managed DASD volumes to Details view. A view of a Workload Monitor/2 object administrator-controlled, system-managed data sets. showing details about the object. The Details view of the Plan object shows information about the current Data Lookaside Facility (DLF). The MVS/ESA plan. The Details view of the Operation object shows component that manages Hiperbatch objects. information about the selected operation. The Details view of the Workstation object shows information about data processing center (DP center). A center or the selected workstation. department, including computer systems and associated personnel, that performs input, processing, storage, deviation. A temporary variation in the quantity of a output, and control functions to accomplish a sequence special resource. of operations on data. DFHSM. See Data Facility Hierarchical Storage | Data Store. The Tivoli OPC component managing the Manager. | job runtime information at the tracked system. It is | dedicated to the storing and possible retrieval of sysout DFSMS/MVS. See Data Facility Storage Management | datasets belonging to OPC-submitted jobs, to optimize Subsystem. | the sysout availability. dialog. The user's online interface with Tivoli OPC. DB2. DATABASE 2. Disaster Recovery Plan (DRP). A plan for emergency DBCS. Double-byte character set. response, backup procedures, and post-disaster recovery. Synonymous with contingency plan, ddname. Data definition name. emergency plan.
deadline. See deadline date and deadline time. DLF. See Data Lookaside Facility.
deadline date. The latest date by which an occurrence DP center. See data processing center. must be complete. DRP. See Disaster Recovery Plan. deadline time. The latest time by which an occurrence must be complete. duration. The length of time an operation is active at a workstation.
Glossary 243
occurrence (the predecessor) must successfully finish E before an operation in the second occurrence (the successor) can begin processing. end user. A person who uses the services of the data processing center. F ended-in-error (E). The Tivoli OPC reporting status for an operation that has ended in error at a workstation. feedback limit. A numeric value in the range 100–999 that defines the limits within which actual data that is error code. A code set by Tivoli OPC to describe how collected in tracking is fed back and used by Tivoli the processing of an operation ended at a computer OPC. workstation. filter criteria. Input values that are used to limit the ETT. See event-triggered tracking. mass update of applications to only those specified. This term is used in the Tivoli OPC ISPF dialogs. estimated duration. The estimated length of time an operation will use a workstation. This is initially based first critical operation. An operation of an occurrence on a value that is provided when the operation is that has the earliest latest-start-time. The first critical defined, but can be adjusted automatically by Tivoli operation of an occurrence determines the critical path. OPC's feedback mechanism to reflect actual durations. first operation. (1) An operation in an occurrence that event. An action that changes an operation's status has no internal predecessor. (2) The start node in a and changes the current plan. network. event manager. The Tivoli OPC function that fixed resources. A set of resource names used to processes all tracking events and determines which of check the authority of users to access the Tivoli OPC these are Tivoli OPC-related. dialogs. event reader. A Tivoli OPC task that reads event form number. A user-defined code that identifies the records from an event dataset. type of paper to be used for an operation on a printer workstation. Tivoli OPC can use the form number to event tracking. A function of Tivoli OPC that follows identify the different print operations belonging to one events in the operations department in real time and job. records status changes in the current plan. free day. Any day that is not a work day. event-triggered tracking (ETT). A component of Tivoli OPC that waits for specific events to occur, and then free-day rule. A rule that determines how Tivoli OPC adds a predefined application to the current plan. ETT will treat free days when the application run day falls on recognizes two types of events: the reader event, which a free day. occurs when a job enters the JES reader, and the resource event, which occurs when the availability status of a special resource is set to “yes”. G event writer. A Tivoli OPC task that writes event general workstation. A workstation where activities records in an event dataset. other than printing and processing are carried out. A general workstation reporting to Tivoli OPC is usually exclusive resource. A resource that can be used by manual, but it can also be automatic. Manual activities only one operation at a time. can include data entry and job setup. expected arrival time. The time when an operation is generic alert. An alert that is broadcast by Tivoli OPC, expected to arrive at a workstation. It can be calculated and collected by NetView, when an operation ends in by daily planning or specified in the long-term plan. error. You can specify this as an option when defining application descriptions. extended status code. Together with the normal status codes, Tivoli OPC maintains extended status global search character. In Tivoli OPC, a percent codes that provide additional information about the sign (%), which represents any single character, or an status of operations. The extended status code is not asterisk (*), which represents any character string of always present. any length. external dependency. A relationship between two global variable table. The JCL variable table that occurrences, in which an operation in the first Tivoli OPC checks for a variable substitution value if no
244 Tivoli OPC Installation Guide
value is found in the specific JCL variable table that is in-progress operation. An operation with a status of associated with the operation. A, R, *, I, E, or S.
Graph view. (1) A view of the Workload Monitor/2 input arrival time (IAT). The user-defined date and Workstation object. Shows the total number of time when an operation or an application is planned to operations with different statuses for a single be ready for processing. workstation. (2) In the Graphical User Interface for Application Description, a view of the operations that intermediate start. The date and time an operation make up an application. It shows the workstation where started after processing was interrupted. each operation is run, and dependencies between the operations. internal date. Internally, Tivoli OPC uses a two-digit year format when handling dates. In order to handle Graphs view. A view of the Workload Monitor/2 dates before and after 31 December 1999 correctly, Workstations List object. Shows the total number of Tivoli OPC uses an origin year of 72 for the internal operations with different statuses for each of the century window. This means that internally the year workstations that are included in the object. 1972 is represented as 00 and 2071 is represented as 99. group definition. The application group to which the application description or job description is a member. internal dependency. A relationship between two operations within an occurrence, in which the first operation (the predecessor) must successfully finish H before the second operation (the successor) can begin. highest return code. A numeric value in the range interrupted (I). A Tivoli OPC reporting status for an 0–4095. If this return code is exceeded during job operation that indicates that the operation has been processing, the job will be reported as ended-in-error. interrupted while processing.
Hiperbatch. The MVS/ESA facility that stores VSAM ISPF. Interactive System Productivity Facility. and QSAM data in Hiperspace for access by multiple jobs. The facility can significantly reduce the execution time of certain batch streams that access VSAM and J QSAM data sets. JCC. See job completion checker. Hot standby. Using the MVS/ESA cross-system coupling facility (XCF), you can include one or more JCL. Job control language. A problem-oriented standby controllers in your configuration. A standby language designed to express statements in a job that system can take over the functions of a controller if the are used to identify the job or describe its requirements controller fails or if the MVS/ESA system that it was to an operating system. active on fails. JCL tailoring. Tivoli OPC provides automatic JCL tailoring facilities, which enable jobs to be automatically I edited using information that is provided at job setup or submit. Icons view. The Workload Monitor/2 objects, Workstations List and Operations List, contain other JCL variable table. A group of related JCL variables. objects. The Icons view shows an icon for each See variable table. contained object. JES. Job entry subsystem. A system facility for IMS. Information Management System. spooling, job queuing, and managing I/O. incident log. An optional function available under the job. (1) A set of data that completely defines a unit of job completion checker. work for a computer. A job usually includes all necessary computer programs, linkages, files, and initiator/terminator. The job scheduler function that instructions to the operating system. (2) In Tivoli OPC, selects jobs and job steps to be executed, allocates an operation performed at a computer workstation. input/output devices for them, places them under task control, and at completion of the job, supplies control job class. Any one of a number of job categories that information for writing job output on a system output can be defined. By classifying jobs and directing unit. initiators to initiate specific classes of jobs, it is possible to control a mixture of jobs that can be run concurrently.
Glossary 245
job-completion checker (JCC). An optional function layout. In the Graphical User Interface for Application of Tivoli OPC that allows extended checking of the Description, a user-created file that determines which results from CPU operations. information about each application is displayed when you view a list of application descriptions. An job description. A single processor (job or application description contains many details about the started-task) operation and its dependencies. application, such as application ID, valid to date, application status, and last user. A layout specifies Job Description dialog. The ISPF dialog used to which details the user wishes to view. create job descriptions. layout ID. A unique name that identifies a specific job ID. The JES job ID of the job associated with the ready or error list layout. operation. limit for feedback. See feedback limit. job name. The name of the job associated with an operation. The job name is assigned in the JOB list, application. In the Graphical User Interface for statement of a job. It identifies the job to the system. Application Description, a list of application definitions from which the user can select one to work with. It job preparation. Job preparation involves modifying consists of application definitions selected according to jobs in preparation for processing. This can be user-specified criteria. performed manually, by a job preparer, or automatically by Tivoli OPC JCL tailoring functions. List view. The Workload Monitor/2 objects Workstations List and Operations List contain other job setup. The preparation of a set of JCL statements objects. The List view shows a list of the contained for a job at a job setup workstation. Job setup can be object and displays data about each contained object. performed manually by an operator, or automatically by Tivoli OPC. local. Synonym for channel-attached. job setup workstation. A general workstation defined local processor. (1) In a complex of processors with the job setup option. A job setup workstation lets under JES3, a processor that executes users' jobs and you modify your job or STC JCL before execution. that can assume global functions if the global processor fails. (2) In Tivoli OPC, a processor in the same job submission. A Tivoli OPC process that presents installation that communicates with the controlling Tivoli jobs to MVS for running on a Tivoli OPC-defined OPC processor through shared DASD or XCF workstation once the scheduling criteria for the communication links. operation is met. logical unit (LU). In Systems Network Architecture job tracking. A Tivoli OPC process that communicates (SNA), a port through which an end user accesses the with operating systems that control computer SNA network in order to communicate with another end workstations. user and through which the end user accesses the functions provided by system services control points JS. The JCL repository dataset. (SSCPs).
logical unit 6.2 (LU 6.2). A type of Systems Network K Architecture (SNA) logical unit (LU) for communication between peer systems. Synonymous with APPC kanji. A character set for the Japanese language. protocol, see Advanced Program-to-Program Communications (APPC). L long-term plan (LTP). A high-level plan of system last operation. (1) An operation in an occurrence that activity that covers a period of at least 1 day, and not has no internal successor. (2) The terminating node in more than 4 years. It serves as the basis for a service a network. level agreement with your users, and as input to daily planning. latest out time. See latest start. LU. See logical unit. latest start. The latest day and time (calculated by Tivoli OPC) that an operation can start and still meet LU-LU session type 6.2. See logical unit 6.2. the deadline specified for the operation and any successor operations. The latest out time for an LTP. See long-term plan. operation is identical to the latest start time.
246 Tivoli OPC Installation Guide
noncyclic period. A period that does not represent a M constant number of days or work days. Examples: quarter, academic semester. manipulation button. One of the two mouse buttons. With default mouse settings, the manipulation button is nonreporting. A reporting attribute of a workstation, mouse button 2, the button on the right. You press and which means that information is not fed back to Tivoli hold this button to move an object, for example, to drag OPC. an object to a printer. Pressing the manipulation button once when the pointer is on an object, opens the object's pop-menu. O manual reporting. A type of workstation reporting in occurrence. An instance of an application in the which events, once they have taken place, are manually long-term plan or current plan. reported to Tivoli OPC. This type of reporting requires An application occurrence is one attempt to process that some action be taken by a workstation operator. that application. Occurrences are distinguished from Manual reporting is usually performed from a list of one another by run date, input arrival time, and ready operations. application ID. For example, an application that runs mass updating. A function of the Application four times a day is said to have four occurrences per Description dialog in which a large update to the day. application database can be requested. occurrence group. Consists of one or more MCU. Multiple Console Support. application occurrences added to the long-term plan or current plan, where such occurrences are defined as Merged Graph view. A view of the Workload belonging to a particular application group specified in Monitor/2 Workstations List object. Shows the total the group definition field of the application description or number of operations with different statuses for all the job description. workstations that are included in the object. The − − information is shown in a single graph. offset. Values, in the ranges 1 to 999 and 1 to 999, that indicate which days of a calendar period an modify current plan (MCP). A Tivoli OPC dialog application runs on. This is sometimes called function used to dynamically change the contents of the displacement. current plan to respond to changes in the operation environment. Examples of special events that would OI. See operator instruction. cause alteration of the current plan are: a rerun, a OPC/ESA. Operations Planning and Control/ESA deadline change, or the arrival of an unplanned application. OPC host. The processor where Tivoli OPC updates the current plan database. most critical application occurrences. Those unfinished applications whose latest start time is less OPC local processor. A processor that connects to than or equal to the current time. the Tivoli OPC host or remote processor through shared event datasets or XCF communication links. N OPC remote processor. A processor connected to NCF. See Network Communication Function. the Tivoli OPC host processor via an SNA network. A Tivoli OPC event writer and an event transmitter (Tivoli NCP. Network Control Program. OPC Network Communication Function) are installed on the remote processor and transmit events to the Tivoli NetView operations. Operations that consist of an OPC host processor via VTAM. operator instruction that Tivoli OPC passes to NetView. These operations are run at a general workstation with open interval. The time interval during which a the WTO option specified. workstation is active and can process work.
Network Communication Function (NCF). A VTAM operation. A unit of work that is part of an application application that submits work to remote systems and and that is processed at a workstation. passes events back to the Tivoli OPC tracker subsystem on the Tivoli OPC controlling system. operation deadline. The latest time when the operation must be complete.
operation latest out. For an operation that has predecessors, the latest out date and time are the latest
Glossary 247
start time for the first critical operation in the application pending occurrence. The dummy occurrence created occurrence. If the first critical operation has not started by the daily planning process to honor a dependency by this date and time, then the operation is flagged as that has been resolved in the long-term plan but cannot late, because it will be impossible for it to start on time be resolved in the current plan because the based on the sum of the planned durations of all the predecessor's input arrival time is not within the current operations on its critical path. plan end time. operation number. The number of the operation. pending predecessor. A predecessor dependency to This uniquely identifies each operation in an application. an occurrence which is defined in the long-term plan but not yet included in the current plan. See also pending Operation object. An object contained in the occurrence. Workload Monitor/2 Operations List object. It represents one operation in the current plan. period. A time period defined in the Tivoli OPC calendar. operation status. The status of an operation at a workstation. personal workstation. In Tivoli OPC documentation this term is used to refer to a computer that runs IBM operation waiting for arrival. The status of an Operating System/2. operation that cannot begin processing because the necessary input has not arrived at a workstation. This PIF. See program interface (PIF). status is applicable only for operations without predecessors. plan. See current plan.
Operations List object. A Workload Monitor/2 object Plan object. A Workload Monitor/2 object that can be that can be used to display information about operations used to get information about the status of the current in the current plan. It contains Operation objects. plan. When the Details view of the Plan object is open, the object monitors for current plan alerts if alert operator instruction (OI). An instruction that an conditions have been specified. operator can view when the operator must manually intervene in Tivoli OPC operations. predecessor. An operation in an internal or external dependency that must finish successfully before its origin date. The date that a period (cyclic or successor operation can begin. noncyclic) starts on. print workstation. A workstation that prints output and owner ID. Owner ID is an identifier that represents the usually reports status to Tivoli OPC automatically. application owner. printout routing. The ddname of the daily planning P printout dataset. priority. The priority of an operation is a value from 1 parallel operations. Operations that are not to 9 (where 1=low, 8=high, and 9=urgent). It is one of dependent on one another and that can, therefore, run the factors that determines how Tivoli OPC schedules at the same time. applications. parallel servers. These represent the number of program interface (PIF). A Tivoli OPC interface that operations that can be processed concurrently by that lets user-written programs issue various requests to workstation. Tivoli OPC. partner transaction program. An Advanced Program-to-Program Communications (APPC) Q transaction program located at the remote partner. query current plan (QCP) dialog. An ISPF dialog that PDF. Program Development Facility. displays information taken directly from the current plan. The information includes information on operations, pending application description. An application workstations, and application occurrences. description that is incomplete and not ready for use in planning or scheduling. See active application QSAM. Queued Sequential Access Method. description.
248 Tivoli OPC Installation Guide
Y The operation is eligible to be rerouted if the R workstation becomes inactive. RACF. Resource Access Control Facility. N The operation will not be rerouted, even though the workstation has an alternate read authority. Access authority that lets a user read destination. the contents of a dataset, file, or storage area, but not blank The operation will be rerouted according to change it. the WSFAILURE parameter on the JTOPTS initialization statement. This is the default. ready (R). The status of an operation indicating that predecessor operations are complete and that the rerun. A Tivoli OPC function that lets an application or operation is ready for processing. part of an application that ended in error be run again. ready list. An ISPF display list of all the operations Resource Object Data Manager. A licensed program ready to be processed at a workstation. Ready lists are that monitors resources and informs subscribing the means by which workstation operators manually applications of their availability. report on the progress of work. restartable. If an operation is defined as restartable, receive. (1) To obtain a message or file from another Tivoli OPC can automatically restart that operation if the computer. Contrast with send. (2) In Communications workstation that it is using becomes inactive. This Manager, the command used to transfer a file from a option applies only to the operation while it has status S host. (started). The operation will be reset to status R (ready). | record format. The definition of how data is structured | in the records contained within a file. The definition return code. An error code that is issued by Tivoli | includes record names, field names, and field attributes, OPC for automatic-reporting workstations. | such as length and data type. RODM. See Resource Object Data Manager. recovery. See automatic job and started-task recovery. row command. An ISPF dialog command used to manipulate data in a table. remote job tracking. The function of tracking jobs on remote processors connected by VTAM links to a Tivoli rule. A named definition of a run cycle that determines OPC controlling processor. This function enables a when an application will run. central site to control the submitting, scheduling, and tracking of jobs at remote sites. run cycle. A specification of when an application is to run. The specification may be in the form of a rule or remote processor. A processor connected to the as a combination of period and offset. Tivoli OPC host processor via a VTAM network. replan current period. A Tivoli OPC function that S recalculates planned start times for all occurrences to reflect the actual situation. SAA. See Systems Application Architecture.
reporting attribute. A code that specifies how a SAF. System Authorization Facility. workstation will report events to Tivoli OPC. A workstation can have one of four reporting attributes: schedule. (1) The current or long-term plan. (2) To determine the input arrival date and time of an A Automatic occurrence or operation. C Completion only N Nonreporting selection button. One of the two mouse buttons. S Manual start and completion. With default mouse settings, the selection button is mouse button 1, the button on the left. You use this reroutable. Tivoli OPC can reroute operations if the button to select windows, menu choices, pages in a workstation that they are scheduled to run on is notebook, and buttons. Pressing the selection button inactive. An example of this can be if communication twice when the pointer is on an object opens the object links to the system where the workstation is located fail. to the default view. This option applies to operations only when they have status R (ready) or W (waiting). When you define an send. (1) To send a message or file to another operation, you can specify one of the following computer. Contrast with receive. (2) In reroutable options:
Glossary 249
Communications Manager, the command used to started-task computer workstation. You can specify transfer a file to the host. that a computer workstation will support started tasks by giving the workstation the STC option. Operations server. The optional Tivoli OPC component that runs defined to this workstation will be treated as started on the controlling system and handles requests from tasks, not as jobs. remote ISPF dialogs, remote PIF applications, and the Graphical User Interface for Application Description. started-task operations. Operations that start or stop started tasks. These operations are run at a computer service functions. Functions of Tivoli OPC that let the workstation with the STC option specified. user deal with exceptional conditions, such as investigating problems, preparing APAR tapes, and status. The current state of an operation or testing Tivoli OPC during implementation. occurrence. service level agreement. An agreement made status code. Codes that represent the current state of between the data processing center and its user groups an operation. The status code is often associated with indicating the service hours and levels, as well as the an extended status code. kind of service the DP center will provide. The status of an operation can be one of the following: Settings notebook. See Settings view A The operation is waiting for input to arrive. R The operation is ready for processing (all Settings view. A view of an object that is used to predecessors have been reported as complete). specify properties of the object itself. S Operation processing has started. shared DASD. Direct access storage devices that can C Operation processing has completed. be accessed from more than one processor. D The operation has been deleted from the current shared resource. A special resource or workstation plan. resource that can be used simultaneously by more than I Operation processing has been interrupted. one operation. * The operation is ready for processing. There is a slack. Refers to ‘spare’ time. This extra time can be predecessor at a nonreporting workstation, but all calculated for the critical path by taking 'Deadline less other predecessors are reported as complete. the Input Arrival less the sum of Operation Durations'. E The operation has ended in error. SMF. System Management Facilities. An MVS W The operation is waiting for a predecessor to component that collects and records system and complete. job-related information. U The operation status is not known. smoothing factor. A value in the range 0-100 that submit/release dataset. A dataset shared between controls the extent to which actual durations are fed the Tivoli OPC host and a local Tivoli OPC processor back into the application description database. that is used to send job-stream data and job-release SMP. System Modification Program. commands from the host to the local processor.
SNA. See Systems Network Architecture. subresources. A set of resource names and rules for the construction of resource names. Tivoli OPC uses special resource. A resource that is not associated these names when checking a user's authority to with a particular workstation, such as a dataset. access individual Tivoli OPC data records. splittable. Refers to a workstation where operations subsystem. A secondary or subordinate system, can be interrupted while being processed. usually capable of operating independently of, or asynchronously with, a controlling system. standard. User-specified open intervals for a typical day at a workstation. successor. An operation in an internal or external dependency that cannot begin until its predecessor started (S). A Tivoli OPC reporting status, for an completes processing. operation or an application, indicating that an operation or an occurrence is started. SYSOUT. A system output stream, also an indicator used in data definition statements to signify that a dataset is to be written on a system output unit.
250 Tivoli OPC Installation Guide
SYSOUT class. An indicator used in data definition link between the MVS system that it runs on and the statements to signify that a dataset is to be written on a controller. system output unit. It applies only to print workstations. tracking event log. A log of job-tracking events and SYSPLEX. An MVS/ESA systems complex provides updates to the current schedule. systems management enhancements for coordinating and controlling the data processing facility across transport time. The time allotted for transporting multiple systems, while minimizing complexity. materials from the workstation where the preceding Implemented using the 9037 Sysplex Timer and the operation took place to the workstation where the cross-system coupling facility (XCF) component of current operation is to occur. The transport time is MVS/ESA. used only for planning purposes. Operations will be started irrespective of the transport time specified. Systems Application Architecture (SAA). A formal set of rules that enable applications to be run without TSO. Time Sharing Option. modification, in different computer environments. turnover. A subfunction of Tivoli OPC that is activated Systems Network Architecture (SNA). The when Tivoli OPC creates an updated version of the description of the logical structure, formats, protocols, current plan. and operational sequences for transmitting information units through the networks and also operation sequences for controlling the configuration and U operations of networks. undecided (U). A Tivoli OPC reporting status, for an operation or an application, indicating that the status is T not known. tail plan. Created during the daily planning process, update authority. (1) Access authority to use the includes only tail work; that is, work that started during ISPF/PDF edit functions of the Tivoli OPC dialog. The or before the current planning period and that extends authority is given to the user via RACF. (2) Access beyond its end. authority to modify a master file or dataset with the current information. TCP/IP. Transmission Control Protocol/Internet Protocol. A set of communication protocols that support peer-to-peer connectivity functions for both local and V wide-area networks. validity period. The time interval defined by an origin temporary operator instructions. Operator date and an end date within which a run cycle or an instructions that have a specific time limit during which application description is valid. they are valid. They will be displayed to the workstation variable table. A group of related JCL variables. operator only during that time period. Tivoli OPC can check these variable tables for time dependent. Tivoli OPC attempts to start substitution values for variables that occur in JCL. This operations as soon as possible, when all dependencies substitution can occur during job setup or at job submit. have been resolved and processing resources are versions. Applications with the same ID but different available. However, you can specify that an operation validity dates. is time-dependent, so Tivoli OPC will not start it until a specific time. VSAM. Virtual Storage Access Method. time zone support. A feature of Tivoli OPC that lets VTAM. Virtual Telecommunications Access Method. applications be planned and run with respect to the local time of the processor that runs the application. Some networks might have processors in different time W zones. The controlling processor will make allowances for differences in time during planning activities to waiting (W). A status indicating that an application is ensure that interacting activities are correctly waiting for a predecessor operation to complete. coordinated. waiting list. A list of jobs that have been submitted TP. See application transaction program. but still have uncompleted predecessors. Operations will be included in the waiting list if the JCL is not tracker. The Tivoli OPC component that runs on every system in your complex. It acts as the communication
Glossary 251
submitted by the Tivoli OPC controller and the Tivoli workstation description database. A Tivoli OPC OPC tracker has been started with HOLDJOB(YES). database containing descriptions of the Tivoli OPC workstations in the operations department. work day. A day on which applications can normally be scheduled to start. workstation resource. A physical resource, such as a tape drive, that must be allocated among jobs. When work-days-only cyclic period. A cyclic period where you define a workstation, you can specify the quantity of only work days are counted when calculating the each of two resources (R1 and R2) that are available to interval. operations. When defining operations to that workstation, you can specify the number of these work-day end time. The time when one Tivoli OPC resources that must be available for the operation to work day ends and the next day begins. By default, start on that workstation. this time is midnight. For example, if the work-day end time is 02:00, work for workstation type. Each workstation can be one of Friday can continue until 02:00 on Saturday morning, three types: computer, printer, or general. even if Saturday is a free day. If Saturday and Sunday write-to-operator workstation. A general workstation are free days, no new work will be started until 02:00 on that lets you use Tivoli OPC scheduling facilities to Monday. issue a write-to-operator (WTO) message at a specific Workload Monitor/2. A part of Tivoli OPC. It runs on operator console defined by the workstation destination. OS/2 Version 2 (or later) and communicates with a NetView can intercept the WTO message and take Tivoli OPC controller subsystem. It carries data about necessary action. the subsystem's current plan from the host to a WTO message. Write-to-operator message. workstation, and can update operation status. WTO operations. Operations that consist of an workstation. (1) A unit, place, or group that performs operator instruction that Tivoli OPC passes to NetView. a specific data processing function. (2) A logical place These operations are run at a general workstation with where work occurs in an operations department. the WTO option specified. Tivoli OPC requires that you define the following characteristics for each workstation: the type of work it does, the quantity of work it can handle at any particular X time, and the times it is active. The activity that occurs at each workstation is called an operation. (3) See also XCF. MVS/ESA cross-system coupling facility. personal workstation. XRF. Extended recovery facility.
252 Tivoli OPC Installation Guide
Index
CDRSC statements A API 99 ACCEPT processing 160 NCF 93 activating checklist for installing 26 API (application programming interface) 96 checkpoint dataset (EQQCKPT) 73 NCF 93 considerations when allocating 75 server 100, 104 class descriptor table 63 subtasks 6 class of service table 96 AIX/6000 CLIST library 73, 87 software requirements for controlled system 201 COFDLFnn member of SYS1.PARMLIB 59 API (application programming interface) commands activating support for 59, 96 MVS 216 APPC/MVS TSO options, updating in SYS1.PARMLIB 59, 99, 103 BACKUP 58 APPCPMnn member of SYS1.PARMLIB 59, 99, 103 OPINFO 58 APPL OPSTAT 58 resource class 63 SRSTAT 58 statements WSSTAT 58 API (application programming interface) 97 COMMNDnn member of SYS1.PARMLIB 59 local LU for the server, defining 101 compatibility, software 204 local LU, defining 97 configurations NCF 93, 95 catalog management, description 183, 186 application description dataset (EQQADDS) 68 connecting Tivoli OPC systems 12 considerations when allocating 71 cross-system coupling facility (XCF) 13 application node definitions, NCF 93 description 5 application programming interface (API) event dataset 11 activating support for 59, 96 examples APPLY processing 160 introduction 15, 167 AS/400 NCF connection 177, 179 software requirements for controlled system 201 OPC/A Release 2 system 181, 185 AUTHCMD statement, updating for Tivoli OPC TSO shared DASD connection 16, 168, 170 commands 58 single address space 20 authority, problem determination procedures 114 sysplex 173 AUTHTSF statement, updating for EQQMINOR 57 Tivoli OPC PLEX 175 automatic-recovery-procedure library (EQQPRLIB) 73 VTAM connection 17, 177, 179 considerations when allocating 80 XCF connection 18, 173 MAS (Multi-Access Spool) restrictions 14 Multi-Access Spool (MAS) restrictions 14 B NCF (network communication function) 13 BACKUP command 58 planning 11 batch jobs shared DASD 12 security 61 VTAM 13 user ID of Tivoli OPC submitted jobs 61 workload restart batch-jobs description 14 generating skeleton JCL 45 examples 169, 171, 174, 178, 180, 182, 186 workstation destination 13 C XCF (cross-system coupling facility) 13 calendar and workstation dataset (EQQWSDS) 68 controlled systems Catalog management description 5 ECSA (extended common service area), use of 53 software requirements 201 sample configurations, description 183, 186 controller checking the message log 112
Copyright IBM Corp. 1991, 1999 253
controller (continued) datasets (continued) description 4 considerations when allocating (continued) IBMOPC resource class 62 job library (EQQJBLIB) 78 loading national language support (NLS) job-tracking archive (EQQJTARC) 79 software 37 job-tracking log (EQQJTnn) 79 loading software 36 message log (EQQMLOG) 80 RACF 61, 62 parameter library (EQQPARM) 80 software requirements 199 PIF parameter dataset (EQQYPARM) 80 started task datasets 83, 85 started-task submit (EQQSTC) 81 verifying installation 111 submit/release (EQQSUDS) 81 controlling system in Tivoli OPC procedure JCL description 5 optional 85 COS table 96 required 83 COUPLEnn member of SYS1.PARMLIB 57 ISPF profile 87 creating sample JCL 40 migrating 141, 145, 146 cross-domain resource definitions security 62 API 99 Tivoli OPC dialog 89 NCF 94 DB2 database cross-system coupling facility (XCF) creating 87 groups 91 default dialog–controller connection table 88 including 91 diagnostic dataset initialization statements 92 EQQDMSG 73, 75 MVS initialization options 57 EQQDUMP 73, 75, 96 run time options 92 SYSMDUMP 56, 73, 76 current plan dataset (EQQCPnDS) 68 dialog considerations when allocating 71 description 7 cutover 146, 147 entering 90 EQQMINOR, authorizing 57 initializing 87 D ISPF command table 88 data lookaside facility (DLF) 59 problem determination procedures 114 databases, migrating 141, 145, 146 security 63 dataset triggering Digital OpenVMS implementing 59 software requirements for controlled system 202 dataset triggering selection table macro (EQQLSENT) dispatching priority 59 invoking 193 distribution tape 8 syntax 193 DLF (data lookaside facility) 59 datasets dump content definitions 56 allocating 67—81 dump dataset (SYSMDUMP) 56, 73, 76 non-VSAM 72—81 dynamic exits (PROGnn) 54, 55 VSAM 68 considerations when allocating application description (EQQADDS) 71 E automatic-recovery-procedure library ECSA (extended common service area) 51 (EQQPRLIB) 80 ended-in-error-list layout table 89 checkpoint (EQQCKPT) 75 environment setup 158 current plan (EQQCPnDS) 71 EQQADDS (application description dataset) 68 diagnostic (EQQDUMP) 75 considerations when allocating 71 diagnostic message and trace (EQQDMSG) 75 EQQBRDS (internal reader dataset) 75 dual job-tracking log (EQQDLnn) 79 EQQCKPT (checkpoint dataset) 73 dump (SYSMDUMP) 76 considerations when allocating 75 event (EQQEVDS) 76 EQQCPnDS (current plan dataset) 68 general 67 considerations when allocating 71 JCC incident log 78 EQQDLnn (dual job-tracking-log dataset) 73 JCC incident work (EQQINCWK) 79 considerations when allocating 79 JCC message table (EQQJCLIB) 78 JCL repository (EQQJSnDS) 72
254 Tivoli OPC Installation Guide
EQQDMSG (diagnostic message and trace EQQSTC (started-task-submit dataset) 73 dataset) 73 considerations when allocating 81 considerations when allocating 75 EQQSUDS (submit/release dataset) 13, 73 EQQDUMP (diagnostic dataset) 73, 96 considerations when allocating 81 considerations when allocating 75 EQQTROUT (tracklog dataset) 79 EQQEVDnn (event dataset for an event reader) 73 EQQWSDS (workstation and calendar dataset) 68 calculating optimum LRECL 77 EQQYPARM (parameter dataset) considerations when allocating 76 considerations when allocating 80 EQQEVDS (event dataset) 73 EQQYPARM (PIF parameter dataset) 73 calculating optimum LRECL 77 ETTRCY1 period 143, 150 considerations when allocating 76 event dataset EQQEXIT (event-tracking-code generation macro) description 11 in JES exits 49, 189 for an event reader (EQQEVDnn) 73 in SMF exits 49, 189 for an event writer (EQQEVDS) 73 invoking 189 for submit checkpointing 11, 73 syntax 190 verify 108 EQQINCWK (JCC incident work dataset) 73 event types 107 considerations when allocating 79 event writer EQQINITD 51 using with event reader function 25 EQQJBLIB (job library dataset) 73 event-tracking-code generation macro (EQQEXIT) considerations when allocating 78 in JES exits 49, 189 EQQJCLIB (JCC message table dataset) 73 in SMF exits 49, 189 considerations when allocating 78 invoking 189 EQQJOBS installation aid syntax 190 creating sample JCL 40 exits description 38 event tracking 49 generating Tivoli OPC batch-job skeletons 45 extended common service area (ECSA) 51 setting up 39 EQQJSnDS (JCL repository dataset) 68 considerations when allocating 72 F EQQJTARC (job-tracking-archive dataset) 73 fallback 149 considerations when allocating 79 functions of Tivoli OPC EQQJTnn (job-tracking-log dataset) 73 subtasks, activating 6 considerations when allocating 79 EQQLDDS (long-term plan work dataset) 68 EQQLSENT (dataset triggering selection table macro) G GDDM 89 invoking 193 generating Tivoli OPC batch-job skeletons 45 syntax 193 graphical attribute table 89 EQQLTBKP (long-term-plan backup dataset) 68 EQQLTDS (long-term plan dataset) 68 EQQMINOR, authorizing for TSO 57 H EQQMLOG hardware requirements 197 checking at the controller 112 Hiperbatch support checking at the server 113 COFDLFnn, updating 59 EQQMLOG (message log dataset) 73 history function considerations when allocating 80 installing 87 EQQNCPDS (new current plan dataset) 68 hot standby 25 EQQNCXDS (new current plan extension dataset) 68 HP-UX EQQOIDS (operator instruction dataset) 68 software requirements for controlled system 202 EQQPARM (parameter library) 73 considerations when allocating 80 EQQPRLIB (automatic-recovery-procedure library) 73 I considerations when allocating 80 IBMOPC resource class 62, 63 EQQRDDS (resource description dataset) 68 ICHRFR01 63 EQQSIDS (side information dataset) 68 ICHRIN03 61
Index 255
ICHRRCDE 63 JES2 IKJTSOnn member of SYS1.PARMLIB EXIT7 189 AUTHCMD statement, updating for Tivoli OPC TSO MAS (Multi-Access Spool) restrictions 14 commands 58 Multi-Access Spool (MAS) restrictions 14 AUTHTSF statement, updating for EQQMINOR 57 JESJOBS RACF resource class 65 incident log (JCC) JESSPOOL RACF resource class 66 considerations when allocating 78 job completion checker (JCC) initialization statements datasets defining 86 considerations when allocating 78 installing incident log 73, 78 availability 25 incident work 79 checklist 26 incident work (EQQINCWK) 73 considerations 25 message table (EQQJCLIB) 73, 78 DB2 database 87 job library dataset (EQQJBLIB) 73 detailed instructions 35 considerations when allocating 78 EQQJOBS installation aid job-tracking datasets creating sample JCL 40 considerations when allocating 79 description 38 dual job-tracking-log dataset (EQQDLnn) 73 generating Tivoli OPC batch-job skeletons 45 job-tracking-archive dataset (EQQJTARC) 73 setting up 39 job-tracking-log dataset (EQQJTnn) 73 event tracking exits 49 tracklog dataset (EQQTROUT) 79 hot standby 25 initialization statements, defining 86 loading controller software 36 L loading national language support (NLS) software libraries for the controller 37 CLIST 87 for the Workload Monitor/2 38 ISPF table 88 loading tracker software 36 link 56 loading Workload Monitor/2 software 37 sample (SEQQSAMP) 155 MAS (Multi-Access Spool) restrictions 14 link library (LNKLSTnn) 56 Multi-Access Spool (MAS) restrictions 14 LNKLSTnn member of SYS1.PARMLIB 56 NCF 93 load module library (IEAAPFnn) 54 overview 9 logon mode table 95 planning 25 long-term plan dataset (EQQLTDS) 68 RACF 60 long-term plan work dataset (EQQLDDS) 68 security 60 long-term-plan backup dataset (EQQLTBKP) 68 started-task operations, implementing support for 82 verifying 105 M macros configuration 118 EQQEXIT (event-tracking-code generation controller 111 macro) 49, 189 standby controller 115 EQQLSENT (dataset triggering selection table submit events 129 macro) 193 tracker 105 migrating, from OPC/A Release 2 220 tracking events 107 MAS (Multi-Access Spool) restrictions 14 internal reader dataset (EQQBRDS) 75 MAXECSA values 53 ISPF (Interactive System Productivity Facility) message log dataset command table 88 checking at the controller 112 table library 88 checking at the server 113 EQQMLOG 73 J considerations when allocating 80 JCL repository dataset (EQQJSnDS) 68 migrating considerations when allocating 72 databases 141, 145, 146 JES exits, installing 49 datasets 141, 145, 146 EQQICTOP conversion program 141
256 Tivoli OPC Installation Guide
migrating (continued) OS/400 OPC/A Release 2 considerations software requirements for controlled system 201 batch-job JCL 220 exits 219 initialization statements 212 P ISPF table 220 parallel sysplex macros 220 configuration examples 167 modules 217 parallel test, OPC/A Release 2 and OPC/ESA Release OPC/ESA Release 1 considerations 2 139 controlled systems 134 parallel test, OPC/ESA Release 2 and OPC/ESA exits 219 Release 3 139 overview 137 parameter library (EQQPARM) 73 Multi-Access Spool (MAS) restrictions 14 considerations when allocating 80 multiple systems performance considerations configuration examples 167 dispatching priority 59 MVS event dataset (EQQEVDS), calculating optimum relationship with Tivoli OPC 7 LRECL 77 router service 63 program properties table (PPT) 59 SSI (subsystem interface) 7 starting an event writer with an event reader 25 subsystem interface (SSI) 7 PIF parameter dataset (EQQYPARM) versions required 199 considerations when allocating 80 PIF parameter dataset(EQQYPARM) 73 planning N installation 25 national language support (NLS) PLEX configuration 175 loading for the controller 37 PPT (program properties table) 59 loading for the Workload Monitor/2 38 problem determination procedures NCF (network communication function) authority 114 activating 93 dialog 114 application node definitions 93 job tracking 107 cross-domain resource definitions 94 security 114 network communication function (NCF) tracker 107 activating 93 PROGnn member of SYS1.PARMLIB 54, 55 application node definitions 93 program directory 8 cross-domain resource definitions 94 program properties table (PPT) 59 new current plan dataset (EQQNCPDS) 68 program temporary fix (PTF) 8 new current plan extension dataset (EQQNCXDS) 68 PTF (program temporary fix) 8 NLS (national language support) loading for the controller 37 loading for the Workload Monitor/2 38 R RACF 7 APPL resource class 63 O batch jobs 61 OPC/A Release 2 class descriptor table 63 parallel test 139 IBMOPC resource class 62, 63 OPC/ESA Release 2 ICHRIN03 61 parallel test 139 modifying 61, 62 OpenVMS, Digital router table 63 software requirements for controlled system 202 STARTED resource class 61 operator instruction dataset (EQQOIDS) 68 started task 62 OPERCMDS RACF resource class 66 user ID of Tivoli OPC submitted jobs 61 OPINFO command 58 using functions of RACF 1.9 OPSTAT command 58 JESJOBS resource class 65 OS/2 JESSPOOL resource class 66 software requirements for controlled system 201 OPERCMDS resource class 66 software requirements for Workload Monitor/2 200 SURROGAT resource class 65
Index 257
RACF (continued) Standby controller using functions of RACF 2.1 description 5 IBMOPC resource class 63 verifying installation 115 STARTED resource class 61 STARTED resource class 61 ready-list layout table 89 started-task operations, implementing support for 82 RECEIVE processing 159 started-task procedure related software 204 controller 82 requirements tracker 82 hardware 197 started-task-submit dataset (EQQSTC) 73 software 199 considerations when allocating 81 resource description dataset (EQQRDDS) 68 submit checkpointing 11 router table, RACF 63 submit/release dataset (EQQSUDS) 13, 73 considerations when allocating 81 subsystem S APPL resource class 63 SAF (system authorization facility) 7, 62 name table (IEFSSNnn) 51 sample JCL, creating 40 subtasks, activating 6 sample library (SEQQSAMP) 8, 155 Sun Solaris SCHEDnn member of SYS1.PARMLIB 59 software requirements for controlled system 202 security 7 SunOS APPL resource class 63 software requirements for controlled system 202 batch jobs 61 SURROGAT RACF resource class 65 class descriptor table 63 SYS1.PARMLIB IBMOPC resource class 62, 63 APPC/MVS options (APPCPMnn) 59, 99, 103 modifying 61, 62 defining subsystems (IEFSSNnn) 51 router table 63 dispatching priority 59 SAF (system authorization facility) 62 dynamic exits (PROGnn) 54, 55 STARTED resource class 61 EQQMINOR, authorizing for TSO (IKJTSOnn) 57 started task 62 Hiperbatch support (COFDLFnn) 59 system authorization facility (SAF) 62 link library (LNKLSTnn) 56 user ID of the Tivoli OPC address space 61 load module library (IEAAPFnn) 54, 56 user ID of Tivoli OPC submitted jobs 61 performance (SCHEDnn) 59 using functions of RACF 1.9 program properties table (PPT) 59 JESJOBS resource class 65 SMF parameters (SMFPRMnn) 54 JESSPOOL resource class 66 starting Tivoli OPC (COMMNDnn) 59 OPERCMDS resource class 66 SYSMDUMP 56 SURROGAT resource class 65 updating dump content definitions 56 security, problem determination procedures 114 XCF initialization options (COUPLEnn) 57 SEQQSAMP (sample library) 8, 155 SYS1.PROCLIB server controller 82 activating 100, 104 tracker 82 checking the message log 113 SYSMDUMP (dump dataset) 56, 73 description 4 considerations when allocating 76 optional datasets 85 sysplex required datasets 83 configuration examples 167 sample configuration 175 sysplex (system complex) 173 updating APPC/MVS options 103 system authorization facility (SAF) 7, 62 side information dataset (EQQSIDS) 68 system complex (sysplex) 173 Silicon Graphics IRIX software requirements for controlled system 202 SMF exits, installing 49 T SMF parameters (SMFPRMnn) 54, 55 time zone support 167 SMFPRMnn member of SYS1.PARMLIB 54, 55 Tivoli Job Scheduling Console server software compatibility 204 activating support for 104 SRSTAT command 58 server support 104
258 Tivoli OPC Installation Guide
Tivoli OPC server Workload Monitor/2 (continued) activating support for 100 loading software 37 server support 100 network support 96 tracker software requirements 200 description 4 workload restart (WLR) loading software 36 description 14 optional datasets 85 examples 169, 171, 174, 178, 180, 182, 186 RACF 61 workstation started task datasets 83 destination 13 verifying installation 105 workstation and calendar dataset (EQQWSDS) 68 tracklog dataset (EQQTROUT) 79 WSSTAT command 58 TSO IKJTSOnn member of SYS1.PARMLIB AUTHCMD statement, updating for Tivoli OPC X TSO commands 58 XCF (cross-system coupling facility) AUTHTSF statement, updating for groups 91 EQQMINOR 57 including 91 RACF user 63 initialization statements 92 TSO commands MVS initialization options 57 BACKUP 58 run time options 92 OPINFO 58 OPSTAT 58 SRSTAT 58 WSSTAT 58
U UNIX software requirements for controlled system 201
V VARY ACT command 96 verifying installation 105 configuration 118 controller 111 standby controller 115 submit events 129 tracker 105 tracking events 107 VMS, Digital software requirements for controlled system 202 VTAM activate network resources 96 class of service table 96 defining NCF 93 logon mode table 95 VARY ACT command 96
W Windows NT software requirements for controlled system 201 Workload Monitor/2 loading national language support (NLS) software 38
Index 259 Communicating Your Comments to IBM
Tivoli Operations Planning and Control Installation Guide Version 2 Release 3 Publication No. SH19-4379-02
If you especially like or dislike anything about this book, please use one of the methods listed below to send your comments to IBM. Whichever method you choose, make sure you send your name, address, and telephone number if you would like a reply.
Feel free to comment on specific errors or omissions, accuracy, organization, subject matter, or completeness of this book. However, the comments you send should pertain to only the information in this manual and the way in which the information is presented. To request additional publications, or to ask questions or make comments about the functions of IBM products or systems, you should talk to your IBM representative or to your IBM authorized remarketer.
When you send comments to IBM, you grant IBM a nonexclusive right to use or distribute your comments in any way it believes appropriate without incurring any obligation to you.
If you prefer to send comments by mail, use the reader's comment form (RCF) at the back of this book. If you wish, you can give the RCF to the local branch office or IBM representative for postage-paid mailing.
If you prefer to send comments by fax, use this number, which is in Italy: 39+06+596+62077
If you prefer to send comments electronically, use this network ID: ROMERCF at VNET.IBM.COM
Make sure to include the following in your note: Title and publication number of this book Page number or topic to which your comment applies
Help us help you!
Tivoli Operations Planning and Control Installation Guide Version 2 Release 3 Publication No. SH19-4379-02
We hope you find this publication useful, readable and technically accurate, but only you can tell us! Your comments and suggestions will help us improve our technical publications. Please take a few minutes to let us know what you think by completing this form.
Overall, how satisfied are you with the information in this book? Satisfied Dissatisfied ØØ
How satisfied are you that the information in this book is: Satisfied Dissatisfied Accurate ØØ Complete ØØ Easy to find ØØ Easy to understand ØØ Well organized ØØ Applicable to your task ØØ
Specific Comments or Problems:
Please tell us how we can improve this book:
Thank you for your response. When you send information to IBM, you grant IBM the right to use or distribute the information without incurring any obligation to you. You of course retain the right to use the information in any way you choose.
Name Address
Company or Organization
Phone No. Help us help you! Cut or Fold Along Line SH19-4379-02 IBM
Fold and Tape Please do not staple Fold and Tape
PLACE POSTAGE STAMP HERE
Tivoli OPC Information Development Rome Tivoli Laboratory IBM Italia S.p.A. Via Sciangai, 53 00144 Rome Italy
Fold and Tape Please do not staple Fold and Tape
Cut or Fold SH19-4379-02 Along Line
IBM
Program Number: 5697-OPC
Printed in Denmark by Danmark A/S
SH19-4379-ð2