ontape to disk

Good morning IDS folks! Sorry for the long post, but I have been wrestling with an ontape script for some time now and seem to have hit a brick wall. We currently have 156 instances on 78 servers. We have IDS 7.31 and 9.40 of various levels running on Sun, HP, and AIX. We have successfully used BMC's SQL-BackTrack as our storage manager with onbar for many years. My company decided they no longer want to pay for the BMC license so I need another method for performing database backups. I looked at ISM but it has too many limitations. Some of our instances are over 1 TB and we have many large chunks. I would love to be able to upgrade to 11.5, but again, the company does not want to spend any resources to upgrade. Their stated goal is to quit using Informix. Although that has been a goal for over ten years, we haven't gotten rid of one app yet. However, that means they won't spend anything to upgrade. By the way, my company is getting rid of SQL-BackTrack for Oracle as well, but rman seems to fill the void fairly well. I feel that my solution is to use ontape to disk. I searched the IIUG repository and Google and the best I could find was a little script named auto_ontape.ksh, written by Peter Tashkoff in 1998. Because the script was originally written for a tape jukebox, I had to make a few modifications, but it has turned out to be very useful. This script watches the output from ontape and when it sees the prompt to "Please mount tape " it jiggers the link specified in TAPEDEV and issues an echo to serve as the "return". Here is what that script looks like: ---------------------------------------------------------------------- echo sleep 20 echo "\\ The first file in the series is ${ARCH_FILE}" >> $OUTFILE while [ `onstat -g ath | grep arcbackup | wc -l` -gt 0 ] do sleep 10 if [ `tail -1 $OUTFILE | awk '{print $2}'` = "mount" ] then let INCRMNT=INCRMNT+1 ARCH_FILE=${BACKUP_DIR}/${INFORMIXSERVER}_${TIMESTAMP}-${INCRMNT}.Level_${LVL} touch $ARCH_FILE chmod 777 $ARCH_FILE rm -f ${BASE_DIR}/${INST}/links/tape/tapedev ln -s ${ARCH_FILE} ${BASE_DIR}/${INST}/links/tape/tapedev echo echo "\\ New file is ${ARCH_FILE}" >> $OUTFILE fi done echo "\\ The last file in the series is ${ARCH_FILE}" >> $OUTFILE ---------------------------------------------------------------------- Most of the environment variables, including the first ARCH_FILE, are set in the calling script. auto_ontape.ksh is called by: auto_ontape.ksh | ontape -s -L $LVL >> $OUTFILE 2>> $OUTFILE The calling script does some instance checking before calling auto_ontape.ksh and it performs some expiration functions afterwards. This works most of the time. It appears to always work for our 9.40 instances because I set TAPESIZE to 0 and we don't have to worry about multiple backup files. The problem I have is that on the 7.31 instances on which I am testing, the output file gets so many "Please mount tape " messages so quickly that the output file fills the filesystem holding our message files (different from the filesystem holding the backup files). So far, it seems to only do this on Saturday nights. There are no informix cron jobs that are different on Saturday than any other night. I am also investigating if the tape ops folks are backing up the server at that time, but thus far I have not found any reason for this to happen. I found a reference to this same issue in my Google searches, but I cannot find any reason for it or how to avoid it. I also read that the 2 GB file limit went away in 7.2, but that does not seem to be the case. (I believe it finally went away in 9.x.) Does anyone have any idea what causes this behavior? Alternatively, does anyone know of a different script that could avoid this problem? Any help would be greatly appreciated. Thanks Rob Schmitz Embarq Data Management rob.b.schmitz@embarq.com www.embarq.com

The 2GB limit went away in 9.40, not in 7.3x, you are correct. Tell you company that right now they can upgrade from 7.31 and/or 9.40 to 11.50.latest for just the cost of a support renewal. Considering that 9.40 went out of support in April and 7.31 goes out of support in September, I'd say that's a good deal. As to why the archive is taking more output files on Saturday than other days, no clue. Art Art S. Kagel Oninit (www.oninit.com) IIUG Board of Directors (art@iiug.org) Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Oninit, the IIUG, nor any other organization with which I am associated either explicitly or implicitly. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Thu, Jul 9, 2009 at 11:20 AM, Schmitz, Rob B[EQ] < Rob.B.Schmitz@embarq.com> wrote: > Good morning IDS folks! > > Sorry for the long post, but I have been wrestling with an ontape script > for > some time now and seem to have hit a brick wall. We currently have 156 > instances on 78 servers. We have IDS 7.31 and 9.40 of various levels > running > on Sun, HP, and AIX. We have successfully used BMC's SQL-BackTrack as our > storage manager with onbar for many years. My company decided they no > longer > want to pay for the BMC license so I need another method for performing > database backups. I looked at ISM but it has too many limitations. Some of > our > instances are over 1 TB and we have many large chunks. > > I would love to be able to upgrade to 11.5, but again, the company does not > want to spend any resources to upgrade. Their stated goal is to quit using > Informix. Although that has been a goal for over ten years, we haven't > gotten > rid of one app yet. However, that means they won't spend anything to > upgrade. > By the way, my company is getting rid of SQL-BackTrack for Oracle as well, > but > rman seems to fill the void fairly well. > > I feel that my solution is to use ontape to disk. I searched the IIUG > repository and Google and the best I could find was a little script named > auto_ontape.ksh, written by Peter Tashkoff in 1998. Because the script was > originally written for a tape jukebox, I had to make a few modifications, > but > it has turned out to be very useful. This script watches the output from > ontape and when it sees the prompt to "Please mount tape " it jiggers the > link > specified in TAPEDEV and issues an echo to serve as the "return". Here is > what > that script looks like: > > ---------------------------------------------------------------------- > echo > > sleep 20 > > echo "\\ The first file in the series is ${ARCH_FILE}" >> $OUTFILE > > while [ `onstat -g ath | grep arcbackup | wc -l` -gt 0 ] > do > > sleep 10 > > if [ `tail -1 $OUTFILE | awk '{print $2}'` = "mount" ] > > then > > let INCRMNT=INCRMNT+1 > > > ARCH_FILE=${BACKUP_DIR}/${INFORMIXSERVER}_${TIMESTAMP}-${INCRMNT}.Level_${LVL} > > touch $ARCH_FILE > > chmod 777 $ARCH_FILE > > rm -f ${BASE_DIR}/${INST}/links/tape/tapedev > > ln -s ${ARCH_FILE} ${BASE_DIR}/${INST}/links/tape/tapedev > > echo > > echo "\\ New file is ${ARCH_FILE}" >> $OUTFILE > > fi > done > > echo "\\ The last file in the series is ${ARCH_FILE}" >> $OUTFILE > ---------------------------------------------------------------------- > > Most of the environment variables, including the first ARCH_FILE, are set > in > the calling script. auto_ontape.ksh is called by: > > auto_ontape.ksh | ontape -s -L $LVL >> $OUTFILE 2>> $OUTFILE > > The calling script does some instance checking before calling > auto_ontape.ksh > and it performs some expiration functions afterwards. > > This works most of the time. It appears to always work for our 9.40 > instances > because I set TAPESIZE to 0 and we don't have to worry about multiple > backup > files. The problem I have is that on the 7.31 instances on which I am > testing, > the output file gets so many "Please mount tape " messages so quickly that > the > output file fills the filesystem holding our message files (different from > the > filesystem holding the backup files). So far, it seems to only do this on > Saturday nights. There are no informix cron jobs that are different on > Saturday than any other night. I am also investigating if the tape ops > folks > are backing up the server at that time, but thus far I have not found any > reason for this to happen. > > I found a reference to this same issue in my Google searches, but I cannot > find any reason for it or how to avoid it. I also read that the 2 GB file > limit went away in 7.2, but that does not seem to be the case. (I believe > it > finally went away in 9.x.) > > Does anyone have any idea what causes this behavior? Alternatively, does > anyone know of a different script that could avoid this problem? > > Any help would be greatly appreciated. > > Thanks > > Rob Schmitz > Embarq Data Management > rob.b.schmitz@embarq.com > www.embarq.com > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --001636c5b526e4aeba046e484ee2

Thanks as always Art. Technically, we can upgrade. We've kept our maintenance up to date and we are currently paying for extended support for 9.40 (and we will also pay for it for 7.31 come September). Our issue has been in getting the applications to fund their effort to support the upgrade. We've just been purchased by another company, so that throws all sorts of tech buying decisions into a tizzy. Rob Schmitz Embarq Data Management rob.b.schmitz@embarq.com www.embarq.com -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Art Kagel Sent: Thursday, July 09, 2009 11:26 AM To: ids@iiug.org Subject: Re: ontape to disk [16295] The 2GB limit went away in 9.40, not in 7.3x, you are correct. Tell you company that right now they can upgrade from 7.31 and/or 9.40 to 11.50.latest for just the cost of a support renewal. Considering that 9.40 went out of support in April and 7.31 goes out of support in September, I'd say that's a good deal. As to why the archive is taking more output files on Saturday than other days, no clue. Art Art S. Kagel Oninit (www.oninit.com) IIUG Board of Directors (art@iiug.org) Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Oninit, the IIUG, nor any other organization with which I am associated either explicitly or implicitly. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Thu, Jul 9, 2009 at 11:20 AM, Schmitz, Rob B[EQ] < Rob.B.Schmitz@embarq.com> wrote: > Good morning IDS folks! > > Sorry for the long post, but I have been wrestling with an ontape script > for > some time now and seem to have hit a brick wall. We currently have 156 > instances on 78 servers. We have IDS 7.31 and 9.40 of various levels > running > on Sun, HP, and AIX. We have successfully used BMC's SQL-BackTrack as our > storage manager with onbar for many years. My company decided they no > longer > want to pay for the BMC license so I need another method for performing > database backups. I looked at ISM but it has too many limitations. Some of > our > instances are over 1 TB and we have many large chunks. > > I would love to be able to upgrade to 11.5, but again, the company does not > want to spend any resources to upgrade. Their stated goal is to quit using > Informix. Although that has been a goal for over ten years, we haven't > gotten > rid of one app yet. However, that means they won't spend anything to > upgrade. > By the way, my company is getting rid of SQL-BackTrack for Oracle as well, > but > rman seems to fill the void fairly well. > > I feel that my solution is to use ontape to disk. I searched the IIUG > repository and Google and the best I could find was a little script named > auto_ontape.ksh, written by Peter Tashkoff in 1998. Because the script was > originally written for a tape jukebox, I had to make a few modifications, > but > it has turned out to be very useful. This script watches the output from > ontape and when it sees the prompt to "Please mount tape " it jiggers the > link > specified in TAPEDEV and issues an echo to serve as the "return". Here is > what > that script looks like: > > ---------------------------------------------------------------------- > echo > > sleep 20 > > echo "\\ The first file in the series is ${ARCH_FILE}" >> $OUTFILE > > while [ `onstat -g ath | grep arcbackup | wc -l` -gt 0 ] > do > > sleep 10 > > if [ `tail -1 $OUTFILE | awk '{print $2}'` = "mount" ] > > then > > let INCRMNT=INCRMNT+1 > > > ARCH_FILE=${BACKUP_DIR}/${INFORMIXSERVER}_${TIMESTAMP}-${INCRMNT}.Level_${LVL} > > touch $ARCH_FILE > > chmod 777 $ARCH_FILE > > rm -f ${BASE_DIR}/${INST}/links/tape/tapedev > > ln -s ${ARCH_FILE} ${BASE_DIR}/${INST}/links/tape/tapedev > > echo > > echo "\\ New file is ${ARCH_FILE}" >> $OUTFILE > > fi > done > > echo "\\ The last file in the series is ${ARCH_FILE}" >> $OUTFILE > ---------------------------------------------------------------------- > > Most of the environment variables, including the first ARCH_FILE, are set > in > the calling script. auto_ontape.ksh is called by: > > auto_ontape.ksh | ontape -s -L $LVL >> $OUTFILE 2>> $OUTFILE > > The calling script does some instance checking before calling > auto_ontape.ksh > and it performs some expiration functions afterwards. > > This works most of the time. It appears to always work for our 9.40 > instances > because I set TAPESIZE to 0 and we don't have to worry about multiple > backup > files. The problem I have is that on the 7.31 instances on which I am > testing, > the output file gets so many "Please mount tape " messages so quickly that > the > output file fills the filesystem holding our message files (different from > the > filesystem holding the backup files). So far, it seems to only do this on > Saturday nights. There are no informix cron jobs that are different on > Saturday than any other night. I am also investigating if the tape ops > folks > are backing up the server at that time, but thus far I have not found any > reason for this to happen. > > I found a reference to this same issue in my Google searches, but I cannot > find any reason for it or how to avoid it. I also read that the 2 GB file > limit went away in 7.2, but that does not seem to be the case. (I believe > it > finally went away in 9.x.) > > Does anyone have any idea what causes this behavior? Alternatively, does > anyone know of a different script that could avoid this problem? > > Any help would be greatly appreciated. > > Thanks > > Rob Schmitz > Embarq Data Management > rob.b.schmitz@embarq.com > www.embarq.com > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --001636c5b526e4aeba046e484ee2 ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.

Certifying apps that are compatible with 7.31 & 9.40 on 11.50 is trivial. If you are not making changes to take advantage of new features and are not using any 9.40 datablades that are no longer supported, it's just the effort to recompile everything and test the heck out of it all. You should see no problems, we've ported several clients with commercial and home-grown apps over the past couple of years without any issues at all, but as always you've got to do the testing. There are new features you may want to take advantage of, but that's a separate issue to the upgrade itself. Art Art S. Kagel Oninit (www.oninit.com) IIUG Board of Directors (art@iiug.org) Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Oninit, the IIUG, nor any other organization with which I am associated either explicitly or implicitly. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Thu, Jul 9, 2009 at 12:50 PM, Schmitz, Rob B[EQ] < Rob.B.Schmitz@embarq.com> wrote: > Thanks as always Art. Technically, we can upgrade. We've kept our > maintenance > up to date and we are currently paying for extended support for 9.40 (and > we > will also pay for it for 7.31 come September). Our issue has been in > getting > the applications to fund their effort to support the upgrade. We've just > been > purchased by another company, so that throws all sorts of tech buying > decisions into a tizzy. > > Rob Schmitz > Embarq Data Management > rob.b.schmitz@embarq.com > www.embarq.com > > -----Original Message----- > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Art > Kagel > Sent: Thursday, July 09, 2009 11:26 AM > To: ids@iiug.org > Subject: Re: ontape to disk [16295] > > The 2GB limit went away in 9.40, not in 7.3x, you are correct. Tell you > company that right now they can upgrade from 7.31 and/or 9.40 to > 11.50.latest for just the cost of a support renewal. Considering that 9.40 > went out of support in April and 7.31 goes out of support in September, I'd > say that's a good deal. > > As to why the archive is taking more output files on Saturday than other > days, no clue. > > Art > > Art S. Kagel > Oninit (www.oninit.com) > IIUG Board of Directors (art@iiug.org) > > Disclaimer: Please keep in mind that my own opinions are my own opinions > and > do not reflect on my employer, Oninit, the IIUG, nor any other organization > with which I am associated either explicitly or implicitly. Neither do > those opinions reflect those of other individuals affiliated with any > entity > with which I am affiliated nor those of the entities themselves. > > On Thu, Jul 9, 2009 at 11:20 AM, Schmitz, Rob B[EQ] < > Rob.B.Schmitz@embarq.com> wrote: > > > Good morning IDS folks! > > > > Sorry for the long post, but I have been wrestling with an ontape script > > for > > some time now and seem to have hit a brick wall. We currently have 156 > > instances on 78 servers. We have IDS 7.31 and 9.40 of various levels > > running > > on Sun, HP, and AIX. We have successfully used BMC's SQL-BackTrack as our > > storage manager with onbar for many years. My company decided they no > > longer > > want to pay for the BMC license so I need another method for performing > > database backups. I looked at ISM but it has too many limitations. Some > of > > our > > instances are over 1 TB and we have many large chunks. > > > > I would love to be able to upgrade to 11.5, but again, the company does > not > > want to spend any resources to upgrade. Their stated goal is to quit > using > > Informix. Although that has been a goal for over ten years, we haven't > > gotten > > rid of one app yet. However, that means they won't spend anything to > > upgrade. > > By the way, my company is getting rid of SQL-BackTrack for Oracle as > well, > > but > > rman seems to fill the void fairly well. > > > > I feel that my solution is to use ontape to disk. I searched the IIUG > > repository and Google and the best I could find was a little script named > > auto_ontape.ksh, written by Peter Tashkoff in 1998. Because the script > was > > originally written for a tape jukebox, I had to make a few modifications, > > but > > it has turned out to be very useful. This script watches the output from > > ontape and when it sees the prompt to "Please mount tape " it jiggers the > > link > > specified in TAPEDEV and issues an echo to serve as the "return". Here is > > what > > that script looks like: > > > > ---------------------------------------------------------------------- > > echo > > > > sleep 20 > > > > echo "\\ The first file in the series is ${ARCH_FILE}" >> $OUTFILE > > > > while [ `onstat -g ath | grep arcbackup | wc -l` -gt 0 ] > > do > > > > sleep 10 > > > > if [ `tail -1 $OUTFILE | awk '{print $2}'` = "mount" ] > > > > then > > > > let INCRMNT=INCRMNT+1 > > > > > > > > ARCH_FILE=${BACKUP_DIR}/${INFORMIXSERVER}_${TIMESTAMP}-${INCRMNT}.Level_${LVL} > > > > touch $ARCH_FILE > > > > chmod 777 $ARCH_FILE > > > > rm -f ${BASE_DIR}/${INST}/links/tape/tapedev > > > > ln -s ${ARCH_FILE} ${BASE_DIR}/${INST}/links/tape/tapedev > > > > echo > > > > echo "\\ New file is ${ARCH_FILE}" >> $OUTFILE > > > > fi > > done > > > > echo "\\ The last file in the series is ${ARCH_FILE}" >> $OUTFILE > > ---------------------------------------------------------------------- > > > > Most of the environment variables, including the first ARCH_FILE, are set > > in > > the calling script. auto_ontape.ksh is called by: > > > > auto_ontape.ksh | ontape -s -L $LVL >> $OUTFILE 2>> $OUTFILE > > > > The calling script does some instance checking before calling > > auto_ontape.ksh > > and it performs some expiration functions afterwards. > > > > This works most of the time. It appears to always work for our 9.40 > > instances > > because I set TAPESIZE to 0 and we don't have to worry about multiple > > backup > > files. The problem I have is that on the 7.31 instances on which I am > > testing, > > the output file gets so many "Please mount tape " messages so quickly > that > > the > > output file fills the filesystem holding our message files (different > from > > the > > filesystem holding the backup files). So far, it seems to only do this on > > Saturday nights. There are no informix cron jobs that are different on > > Saturday than any other night. I am also investigating if the tape ops > > folks > > are backing up the server at that time, but thus far I have not found any > > reason for this to happen. > > > > I found a reference to this same issue in my Google searches, but I > cannot > > find any reason for it or how to avoid it. I also read that the 2 GB file > > limit went away in 7.2, but that does not seem to be the case. (I believe > > it > >

I Rob, what version really you have? I have the same problems years ago with informix 5.x over SCO Unix (limited to 2GB the file destination). Can you use ISM? The basic client is free, with some limitations. I have some scripts to do these job by cron, what you do with the logical logs? they are save to disk too? I think witch I can help you because I have the same problems few years ago, sorry for my english, I prefer spanish but... I remember some combination of scripts with redirection for the "mount next tape" and compress pipe to reduce the space, and, obviously, the restore procedure!

Gustavo, Thank you for offering to help. I am only having an occasional problem with my 7.31 instances. The one I am testing is 7.31.UD5, but the problem arises from having to "mount new tapes" because of the 2 GB file size limit in 7.31. My scripts work fine for my 9.40 instances. I also have a script which saves the logical logs to disk and that works fine. I cannot use ISM because of its limitations. I am interested in learning the approach you used for responding to the "Please mount tape " prompts. My problem only occurs once per week, but perhaps a different approach would eliminate the problem. Thanks Rob Schmitz CenturyLink Data Management rob.b.schmitz@embarq.com www.embarq.com -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of GUSTAVO TOBARES Sent: Thursday, July 09, 2009 10:44 PM To: ids@iiug.org Subject: Re: ontape to disk [16310] I Rob, what version really you have? I have the same problems years ago with informix 5.x over SCO Unix (limited to 2GB the file destination). Can you use ISM? The basic client is free, with some limitations. I have some scripts to do these job by cron, what you do with the logical logs? they are save to disk too? I think witch I can help you because I have the same problems few years ago, sorry for my english, I prefer spanish but... I remember some combination of scripts with redirection for the "mount next tape" and compress pipe to reduce the space, and, obviously, the restore procedure! ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.

The best way is to get TCL and Expect and write an Expect script. Expect is a scripting language written over TCL that is specifically designed to control other software. So, it is event driven and you specify what prompts you are looking for and what the reply should be to each. An expect script for ontape backups would look something like: expect "Please mount tape " { cmd = "mv tapefile tapefile.", fileno; exec cmd; exec "touch tapefile" reply "\\ "; } The syntax isn't exact as I haven't written an Expect script in 8 or 10 years, but that's the idea. This doesn't show opening the pipe running the ontape, but that's just as easy. Trivial. In y\\\\MY utils_ak package, for my EVENTALARM program, I wrote a custom module to handle the interaction with ontape to back up logical logs as they fill. That was before I learned about Expect. It would have been MUCH easier to embed TCL and Expect in my program, but... You can download TCP and Expect from the web. TCL builds easily and Expect is just a bunch of TCL scripts that implement the event driven parts of the language (all of TCL is available to Expect scripts as well). Art Art S. Kagel Oninit (www.oninit.com) IIUG Board of Directors (art@iiug.org) Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Oninit, the IIUG, nor any other organization with which I am associated either explicitly or implicitly. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Fri, Jul 10, 2009 at 8:55 AM, Schmitz, Rob B[EQ] < Rob.B.Schmitz@embarq.com> wrote: > Gustavo, > > Thank you for offering to help. I am only having an occasional problem with > my > 7.31 instances. The one I am testing is 7.31.UD5, but the problem arises > from > having to "mount new tapes" because of the 2 GB file size limit in 7.31. My > scripts work fine for my 9.40 instances. I also have a script which saves > the > logical logs to disk and that works fine. I cannot use ISM because of its > limitations. > > I am interested in learning the approach you used for responding to the > "Please mount tape " prompts. My problem only occurs once per week, but > perhaps a different approach would eliminate the problem. > > Thanks > > Rob Schmitz > CenturyLink Data Management > rob.b.schmitz@embarq.com > www.embarq.com > > -----Original Message----- > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of > GUSTAVO > TOBARES > Sent: Thursday, July 09, 2009 10:44 PM > To: ids@iiug.org > Subject: Re: ontape to disk [16310] > > I Rob, what version really you have? I have the same problems years ago > with > informix 5.x over SCO Unix (limited to 2GB the file destination). > > Can you use ISM? The basic client is free, with some limitations. > > I have some scripts to do these job by cron, what you do with the logical > logs? they are save to disk too? > > I think witch I can help you because I have the same problems few years > ago, > sorry for my english, I prefer spanish but... > > I remember some combination of scripts with redirection for the "mount next > tape" and compress pipe to reduce the space, and, obviously, the restore > procedure! > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --0016e68dbd97da96e9046e5cea23