This disclosure describes systems, methods, and devices related to an enhanced retry count for an uplink (UL) multi-user (MU) transmission. A device may identify a trigger frame received from a first device on a wireless communication channel. The device may determine a quality of service counter associated with an access category. The device may cause to send a frame to the first device based at least in part on the trigger frame. The device may determine an error condition associated with the frame. The device may refrain from incrementing the quality of service counter based on the error condition.

A method, computer program product, and computer system are provided. A message storage area of an adjunct processor (AP) crypto adapter is filled with a plurality of command request messages sufficient to maximize utilization and performance of the AP crypto adapter. In response to detecting an error during execution of one of the plurality of command request messages, generating an AP crypto adapter command reply message. The AP crypto adapter command reply message includes the error. In response to the error being a non-recoverable failure, determining a state of the command request message, wherein the state of the command request message comprises an in-process state or a request-pending state. The AP crypto adapter command reply message is formatted, wherein the formatted AP crypto adapter command reply message is stored in a message queue in the AP crypto adapter pending completion of machine failure recovery. The AP crypto adapter is recovered.

A method includes saving a control state for a processor in response to commencing a transactional processing sequence, wherein saving the control state produces a saved control state. The method also includes permitting updates to the control state for the processor while executing the transactional processing sequence. Examples of updates to the control state include key mask changes, primary region table origin changes, primary segment table origin changes, CPU tracing mode changes, and interrupt mode changes. The method also includes restoring the control state for the processor to the saved control state in response to encountering a transactional error during the transactional processing sequence. In some embodiments, saving the control state comprises saving the current control state to memory corresponding to internal registers for an unused thread or another level of virtualization. A corresponding computer system and computer program product are also disclosed herein.

Techniques are disclosed relating to automated operations management. In various embodiments, a computer system accesses operational information that defines commands for an operational scenario and accesses blueprints that describe operational entities in a target computer environment related to the operational scenario. The computer system implements the operational scenario for the target computer environment. The implementing may include executing a hierarchy of controller modules that include an orchestrator controller module at top level of the hierarchy that is executable to carry out the commands by issuing instructions to controller modules at a next level. The controller modules may be executable to manage the operational entities according to the blueprints to complete the operational scenario. In various embodiments, the computer system includes additional features such as an application programming interface (API), a remote routing engine, a workflow engine, a reasoning engine, a security engine, and a testing engine.

Aspects described herein may relate to a transaction exchange platform using a streaming data platform (SDP) and microservices to process transactions according to review and approval workflows. The transaction exchange platform may receive transactions from origination sources, which may be added to the SDP as transaction objects. As the transactions are received, the transactions may be analyzed to detect duplicate transactions and/or errors in the transactions. The transaction exchange platform may take steps to remediate transactions that are recognized as duplicates or predicted to generate one or more errors. Similarly, the transaction exchange platform may take steps to remediate transactions that are rejected by a clearinghouse.

Aspects described herein may relate to a transaction exchange platform using a streaming data platform (SDP) and microservices to process transactions according to review and approval workflows. The transaction exchange platform may receive transactions from origination sources, which may be added to the SDP as transaction objects. As the transactions are processed, the transactions may require access to a resource (e.g., a key value in a database). A microservice processing the transaction may request, from a locking microservice, a lock for the resource. The locking microservice may query a local cache to determine whether a lock exists for the resource. If the local cache determines that no lock exists for resource, the locking mechanism may employ a consensus protocol to obtain a lock for the resource from a plurality of clusters. If consensus is reached, a lock for the resource may be granted to the requesting microservice.

Aspects described herein may relate to a transaction exchange platform using a streaming data platform (SDP) and microservices to process transactions according to review and approval workflows. The transaction exchange platform may receive transactions from origination sources, which may be added to the SDP as transaction objects. As the transactions are processed, the transactions may require access to a resource (e.g., a key value in a database). A microservice processing the transaction may request, from a locking microservice, a lock for the resource. The locking microservice may query a local cache to determine whether a lock exists for the resource. If the local cache determines that no lock exists for resource, the locking mechanism may employ a consensus protocol to obtain a lock for the resource from a plurality of clusters. If consensus is reached, a lock for the resource may be granted to the requesting microservice.

Aspects described herein may relate to a transaction exchange platform using a streaming data platform (SDP) and microservices to process transactions according to review and approval workflows. The transaction exchange platform may receive transactions from origination sources, which may be added to the SDP as transaction objects. Microservices on the transaction exchange platform may interact with the transaction objects based on configured workflows associated with the transactions. Processing on the transaction exchange platform may facilitate clearing and settlement of transactions. Some aspects may provide for dynamic and flexible reconfiguration of workflows and/or microservices. Other aspects may provide for data snapshots and workflow tracking, allowing for monitoring, quality control, and auditability of transactions on the transaction exchange platform.

Systems, methods and/or computer program products dynamically managing log levels of microservices in a service mesh based on predicted error rates of calls made to the service mesh. A first AI module predicts health, status and/or failures of microservices individually or as part of microservice chains with a particular confidence level. Using health status mapped to the microservices and historical information inputted into a knowledge base (including error rates), the first AI module predicts error rates of the API call for each user profile or generally by the service mesh. A second AI module analyzes the predictions provided by the first AI module and determines whether the predictions meet threshold levels of confidence. To improve the confidence of predictions that are below threshold levels, the second AI module dynamically adjusts application logs of the microservices and/or proxies thereof to an appropriate level to capture more detailed information within the logs.

In an example embodiment, information about one or more failed payment attempts via an electronic payment processing system is obtained. One or more features are extracted from the information. Then, for each of a plurality of potential candidate retry time points, the one or more features and the potential candidate retry time point are fed into a dunning model, the dunning model trained via a machine-learning algorithm to produce a dunning score indicative of a likelihood that a retry attempt at an input retry time point will result in a successful payment processing. The dunning scores for the plurality of potential candidate retry time points are used to select a desired retry time point. Then the electronic payment processing system is caused to attempt to reprocess a payment associated with one of the failed payment attempts at a time matching the desired retry time point.