Home
Extending HCL OneDB™Beyond standard relational database objects, HCL OneDB™ can be extended to handle specialized data types, access methods, routines, and other objects. HCL OneDB™ includes many built-in extensions that are fully integrated in the database server. HCL OneDB™ also provides DataBlade® modules, which are packages of extended database objects for a particular purpose and that are installed separately from the database server. Alternatively, you can create your own user-defined objects for HCL OneDB™.
Creating extensionsYou can create user-defined data types, routines, access methods, and other database objects to suit your needs. You can use application programming interfaces to write user-defined routines and applications that access data in HCL OneDB™ databases.
DataBlade® Developers KitThe DataBlade® Developers Kit (DBDK) guides contain information about the tools you can use to develop and package DataBlade® modules, which extend the functionality of HCL OneDB™ databases.
DataBlade® Developers Kit User's GuideThe HCL OneDB™ DataBlade® Developers Kit Users Guide describes how to use OneDB® DataBlade® Developers Kit (DBDK) tools to develop and package DataBlade® modules.
Debugging and testing DataBlade® modules on UNIX™This section describes how to debug and perform functional tests for DataBlade® modules written in C for HCL OneDB™ on UNIX™.
Debugging a DataBlade® moduleDebugging a DataBlade® module is usually an iterative process, repeated many times until the code is debugged.
Identify the server processTo debug a routine, you must identify the virtual processor in which that routine runs. By default, routines are assigned to the CPU virtual processor class. However, when you create a routine in BladeSmith, you can specify if it is poorly behaved and assign it to a user-defined virtual processor class.

Identify the server process

To debug a routine, you must identify the virtual processor in which that routine runs. By default, routines are assigned to the CPU virtual processor class. However, when you create a routine in BladeSmith, you can specify if it is poorly behaved and assign it to a user-defined virtual processor class.

To identify the virtual processor class assigned to a routine, look at the property page for the routine in BladeSmith. If the class field is blank, then the routine runs in the CPU VP. See C programming guidelines for more information about user-defined virtual processors.

Important: If you have more than one instance of a virtual processor in a CPU or user-defined virtual processor class, threads can migrate between virtual processors, making debugging difficult. To simplify debugging, configure your database server so that there is only one instance each of the CPU VP or user-defined VP used by the routines in your DataBlade® module.

To find the process ID (PID) of the CPU or user-defined virtual processor that you want to debug, execute the onstat command, as follows:

onstat -g glo

The last section of the output of this onstat command is similar to the following example.

Figure 1: Sample onstat command output

Typically, the PID circled in the sample output is the one you need. In this example, there are no user-defined virtual processor classes; all the DataBlade routines are marked as well behaved and run in the single instance of the CPU VP.