Browse Prior Art Database

Method and System for Automating Hardware Tests using Tivoli Configuration Manager

IP.com Disclosure Number: IPCOM000083512D
Original Publication Date: 2005-Mar-01
Included in the Prior Art Database: 2005-Mar-01
Document File: 2 page(s) / 34K

Publishing Venue

IBM

Abstract

Use of TCM (Tivoli Configuration Manager) in HardwareTest Automation Objective: Using TCM to store complete system configuration required for selecting machine for hardware test.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 51% of the total text.

Page 1 of 2

Method and System for Automating Hardware Tests using Tivoli Configuration Manager

Reasons for selecting * TCM (Tivoli Configuration Manager): - Collecting the system hardware configuration of multiple test machines and storing it in DB2 tables, all in an automated fashion. The machines are hardware systems under test.

Purpose : - The hardware data stored in the configuration repository can be used towards selecting a specific test machine(that matches the hardware requirements for a certain hardware test) from amongst a pool of machines.

- Eventually a tester can store the fail data in the same database as the hardware configuration and setup a relation between the fail data and the hardware configuration against which it was run. Hence, this data can be used at a later time to recreate a fail or lookup the fix. (Not covered in this invention)

Description:

Using TCM one can : - Scan hardware software to determine which enterprise assets are part of one's inventory. - Automate and schedule network operations. - Monitor system and configuration changes. - Manage desired state of all elements in one's network - Manage one's enterprise environment across firewalls.

Implementation:

TCM, **Tivoli Management Framework and ***Tivoli Server were installed on one of the test machines. (Tivoli Server for a specific Tivoli management region holds the complete set of Tivoli software, including the full object database).

DB2 database tables were created with the different fields for storing the inventory. These tables are filled with the data that is scanned from the test machines. In order to scan a test machine an endpoint was created on the system under test. (An endpoint is the final recipient of any Tivoli operation). This starts a daemon on the test machine. In our case this needed to exist on the SUT (System Under Test) whose configuration information we require and on which we will perform the inventory scan.

A profile is created which includes information about what all areas one wants to cover in a particular scan/distribution(processor,memory,partition,pci device etc). Multiple profiles can exist. Once an endpoint is created on a particular system a scan can be initiated by drag-n-dropping the profile on the endpoint icon. Once the scan completes the system inventory gets stored in the database tables. The scan results/data from an

1

Page 2 of 2

endpoint are stored in the MIF file on the endpoint which is then parsed and results are placed in the configuration repository in the database schema. Inventory data can be gotten from the configuration repository by using different views via TCM GUI (Graphical User Interface). The information is also stored in the MIF (Management Information Format)...