1. A computer-implemented method for monitoring an operation of a
transaction processing system, comprising steps of:
intercepting a first Application Program Interface (API) call;
examining said first API call, and if said first API call meets predetermined API call criteria, storing all or a portion of a content of said first API call as a first stored event;
intercepting a second API call;
examining said second API call, and if said second API call meets said predetermined API call criteria, storing all or a portion of a content of said second API call as a second stored event;
determining that said first API call is a part of a same particular business transaction as said second API call if:
(a) said first stored event indicates said first API call sent a message, and said second stored event indicates said second API call received said message, or
(b) said first and second stored events indicate said first and second API calls were conducted in a same transactional unit of work; and
if said first API call is a part of said same particular business transaction as said second API call, employing all or a portion of said first and second stored events in a subsequent process.
2. A method as in claim 1, wherein the API call criteria comprises system entity identity.
3. A method as in claim 1, wherein the API call criteria comprises API name.
4. A method as in claim 1, wherein the API call criteria comprises timing data.
5. A method as in claim 1, wherein the API call criteria comprises restrictions on parameter values to the API call.
6. A method as in claim 1, wherein the step of intercepting said first API call includes a step of operating a sensor that is automatically enabled for responding to an occurrence of an error condition or a change in program states or environments.
7. A method as in claim 1, wherein the step of intercepting said first API call includes a step of operating a sensor that is automatically enabled upon an occurrence of at least one pre-programmed triggering event, the sensor thereafter capturing all event data that satisfies a specific data collection filter.
8. A method as in claim 1, wherein the step of employing includes a step of processing the first and second stored events using a script.
9. A method as in claim 8, wherein the script is a pre-programmed script.
10. A method as in claim 8, wherein the script is automatically generated by entry of data to a plurality of fields on a presentation filter dialogue box.
11. A method as in claim 8, wherein the script is an operator-defined script.
12. A method as in claim 1,
wherein the step of intercepting said first API call comprises steps of:
installing a sensor between an output of an application and a function call library for emulating, relative to the application, an interface to the function call library; and
storing the predetermined API call criteria in a memory that is accessible by said sensor, and
wherein the step of examining said first API call comprises:
determining if the first API call fulfills the predetermined API call criteria; and
if a match occurs, capturing data representing all or a portion of the content of the first API call and transmitting the captured data to a database for storage as said first stored event.
13. A method as in claim 1, wherein the step of intercepting said first API call comprises steps of:
installing a sensor between an output of an application and a function call library for emulating, relative to the application, an interface to the function call library; and
programming the predetermined API call criteria into a memory that is accessible by said sensor.
14. A method as in claim 1, wherein the step of determining includes a step of correlating an entry event with an exit event.
15. A method as in claim 1, wherein the step of determining includes a step of correlating a message queue put event with a message queue get event.
16. A method as in claim 1, wherein the step of storing all or a portion of said content of said first API call includes a step of storing said first stored event in an event database with a unique ID, and wherein the step of determining includes a step of locating said first stored event in the event database using the unique ID.
17. A method as in claim 1, wherein the step of storing all or a portion of said content of said first API call stores an entry and an exit for said first API call as one event in an event database and provides a unique ID for said first stored event, such that a matching algorithm need search only one field.
18. A method as in claim 17, wherein the step of storing all or a portion of said content of said first API call further constructs a most-recently-stored (MRS) events list for improving the performance of the matching algorithm.
19. A method as in claim 1, wherein the step of storing all or a portion of said content of said first API call employs a record address as a stored event ID, and wherein the step of determining provides cursors to access events according to various criteria, including an ability to enumerate through events one at a time, without requiring that all events be read into memory.
20. A method as in claim 1, wherein the step of storing all or a portion of said content of said first API call provides event relationship lookup records to assist the performance of the step of determining by providing fast access to a list of events with a same attribute value.
21. An analyzer system for monitoring operation of a transaction processing system, comprising:
a first programmable sensor for intercepting and examining a first Application Program Interface (API) call to determine if said first API call meets programmed API call criteria, said first sensor being responsive to a condition that if said first API call meets the programmed API call criteria, capturing all or a portion of a content of said first API call;
a second programmable sensor for intercepting and examining a second API call to determine if said second API call meets the programmed API call criteria, said second sensor being responsive to a condition that if said second API call meets the programmed API call criteria, capturing all or a portion of a content of said second API call;
an analyzer console bidirectionally coupled to said first and second sensors, said analyzer console comprising:
(i) an event database having inputs coupled to said first and second sensors for storing said captured content of said first and second API calls as first and second stored events, respectively;
(ii) a data manager coupled to said event database for determining that said first API call is a part of a same particular business transaction as said second API call if:
(a) said first stored event indicates said first API call sent a message, and said second stored event indicates said second API call received said message, or
(b) said first and second stored events indicate said first and second API calls were conducted in a same transactional unit of work; and
(iii) a user interface for displaying all or a portion of said first and second stored events, if said first API call is a part of said same particular business transaction as said second API call; and a module that employs all of a portion of said first and second stored events in a subsequent process.
22. An analyzer system as in claim 21, wherein said API call criteria comprises at least one of a system entity identity, an API name, timing data, and restrictions on parameter values to the API call.
23. An analyzer system as in claim 21, wherein said first sensor is automatically enabled for responding to an occurrence of an error condition or a change in program states or environments.
24. An analyzer system as in claim 21,
wherein said first sensor is automatically enabled upon an occurrence of at least one programmed triggering event, and
wherein the first sensor thereafter captures all event data that satisfies a specific data collection filter.
25. An analyzer system as in claim 21,
wherein said data manager processes said first and second stored events using one of a pre-programmed script or an operator-defined script, and
wherein the script can be automatically generated by entry of data to a plurality of fields on a presentation filter dialogue box.
26. An analyzer system as in claim 21,
wherein said first sensor is installed between an output of an application and a function call library for emulating, relative to the application, an interface to the function call library, and
wherein predetermined API call criteria are programmed into a memory that is accessible by said first sensor.
27. An analyzer system as in claim 21, wherein if said first sensor determines that said first API call fulfills the programmed API call criteria, said first sensor transmits said captured content of said first API call to said event database for storage as said first stored event.
28. An analyzer system as in claim 21, wherein said data manager operates on said first and second stored events to at least one of correlate an entry event with an exit event, and correlate a message queue put event with a message queue get event.
29. An analyzer system as in claim 21, wherein said first stored event in said event database is provided a unique ID for locating said first stored event in the event database.
30. An analyzer system as in claim 21, wherein said first stored event in said event database comprises an entry and an exit for said first API call and is identified with a unique ID, such that an event matching algorithm need search only one data field.
31. An analyzer system as in claim 21, wherein said first stored event in said event database comprises technology neutral event information, and wherein said second stored event in said event database comprises technology specific event information.
32. An analyzer system as in claim 31, further comprising a technology-specific module that is invoked as needed to interpret said technology specific event information.
33. An analyzer system for monitoring operation of a data processing system, comprising:
a sensor for
(a) intercepting a first Application Program Interface (API) call,
(b) examining said first API call, and
(c) capturing first data from said first API call, if said first API call meets a criterion; and an analyzer console including
(a) an event database having an input coupled to said sensor for storing said data,
(b) a data manager coupled to said event database for determining that said first API call is logically related to a second API call if:
(i) said first data indicates said first API call sent a message, and second data from said second API call indicates said second API call received said message, or
(ii) said first data indicates said first API call was conducted in a transactional unit of work, and said second data indicates said second API call was also conducted in said transactional unit of work, and
(c) a module that employs said first data and said second data in a subsequent process, if said first API call is logically related to said second API call.
34. The analyzer system of claim 33,
wherein said data processing system is a distributed data processing system that includes a first processor and a second processor,
wherein said first API call is invoked by a first process running on said first processor, and
wherein said second API call is invoked by a second process running on said second processor.
35. The analyzer system of claim 33, wherein said subsequent process displays said data.
36. The analyzer system of claim 33, wherein said criterion is programmable, and
wherein said analyzer console provides configuration data to said sensor for programming said criterion.
The claims below are in addition to those above.
All refrences to claim(s) which appear below refer to the numbering after this setence.
What is claimed is:
1. A system for managing a progressive game, the system comprising:
a progressive management device including an interface; and
a progressive engine for maintaining a progressive, the progressive management device being coupled by interface to a first gaming system and a second gaming system, the first gaming system including a first set of progressive payout parameters and the second gaming system including a second set of progressive payout parameters that is different from the first set of progressive payout parameters.
2. The system of claim 1, further comprising:
a progressive payout parameter analyzer.
3. The system of claim 1, wherein the progressive management device is coupled to the gaming systems through a network.
4. The system of claim 1, wherein the progressive management device includes a currency conversion device for converting data provided from one of the gaming system into a predetermined universal currency.
5. The system of claim 4, wherein the currency conversion is performed in real-time.
6. The system of claim 1, wherein the progressive management device is operable to provide information on a progressive to user gaming interfaces, wherein the information includes the value of the progressive.
7. The system of claim 6, wherein the information is provided to the user gaming interfaces in real-time.
8. The system of claim 1, wherein the progressive is reset when a user attains a progressive.
9. A method for including systems having different progressive payout parameters into the same progressive, comprising:
initiating a progressive;
receiving a request from a first gaming system to participate in a progressive;
receiving a request from and a second gaming system to participate in a progressive, the first gaming system having a first set of progressive payout parameters and the second gaming system having a second set of progressive payout parameters that is different from the first set of progressive payout parameters; and
calculating a percentage of wager to be applied by each gaming system to the progressive, the calculation being based on the first and second sets of progressive payout parameters.
10. The method of claim 9, further comprising:
analyzing the first and second set of progressive payout parameters.
11. The method of claim 9, wherein the percentage of wager to be applied for each gaming system is calculated such that the product of progressive payout parameters odds and wager amount and the percentage of wager applied are equal for each gaming system.
12. The method of claim 9, wherein the progressive payout parameters include game odds.
13. The method of claim 9, wherein the progressive payout parameters include a currency type.
14. A system for managing a progressive game, the system comprising:
a progressive management device coupled to a gaming server, the gaming server including two or more gaming systems, wherein one gaming system includes a first set of progressive payout parameters and a second gaming system includes a second set of progressive payout parameters that is different from the first progressive payout parameters.
15. A method for including gaming systems having different currency types to a progressive, comprising:
receiving input from one or more gaming servers seeking participation in a progressive jackpot;
analyzing characteristics of each gaming system, wherein the characteristics include the currency type of the gaming system;
converting the currency type of each gaming system into a standard currency; and
including one or more gaming systems in the progressive jackpot by varying the percentage of the gaming system’s wager applied to the progressive jackpot.
16. A method for validating progressive payout parameters in gaming systems participating in a progressive, comprising:
receiving requests from one or more gaming servers including one or more gaming systems to participate in a progressive, wherein the gaming systems include a first gaming system having a first set of progressive payout parameters and a second gaming system having a second set of progressive payout parameters that is different from the first progressive payout parameters;
analyzing characteristics of each gaming system, the characteristics including the progressive payout parameters;
validating the progressive payout parameters of the gaming systems, including verifying that game odds and a payoff are consistent and within predetermined criteria; and
including validated gaming systems in the progressive.
17. A system for including gaming systems from different enterprises and having a same progressive payout parameters to a progressive, comprising:
a progressive management server coupled through a network to two or more gaming servers, the gaming servers operated by two or more enterprises; and
the gaming servers operating one or more gaming systems having same progressive payout parameters.
18. The system of claim 17, wherein the gaming systems have different progressive payout parameters.
19. A method for determining a progressive outcome, comprising:
receiving data at a progressive management device concerning a wager placed by a user of a participating gaming system;
determining a percentage of the wager to be applied to a progressive based on progressive payout parameters analysis, the progressive payout parameters including game odds and wager amount;
incrementing the progressive;
executing a random number generator calculation using the game odds from the gaming system progressive payout parameters; and
transmitting results of the random number generator calculation to a participating gaming system.
20. The method of claim 19, wherein a percentage of a wager to be applied to a progressive is determined through retrieval of previous analysis results from a database.