yipeee!

#1

Just recieved a 'thought experiment' assignment from my boss.
Does it make sense, and how would it be accomplised, to move
the databases from the mainframe (small VSE 390?) to AIX?
I mentioned that we should then look at possible programs from
IBM to convert the mainframe database (VSAM?) files into DB2/AIX,
or Oracle databases. And that I thought Oracle had some facility
such that we could cluster and load-balance two+ nodes running
something like Parallel Oracle so that should a node need booting
or modifying off-line the application is still running (at
reduced capacity) for the users.

Thoughts?

Mike

#2

Mike <mikee (AT) mikee (DOT) ath.cx> wrote

Quote:

Just recieved a 'thought experiment' assignment from my boss.
Does it make sense, and how would it be accomplised, to move
the databases from the mainframe (small VSE 390?) to AIX?
I mentioned that we should then look at possible programs from
IBM to convert the mainframe database (VSAM?) files into DB2/AIX,
or Oracle databases. And that I thought Oracle had some facility
such that we could cluster and load-balance two+ nodes running
something like Parallel Oracle so that should a node need booting
or modifying off-line the application is still running (at
reduced capacity) for the users.

Is HA a real requirement, or just a nice-to-have? Because if you can
live with something like 99.9% availability then perhaps log-shipping
would suffice and you might be able to set up a db2 udb prototype in a
single afternoon. If it's one of those rare applications that really
needs 99.999% well then you've got some real work ahead - regardless
of the product chosen.

Oracle has more functionality and capability here but it's more
expensive, more complex/error-prone to use, and while i'm not sure of
RAC, OPS was a manageability nightmare. Still, for many situations it
is great.

However - one more thing: I find that my database choices usually
hinge more on the strategic direction of the company - rather than on
the specific needs of the application. If you go
application-by-application you'll end up with a half-dozen different
databases, and the skillset problem that results is typically more
challenging than the minor technical differences between commercial
databases.

#3

In article <66a61715.0402041122.27cdc560 (AT) posting (DOT) google.com>, Buck Nuggets wrote:

Quote:

Mike <mikee (AT) mikee (DOT) ath.cx> wrote

Just recieved a 'thought experiment' assignment from my boss.
Does it make sense, and how would it be accomplised, to move
the databases from the mainframe (small VSE 390?) to AIX?
I mentioned that we should then look at possible programs from
IBM to convert the mainframe database (VSAM?) files into DB2/AIX,
or Oracle databases. And that I thought Oracle had some facility
such that we could cluster and load-balance two+ nodes running
something like Parallel Oracle so that should a node need booting
or modifying off-line the application is still running (at
reduced capacity) for the users.

Is HA a real requirement, or just a nice-to-have? Because if you can
live with something like 99.9% availability then perhaps log-shipping
would suffice and you might be able to set up a db2 udb prototype in a
single afternoon. If it's one of those rare applications that really
needs 99.999% well then you've got some real work ahead - regardless
of the product chosen.

Oracle has more functionality and capability here but it's more
expensive, more complex/error-prone to use, and while i'm not sure of
RAC, OPS was a manageability nightmare. Still, for many situations it
is great.

However - one more thing: I find that my database choices usually
hinge more on the strategic direction of the company - rather than on
the specific needs of the application. If you go
application-by-application you'll end up with a half-dozen different
databases, and the skillset problem that results is typically more
challenging than the minor technical differences between commercial
databases.

The HA is a must. That's why if I could get it to work with either
oracle or db2 in this parallel fashion then I have built in HA
without having to mess with IBM's HACMP on AIX.

Agreed on the strategic direction.

Turns out this would probably be a phased project. First possibly
move the mainframe stuff to CICS on AIX. Then migrate the VSAM
stuff outside of CICS into DB2 as a phase 2. Then re-write the CICS
applications to run CICS native as a phase 3+.

#4

bucknuggets (AT) yahoo (DOT) com (Buck Nuggets) wrote in message news:<66a61715.0402041122.27cdc560 (AT) posting (DOT) google.com>...

Quote:

However - one more thing: I find that my database choices usually
hinge more on the strategic direction of the company - rather than on
the specific needs of the application. If you go
application-by-application you'll end up with a half-dozen different
databases, and the skillset problem that results is typically more
challenging than the minor technical differences between commercial
databases.

I don't see this. Even if a company has a strategic initiative to go
to a particular database, mergers, aquisitions, and specific
application requirements still mean heterogeneity. There may be some
pure MS companies around, but I wouldn't know about them (and I don't
think MS is one of them, and of course IBM may well be its own world).

The skillset problem is challenging, but a red herring since it is
probably not a good idea as a strategic plan, except maybe in certain
small companies. Even governments that specified Oracle figured that
out. Enterprise software salespeople sell gateways, if they have to.

jg
--
@home.com is bogus.
"I don't practice Santeria." - some pop song.
http://www.signonsandiego.com/news/u...s_1c5cuba.html

#5

Joel Garry wrote:

Quote:

There may be some
pure MS companies around, but I wouldn't know about them (and I don't
think MS is one of them, ....

MS isn't one of them. MS runs SAP for their financial system. And it
sure isn't on SQL Server.

--
Daniel Morgan
http://www.outreach.washington.edu/e...ad/oad_crs.asp
http://www.outreach.washington.edu/e...oa/aoa_crs.asp
damorgan@x.washington.edu
(replace 'x' with a 'u' to reply)

#6

joel-garry (AT) home (DOT) com (Joel Garry) wrote in message news:<91884734.0402061455.50ece075 (AT) posting (DOT) google.com>...

Quote:

I don't see this. Even if a company has a strategic initiative to go
to a particular database, mergers, aquisitions, and specific
application requirements still mean heterogeneity. There may be some
pure MS companies around, but I wouldn't know about them (and I don't
think MS is one of them, and of course IBM may well be its own world).

The skillset problem is challenging, but a red herring since it is
probably not a good idea as a strategic plan, except maybe in certain
small companies. Even governments that specified Oracle figured that
out. Enterprise software salespeople sell gateways, if they have to.

You misread my email: I didn't and don't advocate blind and complete
adherance to a strategic direction for vendor products. I did,
however, recommend putting a lot of priority on compliance with that
strategic direction.

Sure, you can build appliations that are a mix of vb, clipper, .net,
jdbc, and mainframe COBOL. But just because those technologies might
exist in the organization is no reason to avoid attempting some
consistency.

Same issue with databases - you can support Informix, Sybase, SQL
Server, Oracle, DB2, Postgresql, MySQL, Firebird, and Access if you
want. But you'll pay more for licenses, you'll have more human-error
failures due to insufficient skillsets.

Gateways aren't an answer either - just another set of product version
constraints, and incompatibilities. Want to be successful with this
kind of middleware - make sure you've got experts on all databases
*AND* the gateway. Nothing like finding that you've got to upgrade a
database to support an essential new application version, but that
your gateway doesn't yet support that version.

I'd firmly recommend trying to stick to an absolute minimum number of
database and application technologies. These days, the pressure seems
to be on one open source and one commercial product in most
departments that I work with. My recommendation is often something
like:
* mysql only if you have to (if required by application you want)
* postgresql for low-end databases
* db2/sybase/oracle/informix/sql server depending on:
* application requirements
* os preferences (unix vs windows)
* cost

The fact that one database has feature a and another database doesn't
(this year), is only very seldom the best reason for selecting a
database. Decide databases exclusively on that kind of criteria and
you'll create a disaster.

#7

I'm very favorable biased towards DB2 and AIX (based on support
experience, you can have trust) but I would not choose to migrate to
CICS on AIX.

DCE fades away, I can't believe CICS on AIX is -anymore?- a strategic
product (for IBM).

If leaving VSE, I would not reincarnate it on AIX with CICS, even in
an intermediate step.

I also believe log-shipping is a very reliable way to have a
replication side; a database can reside multiple times on a system
based on the redirected restore principle, so the recovery site can
even be a development system also.

In UDB 8.1 LUW the shadow database maintained with log-shipping
remains in roll-forward pending state. Using a snapshot capability of
a storage engine, a copy of the shadow can be validated.

Bernard Dhooghe

Mike <mikee (AT) mikee (DOT) ath.cx> wrote

Quote:

In article <66a61715.0402041122.27cdc560 (AT) posting (DOT) google.com>, Buck Nuggets wrote:
Mike <mikee (AT) mikee (DOT) ath.cx> wrote

Just recieved a 'thought experiment' assignment from my boss.
Does it make sense, and how would it be accomplised, to move
the databases from the mainframe (small VSE 390?) to AIX?
I mentioned that we should then look at possible programs from
IBM to convert the mainframe database (VSAM?) files into DB2/AIX,
or Oracle databases. And that I thought Oracle had some facility
such that we could cluster and load-balance two+ nodes running
something like Parallel Oracle so that should a node need booting
or modifying off-line the application is still running (at
reduced capacity) for the users.

Is HA a real requirement, or just a nice-to-have? Because if you can
live with something like 99.9% availability then perhaps log-shipping
would suffice and you might be able to set up a db2 udb prototype in a
single afternoon. If it's one of those rare applications that really
needs 99.999% well then you've got some real work ahead - regardless
of the product chosen.

Oracle has more functionality and capability here but it's more
expensive, more complex/error-prone to use, and while i'm not sure of
RAC, OPS was a manageability nightmare. Still, for many situations it
is great.

However - one more thing: I find that my database choices usually
hinge more on the strategic direction of the company - rather than on
the specific needs of the application. If you go
application-by-application you'll end up with a half-dozen different
databases, and the skillset problem that results is typically more
challenging than the minor technical differences between commercial
databases.

The HA is a must. That's why if I could get it to work with either
oracle or db2 in this parallel fashion then I have built in HA
without having to mess with IBM's HACMP on AIX.

Agreed on the strategic direction.

Turns out this would probably be a phased project. First possibly
move the mainframe stuff to CICS on AIX. Then migrate the VSAM
stuff outside of CICS into DB2 as a phase 2. Then re-write the CICS
applications to run CICS native as a phase 3+.

#8

"Bernard Dhooghe" <nomen (AT) attglobal (DOT) net> wrote

Quote:

I'm very favorable biased towards DB2 and AIX (based on support
experience, you can have trust) but I would not choose to migrate to
CICS on AIX.

DCE fades away, I can't believe CICS on AIX is -anymore?- a strategic
product (for IBM).

If leaving VSE, I would not reincarnate it on AIX with CICS, even in
an intermediate step.

I also believe log-shipping is a very reliable way to have a
replication side; a database can reside multiple times on a system
based on the redirected restore principle, so the recovery site can
even be a development system also.

In UDB 8.1 LUW the shadow database maintained with log-shipping
remains in roll-forward pending state. Using a snapshot capability of
a storage engine, a copy of the shadow can be validated.

Bernard Dhooghe

Obviously CICS is not a strategic product. But if one wants to move off the

mainframe and not change the application, then it "might be" a viable
solution.

#9

MQSeries is often recommended instead of CICS on Unix.

Bernard Dhooghe wrote:

Quote:

I'm very favorable biased towards DB2 and AIX (based on support
experience, you can have trust) but I would not choose to migrate to
CICS on AIX.

DCE fades away, I can't believe CICS on AIX is -anymore?- a strategic
product (for IBM).

If leaving VSE, I would not reincarnate it on AIX with CICS, even in
an intermediate step.

I also believe log-shipping is a very reliable way to have a
replication side; a database can reside multiple times on a system
based on the redirected restore principle, so the recovery site can
even be a development system also.

In UDB 8.1 LUW the shadow database maintained with log-shipping
remains in roll-forward pending state. Using a snapshot capability of
a storage engine, a copy of the shadow can be validated.

Bernard Dhooghe

Mike <mikee (AT) mikee (DOT) ath.cx> wrote

In article <66a61715.0402041122.27cdc560 (AT) posting (DOT) google.com>, Buck Nuggets wrote:

Mike <mikee (AT) mikee (DOT) ath.cx> wrote

Just recieved a 'thought experiment' assignment from my boss.
Does it make sense, and how would it be accomplised, to move
the databases from the mainframe (small VSE 390?) to AIX?
I mentioned that we should then look at possible programs from
IBM to convert the mainframe database (VSAM?) files into DB2/AIX,
or Oracle databases. And that I thought Oracle had some facility
such that we could cluster and load-balance two+ nodes running
something like Parallel Oracle so that should a node need booting
or modifying off-line the application is still running (at
reduced capacity) for the users.

Is HA a real requirement, or just a nice-to-have? Because if you can
live with something like 99.9% availability then perhaps log-shipping
would suffice and you might be able to set up a db2 udb prototype in a
single afternoon. If it's one of those rare applications that really
needs 99.999% well then you've got some real work ahead - regardless
of the product chosen.

Oracle has more functionality and capability here but it's more
expensive, more complex/error-prone to use, and while i'm not sure of
RAC, OPS was a manageability nightmare. Still, for many situations it
is great.

However - one more thing: I find that my database choices usually
hinge more on the strategic direction of the company - rather than on
the specific needs of the application. If you go
application-by-application you'll end up with a half-dozen different
databases, and the skillset problem that results is typically more
challenging than the minor technical differences between commercial
databases.

The HA is a must. That's why if I could get it to work with either
oracle or db2 in this parallel fashion then I have built in HA
without having to mess with IBM's HACMP on AIX.

Agreed on the strategic direction.

Turns out this would probably be a phased project. First possibly
move the mainframe stuff to CICS on AIX. Then migrate the VSAM
stuff outside of CICS into DB2 as a phase 2. Then re-write the CICS
applications to run CICS native as a phase 3+.

#10

"Blair Adamache" <badamache (AT) 2muchspam (DOT) yahoo.com> wrote

Quote:

MQSeries is often recommended instead of CICS on Unix.

I think people are missing the point. The existing mainframe application is

written in CICS (with a CICS 3270 user interface). MQSeries does not handle
a user interface, and even if it did, they don't want to re-write the
application right away.

Actually, MQSeries is a messaging system built on CICS technology in
Hursley. But there is not much use for a new product with a 3270 interface.