Besides the usual help and version options, the utility accepts two main arguments: an input file, and an optional INFORMIXDIR (if this is not already set). The input file has the following structure:
Most of these parameters should be self-explanatory to anyone who has set up IDS before.
The two directives are optional:
- “directive debug” displays useful extra information while the onconfig file is being generated
- “directive one_crit” forces all data and logs into a single root dbspace (generally not recommended!).
The disk entry also deserves some further explanation:
This entry should be the path, followed by the offset, then the size of the chunk; k, m or g can be specified to qualify the size.
*WARNING: the utility will overwrite the disk specified for this parameter as soon as it is run*.
Although it is undocumented, it is possible to enter multiple disk entries, and this makes sense to avoid the logical log warnings if only a single chunk is specified for the root dbspace. We could not, however, get the utility to use one of these disk entries for a temp dbspace; it seemed to complain there was no disk big enough for the temp space, regardless of the size specified.
Upon execution, the utility reports some useful data relating to storage and CPU speeds (if debug is set – this was a nice and unexpected feature). The utility initialises the storage for each disk entry, and generates an Informix configuration file named “onconfig” in the local directory.
Running the utility with various configurations appeared to give reasonable defaults for most of the onconfig parameters, bar a couple of oddities:
- As mentioned above, the program never appears to allocate a disk for a temp dbspace. This is significant as best practice is for multiple temp dbspaces to be created
- The utility assigns the full amount of memory specified in the input file to both the initial virtual segment and the buffers
Comparing the generated configuration with that of the installer (given the same input parameters as genoncfg) shows some interesting differences. Using the configuration above as an example:
- Setting the ‘disk’ parameter to 250MB, genoncfg assigns exactly this amount to the rootdbs, whereas the installer allocates it 300MB (an additional 50MB)
- The physical log sizes differ wildly. The installer created a physical log around 180MB – three times the size of the one created by genoncfg.
- genoncfg created twice as many logical logs, at twice the size
- genoncfg created 150 TCP poll threads, whereas the installer created 50 shared memory threads
- genoncfg set MULTIPROCESSOR to 0 compared to the installer’s 1
- genoncfg set a 16MB VP_MEMORY_CACHE_KB, whereas the installer set this to 0
- The installer set DIRECT_IO on, despite this being restricted in Innovator-C, whereas genoncfg left this off
- genoncfg set SHMVIRTSIZE to 1024000 (the full amount of memory supplied) with SHMADD at 32000, the installer set these to 101376 / 3165 respectively
- The installer set the buffer pool to 500MB with auto tuning, whereas genoncfg allocates almost all the 1GB given, and set specific LRUs and thresholds
- Installer sets AUTO_TUNE_SERVER_SIZE (genoncfg does not create an entry)
There were many other differences too, with backup devices and PDQ settings differing amongst others. The installer does give a couple of additional options, such as OLTP/DSS and transaction support, but changing these did not bring the parameters into line with those as generated by genoncfg.