TAA Tools

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

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

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

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

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

   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

                 The  entire data base  network must exist  in the From

   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.


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.


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


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

Added to TAA Productivity tools May 1, 1996

Home Page Up to Top