Mainframe Service Model for Transaction Layer Segmentation

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current mainframe systems lack a common modeling method that integrates business transactions and operating software, particularly for middleware like CICS or IMS, due to their complexity and large number of transaction types and database records, making it difficult for IT professionals to understand and manage business impacts effectively.

Innovation Solution

A method and system for dynamically structuring a mainframe by identifying related transactions and resources across the transaction, middleware, and operating system layers, generating a visual service model that integrates business transactions with software and hardware components, allowing for predictive analytics and improved resource monitoring.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Ease of operation

If a common modeling method integrates business transactions and operating software in mainframe systems, then understanding and managing business impacts becomes easier, but the complexity of modeling numerous transaction types and database records increases

Engineering Contradiction:
Improveease of understanding and managing business impactsVSAvoidcomplexity of modeling transaction types and database records
Core Design Contradiction:
Ease of operationVSDevice complexity

Solution Approach 1:

The patent segments the mainframe system into distinct layers (transaction layer, middleware layer, operating system layer) and models each layer separately with its own entities and relationships. This segmentation allows complex business transactions to be broken down into manageable components across different layers, making the overall system easier to understand and manage while reducing the complexity of creating a comprehensive model.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent introduces a service model as an intermediary layer that connects business transactions with underlying software and hardware components. This service model acts as a mediator that translates complex technical details into business-relevant information, enabling easier understanding and management of business impacts without requiring direct modeling of all transaction types and database records.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Productivity

If mainframe systems process numerous transaction types and database records, then processing capability increases, but the difficulty of detecting and measuring business impacts increases

Engineering Contradiction:
Improveprocessing capabilityVSAvoiddifficulty of detecting and measuring business impacts
Core Design Contradiction:
ProductivityVSDifficulty of detecting and measuring

Solution Approach 1:

The patent implements feedback mechanisms where the service model continuously monitors and reports on the status and performance of business transactions and their impact on underlying system components. This feedback loop enables automatic detection and measurement of business impacts by aggregating data from numerous transactions and database records, making it easier to measure business impacts while maintaining high processing capability.

Inventive Principle:
Principle #23Feedback

Solution Approach 2:

The patent creates a virtual copy or representation of the mainframe system's business operations through the service model. This copy mirrors the essential relationships and flows between transactions, middleware, and operating system components, allowing for easier detection and measurement of business impacts without directly analyzing the full complexity of the actual system.

Inventive Principle:
Principle #26Copying

Data Source

PatentUS10990413B2Mainframe system structuring
Publication Date: 2021.04.27 KYNDRYL INC
  • US10990413B2 patent drawing
  • US10990413B2 patent drawing
  • US10990413B2 patent drawing

AI summary

A mainframe of an organization includes a transaction layer and a middleware layer and an operating system layer is structured by steps including identifying that transactions of the transaction layer are related to a classification of the organization. The steps further include identifying resources of the mainframe for executing the transactions, wherein the resources includes a processor and a memory. The steps include identifying transaction access paths between the transaction layer and the middleware layer resources that are associated with the middleware layer. The steps include identifying resources that are associated with the operating system layer and generating a service model of the mainframe that includes a visual representation of the transactions and the resources that are related to the classification across the middleware layer and the transaction layer and the operating system layer of the mainframe.