Browse Prior Art Database

Cell Directory Service - Single Clerk per System on MVS / OS400 Distributed Computing Environment

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

Publishing Venue

IBM

Related People

Cho, DY: AUTHOR [+3]

Abstract

The Open Software Foundation (OSF)/Distributed Computing Environment (DCE) implementation does not scale well on large systems such as MVS and OS/400. This is because the base OSF/DCE implementation forks off a Cell Directory Service (CDS) Clerk for every CDS client on the system. To support a large number of CDS clients, it would require a larger number of CDS Clerk processes which would consume large amounts of system resources. This is not acceptable on large systems like MVS and OS/400. Furthermore, on the OS/400 platform, fork system call is not supported and as a result the base OSF/DCE implementation cannot be ported on the OS/400.

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

Cell Directory Service -  Single Clerk per System on MVS / OS400
Distributed Computing Environment

      The Open Software Foundation (OSF)/Distributed Computing
Environment (DCE) implementation does not scale well on large systems
such as MVS and OS/400.  This is because the base OSF/DCE
implementation forks off a Cell Directory Service (CDS) Clerk for
every CDS client on the system.  To support a large number of CDS
clients, it would require a larger number of CDS Clerk processes
which would consume large amounts of system resources.  This is not
acceptable on large systems like MVS and OS/400.  Furthermore, on the
OS/400 platform, fork system call is not supported and as a result
the base OSF/DCE implementation cannot be ported on the OS/400.

      To solve these problems, the OSF/DCE implementation is changed
from a Clerk per Client to a Single Clerk per system, i.e., only ONE.
CDS Clerk to service all CDS clients on the local system.

The main differences from the OSF/DCE (UNIX*) model are:
  o  The CDS Clerk, instead of getting forked off from Advertiser, is
      started separately through JCLs (Procs), etc.
  o  Unlike the OSF/DCE(UNIX) model, CDS Clerk runs as a long living
      task, i.e., it does not kill itself if there is no
Client<->Clerk
      activity for more than 20 minutes.
  o  The Clerk listens on a well known local socket on the system.
No
      Read/Write permission bits are set on this socket so any Client
      can bind to the Clerk and get CDS Services.
  o  The CDS Clerk runs as a super user on the system.  It has read
      permission to all credential cache files containing the login
      Context of any client.  Such access permissions are absolutely
      essential for the Clerk to be able to import the login Context
of
      any client.  In OSF/DCE 1.0.2 Clerk also runs as a super user
on
      the system.  This is because exclusive Read/Write permission
bits
      are set (for the Advertiser) on the shared memory (cache) in
      order to prevent access/update to cache directly from other
users
      on the system.  Only super users on the system can access the
      cache directly.  This forces the Clerk also to run as a super
      user on the system.
  o  Unlike the OSF/DCE(UNIX) model, the Client does not talk to the
      Advertiser at all because there is no need for this
      communication.
  o  The shared memory ID (CacheId) is passed from the Advertiser to
      Clerk through a file.  In the UNIX model, the Clerk inherits
the
      CacheId from Advertiser during the forking operations.

      The following diagram shows the Client-Clerk-Advertiser
interactions on the MVS and OS/400 systems in the Single Clerk Model.
MVS Model exploits the facility offered by the Open Edition MVS
system to run Multiple Processes in an address space.  Both Clerk and
Advertiser run in the...