As Roger mentions, I recall our transition, and primarily placing the YEARCUTOFF= option into the programs, or placing the YEARCUTOFF= option into the config.sas file eliminated having to put it into all the programs since every 6.12 session started with the YEARCUTOFF= option being set because starting up the session reads/executes the config.sas statements upon start up. If I recall, the YEARCUTOFF= option and/or making 2 or 4 byte storage adjustments where desired was all we did for the 6.12 era. Of course, the later is not an operational issue, but merely a data content preference.

$0.02 more cents, Mark

-----Original Message----- From: Lustig, Roger [mailto:roger.lustig@CITIGROUP.COM] Sent: Monday, November 01, 2004 10:05 AM To: SAS-L@LISTSERV.UGA.EDU Subject: Re: Seeking ancient SAS version

V5 didn't have the YEARCUTOFF= option that defined the century within which two-digit years would be read in. In other words, you had to write some code to get '010101' read in as a 21stC date (or a 19thC one).

I'm sure that's only part of it.

Roger

-----Original Message----- From: SAS(r) Discussion [mailto:SAS-L@LISTSERV.UGA.EDU]On Behalf Of Richard Ristow Sent: Monday, November 01, 2004 12:52 PM To: SAS-L@LISTSERV.UGA.EDU Subject: Re: Seeking ancient SAS version

At 06:50 AM 11/1/2004, Michael L. Davis wrote: >Hello Al and other SAS-L Friends, > >My experience is that SAS generally supplies setinit files for older >versions but not the distribution itself. Assuming for a moment that >SAS could retrieve the old distribution, you're working against >another issue: Y2K compliance. [SAS Version 5 for VMS] was not Y2K >compliant.

This is curiosity at this point, but what Y2K troubles was SAS version 5 known to have? (I was off the lists at that point.) I'd assumed that SAS was pretty robust against Y2K problems, as the SAS date representation, as a days offset, did not depend on the common representation of dates.

On the other hand, I found what I'd consider a Y2K bug, admittedly subtle, in SAS 6.12 for Windows.