Browse Prior Art Database

A virtual group multicast approach to enhance sysplex communication on mainframe

IP.com Disclosure Number: IPCOM000181771D
Original Publication Date: 2009-Apr-13
Included in the Prior Art Database: 2009-Apr-13
Document File: 5 page(s) / 133K

Publishing Venue

IBM

Abstract

The communication capability of Sysplex Services provided through cross-system coupling facility (XCF) has a drawback in multicast, because it does not provide an easy way to maintain multi-cast groups.This document proposes a new approach to simplify the implementation of multicast in one XCF group. The approach is still table-based, however, instead of maintaining a table accessible to all members from different systems, it will establish many virtual XCF groups corresponding to each of the multicast groups, and smartly utilize the IXCQUERY macro to obtain a table dynamically and efficiently.

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

Page 1 of 5

A virtual group multicast approach to enhance sysplex communication on mainframe

Main Idea

1. Background: What is the problem solved by your invention? Describe known solutions to this problem(if any). What are the drawbacks of such known solutions, or why is an additional solution required? Cite any relevant technical documents or references.

   The communication capability of Sysplex Services provided through cross-system coupling facility (XCF) has a drawback in multicast, because it does not provide an easy way to maintain multi-cast groups.

   The IXCMSGO macro only allows a member to send messages to the members in its group. To do multicast, the developers have to identify multiple target members by creating a table containing the member token of each member that is to receive the message and using the IXCMSGO SENDTO=GROUP, MEMBERS=TABLE option and identify the table with the TARGETS parameter. The table containing the member tokens of the target members is an array of entries. Each entry has the same fixed size (specified byNEXTTARGETOFF) and can contain data other than thetarget member token. The number of entries in the table is specified with the #TARGETS keyword. XCF iteratively processes the table for the specified number of entries, sending the message to the

member indicated by each member token in the entry.

[1]

   However, when the members of the multicast group are from different systems/LPARs, it will be significantly complex for the sender to maintain a table of the member tokens of all other members.

   For example, multi-leg stock exchange application usually consists of a number of Execution Venues (EVs), and each EV carries and processes a large number of symbols, with each symbol corresponding to one kind of stock. And in multi-core platform, each symbol is usually assigned to a single thread for processing.

The multi-leg trading will require more than two symbols to interact with each other, which will cause more than two EVs to interact with each other. On the other side, for each symbol, several EVs will constitute a peer group to backup each other in the trading process, which means more than two peer groups need to interact with each other, as shown in figure 1.

1

Page 2 of 5

Peer group for: AT&T, Boeing, Chevron

Peer group for: Dell, Exxon, J.P.Morgan

Symbols: AT&T Boeing Chevron Ford
GE

Symbols: AT&T Boeing Chevron Ford
GE

IBM

Symbols: AT&T Boeing Chevron HP IBM

EV1 EV2

EV3

Symbols: Dell Exxon Ford
GE J.P.Morgan …

Symbols: Dell Exxon
HP
IBM J.P.Morgan …

Symbols: Dell Exxon
HP
IBM J.P.Morgan …

EV4

EV5 EV6

Peer group for: Ford, GE

Peer group for: HP, IBM

Figure 1. Illustration of Multi-leg Stock Exchange Architecture

Particularly, to devise an efficient mechanism for this kind of multi-cast communication, we need to take following constraints into consideration: Symbols will be dynamically added to or removed from an EV, as shown in figure 2, which means peer group...