Re: OS and hardware upgrade.

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/rzamcmigration.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