Informix Ibcs Howto

Marco Greco [ marco@informix.com ], v1.0f, 15 September 1998

This Howto has been assembled in an attempt to better organize Informix on Linux material that was originally published on various issues of Tim Schaefer's [ tschaefe@mindspring.com excellent InxUtil [ http://www.inxutil.com/ ] online magazine.

What follows is not to be intended as an Informix tutorial, but just a list of hints, tricks and issues to be aware of when installing and setting up SCO 3.2.5.x ports of Informix products on a Linux system. Note however that iBCS support on Linux covers a wide range of ix86 unices (SYSV4 like UnixWare, Dell, USL or Interactive; i386 BSD; SYSV3 like SCO 3.2.4 or Wyse; Xenix). While this document does not cover the procedure to install and use Informix products for such ports, it should be fairly simple to draw the appropriate procedure from what it is described later. In particular, engines might at most require some shared libraries from the target OS; 4gl and esql/c of course require the presence of the target development system, and the definition of an appropriate INFORMIXC environmental variable.

Also, while the first part of this document is iBCS specific, the second equally applies to native Linux ports (in this respect, you might be interested to pay a visit to the Informix Developer Network [ http://www.informix.com/idn ]).

Credits

Mike Jagdis [ mike@roan.co.uk ] deserves to be thanked for sending me his hosted environment cc.ibcs2 script, which I used as base for what I describe later, and for writing the iBCS2 module, without which using the SCO port of Informix products on Linux would be impossible.

Disclaimer

You'll need valid SCO and Informix licenses, and must be prepared to refrain from using (and probably installing to start with) Informix software and the SCO development package on two different boxes at the same time. Of course, you'll be able to install both Linux and SCO on two different partitions, alternatively bootable, of the same box. SCO can mount DOS fs', and Linux happily handles SYSV (untested!) / DOS / VFAT , so either way you'll be able to move the SCO dev sys to Linux.
All this said, I still am not sure that you're not infringing either license agreement (even though SCO says nothing against using their software on a different OS)

To start with:

You need to have the iBCS module installed, and loaded. This is the only requirement in order to install and use engines or older versions of tools that don't require a c development system (isql and 4gl rds).

All major distributions ship some iBCS binary, and either install it by default (Red Hat), or let you choose whether to install it or not (SuSE & Slackware) or allow you to install it later (Caldera).
Red Hat, however, ships an iBCS binary which as been compiled against a previous kernel, and since neither the iBCS module nor the kernel have been compiled using version information, the two are inherently incompatible. Recompiling the iBCS module is the only workaround available.

Getting hold of the iBCS source code

The latest iBCS distribution, and some SCO/UnixWare shared libraries stands can be found at tsx-11 [ ftp://tsx-11.mit.edu/pub/linux/BETA/ibcs2 ]. Find a less recent version in the source directory of your distribution.

Recompiling and installing it

is a straightforward process. Just extract the source from the distribution, copy CONFIG.i386 to CONFIG, change configuration parameters according to the following guidelines

type make and make install and you are done. If you are using the kerneld daemon, the iBCS module will be loaded automatically as soon as you invoke any SCO binary. If you are not, execute insmod iBCS before invoking any SCO application.

Limitations

At the time of this writing, tlitcp connections do not work.

Further readings

The excellent iBCS docuentatio, found in the iBCS distribution, or in the documentation directory of you linux distribution. Info on the kerneld daemon can be found in /usr/src/linux/Documentation/modules.txt, or in the appropriate man page.

Something to be aware of: the TZ environmental variable

Linux time conversion functions (tzset, to be precise) gather timezone info from /usr/lib/zoneinfo/localtime, should TZ not be set. A side effect of this convenient alternative is that TZ has quietly disappeared from your average /etc/profile.

This is fine for native Linux apps, but not for SCO's running on iBCS, so you have hack /etc/profile to set TZ, or functions like TODAY and CURRENT will return incorrect values.
To avoid the hassle of changing TZ whenever DST is/isn't in effect, use the following two liner:

TZ=`echo -e \`date +%Z\`'\c'; expr \`date -u +%H\` - \`date +%H\``
export TZ

It will recompute TZ from the localtime file at each login. This, of course, will not work on timezones not differing from GMT by a whole number of hours.

Informix tools & iBCS

Most Informix development tools need a development package to be used, and that includes 4gl-RDS, if you ever wish to relink the runner. Note also that later releases of the tools distribute a dinamically linked brand, so just to properly install you need to move the SCO development package to the Linux box.

The small script below will conveniently pack it in a huge archive and create a script to fix .so symlinks on the target box.

---------------------------cut here------------------------------------------
#
#  must be run from the root directory to masquerade relative pathnames --
#  tar A flag strips / from filenames but not from target links!
#
cd /
#
# list all the files to be tarred, isolating simlinks to be created
# (tar -cPL follows the simliks but copies verbatim rather than creating
# links)
#
ls -l lib/*.a usr/lib/*.a lib/*.o usr/lib/*.o lib/*.so* usr/lib/*.so* \
 `find shlib usr/include usr/ccs -type l -print` | \
#
# this isolates .so* that should be simlinked - note that since, due to
# sorting problems, we not always get the links the right way round, we'll be
# using hard links instead -- edit scodev.lnk if that bothers you
#
sort -k 11,11 | awk '{if ($11==of) print "ln ", ol," ", $9 > "scodev.lnk"; \
                     else {of=$11; ol=$9; print $9}}' > /tmp/st$$
#
# tar, compress, remove temp files & quit
#
tar -cPLvfF - /tmp/st$$ | compress > scodev.tar.Z
rm /tmp/st$$
------------------------end cut----------------------------------------------

Of course, this is like killing mosquitos with a bazooka -- you'll be copying tons of things you won't actually use unless you plan to do serious Linux hosted SCO development. As a pointer, you can consider removing all the dialect directories under usr/include except for xpg4plus, all the X related libs/headers, or m4, make and the SCCS commands (in usr/ccs/bin).

Next, move the two files on a suitable directory on the Linux box (say /scodev), unzip/untar the archive (NB note that bin has a 2 uid on SCO and 1 on Linux), run the scodev.lnk script, create the following simlinks

ln -s /scodev/lib/libprot.so.1 /lib/libprot.so.1
ln -s /scodev/usr/lib/libc.so.1 /usr/lib/libc.so.1	#easy - that won't break gcc: only placing
ln -s /scodev/usr/lib/ld.so.1 /usr/lib/ld.so.1		#SCO stuff on top of iBCS replacements

and voila` you are ready to run the installation script! (note that the dynamic link loader distributed as part of the iBCS is perfectly capable of handling the Informix utilities, and 4gl apps linked with the -shared flag load and execute without problems; however for some obscure reason they core dump at the first DATABASE statement encountered)

C4gl

At this point i4gl, form4gl and the like are all happily working. To actually use c4gl, you'll need the following two steps

Esql/c

The procedure outlined above works with esql/c too, with a notable exception: esql/c 5.0x in which, for reasons beyond my understanding, the esql script makes no use of INFORMIXC. I find none of the following suggestions entirely satisfactory, however, consider

Dynamic 4gl

It is fairly simple to get also Dynamic 4gl to work, provided that you have either 4gl or esql/c. Proceed with a normal installation of the product (you will have to confirm to the installation script that you want to proceed even if it is not the correct platform), and skip the creation of the environment script - it will fail anyway).
Next, set an environmental variable FGLCC, exactly as INFORMIXC described earlier. As a last step, execute 

$ export PATH=`pwd`/bin:$PATH
$ CC=$FGLCC fndlib.sh

This will attempt to find the libraries that are needed to link the runner, and produce a shell script that sets the correct environment for Dynamic 4gl. Note however that the script produced will have an incorrect FGLCC, so be prepared to set this right manually.

Termcap & Terminfo

Both terminfo and termcap files are provided with the ncurses package, and both are supported by SCO ports of Informix products. While termcap needs some hacking (since, for instance, Informix uses kf & kg instead of kP & kN), terminfo files provided with the ncurses package (with the notable exception of the vt320 definitions) work pretty well with Informix products, and need only minor adjustments.
The enclosed termcap [ http://www.ctonline.it/~marcog/dnld/termcap ] can be safely installed under /etc (remember to back up the old one!). On the contrary you should compile terminfo definitions [ http://www.ctonline.it/~marcog/dnld/linux.ti ] (or store my terminfo files [ http://www.ctonline.it/~marcog/dnld/ti.tgz ]) in an appropriate directory, say /usr/informix/terminfo, as outlined in the sample installation procedure below

$ mkdir /usr/informix/terminfo
$ TERMINFO=/usr/informix/terminfo
$ export TERMINFO
$ tic linux.ti

Failing to correctly set the TERMINFO variable will clutter your standard terminfo files, so be careful!
As usual, you would access the newly created terminfo files by suitably setting the INFORMIXTERM variable as per 4gl Reference Manual, volume two, appendix I, and again, with TERMINFO pointing to the alternate terminfo definitions. The purist among you may want to have separate termcap definitions as well. For this, just install the alternate termcap somewhere and have the variable TERMCAP pointing to it.

Printing

The Printing-Howto goes in great length to explain the ladder effect, and how to effectively use a filter to prevent it, only to conclude that printing ascii text is not this hot thing, and that you should seek a magic filter that allows you to print PostScript, TeX, you name it files.

What they don't tell you is that no single LPR filter is included in the LPRng distribution, and that 4gl reports only produce plain ascii text (well, ok, if you haven't read the Informix Faq Appendix M [ http://www.iiug.org/techinfo/faq/ifaqm.htm#APPM ], but that's another story :-)

Here you have a few alternatives:

The last two options will let you control things like orientation, paper size, bin, etc.

Starting and stopping the engine automatically

Can be easily done by placing a small shell script, like the following, in the appropriate initialization scripts directory.

--------------------------------- cut here --------------------------------
#!/bin/sh
:	"@(#)/etc/rc.d/rc.informix	0.0"
#	rc.informix  -  Informix engine startup system initialization script
#
#	Author:	Marco Greco, <marcog@ctonline.it>, Catania, Italy
#
#	Initial release: Jun 97
#	Current release: Jul 97
#
#	Absolutely no warranty -- use at your own risk
 
export INFORMIXDIR=		#fill in your value here, maybe /usr/informix?
export INFORMIXSERVER=		#fill in your value here
export ONCONFIG=		#fill in your value here
 
if [ $# -lt 1 ]
then
    echo "Usage: $0 {start|stop}"
else
    case "$1" in
 
    'start')
	if [ `$INFORMIXDIR/bin/onstat 2>&- | grep -c initialized` -ne 0 ]
	then
	    echo -n "Starting Informix Online... "
	    $INFORMIXDIR/bin/oninit
	    echo "done"
	fi
	;;
 
    'stop')
	if [ `$INFORMIXDIR/bin/onstat 2>&- | grep -c initialized` -eq 0 ]
	then
	    echo -n "Shutting down Informix Online... "
	    $INFORMIXDIR/bin/onmode -ky
	    echo "done"
	fi
	;;
    *)
	echo "Usage: $0 {start|stop}"
	;;
    esac
fi
---------------------------------- end cut --------------------------------

[Note that this only applies to Online since there's nothing to start on SE unless you require network functionality, which is not available at the present time]

All of Red Hat, SuSE and Caldera have a System V approach to system initialization, thus you need to

Slackware uses the SysVinit package unmodified, which takes a BSD approach, thus you would place the above script as a replacement for /etc/rc.d/rc.local. Note that for some reason the plain SysVinit package does not offer a way to stop what has been started by /etc/rc.d/rc.local, so for our little scheme to work you need to

Copyright 1998