onmode bug discovered (-wf)
A user keeps several ONCONFIG files (different TAPEDEV/LTAPEDEV) and switches with 'export ONCONFIG='. After starting the server with one file, running 'onmode -wf TAPEDEV=...' under a different ONCONFIG updated the file used at startup, not the one in the current environment. Respondents (Leffler, Nunes, Müller) explained this isn't a bug: onmode just asks the running engine to write, and the engine only knows the ONCONFIG it was started with, while utilities like ontape read the file from their own environment. Advice: use ontape's '-t device' option (or edit the file) instead of swapping ONCONFIG; the inconsistency and missing documentation were acknowledged, with a PMR/doc change suggested but no fix recorded.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
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
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."
Don't believe in a bug here. When starting the server he knows about the onconfig-file from the environment variable ONCONFIG. If you change this variable when the server is running it will not know the new value. Assuming that variable is only read once during the startup of the server.
[Tried to respond via email... forum still doesn't post my responses. :-( ]
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
Let me start by being clear, that this is not an official IBM answer. If
you want to pursue this you should open a PMR.
from my point of view this is not a bug... at least not the one you're
considering. From my point of view, if there is a bug, that would be in
ontape...
I believe you've found an oddity, which is the fact that you've found one
situation/command that accesses the $ONCONFIG directly (ontape and oncheck
do, onmode and onstat apparently do it for some operarations, but I didn't
do extensive tests).
To me, this behavior is not correct, although I suppose it has always been
like that, and there are probably good reasons to do so.
When you execute "onmode -wf", it's not "onmode" that is changing the file.
Actually if you define ONCONFIG to a non existent file it will warn you,
but then proceeds to "ask" oninit (the engine) to do the change.
And naturally, oninit will use the file that was in it's environment.
Ideally I think all the utilities would "ask" the engine what was the
$ONCONFIG at startup time. But they don't.... I believe this was done for
simplicity, and because in some circumstances these utilities must work
when the engine is not online. I understand the discomfort this may cause
and it looks like an inconsistent behavior...
I wouldn't expect IBM/HCL to consider any of these (either what you're
saying, nor what I'm saying) as a bug, because:
- Probably (didn't look) the documentation is not clear either way
- It has been like this "forever" (didn't test naturally)
- The potential impacts of changing this could be serious
The point against your argument is that (probably) nowhere in the
documentation we state that you're advised to do what you're doing... and
only some options/commands will try to read the file specified in the
$ONCONFIG variable...
But, returning to the beginning, you're free to open a PMR and expose the
issue. I've had worse situations where I couldn't convince anyone that I
had found a bug.... and in this particular case I think DEV could better
use their time :)
But if you pay support, you're entitled to try it...
Regards.
On Wed, Apr 25, 2018 at 11:52 PM, MICHAEL HOFFMAN <offdisc@gmail.com> wrote:
> [Tried to respond via email... forum still doesn't post my responses. :-(
> ]
>
> 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
>
>
>
*******************************************************************************
>
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--
Fernando Nunes
Portugal
http://informix-technology.blogspot.com
My email works... but I don't check it frequently...
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 t
Hhi Jonathan,
The big question is if ontape always uses the ONCONFIG value from it's
environment, should onmode also use the value from it's environment?
The documentation for onmode does not say which ONCONFIG value is used when
dynamically changing values -
https://www.ibm.com/support/knowledgecenter/en/SSGU8G_12.1.0/com.ibm.adref.doc/i
ds_adr_0439.htm
The on* commands are known to use the ONCONFIG value from their environment,
if the onmode command is having the engine rewrite the onconfig file then this
breaks the expection above and should be clearly documented.
Can we get a documentation change put through for this?
Regards,
David.
> On 26 April 2018 at 14:33 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 @@D
I already addressed some points in my previous email... not sure if it got
through to the list.
The main problem here is that after decades, we're discussing, advocating
that it makes sense to change the $ONCONFIG value during the execution of
the engine. In other words, that it makes sense to change the variable
value before executing a specific utility/option. From my point of view, it
doesn't. And the documentation never stated it does. It probably also
doesn't state it can't be done.
It really makes no sense (to me) doing it.
The situation described doesn't need it... we can simply change the
value(s) before running the utility. That's roughly the same work (1
command) as doing the export of a variable :)
Regards.
On Thu, Apr 26, 2018 at 2:53 PM, david@smooth1.co.uk <david@smooth1.co.uk>
wrote:
> Hhi Jonathan,
>
> The big question is if ontape always uses the ONCONFIG value from it's
> environment, should onmode also use the value from it's environment?
>
> The documentation for onmode does not say which ONCONFIG value is used
> when
> dynamically changing values -
> https://www.ibm.com/support/knowledgecenter/en/SSGU8G_12.
> 1.0/com.ibm.adref.doc/ids_adr_0439.htm
>
> The on* commands are known to use the ONCONFIG value from their
> environment,
> if the onmode command is having the engine rewrite the onconfig file then
> this
> breaks the expection above and should be clearly documented.
>
> Can we get a documentation change put through for this?
>
> Regards,
> David.
>
> > On 26 April 2018 at 14:33 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@@NL
I agree with Fernando.
Fundamentally, I am reasonably confident that using multiple ONCONFIG files
with a single server is not officially supported. There is intended to be
a single ONCONFIG file that is used by all the (administrative) programs
accessing that server. (Regular ESQL/C, JDBC, ODBC clients do not use
ONCONFIG, of course.)
Because the ON-* utilities are run separately from ON-Init, there is the
opportunity to use different ONCONFIG files with different commands at
different times. Indeed, because you can have multiple server instances
running out of a single INFORMIXDIR, it is crucial that the utilities use
ONCONFIG to select which server is being administered at the moment.
However, each server instance has a single ONCONFIG file that *should* be
used â the file that is being used by the ON-Init that is running that
instance. Further, while the server is running, it is not a particularly
good idea to edit the file other than by using the ON-Mode command to
trigger the modifications.
Since ON-Tape takes command line arguments to allow you to change the
backup strategy (and it is assumed that you know what you're doing when you
do that â you are most certainly given enough opportunity to cause mischief
if you are careless), there is no real need for the strategy outlined in
the original message in this chain [41059] to make backups to different
devices by switching between ONCONFIG files.
So, I think it unlikely (very unlikely) that using multiple ONCONFIG files
with a single instance of Informix is supported. To some extent, it will
probably work, most of the time, more or less as expected. But it is not
the intended mode of operation. There is supposed to be one ONCONFIG file
used per instance. Consequently, when you run into eccentric behaviour
while using multiple ONCONFIG files for a single server, I would argue that
there isn't a bug unless you can reproduce the same problem using just a
single ONCONFIG file.
Michael Hoffman, the OP in this thread, is at liberty to create a PMR;
others could do so too. Such PMRs will be considered on their merits. But
the existing behaviour has worked reasonably well for most of 30 years â
there will be some resistance to making fundamental changes.
As before, this is my opinion â I'm not writing as the official spokesman
for IBM or HCL.
Yours,
Jonathan
On Thu, Apr 26, 2018 at 7:12 AM Fernando Nunes <domusonline@gmail.com>
wrote:
> I already addressed some points in my previous email... not sure if it got
> through to the list.
> The main problem here is that after decades, we're discussing, advocating
> that it makes sense to change the $ONCONFIG value during the execution of
> the engine. In other words, that it makes sense to change the variable
> value before executing a specific utility/option. From my point of view,
> it
> doesn't. And the documentation never stated it does. It probably also
> doesn't state it can't be done.
>
> It really makes no sense (to me) doing it.
> The situation described doesn't need it... we can simply change the
> value(s) before running the utility. That's roughly the same work (1
> command) as doing the export of a variable :)
>
> Regards.
>
> On Thu, Apr 26, 2018 at 2:53 PM, david@smooth1.co.uk <david@smooth1.co.uk>
>
> wrote:
>
> > Hhi Jonathan,
> >
> > The big question is if ontape always uses the ONCONFIG value from it's
> > environment, should onmode also use the value from it's environment?
> >
> > The documentation for onmode does not say which ONCONFIG value is used
> > when
> > dynamically changing values -
> > https://www.ibm.com/support/knowledgecenter/en/SSGU8G_12.
> > 1.0/com.ibm.adref.doc/ids_adr_0439.htm
> >
> > The on* commands are known to use the ONCONFIG value from their
> > environment,
> > if the onmode command is having the engine rewrite the onconfig file
> then
> > this
> > breaks the expection above and should be clearly documented.
> >
> > Can we get a documentation change put through for this?
> >
> > Regards,
> > David.
> >
> > > On 26 April 2018 at 14:33 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]
> > >@@NL@
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: 'o