Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Module to Module Linkage Mechanism

IP.com Disclosure Number: IPCOM000050907D
Original Publication Date: 1982-Dec-01
Included in the Prior Art Database: 2005-Feb-10
Document File: 8 page(s) / 82K

Publishing Venue

IBM

Related People

Jackson, RD: AUTHOR [+2]

Abstract

This article presents definition and construction of resource manager to resource manager linkage functions. Reference to application to resource manager linkage services is made only when a linkage service function is common to both types of linkage.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 19% of the total text.

Page 1 of 8

Module to Module Linkage Mechanism

This article presents definition and construction of resource manager to resource manager linkage functions. Reference to application to resource manager linkage services is made only when a linkage service function is common to both types of linkage.

A programming system consists of multiple resource managers, each resource manager consisting of one or more modules. Communication between modules within a resource manager and between modules of different resource managers is of two forms: - A service request is such that a module of one resource manager requests a module of the same or of another resource

manager to perform a function the results of which are to be

used by the requesting module. - An event notification is such that a module of one resource manager informs a module of the same or of another resource

manager of the occurrence of a system event. The notified

module determines what, if anything, is to be done relative

to the event occurrence.

A further differentiation in the two forms of module to module communication lies in the responsibility of defining the parameters of the linkage. The provider of a service defines the parameters of a service request, whereas the notifier of an event defines the parameters of an event notification.

The linkage mechanism between modules is an implicit "parameter" of the communication. However, programming systems normally provide common linkage services which assist in simplifying the linkage parameter in module to module communication. We describe here a linkage service commonly designed to support both service requests and event notifications for a data base management system (DBMS), such as IMS/VS.

Two types of linkage tables are supported by an exemplary DBMS. The first type is the system internal linkage table which supports resource manager to resource manager communication. This table is persistent and is built at DBMS initialization.

The second type is the application linkage table which supports application to resource manager communication. It consists of two parts - a static part and a dynamic part. - The static part is persistent and is built at system initialization. This part provides the transition between

application environment and DBMS environment, including

state and key change and the transition between permanently

available DBMS code and deletable DBMS code. - The dynamic part is built when allocating resources for an application. It persists while the application is connected

to the DBMS. This part provides the linkage to resource

manager code which supports the application requested

function.

1

Page 2 of 8

LINKAGE CHARACTERISTICS.

A DBMS has the following characteristics. 1. It is designed to fit into and exploit the services of OS/VS2 MVS. 2. It has many resource managers. 3. Each resource manager has multiple modules. 4. There is significant module to module communication, both inter-resource manager and intra-resource ma...