Method and system for protecting mainframe middleware

Abstract

The application discloses a mainframe middleware protection method and system, relates to the intelligent operation and maintenance field, and can be applied to the financial field and other fields.The method comprises the following steps: obtaining a configuration file, obtaining a query period and a configuration strategy by analyzing the configuration file, collecting the running state of a host and the transaction condition of a host middleware according to the query period to obtain decision parameters, performing decision operation on the decision parameters according to the configuration strategy to generate a state command, analyzing the transaction type of transaction data initiated externally according to the state command, and feeding back a rejection instruction to the initiator of the transaction data or transferring the transaction data to the host middleware for processing according to the transaction type and the state command. In this way, the resources and the state in the host middleware are monitored to generate a state command; when the system resources or the state reach the busy condition configured by the strategy, the request is rejected; and when the system resources or the state recover, the request is allowed to be submitted to the host middleware.

Description

Technical Field

[0001] This application relates to the field of computer software and can be applied to the financial field and other fields, particularly a method and system for protecting mainframe middleware. Background Technology

[0002] Currently, various industries have gradually completed their informatization and datafication. Most IT system architectures in these industries adopt B / S or C / S architectures. Customers operate or submit transaction data requests on various types of customer terminals (such as smartphones, PCs, POS terminals, ATMs, BSMs, etc.). Data transaction requests are sent to the core server for processing through various network channels. The core server responds to service requests, updates customer data on the core server, and then downloads the processing results back to the customer terminal. In banking enterprises, most of the core business still runs on mainframes (also known as host computers). Mainframes provide online transaction middleware, and the enterprise's online systems are generally built on this middleware. Business programs on this middleware are differentiated according to transactions. Typically, banking enterprises have hundreds or thousands of transactions deployed on the middleware; these transactions are usually the bank's core business programs. Therefore, ensuring the secure and stable operation of the mainframe middleware system is a key focus of banking system maintenance. There are many types of middleware used on bank mainframes, among which CICS (Customer Information Control System) middleware is one of the most powerful and widely used. It provides horizontally scalable clustering capabilities and limits the maximum number of concurrent transactions within a single CICS instance. However, with the growth of business volume, during certain critical periods or scenarios (such as Singles' Day, fund rushes, and large-scale merchant promotions), the mainframe CICS may experience excessively large sudden surges in traffic, including increased business volume and increased system resource consumption per transaction pair. If not anticipated, this can lead to middleware outages. On the one hand, mainframe resources are expensive; on the other hand, business volume growth is unpredictable, especially sudden surges, making traffic prediction extremely difficult. Middleware outages, in severe cases, can paralyze the entire core business system of an enterprise, causing significant economic and reputational losses.

[0003] To ensure the normal operation of core servers, various methods have been devised, typically focusing on load balancing and high availability. Two common industry approaches to protect core servers are: one approach combines both load balancing and high availability. Examples include increasing the number of horizontally scaled load balancers; adding traffic balancers in front of the system; and calculating system load based on request and response counts. These methods, by externally monitoring the system's status, control the input to backend application systems, thus protecting them. This externally controlled approach protects application systems while minimizing their impact, making it a highly effective method. Another approach involves installing monitoring devices on the core server to monitor its CPU, memory, and other resource data. If excessive resource usage is detected, new transaction requests are suspended. However, currently, in banking enterprises, most of the core business still runs on IBM mainframes (also known as mainframes). The mainstream mainframe model is the Z10. This model can use Parallel Sysplex technology to couple multiple IBM z / Series or IBM S / 390 servers together via Coupler (CF). Through hardware and software support, these machines can communicate and cooperate, achieving stronger processing power and higher reliability and availability. A single z-series mainframe can be partitioned into multiple LPARs (Logic Partitions). Each LPAR can run OS / 390 and z / OS systems, or load specific microcode (CFCC) for use by the Coupler. All systems within a SYSPLEX must abandon their individual clocks and connect to a common clock server to achieve system synchronization within the SYSPLEX. IBM mainframes use z / OS (z / Operating System), which provides various middleware for processing online transaction data. Online systems in banking enterprises are generally built on top of this middleware. There are many types of middleware on bank mainframes, among which CICS (Customer Information Control System) middleware is one of the most powerful and widely used. It provides horizontally scalable cluster capabilities, giving commercial banks powerful data processing capabilities.

[0004] Therefore, when a large banking enterprise's mainframe server experiences a massive surge, if the two traditional protection methods mentioned above are used, the first protection scheme, in particular, means that the general-purpose front-end server cannot identify the host's operating status and is unaware of any anomalies in the core server system. It can only detect a large number of failed transactions and trigger emergency protection measures, causing other normal transactions to be rejected by the protection device, resulting in the termination of the entire core server system's service and leading to even greater secondary production accidents. Furthermore, this method does not originate from within the application system; when the instantaneous pressure is too high, exceeding the total capacity of the application system, load balancing and traffic balancing will fail. Since the application system involves one-way transactions (requiring only notification to the service provider without a response), the request / response load balancing method will also fail. Therefore, even with external control methods for application system load protection, the risk of the application system being overwhelmed still exists. If the second protection scheme is adopted, using traditional monitoring of the core server's CPU, memory, and other resource data, this method is suitable for ordinary PC servers. However, if the core server is an IBM mainframe (also known as a host), because IBM mainframes use z / OS (z / Operating System, host platform operating system) and Parallel Sysplex technology, host resources can be divided into different partitions, and the host's CPU, memory, and other resources can be dynamically allocated and managed. For example, a single z-series mainframe (such as the Z10 model) can be divided into multiple LPARs (Logic Partitions), and each LPAR can independently run OS / 390 and z / OS systems. Each operating system can independently run the CICS (Client Information Control System) middleware to handle different transaction requests submitted by various applications on the client side. If the common method of monitoring PC server CPU, memory, and other resources is used to monitor the mainframe server's hardware for early warning and protection, there is a high possibility that the CICS may be overloaded and crash, but the early warning and protection will not respond. Therefore, a protection device and method suitable for the middleware of a mainframe online transaction processing system is needed. Summary of the Invention

[0005] The purpose of this application is to provide a method and system for protecting large-scale host middleware. Based on the characteristics of the transaction process of host middleware, this application proposes to start from the application system, detect the usage status of the host middleware system, and use the detection results to control the requests input to the system. Using a negative feedback theory method similar to that in circuits, this improves the host middleware transaction submission process and overcomes the shortcomings of the existing processing mode, which may be overwhelmed by instantaneous high pressure. This application provides a protection device and method for host middleware.

[0006] To achieve the above objectives, the mainframe middleware protection method provided in this application is applicable to IBM mainframe systems and specifically includes: obtaining a configuration file; parsing the configuration file to obtain a query cycle and configuration policy; collecting the mainframe's operating status and the mainframe middleware's transaction status according to the query cycle to obtain decision parameters; performing decision calculations on the decision parameters according to the configuration policy to generate status commands; analyzing the transaction type of externally initiated transaction data according to the status commands; and sending a rejection instruction to the initiator of the transaction data or transferring it to the mainframe middleware for processing according to the transaction type and the status commands.

[0007] In the above-mentioned large host middleware protection method, optionally, the process of collecting the host's operating status and the host middleware's transaction status according to the query period to obtain decision parameters includes: collecting the host's operating status and the allocation of host resources according to the query period, generating first decision data based on the operating status and the allocation status; obtaining the current transaction operation status of the host middleware, comparing the current transaction operation status with a preset threshold to generate second decision data; and generating decision parameters based on the first decision data and the second decision data.

[0008] In the above-mentioned large host middleware protection method, optionally, the host's operating status includes the current CPU usage status, MEM usage status, and I / O usage status.

[0009] In the above-mentioned large host middleware protection method, optionally, the transaction type of externally initiated transaction data is analyzed based on the status command, which includes: when the most recently updated status command in the preset assembly table is busy, obtaining the current time to generate a timestamp; generating a busy time period based on the timestamp and the query period; and analyzing the transaction type of externally initiated transaction data based on the busy time period.

[0010] In the above-mentioned large host middleware protection method, optionally, the transaction type of the externally initiated transaction data analyzed according to the status command further includes: when the most recently updated status command in the preset assembly table is an idle state or a normal state, the transaction data is transferred to the host middleware for processing.

[0011] In the above-described large host middleware protection method, optionally, the step of sending a rejection instruction to the initiator of the transaction data or transferring the data to the host middleware for processing according to the transaction type and the status command includes: when the transaction type is a request type and the status command is busy, sending a rejection instruction to the initiator of the transaction data; when the transaction type is a non-request type, transferring the transaction data to the host middleware for processing.

[0012] This application also provides a large-scale mainframe middleware protection system applicable to IBM mainframe systems. The system includes a status monitoring device and a control device. The status monitoring device is used to acquire a configuration file, parse the configuration file to obtain a query cycle and configuration policy, collect the mainframe's operating status and the mainframe middleware's transaction status according to the query cycle to obtain decision parameters, and perform decision calculations on the decision parameters according to the configuration policy to generate status commands. The control device is used to analyze the transaction type of externally initiated transaction data according to the status commands, and, based on the transaction type and the status commands, send a rejection instruction to the initiator of the transaction data or transfer the data to the mainframe middleware for processing.

[0013] This application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the above-described method.

[0014] This application also provides a computer-readable storage medium storing a computer program that performs the above-described methods.

[0015] This application also provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of the above-described method.

[0016] The beneficial technical effects of this application are as follows: Specifically designed for IBM mainframe systems, it statistically monitors and tracks the number of CICS (Computer Integrated System Configuration) applications; fully considering the technical characteristics of Parallel Sysplex (LPAR) servers, during monitoring, it queries the LPAR management console to inquire about the overall server resource allocation and combines this with policy control decisions. It implements the negative feedback principle in the software, using system status information related to the input of the host middleware system as control signals to control system inputs, effectively preventing excessive pressure from causing the application's host middleware system to crash. This is mainly achieved through the following two aspects: using resource and status monitoring within the host middleware to generate status commands; and implementing a control device within the host middleware to reject requests when system resources or status reach the busy conditions configured by the policy; and allowing requests to be submitted to the host middleware again after system resources or status recover. Attached Figure Description

[0017] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, do not constitute a limitation thereof. In the drawings:

[0018] Figure 1 This is a flowchart illustrating a method for protecting mainframe middleware provided in an embodiment of this application.

[0019] Figure 2This is a schematic diagram illustrating the process of obtaining decision parameters according to an embodiment of this application;

[0020] Figure 3 A schematic diagram of the principle structure of a large host middleware protection system provided in an embodiment of this application;

[0021] Figure 4 This is a schematic diagram of the protective device structure provided in an embodiment of this application;

[0022] Figure 5 This is a schematic diagram of the structure of a status monitoring device provided in an embodiment of this application;

[0023] Figure 6 This is a schematic diagram of the control device structure provided in an embodiment of this application;

[0024] Figure 7 This is a schematic flowchart of a protection method provided in an embodiment of this application;

[0025] Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0026] The following will describe in detail the implementation methods of this application with reference to the accompanying drawings and embodiments, so as to fully understand how this application uses technical means to solve technical problems and achieve technical effects, and to implement it accordingly. It should be noted that, as long as there is no conflict, the various embodiments and features in each embodiment of this application can be combined with each other, and the resulting technical solutions are all within the protection scope of this application.

[0027] Furthermore, the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases the steps shown or described may be executed in a different order than that shown here.

[0028] Please refer to Figure 1 As shown, the mainframe middleware protection method provided in this application is applicable to IBM mainframe systems and specifically includes:

[0029] S101 Obtains the configuration file and parses the configuration file to obtain the query cycle and configuration strategy;

[0030] S102 collects the host's operating status and the host middleware's transaction status according to the query period to obtain decision parameters;

[0031] S103 performs decision calculations on the decision parameters according to the configuration strategy to generate a status command, and analyzes the transaction type of externally initiated transaction data according to the status command;

[0032] S104 Based on the transaction type and the status command, a rejection instruction is sent to the initiator of the transaction data or the data is transferred to the host middleware for processing.

[0033] The host's operational status includes the current CPU usage, MEM usage, and I / O usage. Specifically, in practice, the bank's mainframe CICS acts as a transaction middleware. Business transactions are typically initiated by external applications, and the mainframe CICS submits transaction request data to the mainframe CICS for transaction execution. Mainframe CICS transaction execution is the primary source of host system resource consumption. The protection mechanism of this application involves detecting the internal usage of the mainframe CICS system. A status monitoring device monitors critical system resources, including the operating system's CPU, MEM, and I / O, as well as the number of transactions executed by CICS, and generates status commands according to a predetermined strategy. Subsequently, based on the status commands, the type of externally initiated data is identified. If it is an external request type of data, the latest status command is confirmed; if the status command is "reject," the request data is rejected; otherwise, the request data is submitted to CICS for transaction execution normally.

[0034] In the above embodiments, the status commands can be divided into two types: busy and normal. When a busy status command is received, the client's request is rejected; when a normal status command is received, the request is submitted normally. This avoids the situation where CICS is overwhelmed under high pressure. Since the monitoring of the host CICS is real-time, the status information also reflects the operating status of the host CICS. Whether a request is submitted depends entirely on the status command at that moment. The status command for each request is different, so the rejection will vary. When the host CICS system is busy due to a large number of submitted requests or other reasons, subsequent requests will be rejected and not submitted to the host CICS system. Therefore, after processing the submitted requests, the host system will be idle, and subsequent requests can be submitted to the host CICS system normally. In this way, no matter how high the continuous or instantaneous pressure generated by the client device is, under conditional rejection, it will not put excessive pressure on the subsequent host CICS transaction operation devices, thus effectively protecting the host CICS system.

[0035] Please refer to Figure 2 As shown, in one embodiment of this application, the decision parameters obtained by collecting the host's operating status and the host middleware's transaction status according to the query period include:

[0036] S201 collects the host's operating status and host resource allocation according to the query period, and generates first decision data based on the operating status and the allocation.

[0037] S202 obtains the current transaction operation status of the host middleware, compares the current transaction operation status with a preset threshold, and generates second decision data;

[0038] S203 generates decision parameters based on the first decision data and the second decision data.

[0039] In practical work, in order to save resources, the operating status of the host, the allocation of host resources, and the current transaction operation status of the host middleware can also be collected simultaneously. Decision parameters are then generated based on the collection results. It is worth noting that those skilled in the art can also choose to use the collected data as decision parameters without processing it, depending on actual needs. This application does not restrict the decision data and the collected data to be different data.

[0040] In one embodiment of this application, analyzing the transaction type of externally initiated transaction data based on the status command includes: when the most recently updated status command in the preset assembly table is in a busy state, obtaining the current time to generate a timestamp; generating a busy time period based on the timestamp and the query period; and analyzing the transaction type of externally initiated transaction data based on the busy time period. In another embodiment, analyzing the transaction type of externally initiated transaction data based on the status command further includes: when the most recently updated status command in the preset assembly table is in an idle state or a normal state, transferring the transaction data to the host middleware for processing.

[0041] Specifically, in practical work, an assembly table can be set up to statistically confirm the status commands and their validity periods, which facilitates the subsequent analysis of the current host middleware status and facilitates the processing of relevant transaction request data; those skilled in the art can also choose other similar or equivalent technical means to record status commands according to actual needs, and this application does not make further limitations here.

[0042] In one embodiment of this application, the process of sending a rejection instruction to the initiator of the transaction data or transferring the data to the host middleware for processing based on the transaction type and the status command includes: when the transaction type is a request type and the status command is busy, sending a rejection instruction to the initiator of the transaction data; when the transaction type is a non-request type, transferring the transaction data to the host middleware for processing. Specific examples will be described in detail in subsequent embodiments, and will not be elaborated here.

[0043] Please refer to Figure 3As shown, this application also provides a large-scale mainframe middleware protection system, applicable to IBM mainframe systems. The system includes a status monitoring device and a control device. The status monitoring device is used to acquire a configuration file, parse the configuration file to obtain a query cycle and configuration policy, collect the mainframe's operating status and the mainframe middleware's transaction status according to the query cycle to obtain decision parameters, perform decision calculations on the decision parameters according to the configuration policy to generate status commands. The control device is used to analyze the transaction type of externally initiated transaction data according to the status commands, and send a rejection instruction to the initiator of the transaction data or transfer it to the mainframe middleware for processing according to the transaction type and the status commands.

[0044] Please refer to the details. Figure 4 As shown, in practical applications, a mainframe middleware protection system can include the following structure: A CICS transaction execution device 1, which can run multiple CICS instances, forming a CICS group that provides transaction services and stores enterprise data. A status monitoring device 2, which runs various monitoring programs that monitor the operating system and CICS operational status information, converting the monitored information into status command outputs according to configuration policies. The status monitoring device includes three functional units: an operating system status monitoring device 10, a CICS operational status monitoring device 11, and a status command output device 12. See details... Figure 5 Explanation. Control device 3, which also runs multiple CICS, provides a status command buffer for status monitoring device 2; it provides services to client device 5 by receiving data from the client; if the data from client device 5 is a request and the status command is normal or other types of data, it submits the request to CICS transaction execution device 1 and returns the transaction execution result to client device 5. Control device 3 includes five functional devices: a status command receiving device 20, a data receiving device 21, a data type identification device 22, a comparison execution device 23, and a data return device 24. See details... Figure 6 Explanation: Network device 4 represents the enterprise's internal network environment and serves as the communication foundation for system operation. It can support both SNA and TCP / IP. Client device 5 is the user of the host transaction and can be an application system on an open platform. It submits data requests for transaction services to the host through network device 4.

[0045] Please refer to Figure 5 As shown, the status monitoring device includes three functional parts: operating system status monitoring device 10, CICS operation status monitoring device 11, and status command output device 12.

[0046] The operating system status monitoring device 10 is responsible for monitoring the operating system, including CPU, MEM, IO, and consulting the LPAR management console regarding the overall resource allocation of the server. The generated status information is provided to the status command output device 12. The CICS operation status monitoring device 11 is mainly responsible for collecting operation status information in CICS, such as the current number of running transactions and whether the current number of transactions has reached the maximum number of transactions in CICS. This status information is also provided to the status command output device 12. The status command output device 12 is a decision-making and computation device. Based on the status information provided by the operating system status monitoring device 10 and the CICS operation status monitoring device 11, and combined with the configuration strategy, it performs decision-making and computation, generates status command results, outputs them, and notifies the control device 3. The configuration strategy on the status monitoring device 2 is mainly set according to the operating characteristics of the CICS transaction operation device 1 and the control device 3. It is a file where the conditions in each line of the status command are logically ORed with the conditions in other lines. An example of a configuration strategy is as follows:

[0047] Busy: Each CPU is above 85%; the sum of all MEMs is above 24G; CICS reaches MAX TASK;

[0048] Normal: Other;

[0049] The status monitoring device 2 performs a status information collection action once per cycle according to the status information collection period set in the parameters, generating a status command. The status information collection period and other parameters are set in the parameter configuration file.

[0050] Please refer to Figure 6 As shown, the control device 3 includes a status command receiving device 20, a data receiving device 21, a data type identification device 22, a comparison execution device 23, a data return device 24, and five functional devices.

[0051] The status command receiving device 20 receives status results from the status command output device 12. This device also includes a host assembly table, which mainly includes two fields: timestamp and status command. The control device 3 retrieves the status command from this assembly table. The validity of the status command depends on the time difference between the current system time and the timestamp. If the current time is greater than the timestamp and the time difference is less than or equal to one status information collection cycle of the status monitoring device 2, the status command is valid; otherwise, the status command is invalid and is processed normally according to the default status command. The data receiving device 21 receives data sent by the client device 5. The service provided by this device can be based on TCP / IP or SNA. The data type identification device 22 determines the type of data received by the data receiving device 21, classifying the data into two categories: requested type and non-requested type. The comparison execution device 23 processes the data received by the data receiving device 21 based on the data identification result of the data type identification device 22 and the current status command of the status command receiving device 20. When the transaction type is a request and the current command status is busy, the comparison execution device 23 rejects the data request submitted to the CICS transaction execution device 1 and returns the corresponding rejection information to the client device 5 through the data return device 24; otherwise, it submits data to the CICS execution device 1 and waits for the result, returning the result to the corresponding client device 5 through the data return device 24. The data return device 24 provides data services to the client device, returning the execution result or rejection information of the comparison execution device 23 to the client device 5 through the network device 3.

[0052] To facilitate a clearer understanding of the practical application process of the mainframe middleware protection system provided in this application, please refer to the following: Figure 7 As shown, its protection process is as follows:

[0053] 700-706 is the execution process of the status monitoring device.

[0054] 700, Preprocessing parameter configuration files, such as configuration strategy configuration files, setting the status information collection cycle, etc.;

[0055] 701, Operating system status monitoring device 10 collects information on the current CPU usage of the operating system;

[0056] 702, Operating system status monitoring device 10 collects information on the current usage status of the operating system's MEM;

[0057] 703, The operating system status monitoring device 10 collects information on the current I / O usage of the operating system; the operating system status monitoring device 10 consults the host service LPAR management console for overall resource allocation information.

[0058] 704, CICS operation status monitoring device 11 collects the current number of CICS transaction operations;

[0059] 705, The status command output device 12 performs decision calculations based on the status information provided by the operating system status monitoring device 10 and the CICS running status monitoring device 11, and based on the overall resource allocation information consulted by the host service LPAR management console, plus the configuration strategy, to generate the status command result.

[0060] 706. The status command output device 12 sends the status command to the control device 3. The status command receiving device 20 receives the status result output from the status command output device 12 and records the timestamp and status command (normal, busy) in the assembly table on the status command receiving device 20.

[0061] 707, after the status monitoring device 2 sleeps for one status information collection cycle, it will re-enter 701 for processing.

[0062] 800, Client device 5 sends data to control device 3;

[0063] 801, Data receiving device 21 receives data from client device;

[0064] 802, the data type identification device 22 determines the type of data received by the data receiving device. The data is divided into two categories: request type and non-request type. If it is a request type, proceed to 803; otherwise, proceed to 806.

[0065] 803, compare the timestamp and status command in the assembly table on the status command receiving device 20 with the execution device 23;

[0066] 804. If the current status command is "busy", then the comparison execution device 23 determines the time difference between the current system time and the timestamp. If the current time is greater than the timestamp and the time difference is less than or equal to one status information collection cycle of the status monitoring device 2, then proceed to 805 for processing; otherwise, proceed to 806.

[0067] 805, the comparison execution device 23 generates a transaction rejection message, proceeding to 811;

[0068] 806, Control device 3 submits the transaction data to CICS transaction operation device 1;

[0069] 807, CICS transaction operation device 1 receives a transaction request;

[0070] 808, CICS transaction processing unit 1 performs transaction processing;

[0071] 809, CICS transaction operation device 1 returns the transaction result to control device 3, and control device 3 then returns the result to the client device;

[0072] 810, Control device 3 awaits the return of the transaction result;

[0073] 811, the data return device 24 sends the transaction result to the client device 5;

[0074] 812, Client device 5 receives data return from data return device 24;

[0075] 813, Client device 5 continues with subsequent processing.

[0076] The beneficial technical effects of this application are as follows: Specifically designed for IBM mainframe systems, it statistically monitors and tracks the number of CICS (Computer Integrated System Configuration) applications; fully considering the technical characteristics of Parallel Sysplex (LPAR) servers, during monitoring, it queries the LPAR management console to inquire about the overall server resource allocation and combines this with policy control decisions. It implements the negative feedback principle in the software, using system status information related to the input of the host middleware system as control signals to control system inputs, effectively preventing excessive pressure from causing the application's host middleware system to crash. This is mainly achieved through the following two aspects: using resource and status monitoring within the host middleware to generate status commands; and implementing a control device within the host middleware to reject requests when system resources or status reach the busy conditions configured by the policy; and allowing requests to be submitted to the host middleware again after system resources or status recover.

[0077] This application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the above-described method.

[0078] This application also provides a computer-readable storage medium storing a computer program that performs the above-described methods.

[0079] This application also provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of the above-described method.

[0080] like Figure 8 As shown, the electronic device 600 may further include: a communication module 110, an input unit 120, an audio processing unit 130, a display 160, and a power supply 170. It is worth noting that the electronic device 600 does not necessarily need to include these components. Figure 8 All components shown; in addition, the electronic device 600 may also include Figure 8 For components not shown, please refer to existing technologies.

[0081] like Figure 8 As shown, the central processing unit 100, sometimes also referred to as a controller or operating control, may include a microprocessor or other processor device and / or logic device. The central processing unit 100 receives inputs and controls the operation of various components of the electronic device 600.

[0082] The memory 140 may be, for example, one or more of a cache, flash memory, hard drive, removable media, volatile memory, non-volatile memory, or other suitable devices. It may store the aforementioned failure-related information, and also store a program for executing that information. The central processing unit 100 may execute the program stored in the memory 140 to perform information storage or processing, etc.

[0083] Input unit 120 provides input to central processing unit 100. Input unit 120 may be, for example, a keypad or touch input device. Power supply 170 provides power to electronic device 600. Display 160 displays images and text. Display may be, for example, an LCD display, but is not limited thereto.

[0084] The memory 140 can be a solid-state memory, such as a read-only memory (ROM), random access memory (RAM), a SIM card, etc. It can also be a memory that retains information even when power is off, can be selectively erased, and contains more data; examples of this type of memory are sometimes referred to as EPROMs. The memory 140 can also be some other type of device. The memory 140 includes a buffer memory 141 (sometimes referred to as a buffer). The memory 140 may include an application / function storage unit 142 for storing application programs and function programs or processes for executing the operation of the electronic device 600 via the central processing unit 100.

[0085] The memory 140 may also include a data storage unit 143 for storing data, such as contacts, digital data, pictures, sounds, and / or any other data used by the electronic device. The driver storage unit 144 of the memory 140 may include various drivers for the electronic device's communication functions and / or for performing other functions of the electronic device (such as messaging applications, address book applications, etc.).

[0086] The communication module 110 is a transmitter / receiver 110 that transmits and receives signals via antenna 111. The communication module (transmitter / receiver) 110 is coupled to the central processing unit 100 to provide input signals and receive output signals, which can be the same as in a conventional mobile communication terminal.

[0087] Based on different communication technologies, multiple communication modules 110 can be configured in the same electronic device, such as cellular network modules, Bluetooth modules, and / or wireless LAN modules. The communication module (transmitter / receiver) 110 is also coupled to a speaker 131 and a microphone 132 via an audio processor 130 to provide audio output via the speaker 131 and receive audio input from the microphone 132, thereby enabling typical telecommunications functions. The audio processor 130 may include any suitable buffer, decoder, amplifier, etc. Additionally, the audio processor 130 is coupled to a central processing unit 100, enabling on-device recording via the microphone 132 and on-device playback of stored audio via the speaker 131.

[0088] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0089] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0090] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0091] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0092] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of this application. It should be understood that the above descriptions are merely specific embodiments of this application and are not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A method for protecting mainframe middleware, applicable to IBM mainframe systems, characterized in that, The method includes: Obtain the configuration file, and parse the configuration file to obtain the query cycle and configuration strategy; Decision parameters are obtained by collecting the host's operating status and the host middleware's transaction status according to the query period. The decision parameters are used to perform decision calculations based on the configuration strategy to generate status commands, and the transaction type of externally initiated transaction data is analyzed based on the status commands. Based on the transaction type and the status command, a rejection instruction is sent to the initiator of the transaction data, or the transaction is transferred to the host middleware for processing. The decision parameters obtained by collecting the host's operating status and the host middleware's transaction information according to the query period include: The host's operating status and resource allocation are collected according to the query period, and first decision data is generated based on the operating status and resource allocation; wherein, the resource allocation is obtained by consulting the host service LPAR logical partition management console. In addition, the current transaction operation status of the host middleware is obtained, and the current transaction operation status is compared with a preset threshold to generate second decision data; wherein, the current transaction operation status of the host middleware includes the current number of running transactions of the host middleware and whether the current number of running transactions has reached the maximum number of transactions; Decision parameters are generated based on the first decision data and the second decision data.

2. The method for protecting large-scale host middleware according to claim 1, characterized in that, The transaction types analyzed based on the status command include: When the most recently updated status command in the preset assembly table is in a busy state, obtain the current time and generate a timestamp; A busy time period is generated based on the timestamp and the query period, and the transaction type of externally initiated transaction data is analyzed based on the busy time period.

3. The method for protecting large-scale host middleware according to claim 1, characterized in that, The transaction types analyzed based on the status commands also include: When the most recently updated status command in the preset assembly table is in an idle or normal state, the transaction data is transferred to the host middleware for processing.

4. The method for protecting large-scale host middleware according to claim 1, characterized in that, Based on the transaction type and the status command, sending a rejection instruction to the initiator of the transaction data or transferring it to the host middleware for processing includes: When the transaction type is a request type and the status command is busy, a rejection instruction is sent to the initiator of the transaction data. When the transaction type is a non-request type, the transaction data is transferred to the host middleware for processing.

5. The method for protecting large-scale mainframe middleware according to any one of claims 1 to 4, characterized in that, The host's operating status includes the current CPU usage status, MEM usage status, and I / O usage status.

6. A mainframe middleware protection system, applicable to IBM mainframe systems, characterized in that, The system includes a status monitoring device and a control device; The status monitoring device is used to obtain the configuration file, parse the configuration file to obtain the query cycle and configuration strategy, and collect the host's running status and the host middleware's transaction status according to the query cycle to obtain decision parameters. Based on the configuration strategy, the decision parameters are used to generate a status command; The control device is used to analyze the transaction type of externally initiated transaction data according to the status command; and to send a rejection instruction to the initiator of the transaction data or transfer it to the host middleware for processing according to the transaction type and the status command. Specifically, the status monitoring device is used to collect the host's operating status and host resource allocation according to the query cycle, and generate first decision data based on the operating status and allocation; wherein the host resource allocation is obtained by consulting the host service LPAR logical partition management console; and to obtain the current transaction operation status of the host middleware, and compare the current transaction operation status with a preset threshold to generate second decision data; wherein the current transaction operation status of the host middleware includes the current number of running transactions of the host middleware and whether the current number of running transactions has reached the maximum number of transactions; and to generate decision parameters based on the first decision data and the second decision data.

7. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method of any one of claims 1 to 5.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that enables a computer to execute the method of any one of claims 1 to 5.

9. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instructions are executed by the processor, they implement the steps of the method described in any one of claims 1 to 5.

Images