This
is a collection of code patterns for some of the common Mainframe MVS programming
tasks which tend to repeat from time to time. When not singled out and
classified these patterns get easily lost in the bulk of an application-specific
code, and constant rewriting (and debugging) them from scratch is a senseless
waste of time.
Normally
there are several ways to code the same logic,v and some ways are better than
the other in terms or size, effectiveness, readability and ease of modification.
These criteria are rather fuzzy (except for the "size"), and are affected by personal
preferences. Yet, there seems to exist a certain common sense consensus
of what is "good" – like mnemonic names and labels, use of indentation, commenting,
etc.
My
brother Victor and I have been collecting such "good" code patterns for several decades
and it seems it's about time to select the most usable of them from all of
our scattered notes and programs into one document which will be hyperlinked
for the ease of use, and will be accessible from anywhere and by anybody who
might have interest in it. However, this selection is not compiled for
the Web only – rather it's our working reference, which we try to maintain
as accurate and current as possible As such it inevitably
will always lack an overall integrity and completeness, yet it is still a
rather useful tool that often saves time.
Most
of the tasks originated from a real-life experience of a professional
mainframe programmer. Most of the solutions were coded and debugged
in the process of practical programming of various applications.
Every pattern was checked to the best of our competence, and as a rule was
tested by many years of repeated usage. This is not to suggest that
it is in any way guaranteed to be error-free – you will
be using any code you pick from this selection entirely at your own risk,
and will be completely responsible yourself for any problems that
might arise from this usage. So when trying a code, please
exercise the common sense precautions, and test it most thoroughly
yourself before applying it to anything serious.
This
legal mantra been chanted, I want to mention that all error reports and any
comments about this code pattern selection are most welcome, and I'll try
to do my best to fix any known problem as quick as I'll be able to do this.
Passing parameters specified in the PARM field of
the JCL EXEC operator to the COBOL program is pretty straightforward
as it is outlined in the code below. When Program is EXECuted,
Operating System moves JCL PARM field value to the PARM-String
structure of the COBOL program.
Most legacy systems were designed to work with two-digit
years (i.e., only with years within the current century).
This reflected the fact that computers were introduced to the
widespread use around the middle of the 20-th century.
What was a generally accepted common-sense abbreviation turned
out to be a major design flaw in computer systems at the turn
of the century, which created the notorious "Y2K Computer Crisis".
It was next to impossible to switch legacy systems
entirely from non-Y2K-compliant two-digit year presentation to
the Y2K-compliant four-digit years. Two-digit years were
practically cut in stone — uncountable computer files. Attempt
to change formats in all those files and programs processing them
would be a work immeasurable and might introduce in its process
new bugs no less serious than the Y2K one.
A comparatively simple solution was found to fix
the Y2K bug without the risk to introduce new bugs into systems.
It employs the fact that most business date-related needs can be
comfortably covered by a century span and is based on the notion
of the Pivot Year. It is year 2000 now. Lets assume
Pivot Year to be 50 and treat all two-digit years less or equal
to 50 as belonging to the current century, while years greater
than 50 as belonging to the previous one. This technique
permits the date-related logic to operate within a virtual date
window and is called for that reason "Windowing". It is
obvious that this same technique was used subconsciously by humans
long before computers to handle the naturally abbreviated dates.
The code below shows one possible implementation
of "Windowing" method. Pivot-Year is a way to set
a century window: all two-digit year values greater than
Pivot-Year are assumed to belong to the previous century;
otherwise they are assumed to belong to the current century.
Code works with non-Y2K-compliant dates in Julian
format (YYDDD). Code for dates in Gregorian format (YYMMDD)
is almost identical — only a YY part of a date is used in conversion
logic, so DDD should be changed to MMDD and lengths should be
changed from 3 to 4. Source date lengths should be changed
from 5 to 6.
Source date names are chosen here only to illustrate
date conversion logic. In real program more mnemonic names
should be used for the source dates.
Note: This code can be used both
in batch and CICS programs.
*-----------------------------------------------------------------
DATA DIVISION.
*-----------------------------------------------------------------
. . . . .
WORKING-STORAGE SECTION.
. . . . .
* -- Pivot Year Assumed by the Organizational Standard.
77 Pivot-Year PIC 9(02) VALUE 50.
* -- Source Dates to Be Compared.
77 Source-First-Date PIC 9(5).
77 Source-Second-Date PIC 9(5).
* -- Working Variables for Y2K-Compliant Date Comparison.
01 Y2K-First-Date.
02 First-Date-CC PIC 9(2).
02 First-Date-YYDDD.
03 First-Date-YY PIC 9(2).
03 First-Date-DDD PIC 9(3).
01 Y2K-Second-Date.
02 Second-Date-CC PIC 9(2).
02 Second-Date-YYDDD.
03 Second-Date-YY PIC 9(2).
03 Second-Date-DDD PIC 9(3).
. . . . .
*-----------------------------------------------------------------
PROCEDURE DIVISION.
*-----------------------------------------------------------------
. . . . .
* -- Append Appropriate Century to the Source Dates.
MOVE FUNCTION CURRENT-DATE(1:2) TO First-Date-CC
Second-Date-CC.
MOVE Source-First-Date TO First-Date-YYDDD.
IF (First-Date-YY > Pivot-Year)
SUBTRACT 1 FROM First-Date-CC
END-IF.
MOVE Source-Second-Date TO Second-Date-YYDDD.
IF (Second-Date-YY > Pivot-Year)
SUBTRACT 1 FROM Second-Date-CC
END-IF.
* -- IF (Source-First-Date > Source-Second-Date)
IF ( Y2K-First-Date > Y2K-Second-Date)
. . . . .
ELSE
. . . . .
END-IF.
In order for the "Windowing" method to work smoothly
the Pivot-Year should be advanced every 5 or 10 years
correspondingly. The most reliable way is to keep the
Pivot-Year as a separate and unique COPY member
to be used by all date handling programs. This approach
permits to avoid any possible errors related to Pivot-Year
advancement, since there is only one place where the year
is changed. Process of recompiling all programs containing
the Pivot-Year COPY member is quite formal and, if performed
carefully, doesn't require any debugging.
Continue PARM
field of the JCL EXEC operator to the next line.
Maximum length of PARM field of the JCL EXEC operator
is 100 characters. Long PARM values won't fit into one line
which can span only through pos. 71 and it might become necessary
to continue PARM field to the next line.
If PARM field contains comma-delimited
parameters, split PARM field at the comma and enclose entire
PARM field into parenthesis. PARM continuation should be
no further than pos. 16 of the next line,
E.g.:
If PARM field doesn't contain comma-delimited
parameters, enter PARM field data through pos. 71 and then
continue exactly in pos. 16 of the next line
and enclose entire PARM field into apostrophes, E.g.:
----+----1----+----2----+----3----+----4----+----5----+----6----+----7-
//STEP3 EXEC PGM=IEFBR14,PARM='LONG PARAMETER FIELD WITHOUT COMMA DEL
// IMITERS - CONTINUED IN COLUMN 16 OF THE NEXT LINE'