RE: OS and hardware upgrade. -- MIDRANGE-L

What does "FUD" stand for?

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
Sent: Tuesday, May 15, 2012 2:55 PM
To: Midrange Systems Technical Discussion
Subject: Re: OS and hardware upgrade.

I never said it wasn't doable. I said the other method was preferred. The
OP has hardware that will support 7.1. We have the same model running 7.1.

Saying that some people on the list have had much trouble cleaning up after
doing the unpreferred method is true, but I'll grant you as how that could
be construed as FUD.

And I did say that it was doable, I even said that many have done it.

I even pointed out a second reference in Infocenter which would help the OP
if they decided to still go the "unpreferred way".

The only thing I'm guilty of is stressing the preferred way and maybe even
to the point that some may construe it as FUD.

As a BP perhaps you have more experience doing the "unpreferred" way since,
as you've stated, you support some customers on older hardware which have
restrictions that the OP doesn't. I take it the OP is not a BP, doesn't
have the experience you or I have in doing upgrades, and I just want to save
them from potential problems.

Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail
to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com

From: Evan Harris <auctionitis@xxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>,
Date: 05/15/2012 03:43 PM
Subject: Re: OS and hardware upgrade.
Sent by: midrange-l-bounces@xxxxxxxxxxxx

Rob:

- I never said it was the preferred method.I said it was an option
- Whatever you might think it is an IBM documented, approved method of
getting from one release to another
- If your current hardware does not support the new release you have
to to this way

The OP asked if it was possible and had anyone done it. I said I had
and pointed him to the documentation. I tried to answer his question;
you're trying to change his requirements so your answer fits.

Regardless of the FUD in your examples it's perfectly do-able, you
just have to know what you are doing and know your applications.

Not everyone is you or Dekko. They are entitled to have different
priorities and drivers for their business. The problem with your
perspective is that you have not dealt with enough customers and
scenarios so you think every problem should be solved how you solved
it - that is until you change your mind. (HA, BRMS etc etc)

You should go work for a BP for a couple of years. A lot of your
rantings about the right way to do things would change.

On Tue, May 15, 2012 at 11:41 PM, <rob@xxxxxxxxx> wrote:

See also from the migration section of Infocenter at

http://publib.boulder.ibm.com/infocenter/iseries/v7r1m0/topic/rzamc/rzamcmig
ration.htm

Preparing for the migration from a System i model that does not support
IBM i 7.1

Right below the link for "Restoring previous release user data to a new
system" you'll see
The preferred method to restore previous release user data on your new,
target system is to use the migration method.
The migration method asks you to first install the new, current release
onto your old, source system. After which, you save your old system and
then you perform a full system recovery onto the new, target system.

Only

use these instructions if it is not possible to perform the preferred
migration process referenced in the Data migrations topic.

Notice there's a lot of manual recreation using the "Restoring previous
release user data to a new system" steps instead of just upgrading your
source system to 7.1 first. For example this is one of them from the
manual
Add job scheduler entries with the Add Job Schedule Entry (ADDJOBSCDE)
command using the information you printed from your source system. Use

the

Work with Job Schedule Entries (WRKJOBSCDE) command and select the print
option.
Now, we have a few hundred job schedule entries. Granted some might say
why not just restore the *JOBSCD object? Question this, why didn't IBM
just tell you that? Did they reformat that at some release that would
have been addressed if you had done a normal migration (by updating your
source system first)? Let me give you an example. Let's say you go

from

2.1 of BPCS to 8.3. You decide to skip all the migration steps that

BPCS

had for data conversions in between. Do you think you could just

restore

the 2.1 item master (IIM) file and have it work?

I'm not saying it's impossible to upgrade this way; evidently numerous
people have. I am just saying that you may not end up saving yourself

any

work and there's been a number of people on this list that's taken over

year to clean up a mess caused by doing it this way.

The OP came from Mount Olive Pickles. I would suspect there might be a
slow time of the year in which they could do this over two weekends. OS
upgrade one weekend and the hardware upgrade on another. There's a
company called Red Gold (a tomato processor) which attends our local

user

group and I am just going by some of the stuff I've heard from them.
If 24x7x365 is really a necessity then I'd argue they really should have

HA environment and should switch over to their backup machine and

stagger

the upgrades that way.

Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1
Group Dekko
Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com