Re: OS and hardware upgrade.

It's a misspelling of Elmer's last name.

Jerry C. Adams
IBM i Programmer/Analyst
Mt. Everest grows at a rate of about 4 mm per year. -EUI
--
A&K Wholesale
Murfreesboro, TN
615-867-5070


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Shannon ODonnell
Sent: Tuesday, May 15, 2012 3:00 PM
To: 'Midrange Systems Technical Discussion'
Subject: RE: OS and hardware upgrade.

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

a

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

a

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

--
Regards
Evan Harris
http://www.auctionitis.co.nz
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe,
or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/midrange-l.


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe,
or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/midrange-l.