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: METRICS DETERMINATION FOR APPLICATION PROCESSES IN
MAINFRAME ARCHITECTURE
2. Applicant(s)
NAME NATIONALITY ADDRESS
TATA CONSULTANCY Nirmal Building, 9th Floor, Nariman Point,
Indian
SERVICES LIMITED 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 relates, in general, to mainframe architecture and, in particular, to metrics determination for application processes in the mainframe architecture.
BACKGROUND
[0002] With the increasing business needs and data processing requirements, data centers equipped various computing systems, such as application servers, networking devices and storage devices, are deployed. Usually, large and complicated data centers run on mainframe architecture. In the mainframe architecture, multiple application processes or jobs are executed to achieve a desired result. The related application processes may be dependant on each other and work together.
[0003] The application processes may be monitored and metrics, such as processor time, downtime, and elapsed time, may be collected for various reasons, for example, to fix the problems that may arise during operation of a particular system or a software application, to ensure that the performance and execution of the application processes meet the service level agreements (SLA), and to optimize the execution of the application processes. However, determination of the metrics of the application processes is often a complex and a tedious task.
SUMMARY
[0004] This summary is provided to introduce concepts related to determination of metrics for application processes in a software application in mainframe architecture. These 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] Method(s) and a system(s) for determination of metrics for application processes in mainframe architecture are described herein. In one implementation, application processes that have been executed based on information gathered from a scheduler are identified. Further, for each of the identified application processes, corresponding application data is filtered to obtain metrics data. Based on the metrics data, one or more metrics corresponding to each of the identified application processes are determined.
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. 1a illustrates various components of monitoring metrics determination system, in accordance with an embodiment of the present subject matter.
[0008] Fig. 1b and Fig. 1c illustrate various screenshots pertaining to the present subject matter, in accordance with an embodiment of the present subject matter.
[0009] Fig. 2 illustrates a method for determining metrics for application processes in a mainframe architecture, in accordance with an implementation of the present subject matter.

DETAILED DESCRIPTION
[0010] Generally, organizations and institutions, such as financial institutions, that handle large volumes of data on a daily basis employ mainframe architecture having one or more mainframe computers to process the data. The mainframe architecture may implement various software applications, such as banking applications, for various functions. Each such software application may include one or more batches and each batch may include multiple jobs, to achieve a desired result. Further, there may be hundreds and hundreds of jobs that may be executed by a mainframe computer on a daily basis. The closely integrated jobs, also referred to as application processes, may work close together and may be dependent on each other. Further, in order to achieve a desired result, batch wise execution of the application processes may be done, i.e., a group of related application processes may be executed in series.
[0011] The application processes are often monitored and corresponding metrics are determined to evaluate performance of the mainframe systems, to identify erred application processes, or to maintain stability of the application processes. With a large number of application processes, it may be a time consuming and cumbersome task to obtain and determine metrics, such as status, processor time consumption, elapsed time, and downtime for an application process. The metrics help monitor the status and performance of the application processes. Generally, application process related information may be fetched manually for all the application processes. Further, the application process related information may require further manual processing to generate reports indicative of the metrics of the application processes. However, as the number of application processes increases, the manual monitoring of application processes, creation and maintenance of such manually generated report may become increasingly difficult, tedious, and prone to human error.

[0012] Further, in typical mainframe systems such information may be archived due to periodical house keeping of a database, such as job history subsystem (JHS). In such cases, manual restoration of erred application processes may be required for computation of the metrics. The manual restoration is often a challenging task and consumes considerable computational time and resources, thereby affecting the performance of the mainframe systems. Also, fetching information from the JHS is usually tedious since it involves manual identification of checkpoints corresponding to get information pertaining to the metrics. Further, calculating the metrics after fetching the information and repeating the same for each application process results in consumption of time and manual efforts. Additionally, computation of the metrics for an application process that may be executed multiple times in a batch may be complex.
[0013] According to an embodiment of the present subject matter, methods and systems for monitoring application processes in a mainframe architecture are described herein. In an implementation, the application processes that have been executed are identified based on information obtained from a scheduler. For example, the scheduler may determine whether a batch has been executed. In said example, a last application process of the batch may trigger the metrics determination process. The application processes constituting the batch may be understood to have completed execution and metrics for these applications may be identified. Further, application data pertaining to each of the identified applications may be obtained. The application data may include details pertaining to a corresponding application process. However, the application data may be in an unorganized format.
[0014] Further, the application data corresponding to each of the identified application processes may be filtered to obtain metrics data. The metrics data include information that may be required to compute metrics corresponding to an application process. Examples of the metrics

include, but are not limited to, elapsed time, status of the application process, downtime, abend code, and processor time consumption.
[0015] Based on the metrics data, the metrics associated with each of the application processes may be computed. Further, the computed metrics may be provided to a user in a readable format. Furthermore, in an example, mail alerts notifying users about the metrics associated with the application processes may be provided in case of an alert event.
[0016] Thus, the present subject matter provides for automated monitoring and generation of metrics associated with the application processes. Therefore, even with the increase in the number of the application processes, the metrics may be generated without much efforts and time. Further, the mail alerts may help in maintaining the stability of mainframe systems, since the issues associated with the application processes can be easily identified and addressed.
[0017] While aspects of described systems and methods for metrics determination for application processes in a mainframe architecture 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).
[0018] Fig. 1a illustrates a network environment 100 implementing metrics determination system 105, according to an embodiment of the present subject matter. The network environment 100 includes one or more mainframe systems 110, such as mainframe computer 110-1, 110-2, and so on. The mainframe systems 110 may be grouped together and located at a single site or may be distributed among two or more sites. The mainframe systems 110 may execute a plurality of application processes 115. For the purposes of illustration, the applications processes 115 have been shown as being stored in the mainframe systems 110.

[0019] The mainframe computers 110 and the metrics determination system 105 may communicate with each other through a network 120. The network 120 may be a wireless network, a wired network or a combination thereof. The network 120 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 the like. The network 120 may either be a dedicated network or a shared network. The shared network 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), Wireless Application Protocol (WAP), and the like, to communicate with one another. Further the network 120 may include a variety of network devices, including routers, bridges, servers, computing devices, storage devices, and the like.
[0020] In an implementation, the metrics determination system 105, hereinafter referred to as the system 105, can be implemented in computing systems that include, but are not limited to, desktop computers, hand-held devices, multiprocessor systems, personal digital assistants (PDAs), laptops, network computers, cloud servers, minicomputers, mainframe computers, and the like. In one implementation, the system 105 includes interface(s) 125, one or more processor(s) 130, and a memory 135 coupled to the processor(s) 130.
[0021] The interfaces 125 may include a variety of software and hardware interfaces, for example, interfaces for peripheral device(s), such as a keyboard, a mouse, an external memory, and a printer. Further, the interfaces 125 may enable the system 105 to communicate with other computing systems, such as web servers and external databases. The interfaces 125 can facilitate multiple communications within a wide variety of networks and protocol types, including wired networks, for example, local area network (LAN), cable, etc., and wireless networks, such as Wireless LAN (WLAN), cellular, or satellite. For the purpose, the interfaces 125 may include

one or more ports for connecting a number of computing systems with one another or to another server computer.
[0022] The processor 130 can be a single processing unit or a number of units, all of which could include multiple computing units. The processor 130 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 130 is configured to fetch and execute computer-readable instructions and data stored in the memory 135.
[0023] The memory 135 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 135 also includes modules 140 and data 145.
[0024] The modules 140, amongst other things, include routines, programs, objects, components, data structures, etc., which perform particular tasks or implement particular abstract data types. The modules 140 further include a scheduler 150, a metrics determination module 155, a metrics analysis module 160, and other module(s) 165. The other modules 165 may include programs that supplement applications on the system 105, for example, programs in the operating system. On the other hand, the data 145 serves, amongst other things, as a repository for storing data processed, received, and generated by one or more of the modules 140. The data 145 includes application data 170, analysis data 175, and other data 180. The other data 180

includes data generated as a result of the execution of one or more modules in the other modules 165.
[0025] In one implementation, the mainframe systems 110 may execute a plurality of application processes 115. Further, execution and scheduling of the application processes 115 may be performed by the scheduler 150. The scheduler 150 ensures that the application processes 115 are executed on time and in correct order. In an example, the scheduler 150 is Control M scheduler. Further, history of each application process 115 may be stored in an application database 185, such as Job History Subsystem (JHS).
[0026] In an implementation, the scheduler 150 triggers the metrics determination module 155 upon determining that all the application processes 115 in a batch have been executed. For example, a last application process in the batch may notify the scheduler 150 to trigger the metrics determination module 155 for collecting application data pertaining to each of the application processes 115 associated with the executed batch. The scheduler 150 may provide a list of the application processes 115 that have completed execution to the metrics determination module 155. The list may be indicative of details, such as names of the application process that have been executed. In other words, the list may include names of the application processes 115 for which metrics are to be computed. Accordingly, after execution of each batch, the metrics determination module 155 may be triggered. Thus, the system 105 may automatically determine the names of the application processes 115 that have completed execution instead of manually identifying the executed application processes. In an example, the scheduler 150 may provide a copy of current execution details indicative of the application processes 115 that have been executed. The copy of the execution details may require further processing to identify the application processes 115 that have been executed.

[0027] Upon identifying the application processes that have been executed, the metrics determination module 155 may be configured to obtain information pertaining to these application processes 115. For each application process 115 that has executed, the metrics determination module 155 may be configured to fetch corresponding application data from the application database 185. The application data may include, for example, JESMSGLG, JESJCL, JESYSMSG, SYSPRINT, SYSOUT, and SYSUDUMP. Further, the application data may be further processed. The application data corresponding to the application processes 115 that have been executed may be stored in the application data 170.
[0028] Typically, the application data may be scattered at various places in the application database 185, which generally makes manual fetching of data tedious and time consuming. The metrics determination module 155 provides for automated fetching of application data, thereby saving on time and efforts. Further, usually data in the application database 185, such as JHS, goes into a migrated state after a certain period of time. Therefore, the metrics determination module 155 may continually access the application database 185 to obtain the application data.
[0029] For the purpose of illustration and not as limitation, a screenshot 190 indicating an example of application data fetched by the metrics determination module 155 is shown in Fig. 1b. The information pertaining to the metrics may not be readily available from the application data and therefore, the application data may be processed further to obtain the required metrics.
[0030] In one implementation, the metrics determination module 155 is further configured to filter out metrics data, using filtering rules, from the application data for each of the application process 115 that has executed. The filtering rules may be indicative removal of certain information from the application data that may not be required for metrics computation,

therefore, for each application process, corresponding application data may be filtered out to obtain the metrics data. The extra information may be discarded and therefore the filtration of the relevant information helps in increasing the storage space. For example, upon application of the filtering rules, information, such as JESJCL, SYSPRINT, SYSOUT, and SYSUDUMP is filtered out from the application data to obtain metrics data. The metrics data may include JESMSGLG and JESYSMSG. JESYSMSG may provide information pertaining to jobtime, elapsed time, abend code, etc.
[0031] The metrics data may include information that is relevant for computing the metrics for the application processes 115. For example, metrics data may include information pertaining to an abended step of the application process 115. The metrics data corresponding to this step may be required for computation of downtime of the application process 115 and in finding the error code. Further, the metrics data may be grouped in the chronological order and may be maintained as mainframe files in the analysis data 175. Thus, the critical information, which may be lost during periodic house keeping of the application database 185 can be fetched from these mainframe files thereby avoiding cumbersome tasks of manual restoration of the application processes. The critical information may be for example abend information pertaining to the application processes 115 that are older than, say, two years.
[0032] Further, based on the metrics data, the metrics analysis module 160 may be configured to compute the metrics corresponding to each of the application process 115, for example, to analyze the performance of the application processes or a software application having these application processes. For example, the metrics analysis module 160 may determine elapsed time using the start time and end time for an application process. In another example, in case of an abended application process, an abended code may be determined from the metrics

data. Similarly, downtime and other metrics may be computed. An abended application process may be an application process that has crashed and an abended code may correspond to the reason for crashed portion of the application process.
[0033] In an implementation, upon computation of the metrics, the metrics analysis module 160 may provide the metrics to a user, such as an administrator monitoring the performance of the mainframe system or the software program having these application processes. The metrics may be provided such that it may be easy for the user to analyze or study the metrics. Further, from the metrics, status of the each application process 115 may be easily identified. In an example, the metrics may be provided in a report, which may be in any format, text, excel, etc. The report may be generated for each and every software application. Further, the report may include metrics for each and every application process in a software application and may also provide a consolidated summary at the end of the report.
[0034] A screenshot 195 indicating a format in which metrics may be provided to the user is illustrated in Fig. 1c. The screenshot 195 provides the metrics in a readily available format, which may be used by a user to assess the performance or get the information pertaining to the application processes 115 or a software application having these application processes.
[0035] In an example, the metrics analysis module 160 may analyze the metrics and trigger mail notifications. The metrics analysis module 160 may detect occurrence of an alert event, for example, an alert event may be detected when an application process 115 exceeds a threshold downtime, when the application process 115 exceeds a threshold processor utilization time, when the application process 115 exceeds a threshold elapsed time of execution, after the completion of the application process 115. In another example, when the application process 115 exceeds a

threshold elapsed time of execution, name of the application process 115 and the elapsed time may be notified to the users. Thus, in an implementation, the notification regarding the alert events may be sent as and when such an alert event is detected. In another example, after the completion of execution of the software application having the application processes 115, a report having at least one of the one or more metrics associated with the corresponding identified application processes of the software application and a path to the metrics of a software application having the application process 115 may be provided to users, such as clients or offshore administrators
[0036] The provisions of providing notifications to users upon higher consumption of factors, such as processor time, elapsed time, and down time, helps user to promptly identify the issue and solve the same, thereby ensuring stability of the mainframe systems 110. Further, the automated generation of the metrics in a readable format saves on considerable time and efforts.
[0037] Fig. 2 illustrates a method 200 for determining metrics corresponding to application processes in a mainframe architecture, in accordance with an implementation of the present subject matter.
[0038] The method 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. The method may also be practiced in a distributed computing environment where functions are performed by remote processing devices that are linked through a communications network. In a distributed computing environment,

computer executable instructions may be located in both local and remote computer storage media, including memory storage devices.
[0039] The order in which the method 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 method can be implemented in any suitable hardware, software, firmware, or combination thereof.
[0040] At block 205, application processes that have been executed are identified. In an implementation, the metrics determination module 155 is configured to obtain information pertaining to the application processes that have been executed from the scheduler 150. Based on the information, the application processes that have been executed may be identified.
[0041] At block 210, application data for each of the identified application process is obtained. In an implementation, the metrics determination module 155 is configured to fetch the application data from the application database 185.
[0042] At block 215, for each of the identified application processes, the application data is filtered to obtain corresponding metrics data. In an implementation, the metrics data may be obtained by the metrics determination module 155. The metrics data includes a portion of the application data, which is required for computation of the metrics.
[0043] At block 220, for each of the application processes, one or more metrics are computed based on the corresponding metrics data. The metrics help monitor the status and performance of

an application process. In an implementation, the metrics analysis module 160 may compute the metrics.
[0044] At block 225, notifications are triggered to respective users in case of an alert event based on the metrics. In an implementation, the notifications are provided by the metrics analysis module 160. For example, if it is determined that the processor utilization of an application process is greater than threshold, a notification may be triggered.
[0045] At block 230, the metrics corresponding to each of the application processes are provided to the respective users. In an example, the metrics are provided as reports to the users. The report may be provided for each software application. In an implementation, the metrics analysis module 160 may provide the metrics.
[0046] Although embodiments for determination of metrics for application processes in the mainframe architecture have been described in language specific to structural features and/or methods, it is to be understood that the invention is not necessarily limited to the specific features or methods described. Rather, the specific features and methods are disclosed as exemplary embodiments for determination of metrics for application processes in the mainframe architecture.

I/We claim:
1. A computer implemented method comprising,
identifying application processes (115) that have been executed based on information gathered from a scheduler, wherein the application processes (115) are executed in a mainframe architecture;
obtaining application data corresponding to each of the identified application processes (115) from an application database (185);
filtering the application data corresponding to each of the identified application processes (115) to obtain metrics data, based on filtering rules; and
determining one or more metrics corresponding to each of the identified application processes (115) based on the metrics data.
2. The computer implemented method as claimed in claim 1, wherein the one or more metrics include processor time, elapsed time, downtime, status, and abend code.
3. The computer implemented method as claimed in claim 1, wherein the information gathered from the scheduler comprises a copy of current execution details indicative of the application processes (115) that have been executed.
4. The computer implemented method as claimed in claim 1, wherein the method comprises detecting completion of execution of a batch including the application processes (115), wherein upon detection the application processes (115) that have been executed are identified.

5. The computer implemented method as claimed in claim 1, wherein the computer implemented method further comprises providing a report corresponding to a software application comprising the identified application processes (115), and wherein the report includes at least one of the one or more metrics associated with the corresponding identified application process and a path to a location of the one or more metrics.
6. The computer implemented method as claimed in claim 1, wherein the computer implemented method further comprises:
detecting, for each identified application processes (115) occurrence of an alert event based on the one or more metrics; and
triggering a notification to one or more users, upon detection of the alert event.
7. A metrics determination system (105)comprising:
a processor (130); and
a memory (135) coupled to the processor (130), the memory (135) comprises,
a metrics determination module (155) configured to,
obtain application data corresponding to application processes (115) that have been executed in a mainframe architecture from an application database (185);
determine metrics data corresponding to each of the application processes (115) using corresponding application data; and

a metrics analysis module (160) configured to generate one or more metrics corresponding to each of the application processes (115) based on the corresponding metrics data.
8. The metrics determination system as claimed in claim 7, wherein the metrics determination system further comprises a scheduler (150) configured to detect completion of execution of a batch including the application processes (115), and wherein the list of application processes (115) is obtained upon detection of completion of the execution of the batch.
9. The metrics determination system as claimed in claim 7, wherein the metrics determination module (155) is configured to group the metrics data corresponding to each of the application processes (115) in chronological order.
10. The metrics determination system as claimed in claim 9, wherein the metrics determination module (155) is configured to store grouped metrics data as mainframe files.
11. The metrics determination system as claimed in claim 7, wherein the metrics determination module (155) is configured to filter the application data based on filtering rules.
12. The metrics determination system as claimed in claim 7, wherein the metrics analysis module (160) is configured to provide a report corresponding to a software application comprising the identified application processes (115), and wherein the report includes at least one of the one or more metrics associated with the corresponding identified application process and a path to a location of the one or more metrics.
13. The metrics determination system as claimed in claim 7, wherein the metrics analysis module is configured to

detect, for each of the identified application processes (115), occurrence of an alert event based on one or more metrics; and
trigger a notification to one or more users, upon detection of the alert event.
14. A computer-readable medium having embodied thereon a computer program for executing a method comprising:
identifying application processes (115) that have been executed based on information gathered from a scheduler, wherein the application processes (115) are executed in a mainframe architecture;
obtaining application data corresponding to each of the identified application processes (115) from an application database (185);
filtering the application data corresponding to each of the identified application processes (115) to obtain metrics data, based on filtering rules; and
determining one or more metrics corresponding to each of the identified application processes (115) based on the metrics data.