Informix Ibcs Howto
Marco Greco, v1.0g,
8 December 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 excellent
InxUtil 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).
Credits
Mike Jagdis 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.
Disclaimers
I'll keep it short: don't let the fact that I am currently employed by
Informix UK trick you into believing that the contents of this document are in
any way endorsed or supported by Informix. Should anything go wrong, don't
call tech support, and don't blame the company, or me, for that
matter: I reserve the right to be wrong.
Also, feel free to use this material in whichever way you want, however, nobody
likes a plagiarist, so quote your source, or don't use it at all.
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.
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
- you most likely need to change
SMP since this is turned
on by default. a binary compiled with SMP enabled will not work against a
single processor machine and viceversa.
USE_VERSIONS: if you don't wish to recompile the iBCS module
whenever you change minor kernel release, set this, and remember to set
CONFIG_MODVERSIONS in /usr/src/linux/.config- unless you want to enable xenix emulation, or disable other personalities,
no other change is needed.
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
- using
CC rather than INFORMIXC
- writing an
esql wrapper
- changing
esql to take in account INFORMIXC (the
changes are trivial)
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
can be safely installed under /etc (remember to back up the old
one!). On the contrary you should compile
terminfo definitions
(or store my terminfo
files) 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, but that's another story :-)
Here you have a few alternatives:
- report to pipe, and pass the report output through
pr(1) before
sending it to the printer spooler
- write a small filter yourself - perl or awk will do - and have the
if paramenter of the appropriate entry in /etc/printcap
point to it
- if you have a PCL printer, you can get the CTI hp drivers from the
LPRng home, or use my own
little filter
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
- copy the above script to
/etc/rc.d/init.d
- link it to a start and a stop file in each of the
rc?.d
directory appropriate for the run level for wich you wish the engine to be
started, eg
$ ln -s /etc/rc.d/init.d/rc.informix /etc/rc.d/rc3.d/S99informix
$ ln -s /etc/rc.d/init.d/rc.informix /etc/rc.d/rc3.d/K01informix
for run level 3 (normally, multiuser with X functionality)
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
Back to Top
Back to Technical Information:
Deploying Informix's Products on Linux
