Informix: oncheck -pr in Fast Recovery mode

Here's a cute situation, as in "What a cute little centipede!" In HA replication, the target/replicate server is always running in Fast Recovery mode. On one such server in my environment, I tried to run "oncheck -pr". It gave me the message: $ oncheck -pr Validating IBM Informix Dynamic Server reserved pages IBM Informix Dynamic Server must be OFFLINE or in QUIESCENT mode. Of course, it runs just fine in OnLine mode so the error message is inherently misleading. Let's just chalk that up to an IBMism. But to refuse to run in fast-recovery mode? That's kinda ridiculous, IMHO. Why should that be a problem? It's the same reserved pages as if it were off line. Just asking. Because it messes up a utility that depends on that command internally to build a list. Can anyone explain this rationale? Thanks. ------------------------------ +-----------------------------------------------------------+ | I am pleased to report that I had no problems today. | | I had only issues, opportunities, challenges and valuable | | learning experiences. | +------------------------------------------ Jacob S --------+ ------------------------------

Not seeing this behavior with my secondaries nor in the code. The error is expected if neither in quiescent nor in online mode nor in recovery mode on a secondary, so it should work in your scenario. Can we learn server (and oncheck) version? ------------------------------ Andreas Legner Informix Dev HCL Software ------------------------------

I think I'll open a case with HCL instead. I'll post interesting results when I have'em. ------------------------------ +-----------------------------------------------------------+ | I am pleased to report that I had no problems today. | | I had only issues, opportunities, challenges and valuable | | learning experiences. | +------------------------------------------ Jacob S --------+ ------------------------------

Actually, folks, I was wrong about the HA situation. It had been refreshing from an archive, which also displays "Fast Recovery" mode. Hence my error. The recovery failed, leaving the server in that fake Fast Recovery state. I have opened a ticket with HCVL over the grossly misleading error message. (What I had referred to as an IBMism.) Not the grand-slam solution I was hoping for but no need for the wild goose chase either. ------------------------------ +-----------------------------------------------------------+ | I am pleased to report that I had no problems today. | | I had only issues, opportunities, challenges and valuable | | learning experiences. | +------------------------------------------ Jacob S --------+ ------------------------------

Note that you can force oncheck -p[rR] to work regardless of server state by setting your INFORMIXSERVER environment variable to something random like "blah". Setting it to a name, but not to an existing server name, will result in a fast response and a display of whatever is on disk at that time. ------------------------------ John Lengyel ------------------------------

Now that is a neat trick On 10/7/2026 7:44 AM, John Lengyel via IBM Community wrote: Note that you can force oncheck -p[rR] to work regardless of server state by setting your INFORMIXSERVER environment variable to something random... -posted to the "Informix" group

Whoa, that is something. So you are telling us, the ONCONFIG is the only criteria when INFORMIXSERVER is unknown ? Or how would I address several instances on the same machine ? Best, Marcus Haarmann

Correct. Make sure ONCONFIG is set to your target instance and oncheck will know where to find the root chunk. So you need: INFORMIXDIR PATH ONCONFIG INFORMIXSERVER=blah No waiting for a timeout before it displays what's on disk. ------------------------------ John Lengyel ------------------------------

Glad to know that it works for you in HA, but for those of us using Continuous Log Restore (CLR), oncheck -pr does generate the error message that you mentioned. I was, however, able to use JC's trick of setting INFORMIXSERVER to a value different from any instance in the sqlhosts file. ------------------------------ mark collins ------------------------------

John, This is a GREAT bug!~ I hope they never fix it! Of course I tried it as soon as I saw your post. Sadly, for my situation, it does not quite help. Some years ago I posted my utility dup-spaces.pl on the IIUG repository. It invokes onmode -pr in one step as well as several onstat commands. Those will not work, generating the reasonable message: Shared memory not initialized for server 'blah'. Trying to run dup-spaces.pl is how I discovered the [mis]behavior of oncheck -pr. HMM... For the purpose of the subroutine that invokes the oncheck command, I could temporarily change $ENV{INFORMIXSERVER} ie change the program's environment variable to "blah", run the oncheck command, then change it back. (That's why I like to code in Perl.) I see multiple people thanking you for posting this. I endorse that gratitude! ------------------------------ +-----------------------------------------------------------+ | I am pleased to report that I had no problems today. | | I had only issues, opportunities, challenges and valuable | | learning experiences. | +------------------------------------------ Jacob S --------+ ------------------------------

Jacob et al: For those who are not aware, you can use my myschema utility to get a script to duplicate the storage architecture of a server with: myschema --infrastructure=cmd -- or -- myschema --infrastructure=sql The first way prints out a shell script that (mostly) uses onspaces and onparams to duplicate all of the storage and logs from the source server (it does generate some SQL API calls to mark extendable chunks as there is no other way). The second uses mostly SQL API calls to do the same (again with some utility calls to create any temp sbspaces). The scripts even include a line to create the rootdb's initial chunk, though it is obviously commented out since the engine would need to be online to run the script at all. Art ------------------------------ Art S. Kagel, President and Principal Consultant ASK Database Management Corp. www.askdbmgt.com ------------------------------