RE: Power7

upgrade. Try switching from 2003 to 2008.

Done it. Not a problem. No rewriting at all. Just copy and install. If
you've never done things like that on a Windows deployment before, then you
probably will think that it's difficult. It's not. The Windows HAL/HEL is
designed specifically to manage this upgrade. With .NET, the upgrade is even
simpler.

As for V6R1 versus V5R4, well, I can tell you that our 3rd party vendor had
a blowup with a simple SQL library that had to be re-deployed by an IBM
expert tech to make their application work on V6R1. All we did was a simple
backup/restore for the application into V6R1 on a new iSeries (new
hardware).

Every single platform out there has its quirks about upgrading. There is not
a one that can do it seamlessly for every application.

Example ONE: When Microsoft killed VB6, everything had to be rewritten.

VB6 is not the issue here. That's a programming environment, and nothing to
do with the OS. The VB6 runtime had to be EOL'd at some point so that
VB6.NET and the future of compatible platform computing could be secured on
the windows platform.

VB6 is NOT Windows. It's just a programming language. There are host
processes available that can still run VB6. In fact, I have a legacy
application written in 2004 (not written by ME) that I support and it is
written in plain old VB6. It runs on Windows 2003 and Windows 2008 just
fine.

You said it was simple. The page disagrees. Don't blame me, it's one
of your guys who said it.

Every migration at the enterprise level has its difficulties. I know someone
who is an IT manager for a hospital here and when they upgrade their network
or systems, they are down for the entire weekend sometimes. They run big IBM
iron that takes 12 hours to boot. That is not an exaggeration either.

This is absolute [xxxx]. There isn't a single non-DB2 enterprise

I see this word "enterprise" running around here a lot. What exactly are you
referring to? Is it the scale of the database, or the technologies used to
keep it running, or the extent to which it is made redundant?

If you are an expert DB2 administrator and an RPG programmer, then you must
setup log shipping and hot replication to redundant iSeries nodes for your
systems? Right? You also setup index re-ordering jobs and schedule nightly
maintenance to update query statistics and archive stale data records?
Right?

installation that doesn't demand a full-time DBA.

"demand" is a strong word. These "enterprise" operations choose to have
full-time DBAs because they are also keeping their programming busy update
and improving their systems. Having a full-time DBA is a smart business
decision, not a "mandatory" requirement for "enterprise" operation.

No, I'm saying that DB2 doesn't need a DBA, and every other database does.

It does need a DBA, just like every database system out there that is
running 24/7 in high-availability mode. For exactly the operations that I
mentioned earlier.

And that's why I stay out of these conversations. I'm done here.

These conversations, when kept respectful and on-topic, are important for
newbies who are here to understand the iSeries platform and where it fits
into their enterprise. When I was researching the iSeries for purchase, I
could not find anything about how to easily set it up, what to watch out
for, how to handle configuration failures, nothing.

The documentation at IBM is horribly inept and written clearly with
abstraction in mind so that it could pertain to as many "variants" on their
systems as possible.

but it ain't easy. You get what you pay for.

Yeah, such as USB ports that don't work. Let's try to keep the inflammatory
rhetoric at a minimum. We are all professionals and have extensive
experience in IT management and security.

-- Jake