We are running an old MS-DOS program (Computer Associates AccPac Plus) in
Windows Vista. However, this accounting program requires the user to log
into the program with a date. The problem is that the log in uses a
two-digit versus a 4-digit year. Since the data we are accessing is
pre-2000 (e.g. 1989) we enter 12/31/89, for example. However, the program
interprets this date as 12/31/2089 instead of 12/31/1989 and warns that we
are providing a date outside of the fiscal period for the data. Is there a
compatibility mode or work-around so that the program will think we are in
the 1900's versus the 2000's?

"Blue Max" wrote in message
...
We are running an old MS-DOS program (Computer Associates AccPac Plus) in
Windows Vista. However, this accounting program requires the user to log
into the program with a date. The problem is that the log in uses a
two-digit versus a 4-digit year. Since the data we are accessing is
pre-2000 (e.g. 1989) we enter 12/31/89, for example. However, the program
interprets this date as 12/31/2089 instead of 12/31/1989 and warns that we
are providing a date outside of the fiscal period for the data. Is there
a compatibility mode or work-around so that the program will think we are
in the 1900's versus the 2000's?

It looks like this program is grabbing the century from the system
clock. Being an old MS-DOS program it doesn't have the Y2K
correction algorithm for handling dates. Since it is a DOS program
the Vista date handling won't apply. One solution is to disconnect
that PC from the network and set the clock back to, say, 1999 when
running AccPac. Be aware that doing this could screw up your
Vista activation.

Another solution would be to dual boot with Win2000, if you
can find a copy, and set the system clock back each time you
boot to it. You would have to remember to set the correct date
before re-booting to Vista.

"Blue Max" wrote in message
...
We are running an old MS-DOS program (Computer Associates AccPac Plus) in
Windows Vista. However, this accounting program requires the user to log
into the program with a date. The problem is that the log in uses a
two-digit versus a 4-digit year. Since the data we are accessing is
pre-2000 (e.g. 1989) we enter 12/31/89, for example. However, the program
interprets this date as 12/31/2089 instead of 12/31/1989 and warns that we
are providing a date outside of the fiscal period for the data. Is there
a
compatibility mode or work-around so that the program will think we are in
the 1900's versus the 2000's?



instead of entering "89" as the year

enter the full year "1989"
and it should (hopefully) display just "89"

"philo" wrote in message
...

"Blue Max" wrote in message
...
We are running an old MS-DOS program (Computer Associates AccPac Plus) in
Windows Vista. However, this accounting program requires the user to log
into the program with a date. The problem is that the log in uses a
two-digit versus a 4-digit year. Since the data we are accessing is
pre-2000 (e.g. 1989) we enter 12/31/89, for example. However, the
program
interprets this date as 12/31/2089 instead of 12/31/1989 and warns that
we
are providing a date outside of the fiscal period for the data. Is there
a
compatibility mode or work-around so that the program will think we are
in
the 1900's versus the 2000's?



instead of entering "89" as the year

enter the full year "1989"
and it should (hopefully) display just "89"



This is a log in with rigid fields, so the odds are that 1989 would
truncate to 19, with the resulting date of 2019. This program
was obviously released before Y2K was an issue for cross
century calculations.

The problem is that it appears to be using the system date for the
century info rather than a hard coded 19 prefix. This shows that
they allowed for the program to work in 20xx, but didn't consider
that users might want to use 19xx data. The OP could try 00, as
that might be close enough to the data range.

It is kind of weird that the log in requires a date relating to the data,
rather than the current date.

"Ian D" wrote in message
...

"Blue Max" wrote in message
...
We are running an old MS-DOS program (Computer Associates AccPac
Plus) in Windows Vista. However, this accounting program requires
the user to log into the program with a date. The problem is that
the log in uses a two-digit versus a 4-digit year. Since the data we
are accessing is pre-2000 (e.g. 1989) we enter 12/31/89, for example.
However, the program interprets this date as 12/31/2089 instead of
12/31/1989 and warns that we are providing a date outside of the
fiscal period for the data. Is there a compatibility mode or
work-around so that the program will think we are in the 1900's
versus the 2000's?

It looks like this program is grabbing the century from the system
clock. Being an old MS-DOS program it doesn't have the Y2K
correction algorithm for handling dates. Since it is a DOS program
the Vista date handling won't apply. One solution is to disconnect
that PC from the network and set the clock back to, say, 1999 when
running AccPac. Be aware that doing this could screw up your
Vista activation.


I regularly set the date on Vista PCs forward and back without issue, so
I doubt Vista will complain about activation. That said, I've never
gone back to a date in the last century so YMMV...

Another option is a virtual machine like VMWare. It allows setting the
system date of the virtual machine independently from the host machine.
DOSBox might as well, but I'm not familiar with it so I can't say.

Good luck!

--
Zaphod

Arthur: All my life I've had this strange feeling that there's something
big and sinister going on in the world.
Slartibartfast: No, that's perfectly normal paranoia. Everyone in the
universe gets that.

"Ian D" wrote in message
...

"philo" wrote in message
...

"Blue Max" wrote in message
...
We are running an old MS-DOS program (Computer Associates AccPac Plus)
in
Windows Vista. However, this accounting program requires the user to
log
into the program with a date. The problem is that the log in uses a
two-digit versus a 4-digit year. Since the data we are accessing is
pre-2000 (e.g. 1989) we enter 12/31/89, for example. However, the
program
interprets this date as 12/31/2089 instead of 12/31/1989 and warns that
we
are providing a date outside of the fiscal period for the data. Is
there
a
compatibility mode or work-around so that the program will think we are
in
the 1900's versus the 2000's?



instead of entering "89" as the year

enter the full year "1989"
and it should (hopefully) display just "89"



This is a log in with rigid fields, so the odds are that 1989 would
truncate to 19, with the resulting date of 2019. This program
was obviously released before Y2K was an issue for cross
century calculations.

The problem is that it appears to be using the system date for the
century info rather than a hard coded 19 prefix. This shows that
they allowed for the program to work in 20xx, but didn't consider
that users might want to use 19xx data. The OP could try 00, as
that might be close enough to the data range.

It is kind of weird that the log in requires a date relating to the data,
rather than the current date.




You are probably right but I'd test it anyway

I recall that with dos, the field would accept four numerals for "date"
but simply display the last two.

I never had much of a problem when the year 2000 rolled in...
most of my machines handled it with no problem...
but one of them listed the date as 19100 !!!!

Does the program actually show 2089 or are you guessing? Many older DOS
programs would not allow forward dating and 89 would be greater than the
current 08.


"Blue Max" wrote in message
...
We are running an old MS-DOS program (Computer Associates AccPac Plus) in
Windows Vista. However, this accounting program requires the user to log
into the program with a date. The problem is that the log in uses a
two-digit versus a 4-digit year. Since the data we are accessing is
pre-2000 (e.g. 1989) we enter 12/31/89, for example. However, the program
interprets this date as 12/31/2089 instead of 12/31/1989 and warns that we
are providing a date outside of the fiscal period for the data. Is there
a compatibility mode or work-around so that the program will think we are
in the 1900's versus the 2000's?

Thank you, Ian. Another oddity I have found since this posting is that
entering the year 90 (for 1990) displays properly as 1990, unlike the 89
(for 1989) that displays as 2089. Very interesting!

********************
"Ian D" wrote in message
...

"Blue Max" wrote in message
...
We are running an old MS-DOS program (Computer Associates AccPac Plus) in
Windows Vista. However, this accounting program requires the user to log
into the program with a date. The problem is that the log in uses a
two-digit versus a 4-digit year. Since the data we are accessing is
pre-2000 (e.g. 1989) we enter 12/31/89, for example. However, the
program interprets this date as 12/31/2089 instead of 12/31/1989 and
warns that we are providing a date outside of the fiscal period for the
data. Is there a compatibility mode or work-around so that the program
will think we are in the 1900's versus the 2000's?

It looks like this program is grabbing the century from the system
clock. Being an old MS-DOS program it doesn't have the Y2K
correction algorithm for handling dates. Since it is a DOS program
the Vista date handling won't apply. One solution is to disconnect
that PC from the network and set the clock back to, say, 1999 when
running AccPac. Be aware that doing this could screw up your
Vista activation.

Another solution would be to dual boot with Win2000, if you
can find a copy, and set the system clock back each time you
boot to it. You would have to remember to set the correct date
before re-booting to Vista.

Thank you, Philo. Tried that, but it truncates to 19 (2019) as Ian
suspected.

*******************
"philo" wrote in message
...

"Blue Max" wrote in message
...
We are running an old MS-DOS program (Computer Associates AccPac Plus) in
Windows Vista. However, this accounting program requires the user to log
into the program with a date. The problem is that the log in uses a
two-digit versus a 4-digit year. Since the data we are accessing is
pre-2000 (e.g. 1989) we enter 12/31/89, for example. However, the
program
interprets this date as 12/31/2089 instead of 12/31/1989 and warns that
we
are providing a date outside of the fiscal period for the data. Is there
a
compatibility mode or work-around so that the program will think we are
in
the 1900's versus the 2000's?



instead of entering "89" as the year

enter the full year "1989"
and it should (hopefully) display just "89"

Hello, John. No, we are not guessing. The program, once it opens following
the log in, shows the complete 4-digit date. Moreover, we have observed
another interesting aspect. I have found, since the original posting, that
entering the year 90 (for 1990) displays properly as 1990, unlike the 89
(for 1989) that displays as 2089. Very interesting!

********************
"John Barnes" wrote in message
...
Does the program actually show 2089 or are you guessing? Many older DOS
programs would not allow forward dating and 89 would be greater than the
current 08.


"Blue Max" wrote in message
...
We are running an old MS-DOS program (Computer Associates AccPac Plus) in
Windows Vista. However, this accounting program requires the user to log
into the program with a date. The problem is that the log in uses a
two-digit versus a 4-digit year. Since the data we are accessing is
pre-2000 (e.g. 1989) we enter 12/31/89, for example. However, the
program interprets this date as 12/31/2089 instead of 12/31/1989 and
warns that we are providing a date outside of the fiscal period for the
data. Is there a compatibility mode or work-around so that the program
will think we are in the 1900's versus the 2000's?