DOCSLIB.ORG

An Analysis of Software Quality and Maintainability

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
An Analysis of Software Quality and Maintainability AN ANALYSIS OF SOFTWARE QUALITY AND MAINTAINABILITY METRICS WITH AN APPLICATION TO A LONGITUDINAL STUDY OF THE LINUX KERNEL By Lawrence Gray Thomas Dissertation Submitted to the Faculty of the Graduate School of Vanderbilt University in partial fulfillment of the requirements for the degree of DOCTOR OF PHILOSOPHY In Computer Science August, 2008 Nashville, Tennessee Approved: Dr. Stephen R. Schach Dr. Larry Dowdy Dr. Julie Adams Dr. Richard Alan Peters II Dr. Ralph M. Butler (MTSU) Copyright © 2008 by Lawrence Gray Thomas All Rights Reserved To my beloved wife, Peggy and To the memory of my mother, Nina Irene Gray, Vanderbilt Class of 1947 iii ACKNOWLEDGEMENTS This work was funded in part by a grant from Microsoft Corporation. I am also grateful to Klocwork Inc., for generously providing their software tools used in this research. I am especially indebted to Dr. Stephen R. Schach, Associate Professor of Computer Science and Computer Engineering at Vanderbilt University, who has been invaluable in supporting my research, and who as worked actively to provide me with the protected academic time and other necessary resources to pursue my research. Nobody has been more important to me in the pursuit of this goal than my loving wife, Peggy. I am thankful for her unending encouragement, support, inspiration, and patience. iv TABLE OF CONTENTS Page DEDICATION .................................................................................................................. iii ACKNOWLEDGEMENTS .............................................................................................. iv LIST OF TABLES ............................................................................................................ ix LIST OF FIGURES .......................................................................................................... x Chapter I. INTRODUCTION......................................................................................................1 1.1 What is Quality?...........................................................................................1 1.2 Quality Factors, Quality Metrics, and Validation ........................................2 1.3 Coupling.......................................................................................................6 1.4 Previous Validation Studies .........................................................................8 1.5 Research Objectives.....................................................................................9 1.6 Problem Statement .....................................................................................11 1.7 Contributions of This Work .......................................................................12 1.8 Organization of the Remainder of the Dissertation....................................14 II. RELATED WORK ..................................................................................................16 2.1 Open-Source Software and the Origins of Linux.......................................16 2.2 Software Maintenance................................................................................19 2.3 Metrics Related to Quality and Maintainability.........................................22 2.3.1 Global Variables and Common Coupling........................................24 2.3.2 McCabe’s Cyclomatic Complexity Metrics.....................................30 2.3.3 Halstead Volume (Software Science) ..............................................45 2.3.4 Lines of Code...................................................................................50 2.3.5 Oman’s Maintainability Index (MI).................................................52 2.3.6 Klocwork’s Risk Metric...................................................................59 2.4 Categorization of Instances of Global Variables .......................................61 2.5 What Constitutes “The Kernel”?................................................................62 2.6 Software Evolution ....................................................................................64 III. LINUX: SOURCE CODE AND TOOLS ................................................................65 3.0 Introduction................................................................................................65 3.1 The Linux Source Code .............................................................................65 3.2 Building Linux Under Linux – the Debian Distribution............................66 3.3 CXREF.......................................................................................................68 3.4 Klocwork....................................................................................................68 v 3.5 VMWare Workstation................................................................................69 3.6 WinRAR.....................................................................................................69 3.7 MySQL.......................................................................................................69 IV. WHY REVISIT SCHACH ET AL.?........................................................................71 4.1 Introduction - Aspects of [Schach et al. 2002] to Reconsider....................71 4.2 The Code Base to Consider - What Constitutes the Linux Kernel?...........72 4.3 Kernel Versions Examined (Production vs. Development) .......................77 4.4 Intervals used to determine rate of growth.................................................83 V. SELECTING A CONFIGURATION FOR EMPIRICAL RESEARCH ON THE LINUX KERNEL..........................................................................................85 Contributions in this Chapter ............................................................................85 5.1 Chapter Introduction ..................................................................................85 5.2 Kernel Version Series Chosen for Inclusion in This Study .......................87 5.3 Selecting a Configuration for Empirical Research on the Linux Kernel ...90 5.4 The Configuration Script – make config ...........................................103 5.5 The One Major Exception to Our Method ...............................................107 5.6 Verifying Our Configuration as Selected.................................................107 VI. GLOBAL VARIABLES: A NEW CATEGORIZATION AND ITS CASE TOOL...................................................................................................................111 6.1 How “Global” is “Global”?......................................................................111 6.2 Classifying the GV Instances – Instance Kinds .......................................112 6.3 Performing the GV Instance Classification..............................................118 6.4 Analysis of the Instance Kinds.................................................................129 6.5 Analysis of the Instance Kinds and Common Coupling ..........................139 VII. SCHACH ET AL. 2002, REDUX..........................................................................142 Contribution of this Chapter ...........................................................................142 7.0 Introduction..............................................................................................142 7.1 Which Versions of the Linux Kernel Should We Consider? ...................142 7.2 Development vs. Stable Series and Their Life Cycles.............................145 7.3 Kernel Versions Examined by Schach et al. ............................................147 7.3.1 Schach et al. and the 2.00.x kernels...............................................147 7.3.2 Schach et al. and the 2.02.x kernels...............................................148 7.3.3 Schach et al. and the 2.04.x kernels...............................................149 7.4 Development/Stable Code Forking History.............................................149 7.5 Selecting a Cutoff Point ...........................................................................153 7.6 Confirming Our Cutoff Points by Examining Code Churn .....................154 7.7 Kernel Series 2.00.x, 2.02.x, and 2.04.x – One Longitudinal Study or Three? .....................................................................................................167 7.8 Measuring the Size of the Linux Kernel ..................................................171 vi 7.9 Rate of Growth of the Size of the Linux kernel.......................................177 7.9.1 Versions 2.00.x ..............................................................................177 7.9.2 Versions 2.02.x ..............................................................................182 7.9.3 Versions 2.04.x ..............................................................................185 7.9.4 All Versions ...................................................................................188 7.10 Rate of Growth of Common Coupling in the Linux Kernel ..................190 7.10.1 Common Coupling In the 2.00.x Kernels ....................................190 7.10.2 Common Coupling In the 2.02.x Kernels ....................................192 7.10.3 Common coupling in the 2.04.x Kernels .....................................195 7.10.4 All Versions .................................................................................203 7.11 Examining Schach et al.’s data with respect to release date..................204 7.12 Summary and Conclusions.....................................................................209
Load more

Recommended publications
  • 24 Bringing Order to Chaos: Barrier-Enabled I/O Stack for Flash Storage
    Bringing Order to Chaos: Barrier-Enabled I/O Stack for Flash Storage YOUJIP WON and JOONTAEK OH, Hanyang University, Korea JAEMIN JUNG, Texas A&M University, USA GYEONGYEOL CHOI and SEONGBAE SON, Hanyang University, Korea JOOYOUNG HWANG and SANGYEUN CHO, Samsung Electronics, Korea This work is dedicated to eliminating the overhead required for guaranteeing the storage order in the modern IO stack. The existing block device adopts a prohibitively expensive approach in ensuring the storage order among write requests: interleaving the write requests with Transfer-and-Flush. For exploiting the cache bar- rier command for flash storage, we overhaul the IO scheduler, the dispatch module, and the filesystem sothat these layers are orchestrated to preserve the ordering condition imposed by the application with which the associated data blocks are made durable. The key ingredients of Barrier-Enabled IO stack are Epoch-based IO scheduling, Order-Preserving Dispatch,andDual-Mode Journaling. Barrier-enabled IO stack can control the storage order without Transfer-and-Flush overhead. We implement the barrier-enabled IO stack in server as well as in mobile platforms. SQLite performance increases by 270% and 75%, in server and in smartphone, respectively. In a server storage, BarrierFS brings as much as by 43× andby73× performance gain in MySQL and SQLite, respectively, against EXT4 via relaxing the durability of a transaction. CCS Concepts: • Software and its engineering → File systems management; Additional Key Words and Phrases: Filesystem, storage, block device, linux ACM Reference format: Youjip Won, Joontaek Oh, Jaemin Jung, Gyeongyeol Choi, Seongbae Son, Jooyoung Hwang, and Sangyeun Cho. 2018. Bringing Order to Chaos: Barrier-Enabled I/O Stack for Flash Storage.
    [Show full text]
  • Building Useful Program Analysis Tools Using an Extensible Java Compiler
    Building Useful Program Analysis Tools Using an Extensible Java Compiler Edward Aftandilian, Raluca Sauciuc Siddharth Priya, Sundaresan Krishnan Google, Inc. Google, Inc. Mountain View, CA, USA Hyderabad, India feaftan, [email protected] fsiddharth, [email protected] Abstract—Large software companies need customized tools a specific task, but they fail for several reasons. First, ad- to manage their source code. These tools are often built in hoc program analysis tools are often brittle and break on an ad-hoc fashion, using brittle technologies such as regular uncommon-but-valid code patterns. Second, simple ad-hoc expressions and home-grown parsers. Changes in the language cause the tools to break. More importantly, these ad-hoc tools tools don’t provide sufficient information to perform many often do not support uncommon-but-valid code code patterns. non-trivial analyses, including refactorings. Type and symbol We report our experiences building source-code analysis information is especially useful, but amounts to writing a tools at Google on top of a third-party, open-source, extensible type-checker. Finally, more sophisticated program analysis compiler. We describe three tools in use on our Java codebase. tools are expensive to create and maintain, especially as the The first, Strict Java Dependencies, enforces our dependency target language evolves. policy in order to reduce JAR file sizes and testing load. The second, error-prone, adds new error checks to the compilation In this paper, we present our experience building special- process and automates repair of those errors at a whole- purpose tools on top of the the piece of software in our codebase scale.
    [Show full text]
  • Ein Wilder Ritt Distributionen
    09/2016 Besichtigungstour zu den skurrilsten Linux-Distributionen Titelthema Ein wilder Ritt Distributionen 28 Seit den frühen 90ern schießen die Linux-Distributionen wie Pilze aus dem Boden. Das Linux-Magazin blickt zurück auf ein paar besonders erstaunliche oder schräge Exemplare. Kristian Kißling www.linux-magazin.de © Antonio Oquias, 123RF Oquias, © Antonio Auch wenn die Syntax anderes vermu- samer Linux-Distributionen aufzustellen, Basis für Evil Entity denkt (Grün!), liegt ten lässt, steht der Name des klassischen denn in den zweieinhalb Jahrzehnten falsch. Tatsächlich basierte Evil Entity auf Linux-Tools »awk« nicht für Awkward kreuzte eine Menge von ihnen unseren Slackware und setzte auf einen eher düs- (zu Deutsch etwa „tolpatschig“), sondern Weg. Während einige davon noch putz- ter anmutenden Enlightenment-Desktop für die Namen seiner Autoren, nämlich munter in die Zukunft blicken, ist bei an- (Abbildung 3). Alfred Aho, Peter Weinberger und Brian deren nicht recht klar, welche Zielgruppe Als näher am Leben erwies sich der Fo- Kernighan. Kryptische Namen zu geben sie anpeilen oder ob sie überhaupt noch kus der Distribution, der auf dem Ab- sei eine lange etablierte Unix-Tradition, am Leben sind. spielen von Multimedia-Dateien lag – sie heißt es auf einer Seite des Debian-Wiki wollten doch nur Filme schauen. [1], die sich mit den Namen traditioneller Linux für Zombies Linux-Tools beschäftigt. Je kaputter, desto besser Denn, steht dort weiter, häufig halten Apropos untot: Die passende Linux- Entwickler die Namen ihrer Tools für Distribution für Zombies ließ sich recht Auch Void Linux [4], der Name steht selbsterklärend oder sie glauben, dass einfach ermitteln. Sie heißt Undead Linux je nach Übersetzung für „gleichgültig“ sie die User ohnehin nicht interessieren.
    [Show full text]
  • Parfait – Designing a Scalable Bug Checker
    Parfait – Designing a Scalable Bug Checker Cristina Cifuentes Bernhard Scholz Sun Microsystems Laboratories Sun Microsystems Laboratories Brisbane, Australia Brisbane, Australia [email protected] and The University of Sydney Sydney, Australia [email protected] ABSTRACT library code to 6 MLOC for the core of the Solaris OS and We present the design of Parfait, a static layered program the compilers. analysis framework for bug checking, designed for scalability and precision by improving false positive rates and scale to In talking to these Sun organizations it became clear that millions of lines of code. The Parfait framework is inherently a set of requirements had not been addressed for those teams parallelizable and makes use of demand driven analyses. to be using existing off-the-shelf bug checking tools for C/C++ code. Such requirements are: In this paper we provide an example of several layers of analyses for buffer overflow, summarize our initial imple- mentation for C, and provide preliminary results. Results • scalability: few tools can run over large (millions of are quantified in terms of correctly-reported, false positive lines of code) code bases in an efficient way. Several and false negative rates against the NIST SAMATE syn- tools cannot parse the code or easily integrate with thetic benchmarks for C code. existing build environments, others can but may take too long (> 3 days) to run. Categories and Subject Descriptors • rate of false positives: the tools that support millions D.2.4 [Software Engineering]: Software/Program Veri- of lines of code tend to report many bugs that are not fication; D.2.8 [Software Engineering]: Metrics; D.3.4 bugs, leading to dissatisfaction and lack of use of the [Programming Languages]: Processors tool.
    [Show full text]
  • Enabling Virtualization Technologies for Enhanced Cloud Computing
    New Jersey Institute of Technology Digital Commons @ NJIT Dissertations Electronic Theses and Dissertations Fall 1-31-2015 Enabling virtualization technologies for enhanced cloud computing Kashifuddin Qazi New Jersey Institute of Technology Follow this and additional works at: https://digitalcommons.njit.edu/dissertations Part of the Computer Sciences Commons Recommended Citation Qazi, Kashifuddin, "Enabling virtualization technologies for enhanced cloud computing" (2015). Dissertations. 106. https://digitalcommons.njit.edu/dissertations/106 This Dissertation is brought to you for free and open access by the Electronic Theses and Dissertations at Digital Commons @ NJIT. It has been accepted for inclusion in Dissertations by an authorized administrator of Digital Commons @ NJIT. For more information, please contact [email protected]. Copyright Warning & Restrictions The copyright law of the United States (Title 17, United States Code) governs the making of photocopies or other reproductions of copyrighted material. Under certain conditions specified in the law, libraries and archives are authorized to furnish a photocopy or other reproduction. One of these specified conditions is that the photocopy or reproduction is not to be “used for any purpose other than private study, scholarship, or research.” If a, user makes a request for, or later uses, a photocopy or reproduction for purposes in excess of “fair use” that user may be liable for copyright infringement, This institution reserves the right to refuse to accept a copying order
    [Show full text]
  • Heterogeneous Clusters.Pdf
    HowTo Heterogeneous Clusters Running ClusterKnoppix as a master node to a CHAOS drone army HowTo Heterogeneous Clusters Running ClusterKnoppix as a master node to a CHAOS drone army CONTROL PAGE Document Approvals Approved for Publication: Author Name: Ian Latter 12 December 2003 Document Control Document Name: Heterogeneous Clusters; Running ClusterKnoppix as a master node to a CHAOS drone army Document ID: howto - heterogenous clusters.doc-Release-1.1(467) Distribution: Unrestricted Distribution Status: Release Disk File: C:\Documents and Settings\_.NULL\Desktop\whitepaper\HowTo - Heterogenous Clusters.doc Copyright: Copyright 2003, Macquarie University Version Date Release Information Author/s 1.1 12-Dec-03 Release / Unrestricted Distribution Ian Latter 1.0 11-Dec-03 Draft / Uncontrolled Ian Latter Distribution Version Release to 1.1 Public Release 1.0 Macquarie University, Moshe Bar, Bruce Knox, Wim Vandersmissen Unrestricted Distribution Copyright 2003, Macquarie University Page 2 of 13 HowTo Heterogeneous Clusters Running ClusterKnoppix as a master node to a CHAOS drone army Table of Contents 1 OVERVIEW..................................................................................................................................4 2 WHY YOU WANT A HETEROGENEOUS CLUSTER ..........................................................5 2.1 WHERE APPLICATIONS LIVE ...................................................................................................5 2.2 OPTIMIZING CLUSTER ADMINISTRATION ................................................................................5
    [Show full text]
  • Helix QAC and Klocwork: Which One Is Right for You? Perforce Static Code Analyzers Comparison Guide
    & COMPARISON Helix QAC and Klocwork: Which One Is Right For You? Perforce Static Code Analyzers Comparison Guide Perforce’s static code analyzers — Helix QAC and Klocwork — have been trusted for over 30 years to deliver the most accurate and precise results to mission-critical project teams across a variety of industries. However, depending on your project, one of our software development tools may better meet your needs. Here, we breakdown both tools in order to help you decide which one is right for you. Helix QAC: Best For Functional Klocwork: Best For Developer Safety Compliance Productivity, SAST, and DevOps For over 30 years, Helix QAC has been the trusted static code Klocwork SAST and SAQT for C, C++, C#, and Java identifies analyzer for C and C++ programming languages. With its depth software security, quality, and reliability issues and ensures and accuracy of analysis, Helix QAC has been the preferred compliance to a broad spectrum of recognized standards. static code analyzer in tightly regulated and safety-critical Built for enterprise DevOps and DevSecOps, Klocwork industries that need to meet rigorous compliance requirements. scales to projects of any size, integrates with large complex Often, this involves verifying compliance with coding standards environments, a wide range of developer tools, and provides — such as MISRA and AUTOSAR — and functional safety control, collaboration, and reporting for the entire enterprise. standards, such as ISO 26262. This has made Klocwork the preferred static analyzer that keeps development velocity high while enforcing continuous Helix QAC is certified for functional safety compliance by SGS- compliance for security and quality.
    [Show full text]
  • Linux Installation and Getting Started
    Linux Installation and Getting Started Copyright c 1992–1996 Matt Welsh Version 2.3, 22 February 1996. This book is an installation and new-user guide for the Linux system, meant for UNIX novices and gurus alike. Contained herein is information on how to obtain Linux, installation of the software, a beginning tutorial for new UNIX users, and an introduction to system administration. It is meant to be general enough to be applicable to any distribution of the Linux software. This book is freely distributable; you may copy and redistribute it under certain conditions. Please see the copyright and distribution statement on page xiii. Contents Preface ix Audience ............................................... ix Organization.............................................. x Acknowledgments . x CreditsandLegalese ......................................... xii Documentation Conventions . xiv 1 Introduction to Linux 1 1.1 About This Book ........................................ 1 1.2 A Brief History of Linux .................................... 2 1.3 System Features ......................................... 4 1.4 Software Features ........................................ 5 1.4.1 Basic commands and utilities ............................. 6 1.4.2 Text processing and word processing ......................... 7 1.4.3 Programming languages and utilities .......................... 9 1.4.4 The X Window System ................................. 10 1.4.5 Networking ....................................... 11 1.4.6 Telecommunications and BBS software .......................
    [Show full text]
  • HPC with Openmosix
    HPC with openMosix Ninan Sajeeth Philip St. Thomas College Kozhencheri IMSc -Jan 2005 [email protected] Acknowledgements ● This document uses slides and image clippings available on the web and in books on HPC. Credit is due to their original designers! IMSc -Jan 2005 [email protected] Overview ● Mosix to openMosix ● Why openMosix? ● Design Concepts ● Advantages ● Limitations IMSc -Jan 2005 [email protected] The Scenario ● We have MPI and it's pretty cool, then why we need another solution? ● Well, MPI is a specification for cluster communication and is not a solution. ● Two types of bottlenecks exists in HPC - hardware and software (OS) level. IMSc -Jan 2005 [email protected] Hardware limitations for HPC IMSc -Jan 2005 [email protected] The Scenario ● We are approaching the speed and size limits of the electronics ● Major share of possible optimization remains with software part - OS level IMSc -Jan 2005 [email protected] Hardware limitations for HPC IMSc -Jan 2005 [email protected] How Clusters Work? Conventional supe rcomputers achieve their speed using extremely optimized hardware that operates at very high speed. Then, how do the clusters out-perform them? Simple, they cheat. While the supercomputer is optimized in hardware, the cluster is so in software. The cluster breaks down a problem in a special way so that it can distribute all the little pieces to its constituents. That way the overall problem gets solved very efficiently. - A Brief Introduction To Commodity Clustering Ryan Kaulakis IMSc -Jan 2005 [email protected] What is MOSIX? ● MOSIX is a software solution to minimise OS level bottlenecks - originally designed to improve performance of MPI and PVM on cluster systems http://www.mosix.org Not open source Free for personal and academic use IMSc -Jan 2005 [email protected] MOSIX More Technically speaking: ● MOSIX is a Single System Image (SSI) cluster that allows Automated Load Balancing across nodes through preemptive process migrations.
    [Show full text]
  • Full Circle Magazine N° 85 1 Full Ciircle Magaziine N''est Affiiliié En Aucune Maniière À Canoniical Ltd
    Full Circle LE MAGAZINE INDÉPENDANT DE LA COMMUNAUTÉ UBUNTU LINUX Numéro 85 -Mai 2014 UUBBUUNNTTUU 11 44..0044 MIS SUR LA SELLETTE full circle magazine n° 85 1 Full Ciircle Magaziine n''est affiiliié en aucune maniière à Canoniical Ltd.. sommaire ^ Tutoriels Full Circle LE MAGAZINE INDÉPENDANT DE LA COMMUNAUTÉ UBUNTU LINUX Python p.1 1 ActusLinux p.04 LibreOffice p.1 4 Command&Conquer p.09 Arduino p.25 Demandez au petitnouveau p.29 GRUB2etMultibooting p.17 LaboLinux p.33 Critique:Ubuntu14.04 p.37 Monnaievirtuelle p.39 Blender p.19 Courriers p.42 Tuxidermy p.43 Q&R p.44 Inkscape p.21 Sécurité p.46 Conception Open Source p.47 JeuxUbuntu p.49 Graphismes Les articles contenus dans ce magazine sont publiés sous la licence Creative Commons Attribution-Share Alike 3.0 Unported license. Cela signifie que vous pouvez adapter, copier, distribuer et transmettre les articles mais uniquement sous les conditions suivantes : vous devez citer le nom de l'auteur d'une certaine manière (au moins un nom, une adresse e-mail ou une URL) et le nom du magazine (« Full Circle Magazine ») ainsi que l'URL www.fullcirclemagazine.org (sans pour autant suggérer qu'ils approuvent votre utilisation de l'œuvre). Si vous modifiez, transformez ou adaptez cette création, vous devez distribuerla création qui en résulte sous la même licence ou une similaire. Full Circle Magazine est entièrement indépendantfull de circle Canonical, magazine le sponsor n° 85 des projets2 Ubuntu. Vous ne devez en aucun cas présumer que les avis et les opinions exprimés ici ont reçu l'approbation de Canonical.
    [Show full text]
  • 4D Ariadne the Static Debugger of Java Programs 2011 55 3-4 127 Ariadne Syntax Tree (DST), the Control Flow Graph Build Mechanism, I.E
    Ŕ periodica polytechnica 4D Ariadne the Static Debugger of Electrical Engineering Java Programs 55/3-4 (2011) 127–132 doi: 10.3311/pp.ee.2011-3-4.05 Zalán Sz˝ugyi / István Forgács / Zoltán Porkoláb web: http://www.pp.bme.hu/ee c Periodica Polytechnica 2011 RESEARCH ARTICLE Received 2012-07-03 Abstract 1 Introduction Development environments support the programmer in nu- During software development maintaining and refactoring merous ways from syntax highlighting to different refactoring programs or fixing bugs are essential part of this process. Al- and code generating methods. However, there are cases where though there are prevalent, good quality tools for the latter, there these tools are limited or not usable, such as getting familiar are only a few really reliable tools to maintain huge projects: with large and complex source codes written by a third person; finding the complexity of projects, finding the dependencies of finding the complexities of huge projects or finding semantic er- different modules, understanding large software codes written rors. by third party programmers or finding semantic errors. In this paper we present our static analyzer tool, called 4D In this paper we present 4D Ariadne [21] that helps the pro- Ariadne, which concentrates on these problems. 4D Ariadne grammer or the software architect to deal with maintenance and is a static debugger of Object Oriented applications written in program comprehension. 4D Ariadne is a static debugger tool Java programming language It calculates data dependencies of of Object Oriented programs written in Java programming lan- objects being able to compute them both forward and backward.
    [Show full text]
  • Monitoring Agent for Linux OS Reference Chapter 1
    Monitoring Agent for Linux OS Version 6.3.5 Reference IBM Monitoring Agent for Linux OS Version 6.3.5 Reference IBM Note Before using this information and the product it supports, read the information in “Notices” on page 227. This edition applies to version 6.35.14 of the Monitoring Agent for Linux OS and to all subsequent releases and modifications until otherwise indicated in new editions. © Copyright IBM Corporation 2010, 2018. US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. Contents Chapter 1. Monitoring Agent for Linux Linux Group data set.......... 108 OS ................. 1 Linux Host Availability data set ...... 109 Linux IO Ext (Superseded) data set ..... 110 Chapter 2. Dashboard ......... 3 Linux IO Extended data set........ 113 Linux IP Address data set ........ 116 Default dashboard pages .......... 3 Linux LPAR data set .......... 117 Widgets for the Default dashboard pages ..... 4 Linux Machine Information data set ..... 120 Custom views ............. 31 Linux Network data set ......... 122 Linux Network (Superseded) data set .... 127 Chapter 3. Thresholds ........ 33 Linux NFS Statistics data set ....... 133 Predefined thresholds ........... 33 Linux NFS Statistics (Superseded) data set .. 142 Customized thresholds .......... 36 Linux OS Config data set ........ 152 Linux Process data set ......... 153 Chapter 4. Attributes ......... 39 Linux Process (Superseded) data set ..... 163 Data sets for the monitoring agent....... 40 Linux Process User Info data set ...... 170 Attribute descriptions ........... 44 Linux Process User Info (Superseded) data set 174 Agent Active Runtime Status data set .... 45 Linux RPC Statistics data set ....... 178 Agent Availability Management Status data set 47 Linux RPC Statistics (Superseded) data set .
    [Show full text]