×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
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.
midrange.com
