Browse Prior Art Database

Automated Catalog-Merge Process

IP.com Disclosure Number: IPCOM000114507D
Original Publication Date: 1994-Apr-01
Included in the Prior Art Database: 2005-Mar-28
Document File: 4 page(s) / 160K

Publishing Venue

IBM

Related People

Boardman, CN: AUTHOR [+2]

Abstract

Disclosed is an automated process for moving aliases between catalogs in a Data Facility Storage Management Subsystem (DFSMS) controlled, MVS environment. It replaces labour intensive methods, consisting of multiple steps, each prone to error. The process can be started in advance of the actual move, saving working time - and run concurrently with other jobs, increasing productivity. The process is faster than current method and requires less manual intervention. Aliases are listed automatically, avoiding editing error losses; lists of aliases before and after the move are retained for future reference and related aliases are regenerated.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 38% of the total text.

Automated Catalog-Merge Process

      Disclosed is an automated process for moving aliases between
catalogs in a Data Facility Storage Management Subsystem (DFSMS)
controlled, MVS environment.   It replaces labour intensive methods,
consisting of multiple steps, each prone to error.   The process can
be started in advance of the actual move, saving working time - and
run concurrently with other jobs, increasing productivity.   The
process is faster than current method and requires less manual
intervention.   Aliases are listed automatically, avoiding editing
error losses; lists of aliases before and after the move are retained
for future reference and related aliases are regenerated.

      Catalog background description can be found in the Appendix.
Catalogs have to be merged, moved, recovered etc.   Processes which
can involve tens to hundreds of aliases, requiring much editing with
opportunity for errors.   Errors can be catastrophic and range from
not being able to IPL the system to loss of access to datasets, and
time consuming to fix.   A current process is for moving entries from
one usercatalog to another is:

1.  From the source usercatalog, list all aliases; achieved by
    running IDCAMS job with the LISTCAT ENTRY ('usercat') ALL
    command.

2.  For each alias, list all the datasets with that alias as a HLQ;
    achieved by running IDCAMS job with the LISTCAT LEVEL ('alias')
    ALL command.

3.  If required, CREATE a new usercatalog on the target volume.

4.  To move the catalog entries into the target catalog, the IDCAMS
    commands DELETE and REPRO are used with the MERGECAT parameter.
    This REPRO command can be run either for the whole of the source
    catalog or one alias at a time.   Multiple aliases cannot be
    specified.

5.  If all the aliases have been moved, delete the empty usercatalog.

6.  Regenerate any Related Alias, if they were known to exist.  If
    they were not originally known about (which is likely) then jobs
    will fail!

If the whole catalog is moved at once, and problems are encountered,
it can be tricky and time consuming to sort out the mess.  If one
alias at a time is taken, then this has the advantage of providing a
checkpoint after each move, to check progress but has the drawback
that for each alias a job has to be run and can considerably extend
the time taken to move the catalog entries.   Prior to running the
REPRO, the alias must be deleted and defined again, but related to
the new catalog.

      The Automated Catalog Procedure objective is to get the benefit
of just running a few jobs, but maintain the control of using
aliases, REXX execs have been developed.   These are run in sequence
by submitting three batch jobs.

1.  MCAT1 - This batch job runs in sequence, the REXX execs MCATA, B,
    C, D, DA and DB.  It requires the name of the input usercatalog.
    Two output files are created.  The first contains a s...