RE: Backup - revisited

Pete,

You had me until you mentioned "Then you do an upgrade to the licensed
products". How would you do that upgrade?

I'm just to0 darn boring and do the normal upgrade paths one release at
a time....

I think you are right about your evaluation.....



Michael Crump

Manager, Computing Services
Saint-Gobain Containers, Inc.
1509 S. Macedonia Ave.
Muncie, IN 47302

765.741.7696
765.741.7012 f



Motivation
If a pretty poster and a cute saying are all it takes to motivate you,
you probably have a very easy job. The kind robots will be doing soon.

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Pete Massiello
Sent: Wednesday, September 03, 2008 4:14 PM
To: 'Midrange Systems Technical Discussion'
Subject: RE: Backup - revisited

Mike,

We do this 5.2 to 5.4 type of upgrade for unsupported hardware
all
the time, so it is something that we are very comfortable with, but you
need
to understand a lot of issues as Chuck was alluding to in his note
earlier
today. One of which is that you aren't bringing over QSYS, as that is
already on the machine with LIC, but nothing else. Then you just
restore.
You have a 5.4 machine with LIC and QSYS and nothing else, you restore
the
User Profiles, Config, NONSYS (which includes QUSRSYS will see back
level in
GO LICPGM), the DLO, and the IFS, Then do a RSTAUT. Then you do an
upgrade
to the licensed products to get everything back to V5R4, allowing INZSYS
(and INZBRMPRD to run if you have BRMS) and everything is ready to roll.
Don't forget the PTFs & Object conversions. But any changes to objects
on
the source machine that were in QSYS are lost and don't come across.

So, here is the SA who doesn't understand GO SAVE 21 but he is
trying to restore onto another version. This guy was *SCREWED before he
plugged the machine in. No, wonder things didn't restore correctly. I
am
amazed he got as far as he did.

JMHO
Pete

Pete Massiello
www.itechsol.com

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Crump, Mike
Sent: Wednesday, September 03, 2008 2:38 PM
To: Midrange Systems Technical Discussion
Subject: RE: Backup - revisited

These are the days I really miss Al...........This seems like a couple
of issues but it's not really related to backup.....but the migration
from 5.2 to 5.4....not something I'd ever recommend nor have I
tried.......

Michael Crump

Manager, Computing Services
Saint-Gobain Containers, Inc.
1509 S. Macedonia Ave.
Muncie, IN 47302

765.741.7696
765.741.7012 f



Motivation
If a pretty poster and a cute saying are all it takes to motivate you,
you probably have a very easy job. The kind robots will be doing soon.

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of John McKee
Sent: Wednesday, September 03, 2008 2:03 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: Backup - revisited

I received an email from the sa. The tone was somewhat more civilized
than in
the meeting. He attached a document describing some issues. I will
paste some
of it here, as this might make more sense to others:

During this time a GO SAVE 21 had to be performed on the old hardware to
capture the data and necessary meta-data required to perform the
conversions.

A restore and conversion procedure was available on the new server that
read the
meta-data and performed the necessary conversions.

The GO SAVE process does a lot more than just execute back up commands.

Each time that I worked with IBM support the first thing they asked was
did you
perform a GO SAVE 21.

IBM agreed we were executing all of the right commands using our SFHC
custom
back up procedure, but was unable to give me a definitive reason as to
why I
could not restore all of our IFS directories.

I remember working with IBM on a SAVE problem following the application
of PTFS.
I ended up having to omit the /QNTC file system to get it to work again.
This
was done with IBM's blessing. The GO SAVE 21 procedure saves the /QNTC
file
system without a problem. The QNTC file system is the windows server
file
system.



Does any of the above clarify anything??

John McKee

Quoting CRPence <CRPbottle@xxxxxxxxx>:

That this was an upgrade from v5r2 to v5r4, so the restore was
actually part of an upgrade scenario versus a standard DR, the origin

of

the problem in understanding this issue is probably now clear. It

seems

that the discussion is not about DR, but about an _upgrade_ that is
performed with _data migration_ from a prior release. There are a
variety of data migration strategies. When an upgrade is thrown in,

the

best choice is based on the capabilities of the hardware support for

the

release levels involved. Ideally the target system can be installed

to

the release level of the source system with only the LIC & OS, to

which

the restore-21 is performed, where the target is then upgraded from

the

lower to the higher release level; ideally, because that limits the
number of release upgrades to just one.

The most common failure in such upgrades is for an *assumption* that
it can be done simply by restoring stuff, rather than following a well
understood and tested migration path. And for failure to follow the
path with a good checklist, most typically the biggest problems are a
direct result of improper migration of the user data in quasi-system
user libraries, primarily QUSRSYS and QSYS2. As such my guess is,

that

rather than anything properly termed metadata being at issue, the

issue

is user data. Although it is called /user data/ because it was

supplied

by the user\operator to an application on the server, on another
platform it might be called instead, /application data/; where in this
case, the "application" is the OS.

Regards, Chuck

Ingvaldson, Scott wrote:

Additional information from John:

When BBACKUP was used, ENDSBS OPTION(*IMMED) preceeded BBACKUP. The
commands used by BBACKUP are:

SAVSYS DEV(TAP35) ENDOPT(*LEAVE) SAVLIB LIB(*NONSYS) DEV(TAP35)
ENDOPT(*LEAVE) ACCPTH(*YES)
SAVDLO DLO(*ALL) DEV(TAP35) ENDOPT(*LEAVE)
SAV DEV('/QSYS.LIB/TAP35.DEVD')
OBJ(('/*') ('/QSYS.LIB' *OMIT) ('/QDLS' *OMIT) ('/QNTC' *OMIT))
ENDOPT(*UNLOAD) UPDHST(*YES)

The SA attempted to restore from 820 (?) to 520. I was not present
when he did this. All he offered was that the metadata was not
saved by the above commands. I asked what was included in the
metadata, and got no answer. When I showed him a page from
infocenter detailing the processes used by option 21, he stated
that *something* is different.

Stated that he had been on the phone with IBM for weeks.

Old box was v5r2 and new box is at v5r4. I have NO idea what was
loaded on the new box.

All of this is to do DR planning at some point. He even stated that
option 21 was also non functional. But he quickly moved on. This
makes absolutely no sense to me.

Does any of this help? Any additional information that I might be
able to dig up that could be worthwhile?

Our mutual supervisor has asked me to contact IBM support for
clarification. I would dearly like the call to be worthwhile. But,
I already see that I am missing a considerable level of detail. For
starters, what did he do, on what kind of system.

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