Best practice - creating new WORLD environment

[Frosty the Coder]

I want to create a new environment for WORLD,
in preparation for loading to a new 400.

What is the best approach?
I don't have enough space to CPYLIB.
I want to create the data/common libraries and copy the objects.

NOW - my stupid question of the day (SQOTD) - LOGICAL FILES:
In my to environment do I:
Create all the LFs over blank PFs? (manually by compiling them)
Copy the data from the PFs, and create the LFs in the library
(manually by compiling them)
Copy the PFs AND LFs from source to target?

I want to ensure that TEST/*LFs are built over TEST/*PFs,
and I'd PREFER not to be doing a lot of CRTLFs.

I can't remember which sequence required the least work while providing correct results.

Thanks,
Frosty

 

[Fred Hargett]

I think the best might be to restore the JDFDATA library to the new test library. the JDFDATA library files have some data but not much. this will stop any level checks from program obj and data obj having different dates
we use the rstlib command and put the restore to library as the new library name.

Fred

 

[dhashimura]

Frosty,

crtdupobj *all data(*no)
MIGHT do what you need.

debi

 

[Frosty the Coder]

I had considered that, but opted on the CRTDUPOBJ (which worked (with effort).
I'm not onsite so getting the tape, getting an operator, getting the opportunity were difficulties.

Thanks for the suggestion.
Keep on posting!
Frosty

 

[EmmanuelW]

I know I'm a little late to this, but one potential gotcha from using the CRTDUPOBJ approach is that the command default is TRG(*YES). So, if you've set up triggers using DBAM, your test library's duplicated objects will also fire those triggers, assuming you left the trigger parameter to its default value.

Quick way to check this is to use the PRTTRGPGM over your test libraries, and if need be, RMVPFTRG.

Cheers,

Emmanuel