Filter
Top Products
2.7.2 Program Conversion
The conversion of VSE application code to OS/390 is often (but falsely) believed
to be the center, most challenging, most labor consuming and most critical part
of the conversion, but it is not. With few exceptions (see VSE positioning), it is a
simple code modification which does not change program logic, and can nearly
always be applied with a simple two-pass translation tool.
VSE COBOL code must also be upgraded to the latest (COBOL for OS/390)
compiler level. But this upgrade too, requires no program logic change, and can
be applied with a simple two-pass translation tool.
In technical terms, these OS/390 and COBOL upgrade modifications are simple
code ″re-engineering″ which fall into one of the following categories:
•
Syntax modification: replace a syntax pattern on one or several statements
by a similar OS/390 compatible syntax pattern.
•
Device independence: eliminate block sizes and other device dependencies
from the converted code. Under OS/390, device dependent file attributes are
either coded in the JCL or determined by the system managed storage
(DFSMS) components of OS/390.
•
Elimination of VSE-only features: features such as COMREG, UPSI, DATE and
USER can be replaced by calls to user-developed ad-hoc subroutines that
simulate the feature under OS/390. Some other VSE-only features, such as
the usage of VSE system macros and VSE supervisor calls from Assembler
may be more complex to convert.
The difficulty level when converting COBOL code to OS/390 is fairly similar from
one VSE installation to another, but it is not so with Assembler. The conversion
of Assembler code can be fairly easy, if VSE standard application coding was
used, or very complex, if system-dependent non-standard coding was used. In
some cases, the conversion of an Assembler program may start with a complete
redesign, in which one must identify what function or feature will still be
performed by the program, and what function or feature will be handled by the
OS/390 system software and utilities. This leads to partial or complete rewrite.
Fortunately, those situations are becoming rarer, as VSE installations
progressively eliminate their non-standard and system-dependent coding
practices.
The conversion of VSE code to OS/390 and COBOL code upgrade may last two to
four months and represent 10 to 15% of the total application conversion effort,
unless there is a significant inventory of technical non-standard Assembler
programming.
2.7.3 JCL Conversion
JCL conversion is nearly always underestimated in both duration and labor. It is
the central, most challenging, most labor consuming and most critical part of the
VSE to OS/390 conversion.
VSE JCL streams alone are not sufficient to define the flow of the associated job
streams. The sequence of steps is evident, but the file references are not always
visible. Some are hidden in the standard or partitioned labels. Some are passed
and reused from one step to the next. File reference statements (TLBL and
DLBL) coded in the JCL are not necessarily used in VSE; the program might not
open that file. It is accepted practice in VSE and doesn′t trigger any syntax or
execution error. The file open mode (input, output) is not visible from the VSE
Chapter 2. Sizing the Effort 33