Browse Prior Art Database

Serialize Cross Memory Post

IP.com Disclosure Number: IPCOM000079961D
Original Publication Date: 1973-Oct-01
Included in the Prior Art Database: 2005-Feb-26
Document File: 3 page(s) / 86K

Publishing Venue

IBM

Related People

Cannavino, JA: AUTHOR [+4]

Abstract

In OS/360 the POST and WAIT macros are used to communicate between asynchronous tasks by an Event Control Block (ECB). These macros may be used even though the two tasks are running in different regions. If one of the tasks is no longer interested in being notified of the event, care must be taken to serialize deletion of the ECB with the POSTing task to prevent subsequent POSTing of free core or worse. This serialization may be done with the Enqueue (ENQ) and Dequeue (DEQ) macro instructions, or in some cases, via physical disablement of the CPU. An example of logic which might be used is shown in Fig. 1.

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 53% of the total text.

Page 1 of 3

Serialize Cross Memory Post

In OS/360 the POST and WAIT macros are used to communicate between asynchronous tasks by an Event Control Block (ECB). These macros may be used even though the two tasks are running in different regions. If one of the tasks is no longer interested in being notified of the event, care must be taken to serialize deletion of the ECB with the POSTing task to prevent subsequent POSTing of free core or worse. This serialization may be done with the Enqueue (ENQ) and Dequeue (DEQ) macro instructions, or in some cases, via physical disablement of the CPU. An example of logic which might be used is shown in Fig. 1.

In OS/VS2 Release 2, the POST macro may, of course, no longer be used to communicate between tasks in different memories (since the ECB may not be and the Program Request Block (PRB) of the waiting task is not addressable from the posting task). The XMPOST (Cross Memory Post) macro was defined for this purpose - it requires as operands the Address Space Identification (ASID) of the Waiting task as well as the ECB address.

A problem exists in that the logic in Fig. 1 (with the POST replaced by an XMPOST) will fail, and moreover, no serialization technique extant at the time of the discovery of this problem is adequate to serialize deletion of an ECB with a task which might be XMPOSTing it. This is because XMPOST is a two-stage process. The XMPOST service routine called by the XMPOST macro schedules a Service Request Block (SRB) to the address space of the waiting task (specified by the ASID on the XMPOST macro) and returns to its caller. It is the routine which runs under the SRB which actually does the POST of the ECB. See Fig. 2. There are three possible solutions to this problem: 1)...