Types of Methods

A method is logic in the form of an executable program that is loaded into a RODM address space and is run under certain circumstances. Methods are classified according to the circumstances under which they are run. Several kinds of methods are architected into the RODM product to supply specific kinds of functions. All methods are optional, and the function provided by methods can be used or not, depending on how classes, objects, and methods are defined, organized, and applied in RODM. In broad terms, there are two kinds of methods: object-independent methods, and object-specific methods.
  • Object-independent methods are like callable subroutines that run inside RODM. They can act on many different objects in RODM. Object-independent methods are triggered using the EKG_TriggerOIMethod function, which can be issued by user applications, by other object-independent methods, and asynchronously by object-specific methods.
  • Object-specific methods are run only in the context of a particular object. For example, they are run by transactions that refer to a specific object. When an object-specific method is running, it has access only to the data in the fields and subfields of that object. Object-specific methods in RODM can be triggered as side effects of a transaction (the query, change, and notify methods previously described or by explicit reference (named methods that are run upon explicit request).

Methods can refer to data and manipulate data in RODM objects. Through the routines in the method API, methods can query and change the fields and subfields of the RODM objects to which the methods have access. Methods must use the method API to access data in the RODM data cache.

The different methods and their uses are described on the following pages. A pseudocode description of the method interface is included with each explanation. These descriptions describe only the parameters, not the exact interface. The parameters are assumed to be passed to the method by address. The pseudocode examples (in PL⁄I style) are not intended to imply PL⁄I parameter passing conventions, such as using descriptors for structures. The method interface is intended to be consistent with the user API style of interface where parameters are pointers directly to the passed data.