IBM OS/390 User Manual
flows. For example: You can have hundreds of files with the same name, for
example
example
″
WORK1
″.
WORK1 can exist in different jobs. Most of the time the
WORK1 files will be different from and unrelated to each other. You can however
have JobA use a file named WORK1 and JobB running at the same time and
also using a file called WORK1. JobA WORK1 gets passed to Job3. Job3 runs
and uses WORK1 at a later time. WORK1 in JobB is local use only. The issue is
to distinguish the differences between the WORK1 file in JobA and JobC. If these
files become intermixed or used by the wrong Job it can be complicated to sort
out. There is no data exchanged through those file references. Only analyzing
the complete file/step cross-references with associated open modes and
attributes allows identifying these situations. When migrating to OS/390, it is
critical to identify those data flows as separate OS/390 files. In the worst case
scenario, it would create execution or JCL errors. In the best case, it would
create unwanted contentions, when concurrent jobs try to access the
have JobA use a file named WORK1 and JobB running at the same time and
also using a file called WORK1. JobA WORK1 gets passed to Job3. Job3 runs
and uses WORK1 at a later time. WORK1 in JobB is local use only. The issue is
to distinguish the differences between the WORK1 file in JobA and JobC. If these
files become intermixed or used by the wrong Job it can be complicated to sort
out. There is no data exchanged through those file references. Only analyzing
the complete file/step cross-references with associated open modes and
attributes allows identifying these situations. When migrating to OS/390, it is
critical to identify those data flows as separate OS/390 files. In the worst case
scenario, it would create execution or JCL errors. In the best case, it would
create unwanted contentions, when concurrent jobs try to access the
″
same
″
file:
OS/390 will allow more job multi-threading than VSE, if contentions are not an
issue.
issue.
Once the steps above are completed,
″
Forward engineering
″
techniques are
used to generate OS/390 JCL streams that match the application job streams
while complying with new OS/390 standards and naming conventions. This is the
easiest part of the VSE to OS/390 JCL conversion.
while complying with new OS/390 standards and naming conventions. This is the
easiest part of the VSE to OS/390 JCL conversion.
The conversion of VSE JCL to OS/390 may last three to five months and
represent 40 to 50% of the total application conversion effort.
represent 40 to 50% of the total application conversion effort.
2.7.4 File Migration
File migration can only be as good as JCL conversion. This is because the most
challenging parts of the file migration, identifying and classifying all files
according to their life, and the tape to disk device migration, are for the most
part a by-product of JCL conversion.
challenging parts of the file migration, identifying and classifying all files
according to their life, and the tape to disk device migration, are for the most
part a by-product of JCL conversion.
VSE files and databases can either be migrated
″
in-place
″
or by copy. Both
techniques can be combined in the overall VSE to OS/390 file migration strategy.
In-place migration is by far the quickest, therefore the less disruptive (very short
operations outage). Entire VSE data centers with extremely large application
data pools have been migrated to OS/390 in an hour. But by altering the VSE
production environment, it prevents instant return to VSE. It also complicates,
limits or even prevents the implementation of DFSMS, at least at start: natural
production cycles may be used to replace the sequential files migrated in place
by new DFSMS-controlled versions.
operations outage). Entire VSE data centers with extremely large application
data pools have been migrated to OS/390 in an hour. But by altering the VSE
production environment, it prevents instant return to VSE. It also complicates,
limits or even prevents the implementation of DFSMS, at least at start: natural
production cycles may be used to replace the sequential files migrated in place
by new DFSMS-controlled versions.
File copy takes longer, but with appropriate configuration and planning, large
VSE installations are routinely migrated in mass in only four to eight hours. If the
VSE disk space is unaltered by the file migration, instant VSE fallback is
possible. This technique facilitates full size DFSMS implementation from the very
start of OS/390 operations.
VSE installations are routinely migrated in mass in only four to eight hours. If the
VSE disk space is unaltered by the file migration, instant VSE fallback is
possible. This technique facilitates full size DFSMS implementation from the very
start of OS/390 operations.
Developing a file migration strategy and associated procedures (VSE and OS/390
file migration JCL streams) is not very difficult, technically speaking. Migrating
VSE production files to OS/390 for conversion regression tests allows rehearsing
and finalizing the procedures that will later on be used for the actual file
migration and operations switchover.
file migration JCL streams) is not very difficult, technically speaking. Migrating
VSE production files to OS/390 for conversion regression tests allows rehearsing
and finalizing the procedures that will later on be used for the actual file
migration and operations switchover.
Chapter 2. Sizing the Effort
35