Re: Copying File Structures

The generated\retrieved DDL is likely not an option [for a commercial product derived from DDS source], given the likelihood that much of a DDS LF could not be matched in SQL for typical RLA [Row Level Access]. Some nuances even for DDS PF would probably also be at least difficult [e.g. nuances in defaults or ??], if not also problematic [e.g. editing] for various reasons. In that case a scripted create from DDS source is the effective equivalent, to what is IMO the best procedure [create from DDL] to effect the migration of the /structure/ of the database. I suppose depending on the customization capabilities, the sfw provider may even provide a script to [re]generate the database from source or from existing objects; scripted to handle known dependencies, rather than someone having to analyze dependencies in order to generate the script themselves. I believe CPYLIB is about the most generic, with caveats according to its implementation via the CRTDUPOBJ; except maybe the move library API, but that is a very limited application, to move versus copy to an alternate ASP.

Although I provided design input to a generic function for duplicating SQL SCHEMA, I do not think it ever went anywhere, even though I believe the original intent was limited to only SQL objects. The function is available and implemented for a database, typically as part of change management [development build of either test or production], part of an install, or part of a HA copy function; some of those, may even be implemented in part on S/R.

For the DDS case, either the save/restore or CRTDUPOBJ are options, each with their own merits and potential problems. The S/R maintains ownership but not private authorities [until V6R1 with the PVTAUT parameter], whereas the DUP maintains private authorities but not ownership; DUP is easiest if all duplicated objects are owned by the same user and can then be requested by that [signed-on, submitted-as, or switched-to] user. The DUP introduces a new library name; problematic for, or at least complicating dependencies spanning libraries. DUP still needs to be followed by S/R for move to an alternate LPAR, which again has the private authority issue, and restores to the old library name as a new library name [though IMO better than RNMOBJ of a library]. The DUP allows easier method to effect no-data by DATA(*NO), but RI [Referential Integrity] is still an issue; may be best to disable all RI before duplicating, then enable afterward.? The S/R enables no-data but via no members which can be very problematic. Note: journaling is a potential issue; in both S/R and DUP methods, sometimes everything turning out as expected, even if only by accident, but best to plan the journaling along with the authority, ownership, and [trg\cst\lf\alias] dependency concerns.

Regards, Chuck

vhamberg wrote:

Maybe you said this below - he can retrieve the generation source
for all the files using Navigator's database piece - even though
everything he has was probably created from DDS - and it's a
commercial product - BPCS - he is working against.
Any issues in that light?

CRPence wrote:

IMO the best procedure to effect a migration of the /structure/ of the database [as defined by the DDL] is to run the DDL creation scripts on the target system. Generate the DDL if not already existing in scripts, then run those scripts.
Beyond that, the following may be informative for alternatives; esp. where the files are DDS created without RI and/or triggers.