How to Migrate ver 4.3 to ver 4.4

[Guest.Visitor]

We will soon be replacing one of our old AS/400s model 600 (ver 4.3) to a new model 720 (ver 4.4). I have been tasked to oversee the migration of it's production environment to the new box. Unfortunately, I cannot find any literature on the subject. IBM's website keeps mentioning that I should look at the book System Upgrade Road Map (Risc to Risc), however, whenever I clink to any links refering to the book, all I get are "Book not found" messages. Can anyone help me?

[Guest.Visitor]

Ricardo, I don't know what the Road Map has to say about Risc to Risc. What I would do is run the commands; SAVLIB *ALLUSR, SAVSECDTA, SAVCFG, SAVDLO, SAV (ifs). On the restores do a RSTLIB *ALLUSR and omit QGPL and QUSRSYS. Restore these separately because you do not want to overlay the IBM objects in the new libs for 4.4. You have 2 options to bring the 4.3 objects into the new 4.4 libs. First you can do a RSTOBJ restoring only *NEW objects (OPTION(*NEW)). Second, you can restore both libs to newly created libs like QGPL43, delete the IBM objects, copy what's left into the respective target lib. For the other save commands simply execute the normal restore commands (RSTUSRPRF, RSTCFG, RSTDLO, RST (ifs), RSTAUT). Check your Network Attributes after the RSTCFG. They may have changed. HTH Regards. Jack

[nycsusan@hotmail.com]

Ricardo, Go here: http://publib.boulder.ibm.com/html/as400/online/v4r4eng.htm then select the following: Category bookshelves for v4r4 1. Release Information Overview AS/400 Information Center Overview See What's New

[cwscholbe@dstsystems.com]

Make sure that you restore the USRPRF's and SECDTA first. That way you avoid problems with authorities to objects as you restore them. If you don't do this first, then all objects may be owned by QDFTOWN or worse by the User who is performing the Restore. Good Luck, it shouldn't be tooooo painful. Chris (keeping his fingers crossed for Ricardo) Scholbe

[nycsusan@hotmail.com]

Ricardo, I just remembered something. When we upgraged to v4r4, we had problems with embedded SQL that required a PTF to fix. If you use embedded SQL in RPG or COBOL programs, be sure to apply the appropriate PTF to your machine before running them.

[cwscholbe@dstsystems.com]

The "good" news is that the "newest" CUM just came out in September (C0252440)

[Guest.Visitor]

We recently went from a 510 on V4R3 to a 720 on V4R4 and the Risc to Risc upgrade roadmap insisted that the 510 be upgraded to V4R4 prior to the hardware upgrade. Our hardware upgrade included new DASD so I did not follow the roadmap. I loaded V4R4 on the new box, saved all non-system stuff on the 510 and restored on the 720. If your hardware upgrade involves new DASD, you can save some time by not following the roadmap, if you are migrating your existing DASD you had better follow the roadmap. There is a chapter in the backup and recovery guide that deals specifically with save/restore across OS/400 versions.

[Guest.Visitor]

Can you point me to where this roadmap may be found?

[Guest.Visitor]

Jack, Thanks for the info. But I already know this stuff. They will move most of the stuff, but some work still needs to be done. Time constraints are really tight! A few hours delay could spell the difference between success and failure. I am looking for something more thorough.

[Guest.Visitor]

Susan, Sorry... not there either.

[Guest.Visitor]

Susan, We don't use imbeded SQL. Thanks anyway.

[Guest.Visitor]

The manual is number SA41-5155-03. There is a pointer to it in the AS/400 V4R4 online library, but today it says that the book cannot be found. You can order hardcopy from IBM like I did before I found out it was usually available online.

[Guest.Visitor]

There is no way I can get the hardcopy on time. Thanks anyway.

[Guest.Visitor]

Looks like the book is just not available anywhere in the web. It's too late now to order a hard copy. Guess I am on my own. I'll just pack some extra-strength coffee on my flight to Cebu City. Thanks everybody.

[Guest.Visitor]

Ricardo, I hope the flight is not too turbulent !!!. Anyway I found the RISC to RISC Upgrade at <a > href="http://publib.boulder.ibm.com/pubs/pdfs/as400/V4R4PDF/QB3AES03.PDF"> PDF Version </a>. I just downloaded it to make sure it was there. David

[Guest.Visitor]

Ricardo, If this helps : I just did a double upgrade in one weekend : V3R7M0 to V4R3M0 and immediately after that we went from V4R3M0 to v4r4m0. I just used the Software-installation manual and the additional documents you get from IBM(Installation-considerations, PTF-instructions, etc.). We had no problems at all, except for some small glitches with CA/400. Apparently in our new configuration we had to go to CA/Express. That was about it. This is a machine with R/DARS-software installed, it uses tape-libraries and lots of EDI-processes, etcetera. All of it worked fine. So I really wouldn't know why you'd need any other manuals. HTH, Rob.

[Guest.Visitor]

Rob, You were upgrading the OS versions of just one machine. My problem is in migrating from one box (v4r3) to another box (v4r4). Actually, migration is not new to me. Only problem is that I have never done this before at an OS level higher than v4r2. There are a lot of new stuff in the machine, so I have to make double sure that nothing is missed (from the old box) or lost/deleted (in the new box). My clients always require complete transfers within budgeted time (usually 2 days). When they say "complete", they mean that the old box has been wheeled out, the new box is running in the space vacated by the old box, and the users don't notice anything (except the much improved performance). You think it's easy? How about moving several gigabytes of spool files across? Nope, it's not in the system backup. If you have not planned and programmed for this, chances are, you can't. There are a lot of critical stuff that cannot be moved across with just a simple save and restore operation. I learned this the very, very, hard way. Don't make the same mistake!

[Guest.Visitor]

Thank you David. I got it, and what a letdown! The book dwells mostly on the hardware side. The only thing it says about migration is to employ some of their service offerings. After so many hours of searching for the book... this is all it has to say on migration! This really burns me up!

[Guest.Visitor]

Ricardo, Thanks for the advise but I must have done about 500+ installations in the last 10 years, straightforward ones as well as CISC-RISC. I used to do the CISC-RISC coordination in the Netherlands when I was hired by IBM. Now please do not regard this as complete information ! But here's a bit of information that will be useful. The way I see it, the problem that you have is twofold : 1. Going to new hardware. 2. Going from v4r3 to v4r4. As for point 1, this is where the CISC-RISC manual is useful because it explains how to restore to a new machine. For instance, it explains the importance of doing a RSTCFG SRM(*NONE). If you don't, all resourcenames on your new AS/400s will be changed to the old machines values. Of course I don't have to tell you what hardware to check, to see if it's all there etcetera etcetera. As for point 2, the easiest way I have used for this is to reload your backup on the new machine and then re-installing v4r4 over that. I understand that you will not have the time to do so. In that case keep in mind that you cannot just restore QUSRSYS(nor QGPL I believe). If you do so, several OS/400-components will be in error or incompatible. Basically, what I did was to reload the SAVE/21 on the new machine(exluding the IBM-libraries), then restore QUSRSYS/QGPL, and then re-install only those components that were incompatible after the restore-operation. And of course re-apply the fixes for those components. HTH, Rob.

[Guest.Visitor]

I forgot : one can also first install v4r4 on the old box and then move the whole lot to the new machine(RSTCFG SRM=*NONE !). But I take it that this is not possible in your case ? Rob.

[Guest.Visitor]

Rob, You are right on both points (new hardware and v4r3 to v4r4). My current plan is similar to your last recommended procedure, which is to reload the SAVE/21 on the new machine (excluding IBM-libraries). We differ in that I do not replace components in QUSRSYS/QGPL. In library QUSRSYS, the system files are interlinked by multiple logical files and contain user information (such as mail/system directories). If I follow your procedure, I face a gauntlet of restore failures and lose some or all of the mail/system directory information (which in turn may corrupt the Mail/DLO ownerships). Following is an outline of my (untested) procedure. Any comments or constructive criticisms are welcome. <pre> I. In old machine: A. Print System Information (PRTSYSINF) B. End Subsystems C. Disconnet UPS comms line D. Save All Spools (in-house utility) E. Save Directory Entries (in-house utility) F. SAVE/21 II. In new machine A. Restore Utilities library (for migration programs) B. Change Network Attributes (pre-written CL program) C. Power-down and perform manual-IPL D. Change DST passwords E. Power-down and perform normal-IPL F. End Subsystems and CHGMSGQ QSYSOPR DLVRY(*BREAK) SEV(70) G. Change (using pre-written CL Program): 1. System Values 2. Configuration Lists 3. Auto-Reply Lists 4. Custom changes to print files QPRINT, QSYSPRT, etc. H. Configure TCP/IP (pre-written CL program) I. Move QSTRUP program from QSYS to a work library J. Restore User Profiles K. Restore Configurations with SRM(*NONE) L. Restore All Directory Entries (in-house utility) M. INZSYS N. Change Users QUSER/QSYSOPR to MAXSTG(*NOMAX) O. Restore from SAVE/21 (NOTE: Specify ALWOBJDIF(*ALL) whenever allowed) 1. RSTLIB *ALLUSR OMITLIB(QGPL QGPL38 QUSRSYS QSNX) 2. RSTOBJ *ALL SAVLIB(QGPL) OPTION(*NEW) 3. RSTOBJ *ALL SAVLIB(QUSRSYS) OPTION(*NEW) 4. RSTDLO DLO(*ALL) SAVFLR(*ANY) 5. RSTAUT P. Change QSECOFR password Q. Retrieve CL source of original QSTRUP program in work library R. Compile in-house QSTRUP program to QSYS S. Restore All Spools (in-house utility) T. Apply all third-party product license keys U. Check/Test/Resolve 1. QSYSOPR messages 2. Config of ETHLINE vs comms resource names 3. Distribution Queues 4. System information (from old box) 5. QSTRUP source program (old versus new) 6. Applications access and operations 7. Programming/Test environments V. If Everything OK, 1. Switch over all hardware from old to new box 2. Re-IPL 3. Re-test everything W. If Not OK, 1. Shutdown new box 2. Reconnect all hardware back to old box 3. Re-IPL old box 4. Go home and prepare letter of apology </pre>

[Guest.Visitor]

Ricardo, This plan looks good but I still have reservations about the QUSRSYS *NEW bit. The thing is that I had to do it just as you describe serveral years ago, and I spent a weekend re-linking all the database-relationships. We 'only' lost about two days of OV/400-mail. When I talked to IBM a week or so later they flatly denied that my solution was possible. When I told them that we had already done it and that it worked, they were sorta speechless... 8-) The problem lies in the fact that you only restore the *NEW-objects from the old QUSRSYS. You do however, restore the userprofiles etcetera. There is no documentation available about how exactly QUSRSYS is built up. You won't find it in any manual(not complete anyway). However, it turns out to be loaded with cross-references(as you already stated). These crossreferences are NOT just database-references. For instance, there are databasefiles in QUSRSYS that link the userprofiles to other parts of OS/400 like OV/400-enrollments, directory-entries, Authorizationlistholders, etcetera. And as I said : noone but IBM and a handful of other people around the world know what all the dependencies are. This is the reason why I advised you earlier to restore QUSRSYS and QGPL, and then reinstall these two OS/400-options plus PTF's. The only problem I can see with that is this approach is the fact that the PTF-level-indicators are in QGPL. So if you restore the library, you will lose PTF level-id information. This can/will lead to HuGe problems ! Hence my advise to load everything from the old machine onto the new one(effectively scratching the new machine), and then reinstall then IBM-software for V4R4 plus PTF's. The installationprocess will then automatically process all the old files in QUSRSYS and QGPL while retaining the information. It may sound like a lot of work but actually it isn't. Another advantage you have if you use this approach, is that you will start with a clean system. So any errors that people may have made in the past while installing the system will be removed automatically. BTW : Do you have a date for this operation yet ? HTH, Rob.

[Guest.Visitor]

Rob, Actually, I was scheduled to leave this morning. Fortunately, we got a frantic call last night from the client requesting a postponement to next weekend. This gives me more time to flesh out the migration routines with plenty to spare for some quality time with my wife. Now about the plan: I don't think this QUSRSYS/QGPL *NEW-objects bit is going to cause any serious problems. All the critical objects (user-ids, configurations, and directories) have already been restored. Only a few "additional" objects are restored. Nothing is lost or deleted in these operations. These additional objects are either user-created objects or old system objects that are obviously no longer in use. As a precaution, I will specify Output(*PRINT) to the RSTOBJ commands. If these additional objects do cause problems, I will be able to identify and delete them (since they weren't originally there in the first place, the operating system should not need them to run properly, right?). BTW: You cannot restore v4r3 over v4r4. To do so would cause the restore program to delete/replace itself! The correct (and faster!) way to do this is to perform a scratch-install using the v4r3 system backup tapes.

[Guest.Visitor]

Ricardo, Always nice to have a bit more preparationtime ;-) ***BTW: You cannot restore v4r3 over v4r4. To do so would cause the restore program to delete/replace itself! The correct (and faster!) way to do this is to perform a scratch-install using the v4r3 system backup tapes.*** As the program performing the operation is in working storage, you could get problems AFTER the restore yes. But as programs are in QSYS(and you can't restore that one) it should be no problem. Maybe the old QUSRSYS-objects could cause problems, but as you need to install v4r4 QUSRSYS immediately after the restore of the old software this problem is solved in no time( because it's not a restore, it's an installation). Actually, the catch is : you CAN restore QUSRSYS but normally you should never do it except for during operations like this one. ***I don't think this QUSRSYS/QGPL *NEW-objects bit is going to cause any serious problems. All the critical objects (user-ids, configurations, and directories) have already been restored. Only a few "additional" objects are restored. Nothing is lost or deleted in these operations.*** Sorry, didn't make myself clear here : I did not mean the objects, I meant to say that there is cross-referenced info in the files in QUSRSYS that is related to info in other files. This info in turn refers to *system-objects in other libraries. I think that your solution will work, just not 100 % sure. Just make sure that all the userprofiles, configuration, RSTCFG, etc. have been restored before you do QUSRSYS *NEW. ***These additional objects are either user-created objects or old system objects that are obviously no longer in use.*** That's why it may work in this case. ***As a precaution, I will specify Output(*PRINT) to the RSTOBJ commands. If these additional objects do cause problems, I will be able to identify and delete them (since they weren't originally there in the first place, the operating system should not need them to run properly, right?).*** Right. You might even check if they're being used at all(DSPCMDUSG). If not they can be deleted in, let's say a month or so. CU, Rob.

[Guest.Visitor]

Section 4.1.2.3 of the V4R3 Backup and Recovery Guide provides all of the detail you need to save your non-sys V4R3 stuff and restore it to a V4R4 system. These are the instructions we followed when we upgraded from a 510 on V4R3 to a 720 on V4R4. Then we just ran restores corresponding to the saves in that section. Last thing was a RSTAUT USRPRF(*ALL).

[Guest.Visitor]

Rob, Oh no! I was hoping you would refute me and point out something that I missed (cuz, as you said, I was sure it would work, just not 100% sure.) We are in agreement then! Thank you for your input. I will post the results of the migration when I am through. It would make a fitting end for this thread and might possibly help someone else in this forum. Until then, CU too. Ric

[Guest.Visitor]

Hello Kim, If you are migrating from v4r3 to v4r4, you should look at the v4r4 version of the manual. Good thing the save/restore procedures were very similar, so you probably did not encounter any serious problem. I have read the whole chapter for both versions last week. I was not satisfied with the available information. I therefore posted the outline of my intended procedure so that everybody in the forum (specially Rob) can help me thresh out any problems. To tell you the truth, the procedure was developed based on much of the information derived from that specific chapter you mentioned (with some modifications and additions). Some changes: 1. Use of option 21 of menu SAVE The manual mentioned so many save operations. I thought it wiser to simply get everything in one operation. This reduces operator interventions (and human errors). This also ensures that I do not miss any libraries. What if someone created a Q* library without my knowledge? Anyway, the IBM libraries are relatively small and the additional save time is not significant. 2. Save/restore spools As you know, spools are not migrated by IBM's save/restore operations. My clients insist that they be migrated. I therefore have to include them in my procedure. 3. Omission of restore for QA* files in QGPL I already have CL programs for setting up the client's system directories, TCP/IP configurations, and distribution services. So why bother? 4. RSTAUT is not the last restore operation It may not be the last step, but it is run after all the major IBM restore operations. I believe this will have no impact in the restoration of spools. I will keep this in mind with regards to the additional objects restored to QGPL and QUSRSYS. I hope I have explained everything to your satisfaction. Please feel free to voice out any reservations or disagreements. If you know something I don't, please share it.

[Guest.Visitor]

O.K.dokie ! Look forward to hearing the results. I will wait until you respond to this thread again unless I come up with some more info. Later, Rob.

[Guest.Visitor]

Ricardo, I am in the middle of moving a v4r4/510-system to a 740 with LPAR. As you said you cannot save spoolfiles with the standard IBM-commands. As my customer wants his spoolfiles to be moved to the new machine too, we have come up with the following 'plan' : 1. Migrate everything to the new box(except the spoolfiles obviously). 2. Configure the new AS/400 to mirror the old box(IP-address, systemname, etc). 3. Change the systemname and the IP-address on the old 510. 4. Use SNDNETSPLF(or rather option 1 on the WRKSPLF-command) to send all required spoolfiles from the 510 to the new machine. 5. Store/print/whatever the spoolfiles on the new machine. A small program to automate the SNDNETSPLF would be nice of course ;-). HTH, Rob.

[Guest.Visitor]

Rob, Sounds like a quick and easy solution. The only drawback would be that the transfer rate may not be fast enough. For a large installation with significant spooling requirements, you may wind up waiting several days for all the sent spools to arrive. Perhaps you should take a look at library QSPL to get a rough idea of the magnitude of the transfer. Just remember to first run RCLSPLSTG *NONE.

[Guest.Visitor]

OK! The results are in! YES, it works, with only a few minor hitches: 1. Some printer definitions were not restored in RSTCFG. (cause is unknown). 2. Some system values were not updated. 3. Scheduled job entries were not loaded. 4. Restore of new QUSRSYS objects loaded some undesirables The system values that was not updated had to do with the UPS monitoring program and message queue. This was fixed by recreating the UPS message queue in library QSYS and doing the update again after the RSTLIB *ALLUSR. The scheduled job entries could not be loaded because the programs and commands did not yet exist. This was fixed by rerunning the load after the RSTLIB *ALLUSR. Restoration to QUSRSYS got me some Q* objects (mostly files and journal receivers). I won't bother with the files, but I am still considering whether to delete the journal receivers or not. BTW: I cheated (just a little). I did not do a full DLO restore. Instead, before the SAVLIB *ALLUSR, I ran SAVDLO *ALL DEV(*SAVF) SAVF(mylib/QDLS) OMITFLR(Q*). After the user data were restored, it was a simple matter to RSTDLO from the save file.