The Duplicate Changed Objects command is intended for the case where
you are maintaining an application on one system (the 'source') and
need to keep a duplicate of the application up to date on another
system (the 'target'). Both the source and target could be within
the same machine room or at different physical locations. You may
also have multiple target systems.
Note that the same concept can exist within a single system where a
Test library is used for making changes and then the changed objects
should be placed into production by duplicating the objects.
Regardless of where the source and target systems are located, assume
that you periodically want to capture just the objects that have
changed and integrate them on the target system.
DUPCHGOBJ does the first part of this process and that is to
duplicate the objects that have changed in one library into a
separate library. A tool such as MRGOBJ could then be used on the
target system to do the second part of the process.
A typical DUPCHGOBJ command would be:
DUPCHGOBJ FROMLIB(xxx) TOLIB(yyy) CHGDATE(010196)
This will cause the changed objects (except for Data Base files and
Data Areas) in the FROMLIB to be duplicated to the TOLIB. Any
objects changed on or after that date would be duplicated.
For example, if you had changed 3 programs and a job description, the
new versions of the objects would be placed in the To library.
If versions of the same object exist in the To library, they are
automatically deleted first. A spooled file is output describing
what has occurred.
Options exist to handle special objects:
** Data Base networks (physical and logical files)
** Source members
** Data areas
The handling of the normal object types differs from the special
object types. See the later detail discussions.
DUPCHGOBJ assumes you have proper authority to delete and duplicate
objects.
Save/Restore approach
---------------------
In some cases, a simple Save/Restore based on change dates will be
adequate to keep the target system in synch. However, as the change
process becomes complicated, an approach which uses a separate
library for changes can be a significant advantage.
For example:
** What happens to the data that exists on the target system? Do
you want it replaced by data from the source system or should
the target system retain its own data.
** What happens if ownership changes occur between the source and
the target. A Restore option will allow for this, but it may
not be anticipated in which case the Restore will fail.
Handling of the To library
--------------------------
The DUPCHGOBJ command is tolerant of what exists in the To library.
If an object already exists in the To library and the version in the
From library has met the change criteria of the CHGDATE parameter,
the version in the To library is deleted and then the duplication
occurs. If an object exists in the To library and the corresponding
From library object is not considered changed, the To version remains
unchanged.
Consequently, you can run DUPCHGOBJ on multiple days and change the
CHGDATE parameter to suit your needs. You can also place your own
objects in the To library and they will remain as is (assuming no
From version exists or it has not changed).
Normal object types (such as *PGM)
----------------------------------
The object information is read by using the outfile from DSPOBJD.
The 'last changed date' of the object is checked against the CHGDATE
parameter on the command (century support is automatic). A new
object will have the same date for both the 'create date' and the
'last change date'.
If the object has changed, a check is made if the object exists in
the To library. If so, the object is deleted in the To library.
CRTDUPOBJ is then used to duplicate from the From library to the To
library.
The spooled file will contain a print line for every object and
whether it is new or it replaced a version in the To library.
Data Base networks (non-source)
-------------------------------
If you want to duplicate the changed objects in a Data Base network,
specify DTAF(*YES) on DUPCHGOBJ.
The support is restricted to data base networks that reside in a
single library (All files in the network must be in the From
library).
The change date of the object is not a good choice for Data Base
files (non-source) versus normal object types. If data exists in the
files, the file is considered changed whenever the data is changed.
Therefore, the 'last source change date' stored in the file object is
used to determine that a change has recently been made.
There are cases where a file change has occurred because of CHGPF/LF
or the file has new control information that should be sent to the
target system. See the later discussion about how to force a data
base file to be considered changed.
If a LF is considered changed, DSPFD *ACCPTH is used to determine the
'based on' physical files.
If a PF is considered changed, DSPDBR is used to determine any
dependent logical files that will also need to be duplicated.
Any logical files that are part of a changed network are checked to
see if they exist in the To library and if so they are deleted. The
corresponding physical files in the To library are also considered
and deleted if they exist.
A 'net' list of physical files is then generated. If the same
physical file is used by multiple dependent logical files, it will
only be considered once.
The DUPDBN TAA Tool is then used to duplicate the data base network
(physical and dependent logicals) into the To library.
Note that any existing data is copied to the To library. It is
assumed that either no data exists or only a small amount of test
data or control information is in the file. You can control with the
MRGOBJ tool whether the data from your system should replace the data
on target system.
Duplication of logical files occurs by changing the name of the
current library on the library list to ensure that the proper 'based
on' physical is used. Because of this technique, the From library
cannot be a library in the system portion of the library list.
Source members
--------------
If you want to duplicate the changed source along with the changed
objects, specify SRCF(*YES) on DUPCHGOBJ.
When a source member is changed, the system changes the member 'last
change date' and the file 'last change date'.
DUPCHGOBJ checks each source file to determine if it has been
recently changed based on the CHGDATE parameter. If it has, a check
is made to ensure that the source file exists in the To library. If
not, it is created.
Each member is then checked to see if it has been recently changed.
If so, CPYSRCF is used to copy the member to the To library source
file. This has the effect of:
** Replacing any existing source (the member existed)
** Adding any new members (the member did not exist)
Note that the entire source file is not duplicated unless all members
meet the CHGDATE criteria.
Data Areas
----------
If you want to duplicate the changed Data Areas along with the
changed objects, specify DTAARA(*YES) on DUPCHGOBJ.
When CHGDTAARA is used (or a data area is changed by a HLL program),
the system considers the Data Area to be changed as of that date. If
the corresponding Data Area on the target system has unique data, you
may not want the data replaced with the data from the source system.
If DTAARA(*YES) is specified, any changed data areas will be
duplicated and a tool such as MRGOBJ will replace the data area on
the target system.
Forcing a Data Base network to be considered changed
----------------------------------------------------
Because DUPCHGOBJ looks at the 'last change of the source' that is
stored in the object form of the file, you must physically change the
object to force DUPCHGOBJ to duplicate the network.
There are situations where this technique will not be adequate. For
example, you may have a control file with data that should be
considered changed even though the source date has not changed. Or
you may make a change with CHGPF/LF which does not change the source
date or the file may not have any source. The following are some
solutions you may use:
** Use DUPDBN directly and name the Physical file. This is the
same support that DUPCHGOBJ uses internally. You must decide
for each file if you want to duplicate the data.
** Have a logical file that uses arrival sequence processing.
Cause the source change date to change (such as using SEU,
pressing F3 to access the Exit display, and enter 'Y' for
Create/Change member). Then re-create the logical file (using
arrival sequence will not cause any access paths to be built).
** Use the CHGOBJD2 Tool and change the 'last source change date'
to fit your needs.
Command parameters *CMD
------------------
FROMLIB The From library to be considered.
TOLIB The To library where the changed objects will be
duplicated to.
CHGDATE The change date to consider in job format. Century
support is automatic (years 00-39 are considered the
21st century). Any objects or members that have
been changed on or after the CHGDATE are considered
changed.
CHGTIME The change time to consider in hhmmss format. If
the CHGDATE from the command and the change date of
the object are the same, the CHGTIME is used to
determine if the object has changed.
DTAF A *YES/*NO parameter that determines if Data Base
networks will be considered. The default is *NO.
If *YES is specified, changed data base networks
will be duplicated including any data. The 'last
source change date' of the source used to create the
objects is used to determine if a change has
occurred.
The entire data base network must exist in the From
library.
SRCF A *YES/*NO parameter that determines if Data Base
source files/members will be considered. The
default is *NO. If *YES is specified, changed data
base members will be copied to the corresponding
source file in the To library.
DTAARA A *YES/*NO parameter that determines if data areas
will be considered. The default is *NO. If *YES is
specified, changed data areas will be duplicated to
the To library.
FROMSRCLIB The From Source Library to use. The default is
*FROMLIB to use the same library as specified for
the FROMLIB parameter.
Restrictions
------------
All data base files for a network must exist in the same From library
to be duplicated.
Duplication of logical files occurs by changing the name of the
current library on the library list to ensure that the proper 'based
on' physical is used. Because of this technique, the From library
cannot be a library in the system portion of the library list.
Some sub functions are performed by other TAA Tools such as DLTOBJ2
which has additional restrictions.
You must have proper authority to the objects to perform whatever
deletions and duplications are required.
Prerequisites
-------------
The following TAA Tools must be on your system:
DLTOBJ2 Delete object 2
DUPDBN Duplicate data base network
CRTDUPPF Create duplicate physical file
EDTVAR Edit variable
RTVDBFA Retrieve data base file attributes
RTVSYSVAL3 Retrieve system value 3
SNDCOMPMSG Send completion message
SNDESCMSG Send escape message
SNDSTSMSG Send status message
Implementation
--------------
None, the tool is ready to use.
Objects used by the tool
------------------------
Object Type Attribute Src member Src file
------ ---- --------- ---------- ----------
DUPCHGOBJ *CMD TAALIBV QATTCMD
TAALIBVC *PGM CLP TAALIBVC QATTCL
TAALIBVC2 *PGM CLP TAALIBVC2 QATTCL
TAALIBVC3 *PGM CLP TAALIBVC3 QATTCL
TAALIBVC4 *PGM CLP TAALIBVC4 QATTCL
TAALIBVR *PGM RPG TAALIBVR QATTRPG
TAALIBVR9 *PGM RPG TAALIBVR9 QATTRPG
TAALIBVP *FILE PF TAALIBVP QATTDDS
|
