AE and NSK

You can connect the Automation Engine (AE) to NSK which is a NonStop operating system where NSK stands for Nonstop Kernel. NSK was originally introduced by Tandem Computers Inc., and is now part of the Hewlett Packard Enterprise. The connection from the AE to your NSK system is established through an NSK agent. This agent works together with the AE system through a TCP/IP interface. The NSK Agent can handle and improve job processing, File Transfer executions, and you can use it together with a CallAPI. This topic provides detailed technical information on how Jobs run on an HP NonStop Server through an AE NSK Agent.

Note: This integration capability, like all integrations of the Automic system, can support Service Orchestration Workflows. Such Workflows orchestrate automated processes that run across multiple platforms, domains, and applications to deliver a specific IT service. For more information, see About Service Orchestration.

This page includes the following:

AE Agent Architecture for the HP NonStop Server

The following illustration visualizes how the AE Agent works together with the HP NonStop Server:

Job Start

The Automation Engine initiates the job start and notifies the AE NSK Agent that the job has started. This agent then creates an entry in the AE status file.

The AE NSK Agent sends a message to the AE Output Collector through IPC. This message informs about:

  • the user of the job
  • the job file that should be used
  • the virtual terminal that should be used (if necessary)
  • the priority of the job
  • the file name of the job report
  • the AE macro file name, and so on

The agent gets the following information back:

  • # location of the AE Output Collector that should be used as the output file for the job that should start.
    The AE Output Collector writes all outputs that it receives to this # location to the corresponding report file.
  • A flag that informs whether a re-usable TACL process is available, or a new TACL process must be started by the agent.
  • The information whether the default user that is used by the reserved TACLs after the job has ended is still valid.

If necessary, the agent starts a new TACL process. This process then logs on to the AE Output Collector that is specified as the output device.
The Output Collector generates the report file. Then, it configures the TACL process of the job by setting the user, the priority, and so on. Finally, the TACL process of the job obtains the job file as an OBEY file and starts to process the job.

Job Run

While the job is running, all the outputs that the job generates are sent to the AE Output Collector, and written to the job reports. If an entry is expected and a terminal is configured for the job, the respective entry is collected from the terminal.
The connection between the job report and the job is established through the # location that is used by the jobs to address the Output Collector (output device).
Example: Outputs of the $UC4OC.#AAL location can be written to the $DATA.REPORTS.FFXX report file, and outputs of the $UC4OC.#AAM location to the $DATA.REPORTS.FFXY report file.
# Location names derive from the agent or the Output Collector.

Job End

The Output Collector recognizes that the job has ended when the TACL process of the job requires an entry, or when it closes the Output Collector because an error occurred. When the job has ended, the Output Collector writes this information to the status file of the job and it sends the corresponding message to the agent through IPC. Finally, the agent reports the job to the Server as finished.

Notes

  • Importance of the status file
    If the agent or the Output Collector fails, the status file of the job helps to restore failed processes. When you restart such a failed process, its context is retrieved from the status file of the job. Therefore, many jobs can continue without causing further troubles in operation. Jobs that may have ended while the agent or the Output Collector were down, are identified and reported. This process ensures that the Automation Engine always has the correct information about the status of the system of the agent.

  • Mutual monitoring
    The agent and the Output Collector monitor themselves mutually. One of these processes may end unexpectedly if it is stopped by accident, the CPU fails, or because of a software error. The surviving process automatically restarts the failed process in such a case. If the CPU of the failed process is not available, another available CPU is selected. Preferably, the system uses a CPU that differs from the CPU of the surviving process. This process ensures that the system is fault-tolerant.

See also: