Architecture of the CA7 Server for AAI

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

The CA7 Server for AAI consists of two STCs and an ISPF-based Instance Management System user interface. This graphic illustrates it:

Graphich of the CA7 Server for AAI architecture

The following sections explain the graphic:

AAI Platform Server

This is the server on which AAI is installed and where the Native Connector runs to process the delivered data files for AAI.

Server STC (Primary 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 member called AI7S[xxxy], where[xxxy] identifies the specific instance of the CA7 Server for AAI. This JCL invokes BPXBATCH to start the Unix environment. When the environment is up and running, the Primary Server STC executes a Unix module called AIS7SRVR, which is located in the USS installation directory.

The Server STC is the primary controller task for the CA7 Server for AAI functionality, whose main activity is the generation and delivery of the event data file. The Server STC operates on a cycle basis which, by default, occurs every 30 seconds. During each cycle the following activities occur in sequence:

  1. Calculate the start and end date/time for the next Event extract period based on the last successful delivery Checkpoint date/time stored in the SRVRCKPT dataset.

  2. Execute the SASSHIS8 program for the calculated period to generate the next RPT70.YYMMDD.HHmmss event extract data file into the USS directory where the zFS is mounted.

  3. Invoke the defined data delivery method to transfer the RPT70.YYMMDD.HHmmss data file to the specified AAI directory.

  4. Check the server request dataset SRVRSREQ for any manual requests.

  5. Check for an automatic scheduled definition data generation activity.

  6. Spawn the definitions child process if requested or if due on the automatic schedule.

  7. Calculate the remaining time in the 30 second cycle after the above activities have completed.

  8. Perform a Wait (sleep) for the remaining time until the start of the next cycle.

When the definitions child process is spawned by the Primary Server STC, this task runs asynchronously, invoking the CCITERM program sequentially to generate the following data files:

  • LDSN for job dependency definitions

  • LJOB for job definitions

  • SCAL for calendar conditions

  • TIMEZONE with the CA7 time zone

These data files are generated into the USS directory where the zFS is mounted. Once this completes successfully, the defined data delivery method is invoked to transfer the four definition data files to the specified directory on the AAI server.

Instance Management System (IMS)

The IMS is an interactive ISPF-based menu system with which you add, configure and control multiple instances of the CA7 Server for AAI. The CUSTLIB library contains the IMS control members for all managed CA7 Server for AAI instances, as well as their instance-specific JCL members. Sites that are running both CA7 and IWS/z can use a common installation and a common CUSTLIB library to manage both types of CA7 Server for AAI instances.

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

The IMS can support up to 8 instances of the CA7 Server for AAI. This means that you can deploy up to 8 instances of the CA7 Server for AAI on a given LPAR or across multiple LPARs and manage them all through the same IMS instance. For more information about installations with multiple instances, see Multi-Instance Considerations.

Each CA7 Server for AAI instance has its own configuration dataset called SRVRSCFG, where the IMS stores that instance's configuration parameters. Each Instance also has a SRVRSREQ request dataset for passing requests to the server STC and a SRVRCKPT dataset for maintaining a checkpoint date/time of the last successful event data file delivery.

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 CA7 Server for AAI is defined, a JCL member called AI7R[XXXY] is created in the CUSTLIB. This contains the JCL needed to execute the request STC.

These are the main functions of the Request STC:

  • Automate the shutdown of the server STC through the SRVRSREQ library.

  • Initiate other server STC actions, for example automated requests for generation and delivery of the definition data.

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:

See also: