Browse Prior Art Database

Cell Directory Service Advertiser and Clerk Restart in an MVS Implementation of Distributed Computing Environment

IP.com Disclosure Number: IPCOM000116082D
Original Publication Date: 1995-Aug-01
Included in the Prior Art Database: 2005-Mar-30
Document File: 4 page(s) / 159K

Publishing Venue

IBM

Related People

Kalia, SK: AUTHOR [+2]

Abstract

An algorithm for starting the Call Directory Service (CDS) Advertiser and Clerk in an MVS implementation of the Open Software Foundation (OFS) / Distributed Computing Environment (DCE) is disclosed. This algorithm preserves the availability and integrity of CDS services. The initialization sequences of the Advertiser and Clerk are changed to o enable the Advertiser to be restarted without stopping and restarting the Clerk o ensure that the Advertiser and Clerk are started in the correct sequence.

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

Cell Directory Service Advertiser and Clerk Restart in an MVS Implementation
of Distributed Computing Environment

      An algorithm for starting the Call Directory Service (CDS)
Advertiser and Clerk in an MVS implementation of the Open Software
Foundation (OFS) / Distributed Computing Environment (DCE) is
disclosed.  This algorithm preserves the availability and integrity
of CDS services.  The initialization sequences of the Advertiser and
Clerk are changed to
  o  enable the Advertiser to be restarted without stopping and
      restarting the Clerk
  o  ensure that the Advertiser and Clerk are started in the correct
      sequence.

      Unlike the OSF/DCE implementation of CDS on UNIX* (where there
is one CDS Clerk for every CDS Client), the MVS implementation has
only one instance of CDS Clerk active on the system.  On MVS, this
Clerk services all CDS clients and is a long living process.  It must
be running on the system in order for the CDS services to be
available.

      The initialization sequence of the Advertiser in the OSF/DCE
implementation is made up of the following steps:
  1.  Create a shared memory segment for the CDS Cache.
  2.  Read the cached data saved to file during a previous instance
of
       the Advertiser and initialize the Cache shared memory segment
       with this data.
  3.  Create the semaphore to control access to the Cache and store
the
       semaphore ID in the Cache Header (The fixed part of the cache
       where cache wide internal data is stored.  This is implemented
as
       the CacheFixed structure.)
  4.  Write the Cache shared memory ID (Cache ID) and the Cache
       Creation Time Stamp (Cache CTS) to the cdscache.shmid file.
The
       Cache CTS is the time the shared memory segment was created.

      This initialization sequence must be modified in the MVS
implementation so that the Advertiser can determine whether the
correct shared memory segment (the Cache) already exists and whether
the Clerk is running.  If these two conditions exist then the
Advertiser can simply attach to the shared memory segment and use the
existing semaphore ID stored in the Cache Header.  In this case, a
new Cache should not be created.  CDS Advertiser Restart Algorithm -
The following is the new algorithm for the initialization sequence of
the Advertiser.
  Step 1.  Read the Cache ID and Cache CTS from the cdscache.shmid
   file.  If the file does not exist then assume that the Advertiser
   is starting up for the first time and go through the regular(the
   regular initialization sequence referred to here is the original
   OSF/DCE Advertiser initialization sequence described on Page 1)
   initialization sequence as described above.
    In case of any error, log an error message and terminate.
  Step 2.  Using the Cache ID read from the file, attach to the
   shared memory segment through the shmat syste...