Browse Prior Art Database

Communication Scheme for Several Sibling Tasks

IP.com Disclosure Number: IPCOM000118581D
Original Publication Date: 1997-Mar-01
Included in the Prior Art Database: 2005-Apr-01
Document File: 2 page(s) / 68K

Publishing Venue

IBM

Related People

King, RG: AUTHOR [+2]

Abstract

Disclosed is a means for several sibling Multiple Virtual Storage (MVS) tasks to communicate asynchronously with each other via event control block postings. One scheduling task drives the actions of multiple work tasks asynchronously, and the work tasks return status about the completion of the requested actions asynchronously.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 52% of the total text.

Communication Scheme for Several Sibling Tasks

      Disclosed is a means for several sibling Multiple Virtual
Storage (MVS) tasks to communicate asynchronously with each other via
event control block postings.  One scheduling task drives the actions
of multiple work tasks asynchronously, and the work tasks return
status about the completion of the requested actions asynchronously.

      On MVS systems, work is often divided among tasks to allow
faster completion.  When one sibling task is scheduling the work of
several others, rapid asynchronous communication between the tasks
allows the work to proceed quickly.  This communication can be
accomplished by  establishing pairs of Event Control Blocks (ECBs) to
control the notification.

      The scheduling task maintains a queue of work elements, each of
which represents a piece of work to be scheduled.  The scheduling
task will perform whatever algorithm it uses to decide what action to
take for  which elements and to decide when to delete them.  Each
work element will  contain any necessary information about its piece
of work and will also  contain pointers to two ECBs.  The scheduling
task uses one to notify a  work task, and the work task uses the
other to reply to the scheduling  task.

      A work task creates a new work element with its associated ECBs
when new work exists.  The work task puts all appropriate information
into the work element and puts the element on the queue of the
scheduling task.  This interaction requires the work task to enqueue
and dequeue the  work element queue, so there is some synchronization
among the tasks.  When the element is queued, the work task posts the
scheduli...