Architecture of the IWSz Server for AAI

The IWSz Server for AAI is a Broadcom's software solution that caters for the integration between IWSz and AAI. It is installed on the mainframe to retrieve IWSz job definition data and event data and to pass them onto AAI. This topic explains the components that make up an instance of the IWSz Server for AAI.

Graphic of the architecture of the IWSz Server

The following sections explain the graphic:

IWS Connector Server

It is important to know that the data that is prepared and delivered for AAI is not delivered to AAI directly. Instead, it is delivered to the IWS Connector, which in turn passes the data onto the AAI server.

The IWS Connector performs the majority of the IWSz and IWSd data processing functions and makes the processed data available to the AAI Server via a web http connection. This type of architecture is used for integrating a number of different Schedulers with AAI and was designed to reduce the overhead on the AAI Server system itself.

Although the IWS Connector can be installed on the same server as the main AAI system in low activity environments, such as a test configuration, it is generally recommended that a separate server be used for the IWS Connector execution.

Server STC

The primary Server STC is a continuously running task that executes in the LPAR/USS environment. It is initially started via an instance- specific JCL that invokes BPXBATCH to start the Unix environment. When the environment is up and running, it executes a Unix module called AITS[xxxy]. This is the Server STC code executing under the process name of AITS[xxxy], where xxxy identifies the specific Instance of the IWSz Server for AAI.

The Server STC functions are:

Generate and deliver the event data files to the IWS Connector server

With each pull cycle, the Server STC uses the SASSHIS8 utility to generate an intermediate dataset called SRVRRPTS. SRVRRPTS contains the names and timestamps of the events for each pull cycle. Based on SRVRRPTS, an RPT70.YYMMDD.HHmmss file is generated that is sent via FTP/SFTP to the IWS Connector server.

The pull cycle is determined by the Current Plan Data whenever a Current Plan Extend or Replan occurs in IWSz.

As soon as this file is sent, the SASSHIS8 updates a checkpoint dataset called SRVRCKPT that contains the date and timestamp of the last successfully delivered RPT70. The SRVRCKPT dataset is used for automatic data recovery purposes during a WARM start of the IWSz Server for AAI.
Generate and deliver the job definition data to the IWS Connector server

This type of data does not generally change very often (in the graphic, this is once a day). :

Instance Management System (IMS)

The IMS is an interactive menu based on ISPF. You add, configure and control instances of the IWSz Server for AAI from the IMS. The CUSTLIB library contains the configuration files and JCLs that you need to manage an IMS instance. The CUSTLIB library is common to all defined IMS instances.

When you create an IMS instance, a number of JCLs members are generated in the CUSTLIB, one of them being the JCL AIS7[xxxy] . Executing this JCL starts the IWSz Server for AAI primary STC for the specific instance identified by the [xxxy] suffix.

The IMS can support up to eight instances of the IWSz Server for AAI. This means that you can deploy up to eight instances of the IWSz Server for AAI on a given LPAR or across multiple LPARs and manage them all through the same IMS instance.

Each IWSz Server for AAI instance has a configuration dataset called SRVRSCFG that stores all its configuration parameters.

Important!

You need a separate instance defined in the IMS for each instance of the IWSz Server for AAI.

Request STC

The Request STC is a transient task primarily used by automation solutions to issue control commands to the Server STC. The Request STC executes in a z/OS Address Space. When an instance of the IWSz Server for AAI is defined, a JCL member called AITR[XXXY] is created in the CUSTLIB.

This contains the JCL needed to execute the Request STC. The main functions of the Request STC are:

Automate the shutdown of the Server STC through the SRVRSREQ library.
Initiate other Server STC actions, for example requesting generation and delivery of Definition Data and Current Plan Data files

Next Steps

Now that you are familiarized with the basic architecture of the CA7 Server for AAI you can start with the installation tasks. The following topics guide you through them: