APLawrence.com -  Resources for Unix and Linux Systems, Bloggers and the self-employed

Unixware and the Open Server Kernel Personality

© January 2004 Roberto Zini

© January 2004 Roberto Zini, Strhold Sistemi Edp - Italy

For Italian surfers, soon there will be the Italian version of this article published here:

https://www.strhold.it -> AREA PARTNERS -> Case History

The Italian article was ready before the one in English; I'm just waiting for it to be published ..

The OpenServer Kernel Personality (OKP) module is a special layer of software that can be installed over an existing UnixWare 7.1.3. system as to allow existing OpenServer 5.0.x applications to run unmodified under the UnixWare7 environment. This module allows users with existing OS5 apps to migrate to the newer UW7 platform without having to reinstall or configure the software.

The module can be freely downloaded from SCO's site at the following URL: https://www.sco.com/support/update/download/okp.html

Mind you that the OKP comes in 2 versions: the LITE one is free of change whereas the FULL one comes with a small fee (please get in touch with your local SCO reseller for additional info).

The difference is that, with the LITE version, you MUST have an existing PC with SCO OpenServer 5.0.x installed (and operating) from which a copy across the network will be performed as to migrate all the files/data on the OS5 box to the UnixWare7 one. The network copy is NOT the only method you can choose to perform the migration but, for sure, it's one of the fastest.

This is a good solution for people who cannot reinstall their software from scratch on the UW7 platform (eg, they lost the installation media) or wish to preserve their unmodified configuration files.

The FULL version comes with a SCO OS 5.0.7 media kit (CD-ROM) from which you can perform the installation: in this case, you'll end up installing a "fresh" version of OS5 on the UW7 box over which you can install and configure your application software.

This is a good solution for people preferring a clean installation and a complete configuration of the virtual OS5 environment.

The OKP solution is __NOT__ an emulator in the real sense of the word but rather a "personality": that means that a special layer of software is installed into the UW7 kernel as to perform an "on-the-fly" translation between OS5 syscalls and UW7 ones. So the system must not spend part of its time trying to recreate a "virtual machine" under which OS5 applications will be executed. Instead, native OS5 system calls will be "adapted" to the ones available under UW7, thus vastly reducing the overhead required to run the hosted applications and granting an excellent execution speed (and a pleasant user experience :-).

Likewise, hosted OS5 applications will have access to CPU(s), memory, disks, devices, IPCs available on the UW7 box: that means that an OS5 application running under OKP will have access to a chunk of memory shared by an already running native UW7 application. Also, you could run an OS5 application "piped" to an UW7 application and (possibly) a Linux one, as in the following example:

        <OS5_app> | <Linux_app> | <native_UW7_app>

The same goes for network sockets: since OKP can transparently see the underlying UW7 network stack, you could write a network application which listen(S) on a given TCP/IP socket on the IP address given to the UW7 box. Clients on the LAN will be able to connect to the UW7 box and access the OS5 application without having the sysadmin to modify a single line of code.

As an example, you might issue a "ping" statement while you're inside the OKP environment and it'll work. The same applies to ftp, telnet, lp and what have you.

During our tests we used a PIII-700Mhz system equipped with 256MB of RAM, an Adaptec 39120 controller with a 8GB SCSI disc and an Intel 10/100 network card. This system was powered by UnixWare 7.1.3 patched with Maintenance Pack 3 (available free of change from SCO).

Our aim is the replication of an existing OpenServer 5.0.7 server on which we want to install Informix OnLine 7.31 .

Installing the OKP module on UW7 is a piece of cake; it's only a matter of a simple "pkgadd" command and, after rebooting the server, you're ready for the installation of the OS5 image.

As an example, we give the downloaded package the name of


To install it:

        pkgadd -d /home/test/OS5_compa_LITE.pkg

You can also use the following syntax:

        cat OS5_compat_LITE.pkg | pkgadd -d -

The package being installed will have a name of "osrcompat"; you can, at any time, check that it's been completely installed by running the following command (as root):

        pkginfo -lc set osrcompat

Since our existing OS5 box is available on the LAN, we select the "migrate" procedure as to copy data across the network; again, this is the simplest & fastest solution but if your OS5 box is not connected to a LAN you can always choose a different copy method (eg, via TAPE, CD-ROM, DVD ...).

The "Getting Started with OKP" available through DocView once the package is installed will give you plenty of info concerning this issue.

Before proceeding with the copy we have to setup a "remote equivalence" between the two systems; since the "migrate" script performs remote commands on the OS5 box we have to create a


file as to allow root access from connections coming from the UW7 box.

Mind you that the above file __MUST__ be chmoded to 600 and owned by root. Before issuing the following command, a test with

        rsh <OS5_HOST> <comman>d

from the UW7 is strongly suggested.

To test the Informix OnLine 7.31 server we have to create an "informix" group and an "informix" user, as suggested by the Informix installation notes. This operation __HAS__ to be carried out while operating on the UW7 personality since the user database and other critical subsystem are still managed from there.

Our personal suggestion is the creation of the user __before__ the importing process takes place.

This is the command we issue on the UW7 side for the data copy:

        /usr/lib/okp/bin/migrate -h <os5_system_name>

The above is a simple shell script you could study/hack as to adjust it to your needs (even this is/will not the case for most installations) and it's based on the "pax" utility as to copy the data across the network path.

The time it takes to complete the command is HW/LAN dependend: in our case (the OS5 server was a plain EIDE vanilla system, equipped with a PIII-800Mhz CPU, 512MB of RAM and a 40GB EIDE HD) it takes approx 25 minutes for the copy to complete. Your mileage may vary according the the amount of data you have on the OS5 box and the overall speed of the systems involved.

The just copied data go under the


folder of the UW7 system so you can easily access them from there.

At the end of the copy, we run the


command. This command allows the system to "adjust" some aspects of the "imported" system as to adapt it to the UW7 platform (eg, the creation of symlinks, some directory mounts ...).

Before performing the above I'd suggest you to check if you have files under the /openserver/home directory (in other words, check if you have a /home directory in your OS5 box): we actually had it and the import script managed to screw things a little bit, in the sense that the /openserver/home directory is the mountpoint for the general UW7/LKP "home" filesystem.

When the mount takes place, it'll cause existing contents to disappear (they are available in single user mode __BEFORE__ mount takes place) so please rename (mv) the /openserver/home dir to a different name __BEFORE__ performing the import command.

When "import" finishes, we're ready to test the new environment.

Similiarly to LKP (the Linux Kernel Personality), you can "switch" to the virtual OS5 by issuing "openserver" while at the shell prompt: this will "chroot" you to the /openserver folder under which you'll find all the files & data you had on your OS5 server.

As it is for the LKP personality, the original UW7 commands & files are still available under the



As to test the Informix environment, we decide not to import an existing Informix dbase but to perform a new installation, just to give it a try.

In order to access the CD-ROM, you have to install it while operating under the UW7 personality; a command such as the following one will suffice (as root):

        mount /dev/cdrom/cdrom1 /openserver/mnt

You can now log into the system as "root", issue the "openserver" command and cd into the "/usr/informix" folder: from there, you can explode the OnLine "cpio" file (under /mnt) and run the


to complete the installation.

A nice feature under OKP is that you don't need to modify some kernel parameters that, under the real OS5 system, you are required to change for the dbase engine to run. In fact, most UW7 kernel parameters size dynamic kernel tables that can automatically grow up to a certain level. Mind you that I'm not saying you'll never have to change 'em but, during our tests, the engire executed swimmingly well without having to touch a single bit into the kernel.

Again, mind you we tested the Informix engine with only one user; performances (and tuning) will probably change when accessing the server with multiple concurrent users.

Before starting the engine, you have to create some environment variable into the user informix's .profile (such as INFORMIXDIR) and add $INFORMIXDIR/bin (usually "/usr/informix/bin") to the existing PATH variable.

Also, you need to make sure the following is into the above .profile file:

        export OSR5PATH

When switching to OKP, the PATH variable will be set to a given value unless the above OSR5PATH is defined; doing so will provide the user with the right path to access their Informix applications and commands.

Last, you'll have to check the contents of the




files as to adapt it to your needs and amend the


files according to the installation notes.

The command "oninit -iv" initializes the database engine; please keep in mind that the "-i" option will actually "destroy" the contents of the root dbspace and will initialize it from scratch. Once your root dbspace's been created, you can simply start the engine by using the

        oninit [-v]

command while logged in as user "informix" under OKP (again, you'll have to switch to it by typing "openserver" while at the UW7 shell prompt).

The optional "-v" option will increase the "verbosity" of the command (useful if something goes wrong at this stage).

By using the "dbaccess" tool we are then able to test the engine and to import an existing dbase from a different box; also, we set it up as to allow local PCs (running on our LAN) to connect to it and perform queries and updates of the existing database.

If you want your local users to access the UW7 box and fire up an OS5 application, you'll have to modify their $HOME/.profile file as to include the

        openserver <path_to_the_os5_application>

statement. If you're using a client-server application (such as Informix), you don't have to do that.

The results of the tests we performed on the engine will be reported later.

As previously explained, you can "pipe" applications from different personalities in a single shell command: as an example, you could execute

        openserver /bin/ps | wc -l

while operating from the UW7 shell. In the above case, the system will execute the OS5 "/bin/ps" command piped through the UW7 "wc" command.

A more complicated mix could be achieved by inserting a new pipe level with an LKP command, such as this:

        openserver /bin/ps | <linux_filter> | lp -dprinter

In the above case, the output of the OS5 /bin/ps command will be processed by a shell script running (eg) the Linux incantation of perl. The <linux_filter> shell script whose first line should be set to

        #!/linux/usr/bin/perl -w

as to tell the UW7 shell to execute the Linux/LKP version of perl.

The output of the filter will be printed by the UW7 native "lp" command.

If you want to access the OS 5.0.7 man pages under OKP, you'll have to modify the


file and change the line which referes to




Under OKP you can access (almost) all the same devices available on the real OS5 box; as an example, you could print to the parallel port by accessing the


device under OKP such as in the following example:

        cat filename > /dev/lp0

We were not able to use UW7 commands to access the line printing subsystem as I was used doing under OKP; as to print to a remote print server using the LDP protocol we had to fire up "scoadmin printer" (under OKP) to define a new remote printer just as if we were operating on a real OS5 box. Once the printer was configured, we had to fire up


from OKP and print jobs were successfully delivered to the remote printer.

If you have commands/services fired up via /etc/rcx.d on your native OS5 box, you'll have to check under UW7 /etc/rcx.d since a new script is inserted as to exclude the execution on typical OS5 startup scripts.

Last, keep in mind that you can have control over many aspects of the OKP environment by accessing the


under UW7.

As far as performances are concerned, we had mixed results.

In order to perform some "speed" tests we partitioned the above PC disk into 2 parts: one running a native OS 5.0.7 system and the other running a virtual OS 5.0.7 system under OKP. Every test was performed several times after a clean reboot (as to avoid performance hits due to the system cache).

The table at the end of this article details some of the tests we made.

The first one was focused on the use of the "openssl speed" command executed under both systems; as you will notice, the raw CPU power is approx the same, with the real OS 5.0.7 system being a bit faster than the OKP one (by a 2-3% factor) in some tests and OKP being a bit faster on some other ones. This seems to indicate that the OKP module does not overhead the system while performing intensive CPU ops, thus giving an excellent user & application experience.

The second one saw the use of the good old "glimpseindex" utility as to index approx 7231 ASCII files; under the real 5.0.7 box it took approx 47.00 secs while the very same command under OKP took 44.99 secs. Again, the difference is minimal.

Next, we switched to some tests which involved the extraction of a 70MB tar file (tar xvf). Under the real 5.0.7 box it took 20 secs and under OKP the same process took 1m04secs. This seems to indicate that, without tuning the system, disk write operations seem to complete faster on the real 5.0.7 box by a factor of 1/3.

Some interesting results came out of the tests which involved the Informix engine. Using the "dbimport" command we imported an existing dbased (exported from another box) into the root dbspace managed (on a local filesystem) by the Informix engine.

The real OS5 box took approx 9m41secs to finish the operation whereas the OKP took 10m44secs.

An "update statistics high" performed on every system gave (again) different results: in this case, OKP outperformed a real OS5 system with 1m06secs vs 1m38secs.

The most interesting result we had was related to a "select" SQL statement performed against the imported database (after a clean reboot) on a couple of non-indexed tables. OKP literally smashed the real OS5 system with a time of 1m21secs agains the 4min47secs of its counterpart.

AFAIK, the "select" operation simply reads the given tables in a linear order and performs a sort of the results thus obtained: again, this made us think about a different optimization/caching in use on the OS5 and UW7 systems, with the OS5 being faster on WRITE operations and UW7/OKP being faster on READ operations.

During the "select" phase we had a look at the stats reported by "onstat" and it appeared that the dbase was able have the same cache hit % (approx 55%) on every system.

On a discussion on the comp.unix.sco.misc newsgroup, Robert Lipe offered the following:

=== cut here === 8< ===
>> I performed some other non Informix related tests such as "openssl 
>> speed" (OS5 outperformed - in some case - OKP by a factor of 2-3%) and a 
>> "tar xvf" of a 80MB file, which again showed that OS5 was faster (20s vs 
>> 1m04s).

UnixWare's 'tar' and UnixWare's default filesystem paramaters conspire
to deliver an, uuuuh, less than satisfying performance experience.
The rapid creation of files and the explict call to fsync is an
achilles heel.  Be sure your filesystems are being mounted without
'mincache=closesync' to help things along.   I also find GNU tar to be
about 30% faster on extraction than either of the System V tars shipped
with UnixWare.

[ we checked and the above option was __NOT__ present ]

>> optimized filesystem performances, I was wondering if UnixWare7/OKP (out 
>> of the box) can indeed be faster than OS5 while __READING__ and slower 
>> while __WRITING__.

I know both systems reasonably well and I'm sure I can produce a test
showing either one faster depending on who is asking.  The results
you posted aren't really suprising to me.  I do suspect with only minor
tweaking, you can reduce or eliminate the write penalty.

On modernish, robust hardware, it doesn't suprise me that UnixWare +
one of the personality modules outperforms the OS being impersonated
in many (not all) cases.  If the environment being tested it totally
computationally bound in user space, I'd expect it to be a wash.  The
more time you spend using OS services like VM or I/O, the more you're
likely to gain, but there are specific services that will go either way.

The filesystem paramaters have a LOT to do with perceived performance,
esp in a case like your tar extraction test.  If you're spending your
life creating and writing what are essentially temporary files (as one
might be when, say, compiling software) it's worth noting that the UW
filesystem defaults may penalize you.


=== cut here === 8< ===

We followed the above links and tried with several aggressive tuning but unsuccessfully; perhaps Robert has more tricks up his sleeve than we do :-) .

We expressely asked Robert to provide some but probably he's too busy at the moment to provide us with an answer; however, we'll update this article should something new arise.

Have a pleasant experience with OKP !

OpenSSL speed (processore)

Test Native OS5 OKP % Native OS5 OKP % Native OS5 OKP % Native OS5 OKP % Native OS5 OKP %
md2 14,47 14,49 100.09% 42,36 42,28 99.80% 58,25 58,18 99.88% 64,3 64,2 99.83% 66,34 66,23 99.82%
mdc2 63,64 63,6 99.94% 76,37 76,26 99.87% 78,16 77,78 99.52% 78,29 78,43 100.19% 78,48 78,3 99.75%
md4 147,65 147,06 99.60% 998,05 996,22 99.82% 2694,56 2668,12 99.02% 2004,15 1890,6 97.60% 636,03 509,28 97.92%
md5 138,77 139,05 100.21% 905,8 894,41 98.74% 2303,33 2280,67 99.02% 987,46 977,36 99.73% 1832,09 1820,92 99.75%
hmac(md5) 115,2 115,1 99.90% 764,36 762,96 99.82% 2070,96 2061 99.52% 809,09 794,56 99.59% 1619,36 1622,59 100.07%
sha1 107,51 107,8 100.27% 620,11 624,07 100.64% 1355,35 1359,47 100.30% 1936,15 1921,8 99.26% 2190,33 2188,63 99.92%
rmd160 96,48 96,85 100.39% 527,06 527,18 100.02% 1093,13 1090,68 99.78% 1487,4 1487,33 100.00% 1662,46 1664,59 100.13%
rc4 2128,93 2139,56 100.50% 201,97 184,58 99.41% 378,03 364 99.55% 413,99 410,71 99.90% 426,97 421,23 99.82%
des-cbc 578,2 577,01 99.79% 638,82 641,92 100.48% 649,67 651,39 100.26% 654,68 654,06 99.91% 654,44 653,43 99.85%
des-ede3 219,8 218,42 99.37% 230,3 229,7 99.73% 231,53 231,09 99.82% 232,64 231,56 99.54% 232,03 231,43 99.74%
idea-cbc 292,89 288,04 98.35% 315,72 307,8 97.48% 319,76 311,27 97.34% 319,66 312,19 97.66% 319,57 312,34 97.73%
rc2-cbc 218,33 219,35 100.47% 237,69 237,03 99.73% 239,81 239,07 99.68% 240,36 239,98 99.84% 240,53 240,09 99.81%
rc5-32/12-cbc 1417,61 1422,36 100.33% 1835,94 1827,96 99.56% 1926,55 1923,45 99.84% 1920,9 1912,01 99.54% 1921,36 1978,15 102.96%
blowfish-cbc 845,17 845,88 100.08% 971,17 966,25 99.49% 993,3 983,04 98.97% 1002,04 985,4 98.34% 1009,4 993,06 98.38%
cast-cbc 827,48 830,04 100.31% 960,87 959,56 99.86% 979,68 982 100.24% 988,08 988,85 100.08% 989,2 988,5 99.93%

rsa--512-bits 0,0160 0,0160 100.00% 0,0014 0,0014 100.00% 18,4201 18,5000 100.34% 205,3375 207,2549 100.94%

rsa-1024-bits 0,0743 0,0743 100.00% 0,0042 0,0042 100.00% 3,8778 3,8757 99.68% 75,0042 74,5868 99.44%

rsa-2048-bits 0,4340 0,4361 100.48% 0,0125 0,0125 100.00% 0,6667 0,6313 99.38% 22,8389 22,7500 99.49%

rsa-4096-bits 2,8667 2,8993 101.14% 0,0438 0,0438 100.00% 0,0861 0,0861 100.00% 6,5854 6,5875 100.19%

dsa--512-bits 0,0132 0,0132 100.00% 0,0153 0,0153 100.00% 22,3750 22,4174 100.20% 18,5479 18,7521 100.99%

dsa-1024-bits 0,0361 0,0375 103.85% 0,0451 0,0444 98.46% 7,9229 7,7514 97.54% 6,4174 6,5438 102.08%

dsa-2048-bits 0,1208 0,1208 100.00% 0,1479 0,1479 100.00% 2,3785 2,3785 100.00% 1,9229 1,9229 100.00%

Test Native OS5 OKP

Informix dbimport 9:41,00 10:44,00

Informix update statistics 1:38 1:06

Informix select 4:47 1:21

Glimpse reindex 47,06 44,99

Tar explosion 20,27 1:04

Got something to add? Send me email.

(OLDER)    <- More Stuff -> (NEWER)    (NEWEST)   

Printer Friendly Version

-> Unixware and the Open Server Kernel Personality

Inexpensive and informative Apple related e-books:

Take control of Apple TV, Second Edition

Photos: A Take Control Crash Course

Photos for Mac: A Take Control Crash Course

Take Control of Numbers

Are Your Bits Flipped?

More Articles by © Roberto Zini

Great article, Roberto. Thanks!


I wonder how those performance numbers would look running on late-model AMD Athlon hardware.


Printer Friendly Version

Have you tried Searching this site?

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us

Printer Friendly Version

In fact, my main conclusion after spending ten years of my life working on the TEX project is that software is hard. It’s harder than anything else I’ve ever had to do. (Donald Knuth)

Linux posts

Troubleshooting posts

This post tagged:





Unix/Linux Consultants

Skills Tests

Unix/Linux Book Reviews

My Unix/Linux Troubleshooting Book

This site runs on Linode