SEO

Hi, everybody. Got a question for the experts.

I have a client who runs Informix Dynamic Server 7.20 UC3 on a SCO
Unixware 7.01 box and has done for 5+ years.

We had a disaster recovery PC of identical configuration which was
tested regularly to see if the customer's ontape backups could be
restored.

Unfortunately the motherboard on this PC has failed and a repair would
be prohibitive, so we are looking at upgrading the disaster PC.
Unfortunately our research has found out that Unixware 7.01 is not
compatible with modern hardware and never will be as SCO no longer
support it. Herefore we must upgrade software too.

My question is thus, what parameters are important in being able to
restore ontapes. Could we change to MS Windows 2000 Server and still be
able to restore? Could we change from using RAW DISK SPACE to
filesystems? Is just the onconfig file important or are other
parameters used?

Any help would be most appreciated. Thanks.

Hopalong wrote:
> Hi, everybody. Got a question for the experts.
>
> I have a client who runs Informix Dynamic Server 7.20 UC3 on a SCO
> Unixware 7.01 box and has done for 5+ years.
>
> We had a disaster recovery PC of identical configuration which was
> tested regularly to see if the customer's ontape backups could be
> restored.
>
> Unfortunately the motherboard on this PC has failed and a repair would
> be prohibitive, so we are looking at upgrading the disaster PC.
> Unfortunately our research has found out that Unixware 7.01 is not
> compatible with modern hardware and never will be as SCO no longer
> support it. Herefore we must upgrade software too.
>
> My question is thus, what parameters are important in being able to
> restore ontapes. Could we change to MS Windows 2000 Server and still be
> able to restore? Could we change from using RAW DISK SPACE to
> filesystems? Is just the onconfig file important or are other
> parameters used?

No, IDS can only restore to the exact same OS and minor version number of
IDS on compatible hardware (ie Solaris on Intel cannot restore to Solaris on
Sparc).

Don't go windows, you already know UNIX, go with Linux. There are many
excellent releases of Linux and IDS runs very well on them. You will not be
able to get IDS 7.20 (which BTW is very old, out of support, and not even
Y2K compliant). But you could build the new server, port everything there,
and make that the new main box while building a new backup box, also running
Linux. I'd recommend going to IDS 9.40UC5 or later. You'll find that
besides the faster new hardware, Linux is much faster than SCO was and very
compatible with Unixware. The port should go very smoothly. Also consider
using replication to make a hot backup instead of relying on backup restores
for a warm backup only. Both HDR and ER are rock solid in IDS 9.40.

Art S. Kagel

"Art S. Kagel" <kagel@bloomberg.net> wrote in message
news:41BF66EE.1090103@bloomberg.net...

> Don't go windows, you already know UNIX, go with Linux. There are many
> excellent releases of Linux and IDS runs very well on them. You will not
> be able to get IDS 7.20 (which BTW is very old, out of support, and not
> even Y2K compliant). But you could build the new server, port everything
> there, and make that the new main box while building a new backup box,
> also running Linux. I'd recommend going to IDS 9.40UC5 or later.

As a matter of interest, now that IBM has extended the end-of-support to v7,
why would you recommend a user on a very old version of v7, by all accounts
not very innovative, move to v9? Not saying your wrong but one of my users
asked me the same question today: "Why should I move to v9 if I'm happy on
v7?". "To help pay for my holiday in The Maldives" is the actual answer,
but didn't seem politic, so I said I'd think about it. Thing is, I'd like
to sure I'm not missing anything before replying. For a user who is
comfortable with v7, does not want to use user-defined datatypes or
datablades (in my experince, 90%++ of them), and whose database is modest
enough in size that the 2G chunk limit is not a major inconvenience, what
other imperatives are there?

cheers
Neil

Neil Truby wrote:

> As a matter of interest, now that IBM has extended the end-of-support to v7,
> why would you recommend a user on a very old version of v7, by all accounts
> not very innovative, move to v9? Not saying your wrong but one of my users
> asked me the same question today: "Why should I move to v9 if I'm happy on
> v7?". "To help pay for my holiday in The Maldives" is the actual answer,
> but didn't seem politic, so I said I'd think about it. Thing is, I'd like
> to sure I'm not missing anything before replying. For a user who is
> comfortable with v7, does not want to use user-defined datatypes or
> datablades (in my experince, 90%++ of them), and whose database is modest
> enough in size that the 2G chunk limit is not a major inconvenience, what
> other imperatives are there?

There are a /lot/ of "nice to haves" if no one killer reason. After all
v7 is a stable supported product. The nice to haves can be hard to make
into a convincing business argument from the customer's point of view as
they may not see why they would benefit from them. The best reason I can
come up with is that HDR (on which we rely on heavily) is brilliant in
9.4 - never had a problem with it. 7.3 sometimes has the odd hiccup
although it was usually easy to fix. We use Informix as a DBMS for our
application and it would make our developers' lives easier not to have
to develop for two versions and not to be restricted to the V7 feature
set. Some of our v7 systems run on obsolete/unsupported operating
systems such as Windows NT Workstation and AIX 4.3 - usually we upgrade
them at the same time.

However, I agree with you: unless IBM stop supporting it there is no
great imperative for users content with v7 to migrate. Even then with no
killer bugs having emerged so far, we probably have enough experience to
keep them ticking over until the OS they run on and whether that OS
supports available hardware becomes an issue.

Ben.

"Neil Truby" <neil.truby@ardenta.com> schrieb:

>For a user who is
>comfortable with v7, does not want to use user-defined datatypes or
>datablades (in my experince, 90%++ of them), and whose database is modest
>enough in size that the 2G chunk limit is not a major inconvenience, what
>other imperatives are there?

Very good question. For me, so far there are none, especially in the light
of the extended EOL date given by IBM. And there are still many users out
there who are perfectly content with 5.x!

Regards, Richard

Neil,

other than the holiday, how about all the following which are available
in 9.40 ....


Improved Performance 8-15%better in internal benchmarks;Fuzzy
Checkpoints;Shared Statement Cache;New Buffer Management System;B-Tree
Scanner;Improved Replication Perf; Increased Scalability;Data capacity
of a single instance 128 PB;Support for more CPUs;Improved support for
large objects;Higher Availability/Reliability;Restartable Fast
Recovery;Improved Rollback Performance;Dynamic Log Creation;Improved
Enterprise Replication (ER);ER / HDR InteroperabilityEnhanced Security
;Secure over-the-wire encryption using OpenSSL encryption
libraries;Configurable user authentication mechanisms using Pluggable
Authentication Modules (PAMs);More permission check upon
start-up;Simplified Administration ;Redirected Restore;Full use of
Tapes;Rename Chunks;New Unix Bundle Installer;No libraries in
/usr/lib;Order of install;Add Chunks when first chunk is full;Onstat
enhancements;Explain enhancements;Log Management;Dynamic Lock
Allocation;Easier Application development ;SQL language
enhancements;Expanded Unicode support;Improved Extensibility;Enhanced
API ;Native .Net Provider; LRU_MIN_DIRTY & LRU_MAX_DIRTY; Dynamic
Adding of Logical Log; SmartBlob Spooling Queue; Spooling Threads;
Utilities all compiled to handle large files;Redirected Restore; Rename
Chunks During Restore; Add Chunks When First Chunk of Root DBSpace is
Full;Enhanced Diagnostics; OnStat Enhancements; Explain Can be turned
on Dynamically; Support for Long Identifiers;Updated Unicode
Support;Sequences;Triggers on Select and Views;Order by not in select
list;ANSI SQL-99 Joins;Describe input;Unions in Sub-queries;Names for
Return Values;Multiple OUT parameters;Improved support for long
character strings;Multi-nationalization; Collections;Table
Functions;Virtual Table interface;User Definded Data
Types;High-Performance Programming Support;Built-in functions for
handling complex data;Datablade Support;Enhanced APIs; JDBC;OLE DB;ODBC
ESQL/C;Even More Platform Support;Quality




Neil Truby wrote:
> "Art S. Kagel" <kagel@bloomberg.net> wrote in message
> news:41BF66EE.1090103@bloomberg.net...
>
> > Don't go windows, you already know UNIX, go with Linux. There are
many
> > excellent releases of Linux and IDS runs very well on them. You
will not
> > be able to get IDS 7.20 (which BTW is very old, out of support, and
not
> > even Y2K compliant). But you could build the new server, port
everything
> > there, and make that the new main box while building a new backup
box,
> > also running Linux. I'd recommend going to IDS 9.40UC5 or later.
>
> As a matter of interest, now that IBM has extended the end-of-support
to v7,
> why would you recommend a user on a very old version of v7, by all
accounts
> not very innovative, move to v9? Not saying your wrong but one of my
users
> asked me the same question today: "Why should I move to v9 if I'm
happy on
> v7?". "To help pay for my holiday in The Maldives" is the actual
answer,
> but didn't seem politic, so I said I'd think about it. Thing is, I'd
like
> to sure I'm not missing anything before replying. For a user who is
> comfortable with v7, does not want to use user-defined datatypes or
> datablades (in my experince, 90%++ of them), and whose database is
modest
> enough in size that the 2G chunk limit is not a major inconvenience,
what
> other imperatives are there?
>
> cheers
> Neil

Neil Truby wrote:
> "Art S. Kagel" <kagel@bloomberg.net> wrote in message
> news:41BF66EE.1090103@bloomberg.net...
>
>
>>Don't go windows, you already know UNIX, go with Linux. There are many
>>excellent releases of Linux and IDS runs very well on them. You will not
>>be able to get IDS 7.20 (which BTW is very old, out of support, and not
>>even Y2K compliant). But you could build the new server, port everything
>>there, and make that the new main box while building a new backup box,
>>also running Linux. I'd recommend going to IDS 9.40UC5 or later.
>
>
> As a matter of interest, now that IBM has extended the end-of-support to v7,
> why would you recommend a user on a very old version of v7, by all accounts
> not very innovative, move to v9? Not saying your wrong but one of my users
> asked me the same question today: "Why should I move to v9 if I'm happy on
> v7?". "To help pay for my holiday in The Maldives" is the actual answer,
> but didn't seem politic, so I said I'd think about it. Thing is, I'd like
> to sure I'm not missing anything before replying. For a user who is
> comfortable with v7, does not want to use user-defined datatypes or
> datablades (in my experince, 90%++ of them), and whose database is modest
> enough in size that the 2G chunk limit is not a major inconvenience, what
> other imperatives are there?

My reasons are several, and I've made the recommendation to friends I've
helped out and here at Bloomberg. Vis:

- LVARCHAR is much nicer than VARCHAR and has uses that are not appropriate
for CHAR.
- I find functional indexes very useful.
- IDS 9.4 is 10-15% faster than 7.31.
- SERIAL8 & INT8 are very useful in the real world, much as I like DECIMAL.
- 9.4+ is the path that will grow more and more compatible with DB2 and its
successor. If later I decide that's the way to go, I'm already there.
Meanwhile I get the latest goodies as they appear like the rest of this list.
- Lower overhead checkpoints.
- Automatic logical log management.
- No more lock table overflows (I know 7.31 has it too).
- Ability to create external table interfaces to other data sources.
- Improved ER performance.
- DBspace renaming.
- Direct path to 9.5 with all it promises which includes several of my wish
list items.

Art S. Kagel

"Ben Thompson" <ben@nomonitorsoftspam.com> wrote in message
news:10s032sotac2089@corp.supernews.com...

> There are a /lot/ of "nice to haves" if no one killer reason. After all v7
> is a stable supported product. The nice to haves can be hard to make into
> a convincing business argument from the customer's point of view ....

(Groan). Don't I know it. And now my daughter wants scuba lessons .....
:-(

"Art S. Kagel" <kagel@bloomberg.net> wrote in message
news:41C08CD7.7000100@bloomberg.net...
> Neil Truby wrote:
> what other imperatives [to move from v7 to v9] are there?

> My reasons are several, and I've made the recommendation to friends I've
> helped out and here at Bloomberg. Vis:

> - LVARCHAR is much nicer than VARCHAR and has uses that are not
> appropriate for CHAR.
> - I find functional indexes very useful.
> - IDS 9.4 is 10-15% faster than 7.31.
> - SERIAL8 & INT8 are very useful in the real world, much as I like
> DECIMAL.
> - 9.4+ is the path that will grow more and more compatible with DB2 and
> its successor. If later I decide that's the way to go, I'm already there.
> Meanwhile I get the latest goodies as they appear like the rest of this
> list.
> - Lower overhead checkpoints.
> - Automatic logical log management.
> - No more lock table overflows (I know 7.31 has it too).
> - Ability to create external table interfaces to other data sources.
> - Improved ER performance.
> - DBspace renaming.
> - Direct path to 9.5 with all it promises which includes several of my
> wish list items.

Can this be a reply to wcottishpoet too?

Well, I think the performance one is a moot point. I agree that if you know
what you are doing you can get more out of v9. But remember, you (and
wcottishpoet, and I of course!) are Informix Gods. The fact is that the
most sites *don't* have dedicated, knowledgable DBAs. And if they are that
type of customer they aren't likely to be much bothered with (what they
would see as) arcane performance features, replication, interfaces to
external sources, functional indexes, user-defined data types and the rest.

The quick migration path to DB2 is a killer benefit though :-))

My alter ego was called many things in the past, but and Informix God??

We can say performance is a moot point, but, as I think I have shown in
my list - which may not be complete - , there is a long (and growing
list) of new things in IDS 9 that are not there in IDS 7. The longer
that list becomes the longer it will take DB2 to "catch up"!

Lets be positive! There are a lot of good thinsg in my list!




Neil Truby wrote:
> "Art S. Kagel" <kagel@bloomberg.net> wrote in message
> news:41C08CD7.7000100@bloomberg.net...
> > Neil Truby wrote:
> > what other imperatives [to move from v7 to v9] are there?
>
> > My reasons are several, and I've made the recommendation to friends
I've
> > helped out and here at Bloomberg. Vis:
>
> > - LVARCHAR is much nicer than VARCHAR and has uses that are not
> > appropriate for CHAR.
> > - I find functional indexes very useful.
> > - IDS 9.4 is 10-15% faster than 7.31.
> > - SERIAL8 & INT8 are very useful in the real world, much as I like
> > DECIMAL.
> > - 9.4+ is the path that will grow more and more compatible with DB2
and
> > its successor. If later I decide that's the way to go, I'm already
there.
> > Meanwhile I get the latest goodies as they appear like the rest of
this
> > list.
> > - Lower overhead checkpoints.
> > - Automatic logical log management.
> > - No more lock table overflows (I know 7.31 has it too).
> > - Ability to create external table interfaces to other data
sources.
> > - Improved ER performance.
> > - DBspace renaming.
> > - Direct path to 9.5 with all it promises which includes several of
my
> > wish list items.
>
> Can this be a reply to wcottishpoet too?
>
> Well, I think the performance one is a moot point. I agree that if
you know
> what you are doing you can get more out of v9. But remember, you
(and
> wcottishpoet, and I of course!) are Informix Gods. The fact is that
the
> most sites *don't* have dedicated, knowledgable DBAs. And if they
are that
> type of customer they aren't likely to be much bothered with (what
they
> would see as) arcane performance features, replication, interfaces to

> external sources, functional indexes, user-defined data types and the
rest.
>
> The quick migration path to DB2 is a killer benefit though :-))