FORM 2
THE PATENTS ACT, 1970 (39 of 1970) & THE PATENTS RULES, 2003
COMPLETE SPECIFICATION
(See section 10, rule 13)
1. Title of the invention: CENTRALIZED ADMINISTRATION, LOGGING AND
MONITORING REGISTERED PROCESSES IN A UNIX PLATFORM
2. Applicant(s)
NAME NATIONALITY ADDRESS
TATA CONSULTANCY Indian Nirmal Building, 9th Floor, Nariman
SERVICES LIMITED Point, Mumbai, Maharashtra 400021,
India
3. Preamble to the description
COMPLETE SPECIFICATION
The following specification particularly describes the invention and the manner in which it
is to be performed.

TECHNICAL FIELD
[0001] The present subject matter, in general, relates to monitoring processes in a UNIX platform and, in particular, relates to method(s) and system(s) for centrally administrating, logging and monitoring registered processes in a UNIX platform.
BACKGROUND
[0002] UNIX is a multi-tasking, multi-user virtual memory computer operating system widely used in servers, workstations, and mobile devices. UNIX is capable of multi-tasking for a plurality of users who utilize the UNIX platform and has a dynamic memory resource allocation feature, wherein virtual memory reserves can be utilized over and above the physical memory that is installed therein. UNIX has gained popularity among the scientific, engineering, and academic communities due to its multi-user and multi-tasking environment, flexibility and portability, electronic mail and networking capabilities, and the numerous programming and text processing and scientific utilities available. It has also gained widespread acceptance in government and business based industries.
[0003] In UNIX, various processes may be executed by a plurality of users. Usage of the UNIX platform by the users may pose demanding requirements for the execution of the processes running on the platform. Therefore, a constant monitoring across the UNIX platform may be required to obtain details pertaining to execution of the various processes, such as applications or scripts running on the system. For example, the platform may be monitored to check scalability, responsiveness and quality of service (QoS) requirements of the system.
SUMMARY
[0004] This summary is provided to introduce concepts related to administration, logging and monitoring of various registered processes, such as applications and scripts in the UNIX platform, and the concepts are further described below in the detailed description. This summary is not intended to identify essential features of the claimed subject matter nor is it intended for use in determining or limiting the scope of the claimed subject matter.
[0005] In one implementation, the present subject matter relates to a computer implemented method for centrally administrating, logging and monitoring registered processes on a UNIX

platform. The registered processes may be applications or scripts running on the UNIX platform. The method includes monitoring the registered processes running on the UNIX platform in realtime. At least one of the user interaction information and errors encountered during execution of the registered processes are logged. The user interaction information comprises at least one of a detail pertaining to the user interaction with the registered processes and messages displayed to users during an execution of the registered processes. The information pertaining to the at least one of the user interaction information and the errors is displayed to a user based on the user privilege and the access level.
BRIEF DESCRIPTION OF THE DRAWINGS
[0006] The detailed description is described with reference to the accompanying figures. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. The same numbers are used throughout the drawings to reference like features and components.
[0007] Fig. 1 illustrates a network environment implementing a Centralized Administration, Logging and Monitoring system, in accordance with an embodiment of the present subject matter.
[0008] Fig. 2(a) illustrates a Centralized Administration, Logging and Monitoring system for registered processes, such as applications or scripts in a UNIX platform, in accordance with an embodiment of the present subject matter.
[0009] Fig. 2(b) illustrates a Centralized Administration, Logging and Monitoring system for registered processes, such as applications or scripts in a UNIX platform, in detail, in accordance with an embodiment of the present subject matter.
[0010] Fig. 2(c) illustrates a framework metadata management module of the Centralized Administration, Logging and Monitoring system, in detail, in accordance with an embodiment of the present subject matter.
[0011] Fig. 3 illustrates a method for Centralized Administration, Logging and Monitoring of registered processes, such as applications or scripts in a UNIX platform, in accordance with an embodiment of the present subject matter.
DETAILED DESCRIPTION

[0012] System(s) and method(s) for centralized administration, logging and monitoring of various registered processes, such as applications or scripts in UNIX platform are provided. The system(s) and method(s) can be implemented in a variety of computing devices, such as laptops, desktops, workstations, tablet-PCs, notebooks, portable computers, tablet computers, internet appliances, and similar systems. However, a person skilled in the art will comprehend that the embodiments of the present subject matter are not limited to any particular computing system, architecture or application device, as they may be adapted to take advantage of new computing systems and platforms as they become available.
[0013] UNICS (Uniplexed information computing system), or UNIX as it is generally known, is a multi-user and a multitasking operating system that is capable of operating on a wide variety of systems. Conventional organizations or enterprises utilize UNIX to run their processes, such as applications and scripts, and manage various facets of their business or enterprise. Furthermore, multiple users involved in the organization can work on the UNIX platform simultaneously. In order to protect certain data, or information from other users on the system, users can be assigned different roles, privileges and access levels associated with different tiers of information within the system. For example, an administrator may have different privileges and access levels than an auditor.
[0014] The UNIX platform, being a multitasking operating system, has the ability to facilitate the execution of multiple processes by multiple users simultaneously. The multitasking aspect, in combination with being a multi-user system allows more than one user to be logged on at the same time to use the UNIX system to execute the various processes therein. Furthermore, each of the processes are generally individually monitored within the platform, and errors that are encountered during the execution thereof, are usually required to be logged and stored with regard to each of the processes. Since individual processes generally utilize data handling methods in a nuclear manner, i.e., independent of the other processes, the errors generated during the execution of said processes are individually managed, which can be time and resource intensive. Furthermore, transition of data or information between processes that need to communicate with each other in the UNIX platform also becomes difficult, thereby requiring one or more intermediary stages of data transformation. In other words, there is lack of standardization in terms of the methods for handling the user information and errors encountered

during the execution of the processes, and methods for tracking the progress of execution of the various processes.
[0015] Further, as mentioned above, administration of usage and authorization of the processes running on the UNIX platform may be done in a nuclear manner. This may lead to missing licenses for authorization to use the processes and subsequently a loss in revenue. Moreover, as restrictions on the usage of the processes may not be properly administrated, the usage of the processes is prone to security lapses.
[0016] Furthermore, the processes running on the UNIX platform may be accessed and used on a global level by the users in different geographic locations. However, generally the user information and the errors encountered during the execution of different processes are displayed in a common language. This may lead to inconvenience for the users who may not be familiar with the common language chosen for displaying the user information and the errors. It may also cause time loss if the users need to translate it to a language they are familiar with.
[0017] Moreover, the users working on the UNIX platform may have different roles assigned to them in the system, e.g., functional, technical, administrator, developer, etc. Logs pertaining to the processes, such as applications and scripts may be accessed by the users performing different roles, as mentioned above. A user may have to scan the entire log to trace out the errors for investigation. Therefore, substantially more time is consumed in obtaining the relevant information required, and subsequently, there is a substantial increase in time spent in resolving the errors encountered.
[0018] Moreover, the user information and errors logged in the system may be archived to optimize storage and memory usage. The archived user information and errors may be retrieved on demand of the user. Fetching data from the processes, such as applications and scripts for archiving or retrieval becomes difficult as different processes may have their own set of standards for storing and archiving the data. Therefore, historical data concerning different processes may not be conveniently accessible, and auditing may prove to be a challenge. Further, improper archiving may lead to improper utilization of storage space and information loss. Furthermore, due to the historical data being inaccessible, debugging of the errors encountered during the execution of the processes may not be possible.

[0019] According to the present subject matter, a system with error management and user information management functionalities, and a centralized administration, logging and monitoring framework, hereinafter referred to as CALM framework, for various registered processes, such as applications or scripts in a UNIX platform is provided. The processes and users may need to be registered with the CALM framework to utilize the features and functionalities offered by the CALM framework. Therefore the CALM framework may administrate, log and manage those processes which may be registered. Further, the registration of the users and the processes can be used to ensure secure and licensed usage, and compliance to security standards.
[0020] Furthermore, the management of the user information and errors encountered during the execution of the registered processes includes a plurality of functions, such as logging, editing, displaying, etc. The system standardizes and manages the user information pertaining to the registered processes running on the UNIX platform. The user information may include user credential information and user interaction information. The user credential information may further include log-in details, such as a username and password, authorization details, access levels, privileges, and roles. Therefore, the user credential information may assist the system to identify one user from another. On the other hand, the user interaction information may include but is not limited to details pertaining to the user interaction with the registered processes including application execution information, script call information, etc., and messages displayed to the users during the execution of the registered processes.
[0021] In one implementation, the system may be configured to log or store the user interaction information. The system may further be configured to log the user interaction information in a single line or a stack form. The system is further configured to standardize the user information pertaining to the registered processes running on the UNIX platform.
[0022] In another implementation, the system may be configured to archive the logs pertaining to the user interaction information for optimum utilization of storage space available. The user interaction information logs may be archived after a predefined period of time. In another implementation, the system is further configured to retrieve the logs pertaining to the user interaction information from the archiving storage area on demand of a user.

[0023] In yet another implementation, the retrieved user interaction information may be displayed to the user depending on the access levels and the privileges of the user. If the user is not entitled to receive the user interaction information, the system may not display the user interaction information. Therefore, the access levels and privileges ensure confidentiality, licensed usage and compliance to security standards of the information stored in the system.
[0024] In one implementation, the system may be further configured to display the user interaction information in a single line or a stacked form. Therefore, a stack of the user interaction information may be shown to the user in a single instance. In another implementation, the system may be configured to log and display the user interaction information in multiple languages, thereby ensuring convenience to the users executing the registered processes from different geographic locations.
[0025] In one implementation, the system may be further configured to manage the errors encountered during the execution of the registered processes running on the UNIX platform. The system monitors the registered processes running on the UNIX platform in real-time, and can detect the errors encountered during the execution of the registered processes. Subsequently, the detected errors may be logged in the system for analysis or debugging. The system may further be configured to log the errors in a single line or a stack form.
[0026] Further, the system may be configured to archive the logs pertaining to the errors encountered during execution of the registered processes. Archiving ensures optimum utilization of the storage memory available. The system may be configured to archive the logs pertaining to the errors after a predefined period of time. In one example, the archiving of the error logs may be done in TAR or ZIP format.
[0027] The system is further configured to retrieve the logs pertaining to the errors on demand of a user. The system may display the errors in form of a report. However, the errors may be displayed to the user based on the access levels and privileges defined for the user. Therefore, if a user is not entitled to receive any data pertaining to the user information or the errors encountered, the information may not be displayed to the user by the system.
[0028] In one implementation, the system may be configured to display the errors encountered by the user in various forms, such as a single line form or a stack form. Therefore, a stack of the errors encountered during the execution of the registered processes may be shown to

the user in a single instance. The system is further configured to log and display the data pertaining to at least one of the user information and errors encountered in one or more selected languages thereby negating a separate translation requirement, and hence saving time.
[0029] In one implementation, the system is further configured to allow the users to view the information based on their roles, access levels, and privileges. The system ensures that the right information is displayed to the right user in a time efficient manner. The system is further configured to maintain a master file enlisting the user information and the errors encountered. In one implementation, multiple master files may be maintained. In one implementation, a collection of master files may be maintained. The master file may include codes, error messages, possible errors, user information messages, assigned levels of severity to the errors, steps needed to be taken in case of encountering an error, etc. Further, the master file may be available in the system in multiple languages.
[0030] As mentioned above, the system is configured to manage the user interaction information and the errors encountered during the execution of the registered processes. Further, the details pertaining to the user interaction information and the errors may be displayed to a user based on the user credential information.
[0031] These and other advantages of the present subject matter would be described in greater detail in conjunction with the following figures. While aspects of described system(s) and method(s) for centralized administration, logging and monitoring of the registered processes, such as applications and scripts in UNIX platform can be implemented in any number of different computing systems, environments, and/or configurations, the embodiments are described in the context of the following exemplary system(s).
[0032] Fig. 1 illustrates a network environment 100 implementing a Centralized Administration, Logging and Monitoring system 102 (hereinafter referred to as, CALM system 102), according to an embodiment of the present subject matter. In the network environment 100, the CALM system 102 is connected to a network 104. Furthermore, a database 106, and one or more client devices 108-1, 108-2...108-N, collectively referred to as client devices 108 and individually referred to as client device 108, are also connected to the network 104. In one implementation, the client device 108 may be used to run registered processes that are monitored by the CALM system 102. In another implementation, the client device 108 may be used to view

the logs pertaining to the execution of the registered processes. In yet another implementation, the client device 108 may be used for both purposes.
[0033] The CALM system 102 can be implemented as any set of computing devices connected to the network 104. For instance, the CALM system 102 may be implemented as workstations, personal computers, desktop computers, multiprocessor systems, laptops, network computers, minicomputers, servers, and the like. In addition, the CALM system 102 may include multiple servers to perform mirrored tasks for users.
[0034] Furthermore, the CALM system 102 can be connected to the client devices 108 through the network 104. Examples of the client devices 108 include, but are not limited to personal computers, desktop computers, smart phones, PDAs, and laptops. Communication links between the client devices 108 and the CALM system 102 are enabled through a desired form of connections, for example, via dial-up modem connections, cable links, digital subscriber lines (DSL), wireless or satellite links, or any other suitable form of communication.
[0035] Moreover, the network 104 may be a wireless network, a wired network, or a combination thereof. The network 104 can also be an individual network or a collection of many such individual networks interconnected with each other and functioning as a single large network, e.g., the internet or an intranet. The network 104 can be implemented as one of the different types of networks, such as intranet, local area network (LAN), wide area network (WAN), the internet, and such. The network 104 may either be a dedicated network or a shared network, which represents an association of the different types of networks that use a variety of protocols, for example, Hypertext Transfer Protocol (HTTP), Transmission Control Protocol/Internet Protocol (TCP/IP), etc., to communicate with each other. Further, the network 104 may include network devices, such as network switches, hubs, routers, host bus adapters (HBAs), for providing a link between the CALM system 102 and the client devices 108. The network devices within the network 104 may interact with the CALM system 102 and the client devices 108 through communication links.
[0036] In one implementation, the CALM system 102 may be configured for centralized administration, logging and monitoring of registered processes, such as applications and scripts running on the UNIX platform. The processes, such as applications or scripts, may need to be registered, hereinafter referred to as registered processes, to the CALM system 102 to utilize the

features and functionalities offered by the CALM system 102. In one implementation, the CALM system 102 includes a user interaction information module 110, an error management module 112, and a centralized administration module 114. In one implementation, the user interaction information module 110 may be configured to manage details pertaining to the interaction of the user with the registered processes running on the UNIX platform. In one implementation, the user interaction information module 110 may be configured to store the information pertaining to the user interaction within the CALM system 102. In another implementation, the user interaction information module 110 may be configured to store the information in an external data repository, such as the database 106.
[0037] In one implementation, the error management module 112 may be configured to monitor the registered processes running on the UNIX platform. The error management module 112 may be further configured to detect errors encountered during the execution of the registered processes. The error management module 112 may log the errors detected during the execution of the registered processes. In one implementation, the error management module 112 may be configured to store the errors within the CALM system 102. In another implementation, the error management module 112 may be configured to store the errors in an external data repository, such as the database 106. The errors and associated information can be accessible via the client devices 108.
[0038] In one implementation, the centralized administration module 114 may be configured to register the users and processes, such as applications or scripts, to utilize the features offered by the CALM system 102 and to ensure secure and licensed usage and compliance to security standards. In one implementation, the centralized administration module 114 may further be configured to define access and privilege levels for different users. In this manner, confidentiality and security concerns of different users working on the UNIX platform can be facilitated. The operations of the CALM system 102 are described in further detail with reference to figures 2(a), 2(b), and 2(c) below.
[0039] Fig. 2(a) illustrates the CALM system 102, in accordance with an embodiment of the present subject matter. In said embodiment, the CALM system 102 includes one or more processor(s) 202, interface(s) 204, and a memory 206 coupled to the processor 202. The processor 202 can be a single processing unit or a number of units, all of which could also

include multiple computing units. The processor 202 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, and/or any devices that manipulate signals based on operational instructions. Among other capabilities, the processor 202 is configured to fetch and execute computer-readable instructions and data stored in the memory 206.
[0040] The interfaces 204 may include a variety of software and hardware interfaces, for example, interface for peripheral device(s), such as a keyboard, a mouse, an external memory, and a printer. Further, the interfaces 204 may enable the CALM system 102 to communicate with other computing devices, such as web servers and external data repositories, such as the database 106, in the network environment 100. The interfaces 204 may facilitate multiple communications within a wide variety of protocols and networks, such as a network, including wired networks, e.g., LAN, cable, etc., and wireless networks, e.g., WLAN, cellular, satellite, etc. The interfaces 204 may include one or more ports for connecting the CALM system 102 to a number of computing devices.
[0041] The memory 206 may include any computer-readable medium known in the art including, for example, volatile memory, such as static random access memory (SRAM) and dynamic random access memory (DRAM), and/or non-volatile memory, such as read only memory (ROM), erasable programmable ROM, flash memories, hard disks, optical disks, and magnetic tapes. The memory 206 also includes module(s) 208 and data 210.
[0042] The module(s) 208 include routines, programs, objects, components, data structures, etc., which perform particular tasks or implement particular abstract data types. In one implementation, the module(s) 208 includes the user interaction information module 110, the error management module 112, the centralized administration module 114, and other module(s) 214. The other module(s) 214 may include programs or coded instructions that supplement applications and functions of the CALM system 102.
[0043] On the other hand, the data 210, inter alia serves as a repository for storing data processed, received, and generated by one or more of the module(s) 208. The data 210 includes for example, a user interaction information data 216, an error management data 218, a CALM framework metadata 220, and other data 222. The other data 222 includes data generated as a result of the execution of one or more modules in the module(s) 208.

[0044] In one implementation, the CALM system 102 may be configured to centrally administrate, log and monitor the registered processes in a UNIX platform. In one implementation, the user interaction information module 110 may be configured to manage the user interaction information pertaining to the registered processes. The user interaction information may include but is not limited to details pertaining to the user interaction with the registered processes (application execution information, script call information, etc.), messages displayed to users during the execution, etc. In one example, the user interaction information module 110 may be configured to store the user interaction information in a main storage area. The user interaction information module 110 may be configured to log or store the user interaction information in a single line or a stack form. In one implementation, the user interaction information may be moved from the main storage area to an archive storage area depending on a predefined time period. Furthermore, in an example, the archived user interaction information may be stored in the user interaction information data 216 in TAR or ZIP format.
[0045] In one implementation the user interaction information module 110 may be further configured to log the user interaction information in multiple languages thereby enabling convenience to the users who may be from different geographical locations and having varied language preferences, thereby saving on external or manual translation. This information, for example, can be displayed via a display module on one of the client devices 108, which are networked to the CALM system 102.
[0046] Furthermore, during the operation of the CALM system 102, one or more of the registered processes, such as application and scripts may be executed by the users. In one implementation, the error management module 112 may be configured to manage errors encountered, for example, during the execution of the registered processes running on the UNIX platform. The management, for example, may include monitoring the registered processes using the UNIX platform in real-time, and detecting the errors encountered during the execution of the registered processes. Furthermore, the error management module 112 may be configured to log or store the errors for future reference and accessibility. The error management module 112 may be configured to log or store the errors in a single line or a stack form. In one implementation, the errors may also be stored in a data repository, such as the database 106 or a main storage area, and then may be moved to an archive storage area based on a predefined period of time. In an example, the errors may be archived in TAR or ZIP format.

[0047] In one implementation, the centralized administration module 114 is configured to centrally administrate and manage the users and the registered processes using the UNIX platform. The centralized administration module 114 may be configured to manage the user credential information pertaining to the registered processes. The user credential information may be in the form of metadata, and may include but is not limited to login details, such as a username and password, authorization details, access levels, privileges and roles. Further, the centralized administration module 114 may register the users and processes involved with the CALM system 102 to ensure secure and licensed usage, and compliance to security standards. Furthermore, in one example, the centralized administration module 114 may be configured to store information concerning centralized administration in the CALM framework metadata 220.
[0048] As described earlier, in order to view particular data, a user may forward a user request, via one of the client devices 108. In one implementation, the centralized administration module 114 may be configured to receive the user request. The centralized administration module 114 may further be configured to authorize the user based on the user request, in order to view the data pertaining to the user interaction information, and the errors based on their roles, privileges and access levels. On receiving the user request, the centralized administration module 114 may be configured to authorize the user for accessing the data stored in the CALM system 102. Authorization may include, checking license, verifying user credentials, roles, access levels, privileges, etc. Based on these authorization parameters, the centralized administration module 114 may display the requested details on demand of the user. The centralized administration module 114 is further configured to maintain a master file enlisting various details pertaining to the user information and errors associated with the execution of the registered processes. In one implementation, multiple master files may be maintained enlisting various details pertaining to the execution of the registered processes.
[0049] Therefore, during operation, the centralized administration module 114, based on a successful authorization, may be configured to forward the requested information to the user. Furthermore, based on a user preference, the data may be provided in one or more languages. Moreover, the centralized administration module 114 can be further configured to display the data in single line or stacked form based on a user preference. The multi-lingual capabilities as well as error display form functionality of the CALM system 102 ensures easy accessibility as well as readability for a multitude of users across various geographical locations and with varied

language capabilities. The functionalities of the centralized administration module 114 may be performed by various sub-modules which are explained at a later stage.
[0050] Fig. 2(b) illustrates the Centralized Administration, Logging and Monitoring (CALM) system 102, in more detail. Various modules in addition to along with the user interaction information module 110, the error management module 112, and the centralized administration module 114 have been introduced in fig. 2(b) for providing better clarity about the CALM system 102. Further, the flow arrows in the figure are shown to as to an example to illustrate a flow of events that occur during the functioning of the CALM system 102 and should not be viewed as limiting.
[0051] In a UNIX platform, different types of scripts may be executed, such as a user initiated script (1), a user initiated scheduled batch script (2), and a user initiated continuous batch script (3). Further, in one implementation, there may be parallel scripts executing on the UNIX platform. In another embodiment, at least one of the abovementioned scripts may further invoke a child subscript in the UNIX platform. Child scripts, for example, may be a script invoked by a script being executed. Furthermore, child scripts themselves may further invoke child scripts and various possible combinations of the mentioned scripts may be executed in the UNIX platform.
[0052] In the UNIX platform, different processes, such as applications and scripts have different ways of managing and displaying the user interaction information and the errors encountered during the execution. For example, for different processes, a message displaying the information about the errors encountered may be displayed in quotes, brackets or both. The CALM system 102 standardizes the method of handling the user information and the errors encountered during the execution of the registered processes. Further, for standardizing the handling of user information and the errors encountered, the user interaction information module 110 and the error management module 112 may be provided in the CALM system 102.
[0053] Further, the errors encountered during the execution of the registered processes running on the UNIX platform may have different levels of importance, for example, depending on a severity of the errors. The error management module 112 may be configured to define the severity of the errors encountered during the execution and depending on their importance remedial measures can be taken by a user using the CALM system 102. In an example, the

various levels may include, but are not limited to low, medium, high, critical, etc. Critical errors may be those errors, which pose such a level of criticality that requires the immediate attention of the administrator or authorized personnel as soon as they occur, in order for the execution of the registered processes to continue. Ignoring this error may result in the loss of stability of the concerned registered processes running on the UNIX platform. In an example, in such a situation, the CALM system 102 may generate a message asking to abort the registered process and/or providing remedial steps to resolve the error, for example, via interactive messages. These messages may be displayed in multiple languages.
[0054] Further, the CALM system 102 may also be configured to generate a call acknowledgement as soon as it receives a user request, confirming the initiation of the execution of the registered processes requested by the user. In one implementation, the call acknowledgement functionality for the user interaction information and the errors may be performed by the user interaction information module 110 and the error management module 112, respectively.
[0055] In one implementation, the CALM system 102 may be configured to provide a framework response assistance for the errors encountered by the users during the execution of the registered processes based on the severity of the errors. The CALM system 102 may proceed with the necessary steps for resolving the error without any user initiation. For example, if the severity of the error is critical, the framework may abort the registered process automatically and display a message to the user mentioning the error encountered. In another example, if the severity of the error is low, the CALM system 102 may display a message to the user mentioning the severity of the error and provide steps to resolve the error. In one implementation, the framework response assistance functionality for the user interaction information and the errors may be performed by the user interaction information module 110 and the error management module 112, respectively.
[0056] In one implementation, at least one of the user interaction information module 110 and the error management module 112 may be configured to interact with the CALM framework metadata 220. The CALM framework metadata 220 may further include user login and password credentials, user defined information and error codes, multilingual user information and error messages, roles and privileges for user, application or script registration information and

framework, application or script configurations and processes. This is explained in detail later with reference to Fig. 2(c).
[0057] Further, the user interaction information and the errors encountered may be logged in the CALM system 102. A log management engine 230 may be configured to log the user interaction information and the errors encountered into a log files storage area 232. The log management engine 230 may be configured to log or store the user interaction information and the errors in a single line or a stack form. The log management engine 230 may be configured to provide an intelligent management of the interactions of at least one of the user interaction information module 110 and the error management module 112 with the log files storage area 232. In one example, the log files storage area 232 may be referred to as the main storage area, as mentioned in the description of fig. 2(a).
[0058] In yet another implementation, the log files storage area 232 may include a script log file stack and a framework log file stack. The user interaction information and the errors encountered during the execution of the registered processes may be logged in the log files storage area 232. In one example, each process may have its own log file maintained in the script log file stack. For example, there may be n number of log files for n number of scripts in the script log file stack. In another example, a new log file may be created for each execution of the registered process. In one implementation, the CALM system 102 may be configured to limit the size of the log file maintained in the script log file stack. For example, a threshold memory of 1 MB for each log file may be fixed. Therefore, as soon as the log file exceeds this threshold, a new log file may be created for the process. Therefore, the log files may be managed in an efficient manner.
[0059] Further, during the execution of a registered process by the user, the registered process may invoke a plurality of functions of the CALM system 102. The plurality of the functions invoked by the registered process may be logged in the framework log file stack. For example, information concerning the logging of particular information by the registered process at a particular time may be extracted from the framework log file stack. In one example, the CALM framework may log the information in the framework log file stack on a daily basis. Therefore, the framework log file stack includes the log files related to the usage of the CALM system 102 by the registered processes.

[0060] In one implementation, an archive creation and maintenance module 234 may be configured to archive the log files available in the log files storage area 232 in an archive storage area 236. The archive storage area 236 may further include a script file log stack and a framework log file stack. The functionalities of the script file log stack and the framework log file stack remains same as mentioned above for the log files storage area 232.
[0061] In another implementation, a log enrichment and refactoring module 238 may be configured to extract data from the log files storage area 232 or from the archive storage area 236, based on demand of a user. Further, data may be extracted from the archive storage area 236 by an archive extraction module 228 before providing the data to the log enrichment and refactoring module 238. As will be appreciated by a person skilled in the art, the log files may not be in a format presentable to a user. The log enrichment and refactoring module 238 may process the log files into a format understandable by the user. Therefore, the log enrichment and refactoring module 238 may be configured to enrich and re-factor the information requested by the user, for example, from log files to a form presentable to the user.
[0062] In yet another implementation, the centralized administration module 114 may be further configured to provide an interface to the users to interact with the CALM system 102. In one example, this interface may be provided in the form of a web and graphical user interface. The centralized administration module 114 may further include an on demand log display module 240 and a framework metadata management module 242. The on demand log display module 240 and the framework metadata management module 242 may work in conjunction with each other. The on demand log display module 240 may be configured to display data to the users in real time. The data requested may be displayed to the users depending on their roles, access levels and privileges configured by the framework metadata management module 242. Different user may be assigned different roles in the CALM system 102, e.g., administrator, technical support, functional support, developer, etc. Depending on their role, they may be assigned different access levels and privileges. Therefore, the framework metadata management 242 may authorizes the user for viewing information, thereby ensuring right information to the right user in a time efficient manner.
[0063] In one implementation, the framework metadata management module 242 may further be configured to manage the CALM framework metadata 220 mentioned earlier. The

interaction between the framework metadata management module 242 and the CALM framework metadata 220 is explained in detail at a later stage. Further, the functionalities of the on demand log display module 240 and the framework metadata management module 242 may be performed by the centralized administration module 114, as mentioned in fig. 2(a).
[0064] Fig. 2(c) illustrates the framework metadata management module 242 of the Centralized Administration, Logging and Monitoring (CALM) system 102, in more detail. There are various sub-modules of the framework metadata management module 242 introduced in fig.2 (c) for providing better clarity about the CALM system 102.
[0065] The framework metadata management module 242 may include a user log-in credential module 244, a user role module 246, a master file module 248, a multi-lingual master file module 250, a process registration module 252 and, a process configuration module 254. The user log-in credential module 244 may be configured to manage user login and password credentials for users registered with the CALM system 102. Further, the users working on the UNIX platform may have different roles assigned to them in the CALM system 102, e.g., functional, technical, administrator, developer, etc. The user role module 246 may be configured to define the roles and privileges of the users registered with the CALM system 102. Therefore, the logs may be accessed by the different users performing different roles based on their access levels and privileges, as mentioned above.
[0066] Further, the master file module 248 may be configured to maintain a master file enlisting all the user information and the errors encountered and information concerning the same. In one example, the master file may include codes, error messages, user information messages, assigned levels of severity to the errors, steps needed to be taken in case of encountering an error, etc. In another implementation, there may be a collection of master files maintained enlisting various details concerning the user information and errors encountered during the execution of the registered processes using the UNIX platform. Furthermore, the multi-lingual master file module 250 may be configured to maintain the master file in multiple languages. An example of the master file is provided below as Table 1.
TABLE 1: Example of Master File

Info/Error Code Priority Target User Framework Response Information/Error Message Corrective Action/Hint/Suggestion
UI 123456 IF/S T/F/D/A/C Y/N Do you want to continue? Not applicable
E 456789 S/C/H/M/L T/F/D/A/C Y/N Network path not found! Contact network administrator to fix issue and restart scripts or applications.
[0067] In the table 1 shown above, the abbreviations are defined below
UI- User Information
E- Errors encountered.
IF- Information.
S- System Level Information/Error
C- Critical
H- High
M- Medium
L- Low
T- Technical User
F- Functional User
D- Developer User
A- Administrator User
C- CALM Framework Management User
[0068] Further, as mentioned above, in one implementation, the master file may be available
in multiple languages. This master sheet is provided as an example for illustration and should not
be viewed as limiting.
[0069] In another implementation, the process registration module 252 may be configured for managing the registration of the processes running on the CALM system 102 for ensuring the licensed usage, secure and optimum utilization. Further, the process configuration module 254 may assist in configuring the registered processes with the CALM system 102. In one example, the framework metadata management module 242 may also track the registered processes.

[0070] In one implementation, the framework metadata management module 242 may interact with the CALM framework metadata 220. The CALM framework metadata 220 may include user login and password credentials, user defined information and error codes, multilingual user information and error messages, roles and privileges for user, application or script registration information and framework, application or script configurations and processes. Further, the CALM framework metadata 220 may be further categorized in sub-data, such as a user log-in credential data 256, a users role data 258, a master file data 260, a multi-lingual master file data 262, a process registration data 264, and a process configuration data 266. The information concerning the user log-in credential, such as log-in ID and password may be stored in the user log-in credential data 256. In one implementation, the details pertaining to the roles and privileges assigned to various users may be stored in users role data 258. Further, the details pertaining to the collection of master files may be stored in the master file data 260. Furthermore, details pertaining to collection of master files in multiple languages may be stored in the multilingual master file data 262. Similarly, the information corresponding to the registration of the registered processes may be stored in the process registration data 264. Further, the information corresponding to the configuration of the registered processes may be stored in the process configuration data 266.
[0071] Fig. 3 illustrates a method 300 for centrally monitoring, administrating, logging and displaying user information and errors pertaining to the registered processes running on a UNIX platform, according to one embodiment of the present subject matter. The method 300 may be implemented in a variety of computing systems in several different ways. For example, the method 300, described herein, may be implemented using a Centralized Administration, Logging and Monitoring system 102, as described above.
[0072] The method 300, completely or partially, may be described in the general context of computer executable instructions. Generally, computer executable instructions can include routines, programs, objects, components, data structures, procedures, modules, functions, etc., that perform particular functions or implement particular abstract data types. A person skilled in the art will readily recognize that steps of the method can be performed by programmed computers. Herein, some embodiments are also intended to cover program storage devices, e.g., digital data storage media, which are machine or computer readable and encode machine-

executable or computer-executable programs of instructions, wherein said instructions perform some or all of the steps of the described method 300.
[0073] The order in which the method 300 is described is not intended to be construed as a limitation, and any number of the described method blocks can be combined in any order to implement the method, or an alternative method. Additionally, individual blocks may be deleted from the method without departing from the spirit and scope of the subject matter described herein. Furthermore, the methods can be implemented in any suitable hardware, software, firmware, or combination thereof. It will be understood that even though the method 300 is described with reference to the centralized administration, logging and monitoring system 102, the description may be extended to other systems as well.
[0074] Various processes, such as applications and scripts may need to be registered with the CALM system 102 to utilize the features and functionalities offered by the CALM system 102. Therefore the CALM system 102 may administrate, log and manage those processes which may be registered. Further, registered processes may be executed by users using the UNIX platform. In one example, the users may utilize the web interface as disclosed above, to execute one or more of the processes based on their roles.
[0075] At block 302, the CALM system 102 may monitor the registered processes running on the UNIX platform, in real time. Accordingly, user interaction information pertaining to the registered processes may be monitored. The user interaction information may include but is not limited to details pertaining to the user interaction with the registered processes, such as applications or scripts (application execution information, script call information, etc.), messages displayed to the users during the execution. In an example, the user interaction information module 110 of the CALM system 102 may be configured to monitor said user interaction information, as described earlier. At block 304, errors encountered during the execution of the registered processes may be detected while the registered processes are being monitored. In an example, an error management module 112 of the CALM system 102 may be configured to monitor and detect errors encountered during execution of the registered processes, in real-time, as described earlier.
[0076] At block 306, the user interaction information and the errors encountered may be logged. The user interaction information and the errors encountered may be logged in a single

line or a stack form. In one implementation, the user interaction information and the errors may be logged in a log files storage area. In an example, the user interaction information module 110 of the CALM system 102 may be configured to log the user interaction information pertaining to the registered processes. In another example, the error management module 112 of the CALM system 102 may be configured to log the errors encountered during execution of the registered processes, as described earlier. The user interaction information and the errors encountered during the execution of the registered processes may be moved from the log files storage area to the archiving storage area after a predefined period of time.
[0077] At block 308, a user request may be received from one of the plurality of users, for example, via the client devices 108, in order to gain access and view the data pertaining to the user interaction information and errors encountered during the execution of the registered processes stored in the form of log files. In an example, a centralized administration module 114 of the CALM system 102 may be configured to receive the user request from one of the users, as described earlier.
[0078] At block 310, the user request may be authorized based on one or more of the user credential information. For example, the authorization may require the user to verify oneself by inputting a username and password, which is linked in turn to the configured user access levels and privileges. In one example, a user can access and edit his or her user information, for example, via a client device 108. A user friendly graphical web interface can be provided on the client devices 108 via which the user can securely and efficiently gain access, for example, based on the authorization details, access levels, privileges, etc. For example, a system administrator may be granted rights and privileges to access and modify user information pertaining to all the users. However, a single user may be configured with access levels and privileges only to access his user information, and not that of another user. In one example, the centralized administration module 114 of the CALM system 102 may be configured to authorize the user request as described in fig. 2(b).
[0079] At block 312, based on the authorization, the data pertaining to at least one of the user interaction information and the errors encountered may be forwarded to the user, for example, via the web interface. The data may be displayed to the user in the form of single line information or in stack form. Furthermore on demand of the user, or customization, the at least

one of the user interaction information and errors encountered may be displayed to the user in a multitude of languages. This ensures language compatibility for users in varied geographical locations, as well as users with different language capabilities. In an example, the centralized administration module 114 of the CALM system 102 may be configured to forward the information to the user based on the authorization, as described earlier.
[0080] Although implementations of centralized monitoring, administrating, displaying and logging user interaction information and error for UNIX platform have been described in language specific to structural features and/or methods, it is to be understood that the present subject matter is not necessarily limited to the specific features or methods described. Rather, the specific features and methods are disclosed as implementations for centrally monitoring, administrating and displaying and logging user interaction information and error for UNIX platform.

I/We claim:
1. A computer implemented method for centrally administrating, logging and monitoring
registered processes running on a UNIX platform, the method comprising:
monitoring, in real-time, the registered processes running on the UNIX platform;
logging at least one of a user interaction information and errors encountered during execution of the registered processes, wherein the user interaction information comprises at least one of a detail pertaining to the user interaction with the registered processes and messages displayed to users during execution of the registered processes; and
displaying information pertaining to the at least one of the user interaction information and the errors encountered during the execution to a user depending on user credential information.
2. The method as claimed in claim 1 further comprising:
detecting, in real-time, at least one error encountered during the execution of the plurality of registered processes; and
logging the at least one error in a main storage area.
3. The method as claimed in claim 2 further comprising:
transferring a log of at least one of the user interaction information and the at least one error encountered during the execution of the registered processes from the main storage area to an archive storage area based on a predefined period of time.
4. The method as claimed in claim 1, wherein the user credential information includes at least one of a login details, a username and password, authorization details, access levels and privileges.
5. The method as claimed in claim 1 further comprising:
receiving a user request from the user, in order to gain access to the information pertaining to at least one of the user interaction information and the errors; and
authorizing the user based on the user credential information.

6. The method as claimed in claim 1 further comprising:
enriching and re-factoring the information pertaining to the user interaction information and the errors based on a user request; and
displaying the information in a language selected by the user, and in one of a single line form and a stacked form.
7. A centralized administration, logging and monitoring (CALM) system (102) for a UNIX
platform, the CALM system (102) comprising:
a processor (202); and
a memory (206) coupled to the processor (202), the memory (206) comprising:
a user interaction information module (110) configured to manage user interaction information, wherein the user interaction information includes at least one of a detail pertaining to the user interaction with registered processes and messages displayed to users during execution of the registered processes;
an error management module (112) configured to log errors encountered during execution of at least one of a plurality of registered processes; and
a centralized administration module (114) configured to forward information pertaining to at least one of the user interaction information and errors to the user based on a user request.
8. The CALM system (102) as claimed in claim 7, wherein the centralized administration module (114) includes a framework metadata management module (242) configured to manage user credential information, wherein the user credential information includes at least one of a login details, authorization details, access levels and privileges.
9. The CALM system (102) as claimed in claim 7, wherein the user interaction information module (110) is further configured to log the user interaction information in a main storage area.
10. The CALM system (102) as claimed in claim 7, wherein the error management module (112) is further configured to:
monitor in real-time, the execution of the plurality of registered processes; and

detect the errors encountered during the monitoring.
11. The CALM system (102) as claimed in claim 10, wherein the error management module (112) is further configured to log the errors encountered in the execution of the plurality of the registered processes in a main storage area.
12. The CALM system (102) as claimed in claim 7 further comprising an archive creation and maintenance module (234) configured to archive the user interaction information and the errors encountered during the execution of the registered processes from a main storage area to an archive storage area (236) based on a predefined period of time.
13. The CALM system (102) as claimed in claim 7, wherein the centralized administration module (114) is further configured to:
receive the user request from the at least one user, in order to gain access to the information pertaining to at least one of the user interaction information and the errors; and
authorize the user based on the user credential information.
14. The CALM system (102) as claimed in claim 7, wherein the centralized administration
module (114) is configured to display information pertaining to at least one of the user
interaction information and the errors in one of a plurality of languages based on a user
preference.
15. The CALM system (102) as claimed in claim 7 further comprising a log enrichment and
refactoring module (238) further configured to:
enrich and re-factor the information pertaining to the user interaction information and the errors based on the user request; and
providing the information to the centralized administration module (114) for displaying the information in one of a plurality of languages, based on a user preference.
16. A computer-readable medium having embodied thereon a computer program for
executing a method comprising:
monitoring in real-time, the registered processes running on the UNIX platform;

logging at least one of a user interaction information and errors encountered during execution of the registered processes, wherein the user interaction information comprises at least one of a detail pertaining to the user interaction with the registered processes and messages displayed to users during execution of the registered processes; and
displaying information pertaining to at least one of the user interaction information and the errors to a user depending on user credential information.