Browse Prior Art Database

NetWare Loadable Modules Bindery Monitoring

IP.com Disclosure Number: IPCOM000115908D
Original Publication Date: 1995-Jul-01
Included in the Prior Art Database: 2005-Mar-30
Document File: 2 page(s) / 123K

Publishing Venue

IBM

Related People

Newpol, RS: AUTHOR

Abstract

A method for handling the NetWare Server Bindery Create/Delete events is explained. The method is applicable for handling any NetWare Server OS Events, and involves using the server's Asynchronous Event Scheduler (AES) to allow blocking during event processing.

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

NetWare Loadable Modules Bindery Monitoring

      A method for handling the NetWare Server Bindery Create/Delete
events is explained.  The method is applicable for handling any
NetWare
Server OS Events, and involves using the server's Asynchronous Event
Scheduler (AES) to allow blocking during event processing.

      Netware is a non-preemptive, multi-tasking operating system.
In order to function properly, NetWare server applications, also
called NetWare Loadable Modules (NLMs), must periodically give up
control of the CPU, allowing other tasks to run.  When an NLM gives
up the CPU temporarily, it is said to be 'sleeping' or 'blocked'.
Many of the standard API calls in the NetWare C Library of functions
(CLIB), used by NLMs, cause an NLM to sleep when called.  However,
during OS Event handling, an NLM can cause the server to abend if it
sleeps while processing an event.

      NetWare File Servers have a function that developers of NLMs
can use to trap certain events which might be relevant to the
application.  Two examples of such events are the Bindery Object
Delete (BOD) and Bindery Object Create (BOC) events.

      These events occur whenever an object is added to, or removed
from, the server's Bindery for any reason (the Bindery is a
object-oriented server database, used by the OS and its
applications).  An NLM might need to know, for example, when a user
record is deleted from the database in order to make a log entry for
administrational records.  In such a case, the NLM would need to
examine data in the object that was created or deleted, and perhaps
make certain function calls to system or application functions to
complete the event handling.  The problem with the basic support
provided to handle these events is that handler code cannot call
functions which 'sleep' or 'block', but certain events cannot be
processed without making such function calls.

      For some events, such as the BOC and BOD, this presents a
special problem, because the event handler is not given enough
information to properly handle the event.  The BOD and BOC event
handlers are only given the Bindery ID, a number used to index the
actual object in the Bindery.  The problem is, accessing the Bindery
causes the application to sleep.  One solution is to set a global
flag to signal an application thread to process the event, given the
information obtained (such as the Bindery ID).  However, once the
event handler thread completes, the information provided may not be
valid.  For example, after the completion of the BOD event handler,
the object is deleted, and the Bindery ID is invalid.  There is no
chance to retrieve information from this Bindery object as part of
the BOD handling.  In fact, there is no way to even know what KIND
(type) of object was deleted, since the BOD event occurs for ALL
types.

      A better solution to this problem is for NLMs to shadow, or
maintain a copy of, any Bindery objects of interest.  T...