Primary Managers User’s Guidepublib.boulder.ibm.com/tividd/td/ITIntegRM/GC32-9225-00/... · 2004. 8. 21. · Primary Managers User’s Guide Integrated Resource Manager Version

Primary Managers User’s GuideIntegrated Resource Manager

Version 500

GC32-9225-00

September 2002

Candle Corporation201 North Douglas Street

El Segundo, California 90245

2 IRM Primary Managers User’s Guide Version 500

Registered trademarks and service marks of Candle Corporation: AF/OPERATOR, AF/PERFORMER, AF/REMOTE, Availability Command Center, Candle Command Center, Candle Electronic Customer Support, Candle logo, Candle Management Server, Candle Management Workstation, Candle Technologies, CL/CONFERENCE, CL/SUPERSESSION, CT, CT/Data Server, CT/DS, DB Logo, DB/QUICKCHANGE, DELTAMON, ETEWatch, IntelliWatch, MQSecure, MQView, OMEGACENTER, OMEGAMON, OMEGAMON/e, OMEGAMON II, OMEGAMON Monitoring Agent, OMEGAVIEW, OMEGAVIEW II, Solutions for Networked Businesses, and Transplex.Trademarks and service marks of Candle Corporation: Alert Adapter, Alert Adapter Plus, Alert Emitter, AMS, Amsys, AUTOMATED FACILITIES, Availability Management Systems, Candle Business Partner Logo, Candle Direct Logo, CandleLight, CandleNet, CandleNet 2000, CandleNet Portal, Candle CommandPro, CCC, CECS, CICAT, CL/ENGINE, CL/GATEWAY, CL/TECHNOLOGY, CMS, CMW, Command & Control, CommandWatch, Connect-Two, CSA ANALYZER, CT/ALS, CT/Application Logic Services, CT/DCS, CT/Distributed Computing Services, CT/Engine, CT/Implementation Services, CT/IX, CT/Workbench, CT/Workstation Server, CT/WS, DB/DASD, DB/EXPLAIN, DB/MIGRATOR, DB/QUICKCOMPARE, DB/SMU, DB/Tools, DB/WORKBENCH, Design Network, DEXAN, eBA*ServiceMonitor, End-to-End, Enterprise Candle Command Center, Enterprise Candle Management Workstation, EPILOG, ERPNet, ESRA, ETEWatch, HostBridge, IntelliWatch Pinnacle, Lava Console, Messaging Mastered, MQADMIN, MQEdit, MQEXPERT, MQMON, NBX, OMA, OMC Gateway, OMC Status Manager, OMEGACENTER Bridge, OMEGACENTER Gateway, OMEGACENTER Status Manager, OMEGAMON Management Center, OSM, PC COMPANION, Performance Pac, PowerQ, PQConfiguration, PQEdit, PQScope, Response Time Network, Roma, Roma Application Manager, Roma Broker, Roma BSP, Roma Connector, Roma Developer, Roma FS/A, Roma FS/Access, Roma Network, Roma Object Access, Roma Systems Manager, Roma WF/Access, Roma Workflow Access, RTA, RTN, SentinelManager, Solutions for Networked Applications, Status Monitor, Tracer, Unified Directory Services, and Volcano.Trademarks and registered trademarks of other companies: AIX, DB2, and MQSeries are registered trademarks of International Business Machines Corporation. SAP is a registered trademark and R/3 is a trademark of SAP AG. UNIX is a registered trademark in the U.S. and other countries, licensed exclusively through X/Open Company Ltd. HP-UX is a trademark of Hewlett-Packard Company. SunOS is a trademark of Sun Microsystems, Inc.

All other company and product names used herein are trademarks or registered trademarks of their respective companies.

ProtoView Development Corp. - May contain DataTable Version 3.0 Copyright 1989 - 1996 by ProtoView Development Corp. and distributed under license by Candle Corporation.

Copyright © September 2002, Candle Corporation, a California corporation. All rights reserved. International rights secured.

Threaded Environment for AS/400, Patent No. 5,504,898; Data Server with Data Probes Employing Predicate Tests in Rule Statements (Event Driven Sampling), Patent No. 5,615,359; MVS/ESA Message Transport System Using the XCF Coupling Facility, Patent No. 5,754,856; Intelligent Remote Agent for Computer Performance Monitoring, Patent No. 5,781,703; Data Server with Event Driven Sampling, Patent No. 5,809,238; Threaded Environment for Computer Systems Without Native Threading Support, Patent No. 5,835,763; Object Procedure Messaging Facility, Patent No. 5,848,234; End-to-End Response Time Measurement for Computer Programs, Patent No. 5,991,705; Communications on a Network, Patent Pending; Improved Message Queuing Based Network Computing Architecture, Patent Pending; User Interface for System Management Applications, Patent Pending.

NOTICE: This documentation is provided with RESTRICTED RIGHTS. Use, duplication, or disclosure by the Government is subject to restrictions set forth in the applicable license agreement and/or the applicable government rights clause.

This documentation contains confidential, proprietary information of Candle Corporation that is licensed for your internal use only. Any unauthorized use, duplication, or disclosure is unlawful.

Contents 3

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11About this Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Adobe Portable Document Format . . . . . . . . . . . . . . . . . . . . . . . . . . 12Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Printing problems? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Documentation Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Panels and figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Revision bars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Variables and literals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Symbols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Documentation Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Online Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Printed documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

What’s New . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Chapter 1. Started Task Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21Started Task Manager Components . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Task Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Service Subroutines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23AF/OPERATOR System Variables . . . . . . . . . . . . . . . . . . . 29AF/OPERATOR Traps . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Resource Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31Defining a Resource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31Dynamic Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34Resource Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34Checkpoint Restart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35Resource Manipulation Lock . . . . . . . . . . . . . . . . . . . . . . . 35Queueing a Function Request . . . . . . . . . . . . . . . . . . . . . . 35Waiting for a Function to Complete . . . . . . . . . . . . . . . . . . 35

Contents

Contents


The Force Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36Problem Notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36Resource Management Limitations . . . . . . . . . . . . . . . . . . 37

Started Task Manager Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38The Initialization Process . . . . . . . . . . . . . . . . . . . . . . . . . . 38The Start Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39The Stop Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44The Warning Process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48The Schedule Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49The Cycle Process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49The Kill Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49Recovery Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50Problem Record Command File . . . . . . . . . . . . . . . . . . . . 53Recovery Retry WTOR . . . . . . . . . . . . . . . . . . . . . . . . . . . 53Recovery Exit Command File . . . . . . . . . . . . . . . . . . . . . . 54

User Exits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56Pre-Start Exit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57Post-Start Exit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58Start-WTOR Exit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59Pre-Stop Exit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60Post-Stop Exit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62Stop-WTOR Exit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63Predecessor Exit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64Successor Exit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65VTAM Dependency Exit . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Started Task Manager Task Definition . . . . . . . . . . . . . . . . . . . . . . . . 67Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67Adding or Updating Resources . . . . . . . . . . . . . . . . . . . . . 68Started Task Manager - Task Add Panel. . . . . . . . . . . . . . . 69Started Task Manager Task Definition Panel . . . . . . . . . . . 70Started Task Manager - Add a List . . . . . . . . . . . . . . . . . 101Started Task Manager Schedule Definition . . . . . . . . . . . 102

Using the Service Subroutines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106Starting the Service Subroutines . . . . . . . . . . . . . . . . . . . 106

Controlling Started Task Manager Resources . . . . . . . . . . . . . . . . . . 107RCF Command Syntax. . . . . . . . . . . . . . . . . . . . . . . . . . 108

STM Reporting Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

Contents 5

Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137Outputs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

RCF Command On-line Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

Chapter 2. Message Manager. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149Message Manager Components. . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

Message Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151Service Subroutines . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151AF/OPERATOR System Variables . . . . . . . . . . . . . . . . . . 152

Message Manager Message Definition . . . . . . . . . . . . . . . . . . . . . . . 153Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153Adding or Updating Messages. . . . . . . . . . . . . . . . . . . . . 153Message Manager - Add a Message . . . . . . . . . . . . . . . . 154Message Manager Message Definition Panel . . . . . . . . . . 155

Using the Service Subroutines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171Starting the Service Subroutines . . . . . . . . . . . . . . . . . . . 171

Controlling Message Manager Resources . . . . . . . . . . . . . . . . . . . . . 172MCF Command Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 173MCF Command On-line Help. . . . . . . . . . . . . . . . . . . . . 178

Chapter 3. Command Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179Command Manager Components . . . . . . . . . . . . . . . . . . . . . . . . . . 181

Command Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . 181Service Subroutines . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182AF/OPERATOR System Variables . . . . . . . . . . . . . . . . . . 182

Command Manager Command Definition . . . . . . . . . . . . . . . . . . . 183Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183Adding or Updating Commands . . . . . . . . . . . . . . . . . . . 183Command Manager - Add a Command . . . . . . . . . . . . . 184Command Manager Command Definition Panel . . . . . . . 185


Controlling Command Manager Resources . . . . . . . . . . . . . . . . . . . 196CCF Command Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 197CCF Command On-line Help . . . . . . . . . . . . . . . . . . . . . 202

Contents


Chapter 4. Schedule Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203Schedule Manager Components . . . . . . . . . . . . . . . . . . . . . . . . . . . 204

Schedule Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204Service Subroutines . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204AF/OPERATOR System Variables . . . . . . . . . . . . . . . . . . 205

Schedule Manager Schedule Definition . . . . . . . . . . . . . . . . . . . . . . 206Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206Adding or Updating Schedules . . . . . . . . . . . . . . . . . . . . 206Schedule Manager - Add a Schedule . . . . . . . . . . . . . . . 207Schedule Manager Schedule Definition Panel . . . . . . . . . 208


Controlling Schedule Manager Resources . . . . . . . . . . . . . . . . . . . . 216SCF Command Syntax. . . . . . . . . . . . . . . . . . . . . . . . . . 217SCF Command On-line Help . . . . . . . . . . . . . . . . . . . . . 222

Chapter 5. VTAM Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223VTAM Manager Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225

VTAM Resource Definition . . . . . . . . . . . . . . . . . . . . . . . 225Service Subroutines . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225AF/OPERATOR System Variables . . . . . . . . . . . . . . . . . . 226

VTAM Manager Resource Definition . . . . . . . . . . . . . . . . . . . . . . . . 227Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227Adding or Updating Commands . . . . . . . . . . . . . . . . . . . 227VTAM Manager Resource Definition Panel . . . . . . . . . . . 228


Controlling VTAM Manager Resources . . . . . . . . . . . . . . . . . . . . . . 234VTM Command Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 235VTM Command On-line Help. . . . . . . . . . . . . . . . . . . . . 239

Chapter 6. Device Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241Device Manager Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242

Automation Application Tables . . . . . . . . . . . . . . . . . . . . 242Service Subroutines . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243AF/OPERATOR System Variables . . . . . . . . . . . . . . . . . . 244

Contents 7

Automation Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244Using the Service Subroutines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250Starting the Service Subroutines . . . . . . . . . . . . . . . . . . . 250

Controlling Device Manager Resources . . . . . . . . . . . . . . . . . . . . . . 251DEV Command Syntax. . . . . . . . . . . . . . . . . . . . . . . . . . 252DEV Command On-line Help . . . . . . . . . . . . . . . . . . . . . 256

Chapter 7. Console Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257Console Manager Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258

Console Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258Service Subroutines . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258AF/OPERATOR System Variables . . . . . . . . . . . . . . . . . . 259

Console Manager Console Definition . . . . . . . . . . . . . . . . . . . . . . . 260Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260Adding or Updating Consoles . . . . . . . . . . . . . . . . . . . . . 260Console Manager Consolve Definition . . . . . . . . . . . . . . 261Console Manager Description Definition . . . . . . . . . . . . . 264


Controlling Console Manager Resources . . . . . . . . . . . . . . . . . . . . . 268CNS Command Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 269CNS Command On-line Help . . . . . . . . . . . . . . . . . . . . . 273

Appendix A. Customer Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275Electronic support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275Telephone support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276Customer support locations and numbers . . . . . . . . . . . . 276Incident documentation. . . . . . . . . . . . . . . . . . . . . . . . . . 278Ensuring your satisfaction with customer support . . . . . . 278

Contents


List of Figures 9

FIGURE 1. Start Process Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39FIGURE 2. Stop Process Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44FIGURE 3. Recovery Process Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51FIGURE 4. RCF Command Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108FIGURE 5. MCF Command Syntax. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173FIGURE 6. CCF Command Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197FIGURE 7. SCF Command Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217FIGURE 8. VTM Command Syntax. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235FIGURE 9. DEV Command Syntax. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252

FIGURE 10. CNS Command Syntax. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269

List of Figures


Preface 11

Preface

About this DocumentThis guide provides instructions on how to use the Integrated Resource Manager (IRM) version 500 Primary Managers.

This guide is directed to the systems operator(s) responsible for using the Integrated Resource Manager. It assumes that you have some previous experience in using mainframe software and knowledge of MVS systems and SMP/E.

PrerequisitesThis guide assumes that AF/OPERATOR, or OMEGACENTER Gateway for MVS, and the Integrated Resource Manager has been SMP/E installed and that maintenance has been applied to bring them up to current levels of service. For information on installing AF/OPERATOR refer to Installing Candle Products on MVS (IC51-6057).

Refer to the AF/OPERATOR and the IRM Configuration and Customization Guides for additional information on installing and configuring AF/OPERATOR and IRM respectively.

P

Adobe Portable Document Format



IntroductionCandle supplies documentation in the Adobe Portable Documentation Format (PDF). The Adobe Acrobat Reader prints PDF documents with the fonts, formatting, and graphics as contained in the original document. To print a Candle document, perform the following:

1. Specify the print options for your system. From the Acrobat Reader Menu bar, select File > Print Setup... and make your selections. A setting of 300 dpi is highly recommended as is duplex printing if your printer supports it.

2. To start printing, select File > Print on the Acrobat Reader Menu bar.3. On the Print popup, select one fo the Print Range options for:

– a single page

– a range of pages

– all of the document

(Optional)

4. To fit oversize pages to the paper size currently loaded on your printer, select the Shrink to Fit option.

Printing problems?Your printer usually determines the print quality of your output. Sometimes printing problems can occur. If you experience printing problems, potential areas to check are:

� settings for your printer and printer driver. (The 300 dpi settings for both your driver and printer should be the same. A setting of 300 dpi is recommended.)

� the printer driver you are using. (You may need a different printer driver or the Universal Printer driver from Adobe. This free printer driver is available at www.adobe.com.)

Preface 13


� the halftone/graphics color adjustment for printing color on black and white printers. (Check the printer properties under Start > Settings > Printer. For more information, see the online help for the Acrobat Reader.)

� the amount of available memory in your printer. (Insufficient memory can cause a document or graphics to fail to print.)

For additional information on printing problems, refer to the documentation for your printer or contact your printer manufacturer.

Documentation Conventions



IntroductionCandle documentation adheres to accepted typographical conventions for command syntax. Conventions specific to Candle documentation are discussed in the following sections.

Panels and figuresThe panels and figures in this document are representations. Actual product panels may differ.

Revision barsRevision bars (|) may appear in the left margin to identify new or updated material.

Variables and literalsIn examples of command syntax, uppercase letters are actual values (literals) that the user should type; lowercase letters are used for variables that represent data supplied by the user. Default values are underscored.

LOGON APPLID(cccccccc)

In the above example, you type LOGIN APPLID followed by an application identifier (represented by cccccccc) within parentheses. The number of characters indicates the maximum allowable length of the variable.

Note: In ordinary text, variable names appear in italics.

Preface 15


SymbolsThe following symbols may appear in command syntax.

Table 1. Symbols

Symbol Usage

| The ‘or’ symbol is used to denote a choice. Either the argument on the left or the argument on the right may be used. For example:

YES | NO

In this example, YES or NO may be specified.

[ ] Denotes optional arguments. Those arguments not enclosed in square brackets are required. For example:

APPLDEST DEST [ALTDEST]

In this example, DEST is a required argument and ALTDEST is optional.

{ } Some documents use braces to denote required arguments, or to group arguments for clarity. For example:

COMPARE {workload} -

REPORT={SUMMARY | HISTOGRAM}

The workload variable is required. The REPORT keyword must be specified with a value of SUMMARY or HISTOGRAM.

_ Default values are underscored. For example:

COPY infile outfile -

[COMPRESS=YES | NO}]

In this example, the COMPRESS keyword is optional. If specified, the only valid values are YES or NO. If omitted, the default is YES.

b The symbol b indicates a blank space, when needed for clarity.

Documentation Set


Documentation Set

IntroductionCandle provides a complete set of documentation for the Integrated Resource Manager. Each manual in this documentation set contains a specific type of information to help you use the product.

Candle welcomes your comments and suggestions for changes or additions to the documentation set. A user comment form, located at the back of each manual, provides simple instructions for communicating with Candle's Information Development department. You can also send email to [email protected]. Please include the product name, version, and book title in the subject line. To order additional manuals, contact Candle Customer Support.

Online DocumentationAll documents in the Integrated Resource Manager documentation set are available online.

Printed documentationThe documentation listed in the following table is available for the Integrated Resource Manager. To order additional product manuals, contact your Candle Support Services representative.

Preface 17

Documentation Set

Table 2. Integrated Resource Manager Documentation

DocumentNumber

Document Name Description

AU51-6292 Integrated Resource Manager Configuration and Customization Guide

Explains how to configure and customize the Integrated Resource Manager after it is installed.

AU54-6514 Integrated Resource Manager Primary Managers User’s Guide

Provides a task-oriented guide to using the Integrated Resource Manager. Explains basic features and navigation methods for the Primary Managers.

AU54-6296 Integrated Resource Manager Control Managers User’s Guide

Provides a task-oriented guide to using the Integrated Resource Manager. Explains basic features and navigation methods for the Control Managers.

AU54-6295 Integrated Resource Manager AF/OPERATOR and Subsystem Managers User’s Guide

Provides a task-oriented guide to using the Integrated Resource Manager. Explains basic features and navigation methods.

AU53-6591 Integrated Resource Manager Functions and Other Facilities Manual

Provides comprehensive reference information about the features of the Integrated Resource Manager.

AU52-6293 Integrated Resource Manager Messages Manual

Provides a reference summary of all Integrated Resource Manager messages.

AU99-6297 Integrated Resource Manager Command Quick Reference Guide

Quick Reference Handbook that explains the format and parameters for the Integrated Resource Manager console commands

OMC99-4833 Candle Products Program Directory

Provides installation instructions and details all other installation consideration.

Documentation Set


What’s New

W
Summary
This section details the new features and enhancements incorporated into the latest release of IRM Primary Managers User’s Guide Version 500. These changes reflect recent IRM enhancements. Version 500 provides additional support for reporting functionality associated with the Started Task Manager (STM).

The Version 500 enhancements include

� The IRM SYSPLEX implementation introduces new List structures to the Coupling facility. IRM already has an internal dynamically created table for keeping track of the automation tasks under IRM control. The new list structures provide a global status table for all IRM automated tasks in the Sysplex.

� The IRM recovery process has been improved to ensure that all IRM automated tasks recovered by the ARM sysplex recovery will still be under IRM control but can be moved around in the sysplex by the workload manager.

� Prohibited command combinations have been identified for the various managers and these prohibitions have been identified at the beginning of the command syntax tables.

What’s New 19


Started Task Manager 21

Started Task Manager

IntroductionIn the early days of computing, all programs were run as batch jobs. The application took your input data, processed the data, gave new data back in some form of output, and then terminated. As computers and operating systems became more sophisticated, an additional way to run programs came into existence. Called Started Tasks, they differ from batch jobs in that they do not terminate after giving back output. Instead they stay active waiting for another block of data to process. Once a started task is initiated, it will run until it abends or is manually shut down. Started tasks increase data center efficiency because they formed the basis for real time on-line computing.

Chapter ContentsStarted Task Manager Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Resource Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31Started Task Manager Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38User Exits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56Started Task Manager Task Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67Using the Service Subroutines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106Controlling Started Task Manager Resources . . . . . . . . . . . . . . . . . . . . . 107STM Reporting Function. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137RCF Command On-line Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

1


The Problem

It is easy for data center personnel to define when a started task should be running and to define what the status of other system programs and hardware must be for that task to run properly. Unfortunately, it can be difficult and time consuming to manually check the interdependencies before starting or stopping a task. Even worse is the case where a started task abends during a shift where the people on duty aren't familiar with all the interdependencies.

The advent of sophisticated automation software such as, AF/OPERATOR, allows data center personnel to write their own custom automation programs to manage resources such as started tasks. But this in itself didn't completely solve the problem because many people don't have the time or the desire to write complex automation programs.

The Solution

The Started Task Manager (STM) is an Automation Application running under AF/OPERATOR that manages started tasks without writing automation programs. All you need to do is decide which started tasks (called resources in the rest of this manual) you want to manage with the STM and then define the resources to the STM.


Started Task Manager Components


The STM consists of the following four components:

� Task Definition

� Service subroutines

� AF/OPERATOR system variables

� AF/OPERATOR traps

Task DefinitionThe Automation Application tables are used to define resources to the STM. The STM uses information stored in these tables to manage the resources under its control. All of the tables are members of the Automation Application table dataset, hilev.RKAUTBLR. The tables are created by the user via the IRM ISPF Interface. The interface enables the user to populate the table fields with the appropriate information for each resource. The Started Task Manager Task Definition section beginning on page 67, describes the STM automation tables in detail.

Service SubroutinesThe STM service subroutines are AF/OPERATOR command files used to perform a variety of functions for the resources controlled by the STM:

� Initialize control of a resource

� Start a resource

� Stop a resource

� Cycle a resource

� Recover a resource

� Start/stop resources based on a schedule or multiple schedules

� Issue warning messages before a resource is started or stopped

� Check the state of predecessors prior to starting a resource

� Check the state of successors prior to stopping a resource

� Execute user exits prior to starting or stopping a resource



� Execute user exits after starting or stopping a resource

� Notify users if management of a resource has failed

� Interact with the other Automation Applications, such as the Message Manager, VTAM Manager, or Device Manager, to expand the management of a resource to include messages generated by the resource, VTAM nodes needed by the resource, and MVS devices needed by the resource

� Control where a resource should run and allow for temporary overrides to force a resource onto a system where it does not normally run or except a resource from a system where it does normally run

The service subroutines consist of the following execs:

@RCFBCMP This exec is invoked in batch, via IRXJCL, at the end of the batch stream for a STM resource. It is used to confirm the successful completion of batch for a resource, by triggering @RCFPOST exec.

@RCFBRDY This exec is invoked in batch, via IRXJCL, to post batch ready for the scheduled stop of an STM resource. It is used to confirm the successful completion of a predecessor batch process. This will allow the scheduled stop of an STM resource that waits on Batch Ready to commence.

@RCFBTCH This exec is an external REXX function used by the STM to Perform Batch Submit process for a resource. It is called by @RCFMAIN when requested by function SUBMIT.

@RCFBUSR This exec is invoked in batch, via IRXJCL, to post batch user data for a STM resource.



@RCFINIT This exec initializes the STM Application creating an MVS console command prefix (RCF) that allows you to perform various management functions on a single resource or group of resources, performing clean-up activities by deleting AF/OPERATOR system variables and traps used by the STM the last time it was running, and creating two in-storage tables.

The first table, called @RCFSTAT, is used to maintain various status information for each of the resources the STM controls. The second internal table, @RCFOPTS, is used to maintain option information specified on a call to the STM.

@RCFINIT is also responsible for invoking @RCFMAIN during AF/OPERATOR initialization to either start or re-establish control of all of the resources managed by the STM.

@RCFLHLP This exec displays information for all defined STM Resource Lists. It is called by @RCFMAIN when requested by function DISPLAY LIST LIST=listname.

@RCFMAIN This exec processes STM commands issued to manage resources. @RCFMAIN is responsible for: validating and processing command text, determining if the specified resource is defined to the system, invoking the @RCFDRVR exec to effect changes to the current state of the resource, effecting changes to the control of the resource, and responding to operator inquiries.

@RCFDRVR This exec processes state management functions for the STM. @RCFDRVR performs the actual process for: initializing a resource, starting a resource, stopping a resource, and recovering a resource. @RCFDRVR is invoked asynchronously by @RCFMAIN via a TOD(*) trap. In this way, the STM can process multiple requests simultaneously. A unique thread is established for each resource, so that when a function is requested for a group of resources, multiple threads will be activated and the function will complete for the individual resources as external requirements, such as predecessor relationships, are satisfied.

@RCFHELP This exec provides the STM on-line help facility.



@RCFACTV This exec is an external REXX function used by the STM to determine the current status of a resource. This exec uses the AF/OPERATOR ACTIVE() function in conjunction with the current STM status variable to determine if a resource is active. This exec also accounts for resources that have their own active function, a function other than the AF/OPERATOR ACTIVE() function, as well as, resources that have no active function, such as IPL Only tasks and Sub-tasks.

@RCFCALL This exec is an external REXX function used by other Automation Applications to internally request STM services.

@RCFEXIT This exec is an external REXX function used by the STM to call user exit routines. This allows user exits to be written in either REXX or the AF/OPERATOR Language.

@RCFLACT This exec is an external REXX function used by the STM to check the status of the objects in a STM list.

@RCFPACT This exec is an external REXX function used by the STM to check the status of a STM object on a remote system against a supplied desired state. It checks the state of the P2P link to the remote system. If remote link is active, it will construct WAIT/AFTER parameters for remote active call; execute @RCFPARP REXX exec on the remote system and waits for a WTO indicating status of request; return result of remote active call to the caller. If the remote link is not active it will issue a WTO and exit.

@RCFPARP This exec is called by @RCFPACT to return the status of a STM object on this system to the calling remote system.

@RCFPMON This exec is called by @RCFDRVR to stop the STM OMEGAVIEW Status Monitor function. This exec is used as a pre-recovery exit to suspend OMEGAVIEW status updates during recovery of the OMVIEW logon function.

@RCFP2PC This exec is an external REXX function used by the STM to Process a call to the STM on a remote system. It checks the state of the P2P link to the remote system. If remote link is active, it will process remote STM call by constructing the RCF command to be issued; constructing the command verification messages; issue the command on the remote system and wait for response. If the remote link is not active it will issue a WTO and exit.



@RCFPOST This exec is called by the STM Initialization Trap (@RCFPST#). It performs the Batch Complete process for a resource by: updating the Batch Complete status file for later use; checks for Batch Not Complete WTOR & clears if found; if the task is to start immediately, it will start it now; if confirmation is requested, it will reply to outstanding WTOR.

@RCFPRDY This exec is called by the STM Initialization Trap (@RCFRDY#). It will update the Batch Ready status file for later use and check for Batch Not Ready WTOR & clear if found.

@RCFPUSR This exec is called by the STM Initialization Trap (@RCFUSR#). It will update the Batch User Data status file for later use.

@RCFREAD This exec is an external REXX function used by the STM to read the specified STM Batch Status file and return the value of the record.

@RCFRPLY This exec is called by @RCFDRVR and @RCFPOST to automatically reply to any related WTOR's.

@RCFSCHD This exec is an external REXX function used by the STM to process schedules for those resources that run on a schedule. @RCFSCHD is used to set and change event traps for a resource schedule, as well as, determine whether or not a resource should be active according to its schedule.

@RCFQSCH This exec is an external REXX function used by the STM to query selected schedule information for a resource that runs on a schedule.

@RCFSACT This exec is called by either @RCFMAIN, @RCFDRVR, or @RCFSSTS to execute the STM active function on the remote system and returns the status to the originating system.

@RCFSDEL This exec is an external REXX function used by the STM to delete details for the Sysplex Status or ARM table entries for a specified object on a given irmid.

@RCFSGET This exec is an external REXX function used by the STM to Get the details for the Sysplex Status or ARM table entries for a specified object on a given irmid.

@RCFSETS This exec is an external REXX function used by the STM to update status information held in the @RCFSTAT in-storage table.



@RCFSMON This exec is called by @RCFDRVR to start the STM OMEGAVIEW Status Monitor function. This exec is used as a post-start exit to start the OMEGAVIEW status updates after a successful OMVIEW logon.

@RCFSPUT This exec is an external REXX function used by the STM to Put details for the Sysplex Status or ARM table entries for a specified object on a given irmid.

@RCFSSTS This exec is called by @RCFDRVR to perform an active state check for remote predecessors.

@RCFSSTP This exec is called by @RCFDRVR to execute the STM command on the remote system and return the result to the originating system.

@RCFSTAT This exec is an external REXX function used by the STM to retrieve selected status information for a resource.

@RCFSTCR This exec is an external REXX function used by the STM to create an Omegaview status item for a STM object. It is called by @RCFMAIN when requested by function STCREATE.

@RCFSTDS This exec is an external REXX function used by the STM to delete an OMEGAVIEW status item for a STM object. It is called by @RCFMAIN when requested by function STDESTROY.

@RCFSTLS This exec is an external REXX function used by the STM to close an OMEGAVIEW status item for a STM object. It is called by @RCFMAIN when requested by function STCLOSE.

@RCFSTUP This exec is an external REXX function used by the STM to update an OMEGAVIEW status item for a STM object. It is called by @RCFMAIN when requested by function STUPDATE.

@RCFSUCC This exec is an external REXX function used by the STM to determine the successors to a resource. @RCFSUCC creates a successor name list by interrogating the predecessor information for all defined objects looking for references to the supplied resource name.

@RCFSUPD This exec is an external REXX function used by the STM to update the status information for a Started Task Manager object.

@RCFSYSV This exec is called by @RCFINIT to cleanup unneeded AF/OPERATOR system variables related to the STM resources during initialization.



AF/OPERATOR System VariablesThe STM creates the following AF/OPERATOR system variables to track resource status over time:

@RCFWRIT This exec is an external REXX function used by the STM to update the specified STM Batch Status file with the specified new record value.

@RCFWTOR This exec is called by any Message Manager Trap (@######Q) to capture STM commands delivered via WTOR and invoke the STM to process the command and returns the result of the command by replying to the WTOR.

@RCFXNBS This exec is called by @RCFDRVR to bypass batch process for a STM resource if in a global no-submit window defined by the @RCFXNBS system variable via the @RCFsmfd parmlib member.

@R####B Task Start Verification Flag

@R####D Task Stop Verification Flag

@R####F Task Checkpoint Flags

@R####I Task IPL Status

@R####J Task JCL Errors

@R####N Task Name

@R####Q Task Queue Lock

@R####RA Task Recovery - ASID

@R####RD Task Recovery - Date

@R####RT Task Recovery - Time

@R####RM Task Recovery - Msgid

@R####RX Task Recovery - Text

@R####T Task Start Time

@R####Sn Task Schedule Start Upd(1-5)

@R####Pn Task Schedule Stop Upd(1-5)

@R####Un Task Schedule Start Upd(6-10)



AF/OPERATOR TrapsThe STM creates the following AF/OPERATOR traps to manage the resources under its control:

@R####Vn Task Schedule Stop Upd(6-10)

@R####Wn Task Schedule Start Upd(11-15)

@R####Xn Task Schedule Stop Upd(11-15)

@R####Yn Task Schedule Start Upd(16-20)

@R####Zn Task Schedule Stop Upd(16-20)

@R####Q Task Driver

@R####Bn Task Start Verification Flag

@R####Cn Task Start Verification WTOR

@R####Dn Task Stop Verification Flag

@R####En Task Stop Verification WTOR

@R####Fn Task Predecessor WTOR

@R####Gn Task Successor WTOR

@R####Jn Task Start Command JCL Errors

@R####Mn Task MVS Command Intercept

@R####Rn Task Recovery

@R####RR Task Recovery Reset

@R####Sn Task Scheduled Start (1-5)

@R####Pn Task Scheduled Stop (1-5)

@R####Un Task Scheduled Start (6-10)

@R####Vn Task Scheduled Stop (6-10)

@R####Wn Task Scheduled Start (11-15)

@R####Xn Task Scheduled Stop (11-15)

@R####Yn Task Scheduled Start (16-20)

@R####Zn Task Scheduled Stop (16-20)


Resource Management

Resource Management

The first goal in managing a resource is to determine where the resource is meant to run. This can be a significant task in a multi-center, multi-image environment especially if a moderate to large number of resources are to be managed. Where a resource is meant to run must be defined to the STM in such a way that it is easy to create and maintain the information, but still flexible enough to allow for each resource to be defined to each individual system.

The STM accounts for the inevitable complexity of maintaining resource definitions for an environment in two ways. First, the STM has been designed to control all of the started tasks for an environment from a single set of Automation Application tables. Using a single set of tables greatly reduces the effort involved in maintaining accurate information. The flexibility needed to adequately describe multiple systems in one table, necessitates the second design feature built into the STM, which is the variety and diversity of controls used to define a resource to a system.

Resources can be defined to a system by keyword groups, workload groups, or by identifying specific SMF or CPU IDs of systems where a resource is defined to run. A facility has also been included to except resources from running on certain systems that undesirably fall into the grouping mechanisms, since all does not necessarily mean ALL always and everywhere.

Defining a ResourceA resource can be defined to a system by one or more of the following mechanisms:

Keyword Group

The KEYWORD is used to define resources associated with one of the global grouping categories. Categories are:

� ALL

� AUTO

� NONE

� MANUAL

Resource Management


� TWOPASS

� INTERNAL.

See, Started Task Manager Task Definition - Control Data on page 70 for more information on the Keyword groups.

Workload Groups

Workload grouping works in conjunction with the system definition described in the System Description section of the IRM Control Managers User’s Guide (Candle Document AU54-6515). If the system variable for the group and the resource variable for the group match, the resource will be managed. There are six controls for manipulating resources by workload groups. These controls are:

XRF Grouping mechanism that identifies whether a resource is defined to a system. If the system is defined as an IMS/XRF active system, any resource identified as ACT by the XRF Workload Field will be managed. Similarly, if the system is defined as an IMS/XRF alternate system, any resource identified as ALT by the field will be managed. Valid values are: ACT Specifies that the resource is to be initialized on any IMS/XRF active system. ALT Specifies that the resource is to be initialized on any IMS/XRF alternate system.

JES Grouping mechanism that identifies whether a resource is defined to a system. If this system is defined as a JES3 Global system, any resource identified as GLB by the JES Workload Field will be managed. Similarly, if the system is defined as a JES3 Local system, any resource identified as LCL by the field will be managed. Valid values are: GLB Specifies that the resource is to be initialized on any JES3 Global processor. LCL Specifies that the resource is to be initialized on any JES3 Local processor.

MSn Grouping mechanism that identifies whether a resource is defined to a system. MS1 - MS4 are four user assigned workload grouping fields. If the user assigned system definition for the MSn Workload and the MSn Workload Field matches, the resource will be managed.


Resource Management

Specific Definition

A task can also be specifically defined to a system by including the SMFID or CPUID of the target system in the appropriate list for the resource.

Defining an Exception

The exception list is meant to account for those resources that almost fit into a group. For instance, if you have a resource that runs on every system except for one, you can still define the resource with a KEYWORD of ALL if you include the SMF ID of the one troublesome system in the exception list for the resource. In this example, the resource would start on every system except for the system in the exception list. Exception list processing is separate from the definition process. Any resource can be excepted through the exception list regardless of the source of the definition.

CPUID Allows the user to specifically define up to 12 unique CPUIDs where the resource is meant to run. If the resource does not fit into any resource grouping as previously described, you can code the individual CPUIDs of the systems where the resource is to be managed. NOTE: A CPUID can be entered as either the full six character CPUID, the right-most five characters, or just the right-most four characters of the CPUID for those resources that are not LPAR dependent.

SMFID Allows the user to specifically define up to 24 unique SMFIDs where the resource is meant to run. If the resource does not fit into any resource grouping as previously described, code the individual SMFIDs of the systems where the resource is to be managed. NOTE: If you have not specified the resource in any of the previous workload groups, an SMFID must be specified in order to manage the resource. If an SMFID is not coded, the resource will not be managed anywhere.

EXCEPT Allows the user to exclude up to 24 unique SMFIDs where the resource is not meant to run. If the resource fits into a resource grouping except for a couple of systems, include the resource in the group and code the individual SMFIDs of the systems that are exceptions in the EXCEPT fields.

Resource Management


Dynamic ControlsThe STM allows for control information to be dynamically altered via operator commands. If a resource needs to run on a system where it does not normally run, it can be brought onto that system by issuing an RCF INIT command with the Force option.

Note: Forcing a resource onto a system where it does not normally run, assumes that all of the installation requirements for the resource have been met on the new system. This means that the resource is capable of running on the system, but that it does not normally run there by the choice of the user and not for technical reasons.

Resources can also be temporarily excepted from running on a system by issuing an RCF EXCEPT command. Issuing this command informs the STM that the resource is no longer defined to a system. Once this command has been issued, the STM will no longer attempt to manage the resource on that system.

Resource ListsAnother of the dynamic controls offered by the STM is the ability to manipulate a group of resources via a resource list. A resource list is simply a named list of STM objects created by the user. When invoked to process a resource list, the STM translates the list name into the resource names that have been defined to the list.

Resource lists can include any object known to the STM including other resource lists. They are created by the user via the IRM ISPF User Interface Main Panel Option 2.

Resource lists can be a convenient way of manipulating known groups of resources. One STM list command can take the place of many individual commands needed to start or stop a set of resources.


Resource Management

Checkpoint RestartIf a resource definition is altered dynamically, the change to the resource definition will be checkpointed by the STM. In the event that AF/OPERATOR or the system itself should fail, the STM has the ability to perform a checkpoint restart to resume where the resource failed.

During a checkpoint restart, all dynamic alterations to the resource definitions will be re-established from checkpointed AF/OPERATOR system variables. Therefore, resources that have been forced onto the system will continue to be managed and resources that have been excepted from the system will continue to be bypassed by the STM management routines.

Resource Manipulation LockThe STM now has a resource manipulation lock for each resource. The manipulation lock purpose is to allow only one function to be active for a task at a time to prevent unintentional errors when manipulating a resource. This prevents multiple recovery processes to be active at once, the simultaneous processing of a start and stop command, and the simultaneous processing of two start/stop commands.

Queueing a Function RequestThe STM is capable of processing multiple function requests for a resource by queuing requests. If more than one function is required to manipulate a resource, the function request can be intentionally queued against a resource by using the Queue option of the RCF command.

The Queue option causes the request to be postponed, if another function is active, until the previous function completes and the queued request can acquire the resource manipulation lock. Queued requests are processed in First-In First-Out order.

Waiting for a Function to CompleteSince state changes to resources are processed asynchronously by the STM, the standard return code for a function request that involves a state change indicates only that the request has been accepted and scheduled, not that the request has been successful. In certain situations, especially in the case of internal service calls, the outcome of the state change needs to be verified.

Resource Management


Using the Wait option on the function request, will cause the STM main routine to wait for verification of the asynchronous processes before returning to the caller. The eventual result of the function is communicated to the caller via the return code for the call. Return codes are:

The Force OptionThe Force option of the RCF command is a powerful tool built into the STM. The Force option can be used to force a resource onto a system where it does not normally run, as well as, bypass any or all of the safeguards built into the STM resource management routines when manipulating a resource. The Force option should be used with care because of the implications of bypassing all of the resource management safeguards. The Force option:

� Forces a resource onto a system where it does not normally run

� Cancels any outstanding STM function requests for the resource

� Bypasses Predecessor checks when starting a resource

� Bypasses VTAM Dependency checks when starting a resource

� Bypasses Successor checks when stopping a resource

� Bypasses IPL Checks for IPL Only tasks

� Ignores Abort/Bypass return codes from a pre-start or pre-stop user exit

Problem Notification

Notification List

Any time a STM function for a resource fails, you can be notified of the event. The STM has the capability of sending a notification message to a list of users, identified by TSO userid, any time a resource manipulation function fails. See the Started Task Manager Task Definition - Problem Notification on page 94 for more information on defining a notification list.

0 Indicates that the function request was successful.

8 Indicates that the function did not complete successfully within the indicated time limit.


Resource Management

Notification CFile

The STM also has provided a user exit to augment the basic notification process. This exit will be called any time a problem is encountered while manipulating a resource. To help you create this exit, the STM creates two AF/OPERATOR global variables, named @RNAME and @RFUNC, which contain the name of the resource and the name of the function that failed.

Note: For compatibility with previous releases of the STM, the failing resource name is also stored in the RNAME global variable.

Resource Management LimitationsThe STM can manage only those resources that have been specifically defined to it. Stated another way, it can only keep track of the resources it starts and stops. The STM is not aware of resources started with any other job scheduler, resources started via COMMND00, or resources started manually at a system console.

For example, assume that for a given resource defined to the STM (Task A), one attribute is that a different resource (Task B) must already be running. In this case, Task B is known as a predecessor. If Task B had been started manually from a console, when the STM attempts to start Task A it will fail. This happens because the STM has no record of the predecessor, Task B, being started. Therefore, when planning your implementation of the STM, make sure that all interdependent resources are defined to and controlled by the STM.

Started Task Manager Functions



After understanding the various pieces of the STM, you must understand how the STM functions are used to manage your resources.

The following sections describe the basic services provided by the STM:

� The Initialization Process

� The Start Process

� The Stop Process

� The Warning Process

� The Schedule Process

� The Cycle Process

� The Kill Process.

The Initialization ProcessFor each resource that is defined to a system, the STM invokes an initialization process that defines an environment for the resource. Specifically, during initialization of a resource the STM will:

� Delete all previously defined AF/OPERATOR traps related to the resource.

� Define the AF/OPERATOR system variables used to manage the resource. This includes the variable used for the resource manipulation lock.

� Add a TOD event trap to reset the recovery retry count for the resource. The trap is set with an initial time of 00:00:01, a user defined interval, and an action which invokes the STM to reset the retry counter back to zero.

� Set the command traps if native MVS commands are to be captured and processed by the STM.

� Process schedules for the resource if the resource is defined to run on a schedule. All TOD event traps for the resource's schedules are set at this time.

� Start or stop the resource, if applicable. Once the resource has been initialized, the STM can perform any of its management functions for the resource.



The Start ProcessAfter the STM determines that a resource is defined to a system, it will invoke the @RCFDRVR routine asynchronously, via a TOD(*) trap, to start the resource. The following graphic provides an overview of the Start process.

FIGURE 1. Start Process Overview

Invoke @RCFDRVRvia TOD(*) trap

Check task status, Ifalready active, return.

Check table data, setjobname, job type, sys

name,

Delay start of task untilall Predecessors are

active.

Delay start of task untilall VTAM

dependancies areactive.

A

A

Process managerinterfaces

Add recovery traps(disabled)

Process startcommand override

Prepare startcommand wait.

Issue start command,check results

User start commandfile. Report non-zero

return codes.

Recovery traps. Enableif successful, disable if

not.

B

B

Process Post-Startmanager interfaces.

Set current status.Start at IPL only?

Batch interface?

Pre-Start exit?

Post-Start Exit?

Task Monitor exit?



The following sequence of events takes place when starting the resource:

1. The current state of the resource is checked. If the resource is already active, the STM resets its status for the resource and returns.

2. If a predecessor has been defined for the resource, the STM will check if a Predecessor Exit has been specified. If an exit exists, the STM will execute this exit and, depending on the return code, the STM will continue. Refer to page 64 for more information on the Predecessor Exit. If the resource has no predecessors or if all of the defined predecessors are active, the STM will continue. If the resource’s predecessors are not active, STM will wait and recheck the state(s) of the predecessor(s) at a user defined retry interval. When the STM finds all of the predecessors to the resource active, it will continue the start process. If the user defined wait interval should expire before all of the predecessors are active, the STM will display the following WTOR on the system console:ASOA070W taskname cannot be started PREDECESSORS are not active

nn ASOA070A taskname Reply A to Abort, I to Ignore, or L to List

The following actions are taken based on the operator reply:

ASOA070W taskname cannot be started PREDECESSORS are not active

nn ASOA070A taskname Reply A to Abort, I to Ignore, L to List, or S to Start inactive predecessors

3. If a VTAM dependency has been defined for the resource, the STM will check if a VTAM Dependency Exit has been specified. If an exit exists, the STM will execute this exit and return when complete. Refer to page 66 for more information on the VTAM Dependency Exit. The STM will then

A The start process will be aborted and the resource will remain inactive.

I The STM will ignore any of the predecessors that are not yet active and proceed to start the resource.

L The STM will list those predecessors that are not yet active and then re-display the WTOR with an additional option of S as shown below.

S The STM will issue an ‘RCF START taskname’ for all of the predecessor tasks that are not active.



check the state of each of the VTAM nodes specified for the resource. If all of the VTAM nodes are active, the STM will continue. If all of the nodes are not active, the STM will wait and recheck the states of the nodes at a user-defined retry interval. When the STM finds all of the VTAM nodes active or contactable, it will continue the start process for the resource. If the user-defined wait interval should expire before all of the nodes become active, the STM will display the following WTOR on the operator console:ASOA110W task cannot be started VTAM RESOURCES are not active

nn ASOA110A task Reply A to Abort, I to Ignore, or L to List

This gives the operator the chance to manually activate the VTAM nodes needed by the resource before allowing the start process to continue. The following actions are taken based on the operator reply:

ASOA110W taskname cannot be started VTAM RESOURCES are not active

nn ASOA110A taskname Reply A to Abort, I to Ignore, L to List, or V to Vary resources active


I The STM will ignore any of the nodes that are not yet active and proceed to start the resource.

L The STM will list those nodes that are not yet active and then re-display the WTOR with an additional option of V as shown below.

V The STM will issue an ‘V NET,Act,ID=vtamnode’ command for all of the specified VTAM dependencies.



4. If the resource has been defined as an IPL only task, (for example; a task that is initiated once at the IPL to set hooks and end), the STM will check the last IPL marker it created for this resource. If the system has been IPL'ed, the STM will reset its IPL marker for this resource and continue. If the system has not been IPL'ed, it will issue the following WTO on the system console.ASOA110A RCF has already enabled taskname at the last IPL

ASOA110A RCF Specify ‘START task FORCE’ to execute task again

5. If the Batch Interface has been enabled, the STM will check to see if a Batch Check Exit is specified. If an exit exists, the STM will execute this exit and return when complete. If the batch interface determines that the batch has not been completed the following WTOR will be issued on the system console:ASOA838W taskname cannot be started BATCH COMPLETE not confirmed

ASOA838W taskname Reply A to Abort or C to Continue start-up


6. If a Pre-Start Exit has been specified, the STM will execute the exit and return when complete. Refer to page 57 for more information on the Pre-Start Exit.

7. If any of the interfaces to the other Automation Applications have been enabled, the STM will internally call that application and request the objects it controls, that are associated with the STM resource be enabled.

8. The WTO recovery traps for messages IEF450I, IEF404I, IEF402I, and up to three additional user-defined recovery traps are added in a disabled state in preparation for a successful start of the resource.

9. If a dynamic start command override exists, it is processed for this start only.


C The start process will continue.



10. The start command is used for the resource. Four WTO traps for messages IEF452I, IEF453I, IEFC452I, and IAT6815 (JES3 only) are added to trap any JCL errors that may occur.

11. The STM waits for the start verification message. If the start verification message is not received within the user-defined wait time limit, the STM will execute the exit and return. Refer to page 59 for further information on the Start-WTOR exit. Depending on the return code of the Start WTOR exit, the STM will issue the following WTOR on the system console:ASOA076W taskname start verification message not received

00 ASOA076A taskname Reply A to Abort or U when resource active


12. If the START was successful:A. All Recovery Traps previously added are enabledB. If a Monitor Exit is specified, STM executes this exec and returns.C. If a Post-Start Exit exists, the STM will execute that exec. Refer to page

58 for further information on the Post-Start Exit.D. The resource status is set to ACTIVE.E. The start time for the resource is saved.F. The STM completes with a zero return code.

13. If the START was unsuccessful:A. Recovery Traps are DeletedB. Automation Applications interfaces are called to disable the objects

related to the STM resourceC. The STM completes with a non-zero return code

A The start process will be aborted and the STM will flag the resource as START ABORTED.

U The STM will consider the resource active.



The Stop ProcessWhen the STM receives a stop command for a resource, it will invoke the @RCFDRVR routine asynchronously, via a TOD(*) trap, to stop the resource. The following graphic provides an overview of the stop process.

FIGURE 2. Stop Process Overview

Invoke @RCFDRVR viaTOD(*) trap

Check task status, Ifalready inactive, return.

Check table data, setjobname, job type, sys

name,

Delay stopt of task untilall successors are

inactive.

A

A

Disable recovery traps.

Process stop commandoverride

Prepare stop commandwait.

Issue stop command,check results

User stop commandfile. Report non-zero

return codes.

Recovery traps. Deleteif successful, enable if

not.

B

Set current status.

Process Post-Stopmanager interfaces.

Pre-Stop exit? Post-Stop Exit?

Batch interface?

Batch interface?

Task Monitor Exit

B



The following sequence of events takes place when stopping the resource:

1. The current state of the resource is checked. If the resource is already inactive, the STM resets its status for the resource and returns.

2. If the Batch Ready Exit has been specified, the STM will execute this exit and, depending on the return code, the STM will continue with the stop process. If the Batch Interface determines that the Batch processing related to the resource has not yet completed, the STM will issue the following WTOR on the system console:ASOA840A taskname cannot be stopped BATCH READY not confirmed

nn ASOA840W taskname Reply A to Abort or C to Continue shutdown


3. If a successor has been defined for the resource, the STM will check if a Successor Exit has been specified. If an exit exists, the STM will execute this exit and, depending on the return code, the STM will continue with the stop process. Refer to page 65 for more information on the Successor Exit. The state of each of the resource’s successors is checked. If the resource has no successors, or if all of the defined successors are inactive, the STM will continue. If the resource’s successors are active, it will wait and recheck the states of the successors based on a user-defined retry interval. When the STM finds all of the successors to the resource inactive, it will continue the stop process. If the user-defined wait interval should expire before all of the successors are inactive, the STM will display the following WTOR on the system console:ASOA070W taskname cannot be stopped SUCCESSORS are still active

nn ASOA070W taskname Reply A to Abort, I to Ignore, or L to List

A The stop process will be aborted and the resource will remain active.

C The STM will bypass the Batch Ready warning and continue with the stop process.




ASOA070W taskname cannot be stopped SUCCESSORS are still active

nn ASOA070W taskname Reply A to Abort, I to Ignore, L to List, or S to Stop active successors

4. The user-defined Pre-Stop Exit is invoked. If the exit does not abort or bypass the stop of the resource, the STM will continue the stop process. Refer to page 60 for further information on the Pre-Stop Exit.

5. Recovery traps are disabled.6. If a dynamic stop command override exits, it is processed for this stop

only.7. The STOP command for the resource is issued.

The STM waits for the stop verification message. If the stop verification message is not received within the user-defined wait time limit, the STM will execute the STOP WTOR exit if it exists. The STM will execute the exit and return. Refer to page 63 for further information on the Stop-WTOR Exit. Depending on the return code of the Stop-WTOR exit, the STM will issue the following WTOR on the system console:

ASOA076W taskname stop verification message not received

00 ASOA076A taskname Reply A to Abort or U when resource is down

A The stop process will be aborted and the resource will remain active.

I The STM will ignore any of the successors that are not yet inactive and proceed to stop the resource.

L The STM will list those successors that are not yet inactive and then redisplay the WTOR with an additional option of S as shown below.

S The STM will issue an ‘RCF STOP taskname’ for all of the successor tasks that are still active.




8. If the STOP was successful:A. Recovery Traps are deleted.B. If a Post-Stop Exit exists, the STM will execute that exec. Refer to page

62 for further information on Post-Stop Exit.C. If Batch interface is enabled, the STM will submit the batch ready job.D. The resource status is set to INACTIVE.E. The start time for the resource is deleted.F. Automation Applications interfaces are called to disable the objects

related to the STM resource.G. The STM complete with a zero return code.

9. If the STOP was unsuccessful:A. Recovery Traps are enabled.B. The STM completes with a non-zero return code.

A The stop process will be aborted and the STM will flag the resource as STOP ABORTED.

U The STM will ignore the STOP verification message and flag the resource as STOPPED.



The Warning ProcessWhen a resource runs on a schedule and either stop or start warning has been enabled, the STM will inform the operator of the impending event. The warning process proceeds as follows:

1. The current state of the resource is checked. If the resource is already in the desired state, the STM resets its status for the resource and returns.

2. A message will be displayed on the operator console, warning of the impending event.ASOA086W task is scheduled to be STARTED at time

ASOA086W task is scheduled to be STOPPED at time

3. If warning extension has been enabled, a WTOR will also be displayed on the operator console. The following actions are taken based on the operator reply:00 ASOA087A task Reply A to Abort, E(mm) to Extend, or C to Continue

4. Once the warning interval expires, the appropriate schedule process will be called to start or stop the resource.

A The process will be aborted and the resource will remain in its current state.

E(mm) The warning interval will be extended mm minutes and the WTOR will be re-displayed. The minutes argument can be entered as either a positive or negative number (-3). If a negative extend time is entered which is less than the remaining warning interval, the resource will be started/stopped immediately.

C The start/stop process will continue immediately.



The Schedule ProcessThe sole purpose of the schedule process is to account for those resources that run on a schedule with calendaring. If the schedule for the resource has calendaring enabled, the calendar variable for the schedule will be checked to determine if the schedule is active in conjunction with the calendar.

If the calendar is active, the resource will be started or stopped. If the calendar is disabled the schedule event will be bypassed. The calendaring feature accounts for those tasks that run on schedules related to business days, weekends, holidays or any other calendar event.

If the schedule does not have calendaring enabled, the requested process proceeds uninterrupted.

Schedules without calendaring do not account for calendar events, only specific times and days of the week.

The Cycle ProcessThe Cycle process is used to bounce a resource. The cycle process first invokes the Stop process to stop the resource. After confirming that the resource is inactive, the Start process is called to restart the resource.

The Kill ProcessThe Kill process is used to stop a task via an MVS Cancel command. The standard stop command for the task is temporarily replaced with an MVS Cancel command and the stop verification message is replaced by the MVS message ID, IEF450I. After the process completes, the standard stop command and verification message are restored.

The Kill process is only valid for MVS Started Tasks, and then, only if the process has been enabled for the resource. For additional information, refer to Started Task Manager Task Definition - MIscellaneous Control Data on page 94. The Kill process will only work for those started tasks that are cancellable.



Recovery ProcessSo far, you've learned that the STM can be used to start and stop resources and you've been given a brief description of the components responsible for managing your resources. Now we move on to one of the features that truly distinguishes the STM, the Recovery Process.

The STM contains a very flexible and powerful recovery process which is used to detect and restart failed resources. Broad controls are built into the recovery process so that the user can customize task recovery for their site and for individual tasks.

In order for you to fully exploit the recovery process, you should read the following sections carefully to understand how the process works.

Events That Trigger Recovery

The recovery process comes into play only if a resource becomes inactive during a time period when it should be active. The STM determines whether such an event has occurred by constantly watching for up to six different MVS/JES messages. The first three messages are straightforward and apply to active resources that suddenly become inactive. The rest are more flexible and can be used for a variety of situations. You specify the messages when defining the recovery options for a resource as described in Started Task Manager Task Definition - Recovery on page 84. The messages are:

Abend Message

This signals that a resource has abended.

Cancel Message

This signals that a resource has been cancelled.

End Message This signals that a resource has terminated. While this is not normally a problem in itself, it is a problem if it happens during a time span when the resource should be active.

User DefinedMessages

These three messages signal any event that should cause the STM to initiate the recovery process for the resource. These messages are optional.



The Recovery Flow

The following graphic illustrates the flow of events during the recovery process:

FIGURE 3. Recovery Process Flow

A recoverytrigger

message isreceived

Problem Exitexists?

Execute Problem Exit

Retry limitexceeded?

YES

YES

NO

Operator replyExit and set resource

status to 'recoveryaborted'

A

Issue Recovery retryWTOR

Increment the retry limitcounter

NO

C

Pre-Recovery exitexists?

execute Pre-RecoveryExit

YES

Issue recovery inprogress WTO

NO

Exit Return Code

Restart the resource

A

Issue one of thefollowing WTO's basedon RC:4 = overridden8 = aborted12 = bypassed16 = cancelled

0

4, 8, 12, 16

Post-Recoveryexit?

Execute Post-RecoveryExit

YES

Exit Return Code

A

Issue Recoverycomplete WTO

NO

0

User defined process

RC > 0

Exit



As you examine the diagram, be aware of the following notes:

� Some of the decision boxes check for true/false conditions, others for return codes from a command file, and others for operator replies.

� The retry counter is a mechanism that tracks the number of recovery retries attempted during a given period. It is reset to zero once at the beginning of each retry time period; it is not reset to zero every time the recovery process is initiated by one of the recovery trigger messages.

For example, if a retry counter for a resource is set to allow no more than two recoveries in an hour, and the resource abends three times in an hour, the STM will not automatically recover the resource for the third abend message. Instead, a WTOR will be displayed by the STM, asking the operator if they wish to allow another recovery attempt. If the operator responds Continue (C), the recovery process will continue. If the operator responds Abort (A), the extra recovery attempt will be halted and the resource will remain inactive.

� The STM attempts to initiate the recovery process every time it encounters one of the recovery trigger messages described earlier. This can pose a problem when a resource abends, because MVS will issue two of the recovery trigger messages for an abend: the message signifying the abend (IEF450I) and the normal end message (IEF404I). Since the STM interprets each of these messages as a separate event, the recovery process will be triggered twice.

This is no longer a problem for the STM, because of the resource manipulation lock. The first triggering event, the abend message, will initiate the recovery process which will establish the manipulation lock for the resource. The second event, the end message, will not execute the recovery process because the resource manipulation lock is held by the first event.

� The command files that are executed at various points of the recovery process are all optional; if you do not define these for a given resource, the STM will still perform a basic restart of the resource. The command files allow you to augment the recovery process with special routines of your own. There are some special variables and return codes associated with each of the command files that will shape the way you design the exit.



Problem Record Command FileThis command file is used to interface with your site's problem management system. To help you do this, the STM service routines create a set of AF/OPERATOR global variables available to this command file in addition to all of the standard AF/OPERATOR global and system variables available to any command file. These variables are:

There are no return codes expected from this command file by the STM recovery process. Note that this command file is executed every time the recovery process is initiated.

Recovery Retry WTORIf the retry process is initiated and the recovery retry count has been exceeded, the STM will issue the following WTOR:

ASOA085W taskname has failed n recovery retries

nn ASOA085A taskname Reply A to Abort or C to Continue and try again

The following actions are taken based on the reply:

PMNAME Contains the name of the resource.

PMASID Contains the ASID of the resource.

PMDATE Contains the date the recovery process for the resource was invoked.

PMTIME Contains the time the recovery process for the resource was invoked.

PMABEND Contains the 8 character message ID that initiated the STM recovery process.

PMMSG Contains the 80 character text of the message that initiated the STM recovery process.

A Will stop the extra recovery attempt.

C Will allow an extra recovery attempt.



Recovery Exit Command FileThis command file gives you the opportunity to perform any action before the STM attempts to restart the resource. To help you develop this exit, the STM service routines create a set of AF/OPERATOR global variables available to the command file.

These variables are:

Depending on the nature of the failure, you may not want the STM to subsequently attempt to restart the resource. To help you use this command file as a decision point in the recovery process, the STM expects a return code from this command file which designates further STM actions as follows:

@RNAME The name of the resource.

@RNUMBER The STM number of the resource.

@RCOUNT The current recovery count for the resource.

@RASID The ASID, address space ID, of the resource.

@RDATE The date the recovery process for the resource was invoked.

@RTIME The time the recovery process for the resource was invoked.

@RABEND The 8 character message ID that initiated the recovery process.

@RMSG The 80 character text of the message that initiated the STM recovery process.

@RSTRTCM The start command for the resource.

@RSTRTIN The start interval for the resource, in the format: HH:MM:SS.

@RSTRTVR The start verification message text for the resource.

0 Indicates that the STM should attempt to restart the resource.

4 Indicates that the STM has overridden the recovery of the resource and issues the following WTO to the system console:

ASOA082I RCF Recovery for taskname overridden by user exit

8 Indicates that the STM has aborted the recovery of the resource and issues the following WTO to system console:

ASOA082I RCF Recovery for taskname aborted by user exit



12 Indicates that the STM has bypassed the recovery of the resource and issues the following WTO to system console:

ASOA82I RCF Recovery for taskname bypassed by user exit

16 Indicates that the STM has cancelled the recovery of the resource and issues the following WTO to system console:

ASOA82I RCF Recovery for taskname overridden by user exit

Other RCs Indicates that the STM should end the recovery process and issue a WTO notifying the operator that the resource has failed and the recovery process has been cancelled.

User Exits


User Exits

Now that you know what the STM can do, it is time to discuss what the STM can not do. The STM can not be designed to handle every situation or user requirement for every resource by itself. Instead, the STM has been designed with a set of user exits at critical decision points allowing external logic to increase STM capabilities in order to meet your needs.

Each exit allows you to alter the processing flow of the STM. If one of your resources needs special attention when a STM function is processed, a user exit can, most likely, fill the need. The exits are processed as part of the STM logic flow; return codes and AF/OPERATOR global variables are used to pass information from the exit to the STM and the information is acted upon accordingly by the STM as it is manipulating the resource.

The following sections describe the STM exits: the variables that are available to the exits and the meaning and purpose of the return codes from the exits.


User Exits

Pre-Start ExitThe STM Pre-Start exit is executed prior to starting a STM resource. Any pre-start user requirements for the resource can be processed in this exit. The exit itself allows you to: alter the start command for the resource, alter the start verification message for the resource, alter the start verification interval for the resource, abort the resource start and bypass the resource start.

The following AF/OPERATOR global variables are supplied to the pre-start exit. At the completion of the exit, these variables are incorporated into the STM start routine as if they had been supplied through the resource's table definitions. Any changes to the contents of the variables must comply with the coding restrictions for the table fields they represent. The variables are always available to the exit, however, it is not necessary to use or change the variables unless needed.

Return codes from the pre-start exit have the following meaning:






0 Indicates that the STM should continue the start process. All AF/OPERATOR global variables previously mentioned will be retrieved and used in-place of the resource information stored in the STM tables for the resource.

4 Indicates that the STM should continue the start process. All AF/OPERATOR global variables previously mentioned will be retrieved and used in-place of the resource information stored in the STM tables for the resource. The information passed in the variables will also be stored in the in-storage copies of the STM tables. These table updates are temporary; lasting only as long as AF/OPERATOR does. The permanent copies of the tables on DASD are not altered.

8 Indicates that the STM should abort the start of the resource. The status for the resource will be set to START ABORTED.

12 Indicates that the STM should simply bypass the start of the resource. The status for the resource will be set to BYPASSED.

User Exits


Post-Start ExitThe STM Post-Start exit is executed after the resource has been successfully started. Any post-start user requirements for the resource can be processed in this exit.

The following AF/OPERATOR global variables are supplied to the post-start exit:

Return codes from the post-start exit have the following meaning:



@RAOCASE The AF/OPERATOR AOCASE variable resulting from the start of the resource. The value of this variable will indicate which of the start verification messages for the resource was received.

0 Indicates that processing was successful.

4 Indicates that processing was unsuccessful. The STM completes with a non-zero return code.


User Exits

Start-WTOR ExitThe STM Start-WTOR exit is executed after a resource has failed to start and prior to issuing the start verification WTOR. This exit can be used to avoid the start verification WTOR for resources that need intervention after the start command has been issued.

The following AF/OPERATOR global variables are supplied to the exit:

Return codes from the start WTOR exit have the following meaning:






@RAOCASE The AF/OPERATOR AOCASE variable resulting from the start of the resource.

0 Indicates that the resource is now active. No WTOR will be issued.

4 Indicates that the resource is not active and that the STM should continue to issue the start verification WTOR.

8 Indicates that the STM should abort the start of the resource. The status for the resource will be set to START ABORTED. No WTOR will be issued.

User Exits


Pre-Stop ExitThe STM Pre-Stop exit is executed prior to stopping a STM resource. Any pre-stop user requirements for the resource can be processed in this exit. The exit itself allows you to: alter the stop command for the resource, alter the stop verification message for the resource, alter the stop verification interval for the resource, abort the resource stop, and bypass the resource stop.

The following AF/OPERATOR global variables are supplied to the pre-stop exit. At the completion of the exit, these variables are incorporated into the STM stop routine as if they had been supplied through the resource's table definitions. Any changes to the contents of the variables must comply with the coding restrictions for the table fields they represent. The variables are always available to the exit, however, it is not necessary to use or change the variables unless needed.



@RSTOPCM The stop command for the resource.

@RSTOPIN The stop interval for the resource, in the format: HH:MM:SS.

@RSTOPVR The stop verification message text for the resource.

@RSTOPSP The stop parameter for the resource

@RSTOPOC The override stop command for the resource


User Exits

Return codes from the pre-stop exit have the following meaning:

0 Indicates that the STM should continue the stop process. All AF/OPERATOR global variables previously mentioned will be retrieved and used in-place of the resource information stored in the STM tables for the resource.

4 Indicates that the STM should continue the stop process. All AF/OPERATOR global variables previously mentioned will be retrieved and used in-place of the resource information stored in the STM tables for the resource. The information passed in the variables will also be stored in the in-storage copies of the STM tables. These table updates are temporary; lasting only as long as AF/OPERATOR does. The permanent copies of the tables on DASD are not altered.

8 Indicates that the STM should abort the stop of the resource. The status for the resource will be set to STOP ABORTED.

12 Indicates that the STM should simply bypass the stop of the resource. The status for the resource will be set to BYPASSED.

User Exits


Post-Stop ExitThe STM Post-Stop exit is executed after the resource has been successfully stopped. Any post-stop user requirements for the resource can be processed in this exit.

The following AF/OPERATOR global variables are supplied to the post-stop exit:

Return codes from the post-stop exit have the following meaning:



@RAOCASE The AF/OPERATOR AOCASE variable resulting from the stop of the resource. The value of this variable will indicate which of the stop verification messages for the resource was received.

0 Indicates that processing was successful.

Other Indicates that processing was unsuccessful. The STM completes with a non-zero return code.


User Exits

Stop-WTOR ExitThe STM Stop-WTOR exit is executed after a resource has failed to stop and prior to issuing the stop verification WTOR. This exit can be used to avoid the stop verification WTOR for tasks like CICS, which often do not come down with a simple stop command. With this exit you can enable further logic, like purging CICS transactions, to aid in bringing a resource down without operator intervention.

The following AF/OPERATOR global variables are supplied to the exit:

Return codes from the stop WTOR exit have the following meaning:



@RSTOPCM The stop command for the resource.

@RSTOPIN The stop interval for the resource, in the format: HH:MM:SS.

@RSTOPVR The stop verification message text for the resource.

@RAOCASE The AF/OPERATOR AOCASE variable resulting from the stop of the resource.

0 Indicates that the resource is now inactive. No WTOR will be issued.

4 Indicates that the resource is still active and that the STM should continue to issue the stop verification WTOR.

8 Indicates that the STM should abort the stop of the resource. The status for the resource will be set to STOP ABORTED. No WTOR will be issued.

User Exits


Predecessor ExitThe STM Predecessor Exit is executed before predecessor relationships for the resource are processed. The predecessor exit allows you to: alter the predecessor check interval, alter the predecessor check retry count, alter the predecessor list for the resource, and abort the resource start.

The following AF/OPERATOR global variables are supplied to the predecessor exit:

Return codes from the predecessor exit have the following meaning:



@RPREDIN The predecessor check interval for the resource, in the format: HH:MM:SS.

@RPREDRT The predecessor check retry count for the resource.

@RPREDS The predecessor list for the resource. This variable consists of a list of words; each word is the name of a STM resource that has been defined as a predecessor. If changed, the resulting variable must also consist of a list of resource names or be null.


4 Indicates that the STM should bypass the predecessor routine and continue the start of the resource immediately.

8 Indicates that the STM should abort the start of the resource.


User Exits

Successor ExitThe STM Successor Exit is executed before successor relationships for the resource are processed. The successor exit allows you to: alter the successor check interval, alter the successor check retry count, alter the successor list for the resource, and abort the resource stop.

The following AF/OPERATOR global variables are supplied to the successor exit:

Return codes from the successor exit have the following meaning:


@RSUCCIN The successor check interval for the resource, in the format: HH:MM:SS.

@RSUCCRT The successor check retry count for the resource.

@RSUCCS The successor list for the resource. This variable consists of a list of words; each word is the name of a STM resource that has been defined as a successor. If changed, the resulting variable must also consist of a list of resource names or be null.

0 Indicates that the STM should continue the stop process. All AF/OPERATOR global variables previously mentioned will be retrieved and used in-place of the resource information stored in the STM tables for the resource.

4 Indicates that the STM should bypass the successor routine and continue the stop of the resource immediately.

8 Indicates that the STM should abort the stop of the resource.

User Exits


VTAM Dependency ExitThe STM VTAM Dependency Exit is executed before VTAM dependency relationships for the resource are processed. The VTAM dependency exit allows you to: alter the VTAM dependency check interval, alter the VTAM dependency check retry count, alter the VTAM node list for the resource, and abort the resource start.

The following AF/OPERATOR global variables are supplied to the VTAM dependency exit:

Return codes from the VTAM dependency exit have the following meaning:



@RVTAMIN The VTAM dependency check interval for the resource, in the format: HH:MM:SS.

@RVTAMRT The VTAM dependency check retry count for the resource.

@RVTAMS The VTAM node list for the resource. This variable consists of a list of words; each word is the name of a VTAM node that has been defined as a VTAM dependency. If changed, the resulting variable must also consist of a list of VTAM nodes or be null.


4 Indicates that the STM should bypass the VTAM dependency routine and continue the start of the resource immediately.

8 Indicates that the STM should abort the start of the resource.


Started Task Manager Task Definition


OverviewTo manage the resources under its control, the STM uses information stored in tables created by the user. The tables that contain the resource management information are:

Each table is a member of the Automation Application table dataset. These tables are loaded into above-the-line storage at AF/OPERATOR and Automation Application initialization time. Any time a STM resource is accessed, the appropriate information is retrieved from the tables and used to determine how to manage the resource.

@RCFCNTL The STM Control Table.

@RCFSMFD The STM SMF ID Control Table.

@RCFEXCP The STM Exception Control Table.

@RCFLIST The STM List Table.

@RCFSTRT The STM Start Table.

@RCFSTOP The STM Stop Table.

@RCFPRED The STM Predecessor Table.

@RCFVTAM The STM VTAM Dependency Table.

@RCFRCVR The STM Recovery Table.

@RCFSCHD The STM Schedule Table.

@RCFMISC The STM Miscellaneous Information Table.

@RCFDESC The STM Description Table.



Adding or Updating ResourcesTo add or update a resource definition in the Started Task Manager, execute the KAUUISPF exec from the hilev.RKAUEXEC dataset to activate the IRM ISPF User Interface. Resource definition information is entered on the appropriate panels from within the IRM ISPF User Interface. Under no circumstances attempt to edit the IRM tables outside of the ISPF User Interface as this will cause unpredictable results possibly causing the IRM environment to become unusable.

To implement the changes while AF/OPERATOR is running, use the Table Manager REFRESH command to refresh the in-storage copies of the STM tables. This gives the STM access to the new data. You can then issue an RCF INIT command, specifying the resource name, to initialize a new resource or update an existing one. The information below indicates which tables must be refreshed in order to implement changes to the various Started Task Manager Definition sections.

ISPF Panel Section Name: RCF Table NameControl Data @RCFCNTL

@RCFSMFD@RCFEXCP

Predecessor Data @RCFPRED @RCFPRE2

VTAM Resources @RCFVTAMStart Data @RCFSTRTRecovery @RCFRCVRSuccessors @RCFSTOPStop Data @RCFSTOPAutomation Manager Interfaces @RCFMISCProblem Notification @RCFMISCMiscellaneous Control Data @RCFMISCBatch Job Submission Data @RCFDESCBatch CA7 Interface Data @RCFDESC



Started Task Manager - Task Add Panel

Resource Data

Resource Name

The name of the resource to manage. This field is the table row name key and will be identified in the rest of the STM tables as a reference key in order to tie all resource information together. This is a twelve character alphanumeric field. If the resource is a started task, this field should be equivalent to the PROC name/address space name of the started task. Specifically for started tasks, this name will be used to determine if the task is active by address space name.

If the resource is not a started task, or if there is not an address space associated with the resource, the Resource Name field is assigned by the user and used by the STM as an identifier for the resource. Any alphanumeric character may be used for the name with the exception of an asterisk (*) or double quotes (")

Arm Task Specifies if the resource is defined to the ARM MVS facility. This field is used by the Started Task Manager to limit the start-up of the task to a single system in a Sysplex environment. The task can only be activated on multiple systems through manual intervention with the use of the FORCE option on the RCF INIT command. This is a binary field (0,1); 1 specifies that the resource is defined to ARM. The default is 0; the resource is not defined to ARM.

Note: The task must be defined in the ARM policy prior to its definition in the IRM Started Task Manager.

An example for defining the task in ARM policy:

DEFINE POLICY NAME(ARMPOL07)

RESTART_GROUP(ARMGROUP1)

ELEMENT(SYSCICS_CICS2353)

RESTART_METHOD(BOTH,STC,

'RCG ARM CICS2353'



Application The application associated with the resource. The resource application field is used in conjunction with the STM OMEGAVIEW interface. When the STM creates the OMEGAVIEW status item for the resource, the APPLICATION field, SDMXA8, will be set to the value entered in this field. The value of the field will depend on the organizational structure of OMEGAVIEW at your installation. Consult your OMEGAVIEW administrator for more information.

Started Task Manager Task Definition Panel

Control Data

Description A one line description of the resource. The resource description field is used to provide a 'Plain English' description of the resource for user reference. The field is displayed on the main STM ISPF User Interface selection panel.

Subsystem The subsystem associated with the resource. The resource subsystem field is used in conjunction with the STM OMEGAVIEW interface. When the STM creates the OMEGAVIEW status item for the resource, the SUBSYSTEM ID field, SDMXA7, will be set to the value entered in this field.

Note: The value of the field will depend on the organizational structure of OMEGAVIEW at your installation. Consult your OMEGAVIEW administrator for more information.

Alias Specifies an alias for the actual Resource Name of the resource. This is a twelve character alphanumeric field, assigned by the user. The resource alias can be used to group and/or identify a resource by other than its defined Resource Name.

Number Specifies a unique number for the resource starting from 1001. This is a four character numeric field used by the STM in creating AF/OPERATOR variables and traps associated with the resource.

The task numbers need not be consecutive and are not used in any ordering scheme, but each resource must have a unique number assigned to it.



Log The LOG field is used to enable or disable AF/OPERATOR logging of STM activities associated with the resource. Enter a 1 in this field to enable logging of actions in the AF/OPERATOR message log. For security sensitive resources or to cut down on message log traffic, enter 0 to disable logging. The default is 1, logging is enabled.



Keyword KEYWORD is the first mechanism that identifies whether a resource is defined to a system. The KEYWORD field is used as a generalized grouping mechanism to identify those resources that are defined to all systems, no systems, or manipulated internally by other Automation Applications.

Note: Leave the KEYWORD field blank if the resource does not fall into any of these categories and the Started Task Manager will continue searching the rest of the categories to determine if the resource is defined to the system.

Valid values are:� ALL Specifies that the resource is defined to all

systems. The STM will initialize this resource on every system. This value is not valid for ARM resource.

� AUTO Specifies that the resource is defined to all systems. Under most circumstances, the AUTO keyword is identical to the ALL keyword, except in the case of bringing up a maintenance system running in manual application processing mode. When running in manual mode, only those tasks identified as AUTO will be started. AUTO should be used to identify those tasks that are needed for a skeleton maintenance system (i.e LLA, VLF, and JES). When running in automated mode, the STM will initialize this resource on every system. This value is not valid for ARM resource.

� NONE Specifies that the resource is not defined to any system. The STM will not initialize this resource on any system.

Note: The resource can be initialized via manual intervention by specifying the Force option on an RCF INIT command. This keyword is used to identify those resources that should not be started automatically, but rather, are started on-demand via manual intervention.



Keywordcont.

� MANUAL Specifies that the resource is not to automatically start during STM initialization. During initialization, or anytime an RCF INIT ALL or RCF START ALL command is processed, the STM will bypass this resource. A resource with a keyword of MANUAL will be managed only if an RCF INIT command for the resource itself is manually entered at the operator console. This keyword is used to identify those resources that should not be started automatically, but rather, are started on-demand via manual intervention.

� INTERNALSpecifies that the resource will be initialized internally by another of the Automation Applications. The resource will not automatically start during STM initialization. A resource defined as INTERNAL can only be accessed by the controlling application.

Note: Resources defined with a keyword of INTERNAL are hidden from normal STM operations. INTERNAL resources can not be accessed directly by STM commands unless the Force option of the RCF command is used. This includes all STM displays for the resource.

� TWOPASS Specifies that the resource is not to automatically start during STM initialization. During initialization, or anytime an RCF INIT ALL or START ALL command is processed, the STM will bypass this resource. A resource with a keyword of TWOPASS will be managed only if an RCF INIT command for the resource itself, or an RCF INIT command for a Group or List in which the resource is included, is encountered, and then only if the resource is defined to the system by another mechanism such as including it in a Work Load group or including the system’s SMF ID in the SMF ID fields for the resource. This value is not valid for ARM resource.



XRF Workload XRF WORKLOAD is a grouping mechanism which identifies whether a resource is defined to a system. If the system is defined as an IMS/XRF active system, any resource identified as ACT by the XRF_WKLD field will be managed. Similarly, if the system is defined as an IMS/XRF alternate system, any resource identified as ALT by the field will be managed. Valid values are:� ACT Specifies that the resource is to be initialized on

any IMS/XRF active system.� ALT Specifies that the resource is to be initialized on

any IMS/XRF alternate system.Code a '*' if the resource does not fall into any of these categories and the STM will continue searching the rest of the categories to determine if the resource is defined to the system.

Note: This field is used to identify resources that are to be managed as a group for IMS/XRF activities, such as workload movement in the event of an IMS/XRF takeover.

JES Workload JES WORKLOAD is a grouping mechanism which identifies whether a resource is defined to a system. If the system is defined as a JES3 Global system, any resource identified as GLB by the JES WORKLOAD field will be managed. Similarly, if the system is defined as a JES3 Local system, any resource identified as LCL by the field will be managed. Valid values are:� GLB Specifies that the resource is to be initialized on

any JES3 Global processor.� LCL Specifies that the resource is to be initialized on

any JES3 Local processor.Code a '*' if the resource does not fall into any of these categories and the STM will continue searching the rest of the categories to determine if the resource is defined to the system.

Note: This field is used to identify resources that are to be managed as a group for JES3 activities, such as workload movement in the event of a Dynamic System Interchange (DSI).



MSn MSn is a grouping mechanism that identifies whether a resource is defined to a system. MS1 through MS4 are four user-assigned workload grouping fields. If the user-assigned system definition for the MSn Workload and the MSn Field matches, the resource will be managed. Code a '*' if the resource does not fall into any of these categories, or if these groups have not been assigned, and the STM will continue searching the rest of the categories to determine if the resource is defined to the system

CPU ID The CPUID 1 through CPUID 12 fields allow the user to specifically define up to 12 unique CPU IDs where the resource is meant to run. If the resource does not fit into any resource grouping as previously described, you can code the individual CPU IDs of the systems where the resource is to be managed.

Note: A CPU ID can be entered as either the full six character CPU ID, the right-most five characters of the CPU ID or just the four right-most characters of the CPU ID for those resources that are not LPAR dependent.

SMF ID The SMFID 1 through SMFID 24 fields allow the user to specifically define up to 24 unique SMF IDs where the resource is meant to run. If the resource does not fit into any resource grouping as previously described, code the individual SMF IDs of the systems where the resource is to be managed.

Note: If you have not specified the resource in any of the previous workload groups, an SMF ID must be specified in order to manage the resource. If an SMF ID is not coded the resource will not be managed anywhere.

Exceptions The Exception 1 through Exception 24 fields allow the user to exclude up to 24 unique SMF IDs where the resource is not meant to run. If the resource fits into a resource grouping except for a couple of systems, include the resource in the group and code the individual SMF IDs of the systems that are exceptions in the Exception fields.



Predecessors

Retries Specifies the maximum number of times that you want the STM to check whether predecessors are active, in the form of a whole number. The STM will wait for the time period specified by the Predecessor Interval field between each retry. The default is 10. At least one retry should be specified for each predecessor to the resource. Each time a predecessor to the resource becomes active, the STM will interrupt the predecessor wait cycle and check the rest of the predecessors to the resource. There must be enough retries to account for all of the resource's predecessors.

Interval The period of time which the STM will wait between predecessor checks, in the form HH:MM:SS. At the end of each interval, the predecessors to the resource will be checked for their current state until all predecessors are defined as active. Once all predecessors are active, the resource will be started. The default is one minute, 00:01:00. A fairly short length of time should be specified here for resources that are close to the IPL (LLA, VLF, JES, etc.). This interval should be greater for those tasks further from the IPL for optimal performance.

Note: This interval will be interrupted as predecessors to the resource become active. This interval is used as the maximum time to wait between predecessor checks.

Exit This field identifies the command file name of the predecessor exit for the resource. If the resource has no predecessor exit, code an asterisk (*) in this field.

Pred Specifies the Resource Name of a predecessor to the resource. The Predecessor 1 through Predecessor 20 fields are used to name the resources, under control of the STM, that MUST be active prior to starting the resource. Resources specified in the predecessor fields must be under the control of the STM.

Note: Defining a predecessor that is under STM control, but not defined to a particular system, is allowed. Defining a predecessor that is not under STM control, whether it runs on a particular system or not, is not allowed.



VTAM Resources

SMF ID Specifies the SMFID of a predecessor for a resource. The SMFID 1 through DSMFID 20 fields allows a user to define remote resources as predecessors for a task. Valid values are:� BLANK A BLANK indicates the predecessor runs on

the local system. The local system SMFID can also be specified for clarification, if desired.

� SMFID Coding an SMFID other than the local system indicates the predecessor runs on the remote system specified in this field.

� ANY A value of ANY indicates the predecessor requirement for the task will be satisfied by any occurrence of the predecessor task on any system sharing the same Sysplex structure with the local system.

If a specific SMFID or ANY is coded and the Coupling Facility structure is not available, start-up of the task will be bypassed. If, for any other reason, the status of the remote task cannot be determined, the ASOA070I WTOR will be issued. Start-up of remote predecessors is not available via the WTOR.

Retries Specifies the maximum number of times for the STM to check the VTAM resources, in the form of a whole number. The STM will wait for the time period specified by the Interval field

between each retry. The default is 10. At least one retry should be specified for each VTAM node. Each time a VTAM node becomes active, the STM will interrupt the VTAM dependency wait cycle and check the rest of the VTAM nodes. There must be enough retries to account for all of the VTAM nodes defined for the task.

Interval The period of time which the STM will wait between VTAM dependency checks, in the form HH:MM:SS. At the end of each interval, each of the VTAM nodes will be checked for their current state until all VTAM nodes are active. The default is one minute, 00:01:00.

Note: Interval will be interrupted as VTAM nodes become active. This interval is used as the maximum time to wait between VTAM dependency checks.



Start Data

Exit This field identifies the command file name of the VTAM dependency exit for the resource.

Node Names Specifies the name of a VTAM node. The Node1 through Node12 fields are used to name the VTAM nodes that MUST be active prior to the start of the resource. The node names specified here are assumed to be under external control; if not active, these nodes will be activated by an external source.

Note: VTAM nodes that are to be controlled as part of manipulating the resource should be defined to the VTAM Manager. The STM interface to the VTAM Manager can then be used to vary these nodes active when the resource is started.

Pre-Start Exit This field identifies the command file name of the pre-start exit for the resource. An AF/OPERATOR system or global variable, which equates to the exit command file name, can be coded in this field by prefacing the variable name with an ampersand (&): &AOVARNAM. If the resource has no pre-start exit, code an asterisk (*) in this field.

Post-Start Exit This field identifies the command file name of the post-start exit for the resource. An AF/OPERATOR system or global variable, which equates to the exit command file name, can be coded in this field by prefacing the variable name with an ampersand (&): &AOVARNAM. If the resource has no post-start exit, code an asterisk (*) in this field.

Start WTOR This field identifies the command file name of the start-WTOR exit for the resource. An AF/OPERATOR system or global variable, which equates to the exit command file name, can be coded in this field by prefacing the variable name with an ampersand (&): &AOVARNAM.



Start Job Name

Specifies the job name associated with the start verification message specified by the START_VER field. If the resource is not a sub task or a SUB=MSTR task, by default, the task name will be used for the job name when identifying the issuer of the start verification message. If the resource is a sub task or SUB=MSTR task, an asterisk (*) will be used for the job name associated with the start verification message. This field is used to define the appropriate job name when either of the two defaults described do not meet the needs of the resource.

This field is optional and is only needed when the STM default job name does not meet the needs of the resource. Code the job name as you would with the TRAP command JOBNAME() parameter. An AF/OPERATOR system or global variable, which equates to the job name, can be coded in this field. For example, if the AF/OPERATOR system variable @JOBNAME has been previously set to the value IMSS0CTL, you may code &@JOBNAME in this field, which will then be resolved into a job name of IMSS0CTL.

Job Type Specifies the job type associated with the start verification message specified by the Start Message field. By default, an asterisk (*) will be used for the job type when identifying the issuer of the start verification message. If the start verification message is issued from a special source, such as an IMS MTO only message, or if you need to limit the scope of the message match to a particular job type, code the appropriate job type for the message in this field.

Code the job type as you would with the TRAP command JOBTYPE() parameter. All valid AF/OPERATOR job types are allowed. An AF/OPERATOR system or global variable, which equates to the job type, can be coded in this field. For example, if the AF/OPERATOR system variable @IMSTYPE has been previously set to the value IMS, you may code &@IMSTYPE in this field, which will then be resolved into a job type of IMS. This field is optional.



System ID Specifies the system ID associated with the start verification message specified by the Start Message field. By default, the value specified for AOLSYSNM in the AF/OPERATOR AFPARMS initialization deck will be used for the system ID. If the start verification message is issued from a special source, such as an IMS MTO only message, or if the default system ID for messages is not appropriate for this resource, code the appropriate system ID for the start verification message in this field. Code the system ID as you would with the TRAP command SYSID() parameter. An AF/OPERATOR system or global variable, which equates to the system ID, can be coded in this field. For example, if the AF/OPERATOR system variable @IMSTASK has been previously set to the value IMSS0CTL, you may code &@IMSTASK in this field, which will then be resolved into a system ID of IMSS0CTL. This field is optional.

Start Interval Specifies the amount of time that the STM will wait for the start verification message, specified by the Start Message field, in the form HH:MM:SS. If the start verification message is not received within this interval, the STM will assume that the resource has failed to start successfully. The default is two minutes, 00:02:00.



Start Command

The appropriate start command to issue for the resource. Type the command as you would at a console, except that imbedded quotes in the start command must be quadrupled. For example, the command: S TASKABC,PARM='parm' would read:

S TASKABC,PARM=''''parm''''

Only one command is allowed. Any MVS, MVS-subsystem, or AF/OPERATOR command can be coded. Enclose the entire command in double quotes (").

Note: For IMS start commands, code a fully qualified AF/OPERATOR IMSOPER command:

IMSOPER CTLRGN(IMSS0CTL) CMD(''/STA REG NAME.AO'')

If multiple commands or further logic is needed to start a resource, the start command can be the execution of an AF/OPERATOR command file containing the appropriate logic. To execute a command file, code:

EXEC CFILE_NAME ''PARM''

If the resource has no start command, such as those resources that are started internally by other tasks, leave this field blank. This can be used to limit STM control of the resource to only stopping the resource.

Note: To imbed AF/OPERATOR System variables within the start command, prefix the variable with two ampersands (&&).



Start Message Specifies the resource start verification message; a message you expect to receive that signifies that the resource has started successfully. This message is used by the STM to determine when the resource is active.

Any valid AF/OPERATOR message pattern can be coded for the start verification message. An asterisk (*) will be automatically appended to the end of the message pattern, by the STM, to ensure that the message pattern successfully matches the start verification message. Code the message pattern enclosed in double quotes (").

Multiple start verification messages can be specified for those resources that have various start messages. To specify multiple messages, code:

"ABINS000*','ABINS005"

as you would on a WAIT command with multiple messages. The STM does not require receipt of all of the messages; receipt of any of the messages specified will satisfy the start verification condition.

If there is a job name associated with the start verification message other than the task name, the appropriate job name can be specified for the message by using the J{} parameter. Code the start verification message pattern followed by the J{} parameter with the desired job name within the brackets:

IEF403I* J{TASKABCOE}

Specifying a job name for the start verification message with the J{} parameter is equivalent to specifying a job name in the Job Name field described below.

If there is a job type associated with the start verification message other than the default job type, an asterisk (*), the appropriate job type can be specified for the message by using the T{} parameter. Code the start verification message pattern followed by the T{} parameter with the desired job type within the brackets:

DSNM001I * DSN1 * T{IMSOE}



Start Message cont.

Specifying a job type for the start verification message with the T{} parameter is equivalent to specifying a job type in the Job Type field described below.

If there is a system ID associated with the start verification message other than the default system ID, the appropriate system ID can be specified for the message by using the S{} parameter. Code the start verification message pattern followed S{} parameter with the desired system ID within the brackets:

DSNM001I * DSN1 * T{IMSOE} S{IMSS0CTLOE}

Specifying a system ID for the start verification message with the S{} parameter is equivalent to specifying a system ID in the System ID field described below.

Note: This field is optional, but be aware that if you do not specify a message here, the STM will assume that the resource is active, by default, once the start command has been issued.

START_ARM Specifies if the resource is defined to the ARM MVS facility. This field is used by the Started Task Manager to limit the start-up of the task to a single system in a Sysplex environment. The task can only be activated on multiple systems through manual intervention with the use of the FORCE option on the RCF INIT command. This is a binary field (0,1); 1 specifies that the resource is defined to ARM. The default is 0; the resource is not defined to ARM.



Recovery

Retries The maximum number of times, within the retry time period specified by the Cycle field, that the STM will automatically initiate the recovery process for a failed resource. If the recovery process is invoked and the recovery count exceeds this value, the recovery process will be suspended and the operator will be given an option, via WTOR, whether to continue the recovery process or not. This is a whole number in the range from 1 to 99. The default is 3.

Note: A zero can be specified to prevent the STM from automatically recovering the resource. In this case, anytime a resource failure message is detected, the STM will display the WTOR informing the operator that the resource has failed and request confirmation to continue the recovery process.

Cycle The period of time within which the STM will attempt the number of retries specified by the Retries field. The recovery count for the resource will be reset at this interval. Specify in the form HH:MM:SS and within the range 00:00:01 to 24:00:00. Specifying 24:00:00 will reset the resource recovery count once a day. As an example, if the retry cycle is 24:00:00 and the number of retries is 3, the resource will be automatically recovered a maximum of 3 times every day.

Pre-Exit Pre-Recovery Exit Command File. Specifies the name of an AF/OPERATOR command file to be executed prior to the STM recovery process. This field is optional.

Post-Exit Post-Recovery Exit Command File. Specifies the name of an AF/OPERATOR command file to be executed after the recovery process has completed. This field is optional.

Abend Message Abend Message ID - The message ID of the WTO that signifies that the resource has abended. Usually, this would be the MVS IEF450I message ID. Receipt of this essage will cause the STM to initiate the recovery process for the resource.

End Message End Message ID - The message ID of the WTO that signifies that the resource has ended normally. Usually, this would be the MVS IEF404I message ID. Receipt of this message will cause the STM to initiate the recovery process for the resource.



Cancel Message Cancel Message ID - The message ID of the WTO that signifies that the resource has been cancelled. Usually, this would be the MVS IEF402I message ID. Receipt of this message will cause the STM to initiate the recovery process for the resource.

Recovery Message n.

User Defined Messages - Any message pattern that you want the STM to interpret as a signal to initiate the recovery process for the resource. These fields are optional. Enclose each message in double quotes ("). If there is a job name associated with the recovery message other than the task name, the desired job name can be specified for the recovery message WTO trap by using the J{} parameter. Code the recovery message pattern followed by the J{} parameter with the desired job name within the brackets:

"IEF404I* J"TASKABCOE"

If there is a system ID associated with the recovery message other than the default system ID, the desired system ID can be specified for the recovery message WTO trap by using the S{}parameter. Code the recovery message pattern followed by the S{} parameter with the desired system ID within the brackets:

"IEF404I* S"IMSS0CTLOE"

Both job name and system ID overrides can be specified for a recovery message:

"DFS970I 8?##AO1 * J"IMSLACTLOE S"IMSLACTLOE"

These parameters affect only the recovery message WTO traps where they are present. Specifying the parameters for one recovery message will not carry the options forward to the next recovery message. The J{} and S{} parameters take precedence over any value specified in the Recovery Job Name and Recovery System ID fields described below. The two mechanisms can be used together to override the default job name used for all recovery traps, and then, override the override job name on a particular trap.



Recovery Message n. cont.

If the Recovery Job Name is IMSLACTL and the recovery messages are specified as follows:

REC.1= IEF450I

REC.2= IEF404I

REC.3= IEF402I

REC.4 = "DSI496I*?&@APLVTSA.IMS * J"AOSPROC*E"

REC.5 = "DFS2111I* IMS5*"

REC.6 = "DFS970I*?##AOO10 * S "IMSLACTLOE"

The resulting job names in the recovery traps will be:

REC.1= IMSLACTL

REC.2= IMSLACTL

REC.3= IMSLACTL

REC.4= AOSPROC\

REC.5= IMSLACTL

REC.6= IMSLACTL

Leave blank any Recovery Msg field that is not in use and the recovery message will be bypassed.

Note: If the resource is stopped by the STM, the recovery traps defined by the REC.n fields will be disabled and deleted. This prevents a recovery trap match when the resource is intentionally brought down.

Job Name The job name associated with the Recovery Messages for the resource. By default, the task name will be used for the JOBNAME() option when building recovery WTO traps for the resource. If there is a job name associated with the recovery messages other than the task name, the desired job name can be specified for the recovery traps with this field. This field is optional. Leave this field blank if the default job name should be used when building recovery traps for the resource.

System ID The system ID associated with the Recovery Messages for the resource. The default system ID will be used for the SYSID() option when building recovery WTO traps for the resource. If there is a system ID associated with the recovery messages other than the default system ID, the desired system ID can be specified for the recovery traps with this field. This field is optional. Leave this field blank if the default system ID should be used when building recovery traps for the resource.



Successors

Retries Specifies the maximum number of times that you want the STM to check whether successors are inactive, in the form of a whole number. The STM will wait for the time period specified by the Interval field between each retry. The default is 10. At least one retry should be specified for each successor to the resource. Each time a successor to the resource becomes inactive, the STM will interrupt the successor wait cycle and check the rest of the successors to the resource. There must be enough retries to account for all of the resource's successors.

Interval The period of time which the STM will wait between successor checks, in the form HH:MM:SS. At the end of each interval, the successors to the resource will be checked for their current state until all successors are defined as inactive. Once all successors are inactive, the resource will be stopped. The default is one minute, 00:01:00.

Note: This interval will be interrupted as successors to the resource become inactive. This interval is used as the maximum time to wait between successor checks. A resource's successor list is determined by searching through the predecessor lists. A resource's successors need not be specifically defined.

Exit This field identifies the command file name of the successor exit for the resource. An AF/OPERATOR system or global variable, which equates to the exit command file name, can be coded in this field by prefacing the variable name with an ampersand (&): &AOVARNAM. If the resource has no successor exit, leave this field blank.

Stop Remote This field specifies if the local resource will wait for shutdown of remote successors to occur prior to the stopping of the local resource. This is a binary field (0,1). A 1 indicates all remote successors will be stopped before continuing shutdown of the local resource and 0 indicates remote successors will not be stopped as part of the shutdown process for the local task. The default value is 0.



Stop Data

Pre-Stop Exit This field identifies the command file name of the pre-stop exit for the resource. An AF/OPERATOR system or global variable, which equates to the exit command file name, can be coded in this field by prefacing the variable name with an ampersand (&): &AOVARNAM. If the resource has no pre-stop exit, code an asterisk (*) in this field.

Post-Stop This field identifies the command file name of the post-stop exit for the resource. An AF/OPERATOR system or global variable, which equates to the exit command file name, can be coded in this field by prefacing the variable name with an ampersand (&): &AOVARNAM. If the resource has no post-stop exit, code an asterisk (*) in this field.

Stop WTOR This field identifies the command file name of the stop-WTOR exit for the resource. An AF/OPERATOR system or global variable, which equates to the exit command file name, can be coded in this field by prefacing the variable name with an ampersand (&): &AOVARNAM. If the resource has no stop-WTOR exit, leave this field blank.

Stop Job Name

Specifies the job name associated with the stop verification message specified by the STOP_VER field. If the resource is not a sub task or a SUB=MSTR task, by default, the task name will be used for the job name when identifying the issuer of the stop verification message. If the resource is a sub task or SUB=MSTR task, an asterisk (*) will be used for the job name associated with the stop verification message. This field is used to define the appropriate job name when either of the two defaults described do not meet the needs of the resource.

This field is optional and is only needed when the STM default job name does not meet the needs of the resource. Code the job name as you would with the TRAP command JOBNAME() parameter. An AF/OPERATOR system or global variable, which equates to the job name, can be coded in this field. For example, if the AF/OPERATOR system variable @JOBNAME has been previously set to the value IMSS0CTL, you may code &@JOBNAME in this field, which will then be resolved into a job name of IMSS0CTL.



Job Type Specifies the job type associated with the stop verification message specified by the STOP_VER field. By default, an asterisk (*) will be used for the job type when identifying the issuer of the stop verification message. If the stop verification message is issued from a special source, such as an IMS MTO only message, or if you need to limit the scope of the message match to a particular job type, code the appropriate job type for the message in this field.

Code the job type as you would with the TRAP command JOBTYPE() parameter. All valid AF/OPERATOR job types are allowed. An AF/OPERATOR system or global variable, which equates to the job type, can be coded in this field. For example, if the AF/OPERATOR system variable @IMSTYPE has been previously set to the value IMS, you may code &@IMSTYPE in this field, which will then be resolved into a job type of IMS.

This field is optional.

System ID Specifies the system ID associated with the stop verification message specified by the STOP_VER field. By default, the value specified for AOLSYSNM in the AF/OPERATOR AFPARMS initialization deck will be used for the system ID. If the stop verification message is issued from a special source, such as an IMS MTO only message, or if the default system ID for messages is not appropriate for this resource, code the appropriate system ID for the stop verification message in this field.

Code the system ID as you would with the TRAP command SYSID() parameter. An AF/OPERATOR system or global variable, which equates to the system ID, can be coded in this field. For example, if the AF/OPERATOR system variable @IMSTASK has been previously set to the value IMSS0CTL, you may code &@IMSTASK in this field, which will then be resolved into a system ID of IMSS0CTL.

This field is optional.

Stop Interval Specifies the amount of time that the STM will wait for the stop verification message, specified by the STOP_VER field, in the form HH:MM:SS. If the stop verification message is not received within this interval, the STM will assume that the resource has failed to stop successfully. The default is two minutes, 00:02:00.



Stop Command

The appropriate stop command to issue for the resource. Type the command as you would at a console. Only one command is allowed. Any MVS, MVS-subsystem, or AF/OPERATOR command can be coded. Enclose the entire command in double quotes (").

For IMS stop commands, code a fully qualified AF/OPERATOR IMSOPER command:

IMSOPER CTLRGN(IMSS0CTL) CMD(''/STO REG 1.AO'')

If multiple commands or further logic is needed to stop a resource, the stop command can be the execution of an AF/OPERATOR command file containing the appropriate logic. To execute a command file, code:

EXEC CFILE_NAME ''PARM''

If the resource has no stop command, such as those resources that are only started, leave this field blank. This can be used to limit STM control of the resource to only starting the resource.

Stop Message Specifies the resource stop verification message; a message you expect to receive that signifies that the resource has stopped successfully. This message is used by the STM to determine when the resource is inactive. Any valid AF/OPERATOR message pattern can be coded for the stop verification message. An asterisk (*) will be automatically appended to the end of the message pattern, by the STM, to ensure that the message pattern successfully matches the stop verification message. Code the message pattern enclosed in double quotes ("). Multiple stop verification messages can be specified for those resources that have various stop messages. To specify multiple messages, code:

"IAT9113*','ASOA165I"

as you would on a WAIT command with multiple messages. The STM does not require receipt of all of the messages; receipt of any of the messages specified will satisfy the stop verification condition. If there is a job name associated with the stop verification message other than the task name, the appropriate job name can be specified for the message by using the J{} parameter. Code the stop verification message pattern followed by the J{} parameter with the desired job name within the brackets:

"IEF404I* J"TASKABCOE"



Stop Message cont.

Specifying a job name for the stop verification message with the J{} parameter is equivalent to specifying a job name in the Job Name field described below. If there is a job type associated with the stop verification message other than the default job type, an asterisk (*), the appropriate job type can be specified for the message by using the T{} parameter. Code the stop verification message pattern followed by the T{} parameter with the desired job type within the brackets:

"DSNM002I * DSN1 *T "IMSOE"

Specifying a job type for the stop verification message with the T{} parameter is equivalent to specifying a job type in the Job Type field described below. If there is a system ID associated with the stop verification message other than the default system ID, the appropriate system ID can be specified for the message by using the S{} parameter. Code the stop verification message pattern followed S{} parameter with the desired system ID within the brackets:

"DSNM002I * DSN1 * T "IMSOE S "IMSS0CTLOE"

Specifying a system ID for the stop verification message with the S{} parameter is equivalent to specifying a system ID in the STOP_SYS field described below.

Note: This field is optional, but be aware that if you do not specify a message here, the STM will assume that the resource is inactive, by default, once the stop command has been issued.



Automation Manager Interfaces Control Data

Message Specifies whether or not the STM will internally call the Message Manager to initialize objects associated with the STM resource. Message Manager objects associated with the STM resource are identified with a KEYWORD of INTERNAL and a name equal to:

task_name||@||xxxFor example: VTAM@1

This is a binary field (0,1); 1 enables the Message Manager interface and 0 disables the interface. The default is 0.

Command Specifies whether or not the STM will internally call the Command Manager to initialize objects associated with the STM resource. Command Manager objects associated with the STM resource are identified with a KEYWORD of INTERNAL and a name equal to:

task_name||@||xxxThis is a binary field (0,1); 1 enables the Command Manager interface and 0 disables the interface. The default is 0.

Schedule Specifies whether or not the STM will internally call the Schedule Manager to initialize objects associated with the STM resource. Schedule Manager objects associated with the STM resource are identified with a KEYWORD of INTERNAL and a name equal to:

task_name||@||xxxThis is a binary field (0,1); 1 enables the Schedule Manager interface and 0 disables the interface. The default is 0.

VTAM Specifies whether or not the STM will internally call the VTAM Manager to initialize objects associated with the STM resource. VTAM Manager objects associated with the STM resource are identified with a KEYWORD of INTERNAL and a name equal to:

task_name||@||xxxThis is a binary field (0,1); 1 enables the VTAM Manager interface and 0 disables the interface. The default is 0.



MVS Specifies whether or not the STM will internally call the Device Manager to initialize objects associated with the STM resource. Device Manager objects associated with the STM resource are identified with a KEYWORD of INTERNAL and a name equal to:

task_name||@||xxxThis is a binary field (0,1); 1 enables the Device Manager interface and 0 disables the interface. The default is 0.

JES Job Class Specifies the JES Job Classes that are tied to the STM resource. If a JES job class is associated with the resource, define the job class with this field and the STM will internally call the JES Manager to start or stop the job class when the resource is started or stopped.

Any valid JES job class that is managed by the JES Manager can be specified.

Note: If there are multiple job classes associated with the resource, code the job classes separated by commas:

A,B,Q,R,SMPGEN

If there are no JES job classes associated with the resource, leave this field blank.

JES Job Group Specifies the JES Job Groups that are tied to the STM resource. If a JES job group is associated with the resource, define the job group with this field and the STM will internally call the JES Manager to start or stop the job group initiators when the resource is started or stopped.

Any valid JES job group that is managed by the JES Manager can be specified.

Note: If there are multiple job groups associated with the resource, code the job groups separated by commas:

GGEN,GTAPIf there are no JES job groups associated with the resource, leave this field blank.



Problem Notification

Miscellaneous Control Data

Notify Users The USER.1 through USER.6 fields are used to list the TSO user IDs of up to six users you want to notify if the STM experiences a problem managing a resource. Leave blank any field that is not in use.

Note: If the STM experiences any problems with the resource, each user in the list will be sent a message specifying what resource failed, when the failure occurred, and what STM function was being processed.

Notify Exit Notification Command File. Specifies the name of an AF/OPERATOR command file to be executed if the STM experiences a problem managing a resource. Enclose the command file name and parameters in double quotes ("). This exit is used to augment the standard notification process. This field is optional. Leave blank if there is no notification command file enabled for this resource.

Problem Exit Problem Record Command File. Specifies the name of an AF/OPERATOR command file to be executed prior to the recovery process which interfaces with your site's problem management system to record the failure. This field is optional. Leave blank if there is no problem exit command file enabled for the resource.

MVS Commands

Specifies whether or not the STM will capture native MVS commands affecting the resource. The only commands that will be captured are those that are identical to those specified by the START_CMD and STOP_CMD fields defined previously. This is a binary field (0,1); 1 signifies that the STM should trap and process native MVS commands. The default is 0; no command traps will be set for start/stop commands affecting the resource.



SUB=MSTR Task

Specifies whether or not the resource is a MSTR task. This is a binary field (0,1); 1 signifies that the task is started SUB=MSTR. The default is 0; the resource in not a MSTR task.

This field is used by the STM to determine if traps associated with the resource should use the JOBNAME() option. Tasks that are started SUB=MSTR do not always have a job name specified in the MVS WTO control block.

It is the responsibility of JES to add the job name to the control block, and since SUB=MSTR tasks can run before JES, there is no guarantee that the job name field will be correct. SUB=MSTR tasks should be identified with this field so that traps associated with the task are defined with JOBNAME(*).

Kill Function Specifies whether or not the STM will process a KILL function for the resource. The KILL function is only valid for cancellable MVS started tasks.

This is a binary field (0,1); 1 signifies that the STM will process a KILL function for the resource and 0 indicates that the KILL function has been disabled for this resource. The default is 0.

IPL Only Task Specifies that the task should only be started after a system IPL. This is a binary field (0,1); 1 signifies that the resource is started once at the IPL. This field is used to designate those resources that are executed once at the system IPL to set hooks, but are not expected to run continuously. The default is 0.

Sub Task Specifies whether or not the resource is a sub-task. This is a binary field (0,1); 1 signifies that the resource is a sub-task. The default is 0; the resource in not a sub-task. This field is used by the Started Task Manager when determining the current state of the resource. If the resource is a sub-task and does not have an address space of its own, the AF/OPERATOR active function will not be used to determine if the resource is active. Any resource that does not have its own address space, such as a JES DSP, should be defined as a sub-task.



Command Separator

Specifies the character used to separate parameters in the start and stop commands for the resource. For MVS commands, the separator character is a comma (,). For DB2 commands, the character is a space ( ). The value specified here is used in rebuilding the start command during PARM(), ADDPARM(), and REPPARM() processing. The default value for the Command Separator character is a comma. If the default value is not the correct separator character for the resource, enter the value of the correct character here.

Omview Status Specifies whether or not to communicate the status of the resource to Omegaview. This field can be used to selectively enable/disable status updates for Started Task Manager resources. This is a binary field (0,1); 1 signifies that status information should be communicated to Omegaview. A 0 is used to disable status updates for the resource. The default is 1, Omegaview status will be updated.

Command Console

Specifies the ID of the console that is to be used when commands are issued to start or stop the resource. By default, the STM will direct its commands to the default AF/OPERATOR command destination as specified in AFPARMS. If a resource needs to have its commands directed to a specific console rather than the default AF/OPERATOR console, code the ID of the console in this field. Code an asterisk (*) in this field, if the default AF/OPERATOR console should be used for commands affecting the resource.

User Variable This field is used to specify the value of the User Variable for the resource. Each time an action is taken which affects the resource, the value coded in this field will be copied into the @RUSRVAR AF/OPERATOR global variable by the STM. This makes the @RUSRVAR global variable available to all of the STM exits.

The User Variable field is not used by the &stm, and therefore, there are no restrictions on the value specified for the variable. If there is no User Variable for the resource, code an asterisk (*) in this field.



Active Function Specifies whether or not the resource has its own Active Function. If the resource has its own active function, code the name of the active function in this field. If the resource has no active function or if the default AF/OPERATOR ACTIVE() function should be used, leave this field blank.

The function specified by this field must be a REXX function. This can either be an internal REXX function or a an external function; a function coded in the REXX language. The function must return a 1 or a 0. Returning a 1 signifies that the resource is active. Returning a 0 indicates that the resource is inactive.

By default the function will be called in the following format:

result = act_func(task_name)If the function needs to be called in some other manner, code the exact format of the function call in the table field and the function will be called in the following format:

interpret 'result = 'act_funcParenthesis must be included to have the function called in the second format: "active(arg)". If the function call format contains imbedded blanks, "active(arg1 arg2)", enclose the field in double quotes (").

Note: If the task identifier is required when calling the AF/OPERATOR ACTIVE function, the exact format of the ACTIVE function call should be specified with this field:

ACTIVE('J3SNAWTR.PRTCACN1')Note: For resources that are sub-tasks, but still have an address

space, such as IMS message regions: code a 1 in the SUB_TASK field and specify the standard AF/OPERATOR ACTIVE function with this field.



Batch Job Submission Data

Batch Specifies whether or not the Batch Interface has been enabled for the resource. This is a binary field (0,1). Specify a 1 to enable the Batch Interface for the task or 0 to disable it.

Note: This field must be set to 1 to enable the Batch Interface for the resource. If this field is not set to 1, no batch actions will be taken for the resource, even if values are coded in the other Batch Interface or CA7 Interface fields.

Post SI Specifies whether or not the resource will be started immediately after the completion of batch processing. This is a binary field (0,1). Specify a 1 if you want the resource to be started immediately after batch has completed or 0 if the resource is to be started on its normal schedule.

Check Comp Specifies whether or not to check for the completion of batch processing before starting the resource. This is a binary field (0,1). Specify a 1 if you want to ensure that batch processing has completed before the resource is started or 0 if the completion of the batch process does not affect starting the resource.

Submit Exit This field identifies the command file name of the Batch Submit Exit for the resource. If the resource has no Batch Submit Exit, leave this field blank.

Post Exit This field identifies the command file name of the Batch Post Exit for the resource. If the resource has no Batch Post Exit, leave this field blank.

Check Exit This field identifies the command file name of the Batch Check Exit for the resource. If the resource has no Batch Check Exit, leave this field blank.

Ready Exit This field identifies the command file name of the Batch Ready Exit for the resource. If the resource has no Batch Ready Exit, leave this field blank.



Lead Time This field is used to specify the Batch Ready Lead Time interval for the resource. The lead time is specified in military time format, hh:mm:ss. Use this field to tell the Started Task Manager that batch ready posting for the resource must have occurred within the last hh:mm:ss to satisfy the batch ready requirement. Leave this field blank if there is no Batch Ready Lead Time for the resource, or if the Batch Ready condition is not to be checked prior to the scheduled stop of the resource.

Ready Wait This field is used to specify the Batch Ready Wait Time interval for the resource. The wait time is specified in military time format, hh:mm:ss. Use this field to tell the Started Task Manager how long to wait for the batch ready requirement to be met, before notifying the operator via WTOR that the resource can not be stopped. Leave this field blank if there is no Batch Ready Wait Time for the resource, or if the Batch Ready condition is not to be checked prior to the scheduled stop of the resource.

Edit Member This field identifies the Job JCL Edit Member name for the resource. This field will be passed as an argument to the @JOBEDIT function which is used to edit the JCL and submit the job. Leave this field blank if there is no edited job to submit for the resource.

Edit Args This field specifies the name of the AF/OPERATOR global variable that contains the Batch Edit Substitution Arguments. This field will be resolved and passed as an argument to the @JOBEDIT function which is used to edit the JCL member and submit the job. Leave this field blank if there is no edited job to submit for the resource.

Submit Member This field identifies the Batch Submit Member name for the resource. This field will be passed as an argument to the @JOBSMIT function which will be used to submit the job. Leave this field blank if there is no job to submit for the resource.

Submit Dataset This field identifies the Batch Submit Dataset name for the resource. It is used to override the default JCL library name, TDAUAF.AF250.RKAUSAMP. The value coded in this field will be passed as an argument to the @JOBSMIT function which is used to submit the job. Leave this field blank if there is no job to submit for the resource.



Batch CA7 Interface Data

Post Dataset Specifies whether or not to post a CA7 External Dataset Requirement when the resource is stopped. The format of the posted dataset name is:

SCS.AFOPER.&rname.RELEASE.G0000V00

The external dataset requirement can be used with CA7 to trigger submission of the batch job stream for the resource. This is a binary field (0,1). Enter 1 to enable CA7 External Dataset posting for the resource, or 0 if no CA7 External Dataset should be posted when the resource is stopped.

Demand Job Specifies the name of a CA7 job to demand when the task is successfully stopped. Leave this field blank if there is no CA7 job to demand after the resource is stopped.

Demand SCHID Specifies the CA7 Schedule ID associated with the job specified in the Demand Job Field. This field is used to identify a schedule ID to be used for the run. A default value of 1 will be used if the schedule ID is not specified here. The CA7 Schedule ID must be in the range: 1 to 255. Leave this field blank if there is no CA7 demanded job for the resource.

JCLID Specifies the CA7 JCL ID associated with the job specified in the Demand Job Field. A default JCL ID of 0 will be used if the CA7 JCL ID is not specified here. The CA7 JCL ID must be in the range: 0 to 254. Leave this field blank if there is no CA7 demanded job for the resource.

Option Specifies the CA7 Demand Option associated with the job specified in the Demand Job Field. Code H to demand the job with the hold option, DEMANDH, or N to append the SET=NTR option to the CA7 DEMAND request.



Started Task Manager - Add a List The Add a List panel is used to define resource lists. Any object known to the STM can be defined to a resource list, including other resource lists. Resource lists are defined by the user and used to manipulate a set of STM objects as a group.

The Task List table is a keyed table, which uses system SMF ID as one of the keys. This allows you to control what resources are included in a resource list at a system level. A resource list can be enabled on a single system or many; each object in the list can be included on a system, many systems or all systems.

List Data

Started Task Manager List Definition Panel

List Name The name of the resource list. This is a twelve character alphanumeric field. Any name you choose may be used for the list. List names must be unique and may not include imbedded double quotes (") or asterisks (*).

Description A one line description of the resource list. The resource description field is used to provide a 'Plain English' description of the resource list for user reference.

List Object Add the Resource Name of the object to be included in the list. The Resource Name specified for the List Object must be known to the STM. Another resource list can be specified in this field by coding 'LIST=list_name' in the List Object field.

Key Code DEFAULT to include the object in the resource list on every system or an SMF ID to include the object on a specific system. If an SMF ID is coded, the object will be included only on the system identified by the SMF ID. If all members in a list are enabled only on a specific system, the list will be accessible only on that system.



Started Task Manager Schedule DefinitionThe Started Task Manager Schedule Definition is used to store information on when a resource is meant to be active. All resources are assumed to run 7x24. If the resource runs on a schedule other than 7x24, that schedule must be described to the STM in the Schedule table .:During STM initialization, this table will be searched for references to the resource. If the table contains no schedules for the resource, it is assumed that the resource should run 7x24.

If there are schedules for the resource, the TOD event traps for the schedules will be set and the STM will determine if the resource should currently be running. If the resource should be active, the STM will attempt to start it.

Conversely, if the resource should be inactive, the STM will attempt to stop it. The Schedule table is a keyed table, which uses SMF ID as one of the keys. This offers you the ability to define a unique set of schedules for the resource on each system. You can also define a default schedule if the resource runs at the same time on all systems. Any mixture of default and system specific schedules can be defined for the resource. A maximum of 20 schedules can be defined per resource per system.

Schedule Data

Resource Name The Resource Name of the resource. This is the first table key.

Key This is the second table key. Code DEFAULT to define a schedule for the resource on every system. If you have a schedule for a resource that is unique to a system, code the SMF ID of that system instead of the DEFAULT keyword.

Number This is a unique number for the resource schedule. Valid values are from 1 to 20. All of the schedules for a resource on a system must have a unique number. No more than 20 schedules can be defined for the resource on a system. If you have defined system specific schedules for the resource, schedule numbers may be reused on different systems.



Calendar This is the calendar variable associated with the schedule. If the schedule must account for calendar events, such as business days or holidays, code the name of the AF/OPERATOR system variable which describes the calendar in this field. If the schedule does not account for calendar events, code an asterisk (*).

The AF/OPERATOR system variable that controls the calendar must equate to a value of 0 or 1. One signifies that the calendar is active. Zero signifies that the calendar is inactive. The Automation Application variables, @APLBDAY -Business Day Flag and @APLHDAY - Holiday Flag, are examples of calendar variables. When a resource that runs on a schedule with calendaring is manipulated, the calendar variable for the schedule will be checked. If the calendar is off (0), the schedule event will be bypassed.

Start Only Calendar

The Start Only Calendar Field is used to designate a calendar that is checked only when the resource is started. This is a binary field (1,0); code a 1 to enable the Start Only Calendar feature for this schedule. The default is 0; both start and stop events will respect the calendar. If a resource is run on a schedule with calendaring and the active period crosses the midnight boundary, the calendar could be disabled when the stop event occurs. For example, if a resource is started at 6am on Tuesday, a business day, and is scheduled to be stopped at 2am on Wednesday, a non-business day, the stop would be bypassed by a schedule using a business day calendar. This requires the CSO flag. In the example, if the CSO flag had been enabled for the schedule, the resource would start on Tuesday, because the calendar is enabled, and would also stop on Wednesday, because the calendar is in effect only for starts. Enabling the CSO flag causes all stop events to take place, but start events will take place only if the calendar is active.



Stop Only Calendar

The Stop Only Calendar Field is used to designate a calendar that is checked only when the resource is stopped. This is a binary field (1,0); code a1 to enable the Stop Only Calendar feature for this schedule. The default is 0; both start and stop events will respect the calendar. If a resource is run on a schedule with calendaring and the active period for the resource crosses the midnight boundary, the calendar could be in different states when the scheduled start and stop events take place. Enabling the CPO flag causes all start events to take place, but stop events will take place only if the calendar is active.

Start Warning The amount of time, in the form HH:MM:SS, that the operator console should be notified before the STM automatically starts a resource. Code an asterisk (*) for this field if you do not want to warn the operator before automatically starting a resource.

Extended Start Warning

Specifies whether or not the start warning time for a resource can be extended by the operator. This field works in conjunction with the START_WARN time. This is a binary field (1,0); 1 signifies that the STM should display a WTOR after the start warning message, which allows the operator to extend or postpone the scheduled start of a resource. The default is 0; only a start warning message will be issued.

Stop Warning The amount of time, in the form HH:MM:SS, that the operator console should be notified before the STM automatically stops a resource. Code an asterisk (*) for this field if you do not want to warn the operator before automatically stopping a resource.

Extended Stop Warning

Specifies whether or not the stop warning time for a resource can be extended by the operator. This field works in conjunction with the STOP_WARN time. This is a binary field (1,0); 1 signifies that the STM should display a WTOR after the stop warning message, which allows the operator to extend or postpone the scheduled stop of a resource. The default is 0; only a stop warning message will be issued.



Schedule

If the active period for a resource crosses the midnight boundary, a separate schedule should be created for each day of the week. For example, if a resource is started Monday through Friday at 05:00:00 AM and stopped at 02:00:00 AM the next morning, the active period crosses the midnight boundary. If you were to code this information in a single schedule, the stop time would appear to be 3 hours before the resource was started:

START.TUE = 05:00:00 ==> Tuesday's Start TimeSTOP.TUE = 02:00:00 ==> Monday's Stop Time

because, the stop time of the day before will be misinterpreted as the stop time for the current active period. Instead, a schedule for each day should be defined as follows:

Schedule One:

START.MON = 05:00:00STOP.MON = *START.TUE = *STOP.TUE = 02:00:00

Schedule Two:

START.TUE = 05:00:00STOP.TUE = *START.WED = *STOP.WED = 02:00:00

START The time you want the resource to start, in the form of HH:MM:SS (24 hour military format), for each day of the week. Code an asterisk (*) if the resource does not have a start time for a particular day of the week.

STOP The time you want the resource to stop, in the form of HH:MM:SS (24 hour military format), for each day of the week. Code an asterisk (*) if the resource does not have a stop time for a particular day of the week.

Using the Service Subroutines



IntroductionOnce the automation table component of the STM has been defined, the information needed to manage resources for an environment is available to the STM service subroutines. To initiate the actual management of resources, the STM service subroutines must be activated.

Starting the Service SubroutinesThe STM is automatically started at AF/OPERATOR initialization time by the Application Manager which executes the @RCFINIT exec. This command file initializes the STM environment and executes @RCFMAIN to initialize and start all resources that should be running at the current time and date for that system; therefore, all started tasks defined to a system and scheduled to be running, but are not currently active, will be started. In addition, @RCFINIT will set up a command trap for the RCF operator command.

If AF/OPERATOR is already running, you can activate the STM before the next AF/OPERATOR recycle by issuing the following Application Manager command from the MVS console:

APL INIT RCF

Note: This assumes that the STM tables have been pre-loaded into storage by the Table Manager. If the STM tables have not been automatically loaded, issue the appropriate Table Manager commands, from the MVS console, to load the tables before you initialize the STM.


Controlling Started Task Manager Resources


The RCF command provides an operator interface to give you additional control over the resources defined to the STM. It is used to communicate with AF/OPERATOR and the STM service subroutines to control STM resources and display STM information about the resources from the MVS console.

For example, from the MVS operator console you can enter:

RCF START CICSPROD

at any time, to start the resource associated with the resource definition you named CICSPROD.

The resource name specified in the command is the same as the TASK_NAME field you coded in the Task Control table.

An asterisk (*) is treated as a wild card character, which allows you to specify groups of like-named resources. For example, the command:

RCF START CICS*

will start all resources defined with a TASK_NAME that begins the letters CICS.



RCF Command SyntaxThe following table shows the available RCF commands. To protect against unintentional command errors, certain function/task/option combinations are prohibited. This includes:

� Functions INIT, START, STOP, CYCLE, KILL, RECOVER, STARTWARN, STOPWARN, STARTSCHED, and STOPSCHED with task definitions ALL, *, or GROUP and options FORCE, IMMEDIATE, Command()1, or Cmdparm()2.

� Function SCHEDULE cannot be used with Task definitions ALL or * and option FORCE.

� Functions DEFINE and EXCEPT cannot be used with task definitions ALL or * with or without option FORCE.

FIGURE 4. RCF Command Syntax

1. Where command() = start() or stop()2. Where cmdparm() = parm(), addparm(), repparm(), stpparm(), or usrparm()

RCF function task optionINIT ALL FORCESTART * IMMMEDIATESTOP TASK_NAME PURGECYCLE TASK_ALIAS QUEUEKILL TASK # MAINT

PATTERN TYPE=typeCHKPNOCHKPNOLOCKNOTWOPASS

RESETMCF NOMCFRESETCCF NOCCFRESETSCF NOSCFRESETVTM NOVTM



RCF function task optionRESETDEV NODEVRESETCLASS NOCLASSRESETGROUP NOGROUPRESETRETRY NOBATCH

NOREADYNOCALENDAR

RECOVERSTARTWARN NOPRESTARTSTOPWARN NOPOSTSTARTSTARTSCHED NOPRESTOPSTOPSCHED NOPOSTSTOP

STCREATESTUPDATE LOGSTCLOSE NOLOGSTDESTROYLISTTASK |ALL |

SCOPE= |ONLY ||U |

ACTIVATEINACTIVATEMONITORY CONSOLE=console_idNOMONITOR WAIT=intervalDEFINE CONFIRM=sysidEXCEPT RECIPROCALAOCANCELUNLOCKSUBMITNOOP START(start_cmd)

STOP(stop_cmd)HELP PARM(start_parm)SHOW ADDPARM(start_add_parm)STATUS REPPARM(start_rep_parm)

STPPARM(stop_parm)



RCF function task optionUSRPARM(user_parm)

SCHED=scheduleDAY=weekday

SCHEDULE START=timeSTOP=timeSSAPARM(strtsched_parm)PSAPARM(stopsched_parm)

KEY=keywordGROUP XRF=xrf_wkld

JES=jes_wkldMSn=ms_wkld

LIST LIST=listname

ABENDARMBATCHCOUNTLOCKMISCNAMEPLEX

|=ALL |PREDECESSORS |=DEFINED |

|=NOTDEF ||=LIST |

RECOVERYSCHEDULESTART

DISPLAY STATUSSTOP



Parameters

Function - Required

Task - Required

Options - Optional

RCF function task option|=ALL |

SUCCESSORS |=DEFINED ||=NOTDEF ||=LIST |

TIMEVTAMMCFCCFSCFVTMDEVCLASSGROUP

ACTIVEINACTIVENOMONITORDEACTIVATEDOTHER

SHOW( STARTING )STOPPINGRECOVERINGBYPASSEDOKNOTOK



Functions

The function parameter is used to tell the STM which action to take against a resource. Many, but not all, functions have abbreviations. Acceptable abbreviations are noted with the function's description.

START Starts a resource defined to the STM immediately, rather than at the time specified in the resource definition. This function will not start a resource that is already active. No abbreviations of the START keyword are acceptable.

STOP Stops a resource defined to the STM immediately, rather than at the time specified in the resource definition. RCF STOP ALL, stops all STM resources in an orderly shutdown. No abbreviations of the STOP keyword are acceptable.

INIT Reinitializes a resource defined to the STM so that changes to the resource's definition will take effect immediately without affecting the status of other resources. The resource will be started automatically if it should be running, and likewise, stopped if it should not be running at the current time. No abbreviations of the INIT keyword are acceptable.

Initializing a resource causes all start/stop time-of-day traps to be set, native MVS command traps to be set, the time-of-day trap for recovery count reset to be set, STM resource status variables to be initialized and the resource to be started/stopped, if appropriate.

CYCLE Cycles a resource. The STM will stop the resource and then start it again. No abbreviations of the CYCLE keyword are acceptable.

KILL Issues an MVS Cancel command to stop the resource. Only resources that are cancellable and have the KILL function enabled can be cancelled by the STM. No abbreviations of the KILL keyword are acceptable.

RESETMCF Reinitializes Message Manager objects associated with the STM resource. This function is applicable to only those resources that have the Message Manager interface enabled. This function will be ignored for all other STM resources. No abbreviations of the RESETMCF keyword are acceptable.



RESETCCF Reinitializes Command Manager objects associated with the STM resource. This function is applicable to only those resources that have the Command Manager interface enabled. This function will be ignored for all other STM resources. No abbreviations of the RESETCCF keyword are acceptable.

RESETSCF Reinitializes Schedule Manager objects associated with the STM resource. This function is applicable to only those resources that have the Schedule Manager interface enabled. This function will be ignored for all other STM resources. No abbreviations of the RESETSCF keyword are acceptable.

RESETVTM Reinitializes VTAM Manager objects associated with the STM resource. This function is applicable to only those resources that have the VTAM Manager interface enabled. This function will be ignored for all other STM resources. No abbreviations of the RESETVTM keyword are acceptable.

RESETDEV Reinitializes Device Manager objects associated with the STM resource. This function is applicable to only those resources that have the Device Manager interface enabled. This function will be ignored for all other STM resources. No abbreviations of the RESETDEV keyword are acceptable.

RESETCLASS Reinitializes JES Manager job classes associated with the STM resource. This function is applicable to only those resources that have the JES Manager interface enabled. This function will be ignored for all other STM resources. No abbreviations of the RESETCLASS keyword are acceptable.

RESETGROUP Reinitializes JES Manager job groups associated with the STM resource. This function is applicable to only those resources that have the JES Manager interface enabled. This function will be ignored for all other STM resources. No abbreviations of the RESETGROUP keyword are acceptable.

RECOVER RECOVER is an internal function used to invoke the STM recovery process.

RESETRETRY RESETRETRY is an internal function used to reset the STM recovery retry count for a resource.

STARTWARN STARTWARN is an internal function used to invoke the STM start warning process.



STOPWARN STOPWARN is an internal function used to invoke the STM stop warning process.

STARTSCHED STARTSCHED is an internal function used to invoke the STM start schedule process.

STOPSCHED STOPSCHED is an internal function used to invoke the STM stop schedule process.

STCLOSE STCLOSE is an internal STM function used to delete an Omegaview status item.

STCREATE STCREATE is an internal STM function used to create an Omegaview status item.

STDESTROY STDESTROY is an internal STM function used to destroy an Omegaview status item.

STUPDATE STUPDATE is an internal STM function used to update an Omegaview status item.

LISTTASK An internal function used to store a list of task names, based on the specified search criteria, in the program stack.

ACTIVATE Changes a previously inactivated resource back to active status. This enables STM control of a resource and actions can once again be performed for the resource. Valid abbreviations are: ACT and A.

INACTIVATE Changes a resource to INACTIVE status. This effectively disables STM control of the resource; no further action can be taken for this resource until it is reactivated. Valid abbreviations are: INACT and I.

MONITOR Enables automatic recovery (monitoring) of a resource that has previously been set to NOMONITOR status. Valid abbreviations are: MON and M.

The command:

RCF MONITOR resource will not turn on automatic recovery for a resource that was originally defined to the STM as having recovery OFF.

NOMONITOR Turns off automatic recovery of a resource originally defined to the STM as having recovery ON. Valid abbreviations are: NOMON and N.



DEFINE Temporarily define a task to this system.

EXCEPT EXCEPT is used to temporarily except a resource from running on a system. This function will alter the in-storage copies of the STM control tables to define the resource with a KEYWORD of NONE. An excepted resource will no longer be managed by the STM. To re-enable STM control of a resource that has been excepted, an 'RCF INIT task_name FORCE' command must be issued. Valid abbreviations are: EX and E.

AOCAN AOCAN is used to cancel an outstanding AF/OPERATOR match. No abbreviations of the AOCAN keyword are acceptable.

UNLOCK UNLOCK is used to unlock the STM manipulation lock for the resource. This function is used to reset the lock in case of a STM failure while manipulating the resource. No abbreviations of the UNLOCK keyword are acceptable.

SUBMIT Invoke Batch Submit Process for a task.

NOOP Perform no operation, NoOp. Used to restore checkpointed control information, such as a FORCE or EXCEPT, for a task.

SCHEDULE SCHEDULE is used to temporarily alter a STM schedule for a resource. The TOD event trap affected by the schedule change will be deleted and reset. Each schedule change is in effect for only one schedule cycle; when the altered scheduled event occurs the TOD event trap will be deleted and reset with the original data held in the STM Schedule table. Valid abbreviations are: SCHED.

HELP Displays the STM on-line help file on the operator console. No abbreviations of the HELP keyword are acceptable.

SHOW Shows all AF/OPERATOR, STM created, traps associated with the resource. Valid abbreviations are: SH.

STATUS Issues a WTO to the MVS console that indicates the STM status for the specified resource. Valid abbreviations are: STAT and S.

DISPLAY Displays the requested STM information via WTO to the MVS console (see Display Options below). The default display is the same as the STATUS display as described above. Valid abbreviations are: DIS and D.



Resource Name

The resource name parameter is used to tell the STM which resources to manage. The aforementioned function will be performed for the resources specified with this parameter.

ALL The ALL keyword is used to specify all resources defined to the system. All resources known to the STM will be interrogated, those that have been defined to this system via the Task Control table will be chosen. An asterisk (*) is a synonym for the ALL keyword.

TASK_NAME A resource name precisely as coded in the Task Control table.

TASK_ALIAS A resource alias precisely as coded in the Task Control table.

TASK_# A resource number precisely as coded in the Task Control table.

PATTERN A resource name pattern, using an asterisk (*) as a wild card character. Any resource with a name or alias, TASK_NAME or TASK_ALIAS, that begins with the letters preceding the asterisk (*) and is defined to the system will be managed.

GROUP A keyword, which specifies that a group definition option is to follow. The resources included in a group are defined via the Task Control table. There are no abbreviations for the GROUP keyword. Valid group options are:

� KEY=keywordKEYWORD group as defined in the Task Control Table. Valid values for keyword are defined in Started Task Manager Task Definition - Control Data on page 70, KEYWORD Field.

� XRF=xrf_wkld XRF workload group as defined in the Task Control Table. Valid values for xrf_wkld are: ACT and ALT.

� JES=jes_wkldJES workload group as defined in the Task Control Table. Valid values for jes_wkld are: GLB and LCL.

� MSn=msn_wkldMS1 through MS4 workload groups as defined in the Task Control Table. Valid values for an MSn keyword are site specific.



Standard Options

The standard options are used to alter the normal STM processing of a function for a resource.

FORCE The FORCE option is used to force a resource that is not defined to a system onto that system. The FORCE option can also be used to force a STM function to complete. Specifying force will override all STM checks and pre-requisites. Valid abbreviations are: F.

The FORCE option can be used to:

� Override Task Control table definitions and force a resource to run on a system where it is not defined to run.

� Cancel outstanding STM function requests for the resource.

� Ignore resource predecessor checks when starting a resource.

� Ignore VTAM dependency checks when starting a resource.

� Ignore IPL verification when starting an IPL Only task.

� Ignore resource successor checks when stopping a resource.

� Ignore abort/bypass return codes from user exits.

Note: If a resource is forced onto a system via an RCF INIT or RCF START command, the STM will update the in-storage copy of the Task Control table and define the resource to the system. Any time after this, you need not use the FORCE option on the RCF command to manage the resource.

LIST A keyword, which specifies that a resource list option is to follow. The resources included in the resource list are defined by the user in the Task List Table. There are no abbreviations for the LIST keyword.

The LIST keyword requires the following argument:

LIST=listname

Specify a valid user defined list name for the listname argument.

List names are defined by the user in the Task List Table.



This control definition change is checkpointed and remains in effect until the next IPL or until AF/OPERATOR is started in manual mode between system IPL's. After a system IPL, the definition for the resource reverts to that specified in the Task Control Table.

IMMEDIATE The IMMEDIATE option is used to bypass predecessor and VTAM dependency checks when starting a resource and successor checks when stopping a resource. Valid abbreviations are: I.

PURGE Deletes all STM schedule and command traps for a resource after a successful stop. Used for workload movement.

QUEUE The QUEUE option is used to queue a function request for a resource, if another function is already active for the resource. Once the previous function completes and the queued function can acquire the resource manipulation lock, the function request will be processed. Queued function requests are processed in FIFO order. There are no abbreviations for the QUEUE option.

MAINT The MAINT option is used to manage only those resources that have been defined with a KEYWORD of AUTO. This is a special option used to IPL a maintenance system. Valid abbreviations are: M.

TYPE=type Selects the specified task type. Options:� CHI/CHLINITIATOR Channel Initiator� CHL/CHANNEL Channel� CS/CMDSERVER Command Server� DB/DATABASE Database� DB2 DB2 Subsystem� JPRT/JESPRINTER JES Printer� LSTR/LISTENER Listener� QMGR Queue Manager� SP/TABLESPACE Tablespace� SPRT/SNAPRINTER SNA/RJP Printer� TASK Task� */ALL All types



CHKP The CHKP option is used perform a checkpoint restart of the STM. This is a special option used by the Application Manager when processing a checkpoint restart. There are no abbreviations for the CHKP option.

NOCHKP Bypasses check-pointing of dynamic changes such as defining a task to the system or updating a resource schedule.

NOLOCK Bypasses lock processing when changing task state. use for a pre-initialization function.

NOTWOPASS Bypasses objects defined with the TWOPASS keyword. When used with GROUP, LIST, or a task name pattern, the requested function will not be performed for uninitialized tasks that are defined with the TWOPASS keyword that are members of the group.

NOMCF The NOMCF option is used to bypass the Message Manager interface for a resource. This option is applicable to only those resources that have the Message Manager interface enabled. There are no abbreviations for the NOMCF option.

NOCCF The NOCCF option is used to bypass the Command Manager interface for a resource. This option is applicable to only those resources that have the Command Manager interface enabled. There are no abbreviations for the NOCCF option.

NOSCF The NOSCF option is used to bypass the Schedule Manager interface for a resource. This option is applicable to only those resources that have the Schedule Manager interface enabled. There are no abbreviations for the NOSCF option.

NOVTM The NOVTM option is used to bypass the VTAM Manager interface for a resource. This option is applicable to only those resources that have the VTAM Manager interface enabled. There are no abbreviations for the NOVTM option.



NODEV The NODEV option is used to bypass the Device Manager interface for a resource. This option is applicable to only those resources that have the Device Manager interface enabled. There are no abbreviations for the NODEV option.

NOCLASS The NOCLASS option is used to bypass the JES Manager interface for a resource. This option is applicable to only those resources that have the JES Manager interface enabled. There are no abbreviations for the NOCLASS option.

NOGROUP The NOGROUP option is used to bypass the JES Manager interface for a resource. This option is applicable to only those resources that have the JES Manager interface enabled. There are no abbreviations for the NOGROUP option.

NOBATCH Bypass Batch Process for a task.

NOREADY Bypass Scheduled Stop Batch Ready Check.

NOCALENDAR Bypass calendar check for scheduled event.

NOPRESTART The NOPRESTART option is used to bypass the pre-start exit for a resource. This option is applicable to only those resources that have a pre-start exit enabled. There are no abbreviations for the NOPRESTART option.

NOPOSTSTART The NOPOSTSTART option is used to bypass the post-start exit for a resource. This option is applicable to only those resources that have a post-start exit enabled. There are no abbreviations for the NOPOSTSTART option.

NOPRESTOP The NOPRESTOP option is used to bypass the pre-stop exit for a resource. This option is applicable to only those resources that have a pre-stop exit enabled. There are no abbreviations for the NOPRESTOP option.



NOPOSTSTOP The NOPOSTSTOP option is used to bypass the post-stop exit for a resource. This option is applicable to only those resources that have a post-stop exit enabled. There are no abbreviations for the NOPOSTSTOP option.

LOG Enable AO logging for match.

NOLOG Disable AO logging for match

SCOPE Specify ALL to include all of the successors to the resource in function processing. The default is ONLY or U. The requested function will be processed for the specified resource only.

CONSOLE=console_id The CONSOLE option is used to specify the console to receive STM messages for a function. Specify either a valid console ID or the device address of the console for the console_id argument. There are no abbreviations for the CONSOLE option.

WAIT=interval The WAIT option is used to wait for asynchronous resource state changes to occur. This option is used primarily for internal function requests. The interval argument is used specify a time interval in the form HH:MM:SS. This argument is optional; the default wait interval is 10 minutes. There are no abbreviations for the WAIT option.

CONFIRM=sys Confirm requested function complete. Send confirmation to system SYSID.

RECIPROCAL Confirm option used to avoid deadlocks for tasks in a reciprocal relationship.



START(start_cmd) The START() option is used to override the defined STM start command when starting a resource. The new start command for the resource, start_cmd, must be fully qualified and be enclosed in parenthesis. For Example:RCF START JES3 START(S JES3,MODE=TEST)

START() temporarily overrides the defined start command for the resource. Start_cmd is not saved and must be reentered with each RCF START command. The start_cmd, can be typed just as if it were a native MVS command, including imbedded quotes. There are no abbreviations for the START() keyword.

STOP(stop_cmd) The STOP() option is used to override the defined STM stop command when stopping a resource. The new stop command for the resource, stop_cmd, must be fully qualified and be enclosed in parenthesis. For Example:RCF STOP JES3 STOP(\RETURN,DUMP)

STOP() temporarily overrides the defined stop command for the resource; stop_cmd is not saved and must be reentered with each RCF STOP command. There are no abbreviations for the STOP() keyword.



PARM(start_parm) The PARM() option is used when starting a resource, to override the defined STM start command parameters for the resource. The overriding parameters for the start command, start_parm, must be fully qualified and be enclosed in parenthesis. For example:RCF START JES3 PARM(MODE=TEST,INISH=TEST)

PARM() temporarily overrides the defined start command parameters for the resource; start_parm is not saved and must be reentered, if needed again. Multiple parameters can be entered, separated by commas. The comma preceding the first parameter need not be specified. There are no abbreviations for the PARM() keyword.

ADDPARM(start_add_parm)

The ADDPARM() option is used when starting a resource, to add a parameter to the defined STM start command for the resource. The additional parameters for the start command, start_add_parm, must be fully qualified and be enclosed in parenthesis. For example: RCF START SARSTC ADDPARM(ENV=MBF)

ADDPARM() temporarily adds a parameter to the defined start command for the resource; start_add_parm is not saved and must be reentered, if needed again. Multiple parameters can be entered, separated by commas. The comma preceding the first parameter need not be specified. There are no abbreviations for the ADDPARM() keyword.



REPPARM(start_rep_parm)

The REPPARM() option is used when starting a resource to replace a parameter in the defined STM start command for the resource. The parameter to replace in the start command, start_rep_parm, must be fully qualified and be enclosed in parenthesis. For Example: RCF START SARSTC REPPARM(ENV=MBF)

REPPARM() temporarily replaces a parameter in the defined start command for the resource; start_rep_parm is not saved and must be reentered, if needed again. There are no abbreviations for the REPPARM() keyword.

STPPARM Adds a parameter to the standard STM stop command for a task.

USRPARM User parameter that is passed unaltered to the STM user exits. This parameter is not used by the STM itself.

SCHED=schedule The SCHED option is used to specify a specific resource schedule. The SCHED option can be used with the SCHEDULE and DISPLAY functions to identify a specific schedule for a resource that has multiple schedules. The schedule argument specifies the desired schedule number for the resource. There are no abbreviations for the SCHED option.

DAY=weekday The DAY option is used in conjunction with the SCHEDULE function to specify the day of the week when altering a resource schedule. The weekday argument must specify a three character day-of-week (SUN MON TUE WED THU FRI SAT). There are no abbreviations for the DAY option.



START=time The START option is used in conjunction with the SCHEDULE function to specify the new start time for the resource schedule. The time argument must specify a time in the form: HH:MM:SS (24-Hour Military Format). There are no abbreviations for the START option.

Note: An asterisk (*) can be specified for the time argument if you wish to bypass the scheduled event. Specifying an asterisk (*) for the time argument will cause the STM to delete the TOD event trap for the scheduled event.

STOP=time The STOP option is used in conjunction with the SCHEDULE function to specify the new stop time for the resource schedule. The time argument must specify a time in the form: HH:MM:SS (24-Hour Military Format). There are no abbreviations for the STOP option.

Note: An asterisk (*) can be specified for the time argument if you wish to bypass the scheduled event. Specifying an asterisk (*) for the time argument will cause the STM to delete the TOD event trap for the scheduled event.

SSAPARM Adds the specified RCF command option to the embedded STARTSCHED command, for the task, in the specified schedule trap.

PSAPARM Adds the specified RCF command option to the imbedded STOPSCHED command, for the task, in the specified schedule trap.



Display Options

The display options are to be used in conjunction with the DISPLAY function mentioned previously. Display options are ignored for any other STM function.

ABEND Displays task Recovery information.

ARM Displays task ARM status.

BATCH Displays task Batch Process information.

COUNT Displays task Recovery count.

LOCK Displays the current state of the manipulation lock for the resource. Valid abbreviations are: L.

ASOA096I AFTCI 1002 - LOCK: UNLOCKED

MISC Displays the STM Miscellaneous information for the resource. There are no abbreviations for the MISC option.ASOA094I RCF Miscellaneous Display 588

ASOA094I RCF Miscellaneous Information for JES2:

ASOA094I MVS Cmds.... Y Cmd Char.... ,

ASOA094I MCF......... N SUB=MSTR.... Y

ASOA094I CCF......... N Kill........ N

ASOA094I SCF......... N IPL Only.... N

ASOA094I VTM......... N Sub Task.... N

ASOA094I DEV......... N OMV Updates. Y

ASOA094I Job Class... *

ASOA094I Job Group... *

ASOA094I Notify Exit. *

ASOA094I Notify Users *

ASOA094I Problem Exit * Console..... *

ASOA094I Monitor Exit * User Var.... *

ASOA094I Active...... *

NAME Displays the resource name. Valid abbreviations are: N.

PLEX Displays task status (Sysplex).



PREDECESSORS Displays task Predecessors. Options are:� ALL - Displays all predecessors.� DEFINED - Displays only predecessors defined

to this system. This is the default.� NOTDEFINED - Displays only predecessors not

defined to this system.� LIST - Displays only predecessors defined to this

system and not in an ACTIVE state.

RECOVERY Displays information from the last resource recovery process. Valid abbreviations are: REC.ASOA098I RCF Recovery Information for JES2

ASOA098I Retry count. 0

ASOA098I Retry cycle. 24:00:00

ASOA098I Pre Exit.... *

ASOA098I Post Exit... *

ASOA098I Job Name.... *

ASOA098I System ID... *

ASOA098I

ASOA098I Message 1... IEF450I



ASOA098I Message 4... *



RETRIES Displays the current recovery count for the resource. Valid abbreviations are: RET and R.

ASOA096I OMIIMVS 1002 - COUNT: 1



SCHEDULE Displays the STM Schedule information for the resource. Valid abbreviations are: SCHED.ASOA093I RCF Schedule Information for CICS2351 schedule 1:

ASOA093I Key...... DEFAULT Start Only Clnd. N

ASOA093I Calendar. @APLBDAY Stop Only Clnd... N

ASOA093I Start Warning.* Start Extend. N

ASOA093I Stop Warning. * Stop Extend.. N

ASOA093I

ASOA093I Start Stop

ASOA093I Sunday.......... * *

ASOA093I Monday.......... 04:00:00 20:00:00

ASOA093I Tuesday......... 04:00:00 20:00:00

ASOA093I Wednesday....... 04:00:00 20:00:00

ASOA093I Thursday........ 04:00:00 20:00:00

ASOA093I Friday.......... 04:00:00 20:00:00

ASOA093I Saturday........ * *

START Displays the STM Start information for the resource. There are no abbreviations for the START option.ASOA090I RCF Start Information for JES2:



ASOA090I WTOR Exit... *

ASOA090I Command..... S JES2,MEMBER=OS2A023

ASOA090I Interval.... 00:10:00

ASOA090I Verification $HASP492

STATUS Displays the current resource status. Valid abbreviations are: STAT.

STOP Displays the STM Stop information for the resource: There are no abbreviations for the STOP option.ASOA091I RCF Stop Information for JES2:



ASOA091I WTOR Exit... *

ASOA091I Command..... P JES2

ASOA091I Interval.... 00:00:45

ASOA091I Verification IEF404I JES2



SUCCESSORS Displays task Successors. Options are:� ALL - Displays all successors.� DEFINED - Displays only successors defined to

the system. This is the default.� NOTDEFINED - Displays only successors not

defined to this system� LIST - Displays only successors defined to this

system and not in an INACTIVE state.

TIME Displays the start time for the resource. Valid abbreviations are: T.

VTAM Displays task VTAM Node dependencies.

MCF Displays the status of the Message Manager objects for the resource.

CCF Displays the status of the Command Manager objects for the resource.

SCF Displays the status of the Schedule Manager objects for the resource.

VTM Displays the status of the VTAM Manager objects for the resource.

DEV Displays the status of the Device Manager objects for the resource.

CLASS Displays task JES Manager Class Status.

GROUP Displays task JES Manager Group Status.



Resource Status

The STM keeps status information for each resource that it manages. When an RCF STATUS or RCF DISPLAY command is received, the STM will display its current status for the resource.

A resource can be in any one of the following states:

SHOW Display filtering options:� ACTIVE Display active tasks only.� INACTIVE Display inactive tasks only.� NOMONITOR Display NOT MONITORED

tasks only.� DEACTIVATED Display DE-ACTIVATED

tasks only.� OTHER Display miscellaneous

status tasks only.� STARTING Display starting tasks only.� STOPPING Display stopping tasks only.� RECOVERING Display recovering tasks

only.� BYPASSED Display bypassed tasks

only.� OK Display healthy tasks only.� NOTOK Display problem tasks only.

Note: Multiple options may be specified with the parentheses. For example: SHOW(INA NOM DEACT)

DEFINED The STM knows about the resource, but does not know whether the resource is active or inactive.

INACTIVE The resource is not active.

INACTIVE ON SCHEDULE # The resource is not active, as defined by a resource schedule.

ACTIVE The resource is active or has been enabled.



ACTIVE ON SCHEDULE # The resource is active, as defined by a resource schedule.

AUTO-START SCHEDULED The STM has scheduled the resource to be started at a future time. This status is set when the STM initializes a resource that runs on a schedule and the current time is before the next scheduled start time.

AUTO-STOP SCHEDULED The STM has scheduled the resource to be stopped at a future time. This status is set when the STM initializes a resource that runs on a schedule and the current time is before the next scheduled stop time.

NOT MONITORED The resource is no longer being monitored by the STM. An RCF NO MONITOR command has been issued for the resource. The STM will not react to changes in the resource’s state, all recovery traps are disabled until an RCF MONITOR command has been issued against the resource.

DE-ACTIVATED The resource is no longer under the control of the Started Task Manager. An RCF INACT command has been issued for the resource. The Started Task Manager will not process functions for the resource until the resource is re-activated.

UNKNOWN The resource's status is unknown. This is usually the case if the STM has not fully initialized.

START ABORTED The STM start of the resource has been aborted. This status is set when a resource fails to start and the operator replies Abort to the start verification WTOR. This status is also set if a user exit aborts the start of the resource.



START FAILED The STM start of the resource has failed. This status is set when a resource fails to start and the operator replies Up to the start verification WTOR and the resource is not in an active state. This status is also set if a user exit returns an invalid return code.

START COMMAND JCL ERROR

The STM encountered a JCL error while starting the resource. This status is set when the STM has captured a start command JCL error WTO after issuing the start command for the resource. The STM start command or the resource's JCL must be changed before the STM will be able to start the resource.

STOP ABORTED The STM stop of the resource has been aborted. This status is set when a resource fails to stop and the operator replies Abort to the stop verification WTOR. This status is also set if a user exit aborts the stop of the resource.

STOP FAILED The STM stop of the resource has failed. This status is set when a resource fails to stop and the operator replies Down to the stop verification WTOR and the resource is not in an inactive state. This status is also set if a user exit returns an invalid return code.

RECOVERY ABORTED A recovery process has failed due to the recovery retry count being exceeded. The STM has asked for permission to proceed with the recovery, but has been stopped via operator intervention.

RECOVERY FAILED A recovery process has failed due to the resource not stopping.

RECOVERY OVERRIDDEN A recovery process has been overridden by a user exit.

RECOVERY BYPASSED A recovery process has been bypassed by a user exit.



STARTING The STM is in the process of starting the resource. The resource will remain in STARTING status until: all defined pre-requisites have been met, a START command has been issued and a start verification message has been received.

STARTING: WAITING CONFIRMATION REPLY

The STM is in the process of starting the resource, however a WTOR was issued to the operator console pending intervention before STM will continue with starting the resource.

STARTING: WAITING AUTO-START WARNING

The STM is in the process of starting the resource. A start warning message has been issued to the operator console.

STARTING: WAITING PREDECESSORS

The STM is in the process of starting the resource. The predecessors to the resource are not yet active.

STARTING: WAITING VTAM RESOURCES

The STM is in the process of starting the resource. The VTAM nodes needed by the resource are not yet active.

STARTING: RUNNING PRE-START EXIT

The STM is in the process of starting the resource. The pre-start exit is being executed.

STARTING: WAITING START VERIFICATION

The STM is in the process of starting the resource. The start command has been issued and the STM is awaiting start verification.

STARTING: RUNNING START-WTOR EXIT

The STM is in the process of starting the resource. The start command has been issued, the verification message has not been received, and the STM is processing the start WTOR exit.

STARTING: WAITING VERIFICATION REPLY

The STM is in the process of starting the resource. The start command has been issued, the verification message has not been received, and the STM is awaiting a reply to the start verification WTOR.

STARTING: RUNNING POST-START EXIT

The STM is in the process of starting the resource. The post-start exit is being executed.



STARTING: RUNNING TASK MONITOR EXIT

The STM is in the process of starting the resource. The task monitor exit is being executed.

STARTING: RUNNING BATCH CHECK EXIT

The STM is in the process of starting the resource. The batch check exit is being executed.

STARTING: WAITING BATCH COMPLETE REPLY

The STM is in the process of starting the resource. The batch not complete WTOR has been issued and the STM is waiting for the operator to reply to the outstanding reply-id.

STOPPING The STM is in the process of stopping the resource. The resource will remain in STOPPING status until: all defined pre-requisites have been met, a STOP command has been issued and a stop verification message has been received.

STOPPING: WAITING AUTO-STOP WARNING

The STM is in the process of stopping the resource. A stop warning message has been issued to the operator console.

STOPPING: WAITING SUCCESSORS

The STM is in the process of stopping the resource. The successors to the resource are not yet inactive.

STOPPING: RUNNING PRE-STOP EXIT

The STM is in the process of stopping the resource. The pre-stop exit is being executed.

STOPPING: WAITING STOP VERIFICATION

The STM is in the process of stopping the resource. The stop command has been issued and the STM is awaiting stop verification.

STOPPING: RUNNING STOP-WTOR EXIT

The STM is in the process of stopping the resource. The stop command has been issued, the verification message has not been received, and the STM is processing the stop WTOR exit.

STOPPING: WAITING VERIFICATION REPLY

The STM is in the process of stopping the resource. The stop command has been issued, the verification message has not been received, and the STM is awaiting a reply to the stop verification WTOR.



STOPPING: RUNNING POST-STOP EXIT

The STM is in the process of stopping the resource. The post-stop exit is being executed.

STOPPING: RUNNING TASK MONITOR EXIT

The STM is in the process of stopping the resource. The task monitor exit is being executed.

STOPPING: RUNNING BATCH SUBMIT EXIT

The STM is in the process of stopping the resource. The batch submit exit is being executed.

STOPPING: RUNNING BATCH READY EXIT

The STM is in the process of stopping the resource. The batch ready exit is being executed.

STOPPING: WAITING BATCH READY POSTING

The STM is in the process of stopping the resource. The STM is waiting for the batch ready requirement to be met within the user-defined wait period.

STOPPING: WAITING BATCH READY REPLY

The STM is in the process of stopping the resource. The STM has issued a WTOR indicating that the task cannot be stopped due to the batch ready status not being confirmed. The STM waits for the operator to reply.

RECOVERING The STM is in the process of recovering the resource. The resource will remain in RECOVERING status until once again active.

RECOVERING: RUNNING PROBLEM EXIT

The STM is in the process of recovering the resource. The problem exit is being executed.

RECOVERING: WAITING AUTHORIZATION

The STM is in the process of recovering the resource. The retry count has been exceeded and the STM is awaiting the operator reply to continue the recovery process.

RECOVERING: RUNNING PRE-RECOVERY EXIT

The STM is in the process of recovering the resource. The pre-recovery exit is being executed.

RECOVERY: RUNNING POST-RECOVERY EXIT

The STM is in the process of recovering the resource. The post-recovery exit is being executed.



BYPASSED: MANUAL MODE The STM has bypassed the start of the resource during a manual IPL. The resource will not be started until the automation processing flag is set to AUTO=ON and an RCF INIT command is issued for the resource.

BYPASSED: BY SCHEDULE n The Started Task Manager has bypassed a scheduled event for the resource on schedule n because the calendar for the schedule is disabled. This status is set for those resources that run on a schedule with calendaring, if an event occurs when the calendar is disabled. For example, if a resource runs only on business days and start event occurs on a holiday, the start will be bypassed by the schedule n.

BYPASSED: ALREADY ACTIVE IN SYSPLEX

The STM has bypassed the start of the resource because it has determined that the resource is already active in the Sysplex.

BYPASSED: CF STRUCTURE UNAVAILABLE

The STM was unable to access the Coupling Facility to determine the current state of the resource; subsequently no further action will be taken for the resource.

BYPASSED: NON-BUSINESS DAY

The STM has bypassed a scheduled event for the resource because the calendar for the schedule is disabled.

BYPASSED: USER START EXIT

The STM has bypassed the start of the resource because of a user pre-start exit.

BYPASSED: USER STOP EXIT The STM has bypassed the stop of the resource because of a user pre-stop exit.

NOT DEFINED TO THIS SYSTEM

The resource is known to the STM, but is not defined to run on this system.


STM Reporting Function


This section describes the Start/Stop commands and Predecessor/Successor reporting functionality.

The Started Task Manager Start/Stop Commands Report lists down the STM tasks and their start and stop commands based on input selection criteria. It also reports the keyword, workload, SMFID, and CPUID details for the selected tasks. This report is generated in the batch environment.

The Started Task Manager Predecessor/Successor Report lists down the STM tasks and their eligible predecessors and successors, based on input selection criteria. It also reports the keyword, workload, SMFID and CPUID details for the selected tasks. This report is all generated in the batch environment.

Inputs

KEYWORD

Commands are entered substituting for the KEYWORD value. Valid values for KEYWORD are:

� ALL

� AUTO

� NONE

� BLANK

� MANUAL

� INTERNAL

� TWOPASS

� N/A - Implies select all values. For example, ALL, AUTO, NONE, BLANK, MANUAL, INTERNAL, TWOPASS

The following rules apply:

� If a value is not specified, the default will be - ALL, AUTO, BLANK.

� Multiple values can be specified. The multiple values should be specified as a string within quotes and space delimited E.g. 'ALL AUTO NONE BLANK'.



� If N/A is specified as one of the multiple values then input is forced to N/A.

JCL Parameter

The input JCL parameter is:

KEYWORD

Note: A task is selected for reporting if the task keyword is in the list of values specified for the input keyword parameter.

Keyword Example

The following example shows you how the process works.

Assumptions

TASKA is defined with KEYWORD=AUTO

TASKB is defined with KEYWORD=ALL

TASKC is defined with KEYWORD=NONE

TASKD is defined with KEYWORD=BLANK

TASKE is defined with KEYWORD=MANUAL

TASKF is defined with KEYWORD=INTERNAL

TASKG is defined with KEYWORD=TWOPASS

Results� If input keyword = ' ' then TASKA, TASKB, and TASKD are selected.

� If input keyword = N/A then all the tasks are selected.

� If input keyword = 'MANUAL INTERNAL TWOPASS NONE' then TASKC, TASKE, TASKF, and TASKG are selected.



WORKLOADS

XRF Workload

Workloads are entered substituting for the XRF WORKLOAD value. Valid values for XRF WORKLOAD are:

� ACT

� ALT

� N/A - Implies ignore this parameter


� If no value is specified, default will be - N/A.

� Multiple values can be specified. The multiple values should be specified as a string within quotes and space delimited E.g. 'ACT ALT'.


JCL Parameter

The input JCL Parameter is:

XRF

JES Workload

Valid values for JES WORKLOAD are:

� GLB

� LCL

� SAG




� Multiple values can be specified. The multiple values should be specified as a string within quotes and space delimited E.g. 'GLB LCL SAG'.




JCL Parameter

The input JES Parameter is:

JES

MSn Workload

Valid values for MSn WORKLOAD are:

� User Specified Value




� Multiple values can be specified. The multiple values should be specified as a string within quotes and space delimited e.g. 'ABC DEF'.


JCL Parameter

The input MSn Parameter is:

MSn

Note: A task is selected for reporting if any of the task XRF workload or task JES workload or task MSn workload matches the corresponding input XRF workload or input JES workload or input MSn workload. This check is done only when the task keyword is not specified i.e. not ALL/AUTO/NONE/INTERNAL/MANUAL/TWOPASS.

Workload Example

Assumptions

TASKA is defined with XRF=ACT and JES=' '

TASKB is defined with XRF=ALT and JES=' '

TASKC is defined with JES=GLB and XRF=' '

TASKD is defined with JES=LCL and XRF=' '

TASKE is defined with JES=SAG and XRF=' '



TASKF is defined with XRF='' and JES=' '

Results

If input xrf = 'ACT' and input jes = '' then TASKA is selected.

If input xrf = 'ALT' and input jes = 'GLB LCL' then TASKB, TASKC, and TASKD are selected.

I input xrf = ' ' and input jes = ' ' then all the tasks are selected.

LOCATION

SMFID

Valid values for SMFID are:





� Multiple values can be specified. The multiple values should be specified as a string within quotes and space delimited E.g. 'SYSA SYSB'.


JCL Parameter

The input SMFID Parameter is:

SMFID

CPUID

Valid values for CPUID are:







� Multiple values can be specified. The multiple values should be specified as a string within quotes and space delimited E.g. '1123 1125'.


JCL Parameter

The input CPUID Parameter is:

CPUID

Note: A task is selected for reporting if the task has at least one SMFID in common with the input SMFID parameter. Similar is the case with CPUID. Tasks defined with KEYWORDS other than BLANK and any workload specification can potentially run on any SMFID. A task is selected for reporting if either the SMFID criteria or the CPUID criteria are met.

Location Examples

Assumptions

TASKA is defined with KEYWORD=BLANK, SMFID='SYSA SYSB' and CPUID=' '

TASKB is defined with KEYWORD=BLANK, CPUID='1123 1124' and SMFID=' '

TASKC is defined with KEYWORD=BLANK, SMFID=' ' and CPUID =' '

TASKD is defined with KEYWORD=AUTO, SMFID=' ' and CPUID =' '

Results

If input keyword = N/A, input smfid = SYSA and input cpuid = ' ' then TASKA and TASKD selected.

If input keyword = N/A, input smfid = SYSD and input cpuid = ' ' then TASKD is selected.

If input keyword = N/A, input smfid = ' ' and input cpuid = 1123 then TASKB and TASKD are selected.

If input keyword = N/A, input smfid = ' ' and input cpuid = 1150 then TASKD is selected.



If input keyword = N/A, input smfid = SYSA and input cpuid = 1123 then TASKA, TASKB, and TASKD will be selected.

If input keyword = N/A, input smfid = ' ' and input cpuid = ' ' then all the tasks are selected.

EXCEPTION

Valid values for EXCEPTION are:





� Multiple values can be specified. The multiple values should be specified as a string within quotes and space delimited E.g. 'SYSA SYSB'.


JCL Parameter

The input JCL Parameter is:

EXCEPT

Note: A task is selected for reporting if the task does not run on an SMFID in the list values specified for the input exception parameter.

Exception Examples

Assumptions

TASKA is defined with KEYWORD=AUTO and EXCPT=SYSA

TASKB is defined with KEYWORD=BLANK, SMFID=SYSA, and EXCP=SYSA

TASKC is defined with KEYWORD=BLANK, SMFID=SYSB

TASKD is defined with KEYWORD=BLANK, SMFID=SYSC, and EXCP=SYSB



Results

If input keyword = N/A and input exception = SYSA then TASKA, TASKC, and TASKD are selected.

If input keyword = N/A and input exception = SYSB then TASKD is selected.

If input keyword = N/A and input exception = '' then TASKA, TASKC, and TASKD will be selected.

Outputs

SELECTION DETAILS

The Selection detail is the user input, with the exception when N/A is a value within a list of multiple values. In this case N/A is displayed. The unspecified inputs are reported with the default values.

Example

Selection Details:

KEYWORD Specified ALL AUTO BLANK

XRF Workload Specified N/A

JES Workload Specified N/A

MS1 Workload Specified N/A




SMFIDs Specified N/A

CPUIDs Specified N/A

EXCEPTIONs Specified N/A



TASK DETAILS

Task Name Name of the selected task.

Keyword Keyword of the selected task

Work Load Workload details of the selected task. These are reported as JES=GLB, XRF=ACT, etc.

SMFID(s) The SMFIDs where the task can run. If the task can run on all the SMFIDs defined to IRM then 'ALL' is reported. If the task cannot run on any SMFID defined to IRM then 'N/A' is reported. For example:

Assumptions

TASKA is defined with KEYWORD=BLANK, SMFID='SYSA SYSB', and EXCPT=' '

TASKB is defined with KEYWORD=BLANK, SMFID=SYSA, and EXCPT=SYSA

TASKC is defined with KEYWORD=BLANK, SMFID=' ' and KEYWORD=' '

TASKD is defined with KEYWORD=AUTO, SMFID=' ', and KEYWORD=' '

Results

If input keyword = N/A and all other inputs default

SMFIDs for TASKA - SYSA, SYSB

SMFIDs for TASKB - N/A

SMFIDs for TASKC - N/A

SMFIDs for TASKD - ALL

CPUID(s) The CPUIDs where the task can run. If no CPUIDs are defined, N/A is reported.

Start/Stop Commands

The selected task’s Start/Stop Commands.



SUMMARY DETAILS

The total defined tasks and the total selected tasks are reported.

Example

Summary Details:

Total No Of Tasks Defined... 88No Of Tasks Selected........ 39


RCF Command On-line Help


On-line help for the STM RCF command is available anytime. To display on-line help for the RCF command, enter the following command at the MVS operator console:

RCF HELP

The STM will then display the RCF command syntax followed by a brief explanation of each of the keywords associated with the command.



Message Manager 149

Message Manager

IntroductionThe Message Manager is a facility that allows you to manage WTO, Write To Operator, and WTOR, Write To Operator with Reply, system messages. The Message Manager is used to create and manage instruction rules, called traps, that recognize system messages as they appear. The Message Manager and message traps allow you to:

� Consolidate messages into message groups.� Suppress a message or a group of messages.� Automatically react to system messages.

The Message Manager offers a wide variety of options which allow you to control what portion of your message management activities are enabled on each system. The Message Manager can enable a message trap based on keyword groups, workload groups or on an individual system identified by SMF or CPU ID. Each message is treated as a unique object that can be grouped with other similar messages or managed by itself. Messages that are to be managed by the Message Manager are identified by a WTO Pattern. The WTO Pattern describes the actual text of the message. The text of the message can be qualified to any extent appropriate; the message can be identified from as little as its message ID up to the full text of the message. The WTO Pattern allows you to specify as much of the message text as is needed to uniquely identify the message.

2


The Message Manager allows you to limit the scope of a message trap by defining triggering conditions. Triggering conditions can be used to limit message management activities to messages issued by specific jobs, job types, or job classes. The message trap can also be limited to only recognizing messages with certain route or descriptor codes, messages sent to specific consoles, or messages received from specific systems. Finally, the triggering conditions can be used to limit message management to only certain days of the week.

The Message Manager can be used to automatically react to console messages by defining an action to take when a message is received. Any one of the following actions can be defined for a message managed by the Message Manager:

� Immediate Actions - Allow you to suppress messages and to add or replace route and descriptor codes.

� Extended Actions - Allow you to issue MVS operator commands or execute AF/OPERATOR command files containing automation routines.

� Peer-to-Peer Support - Offers an interface to Candle's Peer-to-Peer Facility to send a message to a remote system.

Chapter ContentsMessage Manager Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151Message Manager Message Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . 153Using the Service Subroutines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171Controlling Message Manager Resources . . . . . . . . . . . . . . . . . . . . . . . . 172

Message Manager 151

Message Manager Components


The Message Manager has three components. They are:

� Message definition


� AF/OPERATOR system variables.

Message DefinitionMessage Manager tables hold information used to create traps for the messages you want to manage with the Message Manager. All of the tables are members of the Automation Application table dataset, hilev.RKAUTBLR. The tables are created by the user via the IRM ISPF Interface. The interface enables the user to populate the table fields with the appropriate information for each message definition. The section, Message Manager Message Definition section beginning on page 153, describes the Message Manager automation tables in detail.

Service SubroutinesMessage Manager service subroutines are AF/OPERATOR command files used to perform a variety of functions for the messages controlled by the Message Manager. These functions include:

� Add a message trap

� Delete a message trap

� Enable/Disable an existing message trap

� Enable/Disable suppression of a message



The service subroutines are comprised of the following execs:

AF/OPERATOR System VariablesThe Message Manager creates the following AF/OPERATOR system variables to track message status over time:

@MCFINIT This exec initializes the Message Manager environment: creating an MVS console command, called MCF, that allows you to perform various management functions on a single message or group of messages, performing clean-up activities, and invoking @MCFMAIN at AF/OPERATOR start-up to initialize and add all of the message management traps controlled by the Message Manager.

@MCFMAIN This exec processes Message Manager commands issued to control messages.

@MCFMAIN is also responsible for: validating and processing command text, determining if the specified message is defined to a system, responding to operator inquiries, adding/deleting message traps and activating/inactivating message traps.

@MCFHELP This exec provides the Message Manager on-line help facility.

@MCFCALL This exec is an external REXX function used by other Automation Applications to internally request Message Manager services.

@M####F Message Checkpoint Flags

@M####S Message Status

Message Manager 153

Message Manager Message Definition


OverviewTo manage the messages under its control, the Message Manager uses information stored in tables created by the user. Each table is a member of the Automation Application table dataset. These tables are loaded into above-the-line storage at AF/OPERATOR and Automation Application initialization time. Anytime a Message Manager message is accessed, the appropriate information is retrieved from the tables and used to determine how to manage the message.

Adding or Updating MessagesTo add or update an object definition in the Message Manager, execute the KAUUISPF exec from the hilev.RKAUEXEC dataset to activate the IRM ISPF User Interface. Object definition information is entered on the appropriate panels from within the IRM ISPF User Interface. Under no circumstances attempt to edit the IRM tables outside of the ISPF User Interface as this will cause unpredictable results possibly causing the IRM environment to become unusable.

To implement the changes while AF/OPERATOR is running, use the Table Manager REFRESH command to refresh the in-storage copies of the Message Manager tables. This gives the Message Manager access to the new data. Then you can issue an MCF INIT command, specifying the message name, to initialize a new message trap or update an existing one.



The figure below indicates which tables will need to be refreshed to implement changes to the various Message Manager Definition sections.

ISPF Panel Section Name MCF Table Name

Control Data @MCFCNTL

@MCFSMFD

@MCFEXCP

Trap Data @MCFTRAP

@MCFCNTL

@MCFTOPT

Triggerring Conditions @MCFTRAP

Immediate Actions @MCFTACT

Extended Actions @MCFTACT

SLF Support @MCFTOPT

Message Manager - Add a Message

Message Data

Message Name

The name of the message to manage. This field is the table row name key and will be identified in the rest of the Message Manager tables as a reference key in order to tie all Message Manager information together. This is a 12character alphanumeric field assigned by the user. Any alphanumeric character may be used for the name with the exception of an asterisk (*) or double quotes (").

Description A one line description for the message. The Message Description field is used to provide a 'Plain English' description of the message for user reference. This field is displayed on the main Message Manager selection panel.

Up to 40 characters of free form text is allowed.

Message Manager 155


Message Manager Message Definition Panel

Control Data

Alias Specifies an alias for the Message Manager message name. This is a 12 character alphanumeric field, assigned by the user. The message alias can be used to group messages and/or identify a message by other than its defined MSG_NAME.



Keyword KEYWORD is the first mechanism which identifies whether a message is defined to a system. The KEYWORD field is used as a generalized grouping mechanism to identify those messages that are defined to all systems, no systems, or manipulated internally by other Automation Applications. Valid values are:� ALL Specifies that the message is defined to

all systems. The Message Manager will initialize this message trap on every system the Message Manager runs on.

� AUTO Specifies that the message is defined to all systems. Under most circumstances the AUTO keyword is identical to the ALL keyword, except in the case of bringing up a maintenance system running in manual application processing mode. When running in manual mode to bring up a maintenance system, only those message traps identified as AUTO will be added. When running in automated mode, the Message Manager will initialize the message trap on every system the Message Manager runs on.

� NONE Specifies that the message is not defined to any system. The Message Manager will not initialize this message trap on any system.

This keyword is used to identify those message traps that should not be added automatically, but rather, are added on-demand by manual intervention.

Note: The message trap can be initialized via manual intervention by specifying the Force option on an MCF INIT command.

Message Manager 157


� MANUAL Specifies that the message trap is not to be automatically added during Message Manager initialization. During initialization, or anytime an MCF INIT ALL or MCF ADD ALL command is processed, the Message Manager will bypass this message. A message with a KEYWORD of MANUAL will be managed only if an MCF INIT command for the message itself is manually entered at the operator console.

Keyword cont. � INTERNAL Specifies that the message trap will be initialized internally by another of the Automation Applications; the message trap will not be automatically added during Message Manager initialization. A message trap defined as INTERNAL can only be accessed by the controlling application.

Note: Messages defined with a KEYWORD of INTERNAL are hidden from normal Message Manager operations. INTERNAL message traps can not be accessed directly by Message Manager commands, unless the Force option of the MCF command is used. This includes all Message Manager displays for the message trap. Code an asterisk (*) if the message does not fall into any of these categories and the Message Manager will continue searching the remaining categories to determine if the message is defined to the system.

Number Specifies a unique number for the message starting from 1001. This is a four character numeric field used by the Message Manager in creating AF/OPERATOR variables and traps associated with the message. The message numbers need not be consecutive and are not used in any ordering scheme, but each message must have a unique number assigned to it.



XRF Workload XRF Workload is a grouping mechanism which identifies whether a message is defined to a system. If the system is defined as an IMS/XRF active system, any message identified as ACT by the XRF Workload field will be managed. Similarly, if the system is defined as an IMS/XRF alternate system, any message identified as ALT by the field will be managed. Valid values are:� ACT Specifies that the message is to be

managed on any IMS/XRF active system.

� ALT Specifies that the message is to be managed on any IMS/XRF alternate system. Leave blank if the message does not fall into any of these categories and the Message Manager will continue searching the remaining categories to determine if the message is defined to the system.

Note: This field is used to identify messages that are to be managed as a group for IMS/XRF activities, such as workload movement in the event of an IMS/XRF takeover.

Message Manager 159


JES Workload JES Workload is a grouping mechanism which identifies whether a message is defined to a system. If the system is defined as a JES3 Global system, any message identified as GLB by the JES Workload field will be managed. Similarly, if the system is defined as a JES3 Local system, any message identified as LCL by the field will be managed. Valid values are:� GLB Specifies that the message is to be

managed on any JES3 Global processor.

� LCL Specifies that the message is to be managed on any JES3 Local processor. Leave blank if the message does not fall into any of these categories and the Message Manager will continue searching the remaining categories to determine if the message is defined to the system.

Note: This field is used to identify messages that are to be managed as a group for JES3 activities, such as workload movement in the event of a Dynamic System Interchange (DSI).



MSn MSn is a grouping mechanism which identifies whether a message is defined to a system. MS1_WKLD through MS4_WKLD are four user assigned workload grouping fields. If the user assigned system variable and the MSn_WKLD fields match, the message will be managed.� MS1 Currently defined as IMS. Specifying

IMS in this field will cause the message to be managed on any system defined as MS1=IMS.

� MS2 Currently defined as ADF or PRD. Specifying ADF will cause the message to be managed on any system defined as MS2=ADF. Specifying PRD will cause the message to be managed on any system defined as MS2=PRD.

� MS3 Currently unassigned.� MS4 Currently unassigned. Leave blank if the message does not fall into any of these categories and the Message Manager will continue searching the remaining categories to determine if the message is defined to the system.

CPU ID The CPUID 1 through CPUID 12 fields allow the user to specifically define up to 12 unique CPU IDs where the message is to be managed. If the message does not fit into any message grouping as previously described, you can code the individual CPU IDs of the systems where the message is to be managed.

Leave blank any CPUID.n field that is not in use.

Note: A CPU ID can be coded as either the full six character CPU ID or just the right-most five characters for those message traps that are not LPAR dependent.

For five character CPU IDs, the first character of the CPU ID, the LPAR identifier, will be ignored.

Message Manager 161


Trap Data

SMF ID The SMFID 1 through SMFID 24 fields allow the user to specifically define up to 24 unique SMF IDs where the message is to be managed. If the message does not fit into any message grouping as previously described, code the individual SMF IDs of the systems where the message is to be managed. Leave blank any SMFID field that is not in use.

Note: If you have not specified the message in any of the previous workload groups, an SMF ID must be specified in order to manage the message. If an SMF ID is not coded, the message will not be managed anywhere.

Exceptions The Exception 1 through Exception 24 fields allow the user to exclude up to 24 unique SMF IDs where the message is not meant to be managed. If the message fits into a message grouping except for a couple of systems, include the message in the group and code the individual SMF IDs of the systems that are exceptions in the EXCPT.n fields. Leave blank any EXCPT.n field that is not in use.

WTO Pattern The WTO Pattern field specifies the text of the message to trap. The message text can be specified in the following ways:� Some or all of the actual text of the message; a message ID

with or without some or all of the message text.� A message pattern. Patterns may contain the

AF/OPERATOR wild card characters: – ? One alphanumeric character– # One numeric character– * Any number of alphanumeric characters– b A single blank space in the pattern will act as a wild

card for one or more blanks in the WTO text.

Note: A single asterisk (*) is not allowed as a valid message pattern. A message pattern may begin with an asterisk (*), but must include additional text. The use of an asterisk as the first character may have an adverse effect on system



Enable This is a binary field (0,1). Specify 1 to enable the trap during Message Manager initialization. Specify 0 to manually manage the activation of the trap by means of a MCF ENABLE command from the operator console. The default is 1.

AOTRAP This is a binary field (0,1). Specify 1 if you want the trap to be triggered by messages generated by AF/OPERATOR. Specify 0 if you want the trap to ignore messages issued by AF/OPERATOR. The default is 0.

Initialization This is a binary field (0,1). This field is used with messages that are managed by the Started Task Manager; messages defined with a keyword of INTERNAL and tied to the management of a Started Task Manager resource.

Specify 1 if this is a message that is issued only during the initialization phase of a started task. Specify 0 if this message is issued at other times in the life of the task. Initialization message traps will be deleted, by the Started Task Manager, when the resource has completed initialization. Deleting initialization message traps eliminates the overhead of checking traps that are not needed after a task has started.

Test This is a binary field (0,1). Specify 1 if you want to disable immediate and extended actions for this trap; the only commands that will execute are the ones that would normally execute in AF/OPERATOR warn mode. The default is 0.

If TEST is enabled when the trap is triggered, a record of the action that would have been taken is logged in the message log. Specify 0 if you want all immediate and extended actions to execute for this trap.

Log This is a binary field (0,1). Specify 1 if you want a message written to the AF/OPERATOR message log every time the trap is triggered. Specify 0 if you want no record of the trap being triggered nor of the trap action taken. The default is 0.

Retain This is a binary field (0,1). Specify 1 if you want information about each match recorded for display by the AF/OPERATOR RETAIN*VIEW facility. Specify 0 if you don't want match information recorded. The default is 0.

Message Manager 163


WAIT This is a binary field (0,1). Specify 1 if you want the address space from which the message was issued to be suspended while the Automation Facility is executing the trap action. Specify 0 if you do not wish to suspend the issuing address space. The trap action occurs while the address space continues normal execution. The default is 0.

Note: IMPORTANT - Never specify WAIT=1 in traps for messages from the CONSOLE address space or multi-user address spaces such as CICS, IMS, JES or VTAM. This would suspend ALL activities of the address space.

Hard Copy This is a binary field (0,1). Specify 1 if you want the message written to the system log, SYSLOG. Specify 0 if you want the message suppressed from the system's hard copy log.

Note: Specify an asterisk(*) in this field if you wish no action taken for this message with regard to the system log.

Wait This is a binary field (0,1). Specify 1 if you want the address space from which the message was issued to be suspended while the Automation Facility is executing the trap action. Specify 0 if you do not wish to suspend the issuing address space. The trap action occurs while the address space continues normal execution.

Note: IMPORTANT - Never specify WAIT=1 in traps for messages from the CONSOLE address space or multi-user address spaces such as CICS, IMS, JES or VTAM. This would suspend ALL activities of the address space.

Dom Log This is a binary field (0,1). Specify 1 if you want a message written to the AF/OPERATOR log every time the DOM trap is triggered. Specify 0 if you want no record of the trap being triggered nor of the trap action taken.

Journal This is a binary field (0,1). Specify 1 if you want to record match information for display in the Subsystem Logging Facility (SLF). Specify 0 if you do not want match information recorded for display in the Subsystem Logging Facility.



Triggering Conditions

Job Name A job name pattern, system task name pattern, or TSO user ID pattern that you want to trigger this trap. The AF/OPERATOR wild cards ?, #, and * are all allowed. Messages with job names, task names, or user IDs that do not match this pattern are ignored. Leave this field blank to allow any job name to trigger the trap.

System ID A system ID that will trigger this trap. The AF/OPERATOR wild cards ?, #, and * are all allowed. Messages with system IDs that do not match this pattern are ignored. Leave this field blank to allow messages from any system to trigger the trap. Code two double quotes (") in this field to set the system ID to the default specified in the AF/OPERATOR start parameters(LSYSNAME).

ASID The address space ID (nnnn) of the issuer of the message that you want to be trapped. Messages from other address spaces will be ignored. Leave this field blank to allow a message from any address space to trigger the trap.

User ID The User ID field is used to limit the trap to triggering only if the message comes from a job with the specified user ID. This parameter works only on systems with the IBM RACF security product installed. An asterisk (*) is allowed as a wild card character in the user ID to form a user ID pattern: USERID(TSO*). Messages with user IDs that do not match this pattern are ignored. Leave this field blank to allow messages from jobs with any user ID to trigger the trap.

Link ID The Link ID field is used to limit the trap to triggering only if the message comes from an AF/OPERATOR address space with the specified ID. An asterisk (*) is allowed as a wild card character to form a link ID pattern: LINKID(SYSA*). Messages with link IDs that do not match the specified link ID or link ID pattern are ignored. Leave this field blank to allow messages from any OG/MVS link ID to trigger the trap. Leave this field blank to use the default link ID specified in the AF/OPERATOR startup options.

Message Manager 165


User Type The User Type field is used to limit the trap to triggering only if the message comes from AOSIM with the AOUSER field set to the specified four characters. An asterisk is allowed as a wild card character to form a user type pattern: USER(XYZ*). Messages with the user type field set to any other value will be ignored.Leave this field blank to allow messages with any user type field setting to trigger the trap.

Job Type The job types that you want to trigger the trap. Messages that are not issued from one of these job types are ignored. Valid values are:� IMS For IMS messages issued to the MTO� JOB For batch jobs� STC For system started tasks� TSU For TSO usersIf specifying multiple job types, use commas or blanks to separate each job type and enclose the entire field in double quotes ("). Leave this field blank to allow any job type to trigger this trap.

Job Class The job classes that you want to trigger this trap. Messages that do not have at least one of these job classes will be ignored. Do not use commas or blanks to separate job classes. For example, 'ABCDE' specifies 5 job classes. Specify a job class by a text character as follows:� alphanumeric (A to Z, 0 to 9)� @ for TSO users� $ for started tasksLeave this field blank to allow any job class to trigger the trap.

Descriptor Code

The descriptor codes that you want to trigger this trap. Messages that do not have at least one of these descriptor codes will be ignored. If specifying multiple descriptor codes, use commas or blanks to separate each code and enclose the entire field in double quotes ("). Leave this field blank to allow any descriptor code to trigger the trap.



Immediate Actions

Route Code The route codes that you want to trigger this trap. Messages that do not have at least one of these route codes will be ignored. If specifying multiple route codes, use commas or blanks to separate each code and enclose the entire field in double quotes ("). Leave this field blank to allow any route code to trigger this trap.

Console The console IDs that you want to trigger this trap. Messages destined for other consoles will be ignored. If specifying multiple console IDs, use commas or blanks to separate each ID and enclose the entire field in double quotes ("). Leave this field blank to allow messages destined for any console to trigger the trap

Days The days on which you want the trap to be triggered. The trap will be triggered only on days explicitly listed here. This is a binary field (0,1), starting with Sunday. For instance, 0111110 will result in the trap being triggered Monday through Friday. Leave this field blank to allow the trap to be triggered on all days.

Bus This is a binary field (0,1). Specify 1 if you want the message to be managed only on business days. Specify 0 if you want the message to be managed every day.

Suppress This is a binary field (0,1). Specify 1 to suppress the message or group of messages. Specify 0 if you want the message or group of messages to be displayed. The default is 1.

New System The JES3 Main ID of the remote system that you want to receive the triggering message. This message is sent via the Peer-to-Peer facility. If the target message is suppressed, the message is not a candidate for Peer-to-Peer and will not be sent to the remote system; it will only be suppressed on the local system. Leave blank if you do not want the message sent to a remote system.

Message Manager 167


New Console The New Console field is used to specify the ID/name of the console that is to receive the trapped message. The message will be sent directly to the specified console; overriding route code(s) or console destinations in the original message. The console may be specified by its numeric ID or by name for MVS/ESA 4.1 and above. Leave this field blank if there is no new console destination for the message.

Color The Color field is used to modify the color attribute of an existing WTO. Specify the desired color of the message with this field. Leave this field blank if the color of the message is not to be altered. Valid values for Color are: BLUE, RED, GREEN, PINK, YELLOW, TURQ and WHITE.

Highlight The Highlight field is used to modify the highlighting attribute of an existing WTO. Specify the desired highlighting for the message with this field. Leave this field blank if the highlighting for the message is not to be altered. Valid values for Highlight are: NONE, BLINK, UNDERLINE, and RVIDEO.

Intensity The Intensity field is used to modify the intensity of an existing WTO. Specify the desired intensity for the message with this field. Leave this field blank if the intensity for the message is not to be altered. Valid values for Intensity are: NORMAL and HIGH.

Add Descriptor Specify a valid descriptor code or set of codes you want to append to the message's existing descriptor codes. If specifying more than one descriptor code, use commas or blanks to separate each code and enclose the entire field in double quotes ("). For instance, "3,7" will add descriptor codes 3 & 7 to the existing descriptor codes for the message.

Add Route Specify a valid route code or set of codes you want to append to the message's existing route codes. If specifying more than one route code, use commas or blanks to separate each code and enclose the entire field in double quotes ("). For instance, "3,8", will add route codes 3 & 8 to the existing route codes for the message.



Del Descriptor Specify a valid descriptor code, or set of codes, that you want deleted from the message's existing descriptor codes. If specifying more than one descriptor code, use commas to separate each code. To specify a range of codes use a colon, ex: 7:11. Leave this field blank if no descriptor codes are to be deleted from the message.

Del Route Specify a valid route code, or set of codes, that you want deleted from the message's existing route codes. If specifying more than one route code, use commas to separate each code. To specify a range of codes use a colon, ex: 1:128. Leave this field blank if no route codes are to be deleted from the message.

New Descriptor Specify a valid descriptor code or set of codes that will be used to replace the message's existing descriptor code. This field affects only WTOs, not WTORs. If specifying more than one descriptor code, use commas or blanks to separate each code and enclose the entire field in double quotes ("). For instance, "3,7", will replace the existing descriptor codes with descriptor codes 3 & 7.

New Route Specify a valid route code or set of codes that will be used to replace the message's existing route codes. If specifying more than one route code, use commas or blanks to separate each code and enclose the entire field in double quotes ("). For instance, "3,8", will replace the existing route codes with route codes 3 & 8.

Message Manager 169


Extended Actions

Action An MVS operator command or an AF/OPERATOR command you want to execute if the trap is triggered. It may be an EXEC command that executes a command file or a REXX exec. It must be a single command no more than 128 characters in length. Code an asterisk (*) if no MVS command, AF/OPERATOR command, or AF/OPERATOR command file is to be executed.

If the command is an MVS operator command, the OPER keyword must prefix the quoted command string. Enclose the entire field in double quotes ("). If a command is passing a quote parameter, enclose the parameter in 4 single quotes:

"OPER ''S SETPARM,PARM=''''SETP=01''''''"

If a command is passing variables, use a single ampersand (&) for immediate substitution or a double ampersand (&&) for substitution at execution time.

Limit The Limit field is used in conjunction with the Alternate Action field. Specify a number, n, where every nth time the trap is triggered, AF/OPERATOR issues the command specified in the Alternate Action field instead of the command specified in the Action field. Leave this field blank to execute the command in the Action field every time the trap is triggered.

Alternate This field is used in conjunction with the Match limit field, see "@MCFTOPT -Message Trap Options Table" on page page 176. Specify an MVS command or AF/OPERATOR command that you want to execute every nth time the trap is triggered, where n is the number specified in the Match limit field. The action may be an EXEC command that executes an AF/OPERATOR command file or a REXX exec. This entry must be a single command no more than 128 characters in length. If the command is an MVS operator command, the OPER keyword must prefix the quoted command string. Enclose the entire field in double quotes ("). Leave blank if no MVS operator command, AF/OPERATOR command, or AF/OPERATOR command file is to be executed.



SLF Support

Dom Action The DOM Action field is used to specify an MVS command or AF/OPERATOR command that you want to execute when the DOM trap is triggered. The command may be an AF/OPERATOR EXEC command, which executes a REXX command file or exec. Leave this field blank if there is no need to trigger a DOM trap.

If the command is an MVS operator command, the OPER keyword must prefix the quoted command string. If a command is passing a quoted parameter, enclose the parameter in 4 single quotes:

OPER ''S SETPARM,PARM=''''SETP=01''''''

If a command is passing variables, use a single ampersand for immediate substitution or two ampersands for substitution at execution time.

Color The Color field is used to modify the color attribute of the SLF data. Specify the desired color of the data with this field. Leave this field blank if the color of the data is not to be altered. Valid values for Color are: BLUE, RED, GREEN, PINK, YELLOW, TURQ and WHITE.

Highlight The Highlight field is used to modify the highlighting attribute of the SLF data. Specify the desired highlighting for the data with this field. Leave this field blank if the highlighting for the data is not to be altered. Valid values for Highlight are: NONE, BLINK, UNDERLINE, and RVIDEO.

Intensity The Intensity field is used to modify the intensity of the SLF data. Specify the desired intensity for the data with this field. Leave this field blank if the intensity of the data is not to be altered. Valid values for Intensity are: NORMAL and HIGH.

Help Panel The Journal Help Panel field is used to specify the name of an optional help panel to be displayed when viewing the SLF data.

Message Manager 171



OverviewOnce the automation table component of the Message Manager has been defined, the information needed to manage messages for an environment is available to the Message Manager service subroutines. To initiate the actual management of messages, the Message Manager service subroutines must be activated.

Starting the Service SubroutinesThe Message Manager is automatically started at AF/OPERATOR initialization time by the Application Manager which executes the @MCFINIT exec. This command file initializes the Message Manager environment and executes @MCFMAIN to initialize and set all message traps that should be enabled at the current time and date for that system; therefore, all message traps defined to a system and scheduled to be enabled, but are not currently, will be enabled. In addition, @MCFINIT will set up a command trap for the MCF operator command.

If AF/OPERATOR is already running, you can activate the Message Manager before the next AF/OPERATOR recycle by issuing the following Application Manager command from the MVS console:

APL INIT MCF

Note: This assumes that the Message Manager tables have been pre-loaded into storage by the Table Manager. If the Message Manager tables have not been automatically loaded, issue the appropriate Table Manager commands, from the MVS console, to load the tables before you initialize the Message Manager.

Controlling Message Manager Resources



The MCF command provides an operator interface to give you additional control over the messages defined to the Message Manager. It is used to communicate with AF/OPERATOR and the Message Manager service subroutines to control Message Manager message traps and display Message Manager information about the message traps from the MVS console.


MCF ENABLE CA7END1

at any time, to enable the message trap associated with the message definition you named CA7END1. The message name specified in the command is the same as the MSG_NAME field you coded in the Message Control table.

An asterisk (*) is treated as a wild card character, allowing you to specify groups of like-named messages.

For example, the command:

MCF ENABLE CA7*

will enable all messages defined with a MSG_NAME that begins with the letters CA7.

Message Manager 173


MCF Command SyntaxThe following table shows the available MCF commands. To protect against unintentional command errors, certain function/message name/option combinations are prohibited. This includes:

� Functions INIT, ADD, and DELETE with message name ALL or * with the FORCE option.

FIGURE 5. MCF Command Syntax

Parameters

Function - Required

Message Name- Required

Option - Optional

MCF function message name optionADD ALL FORCEDELETE * MAINTINIT MSG_NAME CHKP

MSG_ALIASENABLE PATTERN CONSOLE=console_idDISABLE

ALLOW KEY=keywordSUPPRESS GROUP XRF=xrf_wkld

JES=jes_wkldRESET MSn=ms_wkldEXCEPT

HELPSHOWSTATUS

DISPLAY



Functions

The function parameter is used to tell the Message Manager which action to take against a message. Many, but not all, functions have abbreviations. Acceptable abbreviations are noted with the function's description.

ADD Adds and activates a pre-defined message trap immediately. No abbreviations of the ADD keyword are acceptable.

DELETE Deactivates a pre-defined message trap immediately and deletes the definition from storage. Valid abbreviations are: DEL.

INIT Initializes a message trap defined to the Message Manager so that changes to the message's definition will take effect immediately without affecting the status of other messages. The message trap will be added and activated, if so defined, otherwise the message trap will be added in a disabled state. No abbreviations of the INIT keyword are acceptable.

ENABLE Activates a message trap that was previously added or initialized in a disabled state to the Message Manager. Valid abbreviations are: ENA.

DISABLE Deactivates a message trap previously added and enabled. No abbreviations of the DISABLE keyword are acceptable.

ALLOW Deactivates message suppression for a message trap. Valid abbreviations are: AL and A.

SUPPRESS Activates message suppression for a message trap. Valid abbreviations are: SUP.

RESET Resets business day/non-business day Message Manager traps. Valid abbreviations are: RES and R.

EXCEPT EXCEPT is used to temporarily except a message trap from being enabled on a system. This function will alter the in-storage copy of the Message Manager Message Control table to define the message with a KEYWORD of NONE. An excepted message will no longer be managed by the Message Manager. To re-enable Message Manager control of an excepted message, an 'MCF INIT message FORCE' command must be issued. Valid abbreviations are: EX and E.

Message Manager 175


HELP Displays the Message Manager on-line help file on the operator console. No abbreviations of the HELP keyword are acceptable.

SHOW Shows an AF/OPERATOR, Message Manager created, trap associated with the message. Valid abbreviations are: SH.

STATUS A message can be in any one of the following states:� DEFINED The Message Manager knows about

the message, but does not know whether the message trap is enabled or disabled.

� ENABLED The message trap is enabled (activated) on the system.

� DISABLED The message trap is disabled (deactivated) on the system.

� UNKNOWN The message's status is unknown. This is usually the case if the Message Manager has not fully initialized.

� BYPASSED There are two options for this status:– MANUAL MODE The message trap was not

enabled at Message Manager initialization since the system was IPL'ed in a manual mode.

– NON-BUSINESS DAY The message trap is not enabled since the current processing day is defined as a non-business day.

� NOT DEFINED TO THIS SYSTEM The message is not defined to this system.

DISPLAY Issues a WTO to the MVS console that indicates the Message Manager status for the specified message trap. The default display is the same as the STATUS display as described above. Valid abbreviations are: DIS and D.



Message Name

The message name parameter is used to tell the Message Manager which messages to manage. The aforementioned function will be performed for the messages specified with this parameter.

ALL The ALL keyword is used to specify all messages defined to the system. All messages known to the Message Manager will be interrogated, those that have been defined to this system via the Message Control table will be chosen. A '*' is a synonym for the ALL keyword.

MSG_NAME A message name precisely as coded in the Message Control table.

MSG_ALIAS A message alias precisely as coded in the Message Control table.

PATTERN A message name pattern, using a '*' as a wild card character. Any message with a name or alias, MSG_NAME or MSG_ALIAS, that begins with the letters preceding the asterisk (*) and is defined to the system will be managed.

GROUP A keyword, which specifies that a group definition option is to follow. The messages included in a group are defined via the Message Control table. There are no abbreviations for the GROUP keyword. Valid group options are:� KEY=keyword

KEYWORD group as defined in the Message Control Table. Valid values for keyword are: ALL, AUTO, NONE, MANUAL and INTERNAL.

� XRF=xrf_wkld XRF workload group as defined in the Message Control Table. Valid values for xrf_wkld are: ACT and ALT.

� JES=jes_wkld JES workload group as defined in the Message Control Table. Valid values for jes_wkld are: GLB and LCL.

� MSn=msn_wkld MS1 through MS4 workload groups as defined in the Message Control Table. Valid values for an MSn keyword are site specific.

Message Manager 177


Standard Options

The standard options are used to alter the normal Message Manager processing of a function for a message.

FORCE The FORCE option is used to force a message that is not defined to a system onto that system. Valid abbreviations are: F.

Note: If a message is forced onto a system via an MCF INIT or MCF ADD command, the Message Manager will update the in-storage copy of the Message Control table and define the message to the system. Anytime after this, you need not use the FORCE option on the MCF command to manage the message. This is a temporary change that will be in effect until the next time AF/OPERATOR is cycled. Once AF/OPERATOR is brought down, the definition of the message will revert to that specified in the Message Manager tables.

MAINT The MAINT option is used to manage only those messages that have been defined with a KEYWORD of AUTO. This is a special option used when IPL'ing a maintenance system. Valid abbreviations are: M.

CHKP The CHKP option is used to perform a checkpoint restart of the Message Manager. This is a special option used by the Application Manager when processing a checkpoint restart. There are no abbreviations for the CHKP option.

CONSOLE=console_id

The CONSOLE option is used to specify the console to receive Message Manager messages for a function. Specify either a valid console ID or the device address of the console for the console_id argument. There are no abbreviations for the CONSOLE option.



MCF Command On-line HelpOn-line help for the Message Manager MCF command is available anytime. To display on-line help for the MCF command, enter the following command at the MVS operator console:

MCF HELP

The Message Manager will then display the MCF command syntax followed by a brief explanation of each of the keywords associated with the command.

Command Manager 179

Command Manager

IntroductionThe Command Manager is a facility that allows you to manage MVS console commands. The Command Manager is used to create and manage instruction rules, called traps, that recognize console commands as they appear. The Command Manager and command traps allow you to:

� Consolidate commands into command groups.

� Suppress a command or a group of commands.

� Automatically react to console commands.

The Command Manager offers a wide variety of options which allow you to control what command traps are enabled on each system. The Command Manager can enable a command trap based on keyword groups, workload groups or on an individual system identified by SMF or CPU ID. Each command is treated as a unique object that can be grouped with other similar commands or managed by itself.

Commands that are to be managed by the Command Manager are identified by a command pattern. The command pattern describes the actual text of the command. The text of the command can be qualified to any extent appropriate to uniquely identify the command.

3


The Command Manager allows you to limit the scope of a command trap by defining triggering conditions. Triggering conditions can be used to limit command management activities to commands issued by specific jobs, job types, or job classes. The command trap can also be limited to only recognizing commands issued from specific consoles or commands received from specific systems. Finally, the triggering conditions can be used to limit command management to only certain days of the week.

The Command Manager can be used to automatically react to console commands by defining an action to take when a command is received. The Command Manager can be used to suppress a command or trigger the execution of an AF/OPERATOR command file or another MVS command.

Chapter ContentsCommand Manager Components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181Command Manager Command Definition . . . . . . . . . . . . . . . . . . . . . . . 183Using the Service Subroutines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195Controlling Command Manager Resources. . . . . . . . . . . . . . . . . . . . . . . 196

Command Manager 181

Command Manager Components


The Command Manager has three components. They are:

� Command definition



Command DefinitionThe Command Manager tables hold information used to create traps for the commands you want to manage with the Command Manager. All of the tables are members of the Automation Application table dataset, hilev.RKAUTBLR. The tables are created by the user via the IRM ISPF Interface. The interface enables the user to populate the table fields with the appropriate information for each message definition. The section, Command Manager Command Defintion section beginning on page 183, describes the Command Manager automation tables in detail.



Service SubroutinesThe Command Manager service subroutines are AF/OPERATOR command files used to perform a variety of functions for the commands controlled by the Command Manager:

� Add a command trap

� Delete a command trap

� Enable/Disable an existing command trap


AF/OPERATOR System VariablesThe Command Manager creates the following AF/OPERATOR system variables to track command status over time:

@CCFINIT This exec initializes the Command Manager environment: creating an MVS console command, called CCF, that allows you to perform various management functions on a single command or group of commands, performing clean-up activities, and invoking @CCFMAIN at AF/OPERATOR start-up to initialize and add all of the command traps controlled by the Command Manager.

@CCFMAIN This exec processes Command Manager commands issued to control command traps.

@CCFMAIN is also responsible for: validating and processing command text, determining if the specified command is defined to a system, responding to operator inquiries, adding/deleting command traps and activating/inactivating command traps.

@CCFHELP This exec provides the Command Manager on-line help facility.

@CCFCALL This exec is an external REXX function used by other Automation Applications to internally request Command Manager services.

@C####F Command Checkpoint Flags

@C####S Command Status

Command Manager 183

Command Manager Command Definition


OverviewTo manage the commands under its control, the Command Manager uses information stored in tables created by the user.The tables that contain the command management information are:

Each table is a member of the Automation Application table dataset. These tables are loaded into above-the-line storage at AF/OPERATOR and Automation Application initialization time. Anytime a Command Manager command is accessed, the appropriate information is retrieved from the tables and used to determine how to manage the command.

Adding or Updating CommandsTo add or update an object definition in the Command Manager, execute the KAUUISPF exec from the hilev.RKAUEXEC dataset to activate the IRM ISPF User Interface. Object definition information is entered on the appropriate panels from within the IRM ISPF User Interface. Under no circumstances attempt to edit the IRM tables outside of the ISPF User Interface as this will cause unpredictable results possibly causing the IRM environment to become unusable.

To implement the changes while AF/OPERATOR is running, use the Table Manager REFRESH command to refresh the in-storage copies of the Command Manager tables. This gives the Command Manager access to the new data. Then you can issue a CCF INIT command, specifying the command name, to initialize a new command or update an existing one.

@CCFCNTL The Command Manager Control Table.

@CCFSMFD The Command Manager SMF ID Control Table.

@CCFEXCP The Command Manager Exception Control Table.

@CCFTRAP The Command Manager Trap Table.

@CCFTACT The Command Manager Trap Action Table.



The figure below indicates which tables will need to be refreshed to implement changes to the various Command Manager Definition sections.

ISPF Panel Section Name: CCF Table Name

Control Data @CCFCNTL

@CCFSMFD

@CCFEXCP

Trap Data @CCFTRAP

@CCFCNTL

@CCFTOPT

Triggerring Conditions @CCFTRAP

Actions @CCFTACT

SLF Support @CCFTOPT

Command Manager - Add a Command

Command Data

Command Name

The name of the command to manage. This field is the table row name key and will be identified in the rest of the Command Manager tables as a reference key in order to tie all Command Manager information together. This is a 12 character alphanumeric field assigned by the user. Any alphanumeric character may be used for the name with the exception of an asterisk (*) or double quotes (").

Description A one line description for the command. The Command Description field is used to provide a 'Plain English' description of the command for user reference. This field is displayed on the main Command Manager selection panel.


Command Manager 185


Command Manager Command Definition Panel

Control Data

Alias Specifies an alias for the Command Manager command name. This is a 12 character alphanumeric field, assigned by the user. The command alias can be used to group commands and/or identify a command by other than its defined CMD_NAME.

Keyword KEYWORD is the first mechanism which identifies whether a command is defined to a system. The KEYWORD field is used as a generalized grouping mechanism to identify those commands that are defined to all systems, no systems, or manipulated internally by other Automation Applications. Valid values are:� ALL Specifies that the command is defined to all

systems. The Command Manager will initialize this command trap on every system the Command Manager runs on.

� AUTO Specifies that the command is defined to all systems. Under most circumstances the AUTO keyword is identical to the ALL keyword, except in the case of bringing up a maintenance system running in manual application processing mode. When running in manual mode to bring up a maintenance system, only those command traps identified as AUTO will be added. When running in automated mode, the Command Manager will initialize the command trap on every system the Command Manager runs on.

� NONE Specifies that the command is not defined to any system. The Command Manager will not initialize this command trap on any system.

This keyword is used to identify those command traps that should not be added automatically, but rather, are added on-demand by manual intervention.



Keywordcont.

� MANUAL Specifies that the command trap is not to be automatically added during Command Manager initialization. During initialization, or anytime a CCF INIT ALL or CCF ADD ALL command is processed, the Command Manager will bypass this command. A command with a KEYWORD of MANUAL will be managed only if an CCF INIT command for the command itself is manually entered at the operator console.

� INTERNALSpecifies that the command trap will be initialized internally by another of the Automation Applications; the command trap will not be automatically added during Command Manager initialization.A command trap defined as INTERNAL can only be accessed by the controlling application.

Leave blank if the command does not fall into any of these categories and the Command Manager will continue searching the remaining categories to determine if the command is defined to the system.

Note: Commands defined with a KEYWORD of INTERNAL are hidden from normal Command Manager operations. INTERNAL command traps can not be accessed directly by Command Manager commands, unless the Force option of the CCF command is used. This includes all Command Manager displays for the command trap.

Note: The command trap can be initialized via manual intervention by specifying the Force option on a CCF INIT command.

Number Specifies a unique number for the command starting from 1001. This is a four character numeric field used by the Command Manager in creating AF/OPERATOR variables and traps associated with the command.

The command numbers need not be consecutive and are not used in any ordering scheme, but each command must have a unique number assigned to it.

Command Manager 187


XRF Workload XRF Workload is a grouping mechanism which identifies whether a command is defined to a system. If the system is defined as an IMS/XRF active system, any command identified as ACT by the XRF Workload field will be managed. Similarly, if the system is defined as an IMS/XRF alternate system, any command identified as ALT by the field will be managed. Valid values are:� ACT Specifies that the command is to be initialized

on any IMS/XRF active system.� ALT Specifies that the command is to be initialized

on any IMS/XRF alternate system.Leave blank if the command does not fall into any of these categories and the Command Manager will continue searching the remaining categories to determine if the command is defined to the system.

Note: This field is used to identify commands that are to be managed as a group for IMS/XRF activities, such as workload movement in the event of an IMS/XRF takeover.

JES Workload JES Workload is a grouping mechanism which identifies whether a command is defined to a system. If the system is defined as a JES3 Global system, any command identified as GLB by the JES Workload field will be managed. Similarly, if the system is defined as a JES3 Local system, any command identified as LCL by the field will be managed. Valid values are:� GLB Specifie that the command is to be initialized

on any JES3 Global processor.� LCL Specifies that the command is to be initialized

on any JES3 Local processor.Leave blank if the command does not fall into any of these categories and the Command Manager will continue searching the remaining categories to determine if the command is defined to the system.

Note: This field is used to identify commands that are to be managed as a group for JES3 activities, such as workload movement in the event of a Dynamic System Interchange (DSI).



MSn MSn is a grouping mechanism identifying if a command is defined to a system. If the user-assigned system variable and the MSn fields match, the command is managed. MS1 through MS4 are four user-assigned grouping fields (MS1 - MS4).

Leave blank if the command does not fall into any of these categories and the Command Manager will continue searching the remaining categories todetermine if the command is defined to the system.

CPU ID The CPUID 1 through CPUID 12 fields allow the user to specifically define up to 12 unique CPU IDs where the command is to be managed. If the command does not fit into any command grouping as previously described, you can code the individual CPU IDs of the systems where the command is to be managed.

Leave any CPUID.n field that is not in use blank.

Note: A CPU ID can be coded as either the full six character CPU ID or just the right-most five characters for those command traps that are not LPAR dependent. For five character CPU IDs, the first character of the CPU ID, the LPAR identifier, will be ignored.

SMF ID The SMFID 1 through SMFID 24 fields allow the user to specifically define up to 24 unique SMF IDs where the command is to be managed. If the command does not fit into any command grouping as previously described, code the individual SMF IDs of the systems where the command is to be managed.

Leave any SMFID.n field that is not in use blank.

Note: If you have not specified the command in any of the previous workload groups, an SMF ID must be specified in order to manage the command. If an SMF ID is not coded, the command will not be managed anywhere.

Exceptions The Exception 1 through Exception 24 fields allow the user to exclude up to 24 unique SMF IDs where the command is not meant to be managed. If the command fits into a command grouping except for a couple of systems, include the command in the group and code the individual SMF IDs of the systems that are exceptions in the Exception fields.

Command Manager 189


Trap Data

Cmd Pattern The Cmd Pattern field specifies the text of the command to trap. The command text can be specified in the following ways:� Some or all of the actual text of the command.� A command pattern. Patterns may contain the

AF/OPERATOR wild card characters:– ? - One alphanumeric character– # - One numeric character– * - Any number of alphanumeric characters– b - A single blank space in the pattern will act as a wild

card for one or more blanks in the command text.

Note: A single asterisk (*) is not allowed as a valid message pattern. A message pattern may begin with an asterisk (*), but must include additional text. The use of an asterisk as the first character may have adverse effects on system performance.

Enable This is a binary field (0,1). Specify 1 to enable the trap during Command Manager initialization. Specify 0 to manually manage the activation of the trap by means of a CCF ENABLE command from the operator console.

AOTRAP This is a binary field (0,1). Specify 1 if you want the trap to be triggered by commands generated by AF/OPERATOR. Specify 0 if you want the trap to ignore commands issued by AF/OPERATOR. The default is 0.

Test This is a binary field (0,1). Specify 1 if you want to disable immediate and extended actions for this trap; the only commands that will execute are the ones that would normally execute in AF/OPERATOR warn mode.

If TEST is enabled when the trap is triggered, a record of the action that would have been taken is logged in the message log. Specify 0 if you want all immediate and extended actions to execute for this trap.

Log This is a binary field (0,1). Specify 1 if you want a message written to the AF/OPERATOR message log every time the trap is triggered. Specify 0 if you want no record of the trap being triggered nor of the trap action taken. The default is 0.




Retain This is a binary field (0,1). Specify 1 if you want information about each match recorded for display by the AF/OPERATOR RETAIN*VIEW facility. Specify 0 if you don't want match information recorded. The default is 0..

Wait This is a binary field (0,1). Specify 1 if you want the address space from which the command was issued to be suspended while the Automation Facility is executing the trap action. Specify 0 if you do not wish to suspend the issuing address space. The trap action occurs while the address space continues normal execution. The default is 0.

Note: IMPORTANT - Never specify WAIT=1 in traps for commands from the CONSOLE address space or multi-user address spaces such as CICS, IMS, JES or VTAM. This would suspend ALL activities of the address space.

Journal This is a binary field (0,1). Specify 1 if you want to record match information for display in the Subsystem Logging Facility (SLF). Specify 0 if you do not want match information recorded for display in the Subsystem Logging Facility.

Job Name A job name pattern, system task name pattern, or TSO user ID pattern that you want to trigger this trap. The AF/OPERATOR wild cards ?, #, and * are all allowed. Commands from job names, task names, or user IDs that do not match this pattern are ignored. Leave this field blank to allow any job name to trigger the trap.

System ID A system ID that will trigger this trap. The AF/OPERATOR wild cards ?, #, and * are all allowed. Commands with system IDs that do not match this pattern are ignored. Leave this field lank to allow commands from any system ID to trigger this trap. Code two double quotes (") in this field to set the system ID to the default specified in the AF/OPERATOR start parameters (LSYSNAME).

Command Manager 191


ASID The address space ID (nnnn) of the issuer of the command that you want to be trapped. Commands from other address spaces will be ignored. Leave this field blank to allow commands from any address space to trigger the trap.

User ID The User ID field is used to limit the trap to triggering only if the command comes from a job with the specified user ID. This parameter works only on systems with the IBM RACF security product installed. An asterisk (*) is allowed as a wild card character in the user ID to form a user ID pattern: USERID(TSO*). Commands with user IDs that do not match this pattern are ignored. Leave this field blank to allow commands from jobs with any user ID to trigger the trap.

Link ID The Link ID field is used to limit the trap to triggering only if the command comes from an AF/OPERATOR address space with the specified ID. An asterisk (*) is allowed as a wild card character to form a link ID pattern: LINKID(SYSA*). Commands with link IDs that do not match the specified link ID or link ID pattern are ignored. Leave this field blank to allow commands from any OG/MVS link ID to trigger the trap. Leave this field blank to use the default link ID specified in the AF/OPERATOR startup options.

Job Type The job types that you want to trigger the trap. Commands that are not issued from one of these job types are ignored. Valid values are:� IMS For IMS messages issued to the MTO� JOB For batch jobs� STC For system started tasks� TSO For TSO users

If specifying multiple job types, use commas or blanks to separate each job type and enclose the entire field in double quotes ("). Leave this field blank to allow any job type to trigger this trap.



Actionss

Job Class The job classes that you want to trigger this trap. Commands that do not originate from a job with at least one of these job classes will be ignored. Do not use commas or blanks to separate job classes. For example, 'ABCDE' specifies 5 job classes. Specify a job class by a text character as follows:� alphanumeric (A to Z, 0 to 9)� @ for TSO users� $ for started tasksLeave this field blank to allow any job class to trigger the trap.

Console The console IDs that you want to trigger this trap. Commands from other console IDs will be ignored. If specifying multiple console IDs, use commas or blanks to separate each ID and enclose the entire field in double quotes ("). Leave this field blank to allow commands from any console to trigger the trap.

Days The days on which you want the trap to be triggered. The trap will be triggered only on days explicitly listed here. This is a binary field (0,1), starting with Sunday. For instance, 0111110 will result in the trap being triggered Monday through Friday. Leave this field blank to allow the trap to be triggered on all days.

Bus This is a binary field (0,1). Specify 1 if you want the command to be managed only on business days. Specify 0 if you want the command to be managed every day.

Suppress This is a binary field (0,1). Specify 1 to suppress a command or group of commands. Specify 0 if you want the command or group of commands to be processed. The default is 1.

Command Manager 193


Action An MVS operator command or an AF/OPERATOR command you want to execute if the trap is triggered. It may be an EXEC command that executes a command file or a REXX exec. It must be a single command no more than 128 characters in length.

Leave blank if no MVS command, AF/OPERATOR command, or AF/OPERATOR command file is to be executed.

If the command is an MVS operator command, the OPER keyword must prefix the quoted command string. Enclose the entire field in double quotes ("). If a command is passing a quoted parameter, enclose the parameter in 4 single quotes:



Limit This field is used in conjunction with the Alernate field. Specify a number, n, where every nth time the trap is triggered, the Automation Facility issues the command specified in the Alternate field instead of the command specified in the Action field. Leave this field blank to execute the command in the Action field every time the trap is triggered.

Alternate This field is used in conjunction with the Match limit field, see @CCFTOPT -Command Trap Options Table. Specify an MVS command or AF/OPERATOR command that you want to execute every nth time the trap is triggered, where n is the number specified in the Match limit field.

The action may be an EXEC command that executes an AF/OPERATOR command file or a REXX exec. This entry must be a single command no more than 128 characters in length. If the command is an MVS operator command, the OPER keyword must prefix the quoted command string. Enclose the entire field in double quotes (").

Leave blank if no MVS operator command, AF/OPERATOR command, or AF/OPERATOR command file is to be executed.



SLF Support

Color The Color field is used to modify the color attribute of the SLF data. Specify the desired color of the data with this field. Leave this field blank if the color of the data is not to be altered. Valid values for Color are: BLUE, RED, GREEN, PINK, YELLOW, TURQ and WHITE.

Highlight The Highlight field is used to modify the highlighting attribute of the SLF data. Specify the desired highlighting for the data with this field. Leave this field blank if the highlighting for the data is not to be altered. Valid values for Highlight are: NONE, BLINK, UNDERLINE, and RVIDEO.

Intensity The Intensity field is used to modify the intensity of the SLF data. Specify the desired intensity for the data with this field. Leave this field blank if the intensity of the data is not to be altered. Valid values for Intensity are: NORMAL and HIGH.

Help Panel The Journal Help Panel field is used to specify the name of an optional help panel to be displayed when viewing the SLF data.

Command Manager 195



OverviewOnce the automation table component of the Command Manager has been defined, the information needed to manage commands for an environment is available to the Command Manager service subroutines.

To initiate the actual management of commands, the Command Manager service subroutines must be activated.

Starting the Service SubroutinesThe Command Manager is automatically started at AF/OPERATOR initialization time by the Application Manager which executes the @CCFINIT exec. This command file initializes the Command Manager environment and executes @CCFMAIN to initialize and set all command traps that should be running at the current time and date for that system; therefore, all command traps defined to a system and scheduled to be enabled, but are not currently, will be enabled. In addition, @CCFINIT will set up a command trap for the CCF operator command.

If AF/OPERATOR is already running, you can activate the Command Manager before the next AF/OPERATOR recycle by issuing the following Application Manager command from the MVS console:

APL INIT CCF

Note: This assumes that the Command Manager tables have been pre-loaded into storage by the Table Manager. If the Command Manager tables have not been automatically loaded, issue the appropriate Table Manager commands, from the MVS console, to load the tables before you initialize the Command Manager.

Controlling Command Manager Resources



The CCF command provides an operator interface to give you additional control over the commands defined to the Command Manager. It is used to communicate with AF/OPERATOR and the Command Manager service subroutines to control Command Manager command traps and display Command Manager information about the command traps from the MVS console.


CCF ENABLE MVSREPLY

at any time, to enable the command trap associated with the command definition you named MVSREPLY. The command name specified in the command is the same as the CMD_NAME field you coded in the Command Control table.

An asterisk (*) is treated as a wild card character, which allows you to specify groups of like-named commands. For example, the command:

CCF ENABLE MVS*

will enable all commands defined with a CMD_NAME that begins with the letters MVS.

Command Manager 197


CCF Command SyntaxThe following table shows the available CCF commands. To protect against unintentional command errors, certain Function/Com- mand/Option combinations are prohibited. This includes:

� Functions INIT, ADD, and DELETE with command name ALL or * with the FORCE option.

FIGURE 6. CCF Command Syntax

Parameters

Function - Required

Command Name- Required

Option - Optional

CCF function command name optionADD ALL FORCEDELETE * MAINTINIT CMD_NAME CHKP

CMD_ALIASENABLE PATTERN CONSOLE=console_idDISABLE

RESET KEY=keywordEXCEPT GROUP XRF=xrf_wkld

JES=jes_wkldHELP MSn=ms_wkldSHOWSTATUS

DISPLAY



Functions

The function parameter is used to tell the Command Manager which action to take against a command. Many, but not all, functions have abbreviations. Acceptable abbreviations are noted with the function's description.

ADD Adds and activates a pre-defined command trap immediately. No abbreviations of the ADD keyword are acceptable.

DELETE Deactivates a pre-defined command trap immediately and deletes the definition from storage. Valid abbreviations are: DEL.

INIT Initializes a command trap defined to the Command Manager so that changes to the command's definition will take effect immediately without affecting the status of other commands. The command trap will be added and activated if so defined, otherwise the command trap will be added in a disabled state. No abbreviations of the INIT keyword are acceptable.

ENABLE Activates a command trap that was previously added or initialized in a disabled state to the Command Manager. Valid abbreviations are: ENA.

DISABLE Deactivates a command trap previously added and enabled. No abbreviations of the DISABLE keyword are acceptable.

RESET Resets business day/non-business day Command Manager traps. Valid abbreviations are: RES and R.

EXCEPT EXCEPT is used to temporarily except a command trap from being enabled on a system. This function will alter the in-storage copy of the Command Manager Command Control table to define the command with a KEYWORD of NONE. An excepted command will no longer be managed by the Command Manager. To re-enable Command Manager control of an excepted command, a 'CCF INIT command FORCE' command must be issued. Valid abbreviations are: EX and E.

HELP Displays the Command Manager on-line help file on the operator console. No abbreviations of the HELP keyword are acceptable.

SHOW Shows an AF/OPERATOR, Command Manager created, trap associated with the command. Valid abbreviations are: SH.

Command Manager 199


Command Name

STATUS Issues a WTO to the MVS console that indicates the Command Manager status for the specified command. Valid abbreviations are: STAT and S.

A command can be in any one of the following states:� DEFINED The Command Manager knows about

the command, but does not know whether the command trap is enabled or disabled.

� ENABLED The command trap is enabled (activated) on the system.

� DISABLED The command trap is disabled (deactivated) on the system.

� UNKNOWN The command's status is unknown. This is usually the case if the Command Manager has not fully initialized.

� BYPASSED There are two options for this status:– MANUAL MODE The command trap was not

enabled at Command Manager initialization since the system was IPL'ed in a manual mode.

– NON BUSINESS DAY The command trap was not enabled since the current processing day is defined as a non-business day.

� NOT DEFINED TO THIS SYSTEM The command trap is not defined to this system.

DISPLAY Displays the requested Command Manager information via WTO to the MVS console. The default display is the same as the STATUS display as described above. Valid abbreviations are: DIS and D.



The command name parameter is used to tell the Command Manager which commands to manage. The aforementioned function will be performed for the commands specified with this parameter.

ALL The ALL keyword is used to specify all commands defined to the system. All commands known to the Command Manager will be interrogated, those that have been defined to this system via the Command Control table will be chosen. A '*' is a synonym for the ALL keyword.

CMD_NAME A command name precisely as coded in the Command Control table.

CMD_ALIAS A command alias precisely as coded in the Command Control table.

PATTERN A command name pattern, using a '*' as a wild card character. Any command with a name or alias, CMD_NAME or MSG_ALIAS, that begins with the letters preceding the asterisk (*) and is defined to the system will be managed.

GROUP A keyword, which specifies that a group definition option is to follow. The commands included in a group are defined via the Command Control table. There are no abbreviations for the GROUP keyword. Valid group options are:� KEY=keyword

KEYWORD group as defined in the Command Control Table. Valid values for keyword are: ALL, AUTO, NONE, MANUAL and INTERNAL.

� XRF=xrf_wkldXRF workload group as defined in the Command Control Table. Valid values for xrf_wkld are: ACT and ALT.

� JES=jes_wkldJES workload group as defined in the Command Control Table. Valid values for jes_wkld are: GLB and LCL.

� MSn=msn_wkldMS1 through MS4 workload groups as defined in the Command Control Table. Valid values for an MSn keyword are site specific.

Command Manager 201


Standard Options

The standard options are used to alter the normal Command Manager processing of a function for a command.

FORCE The FORCE option is used to force a command that is not defined to a system onto that system. Valid abbreviations are: F.

Note: If a command is forced onto a system via an CCF INIT or CCF ADD command, the Command Manager will update the in-storage copy of the Command Control table and define the command to the system. Anytime after this, you need not use the FORCE option on the CCF command to manage the command.

This is a temporary change that will be in effect until the next time AF/OPERATOR is cycled. Once AF/OPERATOR is brought down, the definition of the command will revert to that specified in the Command Manager tables.

MAINT The MAINT option is used to manage only those commands that have been defined with a KEYWORD of AUTO. This is a special option used when IPL'ing a maintenance system. Valid abbreviations are: M.

CHKP The CHKP option is used to perform a checkpoint restart of the Command Manager. This is a special option used by the Application Manager when processing a checkpoint restart. There are no abbreviations for the CHKP option.

CONSOLE=console_id

The CONSOLE option is used to specify the console to receive Command Manager commands for a function. Specify either a valid console ID or the device address of the console for the console_id argument. There are no abbreviations for the CONSOLE option.



CCF Command On-line HelpOn-line help for the Command Manager CCF command is available anytime. To display on-line help for the CCF command, enter the following command at the MVS operator console:

CCF HELP

The Command Manager will then display the CCF command syntax followed by a brief explanation of each of the keywords associated with the command.

Schedule Manager 203

Schedule Manager

IntroductionThe Schedule Manager is a facility that allows you to manage scheduled events. The Schedule Manager is used to create and manage Time-of-Day instruction rules, called traps, firing at a specific date and time to perform a user defined action.

The Schedule Manager offers a wide variety of options which allow you to control what schedule traps are enabled on each system. The Schedule Manager can enable a schedule trap based on keyword groups, workload groups or on an individual system identified by SMF or CPU ID. Each schedule is treated as a unique object that can be grouped with other similar schedules or managed by itself.

Chapter ContentsSchedule Manager Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204Schedule Manager Schedule Definition . . . . . . . . . . . . . . . . . . . . . . . . . 206Using the Service Subroutines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215Controlling Schedule Manager Resources . . . . . . . . . . . . . . . . . . . . . . . . 216

4

Schedule Manager Components



The Schedule Manager has 3 components: They are:

� Schedule definition



Schedule DefinitionThe Schedule Manager tables hold information used to create TOD traps for the scheduled events you want to automate with the Schedule Manager. All of the tables are members of the Automation Application table dataset, hilev.RKAUTBLR. The tables are created by the user via the IRM ISPF Interface. The interface enables the user to populate the table fields with the appropriate information for each schedule definition. The section, Schedule Manager Schedule Definition beginning on page 206, describes the Schedule Manager automation tables in detail.

Service SubroutinesThe Schedule Manager service subroutines are AF/OPERATOR command files used to perform a variety of functions for the schedules controlled by the Schedule Manager:

� Add a schedule trap

� Delete a schedule trap

� Enable/Disable an existing schedule trap


@SCFINIT This exec initializes the Schedule Manager environment: creating an MVS console command, called SCF, that allows you to perform various management functions on a single schedule or group of schedules, performing clean-up activities, and invoking @SCFMAIN at AF/OPERATOR start-up to initialize and add all of the schedule traps controlled by the Schedule Manager.



AF/OPERATOR System VariablesThe Schedule Manager creates the following AF/OPERATOR system variables to track schedule status over time:

@SCFMAIN This exec processes Schedule Manager commands issued to control schedules.

@SCFMAIN is responsible for: validating and processing command text, determining if a given schedule is defined to a system, responding to operator inquiries, adding/deleting schedule traps and activating/inactivating schedule traps.

@SCFHELP This exec provides the Schedule Manager on-line help facility.

@SCFCALL This exec is an external REXX function used by other Automation Applications to request Schedule Manager services.

@S####F Schedule Checkpoint Flags

@S####S Schedule Status

Schedule Manager Schedule Definition



OverviewTo manage the schedules under its control, the Schedule Manager uses information stored in tables created by the user. The tables that contain the schedule management information are:

Each table is a member of the Automation Application table dataset. These tables are loaded into above-the-line storage at AF/OPERATOR and Automation Application initialization time.

Anytime a Schedule Manager schedule is accessed, the appropriate information is retrieved from the tables and used to determine how to manage the schedule.

Adding or Updating SchedulesTo add or update an object definition in the Schedule Manager, execute the KAUUISPF exec from the hilev.RKAUEXEC dataset to activate the IRM ISPF User Interface. Object definition information is entered on the appropriate panels from within the IRM ISPF User Interface. Under no circumstances attempt to edit the IRM tables outside of the ISPF User Interface as this will cause unpredictable results possibly causing the IRM environment to become unusable.

To implement the changes while AF/OPERATOR is running, use the Table Manager REFRESH command to refresh the in-storage copies of the Schedule Manager tables. This gives the Schedule Manager access to the new data. Then you can issue an SCF INIT command, specifying the schedule name, to initialize a new schedule or update an existing one.

@SCFCNTL The Schedule Manager Control Table.

@SCFSMFD The Schedule Manager SMF ID Control Table.

@SCFEXCP The Schedule Manager Exception Control Table.

@SCFTRAP The Schedule Manager Trap Table.

@SCFTACT The Schedule Manager Trap Action Table.



The figure below indicates which tables will need to be refreshed to implement changes to the various Schedule Manager Definition sections.

ISPF Panel Section Name: SCF Table Name

Control Data @SCFCNTL

@SCFSMFD

@SCFEXCP

Trap Data @SCFTRAP

@SCFCNTL

Triggerring Conditions @SCFTRAP

@SCFCNTL

Actions @SCFTACT

Schedule Manager - Add a Schedule

Schedule Data

Schedule Name The name of the schedule to manage. This field is the table row name key and will be identified in the rest of the Schedule Manager tables as a reference key in order to tie all Schedule Manager information together.

This is a 12 character alphanumeric field assigned by the user. Any alphanumeric character may be used for the name with the exception of an asterisk (*) or double quotes (").

Description A one line description for the schedule. The Schedule Description field is used to provide a 'Plain English' description of the schedule for user reference. This field is displayed on the main Schedule Manager selection panel.




Schedule Manager Schedule Definition Panel

Control Data

Alias Specifies an alias for the Schedule Manager schedule name. This is a 12 character alphanumeric field, assigned by the user. The schedule alias can be used to group schedules and/or identify a schedule by other than its defined TOD_NAME.

Keyword KEYWORD is the first mechanism which identifies whether a schedule is defined to a system. The KEYWORD field is used as a generalized grouping mechanism to identify those schedules that are defined to all systems, no systems or manipulated internally by other Automation Applications. Valid values are:� ALL Specifies that the schedule is defined to all

systems. The Schedule Manager will initialize this schedule on every system the Schedule Manager runs on.

� AUTO Specifies that the schedule is defined to all systems. Under most circumstances the AUTO keyword is identical to the ALL keyword, except in the case of bringing up a maintenance system running in manual application processing mode. When running in manual mode to bring up a maintenance system, only those schedule traps identified as AUTO will be added. When running in automated mode, the Schedule Manager will initialize the schedule trap on every system the Schedule Manager runs on.

� NONE Specifies that the schedule is not defined to any system. The Schedule Manager will not initialize this schedule on any system.

Note: The schedule trap can be initialized via manual intervention by specifying the Force option on an SCF INIT command. This keyword is used to identify those schedule traps that should not be added automatically, but rather, are added on-demand by manual intervention.



Keywordcont.

� MANUAL Specifies that the schedule trap is not to be automatically added during Schedule Manager initialization. During initialization, or anytime an SCF INIT ALL or SCF ADD ALL command is processed, the Schedule Manager will bypass this schedule. A schedule with a KEYWORD of MANUAL will be managed only if an SCF INIT command for the schedule itself is manually entered at the operator console.

� INTERNALSpecifies that the schedule trap will be initialized internally by another of the Automation Applications; the schedule trap will not be automatically added during Schedule Manager initialization. A schedule trap defined as INTERNAL can only be accessed by the controlling application.

Note: Schedules defined with a KEYWORD of INTERNAL are hidden from normal Schedule Manager operations. INTERNAL schedule traps can not be accessed directly by Schedule Manager commands, unless the Force option of the SCF command is used. This includes all Schedule Manager displays for the schedule trap.

Leave blank if the schedule does not fall into any of these categories and the Schedule Manager will continue searching the remaining categories to determine if the schedule is defined to the system.

Number Specifies a unique number for the schedule starting from 1001. This is a four character numeric field used by the Schedule Manager in creating AF/OPERATOR variables and traps associated with the schedule.

The schedule numbers need not be consecutive and are not used in any ordering scheme, but each schedule must have a unique number assigned to it.



XRF Workload XRF Workload is a grouping mechanism which identifies whether a schedule is defined to a system. If the system is defined as an IMS/XRF active system, any schedule identified as ACT by the XRF Workload field will be managed. Similarly, if the system is defined as an IMS/XRF alternate system, any schedule identified as ALT by the field will be managed. Valid values are:� ACT Specifies that the schedule is to be initialized

on any IMS/XRF active system.� ALT Specifies that the schedule is to be initialized

on any IMS/XRF alternate system.Leave blank if the schedule does not fall into any of these categories and the Schedule Manager will continue searching the remaining categories to determine if the schedule is defined to the system.

Note: This field is used to identify schedules that are to be managed as a group for IMS/XRF activities, such as workload movement in the event of an IMS/XRF takeover.

JES Workload JES Workload is a grouping mechanism which identifies whether a schedule is defined to a system. If the system is defined as a JES3 Global system, any schedule identified as GLB by the JES Workload field will be managed. Similarly, if the system is defined as a JES3 Local system, any schedule identified as LCL by the field will be managed. Valid values are:� GLB Specifies that the schedule is to be initialized

on any JES3 Global processor.� LCL Specifies that the schedule is to be initialized

on any JES3 Local processor.Leave blank if the schedule does not fall into any of these categories and the Schedule Manager will continue searching the remaining categories to determine if the schedule is defined to the system.

Note: This field is used to identify schedules that are to be managed as a group for JES3 activities, such as workload movement in the event of a Dynamic System Interchange (DSI).



MSn MSn is a grouping mechanism which identifies whether a schedule is defined to a system. MS1 through MS4 are four user assigned workload grouping fields. If the user assigned system variable and the MSn_WKLD fields match, the schedule will be managed.� MS1 Currently defined as IMS. Specifying IMS in

this field will cause the schedule to be managed on any system defined as MS1=IMS.

� MS2 Currently defined as ADF or PRD. Specifying ADF will cause the schedule to be managed on any system defined as MS2=ADF. Specifying PRD will cause the schedule to be managed on any system defined as MS2=PRD.

� MS3 Currently unassigned.� MS4 Currently unassigned.Leave if the schedule does not fall into any of these categories and the Schedule Manager will continue searching the remaining categories to determine if the schedule is defined to the system.

CPU ID The CPUID 1 through CPUID 12 fields allow the user to specifically define up to 12 unique CPU IDs where the schedule is to be managed. If the schedule does not fit into any schedule grouping as previously described, you can code the individual CPU IDs of the systems where the schedule is to be managed.

Leave blank any CPUID field that is not in use.

Note: A CPU ID can be coded as either the full six character CPU ID or just the right-most five characters for those schedule traps that are not LPAR dependent. For five character CPU IDs, the first character of the CPU ID, the LPAR identifier, will be ignored.



Trap Data

SMF ID The SMFID 1 through SMFID 24 fields allow the user to specifically define up to 24 unique SMF IDs where the schedule is to be managed. If the schedule does not fit into any schedule grouping as previously described, code the individual SMF IDs of the systems where the schedule is to be managed.

Leave blank any SMFID field that is not in use.

Note: If you have not specified the schedule in any of the previous workload groups, an SMF ID must be specified in order to manage the schedule. If an SMF ID is not coded, the schedule will not be managed anywhere.

Exceptions The Exceptions fields allow the user to exclude up to 24 unique SMF IDs where the schedule is not meant to be managed. If the schedule fits into a schedule grouping except for a couple of systems, include the schedule in the group and code the individual SMF IDs of the systems that are exceptions in the Exceptions fields.

Leave blank any Exceptions field that is not in use.

Schedule Time The point in time when the trap will be executed. Specify in the form HH:MM:SS.

The time must be in the range: 00:00:01 to 24:00:00.

Date Specifies the date when the schedule trap will be executed. Code the date in the formats (YYYY/MM/DD or YY/MM/DD). Single character is allowed for month & day. If date is not specified, system date is used.

Interval Specifies that the action will be performed periodically. The interval parameter is specified in the form HH:MM:SS. The maximum interval allowed is 24 hours. Specifying 24:00:00 will cause the trap to be executed once a day at the time specified in the TOD_TIME field.

Enable This is a binary field (0,1). Specify 1 to enable the trap during Schedule Manager initialization. Specify 0 to manually manage the activation of the trap by means of an SCF ENABLE command from the operator console.




Test This is a binary field (0,1). Specify 1 if you want to disable immediate and extended actions for this trap: the only commands that will execute are the ones that would normally execute in AF/OPERATOR warn mode. If TEST is enabled when the trap is triggered, a record of the action that would have been taken is logged in the message log. Specify 0 if you want all immediate and extended actions to execute for this trap.

Log This is a binary field (0,1). Specify 1 if you want a record written to the AF/OPERATOR message log every time the trap is triggered. Specify 0 if you want no record of the trap being triggered nor of the trap action taken.

Catchup Specifies the number of times AF/OPERATOR CATCHUP processing will be invoked. Specifying a number, n, causes AF/OPERATOR to execute the command specified in the Action field whenever the current system date and time are later than the next scheduled execution date and time of the trap.

The trap action will be taken repeatedly until either the TOD trap is scheduled for the future or the CATCHUP limit, n, is reached. Leave this field blank if CATCHUP processing should not be in effect for this schedule.

Specifying CATCHUP processing for a schedule will cause the trap to be check-pointed when added and each time it fires. Checkpointed TOD traps are reloaded at AF/OPERATOR initialization if AF/OPERATOR is warm started and the RELOAD parameter is set to TODS.

Days The days on which you want the trap to be triggered. The trap will be triggered only on days explicitly listed here. This is a binary field (0,1), starting with Sunday. For instance, 0111110, will result in the trap being triggered Monday through Friday. Leave this field blank to allow the trap to be triggered on all days.



Extended Actions

Bus This is a binary field (0,1). Specify 1 if you want the schedule to be managed only on business days. Specify 0 if you want the schedule to be managed every day.

Action An MVS operator command or an AF/OPERATOR command you want to execute when the trap is triggered. It may be an EXEC command that executes a command file or a REXX exec. It must be a single command no more than 128 characters in length.

Leave blank if no MVS command, AF/OPERATOR command, or AF/OPERATOR command file is to be executed.

If the command is an MVS operator command, the OPER keyword must prefix the quoted command string. Enclose the entire field in double quotes ("). If a command is passing a quoted parameter, enclose the parameter in 4 single quotes:



Limit This field is used in conjunction with the Alternate field. Specify a number, n, where every nth time the trap is triggered, the Automation Facility issues the command specified in the Alternate field instead of the command specified in the Action field. Leave this field blank to execute the command in the Action field every time the trap is triggered.

Alternate This field is used in conjunction with the Match limit field. Specify an MVS command or AF/OPERATOR command that you want to execute every nth time the trap is triggered, where n is the number specified in the Match limit field.




OverviewOnce the automation table component of the Schedule Manager has been defined, the information needed to manage schedules for an environment is available to the Schedule Manager service subroutines. To initiate the actual management of schedules, the Schedule Manager service subroutines must be activated.

Starting the Service SubroutinesThe Schedule Manager is automatically started at AF/OPERATOR initialization time by the Application Manager which executes the @SCFINIT exec. This command file initializes the Schedule Manager environment and executes @SCFMAIN to initialize and set all schedule traps that should be running at the current time and date for that system; therefore, all schedule traps defined to a system and scheduled to be enabled, but are not currently, will be enabled. In addition, @SCFINIT will set up a command trap for the SCF operator command.

If AF/OPERATOR is already running, you can activate the Schedule Manager before the next AF/OPERATOR recycle by issuing the following Application Manager command from the MVS console:

APL INIT SCF

Note: This assumes that the Schedule Manager tables have been pre-loaded into storage by the Table Manager. If the Schedule Manager tables have not been automatically loaded, issue the appropriate Table Manager commands, from the MVS console, to load the tables before you initialize the Schedule Manager.

Controlling Schedule Manager Resources



The SCF command provides an operator interface to give you additional control over the schedules defined to the Schedule Manager. It is used to communicate with AF/OPERATOR and the Schedule Manager service subroutines to control Schedule Manager schedules and display Schedule Manager information about the schedules from the MVS console.


SCF ENABLE AOMSGLOG

at any time, to enable the schedule trap associated with the schedule definition you named AOMSGLOG. The schedule name specified in the command is the same as the TOD_NAME field you coded in the Schedule Control table.

An asterisk (*) is treated as a wild card character, which allows you to specify groups of like-named schedules. For example, the command:

SCF ENABLE AO*

will enable all schedules defined with a TOD_NAME that begins with the letters AO.



SCF Command SyntaxThe following table shows the available SCF commands. To protect against unintentional command errors, certain function/schedule name/option combinations are prohibited. This includes:

� Functions INIT, ADD, or DELETE with schedule name ALL or * with the FORCE option.

FIGURE 7. SCF Command Syntax

Parameters

Function - Required

Schedule Name - Required

Option - Optional

SCF function schedule name optionADD ALL FORCEDELETE * MAINTINIT TOD_NAME CHKP

TOD_ALIASENABLE PATTERN CONSOLE=console_idDISABLE

RESET KEY=keywordEXCEPT GROUP XRF=xrf_wkld

JES=jes_wkldHELP MSn-ms_wkldSHOWSTATUS

DISPLAY



Functions

The function parameter is used to tell the Schedule Manager which action to take against a schedule. Many, but not all, functions have abbreviations. Acceptable abbreviations are noted with the function's description.

ADD Adds and activates a pre-defined schedule trap immediately. No abbreviations of the ADD keyword are acceptable.

DELETE Deactivates a pre-defined schedule trap immediately and deletes the definition from storage. Valid abbreviations are: DEL.

INIT Initializes a schedule trap defined to the Schedule Manager so that changes to the schedule's definition will take effect immediately without affecting the status of other schedules. The schedule trap will be added and activated if so defined, otherwise the schedule trap will be added in a disabled state. No abbreviations of the INIT keyword are acceptable.

ENABLE Activates a schedule trap that was previously added or initialized in a disabled state to the Schedule Manager. Valid abbreviations are: ENA.

DISABLE Deactivates a schedule trap previously added and enabled. No abbreviations of the DISABLE keyword are acceptable.

RESET Resets business day/non-business day Schedule Manager traps. Valid abbreviations are: RES and R.

EXCEPT EXCEPT is used to temporarily except a schedule trap from being enabled on a system. This function will alter the in-storage copy of the Schedule Manager Schedule Control table to define the schedule with a KEYWORD of NONE. An excepted schedule will no longer be managed by the Schedule Manager. To re-enable Schedule Manager control of an excepted schedule, an 'SCF INIT schedule FORCE' command must be issued. Valid abbreviations are: EX and E.

HELP Displays the Schedule Manager on-line help file on the operator console. No abbreviations of the HELP keyword are acceptable.

SHOW Shows an AF/OPERATOR, Schedule Manager created, trap associated with the schedule. Valid abbreviations are: SH.



STATUS Issues a WTO to the MVS console that indicates the Schedule Manager status for the specified schedule. Valid abbreviations are: STAT and S.

A schedule can be in any one of the following states:� DEFINED The Schedule Manager knows about the

schedule, but does not know whether the schedule trap is enabled or disabled.

� ENABLED The schedule trap is enabled (activated) on the system.

� DISABLED The schedule trap is disabled (deactivated) on the system.

� UNKNOWN The schedule's status is unknown. This is usually the case if the Schedule Manager has not fully initialized.

� BYPASSED There are two options for a status of BYPASSED:

– MANUAL MODE The schedule trap was not enabled at Schedule Manager initialization since the system was IPL'ed in a manual mode.

– NON BUSINESS DAY The schedule trap was not enabled since the current processing day is defined as a non-business day.

DISPLAY Displays the requested Schedule Manager information via WTO to the MVS console. The default display is the same as the STATUS display as described above. Valid abbreviations are: DIS and D.



Schedule Name

The schedule name parameter is used to tell the Schedule Manager which schedules to manage. The afore mentioned function will be performed for the schedules specified with this parameter.

ALL The ALL keyword is used to specify all schedules defined to the system. All schedules known to the Schedule Manager will be interrogated, those that have been defined to this system via the Schedule Control table will be chosen. A '*' is a synonym for the ALL keyword.

TOD_NAME A schedule name precisely as coded in the Schedule Control table.

TOD_ALIAS A schedule alias precisely as coded in the Schedule Control table.

PATTERN A schedule name pattern, using a '*' as a wild card character. Any schedule with a name or alias, TOD_NAME or TOD_ALIAS, that begins with the letters preceding the asterisk (*) and is defined to the system will be managed.

GROUP A keyword, which specifies that a group definition option is to follow. The schedules included in a group are defined via the Schedule Control table. There are no abbreviations for the GROUP keyword. Valid group options are:� KEY=keyword

KEYWORD group as defined in the Schedule Control Table. Valid values for keyword are: ALL, AUTO, NONE, MANUAL and INTERNAL.

� XRF=xrf_wkldXRF workload group as defined in the Schedule Control Table. Valid values for xrf_wkld are: ACT and ALT.

� JES=jes_wkldJES workload group as defined in the Schedule Control Table. Valid values for jes_wkld are: GLB and LCL.

� MSn=msn_wkldMS1 through MS4 workload groups as defined in the Schedule Control Table. Valid values for an MSn keyword are site specific.



Standard Options

The standard options are used to alter the normal Schedule Manager processing of a function for a schedule.

FORCE The FORCE option is used to force a schedule that is not defined to a system onto that system. Valid abbreviations are: F.

Note: If a schedule is forced onto a system via an SCF INIT or SCF ADD command, the Schedule Manager will update the in-storage copy of the Schedule Control table and define the schedule to the system. Anytime after this, you need not use the FORCE option on the SCF command to manage the schedule.

This is a temporary change that will be in effect until the next time AF/PERATOR is cycled. Once AF/OPERATOR is brought down, the definition of the schedule will revert to that specified in the Schedule Manager tables.

MAINT The MAINT option is used to manage only those schedules that have been defined with a KEYWORD of AUTO. This is a special option used when IPL'ing a maintenance system. Valid abbreviations are: M.

CHKP The CHKP option is used to perform a checkpoint restart of the Schedule Manager. This is a special option used by the Application Manager when processing a checkpoint restart. There are no abbreviations for the CHKP option.

CONSOLE=console_id

The CONSOLE option is used to specify the console to receive Schedule Manager schedules for a function. Specify either a valid console ID or the device address of the console for the console_id argument. There are no abbreviations for the CONSOLE option.



SCF Command On-line HelpOn-line help for the Schedule Manager SCF command is available anytime. To display on-line help for the SCF command, enter the following command at the MVS operator console:

SCF HELP

The Schedule Manager will then display the SCF command syntax followed by a brief explanation of each of the keywords associated with the command.

VTAM Manager 223

VTAM Manager

IntroductionThe VTAM Manager is used to automate the activation and management of VTAM nodes. The VTAM Manager can be used to automatically activate and inactivate the VTAM nodes needed by Started Tasks or other VTAM applications running on your system. The VTAM Manager can be used to:

� Activate a VTAM node before a Started Task is started.� Activate a node as an individual object.� Activate all nodes defined to a system when VTAM is started.

The VTAM Manager allows you to define a default VTAM node name for an object or a system specific node name if the same object has a different VTAM node name on each system. The VTAM Manager also allows you to specify different node names for the VTAM object based on the CPU or LPAR on which the system is running. The flexibility of the VTAM Manager object definitions allow you to manage many individual VTAM nodes as a single entity. Any node that is used for a similar purpose, but uniquely named on each system can be represented by a single VTAM Manager object. Each VTAM object can then be grouped with other similar objects or managed by itself. The VTAM Manager is initialized in a two step process. The basic VTAM Manager environment is created at AF/OPERATOR initialization time. The actual management of VTAM nodes is enabled once VTAM itself has been started.

5


Chapter ContentsVTAM Manager Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225VTAM Manager Resource Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227Using the Service Subroutines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233Controlling VTAM Manager Resources . . . . . . . . . . . . . . . . . . . . . . . . . . 234

VTAM Manager 225

VTAM Manager Components


The VTAM Manager has three components. They are:

� VTAM resource definition



VTAM Resource DefinitionTo manage the VTAM nodes under its control, the VTAM Manager uses information stored in a table created by the user. The table that contains the VTAM Node information is @VTMCNT; the VTAM Manager Control Table.

This table is a member of the Automation Application table dataset, hilev.RKAUTBLR. The table is created by the user via the IRM ISPF Interface. The interface enables the user to populate the table fields with the appropriate information for each VTAM resource definition. The table is loaded into above-the-line storage at AF/OPERATOR and Automation Application initialization time. Anytime a VTAM Manager node is accessed, the appropriate information is retrieved from the table and used to determine how to manage the VTAM node. The section, VTAM Manager Resource Definition beginning on page 227, describes the VTAM Manager automation table in detail.

Service SubroutinesThe VTAM Manager service subroutines are AF/OPERATOR command files which perform the services needed to manage VTAM nodes. The VTAM Manager service subroutines are comprised of the following execs:

@VTMDISP This exec captures D NET ID display response and stores information in the VTAM Node Display Table.

@VTMINIT This exec initializes the VTAM Manager environment and creates an MVS console command, called VTM, that allows you to perform various management functions on a single VTAM node or group of nodes.



AF/OPERATOR System VariablesThe VTAM Manager creates the following AF/OPERATOR system variables to track VTAM node status over time:

@VTMMAIN This exec processes VTAM Manager commands issued to manage VTAM nodes.

@VTMMAIN is responsible for: validating and processing command text, determining if the specified node is defined to the system, responding to operator inquiries, and activating or inactivating VTAM nodes.

@VTMHELP This exec provides the VTAM Manager on-line help facility.

@VTMCALL This exec is an external REXX function used by other Automation Applications to internally request VTAM Manager services.

@VTMDNET This exec determines the status of a VTAM node against a supplied desired state. Returns a 1 if the condition is true and a 0 if false.

@VTMVNET This exec varies a VTAM node active or inactive. Returns a 1 if the vary command is successful and a 0 if unsuccessful.

@V####F VTAM Node Checkpoint Flags

@V####S VTAM Node Status

@VTMSSCN Current VTM Subsystem Console

VTAM Manager 227

VTAM Manager Resource Definition


OverviewTo manage the VTAM resources, the VTAM Manager uses information stored in a table that is dynamically created by the user. The tables is:

This table is a member of the Automation Application table dataset. The table is loaded into above-the-line storage at AF/OPERATOR and Automation Application initialization time. Anytime a VTAM Manager node is accessed, the appropriate information is retrieved from the table and used to determine how to manage the VTAM node.

Adding or Updating CommandsTo add or update an object definition in the VTAM Manager, execute the KAUUISPF exec from the hilev.RKAUEXEC dataset to activate the IRM ISPF User Interface. Resource definition information is entered on the appropriate panels from within the IRM ISPF User Interface. Under no circumstances attempt to edit the IRM tables outside of the ISPF User Interface as this will cause unpredictable results possibly causing the IRM environment to become unusable.To implement the changes while AF/OPERATOR is running, use the Table Manager REFRESH command to refresh the in-storage copy of the VTAM Manager Control table. This gives the VTAM Manager access to the new data. You can then issue a VTM INIT command to initialize control of the new or updated VTAM node.

@VTMCNTL VTAM Manager Control Table



VTAM Manager Resource Definition Panel

Object Name The name of the VTAM object to manage. This field is the first table key. This is a 12 character alphanumeric field which defines the user assigned VTAM object name.

Any alphanumeric character may be used for the name with the exception of an asterisk (*) or double quotes ("). Object names need not be unique; an object name may be repeated if the System or CPU keys are used to uniquely identify the row.

System This field is used to identify the scope of the VTAM object definition. Code the DEFAULT keyword to enable the definition on all systems. Code an SMF ID to enable the object definition only on a specific system. This field is the second table key.

Note: Each VTAM object must have a DEFAULT definition. If there is no valid node information for the DEFAULT definition, code an asterisk (*) in the VTAM_NOD field.

CPU This field is used to identify the scope of the VTAM object definition based on CPU ID. Leave this field blank if the definition is not dependent on CPU ID. Code a CPU ID to enable the object definition only on a specific system, running on a specific CPU. This field is the third table key. This field is used in combination with the System field; an SMF ID must be coded in the System field before the CPU key will be recognized.

Note: A CPU ID can be coded as either the full six character CPU ID or just the right-most five characters for those VTAM object definitions that are not LPAR dependent. For five character CPU IDs, the first character of the system CPUID, the LPAR identifier, will be ignored by the VTAM Manager.

Number Specifies a unique number for the VTAM object starting from 1001. This is a four character numeric field used by the VTAM Manager in creating AF/OPERATOR variables and traps associated with the object. The VTAM object numbers need not be consecutive and are not used in any ordering scheme, but each VTAM object, a unique definition in the Object Name field, must have a unique number assigned to it.

VTAM Manager 229


Keyword The Keyword field is used as a generalized grouping mechanism to identify those VTAM objects that are defined to all systems, no systems, or manipulated internally by other Automation Applications. Valid values are:� ALL Specifies that the VTAM object is defined to

all systems. The VTAM Manager will activate the VTAM node on every system.

� AUTO Specifies that the VTAM object is defined to all systems. Under most circumstances the AUTO keyword is identical to the ALL keyword, except in the case of bringing up a maintenance system running in manual application processing mode. When running in manual mode to bring up a maintenance system, only those objects identified as AUTO will be managed. When running in automated mode, the VTAM Manager will activate the VTAM node on every system.

� NONE Specifies that the VTAM object is not defined to any system. The VTAM Manager will not initialize this VTAM object on any system.

� MANUAL Specifies that the VTAM object is not to be automatically activated during VTAM Manager initialization. During initialization, or anytime a VTM INIT ALL or VTM START ALL command is processed, the VTAM Manager will bypass this VTAM object. A VTAM object with a KEYWORD of MANUAL will be managed only if a VTM INIT command for the VTAM object itself is manually entered at the operator console.

� INTERNALSpecifies that the VTAM object will be initialized internally by another of the Automation Applications; the VTAM object will not be automatically activated by the VTAM Manager. A VTAM object defined as INTERNAL can only be accessed by the controlling application.



Keywordcont.

Note: VTAM objects defined with a KEYWORD of INTERNAL are hidden from normal VTAM Manager operations. INTERNAL VTAM objects can not be accessed directly by VTAM Manager commands, unless the Force option of the VTM command is used. This includes all VTAM Manager displays for the VTAM object.

Note: The VTAM object can be initialized via manual intervention by specifying the Force option on a VTM INIT command. This keyword is used to identify those VTAM objects that should not be activated automatically, but rather, are enabled on-demand by manual intervention.

VTAM Node Name

This field is used to identify the VTAM node name for the object definition. This is an 8 character alphanumeric field. Leave this field blank if there is no node name associated with this definition.

If a VTAM object has different node names on different systems, include a separate row for each system identifying the same VTAM object name in the Object Namefield. Then differentiate the object definitions by coding the appropriate SMF ID for each row in the System field and the node name for the object on that system in this field.

Interval This field is used to specify the verification interval for VTAM Vary commands. When a command is issued to vary a node active or inactive, the VTAM Manager will wait for the time limit specified by this field for verification that the command was successful. Code the verification interval in the form: HH:MM:SS. The default is 30 seconds, 00:00:30.

Recovery Option

This is a binary field. Specify 1 to enable recovery processing for the node. Specify 0 if recovery is not required for the node.

Vary Active This is a binary field (0,1). Specify 1 to allow the VTAM Manager to vary the node active. Specify 0 to limit the VTAM Manager to only inactivating the node. The default is 1.

VTAM Manager 231


Vary Active Check

This is a binary field (0,1). Specify 1 to have the VTAM Manager check the current state of the VTAM node before it attempts to vary the node active. Specify 0 to have the VTAM Manager vary the node active regardless of its current state. The default is 1.

Vary Inactive This is a binary field (0,1). Specify 1 to allow the VTAM Manager to vary the node inactive. Specify 0 to limit the VTAM Manager to only activating the node. The default is 0.

Vary Inactive Check

This is a binary field (0,1). Specify 1 to have the VTAM Manager check the current state of the VTAM node before it attempts to vary the node inactive. Specify 0 to have the VTAM Manager vary the node inactive regardless of its current state. The default is 0.

Vary Active Option

This field is used to specify an option for the VTAM Vary Active command. Valid values are: LOGON=applid and LOGMODE=mode. Specify the LOGON option to dedicate the VTAM object to the application identified by applid. Specify the LOGMODE option to control the LOGMODE of the LU dedicated with the LOGON option:

LOGON=V15OMII,LOGMODE=SNX32702

Leqve this field blank if no option for the vary active command should be used for this object.

Vary Inactive Option

This field is used to specify an option for the VTAM Vary Inactive command. Valid values are: I and F. Specify I, to include the immediate option on the vary inactive command. Specify F, to include the force option on the vary inactive command. Leave this field blank if no option for the vary inactive command should be used for this object.

Pre-Start Exit Specify the name of a pre-start exit command file to be executed prior to the VTAM resource start process. This field is optional. Leave this field blank if there is no pre-start exit command file enabled for the object.

Post Start Exit Specify the name of a post-start exit command file to be executed after the completion of VTAM resource start process. This field is optional. Code an asterisk (*) if there is no post-start exit command file enabled for the object.



Pre-Stop Exit Specify the name of a pre-stop exit command file to be executed prior to the VTAM resource stop process. This field is optional. Leave this field blank if there is no pre-stop exit command file enabled for the object.

Post Stop Exit Specify the name of a post-stop exit command file to be executed after the completion of VTAM resource stop process. This field is optional. Leave this field blank if there is no post-stop exit command file enabled for the object.

Pre-Recovery Exit

Specify the name of a pre-recovery exit command file to be executed prior to the VTAM recovery process. This field is optional. Leave this field blank if there is no pre-recovery exit command file enabled for the object. If a pre-recovery exit command file is coded in this field, the recovery option must be enabled.

Post Recovery Exit

Specify the name of a post-recovery exit command file to be executed after the completion of the VTAM recovery process. This field is optional. Leave this field blank if there is no post-recovery exit command file enabled for the object. If a post-recovery exit command file is coded in this field, the recovery option must be enabled.

Description A one line description of the object. The object's description field is used to provide a 'Plain English' description of the object for user reference. Up to 20 characters of free form text is allowed.

VTAM Manager 233



OverviewOnce the automation table component of the VTAM Manager has been defined, the information needed to manage VTAM nodes for an environment is available to the VTAM Manager service subroutines. To initiate the actual management of VTAM nodes, the VTAM Manager service subroutines must be activated.

Starting the Service SubroutinesThe VTAM Manager is automatically initialized at AF/OPERATOR initialization time by the Application Manager which executes the @VTMINIT exec. This command file initializes the VTAM Manager environment and creates the VTM console command. The VTAM Manager can be automatically started by the STM once VTAM has started by including an entry for the VTAM Manager in the STM tables.

If AF/OPERATOR is already running, you can activate the VTAM Manager before the next AF/OPERATOR recycle by issuing the following Application Manager commands from the MVS console:

APL INIT VTMVTM INIT ALL

Note: This assumes that the VTAM Manager tables have been pre-loaded into storage by the Table Manager. If the VTAM Manager tables have not been automatically loaded, issue the appropriate Table Manager commands, from the MVS console, to load the tables before you initialize the VTAM Manager.

Controlling VTAM Manager Resources



The VTM command provides an operator interface to give you additional control over the VTAM nodes defined to the VTAM Manager. It is used to communicate with AF/OPERATOR and the VTAM Manager service subroutines to control VTAM Manager objects and display VTAM Manager information about the objects from the MVS console.


VTM START NODE1

at any time, to activate the VTAM node associated with the VTAM object definition you named NODE1. The VTAM object name specified in the command is the same as the VTAM_OBJ field you coded in the VTAM Manager Control table.

An asterisk (*) is treated as a wild card character, which allows you to specify groups of like-named VTAM objects. For example, the command:

VTM DISPLAY C*

will display the VTAM Manager status for all objects with an object name that begins with the letter C.

VTAM Manager 235


VTM Command SyntaxThe following table shows the available VTM commands. To protect against unintentional command errors, certain function/node/ option combinations are prohibited. This includes:

� Functions INIT, START, STOP, CYCLE, or RECOVER and node ALL or * with the FORCE option.

FIGURE 8. VTM Command Syntax

Parameters

Function - Required

Node - Required

Option - Optional

VTM function node optionSTART ALL FORCESTOP * MAINTINIT MODE_NAME CHKPCYCLE PATTERNRECOVER CONSOLE=console_id

MONITORNOMONITOREXCEPT

HELPSHOWSTATUS

DISPLAY



Functions

The function parameter is used to tell the VTAM Manager which action to take against a VTAM node. Many, but not all, functions have abbreviations. Acceptable abbreviations are noted with the function's description.

START Activates the node associated with the specified VTAM object name. No abbreviations of the START keyword are acceptable.

STOP Inactivates the node associated with the specified VTAM object name. No abbreviations of the STOP keyword are acceptable.

INIT Initializes VTAM Manager control of a VTAM object. Activates the node associated with the specified VTAM object name. No abbreviations of the INIT keyword are acceptable.

CYCLE Cycles a resource. The VTM will stop the node and then start it again. No abbreviations of the CYCLE keyword are acceptable.

RECOVER Is an internal function used to invoke the VTM recovery process.

MONITOR Enables automatic recovery (monitoring) of a VTAM node that has previously been set to NOMONITOR status. Valid abbreviations are: MON and M.

The command:

VTM MONITOR node

will not turn on automatic recovery for a node that was originally defined to the VTM as having recovery OFF.

NOMONITOR Turns off automatic recovery of a node originally defined to the VTM as having recovery ON. Valid abbreviations are: NOMON and N.

EXCEPT EXCEPT is used to temporarily except a VTAM object from being managed on a system. This function will alter the in-storage copy of the VTAM Manager Control table to define the VTAM object with a KEYWORD of NONE. An excepted VTAM object will no longer be managed by the VTAM Manager. To re-enable VTAM Manager control of an excepted VTAM object, a 'VTM INIT object FORCE' command must be issued. Valid abbreviations are: EX and E.

VTAM Manager 237


Object Name

The VTAM object parameter is used to tell the VTAM Manager which VTAM object to manage. The aforementioned function will be performed for the VTAM objects specified with this parameter.

HELP Displays the VTAM Manager on-line help file on the operator console. No abbreviations of the HELP keyword are acceptable.

STATUS Issues a WTO to the MVS console that indicates the VTAM Manager status for the specified VTAM object. Valid abbreviations are: STAT and S.

A VTAM object can be in any one of the following states:� DEFINED The VTAM Manager knows about the

VTAM object, but does not know whether the VTAM object is active or inactive.

� ACTIVE The VTAM object is active.� INACTIVE The VTAM object is inactive.� UNKNOWN The VTAM object's status is unknown.

This is usually the case if the VTAM Manager has not fully initialized.

� BYPASSED - MANUAL MODE The VTAM object was not activated at VTAM Manager initialization since the system was IPL'ed in a manual mode.

� NOT DEFINED TO THIS SYSTEM The VTAM object is not defined to this system.

DISPLAY Issues a WTO to the MVS console that indicates the VTAM Manager status for the specified VTAM object. The default display is the same as the STATUS display as described above. Valid abbreviations are: DIS and D.

ALL The ALL keyword is used to specify all VTAM objects defined to the system. All VTAM objects known to the VTAM Manager will be interrogated, those that have been defined to this system via the VTAM Manager Control table will be chosen. A '*' is a synonym for the ALL keyword.



Standard Options

The standard options are used to alter the normal VTAM Manager processing of a function for a VTAM object.

NODE_NAME A VTAM object name precisely as coded in the VTAM Manager control table.

PATTERN A VTAM object name pattern, using a '*' as a wild card character. Any VTAM object that begins with the letters preceding the asterisk (*) and is defined to the system will be managed.

FORCE The FORCE option is used to force a VTAM object that is not defined to a system onto that system and to override the Vary Active and Vary Inactive control flags, VTAM_VA and VTAM_VI. Valid abbreviations are: F.

Note: If a VTAM object is forced onto a system via a VTM INIT or VTM START command, the VTAM Manager will update the in-storage copy of the VTAM Manager Control table and define the object to the system. Anytime after this, you need not use the FORCE option on the VTM command to manage the object.

This is a temporary change that will be in effect until the next time AF/OPERATOR is cycled. Once AF/OPERATOR is brought down, the definition of the object will revert to that specified in the VTAM Manager tables.

MAINT The MAINT option is used to manage only those VTAM objects that have been defined with a KEYWORD of AUTO. This is a special option used when IPL'ing a maintenance system. Valid abbreviations are: M.

CHKP The CHKP option is used to perform a checkpoint restart of the VTAM Manager. This is a special option used by the Application Manager when processing a checkpoint restart. There are no abbreviations for the CHKP option.

CONSOLE=console_id

The CONSOLE option is used to specify the console to receive VTAM Manager messages for a function. Specify either a valid console ID or the device address of the console for the console_id argument. There are no abbreviations for the CONSOLE option.

VTAM Manager 239


VTM Command On-line HelpOn-line help for the VTAM Manager VTM command is available anytime. To display on-line help for the VTM command, enter the following command at the MVS operator console:

VTM HELP

The VTAM Manager will then display the VTM command syntax followed by a brief explanation of each of the keywords associated with the command.



Device Manager 241

Device Manager

IntroductionThe Device Manager is used to automatically vary devices online and offline. The Device Manager can be used to manage the devices needed by Started Tasks or the system itself. The Device Manager can be used to:

� Vary a device online before a Started Task is started.

� Vary a device online or offline as an individual object.

The Device Manager allows you to define a default device address for an object or a system specific device address if the same object has a different address on each system. The Device Manager also allows you to specify different device addresses for the device object based on the CPU or LPAR on which the system is running.

The flexibility of the Device Manager object definitions allow you to manage many individual devices as a single entity. Any device that is used for a similar purpose, but uniquely addressed on each system can be represented by a single Device Manager object. Each device object can then be grouped with other similar device objects or managed by itself.

Chapter ContentsDevice Manager Components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242Using the Service Subroutines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250Controlling Device Manager Resources. . . . . . . . . . . . . . . . . . . . . . . . . . 251

6

Device Manager Components



The Device Manager has three components. They are:

� Automation application tables



Automation Application TablesTo manage the devices under its control, the Device Manager uses information stored in a table created by the user. The table that contains the device information is @DEVCNTL The Device Manager Control Table.

This table is a member of the Automation Application table dataset. The table is loaded into above-the-line storage at AF/OPERATOR and Automation Application initialization time. Anytime a Device Manager object is accessed, the appropriate information is retrieved from the table and used to determine how to manage the device.

To add or update an object definition in the Device Manager, execute the KAUUISPF exec from the hilev.RKAUEXEC dataset to activate the IRM ISPF User Interface. Object definition information is entered on the appropriate panels from within the IRM ISPF User Interface. Under no circumstances attempt to edit the IRM tables outside of the ISPF User Interface as this will cause unpredictable results possibly causing the IRM environment to become unusable.To implement the changes while AF/OPERATOR is running, use the Table Manager REFRESH command to refresh the in-storage copy of the Device Manager Control table. This gives the Device Manager access to the new data. You can then issue a DEV INIT command to initialize control of the new or updated device.

Device Manager 243


Service SubroutinesThe Device Manager service subroutines are AF/OPERATOR command files which perform the services needed to manage devices. The Device Manager service subroutines are comprised of the following execs:

@DEVINIT This exec initializes the Device Manager environment and creates an MVS console command, called DEV, that allows you to perform various management functions on a single device or group of devices.

@DEVMAIN This exec processes Device Manager commands issued to manage devices.

@DEVMAIN is responsible for: validating and processing command text, determining if the specified device is defined to the system, responding to operator inquiries, and varying devices online or offline.

@DEVHELP This exec provides the Device Manager on-line help facility.

@DEVCALL This exec is an external REXX function used by other Automation Applications to internally request Device Manager services.

@DEVPPRP This exec is called by the @DEVPPON external function and is used to return the status of a device on this system to the calling remote system.

@DEVEXIT This exec is called by the @DEVMAIN exec and is used to call a Device Manager user exit and returns the result of the exit to the caller.

@DEVPPON This exec is an external routine that is used as an interface to request and process an online function on a remote system.

@DEVVARY This exec is an external REXX function used by other Automation Applications to request a device be varied online or offline.



AF/OPERATOR System VariablesThe Device Manager creates the following AF/OPERATOR system variables to track device status over time:

Automation Tables

@DEVCNTL - Device Manager Control Table

The Device Manager Control table is used to store information on the device objects controlled by the Device Manager. When a device object is accessed, by operator command or internally, information is retrieved from this table and used to determine: if the device object is defined to the system, what the device address for the object is on the system and what options have been defined for the device object.

The Device Manager Control table uses three keys to identify each row in the table. The first key is the user assigned device object name. The second key is used to identify default deviceobject definitions or system specific definitions based on SMF ID. The third key is used to identify device object definitions based on CPU ID.

Device object names, system identifiers, and CPU identifiers need not be unique; what uniquely identifies the row is the combination of the three keys. For instance, the same object name can be used for many rows in the table, as long as, each row has a different SMF ID key to uniquely identify it.

@D####F Device Checkpoint Flags

@D####S Device Status

DEV_OBJ The name of the device object to manage. This field is the first table key. This is a 12 character alphanumeric field which defines the user assigned device object name. Any alphanumeric character may be used for the name with the exception of an asterisk (*) or double quotes ("). Object names need not be unique; an object name may be repeated if the DEV_SYS or DEV_CPU keys are used to uniquely identify the row.

Device Manager 245


DEV_SYS This field is used to identify the scope of the device object definition. Code the DEFAULT keyword to enable the definition on all systems. Code an SMF ID to enable the object definition only on a specific system. This field is the second table key.

Note: Each device object must have a DEFAULT definition. If there is no valid device information for the DEFAULT definition, code an asterisk (*) in the DEV_ADD field.

DEV_CPU This field is used to identify the scope of the device object definition based on CPU ID. Code an asterisk (*) in this field if the definition is not dependent on CPU ID. Code a CPU ID to enable the object definition only on a specific system, running on a specific CPU. This field is the third table key.

This field is used in combination with the DEV_SYS field; an SMF ID must be coded in the DEV_SYS field before the DEV_CPU key will be recognized.

Note: A CPU ID can be coded as either the full six character CPU ID or just the right-most five characters for those device object definitions that are not LPAR dependent. For five character CPU IDs, the first character of the system CPUID, the LPAR identifier, will be ignored by the Device Manager.

DEV_# Specifies a unique number for the device object starting from 1001. This is a four character numeric field used by the Device Manager in creating AF/OPERATOR variables and traps associated with the device object.

The device object numbers need not be consecutive and are not used in any ordering scheme, but each device object, a unique definition in the DEV_OBJ field, must have a unique number assigned to it.



DEV_KEY The DEV_KEY field is used as a generalized grouping mechanism to identify those device objects that are defined to all systems, no systems, or manipulated internally by other Automation Applications. Valid values are:� ALL Specifies that the device object is defined to

all systems. The Device Manager will activate the device object on every system.

� AUTO Specifies that the device object is defined to all systems. Under most circumstances, the AUTO keyword is identical to the ALL keyword, except in the case of bringing up a maintenance system running in manual application processing mode. When running in manual mode to bring up a maintenance system, only those device objects identified as AUTO will be managed. When running in automated mode, the Device Manager will activate the device object on every system.

� NONE Specifies that the device object is not defined to any system. The Device Manager will not initialize this device object on any system.

� MANUAL Specifies that the device object is not to be automatically activated during Device Manager initialization. During initialization, or anytime a DEV INIT ALL or DEV START ALL command is processed, the Device Manager will bypass this device object. A device object with a KEYWORD of MANUAL will be managed only if a DEV INIT command for the device object itself is manually entered at the operator console.

� INTERNALSpecifies that the device object will be initialized internally by another of the Automation Applications; the device object will not be automatically activated by the Device Manager. A device object defined as INTERNAL can only be accessed by the controlling application.

Device Manager 247


DEV_KEYcont.

Note: The device object can be initialized via manual intervention by specifying the Force option on a DEV INIT command. This keyword is used to identify those device objects that should not be activated automatically, but rather, are enabled on-demand by manual intervention.

Note: Device objects defined with a KEYWORD of INTERNAL are hidden from normal Device Manager operations. INTERNAL device objects can not be accessed directly by Device Manager commands, unless the Force option of the DEV command is used. This includes all Device Manager displays for the device object.

DEV_ADD This field is used to identify the device address, or address range, for the object definition. This is an 8 character alphanumeric field. Code an asterisk (*) in this field if there is no device address associated with this definition.

DEV_ADD can be either a single device address, specified as 1D0, or a range of addresses, specified as 1D0-1DF. If a device object has different device addresses on different systems include a separate row for each system identifying the same device object name in the DEV_OBJ field. Then differentiate the object definitions by coding the appropriate SMF ID for each row in the DEV_SYS field and the device address for the object on that system in this field.

DEV_INT This field is used to specify the verification interval for device vary commands. When a command is issued to vary a device online or offline, the Device Manager will wait for the time limit specified by this field for verification that the command was successful. Code the verification interval in the form: HH:MM:SS. The default is one minute, 00:01:00.

DEV_VO This is a binary field (0,1). Specify 1 to allow the Device Manager to vary the device online. Specify 0 to limit the Device Manager to only varying the device offline. The default is 1.

DEV_VF This is a binary field (0,1). Specify 1 to allow the Device Manager to vary the device offline. Specify 0 to limit the Device Manager to only varying the device online. The default is 0.



DEV_ISTAT This is a binary field. Specify 1 to vary the device online during initialization. Specify 0 to vary the device offline during initialization. The default is 1.

DEV_CACHE This is a binary field. Specify 1 to enable cache for the device. Specify 0 to indicate that cache should not be enabled for the device. The default is 0.

DEV_FASTWR This is a binary field. Specify 1 to enable DASD Fast Write for the device. Specify 0 to indicate that DASD Fast Write should not be enabled for the device. The default is 0.

DEV_JESDEV This is a binary field. Specify 1 to indicate this is a JES device. Specify 0 to indicate this is an MVS device only. The default is 0.

Note: If this is a JES device, the Vary Online field must be enabled for the device to be varied on to JES.

DEV_JESGLB This is a binary field. Specify 1 to indicate the device is to be varied on to the JES Global. Specify 0 to indicate the device should not be varied on to the JES Global. The default is 0.

DEV_JESALL This is a binary field. Specify 1 to indicate that the device is to be varied online to all Local Mains. If the device should not be varied online to any Local or should be varied online to only a subset of the Locals, specify 0 in this field. The default is 0.

Note: If you have coded a 1 in this field, do not code any Local Main ID(s) in the JES Main Names fields.

DEV_JLCL.0 This field is an array key which signifies the number of defined JES3 Local Main ID's where the device is managed.

DEV_JLCL.n The JES Main Names 1 through 6 fields allow the user to specifically define up to 6 unique JES Local Main IDs where the device is to be managed.

DEV_XSB This field identifies the command file name of the pre-start exit for the device. An AF/OPERATOR system or global variable, which equates to the exit command file name, can be coded in this field by prefacing the variable name with an ampersand (&): &AOVARNAM. If the device has no pre-start exit, leave this field blank.

Device Manager 249


DEV_XSA This field identifies the command file name of the post-start exit for the device. An AF/OPERATOR system or global variable, which equates to the exit command file name, can be coded in this field by prefacing the variable name with an ampersand (&): &AOVARNAM. If the device has no post-start exit, leave this field blank.

DEV_XPB This field identifies the command file name of the pre-stop exit for the device. An AF/OPERATOR system or global variable, which equates to the exit command file name, can be coded in this field by prefacing the variable name with an ampersand (&): &AOVARNAM. If the device has no pre-stop exit, leave this field blank.

DEV_XPA This field identifies the command file name of the post-stop exit for the device. An AF/OPERATOR system or global variable, which equates to the exit command file name, can be coded in this field by prefacing the variable name with an ampersand (&): &AOVARNAM. If the device has no post-stop exit, leave this field blank.

DEV_XRB This field identifies the command file name of the pre-recovery exit for the device. An AF/OPERATOR system or global variable, which equates to the exit command file name, can be coded in this field by prefacing the variable name with an ampersand (&): &AOVARNAM. If the device has no pre-recovery exit, leave this field blank.

DEV_XRA This field identifies the command file name of the post-recovery exit for the device. An AF/OPERATOR system or global variable, which equates to the exit command file name, can be coded in this field by prefacing the variable name with an ampersand (&): &AOVARNAM. If the device has no post-recovery exit, leave this field blank.

DEV_REC This is a binary field. Specify 1 to enable recovery processing for the device. Specify 0 if recovery is not required for the device. The default is 0.

DEV_DESC A one line description of the object. The object's description field is used to provide a 'Plain English' description of the object for user reference. Up to 20 characters of free form text is allowed.




OverviewOnce the automation table component of the Device Manager has been defined, the information needed to manage devices for an environment is available to the Device Manager service subroutines. To initiate the actual management of devices, the Device Manager service subroutines must be activated.

Starting the Service SubroutinesThe Device Manager is automatically initialized at AF/OPERATOR initialization time by the Application Manager which executes the @DEVINIT exec. This command file initializes the Device Manager environment and creates the DEV console command.

If AF/OPERATOR is already running, you can activate the Device Manager before the next AF/OPERATOR recycle by issuing the following Application Manager commands from the MVS console:

APL INIT DEVDEV INIT ALL

Note: This assumes that the Device Manager tables have been pre-loaded into storage by the Table Manager. If the Device Manager tables have not been automatically loaded, issue the appropriate Table Manager commands, from the MVS console, to load the tables before you initialize the Device Manager.

Device Manager 251

Controlling Device Manager Resources


The DEV command provides an operator interface to give you additional control over the device objects defined to the Device Manager. It is used to communicate with AF/OPERATOR and the Device Manager service subroutines to control Device Manager objects and display Device Manager information about the objects from the MVS console.


DEV START DEVICE1

at any time, to vary online the device associated with the device object definition you named DEVICE1. The device object name specified in the command is the same as the DEV_OBJ field you coded in the Device Manager Control table.

An asterisk (*) is treated as a wild card character, which allows you to specify groups of like-named device objects. For example, the command:

DEV DISPLAY C*

will display the Device Manager status for all objects with an object name beginning with the letter C.



DEV Command SyntaxThe following table shows the available DEV commands. To protect against unintentional command errors, certain function/object/ option combinations are prohibited. This includes:

� Functions INIT, START, STOP, CYCLE, and RECOVER with object ALL or * with the FORCE option.

FIGURE 9. DEV Command Syntax

Parameters

Function - Required

Object - Required

Option - Optional

DEV function object optionINIT ALL FORCESTART * MAINTSTOP DEV_NAME CHKPCYCLE DEV_ADDR NOCHKPRECOVER DEV_#

PATTERN CONSOLE=console_id

MONITOR NOPRESTARTNOMONITOR NOPOSTSTARTEXCEPT NOPRESTOPNOOP NOPOSTSTOP

HELP UNCONDSHOW DEVPARM= SHR

FORCE

DISPLAY

Device Manager 253


Functions

The function parameter is used to tell the Device Manager which action to take against a device. Many, but not all, functions have abbreviations. Acceptable abbreviations are noted with the function's description.

START Varies online the device associated with the specified device object name. No abbreviations of the START keyword are acceptable.

STOP Varies offline the device associated with the specified device object name. No abbreviations of the STOP keyword are acceptable.

INIT Initializes Device Manager control of a device object. Varies online the device associated with the specified device object name. No abbreviations of the INIT keyword are acceptable.

CYCLE Cycles a resource. The DEV will vary the device offline and then vary it online again. No abbreviations of the CYCLE keyword are acceptable.

RECOVER Is an internal function used to invoke the DEV recovery process.

MONITOR Enables automatic recover (monitoring) of a device that has previously been set to NOMONITOR status. Valid abbreviations are: MON and M.

DEV MONITOR device

will not turn on automatic recovery for a node that was originally defined to the DEV as having recovery OFF.

NOMONITOR Turns off automatic recovery of a node originally defined to the DEV as having recovery ON. Valid abbreviations are: NOMON and N.

NOOP Perform no operation, NoOp. Used to restore check-pointed control information, such as a FORCE or EXCEPT, for a device.



EXCEPT EXCEPT is used to temporarily except a device object from being managed on a system. This function will alter the in-storage copy of the Device Manager Control table to define the device object with a KEYWORD of NONE. An excepted device object will no longer be managed by the Device Manager. To re-enable Device Manager control of an excepted device object, a 'DEV INIT object FORCE' command must be issued. Valid abbreviations are: EX and E.

HELP Displays the Device Manager on-line help file on the operator console. No abbreviations of the HELP keyword are acceptable.

STATUS Issues a WTO to the MVS console that indicates the Device Manager status for the specified device object. Valid abbreviations are: STAT and S.

A device object can be in any one of the following states:� DEFINED The Device Manager knows about the

device object, but does not know whether the device object is online or offline.

� ONLINE The device object is online.� OFFLINE The device object is offline.� UNKNOWN The device object's status is unknown.

This is usually the case if the Device Manager has not fully initialized.

� BYPASSED - MANUAL MODE The device object was not activated at Device Manager initialization since the system was IPL'ed in a manual mode.

� NOT DEFINED TO THIS SYSTEM The device object is not defined to this system.

DISPLAY Issues a WTO to the MVS console that indicates the Device Manager status for the specified device object. The default display is the same as the STATUS display as described above. Valid abbreviations are: DIS and D.

Device Manager 255


Object Name

The device object parameter is used to tell the Device Manager which device object to manage. The afore mentioned function will be performed for the device objects specified with this parameter.

Standard Options

The standard options are used to alter the normal Device Manager processing of a function for a device object.

ALL The ALL keyword is used to specify all device objects defined to the system. All device objects known to the Device Manager will be interrogated, those that have been defined to this system via the Device Manager Control table will be chosen. A '*' is a synonym for the ALL keyword.

DEV_NAME A device object name precisely as coded in the Device Manager control table.

PATTERN A device object name pattern, using a '*' as a wild card character. Any device object that begins with the letters preceding the asterisk (*) and is defined to the system will be managed.

FORCE The FORCE option is used to force a device object that is not defined to a system onto that system. Valid abbreviations are: F.

Note: If a device object is forced onto a system via a DEV INIT or DEV START command, the Device Manager will update the in-storage copy of the Device Manager Control table and define the object to the system. Anytime after this, you need not use the FORCE option on the DEV command to manage the object.

This is a temporary change that will be in effect until the next time AF/OPERATOR is cycled. Once AF/OPERATOR is brought down, the definition of the object will revert to that specified in the Device Manager tables.

MAINT The MAINT option is used to manage only those device objects that have been defined with a KEYWORD of AUTO. This is a special option used when IPL'ing a maintenance system. Valid abbreviations are: M.



DEV Command On-line HelpOn-line help for the Device Manager DEV command is available anytime. To display on-line help for the DEV command, enter the following command at the MVS operator console:

DEV HELP

The Device Manager will then display the DEV command syntax followed by a brief explanation of each of the keywords associated with the command.

CHKP The CHKP option is used to perform a checkpoint restart of the Device Manager. This is a special option used by the Application Manager when processing a checkpoint restart. There are no abbreviations for the CHKP option.

NOCHKP Bypasses check-pointing of dynamic changes such as defining a task to the system or updating a resource schedule.

NOPRESTART The NOPRESTART option is used to bypass the pre-start exit for a resource. This option is applicable to only those resources that have a pre-start exit enabled. There are no abbreviations for the NOPRESTART option.

NOPOSTSTART The NOPOSTSTART option is used to bypass the post-start exit for a resource. This option is applicable to only those resources that have a post-start exit enabled. There are no abbreviations for the NOPOSTSTART option.

NOPRESTOP The NOPRESTOP option is used to bypass the pre-stop exit for a resource. This option is applicable to only those resources that have a pre-stop exit enabled. There are no abbreviations for the NOPRESTOP option.

NOPOSTSTOP The NOPOSTSTOP option is used to bypass the post-stop exit for a resource. This option is applicable to only those resources that have a post-stop exit enabled. There are no abbreviations for the NOPOSTSTOP option.

CONSOLE=console_id

The CONSOLE option is used to specify the console to receive Device Manager messages for a function. Specify either a valid console ID or the device address of the console for the console_id argument. There are no abbreviations for the CONSOLE option.

Console Manager 257

Console Manager

IntroductionThe Console Manager is used to automate the activation ahd management of system consoles. The Console Manager can be used to activate and inactivate the consoles needed at any given time.

Chapter ContentsConsole Manager Components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258Console Manager Console Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . 260Using the Service Subroutines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267Controlling Console Manager Resources. . . . . . . . . . . . . . . . . . . . . . . . . 268

7

Console Manager Components



The Console Manager has three components. They are:

� Console definition



Console DefinitionConsole Manager tables hold information used to manage consoles. All of the tables are members of the Automation Application table dataset. The tables are created by user completing the table fields with the appropriate information. The section, Console Manager Console Definition beginning on page 260, describes the Console Manager automation tables in detail.

Service SubroutinesThe console manager service subroutines are AF/OPERATOR command files which perform the services needed to manage the systems consoles. The Console Manager service subroutines are comprised of the following execs:

@CNSINIT This exec initializes the Console Manager environment and creates an MVS console command, called CNS, that allows you to perform various management functions on a single console or a group of consoles.

@CNSMAIN This exec processes Console Manager commands issued to manage Consoles. @CNSMAIN is responsible for: validating and processing command text, responding to operator inquiries, and activating or inactivating consoles.

@CNSHELP This exec provides the Console Manager on-line help facility.

@CNSCALL This exec is an external REXX function used by other Automation Applications to internally request Console Manager services.

@CNSBUFS This exec is automatically invoked via Message Manager Traps for the IEA404A and/or IEA405E console buffer shortage warning messages. It clears console message queues by cycling consoles with pending output or issuing a K Q command.

Console Manager 259


AF/OPERATOR System VariablesThe Console Manager creates the following AF/OPERATOR system variables to tract Console statuses over time.

@K####F Console Checkpoint Flags

@K####S Console Status

Console Manager Console Definition



OverviewTo manage the consoles , the Console Manager uses information stored in two tables that are dynamically created by the user. The tables are:

These tables are loaded into above-the-line storage at AF/OPERATOR and Automation Application initialization time. Each table is a member of the Automation Application table dataset. The table is loaded into above-the-line storage at AF/OPERATOR and Automation Application initialization time. Anytime a Console Manager console is accessed, the appropriate information is retrieved from the table and is used to determine how to manage the Console.

Adding or Updating ConsolesTo add or update an object definition in the Console Manager, execute the KAUUISPF exec from the hilev.RKAUEXEC dataset to activate the IRM ISPF User Interface. Object definition information is entered on the appropriate panels from within the IRM ISPF User Interface. Under no circumstances attempt to edit the IRM tables outside of the ISPF User Interface as this will cause unpredictable results possibly causing the IRM environment to become unusable.To implement the changes while AF/OPERATOR is running, use the Table Manager REFRESH command to refresh the in-storage copy of the Console Manager tables. This gives the Console Manager access to the new data.

You can then issue a CNS INIT command to initialize control of the new or updated console.

@CNSCNTL Console Manager Control Table

@CNSDESC Console Manager Descriptor Table

Console Manager 261


Console Manager Consolve Definition

Control Data

Object Name The name of the console to manage. This is a twelve character alphanumeric field which defines the user assigned console name. Any alphanumeric character may be used for the name with the exception of an asterisk (*) or double quotes. Console names need not be unique; a console name may be repeated if the System or CPUID keys are used to uniquely identify the row. This is a required field.

System The system field is used to identify the scope of the console definition. Code the DEFAULT keyword to enable the definition on all systems. Code an SMFID to enable the console definition only on a specific system. Each console must have a DEFAULT definition. A DEFAULT definition will automatically be added if one does not exist. If coding a DEFAULT definition that will not be used to manage the console, code an asterisk (*) in the console address field. This is a required field.

CPU This field is used to identify the scope of the console definition based on CPU ID. Code an asterisk (*) in this field if the definition is not dependent on CPUID. Code a CPUID to enable the console definition only on a specific system, running on a specific CPU. The field is used in combination with the System field; an SMF ID must be coded in the System field before the CPUID key will be recognized. A CPU ID can be coded as either the full six character CPUID or just the right-most five characters for the console definitions that are not LPAR dependent. This is a required field.



Keyword The Keyword field is used as a generalized grouping mechanism to identify those consoles that are defined to all systems, no systems, or manipulated internally by other Automation Applications. Valid values are:� ALL Specifies that the console is defined to all

systems. The Console Manager will initialize this console on every system.

� AUTO Specifies that the console is defined to all systems. Under most circumstances, the AUTO keyword is identical to the ALL keyword, except in the case of bringing up a maintenance system running in manual application processing mode. When running in manual mode, only those consoles identified as AUTO will be managed. When running in automated mode, the Console Manager will initialize the console on every system.

� NONE Specifies that the console is not defined to any system. The Console Manager will not initialize this console on any system.

Note: The console can be initialized via manual intervention by specifying the Force option on a CNS INIT command. This keyword is used to identify those consoles that should not be started automatically, but rather, are started on demand through manual intervention.

� MANUAL Specifies that the console is not to automatically start during Console Manager initialization. During initialization, or anytime a CNS INIT ALL or CNS START ALL command is processed, the Console Manager command is processed, the Console Manager will bypass this console. A console with a Keyword of MANUAL will be managed only if a CNS INIT command for the console itself is manually entered.

Console Manager 263


Keywordcont.

� INTERNALSpecifies that the console will be initialized internally by another of the Automation Applications; the console will not automatically start during Console Manager initialization. A console defined as INTERNAL can only be accessed by the controlling application. INTERNAL can only be accessed by the controlling application.

Note: Consoles defined with a Keyword of INTERNAL are hidden from normal Console Manager operations. INTERNAL consoles can not be accessed directly by Console Manager commands, unless the Force option of the CNS command is used. This includes all Console Manager displays for the console. This is a required field.

Console ID Specify the Console Identification number as assigned by MVS based on the order of the statements in the CONSOLxx member of SYS1.PARMLIB.

Interval This field is used to specify the verification interval for vary console commands. When a command is issued to vary a console active or online, the Console Manager will wait for the time limit specified by this field for verification that the command was successful. Code the verification interval in military time format. The default is 30 seconds, 00:00:30.

Initial Status This is a binary field. Specify '1' to indicate the initial status of the console is online. Specify '0' to indicate the initial status is offline. The default is 1.

Vary Console This is a binary field. Specify '1' to vary the device as a console. Specify '0' to limit the Console Manager to only inactivating the device. The default is 1.

Vary Online This is a binary field. Specify '1' to vary the console online. Specify '0' to limit the Console Manager to only activating the console. The default is 1.

CP Reset This is a binary field. Specify '1' to issue a VM CP Reset command for the device. Specify '0' to disallow the reset of the device. This field is valid only for devices connected to a VM Guest machine. The default is 0.



Console Manager Description Definition

Console Data

AF/REMOTE Console

Specify '1' if the console will be used as an interface for AF/Remote. Specify '0' if the console will not be used to interface with AF/Remote. The default is 0.

Console Address Specify the device address as defined to MVS. This is a 6 character alphanumeric field. If coding a definition that will not be used to manage the console, code an asterisk (*) in this field.

Console Type The Console Type field contains the name of the Console Description to associate with this console.

NOTE: The Console Type must be defined to the Console Description Table, via the Console Descriptions option, before associating it with a console definition.

Description A one line description of the console. The console's description field is used to provide a 'Plain English' description of the console for user reference. Up to 16 characters of free form text is allowed.

Console Type The name of the console type. This is a twelve character alphanumeric field. Any name you choose may be used for the console type. Console Type names must be unique and may not include imbedded double quotes (") or asterisks (*). For selections Add or Copy, console type is required. For selection Update, console type cannot be changed.

Description A one line description of the type. Tye type description field is used to provide a ‘Plain English’ description of the type for user reference. The contents of this field are displayed on the main Console Manager Descriptions selection panel. Up to 40 characters of free form test is allowed.

Monitor Job Names

Monitor Job Names specifies that the job name will be displayed when the job starts and ends. Code a '1' to monitor the job name. Coding a '0' specifies the job name will not be monitored. The default is 1.

Console Manager 265


Message Delete Mode

Specifies the Message Delete Mode of the console. Specify Y to delete all messages selected for deletion when the screen becomes full. Specify R for roll mode. Specify RD for roll mode except for action messages. Specifying N indicates that no automatic message deletion is in effect. The default is RD.

Segment Number

Segment number specifies the number of lines in the message area that can be deleted when the CONTROL E,SEG command is entered. Specify a decimal value from 1 to the number of lines in the message area. The default is 19.

Conversational Mode

Specifies whether the console is to function in conversational or nonconversational mode. Specify Y for conversational mode; on this console you must verify all messages selected for message deletion with the cursor or through the CONTROL command. Specify N for nonconversational mode; all messages selected for deletion are automatically deleted. If the device is a printer, code an asterisk in this field. The default is N.

Roll Number Roll number specifies a maximum number of lines included in one message roll. Specify a decimal value from 1 to the number of lines in the message area. The default is 19.

Area Area specifies the size of the out-of-line display area on the display console. The minimum number of lines in an area is 4. The maximum number of lines in an area cannot exceed the Roll Number size.

Roll Time Roll Time specifies the number of seconds between message rolls. Specify a decimal value from 1 to 999. If the device is a printer, code an asterisk in this field. The default is 1.

Message Format Message Format specifies the display format of the messages. Specify M to display only the text of each message. Specify J to include the job ID or name. Specify S to include the name of the originating system. Specify T to include a time stamp.

Use Specifies the operating mode of the console. Specify FC for full-capability. If the console is a display device, specify USE(FC). Specify MS for message stream mode. If the console is a printer, specify USE(MS). Specify SD if the console is to be in status display mode only. If the device is a printer, code an asterisk in this field.



Message Levels Specify the message levels for the console. The types of messages a console can receive:� All All messages � NB No broadcast messages � R WTOR messages � I Immediate action messages � CE Critical eventual action messages � E Eventual action messages � IN Informational messages

Message Route Codes

Specifies the routing codes assigned to the console. ALL specifies all routing codes, 1 to 128. nnn-nnn specifies a range of decimal values with the lower value first. NONE is the default. For a master console, NONE indicates routing codes 1 and 2. For all other consoles, NONE indicates no routing codes.

Console Manager 267



OverviewOnce the automation table components of the Console Manager have been defined, the information needed to manage Consoles for an environment is available to the Console Manager service subroutines. To initiate the actual management of Consoles, the Console Manager service subroutines must be activated.

APL INIT CNSCNS INIT ALL

Note: This assumes that the Console Manager tables have been pre-loaded into storage by the Table Manager. If the Console Manager tables have not been automatically loaded, issue the appropriate Table Manager commands, from the MVS console, to load the tables before you initialize the VTAM Manager.

Starting the Service SubroutinesThe Console Manager is automatically initialized at AF/OPERATOR initialization time by the Application Manager which executes the @CNSINIT exec. This command file initializes the Console Manager environment and creates the CNS console command.

If AF/OPERATOR is already running, you can activate the Console Manager before the next AF/OPERATOR recycle by issuing the following Application Manager commands from the MVS console:

TBL LOAD CNS; APL INIT CNS

Controlling Console Manager Resources



The CNS command provides an operator interface to give you additional control over the consoles defined to the Console Manager. It is used to communicate with AF/OPERATOR and the Console Manager service subroutines to control Console Manager objects and display Console Manager information about the objects from the MVS console.


CNS START TAPELIB

at any time, to activate the console in the Tape Library associated with the Console object definition you named TAPELIB. The Console object name specified in the command is the same as the CNS_OBJ field you coded in the Console Manager Control tables. An asterisk (*) is treated as a wild card character, which allows you to specify groups of like-named console objects.

For example, the command:

CNS DISPLAY C*

will display the Console Manager status for all objects with an object name that begins with the letter C.

Console Manager 269


CNS Command SyntaxThe following table shows the available CNS commands. To protect against unintentional command errors, certain function/console/option combinations are prohibited. This includes:

� Functions INIT, START, STOP, and CYCLE and console ALL or * with the FORCE option.

FIGURE 10. CNS Command Syntax

Parameters

Function - Required

Console - Required

Option - Required

CNS function console option

START ALL FORCESTOP * MAINTINIT CNS_NAME CHKPCYCLE CNS_ADDR

CNS_ID CONSOLE=console_idEXCEPT PATTERN

DISPLAYSTATUS



Functions

The function parameter is used to tell the Console Manager which action to take against a console. Many, but not all, functions have abbreviations. Acceptable abbreviations are noted with the function's description.

START Activates the console associated with the specified Console object name. No abbreviations of the START keyword are acceptable.

STOP Inactivates the console associated with the specified Console object name. No abbreviations of the STOP keyword are acceptable.

INIT Initializes Console Manager control of a Console object. Activates the console associated with the specified console object name. No abbreviations of the INIT keyword are acceptable.

CYCLE Cycles a resource. The CNS will stop the console and then start it again. No abbreviations of the CYCLE keyword are acceptable.

EXCEPT EXCEPT is used to temporarily except a console object from being managed on a system. This function will alter the in-storage copy of the Console Manager Control table to define the console object with a KEYWORD of NONE. An excepted console object will no longer be managed by the Console Manager. To re-enable Console Manager control of an excepted console object, a 'CNS INIT object FORCE' command must be issued. Valid abbreviations are: EX and E.

DISPLAY Issues a WTO to the MVS console that indicates the console Manager status for the specified console object. The default display is the same as the STATUS display as described below. Valid abbreviations are: DIS and D.

Console Manager 271


Object Name

The Console object parameter is used to tell the Console Manager which console object to manage. The aforementioned function will be performed for the console objects specified with this parameter.

STATUS Issues a WTO to the MVS console that indicates the Console Manager status for the specified console object. Valid abbreviations are: STAT and S.

A console object can be in any one of the following states:� DEFINED The console Manager knows about the

console object, but does not know whether the console object is active or inactive.

� ACTIVE The console object is active.� INACTIVE The console object is inactive.� UNKNOWN The console object's status is unknown.

This is usually the case if the Console Manager has not fully initialized.

� BYPASSED - MANUAL MODE The console object was not activated at Console Manager initialization since the system was IPL'ed in a manual mode.

� NOT DEFINED TO THIS SYSTEM The console object is not defined to this system.

ALL The ALL keyword is used to specify all console objects defined to the system. All console objects known to the Console Manager will be interrogated, those that have been defined to this system via the Console Manager Control table will be chosen. A '*' is a synonym for the ALL keyword.

CNS_NAME A console object name precisely as coded in the Console Manager control table.

CNS_ADDR A console object address precisely as coded in the Console Manager control table.

CNS_ID A console object id precisely as coded in the Console Manager control table.



Standard Options

The standard options are used to alter the normal Console Manager processing of a function for a console object.

PATTERN A console object name pattern, using a '*' as a wild card character. Any console object that begins with the letters preceding the asterisk (*) and is defined to the system will be managed.

FORCE The FORCE option is used to force a console object that is not defined to a system onto that system and to override the Vary Active and Vary Inactive control flags, CNS_VA and CNS_VI. Valid abbreviations are: F.

Note: If a Console object is forced onto a system via a CNS INIT or CNS START command, the Console Manager will update the in-storage copy of the Console Manager Control table and define the object to the system. Anytime after this, you need not use the FORCE option on the CNS command to manage the object.

This is a temporary change that will be in effect until the next time AF/OPERATOR is cycled. Once AF/OPERATOR is brought down, the definition of the object will revert to that specified in the Console Manager tables.

MAINT The MAINT option is used to manage only those console objects that have been defined with a KEYWORD of AUTO. This is a special option used when IPL'ing a maintenance system. Valid abbreviations are: M.

CHKP The CHKP option is used to perform a checkpoint restart of the Console Manager. This is a special option used by the Application Manager when processing a checkpoint restart. There are no abbreviations for the CHKP option.

CONSOLE=console_id

The CONSOLE option is used to specify the console to receive Console Manager messages for a function. Specify either a valid console ID or the device address of the console for the console_id argument. There are no abbreviations for the CONSOLE option.

Console Manager 273


CNS Command On-line HelpOn-line help for the Console Manager CNS command is available anytime. To display on-line help for the CNS command, enter the following command at the MVS operator console:

CNS HELP

The Console Manager will then display the CNS command syntax followed by a brief explanation of each of the keywords associated with the command.



Customer Support 275

Customer Support

IntroductionCandle Corporation offers a comprehensive maintenance and support plan to ensure you realize the greatest value possible from your Candle software investments. We have more than 200 technicians worldwide, committed to providing you with prompt resolutions to your support requests.

Customer Support hours of operation are from 5:30 A.M. – 5:00 P.M., Pacific Time. In the event of an after-hours or weekend emergency, Candle's computerized call management system ensures that a technician will return your call within one hour. For customers located outside of North America, after-hours and weekend support is provided by Candle Customer Support locations in the United States.

Electronic supportCandle provides information and support services through

n Candle's home page at www.candle.com. You can use the Candle Worldwide Web Site to– open problem records– access maintenance information – order products or maintenance– access IBM compatibility information– download fix packs for distributed products– read news and alerts– scan a list of scheduled Candle education classes

A


n Candle Electronic Customer Support (CECS), an electronic customer support facility. You can access this facility using the IBM Global Network. You can use CECS to:

– open problem records– search our database for solutions to known problems– look for answers to commonly asked questions– read news and alerts– scan a list of scheduled Candle education classes

Both CECS and the Candle Worldwide Web Site are available 24 hours a day, 7 days per week.

Telephone supportOur support network consists of product specialists who work with you to solve your problem.

Candle uses an on-line problem management system to log and track all support requests. Your support request is immediately routed to the appropriate technical resource.

When you call to report a problem, please have the following information:

n your Candle personal ID (PID) numbern the release level of the Candle product n the release level of IBM or other vendor software n identifying information and dates of recently applied maintenance to your

Candle product or IBM productn a detailed description of the problem (including the error message) and

the events preceding the problemn a description of any unusual events that occurred before the problem

Customer support locations and numbersTo contact a Customer Support representative, refer to the following list. While these phone numbers were accurate at the time this document was published, the current numbers can be found on the Candle Web site, www.candle.com, under Customer Support.

http://www.candle.com

Customer Support 277

Table 1. Customer Support Phone Numbers

Office Telephone FAX

North America (800) 328-1811 (310) 535-3636

(310) 727-4204

Europe

Belgium/Luxembourg +32 (0) 3 270 95 60 +32 (0) 3 270 95 41

France +33 (0) 1 53 61 60 60 +33 (0) 1 53 61 06 16

Germany/Switzerland/Austria

+49 (0) 89 54 554 333 +49 (0) 89 54 554 170

Italy – Freephone 800 780992

Netherlands +31 (0) 30 600 35 50 +31 (0) 30 600 35 10

Scandinavia +46 (0)8 444 5940 +46 (0)8 623 1855

United Kingdom +44 (0)161 437 5224 +44 (0)161 437 5225

(Southern Europe, Middle East and South Africa Agents call United Kingdom)

Asia Pacific – English Hub +61 2 9954 1818

Australia +61 2 8912 9898

Hong Kong 800 908 457

India +61 2 8912 9898

Indonesia 0018 03061 2061

Malaysia 1800 803 459

New Zealand 0800 449 596

Philippines 1800 1612 0096

Singapore 800 616 2075

Thailand 0018 00612 1045

Asia Pacific – Japanese Hub +81 3 3595 7150 +81 3 3595 7110

Asia Pacific – Korean Hub +82 2 552 8744 +82 2 552 8746

Asia Pacific – Mandarin Hub +88 62 2739 3223 +88 62 2378 5993

Asia Pacific – e-mail address: [email protected]


When your local support office is unavailable, you can contact Candle's North America support center. If USADirect® service is available in your country, use the 800 telephone number. If USADirect® service is not available, ask your international operator for assistance in calling Candle's local (310) number.

Incident documentationYou may be asked to send incident documentation to the Candle Customer Support Center. On the outside of all packages you send, please write the incident number given to you by the Customer Support representative.

Send tapes containing the incident information to the following address, unless directed otherwise by your Customer Support representative:

Candle Customer SupportCandle Support Center, Incident number201 North Douglas StreetEl Segundo, California 90245

Send all other relevant documentation, such as diskettes or paper documentation, to the address provided by your Customer Support representative.

Ensuring your satisfaction with customer supportCandle Customer Support is committed to achieving high customer satisfaction ratings in all areas. These include

n connecting you to a support representative promptlyn providing you with the appropriate fixesn answering support questionsn filling your shipping ordersn supplying documentation

If you have a concern that has not been resolved to your satisfaction, you can open a complaint ticket. All tickets are logged and tracked to ensure responsiveness and closure. Using the ticket information, a manager will contact you promptly to resolve your problem.

279

Symbols@DEVCNTL Control Table 240

AAbout this Document 11Adobe Portable Document Format 12

CCandle Electronic Customer Support

(CECS) 272Candle home page 271Candle Internet site 271Candle Worldwide Web site 271CCF

AF/OPERATOR System Variables 178Command Data 180Command Definition 177, 179Command Name 195Command Syntax 193Components 177Functions 194Parameters 193Service Subroutines 178Standard Options 197Triggering Conditions 186

CNSAF/OPERATOR System Variables 255Command Syntax 265Components 254Console Definition 254Control Data 257Controlling Resources 264Functions 266Parameters 265Service Subroutines 254

Command Manager 175AF/OPERATOR System Variables 178Command Data 180Command Definition 177, 179Command Name 195Command Syntax 193Components 177Functions 194Parameters 193Service Subroutines 178Standard Options 197Triggering Conditions 186

Command Manager - Add a Command 180Command Manager Command Definition

Panel 181Command Syntax

CNS 265DEV 248DEV Command 248MCF 169RCF 107SCF 213VTM 231

Console Manager 253AF/OPERATOR System Variables 255Command Syntax 265Components 254Console Definition 254Control Data 257Controlling Resources 264Functions 266Parameters 265Service Subroutines 254, 263

customer supportelectronic support 271Internet 271

Index

Index

280 IRM Control Managers User’s Guide Version 500

locations 272numbers 272telephone support 272

DDEV

AF/OPERATOR System Variables 240Automation Application Tables 238Automation Tables 240Components 238Controlling Resources 247Functions 249Object Name 251Parameters 248Service Subroutines 239, 246Standard Options 251

Device Manager 237AF/OPERATOR System Variables 240Automation Application Tables 238Automation Tables 240Command Syntax 248Components 238Controlling Resources 247Functions 249Object Name 251Parameters 248Service Subroutines 239Standard Options 251

Device ManagersService Subroutines 246

Documentationsupplied format 12

Documentation Conventions 14Documentation Set 16

Hhome page

Candle 271

IInternet site

Candle 271

MMCF

AF/OPERATOR System Variables 150Command Syntax 169Control Data 153Controlling Resources 168Extended Actions 165Functions 170Immediate Actions 162Message Data 152Message Definition 149Message Name 172Parameters 169Service Subroutines 149, 167SLF Support 166Standard Options 173Trap Data 157Triggering Conditions 160

Message Manager 147AF/OPERATOR System Variables 150Command Syntax 169Components 149Control Data 153Controlling Resources 168Extended Actions 165Functions 170Immediate Actions 162Message Data 152Message Definition 149Message Name 172Parameters 169Service Subroutines 149, 167SLF Support 166Standard Options 173Trap Data 157Triggering Conditions 160

Message Manager - Add a Message 152

Index 281

OOnline Documentation 16On-line Help

CCF Command 198DEV Command 252MCF Command 174RCF Command 146SCF Command 218VTM Command 235

PPanels and figures 14Post-Start Exit 58Post-Stop Exit 62Predecessor Exit 64Predecessor/Successor Report 146Prerequisites 11Pre-Start Exit 57Pre-Stop Exit 60Printed documentation 16Printing problems 12

RRecovery

Events that Trigger 50Resource Management Limitations 37

SSCF

Adding/Updating Schedules 202AF/OPERATOR System Variables 201Command Syntax 213Components 200Control Data 204Controlling Resources 212Extended Actions 210Functions 214Parameters 213Schedule Data 203Schedule Definition 200, 202Schedule Name 216

Service Subroutines 200, 211Standard Options 217Trap Data 208Triggering Conditions 209

Schedule Manager 199Adding/Updating Schedules 202AF/OPERATOR System Variables 201Command Syntax 213Components 200Control Data 204Controlling Resources 212Functions 214Immediate and Extended Actions 210Parameters 213Schedule Data 203Schedule Definition 200Schedule Manager 202Schedule Name 216Service Subroutines 200, 211Standard Options 217Trap Data 208Triggering Conditions 209

Schedule Manager - Add a Schedule 203Schedule Manager Schedule Definition

Panel 204Started Task Manager 21

Adding or Updating Resources 68AF/OPERATOR System Variables 29AF/OPERATOR Traps 30Automation Manager Interfaces Control

Data 91Batch CA7 Interface Data 99Batch Job Submission Data 97CFile 37Checkpoint Restart 35Command Syntax 107Control Data 70Cycle Resource 49Defining a Resource 31Defining an Exception 33Display Options 125Dynamic Controls 34

Index


Force Option 36Functions 111Initialization Process 38Kill Process 49List Data 100Parameters 110Problem Notification 36Problem Record Command File 53Queueing Function Request 35Recovery 83Recovery Exit Command File 54Recovery Flow 51Recovery Process 50Recovery Retry WTOR 53Resource Data 69Resource Lists 34Resource Management 31Resource Management Limitations 37Resource Manipulation Lock 35Resource Name 115Resource Status 129Schedule 104Schedule Data 101Schedule Process 49Service Subroutines 23Specific Definition 33Standard Options 116Start Data 77Start Process 39Stop Data 87Stop Proces 44Successors 86Task Definition 23, 67User Exits 56VTAM Resources 76Waiting Function Completion 35Warning Process 48

Started Task Manager - Add a List 100Started Task Manager - Task Add Panel 69Started Task Manager Components 23Started Task Manager Functions 38Started Task Manager List Definition

Panel 100Started Task Manager Resources 106Started Task Manager Schedule

Definition 101Started Task Manager Task Definition

Panel 70Start-WTOR Exit 59STM

Adding or Updating Resources 68AF/OPERATOR System Variables 29AF/OPERATOR Traps 30Automation Manager Interfaces Control

Data 91Batch CA7 Interface Data 99Batch Job Submission Data 97CFile 37Checkpoint Restart 35Command Syntax 107Control Data 70Cycle Process 49Defining a Resource 31Defining an Exception 33Display Options 125Dynamic Controls 34Force Option 36Functions 111Initialization Process 38Kill Process 49List Data 100Parameters 110Problem Notification 36Problem Record Command File 53Queueing Function Request 35Recovery 83Recovery Exit Command File 54Recovery Flow 51Recovery Process 50Recovery Retry WTOR 53Resource Data 69Resource Lists 34Resource Management 31Resource Management Limitations 37

Index 283

Resource Manipulation Lock 35Resource Name 115Resource Status 129Schedule 104Schedule Data 101Schedule Process 49Service Subroutines 23, 105Specific Definition 33Standard Options 116Start Data 77Start Process 39Stop Data 87Stop Process 44Successors 86Task Definition 23, 67User Exits 56VTAM Resources 76Waiting Function Completion 35Warning Process 48

STM Reporting Function 136Stop-WTOR Exit 63Successor Exit 65Symbols 15

Ttypographical conventions 14

VVariables and literals 14VTAM Dependency Exit 66VTAM Manager 219

Adding or Updating Commands 223AF/OPERATOR System Variables 222Automation Application Tables 221Command Syntax 231Components 221Controlling Resources 230Functions 232Object Name 233Parameters 231Resource Definition 223

Service Subroutines 221, 229Standard Options 234

VTMAdding or Updating Commands 223AF/OPERATOR System Variables 222Automation Application Tables 221Command Syntax 231Controlling Resources 230Functions 232Object Name 233Parameters 231Resource Definition 223Service Subroutines 221, 229Standard Options 234

WWorldwide Web site

Candle 271

Index


Documents

Primary Managers User’s Guidepublib.boulder.ibm.com/tividd/td/ITIntegRM/GC32-9225-00/... · 2004. 8. 21. · Primary Managers User’s Guide Integrated Resource Manager Version