If your files are journaled you can always use them to obtain your data. If you haven't worked with them before it will take a little bit of effort on your part to learn how to retrieve journal entries. It won't be wasted effort though.
In fact, journal entries may be the best place for you to start your troubleshooting process. In the very least you can determine which job, program and user created a data error.
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Don Wereschuk
Sent: Friday, September 06, 2013 7:45 AM
To: Midrange Systems Technical Discussion
Subject: RE: Data Transfer
I think we're going in a totally different direction with this. I'm not trying to do Disaster Recovery or migration to new systems or upgrades etc... We have 3 boxes all running 6.1 with no need to upgrade further at this time. 1 box is used for production, 1 box is used as a mirror for the production box in case all hell breaks loose, and 1 box is used for development. We also try to do any problem investigation on the development box so as not to interfere with production and it makes things easier when you can use data that's only a few hours old as opposed to 2 or 3 weeks old. I'm usually trouble shooting problems that happened yesterday and so it would be nice to use yesterdays data for this.
<< Basically all that SAVRSTLIB does is
a-Save the library to a save file
b-transmit the library
c-Restore the library
Basically all I really want to do is
a-Save the library to a save file
b-transmit the library
c-Restore the library
a & c are not my concern. Saving to a save file and restoring doesn't interfere with production. I would do the transfer during off hours. I have done the save during production and there is no impact and the restore is on a different box so that is a moot point. I have plenty of room on both boxes so that also is not a concern. Point b is my problem. I'm trying to utilize some form of transmitting a large volume of data (100 GB) between 2 boxes (not 2 LPARs on 1 box or any other combination) in the shortest length of time. FTP takes too long as by the time it finishes transferring the data it's time to start the next save & transfer. Rob, I'm sorry I haven't tried multiple FTPs at the same time yet (as you suggested) so I can't report on that. (I do have that on my to-do list). It appears that a SAVRSTOBJ would be the best possible solution for me. Now all I have to do is get the 2 boxes talking to each other and I'm all set.
Thanks everyone for all the information and suggestions.
******************************************
Don Wereschuk
ISD - Programmer/Analyst
Simcoe Parts Service Inc.
Phone: 705-435-7814 Ex: 302
Fax: 705-435-5029
mailto:dwereschuk@xxxxxxxxxxxxxxx
******************************************
If I'd have done what I said I should have done, then I'd be sitting here saying I should have done what I did do.
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
Sent: Friday, September 06, 2013 9:26 AM
To: Midrange Systems Technical Discussion
Subject: Re: Data Transfer
I am thinking you'd be better off with save/restore for a number of reasons.
Number 1: Do you really want to rename your new system (or your old system)?
Number 2: If you really are a small shop with a single box do you really want to learn all this stuff about SNADS communication just to do a data migration? Keeping in mind that SNADS has no future and it's all in TCP nowadays. Basically all that SAVRSTLIB does is
a-Save the library to a save file
b-transmit the library
c-Restore the library
Number 3: Do you have the space on the old system to contain the space for the save file too?
And my biggest reason: If it is possible, and it may not be if your system is really old and doesn't support newer OS, I think it is best to migrate your system to the newest OS and then restore that using steps
like:
http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/topic/rzarm/rzarmsteps2.htm
If your system is too old then a compromise might be finding out the highest level your old system will support and the lowest level your new system will support. For example I upgraded a 270 to v5r4M5, restored that on a power 6, upgraded it to 6.1 (and when 7.1 came out, 7.1).
If your old system truly cannot upgrade to a level that is supported even as a temporary intermediate between the two then what you are doing is a data migration as outlined in:
http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/topic/rzamc/rzamc1.htm
If you are running such an old system, and you only have a single system, then I'll hazard a guess that it's been awhile since you've done your last upgrade and you may be a bit rusty at it. This is where it may behoove you to contract it out to people who do this all the time. People like Pete Massiello or Larry Bolhuis. I wouldn't mind a little weekend work doing this kind of stuff myself. I have 11 lpars of IBM i 7.1 running on three racks. Granted, I jump on the latest OS ASAP so with 7.1 having come out over two years ago it's been awhile since my last upgrade (but not my last install).
Too many people think they can restore a few libraries and stuff and that will work. What little time they save doing this is often spent by weeks of cleaning up 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: <jvoris@xxxxxxxxxxx>
To: midrange-l@xxxxxxxxxxxx,
Date: 09/06/2013 08:55 AM
Subject: Data Transfer
Sent by: midrange-l-bounces@xxxxxxxxxxxx
Our shop weekly does SAVRSTLIB . . .
The other problem with ftp is if sending a savf - you still have to
restore the savf!
http://pic.dhe.ibm.com/infocenter/iseries/v6r1m0/index.jsp?topic=/cl/savrstlib.htm
This is some great info on a command I was unaware of. I did know about
the IBM command CPYLIB (copy onto same system) but now my eyes are open
and I see an actual application for the SAVRSTLIB (RMTLOCNAME) command
for even small shops with a single box.
When buying a new box and having to migrate data over to it for SOX
validation tests, this command does simplify the effort, eliminate tape
saves and restores of data, and could make the whole effort fairly
painless. . . . Tanx, guys.
midrange.com
