Browse Prior Art Database

Connecting Application Address Spaces

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

Publishing Venue

IBM

Related People

Athwal, DS: AUTHOR [+3]

Abstract

This article describes a method for associating an address space for an application running under a first subsystem to a second subsystem without requiring that the application address space be up (before or) after the second subsystem instance.

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

Page 1 of 3

Connecting Application Address Spaces

This article describes a method for associating an address space for an application running under a first subsystem to a second subsystem without requiring that the application address space be up (before or) after the second subsystem instance. This is done by: issuing a call from the application address space aimed at the second subsystem; processing the call by connecting the application address space to the second subsystem informing resource managers in the second subsystem interested in the call, thereby making of the application address space an allied application address space; if the call is an identify call, maintaining connection of the allied address space and returning control to the allied application address space, thus giving the allied application address space the ability to request other services of the second subsystem; if the call is not an identify call, disconnecting the application address space on return if no other calls from the same application address space are current.

Assume herein the existence of three kinds of IBM Multiple Virtual System (MVS) address spaces: The Data Base Manager (DBM) Control address space. This

address space is started internally via an MVS macro

Master Get Control Routine (MGCR) service as a result of a

DBM "START" command being issued at an authorized MVS

console. It controls the initialization and termination

of itself and DBM Resource Manager address spaces.

The DMB Resource Manager address space(s). These may be

address space is started internally via MVS MGCR service

by the DMB Control address space.

Others, known as non-DMB address spaces. These may be

started, by job Entry System (JES) or Time Sharing Option

(TSO) or may be system (e.g., the Master address space)

address space(s) started at MVS Initial Program Load (IPL)

time.

DBM Control and Resource Manager address spaces have full authority to access data and code amongst themselves via the cross-memory instructions available in IBM MVS/System Product (SP 1-2)- However, the non-DBM address spaces cannot use DBM services or access data and code until they have become DBM Allied (also known as Application) address spaces.

This article describes a technique for connecting/disconnecting these address spaces to/from the DBM so that they can utilize DBM services. The technique satisfies the following requirements: - The connecting address space may be a subsystem type

address space. The examples of such address spaces are the

MVS master address spaces, an IMS/VS MPP or BMP, TSO

address space, JES or CICS/VS.

- The connecting address spaces may be MVS master or JES for

MVS broadcasts (EOM, FEOT, commands, etc.), and the

broadcast must be processed synchronously.

- The connecting address spaces should not be aware of the

connection/disconnection requirement. This process must

1

Page 2 of 3

be automatic.

- The connecting address spaces may choose to come up at any

time, before, during or...