Setting up a New iSeries

[PaulaJ]

We are expecting our new iSeries in June. We are currently on a shared box that we do not control. Does anyone have any suggestions/advice for transferring or copying all of the User Profiles, Device Descriptions, System related objects to the new box? The software move will be handled by a third party, but the system stuff is all ours.

 

[koresnordic]

Are the going to be on the same os level? If so then on the save menu, save everything but the system libraries and restore onto your new box.



Graham

 

[PaulaJ]

Don't Know. Good Question. Since we are currently sharing a box with other companies, we cannot just copy QSYS and QGPL, etc. If we have to recreate our own user profiles and device descriptions, I believe we can but was looking for advice on an easy method. Also, any suggestions that have worked well for setting up group/individual profiles. Which levels of authority to apply at what level, etc. Just fishing here, thanks for your reply.

 

[iSeriesCodePoet]

I created a basic RPG/CL that mass adds users to the system. I use this when I have to add more than a couple users at a time. You could do something like that. Create an excel file that has all of your users settings added. Then create a PF that can be used to upload the data into then have the RPG program read the file and setup the user. The program took me about 20 mins to write.

As far as the other settings. I think print screens and time. We have all of our printers set up as RMTWTRs not devices (set up in CRTOUTQ).

iSeriesCodePoet
IBM iSeries (AS/400) Programmer

Want to have all your bookmarks in one spot?

http://www.koldark.net/bookmark4u/

 

[flapeyre]

Better yet, why not do a DSPUSRPRF to an outfile, save that and restore it to the new system, edit it to weed out the profiles that are not yours, and drive a CL that does a CRTUSRPRF with the same parameters.

For the devices:

Create a blank member RESTORE in your_lib/QCLSRC.

Run this command:
RTVCFGSRC CFGD(*ALL) CFGTYPE(*ALL) SRCFILE(your_lib/QCLSRC) SRCMBR(RESTORE) MBROPT(*ADD) TEXT(*BLANK)

Again, edit the file to weed out the devices you don't need. Restore to your new box, add PGM and ENDPGM statements, compile, and run, and all your devices should be recreated exactly as they were. (I'd exclude the QPADEVxxxx devices, if you use them; let the new box create them as needed).



"When once you have tasted flight, you will forever walk the Earth with your eyes turned skyward, for here you have been, and there you will always long to return."

--Leonardo da Vinci

 

[PaulaJ]

You are all wonderful. That is exactly the type of info I was looking for. Anyone else with any words of wisdom?

 

[flapeyre]

Just a word of caution: Create the devices before you re-create the profiles, because there is a default printer parameter in the profile. That burned us once; somebody deleted a printer device, and some users were unable to sign on.


"When once you have tasted flight, you will forever walk the Earth with your eyes turned skyward, for here you have been, and there you will always long to return."

--Leonardo da Vinci

 

[flapeyre]

Just thought of something else. RTVCFGSTC does not do anything with output queues. You may have to do those manually - look at the Work with OUTQ Description (WRKOUTQD) command.


"When once you have tasted flight, you will forever walk the Earth with your eyes turned skyward, for here you have been, and there you will always long to return."

--Leonardo da Vinci

 

[PaulaJ]

I am setting up the CL suggested to auto create the user profiles. We have decided to do it from scratch as we want to change the usernames and group assignments. However, how do I test my CL? Doesn't the CRTUSRPRF automatically put the profile in QSYS? I would be testing on our current box and the profiles will have different usernames. I am hesitant to run a CL without testing it, but don't want to interfere with any on-going production. What do you think?

 

[flapeyre]

How about renaming the output from DSPUSRPRF, copying 2 or 3 records to the a file original file name, and edit the new file, changing the user profile names to "TEST01", "TEST02", and "TEST03" (or whatever). Check those profiles to see if it's got what you need. If sucessful, delete the new file and the dummy profiles, and rename the original file back to the correct name, and you're good to go.

One other thing: you are not saving any password information from the old profiles, so everybody has to have a default password. Code the CRTUSRPRF command in your CL with the hard-coded parameters PASSWORD(your_default_value_here)[, and PWDEXP(*YES) (to force them to change their password at the first sign-on).

This is one of those things where a full-blown test can't be done (unless you have a dedicated machine).


"When once you have tasted flight, you will forever walk the Earth with your eyes turned skyward, for here you have been, and there you will always long to return."

--Leonardo da Vinci

 

[PaulaJ]

That is kind of what I figured. I won't be using the DSPUSRPRF output, however. I'm hardcoding the New Profiles to our new naming conventions in the CL. At least this way it will all be documented as what was originally put on the system and we'll just have to adjust what doesn't come out correctly. Thanks for the info, I appreciate you getting back to me so quickly.