2007, 2021 EView Technology. All Rights Reserved.

Transcription

2007, 2021 EView Technology. All rights reserved.This document contains unpublished, confidential, and proprietary information of EViewTechnology. No disclosure or use of any portion of the contents of this document may be madewithout the express written consent of EView Technology.ServiceNow is a trademark or registered trademark of ServiceNow, Inc., in the United Statesand/or other countries.Version 7.3.0Last Update: 29 March 2021

Preface .1Ironstream for ServiceNow Discovery for IBM Z.3Ironstream Overview .3Architecture and Data Flow .4New in Version 7.3 .4Ironstream Mainframe Agent .7Agent Main Task . 7Agent Subtasks . 7Ironstream Proxy Server .9Proxy Server Components .9Adding a Mainframe to the Ironstream Proxy and ServiceNow .9Mainframe Discovery Probes and Sensors . 10Discovery Data Flow . 10Discovery Probes . 11LPAR Resource Discovery . 11Db2 Subsystem Discovery . 11CICS Discovery. 12IBM MQ Discovery . 12IMS Discovery . 12List of Discovery Probes . 12Ironstream for ServiceNow Discovery for IBM Zi

THIS PAGE IS INTENTIONALLY LEFT BLANKIronstream for ServiceNow Discovery for IBM Zii

This document is intended for licensed Ironstream for ServiceNow Discovery for IBM Z administratorsand users.Please note: Ironstream for ServiceNow Discovery for IBM Z was formerly EView/390zMainframe Discovery for ServiceNow. Precisely is in the process of re-branding all EView productsto Ironstream.To contact Precisely Support, please visit https://support.precisely.com/.Ironstream for ServiceNow Discovery for IBM Z provides manuals to help you use the product andunderstand the underlying concepts. All product documentation is available athttps://support.precisely.com/. Installation GuideExplains how to upload Ironstream installation files from the Ironstream proxy server,update z/OS, NetView/390, and SOLVE:NETMASTER software, start and stop Ironstreamand also describes all relevant console commands. Administration GuideExplains how to configure and use Ironstream, detailed troubleshooting procedures,explanations of z/OS messages, and z/OS console commandsIn addition to Ironstream documentation, related ServiceNow products provide a comprehensiveset of manuals that help you use the products and improve your understanding of the underlyingconcepts.This manual’s title page contains the following identifying information: Version number, which indicates the software version. Print date, which changes each time the document is updated.This table indicates changes made to this document since the last released edition.Ironstream for ServiceNow Discovery for IBM Z Concepts Guide1

DateDescriptionJan 2020Version A.07.30Feb-2021Document re-branded to PreciselyIronstream for ServiceNow Discovery for IBM Z Concepts Guide2

This chapter describes Ironstream for ServiceNow Discovery for IBM Z. It also provides a briefoverview of its benefits, architecture, and data flow.Ironstream for ServiceNow Discovery for IBM Z integrates the z/OS mainframe platform intoServiceNow Discovery. With the addition of Ironstream, ServiceNow Discovery provides you withtrue end-to-end management of your information technology (IT) environment, from PCs tomainframe computers.Ironstream is closely integrated into the ServiceNow Discovery instance. An Ironstream agentmonitors the z/OS mainframe environment to be processed and stored in the ServiceNow CMDB.Ironstream provides you with the following benefits: Compatibility with z/OSAbility to co-exist with currently installed z/OS management solutions. Comprehensive ViewGet a comprehensive view of all your IT resources to improve IT operations management(ITOM) Automated Configuration Data CollectionEliminate manual processes to reduce errors, increase productivity and respond faster Better Decision MakingRelationship mapping to correlate configuration items to incident and change management.Ironstream for ServiceNow Discovery for IBM Z Concepts Guide3

Ironstream consists of two main components: The Ironstream Agent component that runs on the z/OS mainframe.Ironstream Proxy Server component that runs on a ServiceNow MID server.The diagram below shows the data flow between the z/OS mainframe, the Ironstream proxy serverand the ServiceNow MID Server.The ServiceNow MID server agent receives requests by the ServiceNow instance to run commandsthat are sent by the Ironstream Proxy Server to the Ironstream mainframe agent to be executed.Results are returned to the Ironstream proxy server and returned to the ServiceNow instancewhere the results are processed by the associated sensor and configuration items added to theServiceNow CMDB.See the section Discovery Data Flow for further details on the workflow.Version 7.3 contains the following enhancements and features: APF Dataset Discovery – Datasets defined to the Authorized Program Facility arediscovered for each LPAR. The discovery process will attempt to verify that datasets in theAPF list exist and if verified a “verified” attribute will be set to “true”. If the dataset cannotbe verified the “verified” attribute will be set to false.Ironstream for ServiceNow Discovery for IBM Z Concepts Guide4

CICSPlex Discovery – This discovery will check LPARs to see if a CICSPlex exists on theLPAR and if found will create a configuration item for the CICSPlex. Additionally, adiscovery probe is available to discover CICS programs and transactions that have beendefined using BAS. Active Software Product Discovery – This discovery uses data discovered during theactive job discovery and data collected using SMF Type 30 subtype 4 records to discoversoftware products that are actively running on z/OS LPARs. The discovery makes use of aSyncsort provided software catalog as well as a user populated catalog to match programexecutable names from the SMF Type 30 subtype 4 data or the Mainframe active jobs tableto a product name and populate the Active Software Products table.Ironstream for ServiceNow Discovery for IBM Z Concepts Guide5

Parent-Child Relationship and Relationship Type Configuration – Each discoveryprobe for mainframe discovery can now be configured to change the direction of therelationship as displayed in the ServiceNow dependency views. Additionally, the defaultRelationship type used for created relationships can be overridden for each discovery probe.Ironstream for ServiceNow Discovery for IBM Z Concepts Guide6

This chapter describes the agent provided with Ironstream.The Ironstream agent operates as a z/OS started task. In a Discovery environment the agent iswaiting for data requests from the Ironstream proxy server on the ServiceNow MID server.The Ironstream mainframe agent executes as a started task or batch job on the mainframe system.The Job Control Language (JCL) starts the main task program. The main task program opens andreads initialization cards from System Input (SYSIN), which specifies the subtasks to be started.As the cards are processed, a set of interprocess communication queues is set up in storage to beshared by the main task and all subtasks. All communication between tasks within the Ironstreamagent is accomplished by these queues. After SYSIN card processing is complete, the Ironstreamagent main task routes messages between the subtask queues and processes maintenance (Modify)commands from the z/OS console operator.The Ironstream agent subtasks collectively provide all the necessary communications and systeminterfaces. Each of the subtasks are dedicated to a particular interface function and communicateswith other subtasks using the Ironstream agent interprocess communications queues.Each subtask uses the following two queues: Subtask Input QueueQueue used for messages destined for processing in the subtask interface. These messagescan be commands for execution or messages to be transmitted to the Ironstream proxyserver component. Subtask Output QueueQueue used for messages that are the result of subtask processing. Messages from thisqueue are routed by the main task to other subtasks for processing.The TCP/IP (TCP) subtask is an executable that requests the opening of two TCP/IP ports from theTCP/IP address space on the mainframe, then waits for the Ironstream proxy server component tostart communication with the Ironstream mainframe agent through these ports. The TCP subtaskaccepts commands from the Ironstream proxy server component, routes them to the appropriatesubtask for execution, and sends the replies back to the Ironstream proxy server component over aTCP/IP port.As a rule, you must have one TCP subtask defined for each Ironstream proxy server componentthat will be connecting to the mainframe through TCP/IP.Ironstream for ServiceNow Discovery for IBM Z Concepts Guide7

The Command (CMD) subtask is an executable that does the following:1. Establishes an extended Multiple Console Support (MCS) console for Ironstream.2. Receives z/OS commands (for example, Modify) from the Ironstream proxy servercomponents.3. Sends the commands to the defined console.4. Receives the response messages from z/OS.5. Sends the responses back to the Ironstream proxy server component that initiated thecommand.The Secondary Program Operator (SPO) subtask is an executable that does the following:1. Initializes a SPO Active Control Block (ACB) to VTAM.2. Receives VTAM commands (for example, Vary or Display) from Ironstream proxy servercomponent subtasks.3. Sends the commands to VTAM over the SPO.4. Receives the response messages from VTAM.5. Sends response messages back to the Ironstream proxy server component subtask thatinitiated the command.If several commands arrive at nearly the same time from different OMi operators, the Ironstreamagent allows for multiple SPO subtasks to distribute the work.The Operating System Information subtask (OSINFO) collects on-demand information about themainframe system its active address spaces, DASD statistics, memory usage, and submitted jobs.These data can be requested at any time using a command script on the OVO management serverto allow users to develop customized queries about the status of the mainframe.The SMF when active initializes SMF exits to collect SMF record data and forward that data to theIronstream proxy on the ServiceNow MID server. For mainframe job discovery, SMF type 30subtype 4 and subtype 5 records are collected.The Ironstream agent has a subtask restart function that automatically restarts the mainframesubtasks when communication is lost from the host. This restart function eliminates the need torestart the entire Ironstream agent address space.Ironstream for ServiceNow Discovery for IBM Z Concepts Guide8

This chapter describes the components and process management provided by Ironstream proxyserver, installed on the ServiceNow MID server. The client components perform the followingprimary functions: Establish and maintain communication with the Ironstream mainframe agent Send requests for discovery data through the communication channel to the Ironstreammainframe agent and receive responses to those requests. A configuration interface to define z/OS systems to be discovered and start and stopcommunication between the client and the Ironstream mainframe agent.For each mainframe LPAR to be discovered there is one service created. This service runs theIronstream Message and Command server service which maintains an active connection with theIronstream mainframe agent.The ev390hostcmd utility program is the vehicle for sending data requests to the Ironstreammainframe agent and receiving responses to those requests. The ev390hostcmd program may beexecuted directly by discovery probes or by scripts which are executed by discovery probes.You must install these Ironstream proxy server components before you install the Ironstreamagent.The Ironstream web configuration interface is used to add a new mainframe node to be monitored.After you enter some identifying information about the mainframe, the web configuration interfacewill create a configuration file on the Ironstream proxy server and trigger the Ironstreamdiscovery policy to run which will add a z/OS CI to ServiceNow.Ironstream for ServiceNow Discovery for IBM Z Concepts Guide9

This chapter describes the data flow, the different discovery probes and sensors and the type ofdata discovered.1. When probes are scheduled to execute on the ServiceNow instance they are sent to the MIDServer agent.2. The probes execute commands or scripts that make requests of the Ironstream proxy serverto collect data, relevant to the type of discovery being executed by the probe.3. The requests are passed by the Ironstream proxy server to the mainframe agent.4. The agent executes the commands on the mainframe.5. The results of the data request are returned to the Ironstream proxy server.6. The Ironstream proxy server passes the results back to the script which sends them back tothe ServiceNow instance. Depending on the probe, the script may do additional processingof the data returned from the mainframe.7. The associated sensor parses the output data and creates configuration items andrelationships in the CMDB.Ironstream for ServiceNow Discovery for IBM Z Concepts Guide10

Mainframe discovery is broken down into 38 different probes in 5 different component categories.See the section List of Discovery Probes for a list of probes in each category. This allows theadministrator to choose which types of mainframe data is to be discovered without having todiscover data that is not required for the customer use cases.LPAR resource discovery encompasses all z/OS host related resource type discoveries. There are15 probes available that are available for performing discovery of different types of LPAR hostconfiguration data. The following types of information are available using LPAR resourcediscovery probes. LPAR and Basic Information (Serial, number, CPU information, physical machine) Network Information (TCP Stacks, Interfaces, IP Addresses, Connections, Routes) Disk Information (SMS Storage Groups, Volumes in Storage Groups, Online DASD) Active Jobs (Jobs running at time of Discovery) Completed Jobs (Completed job information collected from SMF type 30 records) Authorized Program Facility Datasets Active Software Products (based on software product catalog)Db2 subsystem discovery consists of 8 different probes to discover information on active Db2subsystems on all discovered LPARs. The following types of information are available using theDb2 Subsystem discovery probes. Active Db2 subsystems on LPARs Data sharing groups and members Distributed Data Facility Definitions and Aliases Distributed Data Facility Remote Locations Db2 Databases Db2 Tablespaces Db2 TablesIronstream for ServiceNow Discovery for IBM Z Concepts Guide11

CICS discovery consists of 2 different probes to discover active CICS regions and configurationinformation for the CICS regions. The following types of information are available using the CICSdiscovery probes. Active CICS Regions CICS Lists, Groups, Transactions and Programs (includes transactions and programsdefined using BAS) CICS plexIBM MQ discovery consists of 3 probes to discover IBM MQ managers and information related tothose MQ managers. The following types of information are available using the IBM MQ discoveryprobes. MQ Managers MQ Channels MQ QueuesIMS Discovery consists of 5 probes to discover IMS subsystems and regions on each LPAR. Thefollowing types of information are available using the IMS discovery probes. IMS Subsystems and active regions IMS Databases IMS Database areas IMS Transactions and associated PSBThis chapter provides a list of all the discovery probes available and the names of the CMDB tablethat the probes right to.In each category, the first probe listed is the minimum requirement for doing discovery in thosecategories. For Db2, CICS, IBM MQ and IMS, the probes are listed in the order that they must berun because of dependency relationships between the different configuration items.Ironstream for ServiceNow Discovery for IBM Z Concepts Guide12

Ironstream for ServiceNow Discovery for IBM Z Concepts Guide13

Ironstream proxy on the ServiceNow MID server. For mainframe job discovery, SMF type 30 subtype 4 and subtype 5 records are collected. The Ironstream agent has a subtask restart function that automatically restarts the mainframe subtasks when communication is lost from the host. This restart function eliminates the need to