Administering

The following administrative procedures are available.

Adding a New Application to Automation
This information outlines the requirements to add and monitor a new application for SA z/OS.
Creating Automation Procedures
You can write additional automation procedures to supplement the basic automation procedures that are supplied by SA z/OS. For example, you may want to develop procedures to automate an application that is used exclusively on your system or to perform specialized automated operations for a subsystem.
Monitoring Applications
System Automation for z/OS provides different ways to monitor your applications:
Job Log Monitoring
This information introduces the components of joblog monitoring and describes how to set up the monitoring function using the customization dialogs.
Alert-Based Notification
SA z/OS provides an alert-based notification service that enables you to alert subject-matter experts. You can escalate automation problems that require manual intervention by sending alerts, events or trouble tickets to different kinds of notification targets.
Availability and Recovery Time Reporting
SA z/OS introduces support to assist you in billing users or reporting reliability of your critical applications or the software that those applications are dependent on. For example, you might want to charge accurately based on the amount of time required to run an application. This is of importance for non-MVS resources, such as USS applications, or monitoring resources that might run in the NetView address space.
Automating Processor Operations-Controlled Resources
This information describes how to customize your SA z/OS installation to enable the automation of messages coming from target systems that are controlled by processor operations.
Automating USS Resources
This information describes how z/OS UNIX System Services are integrated into SA z/OS, how to set up z/OS UNIX automation, and provides tips about using z/OS UNIX automation.
Command Receiver
This information describes how to set up and use command receivers for general use. The command receiver is able to pass NetView, SA z/OS or MVS commands to SA z/OS for execution. The command receiver is able to dispatch incoming commands to a dedicated group of tasks, called the command work tasks. The command receiver uses a round robin algorithm that ensures, on average, each of the associated automated functions has the same number of commands to process. In short, the technique enables the execution of multiple received commands in parallel.
Enabling Relational Data Services (RDS)
SA z/OS provides Relational Data Services (RDS) which are available through the INGRDS command. It provides basic access methods for SA z/OS built-in relational data tables. The syntax of the INGRDS command is similar to the API of SQL but without the full SQL language parser. However, RDS is not a full SQL and does not support all concepts of SQL. SA z/OS saves the relational data tables in VSAM files.
Enabling Sysplex Automation
This information covers SA z/OS specific capabilities for Parallel Sysplex® automation, how to use the SA z/OS customization dialogs to enable them, and how to customize your system.
Automating Networks
Defining a VTAM Application to SA z/OS
VTAM® applications need to have Application nodes activated for the application to operate correctly. This is normally not a problem if an application is to run on a single system. However, if the application is to be switched from one system to another (via a move group or server group), the application node definition must be deleted from the system that the application is moving from. If this is not done, users may not be able to log on to the application because there is a definition for the application node that is not active, that is, the application has not opened the node ACB.
Shutting Down z/OS Systems
This section describes the considerations of a system shutdown. When SA z/OS® is used to shut down a system, it shuts down all SA z/OS resources like applications (APLs), application groups (APGs), and monitor resources (MTRs) that are defined in the SA z/OS policy. This includes the Automation Managers (AM) and NetView itself that are represented by APL definitions. Both AMs and NetView itself are intended to be the last applications to be terminated.
WTOR Processing
When Z System Automation receives WTORs (write-to-operator-with-reply requests), it either automatically replies to them, or stores them if they are to be used for recovery or to shut down the subsystem that issued them. WTORs that are stored for later use are known as outstanding WTORs.
SA z/OS User Exits
To allow user-specific activities that are not covered by the Customization Dialog, SA z/OS provides support for the following classes of user exits:
Automation Solutions
SA z/OS provides solutions that enable automatic processing of z/OS components, data sets and job scheduling systems as well as automation procedures that are useful tools in the automation processing context. By using these prefabricated automation procedures you can save the time to develop your own procedures to handle the processing in corresponding situations.
Global Variables
You must ensure that the names of any global variables you create do not clash with SA z/OS external or internal global variable names. You should check the following tables before creating any global variables of your own.
Customizing the Status Display Facility
Coordinating System Operations with Automatic Restart Manager
SA z/OS system operations provides coordination with the Automatic Restart Manager. The Automatic Restart Manager (ARM) is a base z/OS component. It is a recovery function that automatically restarts designated applications when:
TSO User Monitoring
Active TSO users can be monitored in SDF using the SA z/OS command DFTSOU (EVJETSOU).
z13/z13s Specific Timeout Values for Selected Hardware Commands
Mainframe types D/T2964 and D/T2965 may require an elongated period of time to clear the main storage assigned to a logical partition due to a hardware chip deficiency, which cannot be corrected. The ISQCCMD common commands that allow to clear the main storage are ACTIVATE, DEACTIVATE, SYSRESET, and LOAD. If a TIMEOUT value used is not high enough to satisfy this machine type specific condition, the command may end with a timeout error.