TRANSLATION LOOKASIDE BUFFER

A translation lookaside buffer (TLB) is a CPU cache that memory management hardware uses to improve virtual address translation speed. All current desktop and server processors (such as x86) use a TLB to map virtual and physical address spaces, and it is ubiquitous in any hardware which utilizes virtual memory.

The TLB is typically implemented as content-addressable memory (CAM). The CAM search key is the virtual address and the search result is a physical address. If the requested address is present in the TLB, the CAM search yields a match quickly and the retrieved physical address can be used to access memory. This is called a TLB hit. If the requested address is not in the TLB, it is a miss, and the translation proceeds by looking up the page table in a process called a page walk. The page walk is an expensive process, as it involves reading the contents of multiple memory locations and using them to compute the physical address. After the physical address is determined by the page walk, the virtual address to physical address mapping is entered into the TLB.

A TLB has a fixed number of slots that contain page table entries, which map virtual addresses to physical addresses. The virtual memory is the space seen from a process. This space is segmented in pages of a prefixed size. The page table (generally loaded in memory) keeps track of where the virtual pages are loaded in the physical memory. The TLB is a cache of the page table; that is, only a subset of its content are stored.

The TLB references physical memory addresses in its table. It may reside between the CPU and the CPU cache, between the CPU cache and primary storage memory, or between levels of a multi-level cache. The placement determines whether the cache uses physical or virtual addressing. If the cache is virtually addressed, requests are sent directly from the CPU to the cache, and the TLB is accessed only on a cache miss. If the cache is physically addressed, the CPU does a TLB lookup on every memory operation and the resulting physical address is sent to the cache. There are pros and cons to both implementations. Caches that use virtual addressing have for their key part of the virtual address plus, optionally, a key called an "address space identifier" (ASID). Caches that don't have ASIDs must be flushed every context switch in a multiprocessing environment.

Implication For Performance:

The CPU has to access main memory for a:

• instruction cache miss
• data cache miss
• TLB miss

The third case (the simplest case) is where the desired information itself actually is in a cache, but the information for virtual-to-physical translation is not in a TLB. These are all about equally slow, so a program "thrashing" the TLB will run just as poorly as one thrashing an instruction or data cache. That is why a well functioning TLB is important.

VIRTUAL FUNCTION

A virtual function or virtual method is a function or method whose behaviour can be overridden within an inheriting class by a function with the same signature. This concept is a very important part of the polymorphism portion of object-oriented programming (OOP).

The concept of the virtual function solves the following problem:

In OOP when a derived class inherits a base class, an object of the derived class may be referred to (or cast) as either being the base class type or the derived class type. If there are base class methods overridden by the derived class, the method call behaviour is ambiguous.

The distinction between virtual and non-virtual resolves this ambiguity. If the function in question is designated "virtual" in the base class then the derived class's function would be called (if it exists). If it is not virtual, the base class's function would be called.

Virtual functions overcome the problems with the type-field solution by allowing the programmer to declare functions in a base class that can be redefined in each derived class.

In C++ virtual functions or virtual methods are declared by using the virtual keyword to the function's declaration.

For example, a base class Animal could have a virtual function eat. Subclass Fish would implement eat() differently than subclass Wolf, but you can invoke eat() on any class instance referred to as Animal, and get the eat() behaviour of the specific subclass.

This allows a programmer to process a list of objects of class Animal, telling each in turn to eat (by calling eat()), with no knowledge of what kind of animal may be in the list. You also do not need to have knowledge of how each animal eats, or what the complete set of possible animal types might be.

The following is an example in C++. Note that this example is not exception-safe. In particular, it may leak resources if new or vector::push_back throws an exception.

#include <iostream>
#include <vector>
 
class Animal {
    public:
        virtual void eat() const { 
            std::cout << "I eat like a generic Animal." << std::endl; 
        }
        virtual ~Animal() { 
        }
};
 
class Wolf : public Animal {
    public:
        void eat() const { 
            std::cout << "I eat like a wolf!" << std::endl; 
        }
        virtual ~Wolf() { 
        }
};
 
class Fish : public Animal {
    public:
        void eat() const { 
            std::cout << "I eat like a fish!" << std::endl; 
        }
        virtual ~Fish() { 
        }
};
 
class GoldFish : public Fish {
    public:
        void eat() const { 
            std::cout << "I eat like a goldfish!" << std::endl; 
        }
        virtual ~GoldFish() { 
        }
};
 
class OtherAnimal : public Animal {
        virtual ~OtherAnimal() { 
        }
};
 
int main() {
    std::vector<Animal*> animals;
    animals.push_back(new Animal());
    animals.push_back(new Wolf());
    animals.push_back(new Fish());
    animals.push_back(new GoldFish());
    animals.push_back(new OtherAnimal());
 
    for (std::vector<Animal*>::const_iterator it = animals.begin(); it != animals.end(); ++it) {
        (*it)->eat();
        delete *it;
    }
 
    return 0;
}

Output with the virtual function Animal::eat():

I eat like a generic Animal.
I eat like a wolf!
I eat like a fish!
I eat like a goldfish!
I eat like a generic Animal.

Output if Animal::eat() were not declared as virtual:

I eat like a generic Animal.
I eat like a generic Animal.
I eat like a generic Animal.
I eat like a generic Animal.
I eat like a generic Animal.

COST BENEFIT

A cost benefit analysis is done to determine how well, or how poorly, a planned action will turn out. Although a cost benefit analysis can be used for almost anything, it is most commonly done on financial questions. Since the cost benefit analysis relies on the addition of positive factors and the subtraction of negative ones to determine a net result, it is also known as running the numbers.

Cost Benefit Analysis

A cost benefit analysis finds, quantifies, and adds all the positive factors. These are the benefits. Then it identifies, quantifies, and subtracts all the negatives, the costs. The difference between the two indicates whether the planned action is advisable. The real trick to doing a cost benefit analysis well is making sure you include all the costs and all the benefits and properly quantify them.

Should we hire an additional sales person or assign overtime? Is it a good idea to purchase the new stamping machine? Will we be better off putting our free cash flow into securities rather than investing in additional capital equipment? Each of these questions can be answered by doing a proper cost benefit analysis.

Example Cost Benefit Analysis

As the Production Manager, you are proposing the purchase of a $1 Million stamping machine to increase output. Before you can present the proposal to the Vice President, you know you need some facts to support your suggestion, so you decide to run the numbers and do a cost benefit analysis.

You itemize the benefits. With the new machine, you can produce 100 more units per hour. The three workers currently doing the stamping by hand can be replaced. The units will be higher quality because they will be more uniform. You are convinced these outweigh the costs.

There is a cost to purchase the machine and it will consume some electricity. Any other costs would be insignificant.

You calculate the selling price of the 100 additional units per hour multiplied by the number of production hours per month. Add to that two percent for the units that aren't rejected because of the quality of the machine output. You also add the monthly salaries of the three workers. That's a pretty good total benefit.

Then you calculate the monthly cost of the machine, by dividing the purchase price by 12 months per year and divide that by the 10 years the machine should last. The manufacturer's specs tell you what the power consumption of the machine is and you can get power cost numbers from accounting so you figure the cost of electricity to run the machine and add the purchase cost to get a total cost figure.

You subtract your total cost figure from your total benefit value and your analysis shows a healthy profit. All you have to do now is present it to the VP, right? Wrong. You've got the right idea, but you left out a lot of detail. 

FACT FINDING TECHNIQUE

To study any system the analyst needs to do collect facts and all relevant information. the facts when expressed in quantitative form are termed as data. The success of any project is depended upon the accuracy of available data. Accurate information can be collected with help of certain methods/ techniques. These specific methods for finding information of the system are termed as fact finding techniques. Interview, Questionnaire, Record View and Observations are the different fact finding techniques used by the analyst. The analyst may use more than one technique for investigation. 

Interview
This method is used to collect the information from groups or individuals. Analyst selects the people who are related with the system for the interview. In this method the analyst sits face to face with the people and records their responses. The interviewer must plan in advance the type of questions he/ she is going to ask and should be ready to answer any type of question. He should also choose a suitable place and time which will be comfortable for the respondent.

The information collected is quite accurate and reliable as the interviewer can clear and cross check the doubts there itself. This method also helps gap the areas of misunderstandings and help to discuss about the future problems. Structured and unstructured are the two sub categories of Interview. Structured interview is more formal interview where fixed questions are asked and specific information is collected whereas unstructured interview is more or less like a casual conversation where in-depth areas topics are covered and other information apart from the topic may also be obtained.


Questionnaire
It is the technique used to extract information from number of people. This method can be adopted and used only by an skillful analyst. The Questionnaire consists of series of questions framed together in logical manner. The questions are simple, clear and to the point. This method is very useful for attaining information from people who are concerned with the usage of the system and who are living in different countries. The questionnaire can be mailed or send to people by post. This is the cheapest source of fact finding.


Record View
The information related to the system is published in the sources like newspapers, magazines, journals, documents etc. This record review helps the analyst to get valuable information about the system and the organization.

Observation
Unlike the other fact finding techniques, in this method the analyst himself visits the organization and observes and understand the flow of documents, working of the existing system, the users of the system etc. For this method to be adopted it takes an analyst to perform this job as he knows which points should be noticed and highlighted. In analyst may observe the unwanted things as well and simply cause delay in the development of the new system.

INHERITANCE IN C++

Inheritance is the process of creating new classes from the existing class or classes.

Using inheritance, one can create general class that defines traits common to a set of related items. This class can then be inherited (reused) by the other classes by using the properties of the existing ones with the addition of its own unique properties.

The old class is referred to as the base class and the new classes, which are inherited from the base class, are called derived classes.



In above figure, the class B contains the three member i.e. Property1, Property2 and Property3.

The second class named as D contains four members i.e. Property1, Property2, Property3 and Property4.

Out of these, three members (Property1, Property2, Property3) of the class D are same as that of class B, while the one member i.e. Property4 is unique.

In the class D, instead of defining all the three members again, one can reuse them from the class B. This feature is known as inheritance which saves time, space, money and increases the reliability and efficiency.

Forms of Inheritance:

Single Inheritance

If a class is derived from a single base class, it is called as single inheritance.

Multiple Inheritance

If a class is derived from more than one base class, it is known as multiple inheritance

Multilevel Inheritance

The classes can also be derived from the classes that are already derived. This type of inheritance is called multilevel inheritance.

Hierarchical Inheritance

If a number of classes are derived from a single base class, it is called as hierarchical inheritance

A derived class can be defined as follows:

class derived_class_name : access_specifier base_class_name
{
data members of the derived class ;
member functions of the derived class ;
}
The colon (:), indicates that the class derived_class_name is derived from the class base_class_name.
The access_specifier may be public, private or protected (will be discussed further).
If no access_specifier is specified, it is private by default.
The access_specifier indicates whether the members of the base class are privately derived or publicly derived.

Public inheritance

When a derived class publicly inherits the base class, all the public members of the base class also become public to the derived class and the objects of the derived class can access the public members of the base class.

The following program will illustrate the use of the single inheritance.

This program has a base class B, from which class D is inherited publicly.

Example:

#include
class Rectangle
{
private:
float length ; // This can't be inherited
public:
float breadth ; // The data and member functions are inheritable
void Enter_lb(void)
{
cout << "\n Enter the length of the rectangle : ";
cin >> length ;
cout << "\n Enter the breadth of the rectangle : ";
cin >> breadth ;
}
float Enter_l(void)
{ return length ; }
}; // End of the class definition

class Rectangle1 : public Rectangle
{
private:
float area ;
public:
void Rec_area(void)
{ area = Enter_l( ) * breadth ; }
// area = length * breadth ; can't be used here

void Display(void)
{
cout << "\n Length = " << Enter_l( ) ; // Object of the derived class can't
// inherit the private member of the base class. Thus the member
// function is used here to get the value of data member 'length'.
cout << "\n Breadth = " << breadth ;
cout << "\n Area = " << area ;
}
}; // End of the derived class definition D
void main(void)
{
Rectangle1 r1 ;
r1.Enter_lb( );
r1.Rec_area( );
r1.Display( );
}

Figure- Public Inheritance



Private inheritance

When a derived class privately inherits a base class, all the public members of the base class become private for the derived class.

In this case, the public members of the base class can only be accessed by the member functions of the derived class.

The objects of the derived class cannot access the public members of the base class.

Note that whether the derived class is inherited publicly or privately from the base class, the private members of the base class cannot be inherited.


Example:

#include
#include
class Rectangle
{
int length, breadth;
public:
void enter()
{
cout << "\n Enter length: "; cin >> length;
cout << "\n Enter breadth: "; cin >> breadth;
}
int getLength()
{
return length;
}
int getBreadth()
{
return breadth;
}
void display()
{
cout << "\n Length= " << length;
cout << "\n Breadth= " << breadth;
}
};

class RecArea : private Rectangle
{

public:
void area_rec()
{
enter();
cout << "\n Area = " << (getLength() * getBreadth());
}
};
void main()
{
clrscr();
RecArea r ;
r.area_rec();
getch();
}

Example:2

#include
class Rectangle // Base class
{
private:
float length ; // This data member can't be inherited
public:
float breadth ; // This data member is inheritable
void Enter_lb(void)
{
cout << "\n Enter the length of the rectangle: "; cin >> length ;
cout << "\n Enter the breadth of the rectangle: "; cin >> bredth ;
}
float Enter_l(void)
{
return length ;
}
void Display_l(void)
{
cout << "\n Length = " << length ;
}
}; // End of the base class Rectangle.
// Defining the derived class Rectangle1. This class has been derived from the
// base class i.e. Rectangle, privately.
class Rectangle1 : private Rectangle // All the public members of the base class
{ // Rectangle become private for the derived class Rectangle1.
private:
float area ;
public:
void Rec_area(void)
{
Enter_lb( );
area = Enter_l( ) * bredth ; // length can't be used directly
}
void Display(void)
{
Display_l( ); // Displays the value of length.
cout << "\n Bredth = " << bredth ;
cout << "\n Area = " << area << endl ;
}
};
void main(void)
{
Rectangle1 r1 ;
r1.Rec_area( ) ;
// r.Enter_lb( ); will not work as it has become private for the derived class.
r1.Display( ) ;
// r.Display_l( ) will not work as it also has become private for the derived class.
}

Fig: private inheritance



The protected access specifier

The third access specifier provided by C++ is protected.

The members declared as protected can be accessed by the member functions within their own class and any other class immediately derived from it.

These members cannot be accessed by the functions outside these two classes.

Therefore, the objects of the derived class cannot access protected members of the base class.

When the protected members (data, functions) are inherited in public mode, they become protected in the derived class. Thus, they can be accessed by the member functions of the derived class.

On other hand, if the protected members are inherited in the private mode, the members also become private in the derived class.

They can also be accessed by the member functions of the derived class, but cannot be inherited further.



Overriding the member functions:

The member functions can also be used in a derived class, with the same name as those in the base class.

One might want to do this so that calls in the program work the same way for objects of both base and derived classes.

The following program will illustrate this concept.

#include
const int len = 20 ;
class Employee
{
private:
char F_name[len];
int I_number ;
int age ;
float salary ;
public:
void Enter_data(void)
{
cout << "\n Enter the first name = " ; cin >> F_name ;
cout << "\n Enter the identity number = " ; cin >> I_number ;
cout << "\n Enter the age = " ; cin >> age ;
cout << "\n Enter the salary = " ; cin >> salary ;
}
void Display_data(void)
{
cout << "\n Name = " << F_name ;
cout << "\n Identity Number = " << I_number ;
cout << "\n Age = " << age ;
cout << "\n Salary = " << salary ;
}
}; // End of the base class
class Engineer : public Employee
{
private:
char design[len] ; // S_Engineer, J_Engineer, Ex_Engineer etc

public:
void Enter_data( )
{
Employee :: Enter_data( ) ; // Overriding of the member function
cout << "\n Enter the designation of the Engineer: " ; cin >> design ;
}


void Display_data(void)
{
cout << "\n *******Displaying the particulars of the Engineer**** \n" ;
Employee :: Display_data( ) ; // Overriding of the member function
cout << "\n Designition = " << design ;
}
}; // End of the derived class

void main(void)
{
Engineer er ;
er.Enter_data( ) ;
er.Display_data( );
}

Hierarchical Inheritance:
When two or more classes are derived from a single base class, then
Inheritance is called the hierarchical inheritance. The representation
of the hierarchical inheritance is shown in the following Fig.



In the above Fig., student is a base class, from which the three classes viz. arts, science and commerce have been derived. Now, let us write a program that illustrates the hierarchical inheritance, based on the above design.

Example

include
const int len = 20 ;
class student // Base class
{
private: char F_name[len] , L_name[len] ;
int age, int roll_no ;
public:
void Enter_data(void)
{
cout << "\n\t Enter the first name: " ; cin >> F_name ;
cout << "\t Enter the second name: "; cin >> L_name ;
cout << "\t Enter the age: " ; cin >> age ;
cout << "\t Enter the roll_no: " ; cin >> roll_no ;
}
void Display_data(void)
{
cout << "\n\t First Name = " << F_name ;
cout << "\n\t Last Name = " << L_name ;
cout << "\n\t Age = " << age ;
cout << "\n\t Roll Number = " << roll_no ;
}
};
class arts : public student
{
private:
char asub1[len] ;
char asub2[len] ;
char asub3[len] ;
public:
void Enter_data(void)
{
student :: Enter_data( );
cout << "\t Enter the subject1 of the arts student: "; cin >> asub1 ;
cout << "\t Enter the subject2 of the arts student: "; cin >> asub2 ;
cout << "\t Enter the subject3 of the arts student: "; cin >> asub3 ;
}
void Display_data(void)
{
student :: Display_data( );
cout << "\n\t Subject1 of the arts student = " << asub1 ;
cout << "\n\t Subject2 of the arts student = " << asub2 ;
cout << "\n\t Subject3 of the arts student = " << asub3 ;
}
};
class commerce : public student
{
private: char csub1[len], csub2[len], csub3[len] ;
public:
void Enter_data(void)
{
student :: Enter_data( );
cout << "\t Enter the subject1 of the commerce student: ";
cin >> csub1;
cout << "\t Enter the subject2 of the commerce student: ";
cin >> csub2 ;
cout << "\t Enter the subject3 of the commerce student: ";
cin >> csub3 ;
}
void Display_data(void)
{
student :: Display_data( );
cout << "\n\t Subject1 of the commerce student = " << csub1 ;
cout << "\n\t Subject2 of the commerce student = " << csub2 ;
cout << "\n\t Subject3 of the commerce student = " << csub3 ;
}
};

void main(void)
{
arts a ;
cout << "\n Entering details of the arts student\n" ;
a.Enter_data( );
cout << "\n Displaying the details of the arts student\n" ;
a.Display_data( );
science s ;
cout << "\n\n Entering details of the science student\n" ;
s.Enter_data( );
cout << "\n Displaying the details of the science student\n" ;
s.Display_data( );
commerce c ;
cout << "\n\n Entering details of the commerce student\n" ;
c.Enter_data( );
cout << "\n Displaying the details of the commerce student\n";
c.Display_data( );
}

Multiple Inheritance

When a class is inherited from more than one base class, it is known as multiple inheritance.
The syntax for defining a subclass, which is inheriting more than one classes is:
class Subclass : access_specifier Baseclass1,
access_specifier Baseclass2, ………
…….. access_specifier Baseclass_n
{
members of the derived class ;
};
The following figure illustrates the use of multiple inheritance.


In the above figure, Circle and Rectangle are two base classes from which the class Cylinder is being inherited.

The data members of both the base classes are declared in protected mode. Thus, the class Cylinder can access the data member radius of class Circle and data member length, breadth of the class Rectangle, but the objects of the class Cylinder cannot access these protected data members.

The volume of the cylinder is equal to 22/7*(radius*radius*length). Thus, instead of defining these data again, they can be inherited from the base classes Circle and Rectangle ( radius from class Circle and length from class Rectangle ).

Example:

#include
class Circle // First base class
{
protected:
float radius ;
public:
void Enter_r(void)
{
cout << "\n\t Enter the radius: "; cin >> radius ;
}
void Display_ca(void)
{
cout << "\t The area = " << (22/7 * radius*radius) ;
}
};
class Rectangle // Second base class
{
protected:
float length, breadth ;
public:
void Enter_lb(void)
{
cout << "\t Enter the length : "; cin >> length ;
cout << “\t Enter the breadth : ” ; cin >> breadth ;
}
void Display_ar(void)
{
cout << "\t The area = " << (length * breadth);
}
};
class Cylinder : public Circle, public Rectangle // Derived class, inherited
{ // from classes Circle & Rectangle
public:
void volume_cy(void)
{
cout << "\t The volume of the cylinder is: "
<< (22/7* radius*radius*length) ;
}
};
void main(void)
{
Circle c ;
cout << "\n Getting the radius of the circle\n" ;
c.Enter_r( );
c.Display_ca( );
Rectangle r ;
cout << "\n\n Getting the length and breadth of the rectangle\n\n";
r.Enter_l( );
r.Enter_b( );
r.Display_ar( );
Cylinder cy ; // Object cy of the class cylinder which can access all the
// public members of the class circle as well as of the class rectangle
cout << "\n\n Getting the height and radius of the cylinder\n";
cy.Enter_r( );
cy.Enter_lb( );
cy.volume_cy( );
}

Multilevel Inheritance:

It has been discussed so far that a class can be derived from a class.

C++ also provides the facility of multilevel inheritance, according to which the derived class can also be derived by an another class, which in turn can further be inherited by another and so on.

The following figure will illustrate the meaning of the multilevel inheritance.


In the above figure, class B represents the base class. The class D1 that is called first level of inheritance, inherits the class B. The derived class D1 is further inherited by the class D2, which is called second level of inheritance.

Example: Multilevel Inheritance

#include
class Base
{
protected:
int b;
public:
void EnterData( )
{
cout << "\n Enter the value of b: ";
cin >> b;
}
void DisplayData( )
{
cout << "\n b = " << b;
}
};
class Derive1 : public Base
{
protected:
int d1;
public:
void EnterData( )
{
Base:: EnterData( );
cout << "\n Enter the value of d1: ";
cin >> d1;
}
void DisplayData( )
{
Base::DisplayData();
cout << "\n d1 = " << d1;
}
};
class Derive2 : public Derive1
{
private:
int d2;
public:
void EnterData( )
{
Derive1::EnterData( );
cout << "\n Enter the value of d2: ";
cin >> d2;
}
void DisplayData( )
{
Derive1::DisplayData( );
cout << "\n d2 = " << d2;
}
};
int main( )
{
Derive2 objd2;
objd2.EnterData( );
objd2.DisplayData( );
return 0;
}

DOCUMENTATION

Documentation and Importance of Documentation

Documentation is one of the system which is used to communicate, instruct and record the information for any reference or operational purpose. They are very useful for representing the formal flow of the present system. With the help of documentation it is very easy to track the flow of the system's progress and they working of the system can be expalined very easily.

It helps to provide the clear description of the work done so far. It is essential that the documents prepared must be updated on regular basis this will help to trace the progress of work easily. With appropriate and good documentation it is very easy to understand the how aspects of the system will work for the company where the system is to installed. It is also help to understand the type of data which will be inputted in the system and how the output can be produced.

After the system is installed, and if in case the system is not working properly it will be very easy for the administrator to understand the flow of data in the system with documentation which will help him/ her to correct the flaws and get the system working in no time.

Uses of Documentation

• It facilitates effective communication regarding the system between the technical and the non technical users.
• It is very useful in training new users. With a Good documentation new users can easily get acquainted with the flow of the systems.
• Documentation also helps the users to solve problems like trouble shooting even a non technical user can fix the problems.
• It plays a significant role in evaluation process.
• It not only helps to exercise a better control over the internal working of the firm, but it also external as well especially during audit.
• Documentations can help the manager to take better financial decisions of the organization.

Characteristics

What the characteristics of good system documentation are is difficult to decide. Some desirable characteristics are described below:

Created for intended audience

The documentation should be created for the intended audience. While it may be appropriate for a "Management overview" to be created for non-technical people, most system documentation will be used by System Administrators and other technical people as an important reference. System documentation should provide sufficient technical detail.

Specific

The system documentation should describe the specific implementation of a given system rather than provide generic documentation.

Relationship with other documentation

System documentation should be reasonably self contained; however it will often be a component of a wider collection of documentation and it is reasonable for it to reference other documents. There is little value in duplicating information from Vendor's manuals.

Up to date

The documentation needs to be up to date, but does not necessarily have to be recent. If the system has remained completely unchanged for a long period of time, the documentation can remain unchanged for the same period of time. It is important that when systems are changed documentation is updated to reflect the changes and this should be part of any change control procedures.

Sufficiently comprehensive

Documentation needs to be sufficiently comprehensive to for fill its purpose.

Accessible

The documentation must be held in a location and format that makes it accessible. It is obviously unacceptable to have the only copy of a system's documentation held on a drive that has failed or on the system itself should it fail.
It is very desirable to hold the documentation in a universal standard format that does not require access to a particular word processor; ASCII text may be most suitable.

Secure

Because system documentation could be useful to troublemakers, thought may need to be given to controlling access to the documentation.

Requirements

The question of what is the purpose of system documentation is difficult to answer. Below are some possible uses of system documentation.

Introduction / overview

System documentation can provide an introduction and overview of systems. New Administrators, contractors and other staff may need to familiarise themselves with a system; the first thing that will be requested is any system documentation. To avoid staff having to waste time discovering the purpose of a system, how it is configured etc system documentation should provide an Introduction.

Disaster Recovery

Many systems are supported by disaster recovery arrangements, but even in such circumstances, the recovery can still fail. There may be a need to re-build a system from scratch at least to the point where a normal restore from backup can be done. To make a rebuild possible it will be necessary to have documentation that provides answers to the configuration choices. For example it is important to re-build the system with the correct size of file systems to avoid trying to restore data to a file system that has been made too small. In some circumstances certain parameters can be difficult to change at a later date. When rebuilding a system it may be important to configure networking with the original parameters both to avoid conflicts with other systems on the network and because these may be difficult to change subsequently.

OS or Application re-load

Even when a disaster has not occurred, there may be times when it is necessary to reload an Operating System or Application; this can either be as part of a major version upgrade or a drastic step necessary to solve problems. In such circumstances it is important to know how an OS or Application has been configured.

Trouble shooting aid

The benefits of good system documentation, when trouble shooting, are fairly obvious. A comprehensive description of how a system should be configured and should behave can be invaluable when configuration information has become corrupted, when services have failed, or components have failed.
Good system documentation will include a description of the physical hardware and its physical configuration, which can avoid the need to shutdown a system in order to examine items such as jumper settings.

Planning tool

When planning changes or upgrades it will be necessary to assess the impact of changes on existing systems. A good understanding of existing systems is necessary for assessing the impact of any changes and for this good system documentation is required.

Other

System documentation can be used for many purposes including Auditing, Inventory, Maintenance, etc. The documentation of individual systems forms an important component of the overall network documentation.

Automating the creation of system documentation

Most operating systems include tools to report important system information and often the output from such tools can be re-directed to a file; this provides a means of automating the creation of system documentation.
Many Administrators have neither the time nor inclination to produce System Documentation and given the importance of keeping such documentation current, automation of the creation of system documentation is very desirable.
There are limitations to the extent to which system documentation can be automated. The following cannot be documented automatically:

• Textual descriptions that Administrators may create.
• Hardware configuration items that cannot be detected through software (perhaps such as which slot on a bus a card occupies or how jumpers are set).
• Other items that cannot be detected through software such as serial numbers, the physical location of a system etc.

The documentation of items that cannot be documented automatically can be facilitated by such means as having standard template documents and creating such documentation when systems are first installed. Fortunately this kind of documentation is less susceptible to change and is often less critical. It may be useful to create a simple file in a standard location (perhaps root) on systems that contains "external" information such as serial numbers, asset numbers etc.
Most Operating Systems have tools for automating their deployment (e.g. unattend.txt for NT, JumpStart for Solaris, Kickstart for Redhat Linux etc). Although these tools are primarily intended for deploying large numbers of systems they can be used for individual systems. While the configuration scripts used in these tools are not very readable, they are in text form, and can be read by technical staff. Such scripts offer the great advantage that a system is documented in an unambiguous way that guarantees that the system can be rebuilt exactly the same way it was first built.
For most systems it should be possible to create a simple script (or batch file) that uses several system tools to report system information and out put the results to a file. The use of such tools together with simple print commands (e.g. echo "line of text") can readily produce a useful document. It should be possible to adapt such scripts to produce the documentation required in terms of content and level of detail etc.
If standard tools do not provide sufficient information, there are many third party tools and free tools that can be used, however the potential problems of using additional tools, rather than just "built-in" tools, has to be weighed against the advantages. Alternative scripting languages (such a Perl) may provide additional benefits.