A Look at What's New in SOM 2.1

Written by Gordon Zeglinski

I finally got the SOM 2.1 toolkit. In this issue, we'll look at its new features and then compare its benchmark results with those of SOM 2.0.

Before we move on, let's look at some miscellaneous details. I strongly recommend that anyone installing SOM 2.1 over SOM 2.0 edit their CONFIG.SYS files and then reboot OS/2 to disable the 2.0 toolkit before installing. This will make installation much simpler and helps insure it works the first time. The installation is pretty much the same as that of the 2.0 toolkit. Outside of a small install manual, the toolkit no longer contains any printed documentation. The CD contains a set of PostScript files one can print to make manuals, and some FrameView files. This is where I get really annoyed at IBM. They only ship a Windows and AIX version of the on-line documentation viewer! This means that you have to run WIN-OS/2. Thus, losing all the resources it uses while running the memory hungry development tools. This quickly makes 20 megs of RAM look pretty small.

What's New in SOM 2.1
There are many new features in the 2.1 toolkit. Overall I think a fair summary would be saying it's more C++ like but still retains all of the OOP abilities from the 2.0 version. Direct To SOM (DTS) C++ compiler support is now included along with support for the 32 bit TCP/IP stack available in TCP/IP 2.0 for OS/2 and the Internet Access Kit in Warp. The use of somInit and somUninit is no longer recommended. Instead, a more C++ like method of doing initializers is recommended. The methods somDefaultInit, somDefaultConstCopyInit and somDestruct have been added. These methods correspond to the default constructor, copy constructor and destructor in C++. In addition there's now support for an assignment method. The somDefaultConstAssign method provides this mechanism and is equivalent to the operator = in C++.

In our previous SOM articles, metaclasses were used to provide class data and constructors. Recall that class data is analogous to static data in C++. SOM 2.1 now supports staticdata variables. When this is combined with the new method of specifying constructors/initializers, metaclasses are rarely needed now. The modifiers somallocate and somdeallocate allow user defined memory allocation and deallocation functions to be used when creating an instance of the object. This is similar to overloading the new and delete operators in C++. This concludes our brief look at what's new in SOM 2.1. I haven't covered any of the new features in DSOM because we haven't previous looked at DSOM.

Benchmarking SOM 2.1
The SOM 2.1 documentation claims that SOM 2.1 is faster than SOM 2.0. In this section, we'll present the revamped SOM benchmark code and compare the results of running the SOM 2.1 benchmark with those previous obtained for SOM 2.0 and C++.

Let's start by looking at the new SOMBENCH.IDL file.

//--- // SOMfoo //  Our SOM based test object //--- interface SOMFoo : SOMObject {   attribute long Count;	    // Stores the Count Data void IncrementCount;	  //procedure void OffIncrementCount;	  //offset void LookIncrementCount;   //lookup implementation {    releaseorder: _get_Count,_set_Count,IncrementCount,\ OffIncrementCount,LookIncrementCount; IncrementCount: procedure; LookIncrementCount:namelookup; callstyle=oidl; filestem = sombench; somDefaultInit: override; // initialize instance variables to 0 somDestruct:override; // just for fun }; };
 * 1) ifndef __SOMBENCH_h__
 * 2) define __SOMBENCH_h__
 * 1) include 
 * 1) ifdef __SOMIDL__
 * 1) endif /* __SOMIDL__ */
 * 1) endif /* __SOMBENCH_h__ */

There's no major difference between this version and the previous version of sombench. In fact, the only difference is that somInit and somUnitit have been replaced by somDefaultInit and somDestruct. Even though the definition isn't much different, the benchmark results are different. The following table shows the results of the benchmarks. ''Table 1. Comparison of call type overhead between C++, SOM 2.0 and SOM 2.1''

The times indicated are in milliseconds for 1000000 calls to a given function. The results for SOM 2.1 show that there are some speed increases and some decreases. In particular, the name lookup resolution method shows dramatic speed improvements.

Profile Files Revisited
To explore the new initialization methods, we will once again look at the "ini file" manipulation object. The definition for the revised SOM_CPPini file follows.

//--- // SOMfoo //  Our SOM based test object //--- interface ProfileFile; interface SOM_CPPini : SOMObject {   typedef unsigned long ULONG; typedef sequence buffType; void OpenFile(in string FileName); ULONG GetError; unsigned long GetHandle; void SetHandle(in unsigned long H); void WriteString(in string App,in string Key, in string String); // write a string void WriteData(in string App, in string Key,in buffType Buff, 	   in ULONG BLen);	  // write the Buffer void WriteInt(in string App,in string Key,in long Num); // write an "int" ULONG GetDataSize(in string App,in string Key); // return the lenght of the data void GetData(in string App,in string Key,in buffType Buff, 	   inout ULONG BufMax);     // return the data in Buff ULONG GetString(in string App,in string Key,in buffType Buff, 	  in ULONG BufMax, in string DefArg); // return the String in Buff, defaults to DefArg if App/Key not // present ULONG GetStringNoDef(in string App,in string Key, in buffType Buff, 	  in LONG BufMax);	    // return the String in Buff long GetInt(in string App,in string Key,in long DefArg); // return the "int" in App/Key or the DefArg if App/Key // not present long GetIntNoDef(in string App,in string Key); // return the "int" in App/Key void ProfileFileFromName(inout somInitCtrl ctrl, in string name); void ProfileFileFromHandle(inout somInitCtrl ctrl, in ULONG H); implementation {    ProfileFile INIFile; releaseorder: GetHandle,SetHandle,GetError,OpenFile, \WriteString,WriteData,WriteInt,GetDataSize,GetData, \GetString,GetStringNoDef,GetInt,GetIntNoDef, \ProfileFileFromName,ProfileFileFromHandle; callstyle=oidl; filestem = somcpp; somDefaultInit: override;   // initialize instance variables to 0 somDestruct:override;	  // just for fun ProfileFileFromHandle:init; ProfileFileFromName:init; passthru C_xh_after=  "#define INCL_WINSHELLDATA" \ "#include " \ "#include \"iniflobj.h\""; }; };
 * 1) ifndef __SOMCPP_idl__
 * 2) define __SOMCPP_idl__
 * 1) include 
 * 1) ifdef __SOMIDL__
 * 1) endif /* __SOMIDL__ */
 * 1) endif /* __SOMBENCH_h__ */

Additions to the interface definition are marked in bold. The revised definition has the functions ProfileFileFromName and ProfileFileFromHandle declared as initializers. This allows us to use a more C++ like method of creating an instance of SOM_CPPini. Following is the revised main routine for the object test file.

void main{ int i;   SOM_CPPini *Prf=new SOM_CPPini("test.ini"); Prf->WriteInt("App","Key",10); i=Prf->GetIntNoDef("App","Key"); printf("i= %i\r\n",i); delete Prf; } The new SOM_CPPini("test.ini") operation will create an instance of the SOM object SOM_CPPini and then call the initializer ProfileFileFromName. The SOM compiler will map each SOM initializer on to a C++ constructor provided the arguments to the SOM methods are different. Basically, this is the same rule that is imposed on C++ constructors; no two constructors can have the same arguments.
 * 1) include "somcpp.xh"
 * 2) include 

Wrapping Things Up
We now come to the end of our peek at SOM 2.1. The executables, which should run under WARP, and source code to these examples is included with this issue. We have briefly looked at the new features in SOM 2.1, benchmarked SOM 2.1 using the simple test code, and then explored the new methods used to initialize SOM objects. We have seen that many of the new features allow SOM objects to be more C++ like.

In the next issue, I hope to start looking at DSOM. I think DSOM/COBRA have the potential to radically alter the way client/server programming is done. For this reason, and my ongoing experience with programming INTERcomm and AdeptXBBS, the look at DSOM will be heavily skewed towards client/server type scenarios.