|
Action |
DEVL |
TEST |
PROD |
Total |
|---|---|---|---|---|
|
Start with no records defined. |
|
|
|
|
|
Define 10 IRDs and 10 ORDs. |
10 |
|
|
10 |
|
Commit records to TEST version. |
|
10 |
|
10 |
|
Copy TEST version. |
10 |
10 |
|
20 |
|
Commit DEVELOPMENT records to PROD. |
|
10 |
10 |
20 |
|
Copy PROD version. |
10 |
10 |
10 |
30 |
These descriptions correspond to the six actions in the table above:
Suppose these tables are empty when you start using DataManager.
The records you input using the online facility always belong to the DEVELOPMENT version.
COMMIT DM TEST moves all your DEVELOPMENT IRDs to the REAL version and all your DEVELOPMENT ORDs to the TEST version. Now there are no DEVELOPMENT records. CAKSLOAD production runs can now begin using the TEST version.
You want to continue refining your definitions, so COPY DM TEST REFRESH copies your TEST and REAL definitions back to the DEVELOPMENT version. You do this because only the DEVELOPMENT version can be edited.
When you've finished refining these definitions, commit them for production (the PROD version) using COMMIT DM PROD. The refined IRDs replace the old REAL definitions and there are no more records in the DEVELOPMENT version. Now you can run production jobs from either the PROD or TEST version.
To further refine your definitions, copy the latest version (PROD) using COPY DM PROD REFRESH. This copies your latest definitions into the DEVELOPMENT version so you can continue editing.
This example illustrates the advantages of keeping a log of COMMIT and COPY processing.
| Copyright © 2011 CA. All rights reserved. | Tell Technical Publications how we can improve this information |