| |
 |
|
|
Functional
Overview
|
 |
DSN/Change
searches JCL libraries, data cards, CLIST and REXX
programs, CA-1 tape management definitions, RACF
profiles, IMS dynallocs and more for all references
to the files you want to rename. These references
are then written to the internal database of DSN/Change.
A typical example of a reference is the DSN parameter
of a DD statement: DSN=FILENAME. |
|
DSN/Change
creates new file names according to pre-defined
rules. These rules are set and maintained by the
user in an ISPF dialog. Extensive utilities such
as variables, tables and string functions are available.
|
|
DSN/Change
simulates all changes. In the so-called TRY mode,
old and new file names are listed next to each other
and the result you will get after conversion is
displayed. |
|
DSN/Change
can reformat DD statements: BLKSIZE, UNIT, VOLUME,
MGMTCLAS, DATACLAS, STORCLAS and so forth can be
changed, added or removed automatically according
to pre-defined rules. |
|
DSN/Change
considers symbolic parameters in the JCL and in
procedures. |
|
DSN/Change
compares access rights to old and new dataset names
with each other. If they don't match, the differences
are displayed. |
|
DSN/Change
renames the physical files (non-VSAM, VSAM, GDGs,
IMS databases, tapes) as well as all references
to these files while production is running. |
|
DSN/Change
recalls migrated datasets. After renaming, these
datasets are returned to the media they were recalled
from. |
|
DSN
/Change tracks all modifications: Complete and error-free,
no revision is necessary. Such seamless tracking
makes it possible to undo all changes at any time.
|
| |
|
| |
|
|
Example |
| Here's
a simple example to illustrate the basic procedure
used for renaming datasets with DSN/Change. |
| 1. |
Rules
are Defined
|
| |
Rules
are used for determining the new file names. In
our example, all P390A.DCH.* files are to be renamed
P390A.XCP.JOBNAME.* (where JOBNAME is the name of
the job creating the files). |
| |
|
| |
|
| 2. |
JCL
is Modified |
| As
SMS has now been deployed in our example company,
old UNIT, VOLUME and BLKSIZE information is to be
removed from the JCL. At the same time, management-class
parameters are to be added. |
| |
|
| |
|
| 3. |
Rename
is Prepared |
| The
user now selects a group of files to be re-named.
Rules are used to create new file names and these
names are written to the DSN/Change database. However,
the entire conversion should be simulated first
in TRY mode. |
| |
|
| |
|
| 4. |
Results
are Verified |
| |
In
TRY mode, the user can check planned modifications.
The old file names are listed next to the new ones
and the way the JCL will be modified JCL. |
| |
 |
| |
|
| 5. |
Files
are Renamed |
| |
Only
now are the files physically renamed or copied.
The current batch production does not have to be
interrupted: The entire modification process executes
automatically in the background: |
|
The
first file is selected for processing. |
|
If
the file has been migrated, it is first "recalled". |
|
The
file is locked (enqueue). |
|
Only
at this point is the file renamed or copied. |
|
All
members with references to the file are changed
accordingly. |
|
The
file is unlocked (dequeue). |
|
The
next file is processed. |
| |
|
| |
|
|
Cost
/ Benefit Analysis |
| |
Empirical
values were used for this cost/benefit analysis.
Depending on the environment ? the number of symbolic
parameters, naming conventions already available,
special cases and so on ? the benefit may be far
higher but, of course, also less than in the example.
However, using DSN/Change will always save you a
lot of money. |
|
One
man-year costs €75,000. |
|
Depending
on the number of files, DSN/Change costs between
€40,000 € and €125,000.[1] |
|
Without
DSN/Change an employee can change approximately
10,000 file names per annum using 100% of his or
her working time. |
|
With
DSN/Change an employee can rename 50,000 DSNs in
50% of his or her working time. The rest of the
time the employee is available for other work. |
| |
 |
