IDS Forum

Re: onmode bug discovered (-wf)

Posted By: Mike Hoffman
Date: Thursday, 26 April 2018, at 11:23 a.m.

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

Thanks for this discussion everyone.
Some interesting points were brought up, about accepted practices and about
what constitutes a bug. :-)

To be clear, the practice of flipping between onconfig files dates back to,
hmm, at least early version 9. It is something I picked up from either Jake
Solomon or, possibly, Art at an Informix DBA class.

I suppose it is time to update my practices to the current times. ;-)

Thanks for helping shed more light on the situation!
Michael

---------
"Sit Long, Talk Much, Laugh Often" -- anon
"Shared Pain is lessened, Shared Joy is increased" --- Spider Robinson

On Thu, Apr 26, 2018 at 7:32 AM, Jonathan Leffler <
jonathan.leffler@gmail.com> wrote:

> 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.