Good News for Corps: Drive Down Rates as Desired w This Y2K Solution 
Author Message
 Good News for Corps: Drive Down Rates as Desired w This Y2K Solution

With the "Open and Shut Window Technique" Y2K solution, employers
of programmers can actually *layoff* programmers, not need more!

If, perchance, competitors foolishly raid your staff, and you find
yourself in need of programmers, then you can send the work
overseas to India with confidence with the "Open and Shut Window
Technique" because it is so simple.  It relies heavily on existing
code, so it needs little testing, and contrary to someone's
mistaken belief, it needs no continual maintenance beyond the
initial program modifications.

In any case, you can continue with your corporate objectives, that
is, to drive down compensation rates for labor, particularly
expensive labor, particularly programmers.  Sock it to those
indolent and privileged prima donnas!

The "Open and Shut Window Technique," the quickest, simplest
Y2K solution follows!

Please read this document to the end.  Some important content
is near the end.

This approach will

    1.) eliminate the need for file conversions
    2.) allow you to move individual programs into
        production as they are converted indepen-
        dently of the status of other programs
        (great from an standpoint of keeping things
        organized)
    3.) work for all languages and all data access
        methods and databases
    4.) work for batch and on-line systems
    5.) work for subsequent turns of century
        (as far as 2100 not being a leap year, you
        are on your own with this minor glitch)
    5.) not involve the reformatting of input
        screens unless desired
    6.) not involve the reformatting of output
        reports unless desired

This approach will work for systems whose active
two-digit years do not span more than 50 years,
such as motor vehicle systems (aside from birth-
dates which should already be carried with 4
digit years), manufacturing systems, payroll
systems, order processing systems, and many, many
others.  (Note:  you can also use this approach
partially to buy you more time for a different
permanent solution if the range of active dates
in your system is greater than 50 years but less
than app. 90 years,)

Where you will primarily run into problems in a
program is in date comparisons, however, the
problem exists ONLY when the two dates are in
different centuries, otherwise the existing code
is adequate.  You make the distinction by having
a convention whereby all two digit years less
than n are new century years and all other years
are old century years.  n may be 10 or 50 or
whatever works for your particular system and
whatever you feel comfortable with.

Here is the logic for date comparisons:

If both dates are in the same century, execute
existing logic as is, otherwise, if year1 < year2,
then GOTO the existing GREATER-than logic for
date1 being greater than date2, else GOTO the
existing LESS-than logic for date1 being less
than date2.  Don't expand the years by prefixing
them with 19 or 20; there is no need to do so.

If you are looking for more, there isn't much
more to it than that.  When you are well into
the new century and all the active dates in the
system are new century dates, then go into your
programs and comment out the logic above and
recompile.  Then as you approach the next turn
of the century, uncomment out the comments making
the code active again!  (Save your screams.  Wait
to see what's below.)

You will also have to insert some correcting
code where you calculate the number of days
between two dates.  Here, if both dates are in
the same century just execute the existing code.
Otherwise expand the the new century year to
three digits by prefixing it with a 1 and
expand the old century year by prefixing it
with a 0.  Find the difference between the two
years, and GOTO the appropriate point in the
existing code beyond the point where the dif-
ference was calculated originally.

Again, at an appropriate time in the future,
comment out the code, recompile, and at the next
turn of century uncomment out the code and reuse
it.

You may have a situation where you are browsing
a KSDS VSAM file which is in key sequence accord-
ing to dates.  You are going to have to insert
modification code to end the browse at the end of
the records for year 99 and then restart the
browse for the records for year 00.

There may be situations where dates are used in
arithmetic calculations to come up with a VSAM
RRDS record number.  Depending on how the situ-
ation is handled, you may not need any correcting
code.  If you do, it should be as simple as the
other correcting code described herein.

With this approach, two digits years will always
be interpreted by humans as usual when they input
dates or when they read reports.  However, if you
so desire, you can modify your input programs and
output programs to use 4 digits years, but to
avoid file conversions, you will still carry the
dates in two digits in the files.  (Actually, having
the century prefixed to input and report output
dates will necessitate extra logic for keeping it
working into the 2100's, so it is recommended to
dispense with this for simplicity's sake.)

Remember to keep your correcting code well
contained for the convenience of commenting and
uncommenting it out in the future.  And be sure to
put liberal **** asterisk blocked **** documenting
comments to this effect.

Well, maybe you don't want to comment and uncomment
the code.  A convenient way to determine if your
two dates are in the different centuries is to check
the absolute value of their differences.

So now your correction code for date comparisons
will look something like the following.  (Remember,
all dates to be compared must not span more than
50 years, otherwise the following will not work
properly!)

* Note:  vertical lines: "| |" surrounding "year1 - year2" below
* indicate absolute value of the difference of year1 and year2.
IF |year1 - year2| is greater than 49
   IF year1 is less than year2
      GOTO date1-is-greater-so-goto-existing-greater-than-logic
   ELSE GOTO date1-is-lower-so-goto-existing-lower-logic.
* Continue with next program instruction as it was originally.

Some reports will be printed with the data for
the new century dates preceding the old century
dates.  But this is just a minor inconvenience
which will go away when all dates in the system
are in the new century.  Also, it is my under-
standing that if you put your data through
Syncsort, you can specify sort parameters which
will eliminate this problem.


Dash Langan



Tue, 07 Sep 1999 03:00:00 GMT  
 
 [ 1 post ] 

 Relevant Pages 

1. Good News for Corps: Drive Down Rates as Desired w This Y2K Solution

2. Good News for Corps: Drive Down Rates as Desired w This Y2K Solution

3. Good News for Corps: Drive Down Rates as Desired w This Y2K Solution

4. For a Really Good Time, Check Out This Y2K Solution

5. This Y2K Solution w/o Testing is Better Than Nothing

6. This Y2K Solution w/o Testing is Better Than Nothing

7. For a Really Good Time, Check Out This Y2K Solution

8. This Y2K Solution w/o Testing is Better Than Nothing

9. This Y2K Solution w/o Testing is Better Than Nothing

10. Good news about Y2K Links

11. Clarion's Propery List - Desired solution to MAX controls

12. Rates, rates, rates.

 

 
Powered by phpBB® Forum Software