Filter
Top Products
names. This is because naming conventions can facilitate or impair the
implementation of OS/390 system components (such as DFSMS) and other
automated operations tools. It is recommended that you understand how a
production item will be stored, used and managed under OS/390 before giving it
a name.
Because new OS/390 JCL streams will be generated, new rules are developed to
define the structure of those streams, and how repetitive JCL statements will be
regrouped into procedures or includes in order to facilitate future JCL
maintenance. For example, a dedicated JCL procedure may be used for each of
the highly repetitive utility steps (SORT, IDCAMS, and so on), and compiler or
debug related DD statements (SYSOUT, SYSUDUMP, and so on) may be
regrouped into a single JCL include. The storage and management of control
cards and their reference from the JCL is another set of rules associated with
the structure of JCL streams, as is the usage of execution parameters and their
transfer from production control clerk to executing program through job
scheduler and JCL symbolic parameters. It is recommended that you not
redefine the division of batch applications into job streams, because this would
impact the job scheduling rules and confuse operations personnel.
As part of the OS/390 migration, the usage of utility steps can be redefined. It is
typical to find half a dozen ways of performing the same file copy in the VSE
JCL. Only a couple of ways may be needed and retained in the OS/390 JCL. The
same standardization applies to other file utility steps, such as external sorts
and backups. Database application steps and database utility steps are also
standardized, and some of the associated JCL may be isolated in JCL includes
or procedures for easier maintenance. Service steps of all kinds may be inserted
automatically by the mass conversion JCL generation tools, for example to
delete catalogued temporary files.
System managed storage is very strongly recommended when it comes to file
management under OS/390. One of the great combined advantages of DFSMS
and DFP is that they allow drastically simplified DD statements, which makes
JCL very easy to read or maintain, and be configuration independent. Typical
OS/390 migration standards include the elimination of VOLSER, RECL, BLKSIZE,
RECFM, ORG, DSCB, SPACE and UNIT attributes (with the exception of RECL in
IDCAMS/REPRO output and UNIT for tape file output).
Many VSE sites tend to be tape oriented. The OS/390 migration is an excellent
opportunity to migrate from tape intensive to disk intensive operations,
eliminating many manual interventions (for tape volume mounts) and boosting
job throughput as a result. DFSMS′s automated free space release and HSM′s
archival features can be combined to implement disk space ″buffering″
techniques, in which files that will end up on tape are created on disk by the
executing job. The copy of the file to tape, as well as the accumulation of many
files on the same tape volume is left to HSM. It takes place after the job
execution is completed. Once again, the effect is a drastic reduction of manual
interventions for tape mounts, as well as an acceleration of the job throughput.
Such file and device management policies are part of the standards and
operations procedures definition in an OS/390 migration. They have an
enormous effect on the structure and content of JCL streams.
New names must be defined under OS/390 for all items referenced in the new
OS/390 JCL, including data sets, jobs, procedures, includes, steps, execution
parameters, libraries of any kind (from source or executable code to procedures
498 VSE to OS/390 Migration Workbook