Browse Prior Art Database

METHOD FOR EFFICIENT HANDLING OF RESOURCE AFFINITY IN A WORKLOAD MANAGED MULTI-PROCESS MIDDLEWARE ENVIRONMENT

IP.com Disclosure Number: IPCOM000244612D
Publication Date: 2015-Dec-29
Document File: 8 page(s) / 159K

Publishing Venue

The IP.com Prior Art Database

Abstract

In a CICS environment, the resources are tightly bound to the region and they are not accessible outside the region's boundaries unless using Inter System Communication standards defined by CICS. The proposed method for efficient handling of resource affinity in a workload managed multi-process middleware environment.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 43% of the total text.

Page 01 of 8

METHOD FOR EFFICIENT HANDLING OF RESOURCE AFFINITY IN A WORKLOAD MANAGED MULTI-PROCESS MIDDLEWARE ENVIRONMENT

TXSeries for Multiplatforms is a premium middleware offering from IBM for running COBOL, C, C++, PL/I and other non Java based applications in a transactional environment. Non-Java applications can leverage transactional facilities and other services such as transactional mangement (COMMIT/ABORT) across multiple resources,
CICS APIs, etc,. TXSeries is based on a multi-process based environment where there are multiple independent operating system processes that are well coordinated and informations across each processes are shared through IPC mechanisms such as shared memory. There are other offerings in the market place such as Unikix, TMAX, Micro Focus Enterprise Server, XFRAME, Bull Liber TP who provide a multi-process based middleware environment for managing the non-Java applications

In a typical Workload Load Management (WLM) setup in a OLTP environment, the transactions get routed to different identically configured application systems (In short Application
Owning Regions or AOR) and expects the transaction to be independent of each other. A sample WLM environment is shown in Figure 1. In this setup, each transaction connects to a
client owning region(COR) which routes the request to different AORs based on load and other factors.

Challenges with WLM:

This type of WLM setup mandates every AOR to be isolated from a resource perspective; we cannot have shared resources across AORs. For example, let us consider two transactions
(For example TRAN1 and TRAN2) that use a same local resource say Temporary storage queue or a Transient storage queue where one transaction (TRAN1) performs update on a local
resource and other transaction (TRAN2) is expected to read the updated information. When such dependant transactions are run in WLM environment, the behavior is undefined.

The failure scenario is described pictorially in figure 2.

There are large customers in China who heavily depend on WLM to provide high availability for their critical systems. In CICS, the resources such as TSQs and TDQs are tightly bound
to a region resulting in high level of affinity. Their applications also use these resources to share data across transactions. Due to this, their applications are not completely
consumable in the WLM environment. This is a serious restriction which forces them to change either their application architecture.

1


Page 02 of 8

Figure 1: A typical WLM setup in a CICS environment.

Figure 2: Case where WLM fails

Existing Solution:


(1) For addressing this problem, customer can define the resource as remote and create the resource in the Data Owning Region (DOR). So the each request on the resource
operation will perform the function shipping to the DOR from the AOR. A set up is shown as in figure 3 below.

2


Page 03 of 8

Figure 3: WLM environment to overcome the problem in a CICS environment.

Though this approach solves the problem of...