COMPUTER PROGRAM PROFILER

Abstract: A computer program providing an output which is used to profile one or more operational characteristics of another computer program. The computer program being evaluated is defined by a group of events. In order to provide a user with a useful way to evaluate the performance of the computer program under evaluation, data is gathered corresponding to one or more of the group of events. A path map is constructed from the gathered event data in which the path map represents program operation performance relationships between the gathered events, and the path map is arranged in order of execution. The output is created based on the path map. The output is presented in such a manner that a user can quickly evaluate the performance of the program under evaluation. This is accomplished by presenting event data in a form which shows a logical programmatic flow along with a scaled representation of the quantity of times a measured event occurred along with a scaled representation of the duration of each measured event. Other statistical data can be analyzed and used as the basis for the output. The event data is gathered such that there is little effect on the performance of the program being evaluated.

Description: COMPUTER PROGRAM PROFILER BACKGROUND OF THE INVENTION This invention relates to a system and method for profiling the dynamic execution of a computer program, and more particularly to a system and method for creating a pictorial or diagrammatic representation of the dynamic execution of a computer program. The efficiency of computer systems overall, and of individual computer programs or portions thereof in particular, is of great concern to those who write software and maintain computer systems. This is exemplified by the fact that computer hardware and software owners often view their computing resources, and the applications executing on them, as assets. Like many other assets, their owners seek to manage the assets such that the efficiency and productivity of these assets are maximized. The performance of any computer system is necessarily a function of the efficient utilization of the computer's limited resources (e.g., processor usage, memory and I/O devices). Adjusting the allocation of the limited resources in the computer system in order to effectively manage the computing assets, also known as "tuning," can result in more efficient utilization of these valuable resources and programs which execute faster and more efficiently. The "behavior" of computer programs, that is, the dynamic, runtime execution and processing of a computer program, is often studied in detail. Understanding the behavior of a computer program facilitates tuning of the system and correction of run-time errors or other shortcomings. These errors may be the result of programming mistakes, or of unexpected and inefficient interaction between one or more programs (or one or more processes spawned by a single program) running simultaneously on the system. The behavior of a computer program, and in particular the sequence of operations performed by the program, may vary considerably each time the program is run (each "instance" of the program) even though the source code has not changed. The behavior of a program may vary from instance to instance based on input (received from a user or an I/O device, for example), data read by and operated on by the program, and the like. As a result of these variables, the sequence of operations performed by the program (known as "paths") may vary significantly from instance to instance. Further, as a result of such different paths being taken by the program, the performance of the program may vary from instance to instance, in some cases being satisfactory and in other cases being unsatisfactory. Moreover, the program may perform correctly when certain paths are taken, and the program may perform erroneously when other paths are taken. Even paths that perform correctly may follow a sequence not well understood by programmers maintaining the program, or even by its original developer. These difficulties are compounded in larger programs, wherein the increased number of functions and subfunctions makes it less likely that the program's internal workings will be fully understood. In such cases, it is likely that a "result-oriented" approach will be taken by developers and maintenance personnel, by which the efficacy of the program is tested only by verifying the correctness of output from the program without fully understanding what the program is actually doing while executing, and in what manner the program is making use of system resources. A "behavioral" approach to tuning and debugging, in which the programmer or maintainer understands the logical flow or behavior of programs during execution and use of the system's resources, is better suited for developing programs and tuning systems to maximize the efficient use of resources while minimizing errors. However, a tool is needed to convey information about the behavior and performance of the program to the programmer or maintainer (the user of the tool) in a comprehensible and more easily graspable format. Several types of programs have been developed which create pictorial representations, or profiles, of program performance. One type of profiling program monitors and profiles the overall performance of subject programs by simply gathering statistics on such things as I/O frequency and CPU utilization and by indexing this data by time period, type of I/O, etc. A second type of profiling program profiles the performance of subject programs by collecting statistics related to individual instructions or ranges of instructions executed by the subject program. This second type of profiling program typically periodically interrupts the operation of the subject program and detects the instruction about to be performed by the subject program. This type of profiling program reports the relative frequency with which particular instructions or ranges of instructions are executed, and may also report on the CPU time consumed by those instructions. The report produced by this type of profiling program may consist of a bar chart with a bar for each instruction or instruction range, wherein the height of each bar denotes the frequency with which the subject program was found to be executing the instruction or range of instructions at issue when the subject program was interrupted. A third type of profiling program, known as "flow charting programs," processes the source code of a computer program directly and depicts it graphically, according to well-known conventions, so that the processing logic and flow can be more easily traced and understood. While all of these types of profiling programs provide valuable information for systems and application programmers, the present art is deficient in that no program relates the run-time behavior and dynamic performance of a program to its logical flow. Therefore, it is desired to provide a computer program profiler which depicts the behavior of a computer program and relates the program's behavior and performance to its logical flow in its operating environment, including multiprocessor and networked environments. SUMMARY OF THE INVENTION Generally speaking, in accordance with the invention a computer program profiler is provided which diagrammatically, pictorially and tabularly provides a user with data showing the behavior of a computer program such that the program's behavior and performance is shown in accordance with its logical flow in its operating environment, including multiprocessor and networked environments. This allows owners and operators of the computers and networks executing the program to effectively and efficiently manage their computing and networking assets. It is an object of the present invention to provide a method for profiling one or more operational characteristics of a computer program, the computer program performing one or more transactions, at least one of the transactions having one or more events in which data is gathered corresponding to one or more of the events. A path map is constructed from the gathered event data in which the path map represents program operation performance relationships between the gathered events, the path map being in execution-time sequence, and an output is created based on the path map. Another object of the invention is to provide a method for analyzing at least one transaction of a computer program to determine the operational characteristics of the computer program, in which a plurality of data is gathered corresponding to one or more of a plurality of event data in a manner having approximately no impact on the executional performance of the computer program. An output is created based on the plurality of gathered event data. According to still another object of the present invention, an apparatus for profiling one or more operational characteristics of a computer program is provided, the computer program performing one or more transactions, at least one of the transactions having one or more events in which the apparatus comprises a processor capable of the following functions: gathering data corresponding to one or more of said plurality of events: constructing a path map from the gathered event data, the path map representing program operation performance relationships between the gathered events, the path map being in execution-time sequence; and creating an output based on the path map Other features and advantages of the present invention will become apparent from the following description of the invention which refers to the accompanying drawings BRIEF DESCRIPTION OF THE DRAWINGS For the purpose of illustrating the invention, there is shown in the drawing several forms which are presently preferred, it being understood, however, that the invention is not limited to the precise arrangements and instrumentalities shown. Fig 1 is a block diagram of a computer program profiler constructed in accordance with the present invention, Fig. 2 is a sample output diagram generated by a computer program profiler constructed in accordance with the present invention; Figs. 3-16 are flov. diagrams depicting the operation of a computer program profiler constructed in accordance with the present invention, Fig 17 is a diagram showing a multi-node network whose operation can be profiled using the present invention, and Fig 18 is a path map showing electronic mail message transactions across the network of Fig. 17 Fig. 19 is a flow diagram depicting the operation of an output component constructed in accordance with the present invention. DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION Reference is first made to Fig 1 , in which a computer program profiler 102 developed m accordance with the present invention is shown. Computer program profiler 102 includes a data gathering component 104, an analysis component 106 and an output component 108 Generally speaking, in accordance with the invention, data gathering component 104 gathers data on the sequential execution logic and performance of a subject program 110. The data gathered on subject program 110 by data gathering component 104 is transferred to analysis component 106 for analysis and creation of a specialized data structure referred to as a "path map." The path map created by analysis component 106 is used by output component 108 to create a specialized depiction of graphics and/or text which relates the behavior and performance of subject program 110 to its logical flow. Computer program profiler 102 is executed by one or more processing computers. The processing computers can be mainframe computers, minicomputers or personal computers. In addition, data gathering component 104 of computer program profiler 102 can execute on a special purpose computer such as a network router or switch. Subject program 110 may generally comprise any computer program running on virtually any type and any number of computers such as mainframe computers, minicomputers, personal computers, or special purpose computers such as network routers, switches, etc. For ease of discussion, the following description of the preferred embodiments of the invention is based on an IBM Customer Information Control System (CICS) transaction processing program. CICS is a product which enables users to create programming applications called "transactions" to process certain data. Each transaction is identified by a unique name and comprises a sequence of operations or "events." An event is a milestone that can be quantified for gathering statistical profiling data. For example, in CICS, a transaction is the execution of a program that performs a sequence of events according to input data provided by the user. In UNIX it is common to "pipe" data through two or more programs, each of which performs a sequence of operations. Such events may include, for example, reading and writing to various data files. Accordingly, subject program 110 will generally be referred to herein as a transaction. Although the following description refers to transactions and events, it is to be understood that the invention encompasses any implementation of the computer program profiler having the features described herein on any computer hardware or software platform or network of computers. Moreover, the term "transaction" is intended to more generally refer to any program, application or portion thereof, and the term "event" is intended to more generally refer to any segment of a transaction which is of interest to a user. Such segments may include, but are not limited to, an instruction, I/O operation, macro, function, subroutine or the like, a signal passing through a network node, or a group thereof. Events can be considered either low-level operations, high-level operations, or a combination of both. High-level operations are generally composed of one or more low-level operations. The distinction between high- level operations and low-level operations is fluid and is not a function of the program which is gathering corresponding statistical data. Rather, it is a function of how a user defines "high" and "low". For example, a user may consider read file, write file, create database record, perform network I/O, and perform an operating system function as examples of low-level events. The same user might also consider send electronic mail, query a database, execute an application program and an internet domain name look-up as examples of high-level events. Thus, high-level or low-level events can be monitored, depending upon the nature of the user's interest. With the proliferation of networking computers together to perform a function, a computer program is no longer considered a single entity residing and executing in a single unit. A computer program can be distributed among multiple computer units. Thus, as used herein the term "computer program" refers to the overall entity being profiled through which a transaction passes. This entity may require numerous separate programs and multiple computer units to perform its function. These separate programs may in turn employ the use of multiple libraries or may be bundled into one or more program suites. Data gathering component 104 and subject program 110 are preferably stored and executed on the same computer system. However, as discussed above, data gathering component 104 may be stored and executed on a different computer system than subject program 110 so long as the systems are either sufficiently linked for data gathering component 104 to obtain the necessary data from subject program 110 or the data is made available to subject program 110 in some fashion such as a tape, disk or other media. Regardless of where data gathering component 104 is stored and executed, as discussed in detail below, the present invention operates and performs in a non-intrusive manner with respect to subject program 110 such that there is approximately no adverse impact on the executional performance of subject program 110. Analysis of a program's operation using the above-described program profilers is further complicated when the operation of the program is distributed across multiple processors, or multiple networked CPUs. Data gathering component 104, analysis component 106 and output component 108 are also preferably stored and executed on the same computer system. However, it is to be noted that data gathering component 104 may gather and store data concerning subject program 110, and this data may then be copied, transmitted or otherwise transferred to a wholly separate computer system or systems on which analysis component 106 and output component 108 are stored. In addition to using multiple computer systems or separate computers to gather, analyze and produce the output for the computer program profiler 102, it is also possible that one or more of the programs involved in the execution of all or part of a transaction may be running on multiple processors or multiple computers within the operating environment. The computer program profiler 102 can support this distributed environment, including profiling the movement of data packets over a network. These scenarios are addressed in detail below. Fig. 2 shows an output report 212 for the actual processing flow for an example subject program 210 named "ORDR". The output allows a user to diagnose the exact cause of slow or erratic transactions by letting the user see what subject program 210 is actually doing in a way that can be related to the program code itself. The output, displayed on a screen, printed, or stored for future use is a path diagram that reflects the actual processing flow of subject program 210. The diagram depicts each path through subject program 210 that was followed by one or more transactions. A path is a distinct sequence of operations, such as I/O, transient data, etc. As shown in Fig. 2, each line segment labeled with a letter within a diamond represents a particular operation 214. There are also shown segments in which the length 216 of each segment represents the average amount of elapsed execution time taken to perform the operation. The thickness 218 of each segment represents the number of transactions following that path. The dashed lines 220 show the operational flow back to the subject program's main line, represented in this example by operations A-G. The main line (or main path) is the path of the most frequently occurring sequence of paths from the beginning to the end of a transaction. The longest path is placed in the middle of the output diagram. The output diagram 212 quickly reveals any unnecessary, duplicated, or suspect operations. For example, in the mainline path, the write-key of the ORDER-DETAIL file (operation E) takes a long time to complete when compared with the other operations, possibly indicating a problem. As another example, the PARTS table is read in four different places (B, K, M, and N), revealing a possible logic error, or at the very least, an area of possible coding improvement. All transactions can be analyzed, or analysis can be restricted to particular transaction IDs and/or particular terminal IDs. Data can be captured using standard exit routines such that very little overhead is introduced into the operation and performance of subject program 210. Reference is now made to Figs. 3 and 4, wherein the operation of data gathering component 104 is explained in further detail. Data gathering component 104 is preferably initiated by a command input by the user to start data gathering. The initial task 302 performed by data gathering component 104 gets parameters from the user specifying the data to be gathered. For example, the user may be asked to specify the names of the transactions to be monitored for profiling. A default profile can also be created to monitor transactions when none are specified. Additionally or alternatively, the user may be prompted to specify names of transactions which are to be excluded from data gathering. Such exclusions may serve to limit any generic names, names with wildcard characters, or lists of transaction names which the user has previously specified for inclusion in data gathering. Preferably, if no transaction names are specified by the user, data gathering component 104 will gather data on all transactions running on the subject computer system. A grouping of transactions of a specific type, or transactions which are related are referred to as a "category". Examples of categories include activities conducted under a user-ID, internet domain name and internet domain name look-up, etc. Users might be interested in gathering statistical data relating to these categories. In these cases, profiling software is necessary to capture, analyze and present this data in a meaningful fashion. Data gathering component 104 can gather data relating to these categories. Presenting categorized transaction event data allows a user to view system performance at a meaningful level because the user is able to determine how a specific aspect of the system is operating, rather than merely viewing the low-level operational characteristics of the system. The present invention allows a user to view categorical system performance via an output, as described below, based on categories. Data gathering component 104 also allows a user to specify certain criteria. The resultant profile is then based on this criteria. Criteria can be specified alone or in combination with one or more other criteria. In other words, criteria provide a way to filter data gathered or used in the present invention. It must be noted that filtering criteria can be implemented 1) in the data gathering stage so that only relevant data is captured and stored in memory; 2) during the path map creation stage such that all data pertaining to a transaction is captured and stored in memory, but only data meeting the specified criteria is passed to analysis component 106; 3) in the reporting stage so that the output presented to the user is focused on the area of interest to the user, or 4) any combination thereof. For example, a user might want to include or exclude transactions which: have a specific transaction identification; have a specific user identification; have a path containing a particular node or event type; have a particular Internet domain name; have a particular Transmission Control Protocol/Internet Protocol (TCP/IP) address; access a particular file or particular data; or occur in a specific time period. Data gathering component 104 then enters a loop beginning with step 304 in which data gathering component 104 checks whether the command input by the user is a request to start or stop data gathering. If the user has entered a start command, then data gathering component 104 proceeds to step 306 in which data is gathered on subject program 110 pursuant to the input parameters specified by the user in step 302. Internal work space for the data to be gathered is obtained. After records containing the data have been gathered in step 306, data gathering component 104 checks to see if a new command has been issued by the user or, perhaps, by another program or I/O device in step 308. If no new command has been issued, processing reverts back to step 306 in which data gathering component 104 continues to gather and store data. This loop continues until a new user command has been detected in step 308. At this point, control is returned to step 304 in which the new user command is checked to determine whether or not it is a start command. Typically, a command entered after data gathering has begun will not be a start command, but rather will be a "quit" or similar command indicating that data gathering is to be stopped. In this case, the result of the query in step 304 will be negative and control will pass to a step 310 in which the final data is written to the data file specified by the user. All internal storage is then released and processing is complete. Additionally or alternatively, data gathering component 104 may be discontinued in step 304 upon the expiration of a timer or upon reaching an ending time specified by the user in step 302. Such a configuration would allow the user to automate and simplify the gathering of data concerning subject program 110. The quantity of criteria required to effectively monitor and profile transactions, and the resultant data from those criteria, may be too voluminous to be efficiently entered by a user. In addition, a user might not know which specific events are important for gathering and profiling purposes. In the alternative, data processes within data gathering component 104 can be substantially automated such that a user need not select particular event criteria. Using an automatic process, a user need not know which events are particularly important. Methods and apparatuses for automatically monitoring computers to detect, monitor and control software products installed on a computer system are known. Such methods and apparatuses are provided, for example, in U.S. Patent No. 5,499,340, issued to Barritz, and U.S. Patent No. 5,590,056, issued to Barritz, both of which are incorporated herein by reference. The present invention can make use of automatic program detection by maintaining a list of criteria for which data are to be gathered in the event that a particular program is automatically detected. This reduces the amount of user interaction required to merely a single instruction, namely to begin automatic data gathering. This aspect of the present invention is particularly useful when used in conjunction with mainframe computers because these computers typically employ many logical disks, for many different user communities, such that there is a large number of potential programs which may be executed thereon. Automated data gathering in conjunction with automatic program detection is also quite useful in the network computing environment because a packet received by an individual node may cause the execution of one or any number of computer programs within that particular host. A user need only initiate the automatic execution of data gathering component 104 rather than enter data gathering criteria for each of these programs in the hopes that one will be executed. In other words, the automatic initiation of data gathering component 104 can be quite beneficial in large-scale computing environments. These predetermined data gathering criteria are stored in the computer's volatile or nonvolatile memory for future use. The predetermined criteria can be provided by the vendor of the particular software program to be monitored, can be established by the user, or can be generated by capturing all events for a particular program and deleting those event criteria which are not needed. Of course, the predetermined list of event criteria can be edited by a user, and customized for a particular use. In this embodiment, the substantially automated initiation of data gathering component 104 can optionally automatically invoke analysis component 106, described in detail below, such that the generation of an output map, or other output data, is automatically generated without the need for any user intervention. Preferably, analysis component 106 is invoked once data gathering component 104 has halted, i.e., data gathering is complete. Thus, automatic initiation of data gathering component 104 can be invoked without a user being present, and executed overnight, such that the resultant output is available for the user in the morning. The data gathering performed by step 306 of data gathering component 104 is depicted in greater detail in Fig. 4. Each time data gathering component 104 is notified that an event has been or is about to be executed in an instance of a transaction, the transaction name of the event is checked in step 402. The transaction name for the subject event is compared with the list of transactions or classes of transactions specified by the user in step 302 for which data gathering was requested. If data gathering was not specified for this event, then the event is ignored and data gathering component 104 waits for the next event. If the transaction name checked in step 402 matches one of the transactions to be monitored, control proceeds to a step 404 in which pertinent information about this event is recorded in a transaction record for the current instance of the subject transaction. In particular, the "event type" is recorded. The event type may indicate, for example, that the event is a read or write to a file, a transfer of control to another program or transaction module, or a request for system service such as storage. In addition, the time that the event occurred is recorded. Additional information specific to the event type is also recorded. For example, if the event was a write to a file, the additional information could include the name of the file and the size of data written to it. Finally, after the pertinent event information is recorded in step 404, in step 406 the resultant data record for this event is written to the data file specified by the user in step 302. The mechanism for recording event data will vary from system to system. Some systems, such as CICS, allow "exit-routines" to be supplied in order to capture and record appropriate transaction and event data. Others, such as many computer operating systems, lack provision for some or all of the such exit-routines. In the latter case, it is necessary to establish a monitor to intercept the appropriate transactions and events without requiring modification to subject program 110 and/or having approximately no negative impact on the executional performance of subject program 110, and to record the data pertinent thereto. One such monitor is disclosed in U.S. Patent No. 5,499,340, except that the functions being intercepted would also include input and output functions. Reference is now made to Fig. 5, in which analysis component 106 of computer program profiler 102 is described in greater detail. Analysis component 106 can generally be divided into two fundamental, sequential phases: a data reduction phase 502 and a presentation phase 504. During the data reduction phase 502, the transaction and event data to be analyzed are selected and a data structure representing an internal map of the recorded events is created which relates the recorded events to one another. In addition, data from like sequences of events in different transaction instances are combined and looping events in each instance of the transaction are condensed. In the presentation phase 504, the internal map created in data reduction phase 502 is used to create a logical view that will allow the user to quickly understand how the recorded events relate to one another. This is accomplished by reassembling the events according to their sequence of execution within the subject transaction, identifying a "main path" through the recorded events, and generating data necessary to create a pictorial representation of this main path. Events which fall outside of the main path are arranged to show how they relate to those events which are on the main path. The relationships between the recorded events are analyzed to allow an optimum pictorial representation of the events. In the output component 108, the logical view created in presentation phase 504 is translated into a selected output medium, such as a printer or a computer monitor. As discussed above, analysis component 106 may be activated at any time after the transaction and event data gathered by data gathering component 104 has been stored. As shown in Fig. 6, the data reduction phase 502 may itself be generally divided into two sequential tasks. In a first data reduction phase task 602, event data is validated, sorted and selected. The recorded data is analyzed to ensure that it was built correctly and that the user parameters relating to the selected data, the selected output medium and the like, are correct. In a second data reduction phase task 604, a specialized data structure, referred to as a "path map," is built. The path map comprises a number of path element control blocks ("PECBs") which are created from the event data selected in the first data reduction phase task 602. Each PECB initially contains data for one recorded event, although the PECBs in the final path map are likely to contain data on more than one recorded event. The path formed by these PECBs is a logical map showing how each recorded event relates, in order of execution, to each other recorded event. Data is accumulated in each PECB related to particular aspects of one or more associated recorded events, such as the duration of execution time for the event and the number of times the event occurred within the time period selected for recording and analysis. The processing performed by the first data reduction phase task 602 is shown in greater detail in Fig. 7. First data reduction phase task 602 begins with an input step 702 in which the user is prompted to specify where the event records to be analyzed are located and which records which should be selected for analysis. The parameters entered by the user may include, but are not limited to, file name(s) of records containing the event data, the names of transactions to be analyzed, the time period for analysis, and the like. After the input parameters have been obtained in step 702, the records containing the event data specified by the user are validated in a step 704 together with any transaction names and/or time periods specified by the user. In particular, the file containing the event records specified by the user is read and the format of the event records is validated to ensure that the data and the records can be properly interpreted. The event records are also checked to ensure that the event records contained in the specified file actually occurred within the time period specified by the user in step 702. A sort step 706 is then executed which sorts the event records in order of their respective points of execution within the program. The event records are further sorted by transaction name and any other relevant indicia specified by the user (for example, terminal I.D., user I.D., etc.) so that the event records are organized in the order in which the events occurred for a particular transaction. These event records are then selected in a selection step 708 based on the time period and transaction names specified by the user in input step 702. Finally, the sorted and selected event records are preferably written in a step 710 to a separate file for use in later processing. Reference is now made to Figs. 8-13 in which the second data reduction phase task 604 is described in further detail. Task 604 builds PECB chains from the PECBs selected and sorted in first data reduction phase task 602. Each PECB chain is a two-way linked list of PECBs representing the sequence of events which occurred in one instance of a recorded transaction. Second data reduction phase task 604 assimilates each of these PECB chains into a path map which is a specialized data structure, preferably configured as a linked list of PECBs, representing all unique paths or event sequences (each of which is represented by a path of linked PECBs on the map) executed for the selected transaction(s). Where the same path or path segment is executed in more than one instance of the transaction, the redundant paths or path segments are not given separate representation in the path map, but are instead tracked by recording, within the PECBs comprising the path map, the frequency with which certain paths or path segments were executed. In this way, the simplest logical and pictorial representation possible may be obtained without sacrificing any relevant data. As shown in Fig. 8, building the path map begins by creating a chain of PECBs for each recorded instance of the transaction. First, a PECB chain building task 802 builds a single PECB chain for one instance of the transaction. After a PECB chain has been built, a decision 804 is made as to whether the PECB chain most recently built in step 802 is the first PECB chain built for the path map. If it is, two special PECBs are preferably built. Specifically, a header PECB and a trailer PECB (represented in the figures as HDR and TRLR, respectively) are built to anchor the beginning and end of the path map. The first PECB in the PECB chain detected by decision 804 is then linked to the header PECB, and the last PECB in the PECB chain detected by decision 804 is linked to the trailer PECB of the path map in step 806. At this point, the path map reflects one path for the subject transaction, namely, the path taken in the first recorded instance of the transaction. An identifier is preferably set in each PECB in this chain indicating that the path represented by this first PECB chain is the first unique path added to the path map. The identifier may comprise, for example, an integer path number (in this case " 1 "). Each time a new, unique path or path segment is added to the path map, its presence is preferably indicated by identifying each PECB in the new path or path segment with the next available path number. When the path map is complete, the path numbers in the PECBs will give an indication of how many unique path segments make up the final path map. Control then returns to step 802 in which a PECB chain is built for the next recorded instance of the recorded transaction, if applicable. For each PECB chain built after the first in step 802, decision 804 will pass control to path reduction task 808 which condenses loop events within the PECB chain and attempts to match the chain to a PECB chain or PECB chain segment already in the path map. Data from like PECBs are combined in path reduction task 808 and the frequency of particular events is recorded to enable computation of average execution times for the recorded events. The process of building new PECB chains in task 802 and performing path reduction in task 808 continues in a loop until it is determined by a decision 810 that there are no more recorded transaction instances to be processed, after which control will be passed to presentation phase 504. PECB chain-building task 802 is described in further detail with reference to Fig. 9. PECB chain building begins by obtaining an event record from the file of sorted and selected event records created in step 710 of Fig. 7. Next, a PECB is built in a step 904 from the event record selected in step 902. The PECB is a multi-threadable control block which will contain data about collected occurrences of the subject event and will be linked to events which precede and/or follow it in the PECB chain. Memory must, of course, be allocated for each PECB. Such allocation is preferably accomplished by allocating a large block of contiguous memory early in the analysis process, such as when each PECB chain is built or when the second data reduction phase task 604 is initiated, rather than when each PECB is built, for reasons of speed and efficiency. Allocating PECBs from a single large memory area also permits the PECBs to be contiguous in memory, which facilitates searching the linked PECBs. Data from the event record selected in step 902 is then written into the allocated PECB in step 904. In a CICS environment, the relevant event data could include the time the event was executed, a transaction I.D., an event type, event operands, a task number, a terminal I.D., a user I.D., and the like. The PECB will also contain a number of pointers for linking the PECB to other PECBs before and after it on the PECB chain. A PECB may contain multiple forward and backward pointers, and therefore the size of a PECB may vary depending on the number of pointers allocated for the PECB. For this reason, the size of a PECB may be statically allocated by limiting the number of forward and backward pointers in the PECB, or, alternatively, memory space for additional pointers may be allocated dynamically to the PECB when such pointers are stored in the PECB. After the PECB has been built in step 904, this most recently built PECB is chained or linked to the previously built PECB in this chain by step 908 lf the current PECB is not the first in the chain as determined in decision 906 Chaining is accomplished by wπting a forward pointer m the previous PECB which points to the current PECB, and by wntmg a backward pointer m the current PECB which points to the previous PECB m order to maintain the preferable two-way linkage Decision 910 creates a loop by which PECBs are built and chained as descπbed above until a PECB for the last event for the current transaction instance has been built and chained At this point, the duration of execution of each event (the "event duration") is calculated, preferably by subtracting the time at which the event occurred (which was stored m each PECB in step 904) from the time at which the following event m the PECB cham occurred The event duration for each event is written into the PECB for that event An "event count" is also wπtten into each PECB indicating the number of times the associated event was executed (m the sequence represented by the PECB chain) in all the recorded instances of the transaction When a PECB chain is initially built, the event count in each PECB is set to 1 The path reduction performed by path reduction task 808 on each PECB chain is descπbed in greater detail with respect to Figs 10-13 Path reduction begins with a loop processing task 1002 Since a series of consecutive events of the same type may indicate a loop condition, the path map (and therefore the ultimate pictonal representation) should be simplified to condense the PECBs representing a loop condition mto a single PECB m which the number of repetitions of the particular event is recorded as well as the average duration for each repetition of the event Likewise, repeated sequences of multiple events may indicate a multiple event loop which requires similar processing After loops have been processed, a forward-processing task 1004 is initiated to determine whether the event sequence or "path" of the new PECB chain, or an initial segment of it, is identical to a path or path segment already on the path map Forward-processing task 1004 attempts to match events on the new PECB chain with those already on the path map, beginning with the first event in the new PECB chain and the first event(s) on the path map and moving forward through the chain and path map When a match is found, the event data in the PECB on the new chain is incorporated into the matching PECB already on the path map, and the PECB on the new chain is eliminated, thereby reducing the number of PECBs added to the path map and simplifying the ultimate output. PECBs which do not match any PECB already on the path map are added to the path map. Likewise, backward-processing task 1006 completes path reduction by working backward from the end of the new PECB chain and attempting to match PECBs on the new chain against those already in the path map. This process is useful for identifying whether the path represented by the new PECB chain begins differently than those already in the path map but nevertheless ends with a sequence of events which is already identified in the path map and may be incorporated therein as described above. Loop processing task 1002 condenses PECB chains containing loops by retaining only those PECBs in the chain necessary to represent one cycle of the loop and eliminating the remaining PECBs representing the redundant cycles of that loop. It is desirable to represent the loop as a single PECB block on the path map rather than including a PECB for every loop cycle. Such repetitive events would cause a large number of PECBs and unique paths, both in the path map and on the ultimate output diagram, which would overly confuse the user by displaying a complex set of interconnected and possibly crossing connection lines indicating these unique paths. The important information for the user, and therefore the relevant information to be stored in the path map, is the fact that a loop occurred and the average time consumed by the loop (in the example above, the number and duration of read events which were executed). In addition, loop processing task 1002 averages the effects of loops across different instances of a transaction so that a variation in the number of identical events within the loop in different instances of the transaction does not cause a disproportionate number of unique paths to be created in the path map and ultimate output. For example, if a transaction contains a "read" event, wherein the read event is executed in a single-event loop until a particular datum is located, three instances of the transaction might result in this read event looping four times in the first instance, five times in the second instance, and twenty-five times in the third instance. It would be desirable to show only a single path for such a loop on the path map indicating the average execution time expended by the loop to read the datum in all three instances rather than, in this example, three unique paths, one for each loop length. Single event loops (that is, loops consisting of a series of consecutive identical events) are preferably processed as described in Fig. 11. A PECB pointer, named THISEVENT for purposes of this description, is initially set to point to the first PECB on the new PECB chain to undergo loop processing. The event "type" (such as read, write, etc.) of the PECB pointed to by THISEVENT is then compared to the type of the next forward event on the PECB chain. If the types do not match, then a loop has not been found. In that case, control is passed to decision 1106 which determines whether this is the last PECB in the chain, in which case the single event loop processing would be complete. If THISEVENT is not the last PECB on the chain, the THISEVENT pointer is advanced to point to the next PECB on the chain in step 1108, and the type of the new PECB pointed to by THISEVENT is again matched to the type of the next event on the chain in step 1104. This loop, comprising decisions 1104, 1106 and step 1108, continues until decision 1104 determines that the types of two consecutive PECBs are the same, thereby indicating a loop event. When a loop event has been found, a loop event counting loop 1118, comprising steps 1110, 1112, 1114 and decision 1116, is executed. Loop event counting loop 1118 begins by storing the event duration (that is, the execution time consumed by the event calculated in step 912 of Fig. 9) of the latter event in a temporary field. This event duration is obtained from the PECB for the latter event. Next, a counter of loop events is incremented in step 1112. This counter is preferably created and or cleared after decision 1104 determined that a loop event had occurred. A new PECB pointer, named LOOPEVENT for purposes of this description, is then set to point to the next PECB on the PECB chain in step 1114. If the type of the PECB pointed to by LOOPEVENT is determined in decision 1116 to be the same as the type for the PECB pointed to by THISEVENT, then loop event counting loop 1118 recurs, starting again with step 1110. Loop event counting loop 1118 continues in this manner until the type of the PECB pointed to by LOOPEVENT is different than that of the PECB pointed to by THISEVENT, indicating that the loop found in the PECB chain has ended. Once the end of the loop in the PECB chain has been found, the event duration in the PECB pointed to by THISEVENT is added to the temporary field and the loop counter is incremented as shown in steps 1120 and 1 122, respectively. These steps account for the first event in the loop. The average event duration for each event in the loop is then calculated in step 1124 by dividing the time in the temporary field by the number of events indicated by the loop counter, and this average time, together with the number of events in the loop indicated by the loop counter, are stored in corresponding fields in the PECB pointed to by THISEVENT in step 1126. The redundant loop events are next removed from the PECB chain by chaining the PECB pointed to by THISEVENT to the non-identical event found in decision 1116 (which is pointed to by LOOPEVENT) in step 1128. This is accomplished by setting the forward pointer in the THISEVENT PECB to point to the LOOPEVENT PECB, and by setting the backward pointer in the LOOPEVENT PECB to point to the THISEVENT PECB. At this point, the PECB pointed to by THISEVENT contains all the necessary information regarding the loop, including the event type, the number of times the event was executed, and the average event duration consumed by each event. Accordingly, the remaining PECBs for the loop events (that is, the PECBs formerly located on the chain between the THISEVENT PECB and the LOOPEVENT PECB) may be eliminated, and the memory space occupied by these PECBs may be freed in a step 1130. Finally, THISEVENT is set to point to the non-identical event found in decision 1116 (also pointed to by LOOPEVENT) in step 1132 and control is returned to step 1104 for further loop processing along the chain. Loop processing continues in this manner until the last event in the chain is found in decision 1106, at which time single event loop processing for this PECB chain is complete. After single event loop processing has been completed, multiple event loop processing is performed on the chain. Multiple event loop processing proceeds in a manner similar to single event loop processing as described above, but instead of searching for repetitive, sequential occurrences of a single event, a search is conducted for repetitive, sequential occurrences of groups of events. Multiple event loop processing preferably begins by searching for repetitive, sequential occurrences of two-event groups, and proceeds to three-event groups, and so on. The largest size group searched for may be determined as desired, generally based on countervailing considerations of output simplification and the speed of loop event processing. However, the largest event group searched for should obviously be no larger than one-half of the number of PECBs on the chain. Referring again to Fig. 10, after loop processing task 1002 is complete, additional path reduction is performed on the chain by a forward- processing task 1004 which is described in greater detail with respect to Fig. 12. Forward-processing task 1004 attempts to match sequential events at the beginning of the new PECB chain with the beginning of the paths already on the path map, starting with the first event in the new PECB chain and the first event(s) on the path map, and moving forward through the new PECB chain and path map if such matching events are found. The event data from matching events is incorporated into the PECBs already on the path map, and only PECBs which do not match a path already on the path map are actually added to the path map itself. As shown in Fig. 12, forward-processing task 1004 begins with a determination 1202 as to whether the event type of the first PECB on the new chain matches the event type of any PECB connected to the header PECB on the path map. In other words, the first element of the new chain is compared to the first elements of the paths already identified on the path map to determine whether the beginning of the path represented by the new chain coincides with a path which is already on the path map. If no match is found in determination 1202, then the first PECB of the new chain is chained to the header PECB on the path map in step 1204, thus indicating that the new chain represents the beginning of a new path. A new path number is preferably set in each PECB in the new chain to indicate that the new chain represents a new, unique path, and this path number is preferably set as the next available integer path number. Although a path may begin with different events than any path on the path map, the new path may at some point execute a sequence of events which ends a transaction like a path already on the map. That is, the new path may "merge" with a path already on the map. For this reason, so called "backward processing" should be performed on the new path as described below, and an indication that backward processing is necessary is made in step 1206, after which forward processing would be complete for this new chain. If the type of the first element on the new PECB chain does match the type of one of the elements connected to the header PECB on the path map, then a common path beginning has been found. The data from the matching PECB on the new chain is incorporated into the data in the matching PECB on the path map in step 1208. Specifically, at least the average event duration and event count contained in the matching PECB on the path map would preferably be updated to reflect the data in the matching PECB on the new PECB chain. The matching PECB on the new PECB chain can then be freed in step 1210 since its data is already incorporated in the path map. Alternatively, an indicator in the matching PECB on the chain could be set in step 1210 for indication that the PECB should be freed at a later time, and in this manner all PECBs so indicated could later be freed essentially simultaneously after path reduction task 808 is complete. If the matching PECB on the new chain is determined to be the last PECB on the new chain in decision 1212, then the entire new PECB chain has been matched to a path already on the path map. In such a case, forward processing would be complete and no backward processing would be necessary, and this is indicated in step 1214. If a matching event has been found and the end of the new PECB chain has not yet been reached, the event type of the next PECB on the new chain is compared in determination 1216 to the event type(s) of the next element(s) on the path map which follows the matching path map PECB found in determination 1202. If another match is found, control returns to steps 1208 and 1210 to combine the data from this most recently matched PECB on the new chain to the most recently matched PECB on the path map and to free the PECB on the new chain. This path-matching loop, comprising steps 1208 and 1210 and determinations 1212 and 1216, continues until either the end of the new PECB chain is reached in determination 1212 as discussed above or a non-matching event is encountered while travelling the path map in determination 1216. If the latter event occurs, a new path segment has been found in the new chain beginning with the non-matching PECB. Accordingly, the non-matching PECB on the new chain is connected to the most recently matching PECB on the path map in step 1218. A new forward pointer is added to the matching path map PECB pointing to the non-matching PECB on the new chain, and the backward pointer in the non-matching PECB on the new chain is changed to point to the matching path map PECB. Finally, the next available path number is set in each PECB representing the new path segment. Since an end portion of this new path segment may merge with a path already on the path map before ending, the new path segment is marked to indicate that backward processing is necessary in step 1220, and forward-processing task 1004 is complete. Backward-processing task 1006 operates similarly to forward- processing task 1004 as shown in Fig. 13, with the exception that processing begins at the end of the new chain and path map and proceeds backwards toward the beginning. Backward-processing task 1006 is executed only if forward- processing task 1004 discovered a path or path segment in the PECB chain which was not already on the path map. The completion of loop processing task 1002, forward-processing task 1004 and backward-processing task 1006 (if required) completes path reduction task 808 and, therefore, the processing for one new PECB chain. After all of the PECB chains have been built and incorporated into the path map in accordance with step 604 of the data reduction phase, the result is a path map data structure which logically relates each event which occuπed in any instance of the subject transaction to each other event which occurred in any instance of the transaction. A path map built in the manner described above incorporates characteristics and restrictions worthy of note. First, since each path, represented by a single PECB chain built in step 802, is reduced based on the results of PECB chains which were previously processed, a different path map, and consequently a different output diagram, may result if the transaction data were processed in a different order. Specifically, the configuration of the ultimate path map is a function of the order in which the recorded instances of the transaction are processed. Nevertheless, the main path would be substantially the same since determination of the main path is based on the content, in addition to the sequence, of the event data as discussed below. In addition, it is preferable to ensure that PECBs do not contain both multiple forward pointers and multiple backward pointers. If a PECB did contain both multiple forward and multiple backward pointers, this would indicate a "crossing point" or overlap between two paths. As a result, it would not be possible to determine the true path taken by a transaction by following the path map from the beginning to the end. Accordingly, it is preferable to ensure that a PECB which has more than one forward pointer has only one backward pointer, and likewise, that a PECB which has more than one backward pointer has only one forward pointer. It will be noted that a PECB on the path map containing more than one backward pointer indicates a "merge point" of two or more transaction paths, while a PECB with more than one forward pointer indicates a "split point" where a single path splits into two or more transaction paths. To facilitate following the path map accurately, it is therefore also preferable to ensure that there are no paths in which a split point occurs after a merge point. The next phase of analysis component 106 of the invention is the presentation phase 504 as shown in Fig. 5. Referring now to Fig. 14, presentation phase 504 begins with a step 1402 wherein the average event duration for each event represented by a PECB on the path map is calculated and stored in each PECB. In particular, after data reduction phase 502 is complete, each PECB in the path map contains the accumulated event times for all of the instances in which the event was executed in its sequence on the path map, as well as the total quantity of event occurrences. In each PECB, the total accumulated event time is divided by the total quantity of event occurrences to obtain the average event duration for that event, which is stored in that PECB. This average event duration will be used in the output component 108. In addition, the shortest and longest average times of all of the PECBs on the path map are maintained for use in determining the proper scale factors for the final display in the output component 108 as will be described below. The start locations for each event in the ultimate output diagram are next determined in step 1404. One dimension of the output diagram will be the duration of the recorded transactions and the events comprising them. Since each path in the path diagram contains a series of sequential events, the placement of each event in the output diagram depends on the placement of those before it in the path. The start location for each event is determined in the following manner. Each transaction consumes a certain amount of time prior to the occurrence of the first recorded event. This time is known as the default start time and is stored in the header PECB in the path map. Likewise, each transaction consumes a certain amount of time after the occurrence of the last recorded event, which is stored in the trailer PECB. For each path leading from the header PECB, the first PECB in the path is selected. The start location for this first path element is set to the default start time as described above. A forward pointer of this PECB is then used to select a next PECB in the path. The start location for this PECB is calculated as the start location from the previous PECB plus the average event duration of this PECB, and this sum is stored as the start location for this PECB. Processing continues in this manner working forward along the path to the last, terminal PECB. It should be noted that due to the possibility of splitting and merging paths, it will be necessary to indicate which path segments have been processed for start location and which still require processing after reaching the terminal PECB. This indication is preferably accomplished by monitoring whether the previous PECB contains more than one forward pointer, thus indicating that the present PECB is the first PECB in one of a plurality of branching paths emanating from the previous PECB. When such a condition is found, the start location values stored in each PECB from the previous PECB backward to the first PECB in the path may be cleared. This will indicate that the path needs to be processed again, and the start location values retained in the present PECB will indicate that another branch should be processed when this PECB is again selected. The indication that other branching path segments require processing may be indicated by other means, such as by the use of flags or recursive processes, for example. Conversely, if while processing along a path a block is found which already has a start location time stored in it, then this PECB is a merge point for several paths. The start location time for this PECB should be calculated in the normal manner described above, and preferably the higher of this calculated value and the value already stored in this PECB should be retained in PECB. Storing the higher value ensures that the PECBs contain the latest start location time for all possible paths. This is preferable because it allows all connecting lines drawn in the output diagram to point forward along the time dimension (typically downward on the output medium) which presents a more readable and understandable output diagram. This also ensures that the start location time contained in the terminal PECB will be the value of the longest path on the path map, which can be used to scale the output diagram in the time dimension in the output component 108. After the average event durations and the start time locations of the events in the path map are determined in steps 1402 and 1404, the information necessary to determine the relative vertical positioning of each element on the output diagram has been determined. The final task for the presentation phase 504 is to determine the horizontal position of each element as shown in step 1406 of Fig. 14. Determining the horizontal positioning of each element requires determining a main path through the path map in a step 1408, determining a longest path through the path map in a step 1410, and allocating a location for all remaining paths through the path map in a step 1412. Steps 1408 and 1410 may be performed in any order. Fig. 15 illustrates a preferred method for selecting the main path. The main path through the path map is determined to be a path which connects those events which were executed with the highest frequency as reflected in the event count information in each PECB. Beginning with step 1502, the PECB in the path map connected to the header PECB which contains the highest event count is selected. Likewise, in step 1504 the PECB connected to the trailer PECB which contains the highest event count is also selected. Using the forward and backward pointers in step 1506, a search is conducted to determine whether a common path exists between the PECBs selected in steps 1502 and 1504. If a common path does exist as determined in determination 1508, then the PECBs along this common path, together with the PECBs selected in steps 1502 and 1504, comprise the main path. If a common path is not found in steps 1506 and determination 1508, then the main path may be selected by, for example, working forward using the PECB forward pointers from the PECB selected in step 1502 toward the trailer PECB, and selecting, after each PECB with multiple forward pointers, a PECB for the main path which has the highest event count. Alternatively, where multiple forward pointers are found, the longest path may be chosen as the main path to enhance the readability of the output diagram by ensuring that connections among events can be easily routed without crossing each other. After the main path has been determined, an indicator or flag in each PECB along the main path is set in step 1512. There are a variety of methods for defining and determining a main path through the path map. It is to be understood that any method for determining a main path is encompassed by this invention, so long as the main path reflects some information about the relative frequency of the occurrence of the events on that path with respect to other paths on the path map. The longest path through the path map is preferably determined in step 1410 in the following manner. Starting at the trailer PECB, backward pointers are used to find the preceding PECB on the path map wherein the sum of the start location time and the event duration equals the start location time for the current PECB. This process is continued until the header PECB is reached. Another indicator or flag is set in each PECB on the longest path. The main path and longest path are useful for plotting the final output diagram. In particular, the main path will preferably be shown as a vertical column of event symbols positioned in the center of the output diagram and the remaining path segments will be placed to the left and right of the main path. The longest path, if it is not also the main path, will preferably be placed on the output diagram at the farthest horizontal distance from the main path. This allows connecting lines from the remaining path segments to be drawn to the main path without having to be drawn through the longest path itself, thereby enhancing the readability of the output diagram. Gathered data can include any relevant statistical data which can be measured, for example, I/O data quantity, data transmission rates, memory/storage usage during program execution, etc. As such, the present invention should not be interpreted as directed only toward event duration, i.e., time, and frequency of occurrence. The final step of presentation phase 504 is step 1412 in which the horizontal positions of all paths other than the main and longest paths are allocated in such a way as to minimize the number of connecting lines between events which would cross one another. As shown in Fig. 16, allocating the positions of these paths is preferably accomplished by analyzing the path map and searching for certain predictable categories of paths and path segments based on their relationship to the main path determined above. As these paths and path segments are found, they will be located alternately on the output diagram to the left and right of the main path to balance the appearance of the final output. The general layout of the final output diagram involves placing the main path in the center of the output diagram and placing the remaining path segments to the right and left of the main path. As used herein, "placing" a path or path segment means either determining the relative location of the path or path segment on the output medium or actually depicting its representation on the output medium. Events will be represented by event symbols on the output diagram and the relationship between events may be represented by connecting lines between events, adjacency of event symbols or by other appropriate depictions. The output diagram may be conceptually divided into a number of vertical columns spaced at a horizontal distance away from each other as desired based on the size and shape of the event indicators chosen for the output diagram and the width of the output medium. After the main path is placed, each path segment processed in the presentation phase 504 is generally placed in a column further away from the main path than the path segments processed before it. Each path segment will be assigned a column number representing a particular column of the output medium. One method for separating the path segments to be placed to the left of the main path from those to be placed to the right of the main path is to assign odd column numbers to path segments to be placed to the right of the main path and even column numbers to path segments to be placed to the left of the main path. These column numbers are preferably stored in the respective PECBs in the path map comprising the processed path segment. The column numbers will ultimately be used to place the event data on the output diagram and to assist in drawing connecting lines as required between sequential events on the output diagram. The readability and understandability of the output diagram may be greatly enhanced by choosing the placement of path segments so as to eliminate, as much as possible, connecting lines which cross through other path segments (including their event symbols and connecting lines) on the output diagram. One method for achieving this is to create a path segment plot table data structure for allocating the path segments comprising the output diagram to the left and right sides of the main path. The plot table preferably contains an entry for each path segment to be placed on the output diagram. Each plot table entry preferably includes the column number assigned to the associated path segment, the start location of the first event of the path segment, and the end location of the path segment. The end location is generally defined as the start location of the last event in the path segment plus the event duration of the last event of the path segment. As each path segment is processed, its placement on the output diagram to the left or right of the main path depends on the path segments previously processed, which can be readily ascertained from the plot table. It may be possible to allocate more than one path segment per column on the output diagram where the path segments do not overlap each other in the time dimension. For example, if one path segment ended at a time of 10.0 and second path segment began at a time of 12.0, these two path segments could be placed in the same column without overlap. Allocating non-overlapping path segments in this manner allows the information presented in the output diagram to be placed more densely in a given area of the output medium. In particular, the quantity of information displayed in a given column of the output diagram is increased. In some cases, this increase in information density may make the output diagram more readable, while in other cases too much information might be placed on a particular page or screen of the output medium thus hampering ready understanding of the relationship of the events depicted. The decision as to whether to depict more than one path segment in a particular column of the output diagram for a particular output diagram should be based on these countervailing considerations and on the specific data to be depicted. The output diagram generally comprises event symbols and connecting lines. Connecting lines will be depicted on the output diagram between event symbols to show the sequential relationship of the depicted events to one another. Likewise, connecting lines will be drawn between various path segments (sequential groups of connected events) on the output diagram to show how sequences of events transpire from one path segment to another. The connecting lines between events within a path segment are generally drawn vertically downward from one event to the next event on the output diagram in the time dimension. Connecting lines between path segments are generally drawn directly left or right to the beginning or from the end of the connecting path segment. In most cases, a connecting line will exist at the end of the path segment connecting it to another path segment. However, it may also be the case that a connecting line is drawn from an event within a path segment to another path segment. That is, there may be more events, and consequently more PECBs in the path map, following an event from which a connecting line is drawn which have the same path number and column number such that they will be placed immediately below the event in question on the output diagram. In such cases, it will be necessary to draw a short connecting line either left or right of the event in question before drawing the connecting line in the vertical dimension to the remaining event symbol or symbols for the currently processed path segment. When selecting the appropriate side of the main path to position a new path segment, it is preferable to determine whether the connecting line to and/or from a path segment can be drawn directly to the point to be connected, or if the connecting line might pass through a path segment which has already been placed on the output diagram. This can be determined by checking the data in the path segment plot table data structure described above. In particular, if the location of the connecting line lies between the start and end locations of any path segment on one side of the path map, the connecting line would have to be drawn through that path segment. This would be undesirable because it would present overlapping and convoluted paths on the output diagram which would impair the readability and understandability thereof. To prevent such a result, the path segments on the other side of the main path are checked. If the connecting line would pass through a path segment on the other side of the main path as well, a left/right preference indicator is checked to see where the next path segment should be placed to balance the depicted path segments on the left and right of the main path. Each time the left/right preference indicator is used, it is "flipped" to indicate the opposite preference for the next time it is checked. For example, if the left/right preference indicator currently indicates "left" and is then used to place a path segment, it is flipped to "right" after such use. The new path segment is placed on the preferred side indicated by the left/right preference indicator by creating an entry in the path segment plot table with the next column number for that side and the start and end locations for this new path segment. If connecting lines for this path segment are still blocked by path segments on both side of the path map, then a special connecting line or other symbol would preferably used to indicate the connection across a path segment on the output diagram. As shown in Fig. 16, the horizontal location determination 1406 preferably begins with a step 1602 in which paths which split from the main path and later merge with the main path are located. This type of path segment will have two lines connecting it to the main path on the output diagram and therefore should be handled first in order to have access to the most free space available on the output diagram to draw the connecting lines. This type of path segment is also most likely to have a close relationship to the logic of the main path itself, and it is therefore preferable to position this path close to the main path for ease of comparison. These path segments are found by checking each PECB on the main path to determine whether it has more than one forward pointer. If so, the pointer or pointers leading to PECBs not on the main path are followed to determine whether any PECB along that path segment contains a main path flag, indicating that the path segment has merged with the main path. Alternatively, the main path PECBs could be checked for the presence of more than one backward pointer, and the associated path segments not on the main path could be followed backward to determine whether any of the PECBs on such path segments contain a main path flag. Paths which split from the main path and merge with no other paths are preferably allocated next in step 1604. These are paths which split from the main path and connect directly to the trailer PECB. This type of path segment is a highly likely occurrence. Therefore, such path segments should also be placed near the main path on the output diagram. Starting with the first main path PECB and working forward along the main path, each main path PECB is checked for the presence of multiple forward pointers. When found, the path or paths beginning with a PECB not on the main path are followed forward until the trailer PECB is reached or another PECB with multiple forward pointers is found. If the trailer PECB is reached, then a desired path which splits from the main path and joins no other paths has been found, and this path is added to the output diagram. If instead multiple forward pointers are found, then this path is not selected at this time because it has other branches and is reserved for processing in another step. It should be understood that, although paths are checked in a forward manner in step 1604, both forward and backward checking is needed as part of the overall processes used to identify all paths. The next paths to be located in step 1606 are those which begin at the header PECB and merge with the main path only. These paths merge with the main path and connect to no other paths. Using the forward pointers in the PECBs, each path leading from the header PECB is followed forward. If any element on the path has multiple forward pointers, the path is skipped in this phase and will be processed later. If a main path element is found on the path being followed, the path is selected for processing at this time. The next paths selected for processing are those which split from the main path and merge with paths other than the main path as determined in step 1608. The main path is followed forward from the header PECB as described above with respect to steps 1602 and 1604. When a main path PECB with multiple forward pointers is found, the pointer or pointers to a path segment not on the main path are followed forward. This path segment or these path segments will have a path number different from the main path. These paths which split from the main path are followed forward, and if a PECB is reached which has yet a different path number from that being followed, then this indicates that the path segment being followed has merged with another path. Once such a path segment has been identified, it is advantageous to process all path segments connected to this one which have not yet been processed before searching for another segment relating to the main path in order to keep all interconnected paths on the same side of the main path on the output diagram to reduce crossing connection lines between events. Likewise, paths which split from paths other than the main path and later merge with the main path are processed in step 1610. These paths are located and processed in the same manner as those described in step 1608, with the exception that main path PECBs with multiple backward, instead of forward, pointers are located to find where such paths may merge with the main path, and these paths are followed backward in an attempt to determine whether they split from paths other than the main path. As with the paths identified in step 1608, all path segments connected with this type of path identified in step 1610 should be processed at this point so as to group these paths on the same side of the main path in the output diagram to minimize connection lines drawn through the main path itself on the output diagram. Paths which have no connection to the main path but do connect to other paths are next processed in step 1612. As these paths have no relationship to the main path, they can be processed in any order. However, these paths should be grouped together on the output diagram with the paths to which they connect to minimize the crossing of connection lines on the output diagram. Paths which do not connect with the main path or to any other paths are then processed in step 1614. These paths begin at the header PECB and proceed forward and connect only with the trailer PECB. These paths have no other branch points, and therefore each PECB in such a path has only one forward and one backward pointer. Since these types of paths are not related to any of the other paths on the path map, they are preferably placed on the output diagram near the outside or edge of the display area as there will be no connections from these paths to any other paths on the diagram. Finally, each PECB is checked in step 1616 to ensure that it contains a column number indicating that it has been processed in one of the steps above. Any PECBs or paths not already processed are processed at this stage. Once all PECBs have been processed as described above, presentation phase 504 is complete, and the final output component 108 may be executed. In the case where one or more of the programs for all or a part of a transaction are concurrently executed on multiple computers within the enterprise, the computer program profiler 102 can present statistics to the user segmented both by process and processor. For example, a transaction may consist of multiple processes divided among multiple computer systems. It is further possible that some of these systems are capable of executing the same process. A given transaction, therefore, can take multiple paths throughout the enterprise. As a result, the results obtained for a particular transaction will differ due to the mix of computer systems, depending on which system executed a particular process. This is due to the fact that different computer systems may have different processor speeds, communication speeds, CPU utilization levels, peripheral input/output capabilities, etc. Although it is possible that multiple CPUs can exist in the same computer, it is more likely that transactions will occur across a network when multiple computer systems are used to support a transaction. For example, the movement of data packets over a network, particularly the Internet, is a transaction when that movement is considered in its most basic form. In that case, each network node can have a program running to capture statistics regarding particular transactions. These statistics can be reported and presented to a user as described above. This allows a user to view the process flow in terms of network activity, network routing, network loading, etc., by transaction or one or more types of transactions. In order to analyze the operation of a network of computers, transactions must be defined for the various nodes and incorporated by monitoring programs on the relevant nodes. As discussed above, transactions can therefore be defined and distributed across multiple nodes, and monitored using the aforementioned techniques of the present invention. For example, network nodes perform transactions defined by data contained in the network transmission protocol. The present invention can be applied to the Internet in which new protocols are being devised and refined to support particular communication needs. Examples include File Transfer Protocol (FTP) for transferring files, Hypertext Transfer Protocol (HTTP) for accessing Internet web pages, Simple Mail Transfer Protocol (SMTP) for transporting electronic mail messages, etc. The overall performance of the system based on these transactions can be profiled by defining the transactions to gain knowledge as to how much time is taken in executing these transactions across a network. An example of defining transactions as distributed across multiple network nodes will be described with reference to Figs. 17 and 18. Fig. 17 shows an example of a network used to transport electronic mail ("e-mail") messages. As used throughout this example, the term "transaction" refers to both the overall process of sending an e-mail from one node to another (an "e-mail transaction") as well as the individual transactions occurring in each host node, i.e., forming a packet, sending a packet, receiving a packet, etc. Both types of transactions can be profiled using the subject invention. As shown in Fig. 17, a network 2100 is comprised of Host A 2102, Host B 2104, Host C 2106, and Host D 2108 interconnected by a series of links 21 lOa-e. Each of Hosts A-D 2102-2108 is capable of sending, receiving and forwarding electronic mail messages. For example, Host A 2102 can transmit an electronic mail message to Host D 2108 by assembling a message and transmitting it via link 2110a to Host B 2104 or link 2110b to Host C 2106. Host B 2104 or Host C 2106 can then route the electronic mail message to Host D 2108 via its respective link 2110c or 21 lOd. In a case where there is congestion or a transmission impairment on one of the links 2110c or 2210d, Host B 2104 can route the electronic mail message to Host C 2106 via link 21 lOe for subsequent transmission to Host D 2108. Thus, in the process of composing and routing the electronic mail message, routing might take several hops from node to node, and various segments of the message which have been assembled into multiple packets could take different paths in reaching their destination prior to reassembly in Host D 2108. It is desirable, therefore, to be able to monitor the transactions in Hosts A-D 2102-2108 in order to determine the performance levels of the various Hosts such that their operational programs can be updated as necessary to maximize use of their resources, and to maximize network performance. By way of further illustrating how a path map would present a representative picture of network operations, assume that each Host A-D 2102- 2108 has certain basic transactional capabilities defined as: send a message (SM); receive a message (RM) - store the complete message; packetize a message for transmission (PM); re-assemble packets into a message (AM); forward packet to host 'X' (FPX); receive packet from host 'X' (RPX) and send packet to host 'X' (SPX). The overall process of sending and receiving an electronic mail message is a combination of these transactions. To send a message from Host A 2102 to Host D 2108, each Host has certain transactions: • Host A 2102: PM Host A 2102 → SPB 2104 PM Host A 2102 → SPC 2106 • Host B 2104: RPA 2102 → FPD 2108 RPA 2102 → FPC 2106 RPC 2106 - FPD 2108 • Host C 2106: RPA 2102 - FPD 2108 RPA 2102 → FPB 2104 RPB 2104 → FPD 2108 • Host D 2108: RPB 2104 → AM Host A 2102 RPC 2106 - AM Host A 2102 A path map would therefore present a representative picture of network operations for these types of transactions showing network performance and possibly overloaded or under utilized paths, routing, etc. Fig. 18 depicts the paths a message might take. Where Host A 2102 has a send e-mail process 2112, and Host D 2108 has a receive e-mail process 2114, a path map can be constructed using the basic transactional capabilities described above. One path of the numerous paths from send e-mail 2112 to receive e-mail 2114 is described as follows. Host A 2102 has a send message transaction 2116 which feeds a packetize message transaction 2118. The packetize message transaction 2118 disassembles the message into subparts for transmission through the network. The packetize message transaction 2118 sends one or more of packets to the send packet B 2120 transaction. Send packet B 2120 causes the packet to be transmitted on the network to Host B 2104. On Host B 2104, the receive packet A transaction 2122 receives the packet from Host A 2102 and, for example, executes a forward packet D transaction 2124 to cause the packet to be forwarded to its destination node, Host D 2108. On Host D 2108, a receive packet B transaction 2126 receives the packet from Host B 2104 and executes an assemble message transaction 2128 to reassemble the packetized message. Assemble message transaction 2128 reassembles packets comprising the message from various receive packet transactions, such as the receive packet B transaction 2126 and the receive packet C transaction 2130. Receive message transaction 2132 represents the terminus in the path map. Note that packets could be sent from Host B 2104 to Host C 2106 and vice versa rather than being forwarded directly to Host D 2108. Depending upon network traffic, a direct transmission to Host D 2108 might not be as responsive as routing it through another host and then on to the Host D 2108. For example, network link 211 Od from Host C 2106 to Host D 2108 may be experiencing transmission errors, or the connection speed may be significantly slower than if the packet were routed through Host B 2106 and then on to Host D 2108 via link 2110c. As is shown in Figure 18, a complete and comprehensive path map depicting all of the various transactions required within each node to effect the transmission and receipt of an electronic mail message can be created using the subject invention. This allows system owners and designers to effectively manage their resources, even resources distributed across a computer network. In addition to using the present invention to create a path map depicting all of the transactions within each node as was described above with reference to Figs. 17 and 18, event data surrounding the network-based transactions can be profiled. The preferred sequence of steps for performing the output component 108 is shown in Fig. 19. Because the presentation of the output on the physical output medium is partly dependent on the characteristics of that medium, the first step of the output component 108 typically is to determine the specifications of the output medium as shown in step 1702. For example, if the output medium is paper which will be printed upon by a printer attached to the computer embodying the invention, the specifications might include the dimensions of the paper, the printer type or make and model, the characteristics of the fonts available for use on the printer, etc. These specifications are typically specified by the user but may be obtained from other sources, such as configuration files stored on the computer embodying the software running the output component 108. After the output characteristics are defined, the output data calculated in the analysis phase 504 is further modified by the given media characteristics in step 1704. At this point, any scaling necessary to relate the output diagram to the dimensions of the physical medium is performed. The data necessary to plot each event on the output diagram exists in each PECB in the path map. However, the output data for each event exists in raw form and must be scaled to the dimensions of the physical output medium chosen by the user, such as the dimensions of paper on which the output diagram is to be printed if the user desires a paper copy of the output diagram. In particular, it is preferable in many cases, especially when the output is to be printed, that the length and width of each path element (representing each event or loop event) be related to "point" sizes for output processing. Point sizes are a standard printing convention wherein each point represents 1/72 of an inch. The first dimension represented on the output diagram is the time dimension. The time dimension is preferably displayed vertically on the output medium with time increasing from the top to the bottom of the output medium, although the time dimension may instead be displayed in other orientations, such as horizontally, for example. Each succeeding event is displayed below its immediate predecessor. The length of the longest path, as determined above in step 1404 and stored in the trailer PECB, is preferably used to determine the overall length of the time dimension to be shown. It will also be necessary to scale the output diagram to ensure that the shortest event duration is visible on the output diagram. For example, a minimum length of at least one quarter of an inch may be specified as a length for the shortest event duration. Dividing the shortest average event duration of all the PECBs on the path map into the total time consumed by the longest path and dividing by four thereby yields the length of the longest path in inches on the output diagram. The result of this calculation can be used to determine whether the longest path will span more than one page (if printed output is specified) or screen (if video display is specified). If more than one page or screen is required, the time location of a breakpoint between such pages or screens must be maintained to properly determine which events will appear on which page or screen. A separate symbol or other indication may be necessary to identify a connection between events on different pages or screens. The second dimension shown on the output diagram corresponds to the event count for the depicted events, or the number of times each event was executed in all of the recorded transactions. Where the time dimension is displayed in the vertical dimension of the output medium, this second, event count dimension is preferably displayed in the horizontal dimension of the output medium. There are two steps in scaling the information in the event count dimension. First, the width of each event symbol (when the event count is shown in the horizontal dimension) depicting a recorded event must be related to the event count for that event. A maximum width is chosen for any event symbol based on the specifications of the output medium as determined in step 1702 of the output component. For example, a maximum event symbol width of one-half of an inch might be chosen. Although not necessary, start and end event symbols are preferably depicted on the output diagram denoting the beginning and end of the time dimension represented in the output diagram. These start and end symbols may be related to the header and trailer PECBs in the path map. Accordingly, the start and end symbols, if used, would have the greatest event counts of all event symbols on the output diagram and, in particular, would each have an event count equal to the number of transaction occurrences recorded. Accordingly, in the instant example, these start and end symbols would be set to the maximum width of one-half of an inch. The width of every other event symbol to be depicted on the output diagram, each of which coπesponds to exactly one PECB on the path map, is calculated as a fraction of the maximum width based on the ratio of the event count of the event to the total number of recorded transaction instances. For example, if a particular event was found to have an event count of 2, and 8 total transaction instances had been recorded, the width of the event symbol for this event would be one-quarter of the maximum width chosen for the event symbols, or one-eighth of an inch in the example described above. The second step for scaling the event data information in the event count (and, in this example, the horizontal) dimension is to determine the position of the columns allocated for each event in step 1406 on the output medium. A minimum column spacing between adjacent columns is preferably set. The minimum column spacing is based on the maximum width of all the event symbols to be depicted on the output diagram (except for the start and end symbols, if any), the space needed to draw connecting lines in the direction of the time dimension between columns, and any space necessary to print desired text describing the event data. The text spacing will be based on the font size used. The arrangement of the columns can then be determined based on the minimum column spacing, the number of columns of data to be depicted (which may be determined from the path map or the path segment plot table data structures) and the width of the physical media. If the media width is greater than the sum of the column space required, the columns may be further adjusted to be spaced farther apart and to thereby make maximum use of the media as desired. If, however, the media width is less than the sum of column space required, the output diagram must be divided into multiple pages of screens of the output media in the event count dimension. This may be accomplished by, for example, selecting one or more pages to represent the event data to be placed to the left or right of the main path as necessary. For example, if two output media pages are necessary to depict the event count dimension, a first page could be used to depict the columns placed to the left of the main path and a second page could be used to depict the columns placed to the right of the main path. The main path is preferably included on both such pages near the right or left edge thereof. Where multiple pages are also required to represent the time dimension, it is preferable to print all pages in sequence for the events on one side of the main path first, and then to print all remaining pages in sequence to depict the events plotted on the other side of the main path. After scaling has been performed, the actual output begins in step 1706 by printing header information on the output medium, preferably at or near the top thereof. This header information is not necessary but may be output to provide useful information about analyzed transactions, such as the time period specified for analysis, the number of events executed within that time period, the date of the report, a page number, etc. The event-specific data is then plotted on the output medium for each event recorded for the analyzed transaction in step 1708. The output diagram will usually contain a combination of graphics and text. The output process for the event data preferably proceeds by specifying planar coordinates for each item (such as an event symbol, associated text, or a connecting line) on the output medium. The average event duration and event count for each event may be displayed as an event symbol having a width corresponding to the event count and a length corresponding to the average event duration. The placement of the event symbol is determined by its start location and column allocation previously calculated and stored in the PECB representing the event in the path map. Since each event represented in the path map was allocated a start location based on the latest value of its start time, all connecting lines can be drawn forward through the time dimension (in the present example, downward through the output medium) and either to the left or to the right to connect with other event symbols. Each PECB in the path map contains sufficient data to specify its placement on the output diagram. The scaling factors determined earlier are now applied to the data in the PECBs, and the event represented by each PECB may now be plotted on the output medium as an event symbol based on the data in that PECB. The PECBs of the path map may be processed in any order since each PECB contains all of the data necessary, in combination with the scaling factors and output medium characteristics as described above, to plot the event represented by the PECB on the output diagram. The start location and average event duration fields of the PECBs are used to determine the vertical coordinates of the event symbols. The column identifier and event count fields are used to determine the horizontal coordinates of the event symbols. Each PECB is preferably marked with a completion indicator after the event which it represents has been placed on the output diagram. As described above, event symbols plotted in the same column on the output diagram are preferably depicted adjacent to one another in the vertical dimension to show their sequential relationship, and connecting lines are preferably drawn only to show the sequential relationship among path segments plotted in different columns of the output medium. The pointers in the PECBs of the path map are used to determine if a connecting line is to be drawn from the currently processed event symbol to an event symbol in another path segment or column of the output diagram. For example, if the PECB pointed to by the forward pointer of the current PECB has a different column identifier than that of the current PECB, or a start location greater than the end location (the start location plus the average event duration) of the current PECB, then a connecting line must be drawn on the output diagram. If the column identifier in the next PECB is the same as that for the current PECB, then the event symbol for the next PECB will be plotted in the same column below the event symbol for the current PECB. It should be noted that in some instances where more than one choice exists for including a path segment on the main path, the decision as to which path segment to include was preferably based on the event count for the events in the path segments in the path segment, with the path segment having the greatest event count being chosen. This could lead to event symbols on the main path of the output diagram which are not adjacent to one another. In such a case, a connecting line may be required between event symbols even on the main path itself. While traversing the path map to plot the event data, multiple forward pointers will generally be found to exist in certain PECBs. When a multiple forward pointer PECB is selected, if the column number of the PECB pointed to by one of the multiple forward pointers is the same as the column number for the selected PECB, then the event symbol for that next PECB is displayed below that for the current PECB. If the column number is not the same, a short connecting line should be drawn to the left or the right of the event symbol for the current PECB as required and the remainder of this connecting line should be drawn as described below. As described above, the preferred output path map is a sequence of lines of varying widths and lengths used to denote frequency of occurrence and time length of occurrence, respectively. There are a number of alternative ways that the output map can be expressed in order to effectively represent the transactional paths along with the frequency and duration data for each event. In particular, the use of color, greyscale and shading patterns can be used separately or in combination in the output path map to distinguish frequency of occuπence data, and possible time length of occurrence data. For example, the main path can be set apart from the other paths by presenting the main path in a color other than that used for the other paths. In addition, the use of color, greyscale and shading can ease display restrictions caused by line width in producing a map containing numerous paths on a display or a printer. These presentation alternatives are particularly important and useful when the output is large and needs to be scaled to fit on one output page or display screen; techniques for which are described below. As an alternative to altering the width of the path elements, color graduations can be used, for example, from black to red. Different frequencies or time lengths of occurrence are individually represented different colors, or are grouped within a banded range, such that each range is represented by a particular color. Color changes can also be implemented in proportion to line width or length by varying the hue at a fixed luminosity and saturation. For example, white can be used to represent the smallest value and black the largest, or violet can be used to represent the smallest value and red the highest. As another alternative, greyscaling and/or shading can be used separately or in combination with color. Color can be used as described above on a color monitor, with the printed output being represented using greyscaling or shading. Colors, greyscales and shading can be used to distinguish combinations of high event occuπence quantity and/or high event durations to indicate potential bottlenecks. For example, the value of event occurrences multiplied by event duration can be represented by varying colors, greyscales or shades (or combinations thereof) for values within a group of banded ranges. Using this approach, a user can quickly identify problematic areas. By setting the uppermost band to red, for example, a user is quickly alerted that the depicted event requires further attention. As described above, the preferred method for presenting event duration data is via the length of the output path element. However, transactions spanning a long period of time may not fit onto one page and may cause the output map to extend onto multiple pages, or require a display window to be scrolled to view the entirety of the output map. The present invention overcomes this potential limitation in several ways. The user can select from a suite of "time rulers" or customize his own. A "time ruler" defines how time should be mapped, i.e. scaled, onto the output. "Time rulers" can be linear such that one distance unit equates with one time unit, for example, inches to tenths of seconds. "Time rulers" can also be logarithmic such that the length of the event output equals: Z*log(l + time) where Z is a scaling factor defined by the user. "Time rulers" can also be defined parabolically such that the length of the event output equals: Z*(a + sqrt(b + c*time)) where a, b and c are parabolic constants defined by the user. Similarly, a user can select from a suite of "event rulers" or customize his own in order to scale event frequency of occurrence output. Of course, rulers are not limited to "time rulers" and "event rulers." A ruler can be created to scale any event variable being expressed vertically (time in the example described above) or horizontally (frequency of occurrence in the example described above). The present invention also allows a user to specify a magnification factor to expand or shrink the output map to occupy an entire page or display window. The output can be scaled using a magnification factor such that one or both of the event duration (length) or the event occurrence (width) dimensions can be enlarged or shrunk. In the case where a magnification factor is applied to a large output path map to allow it to fit on one page or display window, the resolution of the output path map decreases. Color, greyscaling and shading can aid the user's ability to ascertain differences between event symbols when presented with a low resolution path map. For example, a color such as red can be used to indicate particularly important event symbols such as areas of high processing activity. A user can then "zoom in" on this area by establishing new or refined viewing criteria and be presented with a higher resolution view of the event symbol and its smrounding symbols in order to better ascertain the problem. In addition to the path map, other data, both captured and calculated can be presented to the user in the form of output tables, charts, graphs, reports, etc. The data includes but is not limited to: 1) the identify of each operation such as the nature of the I/O, service request, etc.; 2) the identify of the dataset or database under operation; 3) statistics relevant to the elapsed time, CPU time, and other resources consumed by that operation, such as main and secondary storage. The statistics can represent averages, medians, modes, maximums, minimums, standard deviation, etc., depending on the user's requirements; 4) the number of times and relative frequency that an operation occurred; 5) the operation or series of operations immediately following a particular operation; and 6) the sequence of operations for a particular transaction. These statistics, in conjunction with the path map, facilitate the asset management of the hardware and software resources being monitored. The multitude of types of outputs allow an efficient and expedient means for maximizing the use of these expensive assets. After the event elements have been output, the connecting lines showing how the event elements precede or follow one another are drawn on the output medium in step 1710. These lines show the interaction between the recorded events and connect the event symbols on the output diagram based on the pointers in the path map. The connection lines may also be used as an alternative indicator for representing the event count or event duration of the events on the output diagram (by varying the width of the connecting lines based on the event count of the events connected by the connecting lines, for example) if this information is not represented in the display of the event symbols themselves. The connecting lines are drawn as follows. When drawing connecting lines, the current block identifies the start point and the next block identifies the end point. When a block starts at the same horizontal level as the current end point, the connecting line is a horizontal line to the new block start location. The column information of the next block is used to determine whether the connecting line moves right or left. When the start location value of indexed block is directly below, the connecting line is drawn vertically down to the start location value of that next block. When the column number of the block containing the next connection point is one greater or one less than the column of the current block, a line is drawn directly to that connecting block since there is no intervening column of data. A connector is drawn when the connecting column is on the opposite side of the main path. When the connecting column is more than one column away from the current block, the various path segments must be checked for intervening column numbers. Intervening paths found for data elements which exist in a horizontal path, i.e., the path line would cross that data element, must be determined. If no intervening paths exist, the line is drawn directly. If an intervening path segment exists in the area where the connecting line will pass, a connector must be used. If a connector is required, a short line is drawn in the direction of the next block and a connector drawn thereon using an appropriate symbol to identify the connection. The corresponding connector is drawn at the target point a short distance from the connector point and a line is drawn to the connector point. The line segment need not be drawn on the chart prior to the connector since the path element control blocks contain all of the necessary data needed to plot the line segment. When connectors are required, the identifier assigned to the connector and the location on the page of the connector must be tracked. If a connector is needed, a determination must be made as to whether a connector value has been assigned. If a value has not been assigned, the next connector identifier value is assigned to that connector. Once all of the data segments have been plotted, text describing the events can be added to the output display. Information in the control block is used to place the descriptive text to the side of the segment it describes, midway down the line segment. A flag is added to the descriptive text if there is looped data for that event. Where looped data for an event exists, an additional page is created and the header information from the display page is repeated. Any looped data for the events is then printed, in which the looped data contains the event description, total time spent in the looping event and the quantity of times the event looped. Finally, after all of the event elements and connecting lines have been drawn, summary and/or error messages may be printed at the end of the output medium in step 1712. The summary information and error messages are not necessary, but may include useful information for the user such as which events were involved in looping situations, the total time spent in the looping events, the number of repetitions of the loops, and the like. Although the present invention has been described in relation to particular embodiments thereof, many other variations and modifications and other uses will become apparent to those skilled in the art. It is prefeπed, therefore, that the present invention be limited not by the specific disclosure herein, but only by the appended claims.

Claims: WHAT IS CLAIMED IS: 1. A method for profiling one or more operational characteristics of a computer program, said computer program performing one or more transactions, at least one of said transactions having at least one event, said method comprising the steps of: gathering event data corresponding to one or more of said transactions; constructing a path map from said gathered event data, said path map representing program operation performance relationships between said gathered events, said path map being arranged in order of execution; and creating an output, said output being created based on said path map. 2. A method according to Claim 1, wherein said gathering, constructing and creating steps are performed by at least two processors. 3. A method according to Claim 1, wherein said data gathering step includes the step of allowing a user to specify one or more data gathering criterion. 4. A method according to Claim 1, wherein said output is created in accordance with one or more filtering criterion specified by a user. 5. The method according to Claim 1, wherein said method is performed by a mainframe computer. 6. A method according to Claim 1, wherein said path map construction step comprises the steps of: selecting which of said gathered events is to be analyzed; sorting said selected events in order of event occuπence; building one or more event chains in which each of said event chains coπesponds to a sequence of sorted events occurring in an instance of said computer program; and generating said path map by assimilating said event chains into said path map such that only said event chains representing a unique sequence of sorted events are assimilated, said path map including data corresponding to a frequency of occurrence and a time length of occurrence for each of said sorted events. 7. A method according to Claim 1 wherein said path map comprises a plurality of path element control blocks linked together, each of said path element control blocks is comprised of: an event identifier for correlating said gathered event with a textual representation of said gathered event; accumulated statistical data for each of said gathered events; a path segment identifier indicating a path number for said gathered event; and a pointer, said pointer representing linking data to another path element control block. 8. A method according to Claim 7, wherein said accumulated statistical data comprises a frequency of occurrence and a time length of occurrence. 9. A method according to Claim 1, wherein said output comprises output data selected from the group consisting of display data, print data and storage data, said output being scaled in accordance with at least one of a first ruler and a second ruler, said first ruler defining a first mapping between first units and horizontal output distance units, said second ruler defining a second mapping between second units and vertical output distance units. 10. A method according to Claim 1, wherein said output depicts a path through said computer program showing the actual processing flow of said computer program, said output being comprised of: a header; a plurality of event symbols; and a plurality of textual data, each of said plurality of textual data describing a respective event symbol; a length of each of said event symbols corresponds to a ratio of an average total event duration for a respective gathered event to a sum of an average total event duration for all of said gathered events; and a width of each of said event symbols corresponds to a ratio of a quantity of occurrences for a respective gathered event to a sum of the quantity of occurrences for all of said gathered events. 11. A method according to Claim 9, wherein said first units correspond to time units and said second units coπespond to event frequency of occuπence units. 12. A method for analyzing at least one transaction of a computer program to determine the operational characteristics of said computer program, said method comprising the steps of: gathering event data coπesponding to one or more of said transactions in a manner having approximately no impact on the executional performance of said computer program; and creating an output based on said gathered event data, said output having operations presented in sequential order of execution and statistical data derived from said gathered event data. 13. An apparatus for profiling one or more operational characteristics of a computer program, said computer program performing one or more transactions, at least one of said transactions having one or more events, said apparatus comprising a processor capable of the following functions: gathering event data corresponding to one or more of said transactions; constructing a path map from said gathered event data, said path map representing program operation performance relationships between said gathered events, said path map being in execution-time sequence; and creating an output, said output being created based on said path map, wherein said data is gathered in a manner having approximately no adverse impact on the operation of said computer program. 14. An apparatus according to Claim 13, wherein said processor is a mainframe computer. 15. A method for profiling one or more operational characteristics of a network of computers, said network of computers having a plurality of nodes each capable of executing one or more transactions, said method comprising the steps of: gathering data coπesponding to one or more of said transactions; constructing a path map from said gathered data, said path map representing operational performance relationships of said plurality of nodes based on said gathered transactions, said path map being in transaction execution sequence; and creating an output, said output being created based on said path map. 16. A method for profiling one or more operational characteristics of a computer program, said computer program having at least one event, said method comprising the steps of: substantially automatically initiating a gathering of event data coπesponding to one or more of said transactions upon detection of an execution of said computer program; constructing a path map from said gathered event data, said path map representing program operation performance relationships between said gathered events, said path map being aπanged in order of execution; and creating an output, said output being created based on said path map. 17. A method according to Claim 16, further comprising the step of storing in a computer memory at least one predetermined criteria defining, for said computer program, which of said event data constitutes said gathered event data. 18. A method according to Claim 17, wherein there are a plurality of computer programs and at least one predetermined criteria is defined, for at least one of said computer programs, indicating which of said event data constitutes said gathered event data. 19. A method according to Claim 16, wherein said gathering step is automatically halted, and said creating and constructing steps are automatically respectively initiated.

Inventors: BARRITZ ROBERT, COHEN GERALD, BARRITZ, ROBERT, COHEN, GERALD
Applicants: ISOGON CORP, ISOGON CORPORATION
Application year: 1999
Main classification: G06F11
IPC codes: G06F11