|
SA z/OS V3.2 incorporates many new features and its key benefits include:
- Enhanced performance monitoring with improved integration with CICSPLEX SM, IBM Tivoli Enterprise Portal and OMEGAMON XE
- Improved availability management and reduced application downtime with the inclusion of provider/consumer scenarios and recover failures, smarter ‘move’ algorithms, and enhanced measurements and reporting capabilities
- Improved incident management with the integration of System Automation for Integrated Operations Management (SA IOM) that enables automated alert and escalation to help expedite problem resolution
- Enhanced interoperability with IBM Tivoli Workload Scheduler (TWS) that allows you to proactively manage critical paths to meet strict scheduling deadlines
- Usability enhancements with improved tracking of automation activity, data accessibility for user written automation routines, and the ability to temporarily modify start and stop commands
SA z/OS V3.2 provides improved ease of use, with integration of the Tivoli Enterprise Portal (TEP) for management of z/OS automation data. With this capability, the TEP can serve as the central integration point for all IBM Tivoli Monitoring, IBM Tivoli OMEGAMON XE, and IBM Tivoli Composite Application Management products, as well as IBM Tivoli Workload Scheduler and IBM Tivoli Netview for z/OS.
Event-based monitoring by SA z/OS allows you to explicitly bind monitor resources to real-world objects and optionally jobs. A trigger that contains the monitored object name or the job can then be used by SA z/OS to locate the Monitor Resource and to set the health status or issue commands. This allows SA z/OS to handle a variety of monitoring events. This has been implemented for:
- CICS link and health monitoring
- OMEGAMON XE situations
Message ING150I has been introduced as a trigger that allows you to set the health status of a Monitor Resource based on the monitored object name and job. The monitored object name must be prefixed to be able to identify objects for different products (for example, between CICSPLEX/SM and ITCAM for SOA).
INGMON, the generic routine that is responsible for health monitoring, is invoked from the NetView automation table whenever ING150I is issued. It locates the Monitor Resource for a given monitored object or job and then looks up the code match table for the health status or commands, or both, that should be issued whenever the triggering event occurs.
CICSPlex monitoring
Event-based CICS link and health monitoring is implemented using CICSPlex System Manager (CICSPlex SM) objects. Whenever an event is received from CICSPlex SM, message ING150I is issued.
INGCPSM is the event listener for CICSPlex SM. Because it is a long-running CLIST it needs to be run in a virtual operator station task (VOST). It scans the configuration on startup and listens for events. It then periodically checks whether the configuration has changed (that is, Monitor Resources have been added, deleted, or changed, etc.) or Monitor Resources are waiting for initial monitoring (that is, they have STATUS=ACTIVE and HEALTH=UNKNOWN).
Monitoring OMEGAMON XE situations
Unlike the exception-based monitoring that SA z/OS uses for classic OMEGAMON monitors, the OMEGAMON XE infrastructure provides the means to react to situations whenever they occur. On the Tivoli Enterprise Portal (TEP), a user can specify what kind of automated response (reflex automation) should be triggered for each individual situation.
SA z/OS makes use of this capability by providing a simple command called INGSIT. This command can entered on the TEP with the Take Action dialog by the ITM administrator for those situations where SA z/OS health monitoring or health-based automation should take place.
The Take Action command is carried out on the agent, in this case, OMEGAMON XE for z/OS, and not the Tivoli Enterprise Monitoring Server (TEMS) unless the TEMS is on the same system. This is because it is possible that the hub TEMS may not reside on z/OS and so the command may not be delivered.
INGSIT triggers message ING150I that allows you to set the health status of individual Monitor Resources. It is then possible to issue commands, such as recovery or notification commands, to automatically fix the situation. You can specify what health status and associated commands are issued in the customization dialog.
SA z/OS is now able to communicate with IBM Tivoli Monitoring (ITM) through the standardized Simple Object Access Protocol (SOAP) interface. Although it is not possible to interact with each and every monitoring product individually, as is the case with the existing OMEGAMON classic interface of SA z/OS, monitoring data can be accessed through the hub Tivoli Enterprise Monitoring Server (monitoring server).
The hub monitoring server can be configured such that other hubs may be reached through it. In this case a single connection to one hub monitoring server may offer access to many monitoring products outside the scope of this hub monitoring server.
The SA z/OS utility command INGOMX has been enhanced to read SOAP request data from the default SAFE or from a data set, and connect to a SOAP server that has been defined in the customization dialog, and that returns the SOAP response to the caller that requested it. This SOAP response can be processed easily through standard NetView programming techniques such as PIPE.
SA z/OS introduces availability and recovery time reporting. System Management Facility (SMF) records can now be written for subsystems (APLs), application groups (APGs), and monitor resources (MTRs). The data can be used to produce a spreadsheet to assist you in billing users or reporting the reliability of your critical applications or the software that those applications are dependent on.
Extended status command support allows you to manage components that have not been defined to SA z/OS but still depend on the availability of a subsystem. You can perform actions on applications or application components while certain services are started or stopped, or if they fail. For example, consider TCP/IP communication using WebSphere MQ. The MQ TCPIP Listener component is an application's network interface to the MQ queue manager. It listens to a particular port for TCP/IP connections. When TCP/IP is down, the listener can be stopped because there is then no point listening to the port. However, as soon as TCP/IP is up again, the listener must be restarted and listen to its port again.
Applications, or their components, that consume services are known as
service consumers (or simply consumers), and applications that provide services are known as
service providers (or simply providers). Thus the Listener is the service consumer that consumes services that are provided by TCP/IP, which is the service provider.
In certain cases the consumer application knows its provider application at configuration time. This is known as a
static link between a consumer and a provider. In other cases, the consumer has to evaluate its provider application at run time. This is a
dynamic link. Note that only consumers and providers on the
same system can be linked.
The most important changes in the behavior of the customization dialog for SA z/OS 3.2 include:
Nested class support
Nested class support allows you to link one application class to another, thus enabling the specification of a class hierarchy. Links from a class can be made in two directions:
- Downward to multiple classes or instances, where the policy that is defined in the upper-level class is inherited by the classes or instances
-
Upward to a single class, so that the lower-level application inherits the policy that is defined in the upper-level class
These classes can carry data on various levels, be nested, and an application can inherit data from a class chain. This can be particularly useful for policy databases with lots of applications of the same type, for example, large IMS installations with lots of IMS subsystems. You might define a top-level class with basic definitions for all IMS applications, and nested classes with more specific definitions for the various IMS subtypes, so that applications can inherit policy values from the top-level class and specific nested classes.
Class policies are inherited down to the instance level where any changes to the policy on that level override the inherited policy. Inherited policy data is initially displayed in a different color but you can change this from the customization dialog Settings Menu.
Policy database import
The policy database import function has been extended to allow you to select GRP and SYS entry types to be imported. You can also import the entry types that are linked to these, the links between resources in the groups or systems, and the resources in the systems.
Policy database flat file update
The flat file update facility has been enhanced to allow you to create new entries of any type and to update the following:
- The THRESHOLDS policy for the Application (APL) entry type
- All policies for the User E-T Pairs (UET) entry type
- All policies for the Monitor Resource (MTR) entry type
- A subset of policies for the Application Group (APG) entry type
CHRON timer support
This is an extension of the TMR definitions that allows you to define NetView CHRON timer parameters and thus use the full range of command scheduling that is offered by the CHRON command.
Definitions that you make with the TIMERS policy item are:
- Automatically included in the ACF fragment during configuration build
- Added to the CHRON timer definitions when the CHRON timer is created during SA z/OS initialization
Add-On sample policy databases
Best practice policies (sample policy databases) are delivered with SA z/OS V3.2 that allow you to get productive much faster, also in the case of migrating from competitive products.
The collection of policies that is delivered with SA z/OS has been enhanced, and new policies have been added, such as:
- *HYPERSWAP
- *IBMCOMP
- *ITM (previously *OMEGAMON)
- *TBSM
Diagrams of the policies are also provided as PDF files that are located in the USS installation path.
Sysplex Defaults policy object (XDF)
The Sysplex Defaults policy object allows you to define sysplex resource information defaults.
Default desired status
An option called Desired Available has been introduced that sets the Desired Status of a resource in the absence of any propagated desiredStatus votes. It is available for:
- Subsystems (APLs)
- Application groups (APGs)
- Monitor resources (MTRs)
Shared WLM resource names support
You can now define a single WLM resource for
multiple SA z/OS resources. The state of the WLM resource is ON as long as one of these SA z/OS resources is available.
SA z/OS can now access the notification feature of System Automation for Integrated Operations Management (SA IOM) to alert operators or system programmers in case of SA z/OS problems where manual intervention is required.
SA z/OS connects to the SA IOM Server and triggers the notification process for an alert. Automation managers cannot connect to SA IOM so they inform their automation agents whenever application groups that they are responsible for experience problems that require alert notification.
Alerts can be triggered by executing the INGALERT command. This can be either from the NetView automation table, from a CLIST or from the command line.
The customization dialogs allow you to specify IOM for reporting and to define alert points for application groups. SA z/OS provides a set of built-in alert points. You can use them by defining INGALERT as a message ID and specifying appropriate code entries for it. In addition you can use any user-defined alert ID you want. Specify it in the corresponding code entry and call INGALERT with this ID.
You can define the individual registration of resources through the
Inform List input field. You can specify:
- Whether a resource (APL, APG, or MTR) is registered with SDF, NMC, the TWS status observer, IOM, or SMF
- Default values for certain inheritance levels for the entry types SDF, XDF, MDF, and ADF (similar to that for the captured messages limit)
The advantages of this include:
- Reducing unnecessary data traffic
- Relaying the right resource information to the right people
- More efficient alerting and notification
If you have a large number of resources this can help improve performance.
Move Mode
You can now define a
move mode for MOVE application groups so that the order to start the new group is not sent until the old member has become inactive. You can specify whether the new groups is started in:
- Parallel: At the same time as the old member is being stopped.
-
Serial: After the old member has been stopped completely.
Preemptive Move
Preemptive move allows you to use preference values so that the automation manager can plan an application move when an operator requests a system shutdown. This can lead to much reduced downtime for the system.
SA z/OS integrates the concept of minor resource thresholds into the base code, thus providing a consistent concept for usage by each application. This includes threshold checking with a consistent evaluation concept related to the search sequence for default values of thresholds. Furthermore, SA z/OS 3.2 considers thresholds when issuing actions. This increases the flexibility in defining actions that are dependent on the frequency of the triggering event.
Minor resource thresholds can now be defined using the MINOR RESOURCE THRES policy item for all application types and additionally for MVSESA resources with the MVC entry type. CICS and IMS minor resource thresholds are also now defined with the MINOR RESOURCE THRES policy item. Minor resource names must be specified separately for minor resource flags and minor resource thresholds.
Thresholds can also be specified during run time with the INGTHRES operator command.
When SA z/OS has to control automation actions for events via thresholds, the threshold definitions are retrieved from the automation policy, and the error timestamps for the last events of the same type that have been registered are retrieved from the status file. If the frequency of the event exceeds the critical threshold, only a notification is issued to inform about the situation. If however the critical threshold has not yet been reached, the defined automation action is executed.
SA z/OS V3.2 integrates the startup, shutdown, recovery, and monitoring of IMS applications into its base functionality. The new structure makes use of existing base functionality and monitor resources (MTRs). This results in the following:
- Less IMS feature code.
- The use of base SA z/OS functions to start and stop resources.
- The use of MTRs to have relationships to the IMS applications. This further makes it possible to have customizable recovery actions from the MESSAGES/USER DATA policy or the HEALTHSTATE policy.
As part of the cleanup, the IMS panels have been modernized to give them the same look and feel as standard SA z/OS command dialogs.
The processing of WTORs by SA z/OS has been enhanced to:
- Avoid bottlenecks
- Improve performance
- Make use of NetView PIPEs and DOM messages
- Reduce run time
- Improve serviceability and reliability
When SA z/OS 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.
All WTORs that are issued at a system are forwarded to NetView and processed by the NetView automation table (AT) that triggers generic routines according to the processing purpose.
You can use the MESSAGES/USER DATA automation policy item to define what response SA z/OS should make to incoming WTORs for applications, monitor resources and MVS components.
SA z/OS keeps track of all outstanding WTORs that have not yet been replied to and displays them via SDF or NMC. You can use the automation policy to define the severity for outstanding WTORs and a priority that allows you to distinguish between primary and secondary WTORs.
Automation flags can be used to control whether or not automation actions are executed by SA z/OS. They can be set at different levels to control specific situations:
- Related to different phases in the lifetime of an application
- Resource or even minor resource specific
- As the default for applications or MVSESA resources
- As the default for a system
- In the automation policy database or during run time
- Permanently or limited in time
Restructured automation flag processing in SA z/OS 3.2 results in:
- Reduced storage consumption
- Reduced usage of timers
- Consistent checking of automation flags for minor resources
- Improved performance
The separate definition of ASSIST flags is no longer possible. To specify the LOG assist mode in SA z/OS 3.2, you can set the automation flag to L, which means that triggered automation actions that this flag is set for, such as commands or replies, are written to the NetView Log instead of being issued.
Multiple NMC Focal Points
Multiple NMC focal points are supported by focal point specific heartbeats. Typically two NMC focal points are used to survey the NMC targets. Each focal point is the backup of the other one. They always show identical information about the targets (hot backup). Both focal points have to be configured in the SA z/OS customization dialogs. Each focal point needs its own heartbeat (heartbeat timer on target system and deadman timer on focal point system).
Bulk Status Update
Many resource status changes that occur at the same time are processed together. They are sent to the NMC focal point with one call of INGPOST and applied to the RODM database with one call. This makes processing of these changes faster and more efficient. Thus, for example, the startup of a group with many members is displayed much faster on the NMC client with bulk processing.
You can use the INGAMS command dialog to display work item statistics. INGAMS shows history information about the work items processed by the automation manager. The automation manager keeps track of the last 300 work items processed by each of the tasks that build the automation manager kernel.
SA z/OS introduces work item lifecycle recording, an internal diagnostic tool that you should use only if required by SA z/OS service. It provides enhanced debugging to track down lost requests during automation agent-automation manager communication and other automation manager-related problems.
New commands
DISPAPG
The DISPAPG command displays detailed information about a specified application group.
INGCNTL
The INGCNTL common routine is used to enable and disable alerting to System Automation for Integrated Operations Management (SA IOM) and to set the parameters that are required for the connection to the SA IOM server.
INGQRY
The INGQRY common routine returns the value of the specified attribute for a particular resource.
INGVSTRT
The INGVSTRT common routine allows an automation procedure to start a virtual operator station task (VOST).
INGVSTOP
The INGVSTOP common routine allows an automation procedure to stop a virtual operator station task (VOST).
INGPSMON
The INGPSMON monitoring routine is used to determine the status of an MVS subsystem. Unlike INGPJMON it does not search MVS address space control blocks.
INGVMON
The INGVMON monitoring routine is used to determine the status of a virtual OST (VOST). It should be used as monitoring routine in a VOST management APL.
ISSUEACT
ISSUEACT, ISSUECMD and ISSUEREP are defined as synonyms for the same generic routine, which can be used to trigger your own commands, replies, or both, from messages that are defined in the automation policy item MESSAGES/USER DATA under consideration of the automation flags.
If the generic routine is called as ISSUECMD, only commands are issued, whereas if it is called as ISSUEREP, only replies are issued. When called as ISSUEACT, the generic routine issues commands and replies according to the given selection criteria that are passed as parameters.
In addition, this generic routine includes special message processing for some critical DB2 messages and for JES2 message $HASP099.
INGALERT
The INGALERT utility allows you to send alerts to operators or system programmers whenever there is a problem with SA z/OS that requires their attention.
INGCPSM
The INGCPSM utility returns status information for a CICSPlex(R) System Manager (CICSPlex SM) object. This data is returned in ING150I messages. INGCPSM should be run in a virtual operator station task (VOST).
INGLINK
The INGLINK utility lets you:
- Activate and deactivate a link between a consumer and a provider application that is defined as a dynamic link in the automation policy
- Query the status of a link between a consumer and a provider application as defined in the automation policy
A consumer is an application that has messages defined for it with a prefix of UP_ or DN_ and with a suffix of a valid subsystem name.
A provider is an application whose subsystem name is used as the suffix for an UP_ or DN_ message that is defined for any application.
INGMDFY
The INGMDFY utility displays the defined actions for the startup or shutdown of a subsystem that are currently loaded and allows you to modify them for the next startup or shutdown. INGMDFY also allows you to define additional actions or to delete defined actions for the startup or shutdown of a subsystem.
INGSIT
The INGSIT utility allows you to report an event to SA z/OS. To allow SA z/OS to react to that event, it must be associated with one or more Monitor Resources through the monitored object name and optionally a job name. The event information consists of the monitored object name, an optional event severity, an optional job name, and optional related data. INGSIT transforms the event into a well-formed ING150I message that can subsequently be automated on behalf of the monitored object according to the definitions in the automation policy.
ING$QRY
SA z/OS provides a NetView Automation Table Function (ATF), called ING$QRY. This allows you to query or compare the status and other important attributes of jobs that are controlled by SA z/OS from within the AT and use the result as a condition in the AT statement. ING$QRY is an alias. The routine returns the attribute or comparison result as the function value of the NetView ATF function so that it can be used within the AT statement
Enhanced commands
- DISPINFO
The DISPINFO command has been modified to show:
- The inform list
- The subcategory of the resource
- The class chain list, if applicable
- DISPMTR
The DISPMTR command has been modified to show:
- The timestamp, in chronological order, of the last startup and shutdown of the monitor
- The Inform list for the monitor
INGAMS
You can use the SUSPEND and RESUME parameters to control the sending of orders to an automation agent by the automation manager (in case, for example, an order to shut down a system has been unintentionally sent).
INGAUTO
You can have INGAUTO write commands and replies to the netlog if an event occurs that triggers an automated action.
INGGROUP
A new action called OVERRIDES has been introduced for the INGGROUP command. If specified, it displays resource groups whose attributes have been modified by means of the INGGROUP command.
INGINFO
The information displayed by INGINFO has been changed as follows:
- The
Compound Status now has a timestamp
- The
Desired Available setting is shown, which is the Desired Status of the resource in the absence of any propagated desiredStatus votes
INGMOVE
INGMOVE now supports the moving of a sysplex application group to another system.
- INGPLEX SVCdump
The INGPLEX SVCdump command can now be executed in line mode.
INGREQ
You can now specify a feedback parameter that causes the final result of the command to be reported back to a designated instance.
The INGREQ panel has been redesigned so that
Comment field is on the first screen.
INGSTOBS
A new wait option parameter has been added to the INGSTOBS command. It controls the maximum time to wait for process completion when a request has been sent to the automation manager, for example, when subscribing a user-specified exit as the status change observer.
- INGTIMER
You can now specify a day of the week when coding an interval with the EVERY parameter.
RESYNC
The RESYNC command now lists explicitly the resources that it can be used for.
At the end of resynchronization, subsystems in a DOWN or RESTART status are not automatically started or restarted.
- SETTIMER
The SETTIMER command has been enhanced so that you can define either an AFTER, AT or EVERY timer, and also additional options that apply to a CHRON timer.
I/O Operations Supports TCP/IP Communication
With SA z/OS V3.2 I/O operations supports TCP/IP in parallel to VTAM. All I/O operations applications running SA z/OS V3.2 will try to communicate using TCP/IP. If this fails for whatever reason the communication protocol falls back to VTAM. However, to allow I/O operations to communicate via TCP/IP you need to define at least the server port.
I/O operations supports a PARM parameter on startup that allows you to restrict the communication to a specific protocol or a particular TCP/IP address space.
I/O Operations Makes Use of the MVS Component Trace
With SA z/OS V3.2 I/O operations has replaced its internal trace table and the GTF trace with the MVS Component Trace. The benefits of this are:
- More information can be traced by a single trace entry
- The trace data can be visualized much more easily
- All I/O operations programs can perform traces even if they are running outside the I/O operations address space as IHVAPI
The implementation requires the I/O operations address space to be non-swappable.
Password Support for ISQCCMD 'CBU Command
With CBU password support, ProcOps or BCPii users can directly enter the password together with the CBU 'ACTIVATE' or 'TESTACT' command.
BCPii Support for ProcOps Lpar Management Commands
The SA z/OS BCP Internal Interface (BCPii) hardware interface now offers a common set of hardware commands (using ISQCCMD) to manage and control the logical partitions of your System z and zSeries processor hardware. In addition, the management of processor activation profiles and queries of CPC and LPAR information is available.
| 
