Date: Fri, 31 Dec 1999 17:08:58 -0000
Reply-To: David Johnson <david_johnson@TOTALISE.CO.UK>
Sender: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From: David Johnson <david_johnson@TOTALISE.CO.UK>
Subject: Re: (MVS): Re[2]: (MVS) Warning: Possible Date Problem
Content-Type: text/plain; charset="iso-8859-1"
Well Michael, I can only count myself lucky.
The Year 2000 team at my current 'shop' defined a windowing technique, and
value for all applications that was implemented on the MVS machine before
the code freeze three months ago. They independently decided on 1920 and
only after I started there was the SAS definition checked and found to be
the default 6.12 setting. That was quickly changed in line with the site
standard.
We had more latitude on the Unix, where data was sourced from MVS in SAS
transport files, so generally speaking, all imported data used SAS numbers.
We discovered problems with one transport file, but that was resolved with
an appropriate YEARCUTOFF on the global config.
In this case though, we analysed the data and found the particular table
reported dates for business alliances, all of which fell on or after 1984.
That particular program tested the YEARCUTOFF setting, with an ISOPTION
macro, stored the value to a macro then reset it to 1980. At the end of the
program, the YEARCUTOFF is reset back to the system setting. Now that
program is safe for another 80 years. Longer than I shall care about, and
longer than this new MI will last I should expect!
What this scenario allowed me to highlight, was that blind use of windowing
dates is not necessarily always best. My experience of data sources goes
back to records of insured persons born before 1/1/1900, which was the
default missing value on a system I knew ten years ago. The insurance
dates, or vehicle purchase dates, or drivers license dates did not predate
1/1/1900 which reflected a characteristic of that type of data. Dealing
with missing or incorrect values needed one to use the 'little grey cells'
as Msr Poirot would say.
At that time, the data needed to represent two different centuries, just as
data will for now on. And I think we still need to consider the purpose of
the data before we blindly apply some cleanup rule. At the risk of reviving
an oft discussed topic on this list, 'missing' doesn't mean 'No' if it does
mean 'Question not answered' or 'Sample lost prior to analysis'.
In any case, I appreciated your humour.
Best for the season
David
----- Original Message -----
From: RAITHEM <RAITHEM@WESTAT.COM>
To: <SAS-L@AKH-WIEN.AC.AT>
Sent: 30 December 1999 18:20
Subject: (MVS): Re[2]: (MVS) Warning: Possible Date Problem
> Replying to my New Years Eve-Eve posting on the "Y2K Bug," Diana Noble
posted,
> in part, the following:
>
> <<Diana's entire posting can be found beneath the Sig line, below>>
>
>
> >2. To further complicate the problem, our MVS installation determines
all the
> >default cutoff values, which may well continue to be yearcutoff=1900.
The best
> >solution I can give you to thwart installation imposed Y2K problems
(lacking
> the
> >power to change the systems yourself), is to add code to the options
statement
> >at the top of all your JCL to the effect of: Options yearcutoff=1920 (or
> >whatever year you deem sufficient). This is addressed by SI at their web
site.
> >
>
> Diana, I was actually making an attempt at humor in my posting. However,
you
> have turned it into something very informational. Thank you! Your points
are
> well taken, and you have redeemed my flagrant misuse of bandwidth!
>
> All humor aside, I believe that a lot of persons can identify with your
> scenario: The default SAS options in the SAS System Configuration file
are
> controlled by another group; often the Systems group. The Systems group
members
> may or may not be aware of the most beneficial default settings for some
> important SAS options. Alternately, they may be aware, but have strong
opinions
> on options settings that conflict with your own. Or, a "SAS Expert" in
another
> group may have gotten to the Systems group first and enabled options
settings
> that don't quite agree with your own. So, what is a conscientious SAS
> programmer to do?
>
> Diana, you have already given us one solution--one that I would definitely
would
> employ. Here are my own two personal favorites, listed in my order of
> preference:
>
> 1. Create a User Configuration File and invoke it in all applications.
The User
> Configuration file is a file with SAS systems options that you specify.
It is
> automatically concatenated after the system configuration file and
processed at
> SAS initialization time. Any options set in the User Configuration file
> override options set in the System Configuration file. The User
Configuration
> file is especially useful for specifying SAS system options that can only
be
> specified at system initialization time. You can specify the User
configuration
> file in batch like this:
>
> file://STEP01 EXEC SAS,CONFIG='user.config.file.name'
>
> Invoking SAS under TSO:
>
> SAS CONFIG('''user.config.file.name''')
>
> Note, that in the TSO invocation, three single quotes _MUST_ precede and
follow
> the configuration file name.
>
> 2. Create and use an Autoexec File. As we all know, the autoexec file is
a file
> of SAS statements that are executed immediately after the SAS System is
> initialized, and before the source program statements are executed. Many
SAS
> system options can be set there via the OPTIONS statement. You can
specify the
> Autoexec file in batch like this:
>
> file://STEP01 EXEC SAS
> file://SASEXEC DD DSN=autoexec.file.name,DISP=SHR
>
> Invoking SAS under TSO:
>
> SAS AUTOEXEC('''autoexec.file.name''')
>
> Again; the three single quotes bracketing each end of the Autoexec file
name are
> needed (if you want to successfully invoke the SAS System with an Autoexec
> file).
>
> Diana, like you, I absolutely refuse to be a (SAS system options) victim!
I
> think that it is worthwhile for MVS SAS programmers to be proactive and
either
> create a group Config file and/or Autoexec file, or create personal ones.
They
> should actively use them in their on-line and in their batch SAS
applications.
> In that way, they will more closely control the destiny, the health, and
the
> success of their SAS applications!
>
>
> I hope that this explanation proves helpful now, and in the future!
>
> Of course, all of these opinions and insights are my own, and do not
> reflect those of my organization or my associates.
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Michael A. Raithel, Westat
> E-mail: raithem@westat.com
> Author: Tuning SAS Applications in the MVS Environment
>
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Good is not good, where better is expected. -- Thomas Fuller
>
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>
> I have discovered 2 problems in which non-compliant Y2K data can be
imposed on a
> SAS programmer which are beyond his/her control.
>
> 1. One is where the installation uses 'windowing' techniques for all
production
> programs (as Michael has so aptly described), whereby the production
version of
> all processing programs append a 2 digit century to the 2 digit year
'DURING
> PROCESSING ONLY'. Since this form of 'windowing' only occurs for
processing
> production activities, the data files continue to store the 2 digit year,
> leaving those of us who only use the data files for information processing
in a
> quandary. This is solved as Michael suggested, by converting all programs
to
> create 4-digit versions of the year.
>
> 2. To further complicate the problem, our MVS installation determines all
the
> default cutoff values, which may well continue to be yearcutoff=1900. The
best
> solution I can give you to thwart installation imposed Y2K problems
(lacking the
> power to change the systems yourself), is to add code to the options
statement
> at the top of all your JCL to the effect of: Options yearcutoff=1920 (or
> whatever year you deem sufficient). This is addressed by SI at their web
site.
>
> I join the chorus in urging everyone to check their options, configuration
> setups, and system defaults.
>
> Beyond that, I wish everyone a safe and prosperous New Year!
>
> Diana Noble
> Prudential
> *************
> email diana.noble@prudential.com
>
> The opinions expressed here are mine alone and do not reflect those of my
> associates or that of my organization.
>
> **************
> ------------------------------
>
> Date: Thu, 30 Dec 1999 08:21:24 -0500
> From: RAITHEM <RAITHEM@WESTAT.COM>
> Subject: (MVS) Warning: Possible Date Problem With Change of Century!
>
> Dear SAS-L-ers,
>
> I just chanced upon an article in a computer magazine that has stunning
> implications! It seems that a lot of computer programmers have been using
2
> digits to store year values. For instance, 1964 would be stored as 64,
1973
> would be stored as 73, 1999 would be stored as 99, etc. This method saves
two
> bytes per year value and makes it easy to determine the number of years
between
> dates: 99 - 73 = 26. But a problem will arise when the new century
arrives and
> the two-digit years become 00! Then, a calculation such as 00 - 73 will
return
> a negative number (-73)! So, a person born in 1973 could mistakenly be
> considered to be -73 years old! This problem has been dubbed the "Y2K
Bug."
> (Y2K stands for "Year 2000").
>
> Since there are only a few days left before the change, I would urge you
and
> your colleagues to check through your own SAS programs and ensure that you
are
> not using two-digit years! If you are, then you should modify them to
> four-digit years to avoid the "Y2K Bug". Doing this is has been dubbed
"making
> an applications Y2K compliant." I know that I will be busy in the next
two days
> checking my own SAS programs and changing two-digit years to four-digit
years!
> I want all of my applications to be "Y2K compliant!"
>
> Boy, am I glad that I happened upon that article! I just hope that I will
be
> able to make the necessary changes and spread the word before it is too
late!
>
> I hope that this explanation proves helpful now, and in the future!
>
> Of course, all of these opinions and insights are my own, and do not
> reflect those of my organization or my associates.
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Michael A. Raithel, Westat
> E-mail: raithem@westat.com
> Author: Tuning SAS Applications in the MVS Environment
>
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Life is like the core of the apple; it never gets into the pie. --
Michael A.
> Raithel
>
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
| 
