IDS Forum

Re: onmode bug discovered (-wf)

Posted By: Jonathan Leffler
Date: Thursday, 26 April 2018, at 9:33 a.m.

In Response To: onmode bug discovered (-wf) (MICHAEL HOFFMAN)

Michael: your message probably will get posted to the IDS mailing list, but
will then have a different number in the subject line. (Message 41059 was
posted; it was sent from a different email account (offdisc.com) than the
one I'm replying to here (panix.com) — both bcc'd.)

*This is not an official IBM or HCL statement about this issue. It is my
personal opinion backed up by limited and incomplete testing. It is a
moderately long message; it should be longer and with more testing.*

There's no doubt that oninit pays attention to the value in the ONCONFIG
environment variable when it starts up — both when the server is
initialized and when it is brought up subsequently.
That value does not, however, change while oninit is running; it continues
to use the same name for the ONCONFIG file until it stops.
When it starts again, it uses the prevailing value of ONCONFIG, but keeps
using that until it is stopped.
That much is, I think, non-controversial and not a bug.

The ON-Tape command does use the value of ONCONFIG to determine which
server to connect to.
If you unset ONCONFIG, it uses the default value (onconfig), and if that
file doesn't exist, fails.
The expectation is that you will use the same file as you used to start
oninit, so that you know you are talking to the same server.
If you don't use the same file, you may or may not get the result you
expect.

Further, the system archive option ('ontape -s -L 0', for example), will
use the value of TAPEDEV from the ONCONFIG file specified when the command
is run.
However, it also supports the '-t device' option to allow you to specify
the device to be used (e.g. 'ontape -s -L 0 -t $INFORMIXDIR/backup') —
which is the way you're intended to change the backup device.

In contrast, the logical log backup ('ontape -a -d') uses the value of
LTAPEDEV from shared memory, not from the ONCONFIG file.
And there isn't a documented option to change the logical log backup device
on the fly according to the usage message:

ontape

usage:

{ -a [-d] |

-c |

-l [-C | -X] [-d] |

-p [-e|-encrypt|-decrypt] [-rename {-f <filename> |

-p <old path> -o <old offset> -n <new path> -o <new
offset>...}]

[-t tape_device_path [-v]] [-d] |

-S [-d] |

-r [-encrypt|-decrypt] [-rename {-f <filename> |

-p <old path> -o <old offset> -n <new path> -o <new
offset>...}]

[-D DBspace_list] [-t tape_device_path [-v]] [-d] |

-s [[-L archive_level][-F]] [-A database_list] [-B database_list]

[-N database_list] [-U database_list] [-t tape_device_path [-v]] [-d]
}

However, empirical evidence shows that the '-t device' option does work:

ontape -a -d -t $INFORMIXDIR/backup

Performing automatic backup of logical logs.

File created:
/view/ids1210.jleffler.toru/vobs/tristarm/sqldist/backup/toru_11_Log0000000006

Do you want to back up the current logical log? (y/n) n

Program over.

BUG: The ontape usage message is incomplete — '-a' accepts '-t'.
BUG: The spiel for TAPEDEV and LTAPEDEV on onconfig.std is incomplete.
BUG: The ontape usage message is incomplete — '-c' accepts '-t'.

Having brought up my server, toru_11, with ONCONFIG file onconfig.toru_11
(which had TAPEDEV and LTAPEDEV set to /dev/null because it's a test server
with no valuable data in it), I took it down. I then restarted it with a
different ONCONFIG file onconfig.toru_11.logfile (which had TAPEDEV and
LTAPEDEV set to $INFORMIXDIR/backup, a directory). However, there was no
report in the online log file of the tape device parameters changing,
though the log file did state the new file name (it was a server built in
TESTMODE; that may or not be available in a production mode server). When
I ran an archive ('ontape -s -L 0') with the original ONCONFIG file, the
archive was done to /dev/null, notwithstanding what the ONCONFIG file
said. Checking with 'onstat -c | grep TAPEDEV' confirmed that the
parameters were still set to /dev/null. This is curious; it seems to mean
that many of the parameters are cached when the server is built (in the
reserved pages of chunk 0 or the root dbspace). *[More testing needed
here. It is complicated because (I believe) the server also reads
onconfig.std to collect 'default' values for parameters not set in the
ONCONFIG file.]*

At some point, I need to find out which of the ONCONFIG parameters are read
and used from the file when a server is restarted (as opposed to
initialized, when the whole file is used).

Ideally, I need to re-review and re-reproduce the results to make sure I'm
not accidentally misleading myself and thereby unintentionally misleading
you.

I am not happy about the asymmetry in the way ON-Tape seems to read TAPEDEV
from the file specified by ONCONFIG when it is run, but seems to ignore
LTAPEDEV from the same source. I can see accepting both or ignoring both
making sense; accepting one and ignoring the other seems inconsistent.
OTOH, since the '-t name' option works for archives and log backups, there
really isn't that much to use the ONCONFIG file except to identify which
server to connect to.

There's missing discussion about ON-Mode here. However, as I mentioned in
my first response to this subject, the ON-Mode command does not itself
write the ONCONFIG file when given the '-wf' option. The server does
that. And, as I said at the outset, the server doesn't change its opinion
of which file is the ONCONFIG file while it is running.

Since I started writing this, I've seen a couple of other responses more or
less agreeing that what you're trying to do is not what's intended.

On Wed, Apr 25, 2018 at 3:50 PM, Mike Hoffman <mrh@panix.com> wrote:

> (Let's see if this actually gets posted to the forum)
>
> Hmmm.... if 'oninit' can read the environment setting of ONCONFIG and not
> use the default file "onconfig" in $INFORMIXDIR/etc, then why wouldn't it
> be considered a bug that all commands don't allow for the environment
> variables to overwrite what is in the server's memory?
> There is absolutely no note that I can find saying "ONCONFIG environment
> setting will be read by some commands, but not all".
>
> For example: 'ontape' and "oninit" will read the enviroment setting
> ONCONFIG over the one in system memory. Isn't lack of consistency
> considered a bug of some sort?
>
> Thanks,
> Michael
>
>
> ---------
> "Shared Pain is lessened, Shared Joy is increased" --- Spider Robinson
> “Life is short. break the rules, forgive quickly, kiss slowly, love truly,
> laugh uncontrollably,
> and never regret anything that made you smile” ― Mae West
>
>
> On Wed, Apr 25, 2018 at 2:19 AM, Jonathan Leffler <
> jonathan.leffler@gmail.com> wrote:
>
>> Interesting, but I'm not convinced it is a bug.
>>
>> I'm assuming you use something like the following two commands and you
>> are claiming that there is a bug because it is onconfig.serv-disk that
>> is modified and not onconfig.dev-null.
>>
>> ONCONFIG=onconfig.serv-disk oninit # To bring the server up
>>
>> ONCONFIG=onconfig.dev-null onmode -wf LTAPEDEV=/some/where
>>
>> The 'onmode -wf' command asks the server to write to its ONCONFIG file,
>> the one it knows about, the one it used when it started. That's the file
>> it will write to; that is its onconfig file. The fact that you sometimes
>> get away with using alternative names is useful for you, but not
>> necessarily supported (I reserve judgement on that). However, the file
>> writing is only going to write to the ONCONFIG file name used by oninit
>> when it was started. What isn't obvious is that ON-Mode prods the server
>> into doing the writing, rather than doing the writing itself, but that's
>> why the server writes to its own ONCONFIG file, and not whatever is
>> specified to ON-Mode.
>>
>>
>> On Tue, Apr 24, 2018 at 2:15 PM, MICHAEL HOFFMAN <offdisc@gmail.com>
>> wrote:
>>
>>> Hi All,
>>> ran across an interesting little bug today:
>>> we have several onconfig files for an instance, each with different
>>> TAPEDEV
>>> and LTAPEDEV settings, used for ontape backups and restores.
>>> For example:
>>> onconfig.serv-null has TAPEDEV set to /dev/null so we can run on-the-fly
>>> 'ontape -s -L 0' without actually creating a new archive. (useful for
>>> when
>>> moving or dropping dbspaces and chunks).
>>> onconfig.serv-disk has TAPEDEV and LTAPEDEV pointing to speficic
>>> files/directories for backups to disk.
>>> onconfig.serv-tape has TAPEDEV and LTAPEDEV pointing to specific tape
>>> drives.
>>>
>>> We switch between these onconfigs using 'export ONCONFIG='.
>>>
>>> Well, I am performing proof of concept testing to move all of our
>>> logging
>>> (archives and logical logs) off of tape, onto disk.
>>> As part of the POC, I need to show how Level 0,1, and 2 archives differ.
>>>
>>> I did my 'export ONCONFIG=onconfig.serv-disk' and created a Level 0
>>> archive.
>>> Messed around with some dbspaces and tables, and now want to run a Level
>>> 1.
>>>
>>> So I run 'onmode -wf TAPEDEV=/diska/serv_lvl1.backup' and all looks
>>> good...
>>> until I run the backup and the "tape device" shown is the original
>>> filename in
>>> the onconfig.serv-disk file.
>>>
>>> The onmode updated the onconfig file that was used at the time of the
>>> instance
>>> startup!!!!
>>>
>>> Has anyone else run into this? It's not am urgent bug, but it should be
>>> reported. If Informix provides us the ability to use environment
>>> variables,
>>> then they should be consistent in how those are used by the engine.
>>>
>>> What is the best way to report this "non-urgent, non-system-down" error
>>> to
>>> IBM/HCL?
>>>
>>> Thanks,
>>> Michael
>>>
>>>
>>> *******************************************************************************
>>>
>>> Forum Note: Use "Reply" to post a response in the discussion forum.
>>>
>>>
>>
>>
>> --
>> Jonathan Leffler <jonathan.leffler@gmail.com> #include <disclaimer.h>
>> Guardian of DBD::Informix - v2015.1101 - http://dbi.perl.org
>> "Blessed are we who can laugh at ourselves, for we shall never cease to
>> be amused."
>>
>
>

--
Jonathan Leffler <jonathan.leffler@gmail.com> #include <disclaimer.h>
Guardian of DBD::Informix - v2015.1101 - http://dbi.perl.org
"Blessed are we who can laugh at ourselves, for we shall never cease to be
amused."

Messages In This Thread

• onmode bug discovered (-wf)
  MICHAEL HOFFMAN -- Tuesday, 24 April 2018, at 5:15 p.m.
  • Re: onmode bug discovered (-wf)
    Jonathan Leffler -- Wednesday, 25 April 2018, at 4:19 a.m.
    • Re: onmode bug discovered (-wf)
      MICHAEL HOFFMAN -- Wednesday, 25 April 2018, at 6:52 p.m.
      • Re: onmode bug discovered (-wf)
        Fernando Nunes -- Wednesday, 25 April 2018, at 7:48 p.m.
  • Re: onmode bug discovered (-wf)
    TANJA M�LLER -- Wednesday, 25 April 2018, at 5:59 a.m.
  • Re: onmode bug discovered (-wf)
    Jonathan Leffler -- Thursday, 26 April 2018, at 9:33 a.m.
    • Re: onmode bug discovered (-wf)
      david@smooth1.co.uk -- Thursday, 26 April 2018, at 9:53 a.m.
      • Re: onmode bug discovered (-wf)
        Fernando Nunes -- Thursday, 26 April 2018, at 10:09 a.m.
        • Fwd: onmode bug discovered (-wf)
          Jonathan Leffler -- Thursday, 26 April 2018, at 10:44 a.m.
  • Re: onmode bug discovered (-wf)
    Mike Hoffman -- Thursday, 26 April 2018, at 11:23 a.m.

IDS Forum is maintained by Administrator with WebBBS 5.12.