Last update:
January 27, 2000
Paul Hotz
January 27, 2000
David Chaffee has patched the current version of Pragma 4 for SCO UNIX (version 4.30a) and hopefully solved the year 2000 bug caused by an old version of SCO UNIX where the year 2000 is not seen as a leap year.
You can download the new version of Pragma from the Pragma 4 Downloads page. Please note that I have not tested this new version.
Thanks David for your help!
Paul Hotz,
October 11, 1999
According to Frans Loeve the new version of SCO UNIX 5.0.5A is year 2000 compliant, that is the year 2000 in this version is correctly seen as a leap year.
Thanks Frans for your help!
Paul Hotz,
October 11, 1999
I have been asked whether Pragma is year 2000 compliant.
Pragma and all of its predecessors back to NL have always been year 2000 compliant. The only place where Pragma deals with time is in the verbs PUT TIME and EXTERNAL TIME. In both instances the current date and time are read from the system clock and put into a noun in the format YYYY MM DD hh mm ss, a string of 20 characters. Even when memory was expensive, Logical did not make savings in the wrong place.
To sum it up. Pragma is year 2000 compliant, provided that the system clock of the computer is also year 2000 compliant.
Whether programs written with the Pragma language are year 2000 compliant is another story. You can take a horse to the water but cannot make it drink.
Ronald Scheepstra
October 1st, 1999
Hello Paul,
A pretty millennium bug I think.
Could it be that the operating system or BIOS clock is not millennium
compatible? As far as I know Pragma receives the time from the operating
system when the verb PUT TIME is used. So, whenever a operating system is
not millennium proof it shows the incorrect value.
Some bios and operating systems are convinced that 2000 is not a leap year
because it can be divided by 100. That is true for most century's but not for
years that can be divided by 400.
Have you tested the operating system on millennium compatibility?
Ron Fish
October 1st, 1999
I have scanned the SCO site and there are several patches for
Y2K problems. I have downloaded them and after I isolate which patch (if any)
fixes this problem, I'll pass it on.
Paul Hotz
October 1st, 1999
UNIX PROBLEM
I have received a report that Pragma 4, UNIX version 4.40 has a problem after
February 28, 2000. Instead of showing February 29, 2000, the verb PUT_TIME
shows March 1, 2000.
SCO UNIX 5.0.5 Open Server is one of the version of UNIX that I know has this
problem. The strange thing is that Pragma 4 for DOS and Pragma 5 do
not show this, yet the C code that sets the time of PUT TIME is always the same.
Can anybody confirm this strange behavior? If so, let me know
which version of UNIX does or does not do this.
At the end of this technical bulletin is the C code of the PUT TIME function.
Many thanks in advance.
PUT TIME C code
The function time (time_t *timer) returns the number of seconds elapsed since
midnight (00:00:00), January 1, 1970, coordinated universal time, according to
the system clock.
The function ctime() converts a time value stored as a time_t structure into a
character string that contains exactly 26 characters and has the form:
Wed Jan 02 02:03:55 1980\n\0
static unsigned char
monthname[12] [3] =
{
'J','a','n',
'F','e','b',
'M','a','r',
'A','p','r',
'M','a','y',
'J','u','n',
'J','u','l',
'A','u','g',
'S','e','p',
'O','c','t',
'N','o','v',
'D','e','c'
};
static unsigned char
monthnumber[13] [2] =
{
'0','1',
'0','2',
'0','3',
'0','4',
'0','5',
'0','6',
'0','7',
'0','8',
'0','9',
'1','0',
'1','1',
'1','2',
'?','?',
};
unsigned long
int currseconds()
{
unsigned long
int timebin;
time(&timebin);
return timebin;
}
PUT_TIME(op1)
struct noun *op1;
{
long
int timebin;
unsigned char
*timestr;
short
int
month;
unsigned char
*wrkptr;
op1->datatype = typeascii;
op1->datalength = 20L;
nounalloc(op1);
wrkptr = op1->value.ascii;
time(&timebin);
timestr = (unsigned char *) ctime(&timebin);
memcpy((wrkptr + 0), (timestr + 20), 4);
for (month = 0; month < 12; month++)
{
if (memcmp((timestr + 4),
monthname[month], 3) == 0)
break;
}
memcpy((wrkptr + 5), monthnumber[month], 2);
memcpy((wrkptr + 8), (timestr + 8), 11);
*(wrkptr + 4) = ' ';
*(wrkptr + 7) = ' ';
*(wrkptr + 10) = ' ';
*(wrkptr + 13) = ' ';
*(wrkptr + 16) = ' ';
*(wrkptr + 19) = ' ';
if (!isdigit(*(wrkptr + 8)))
*(wrkptr + 8) = '0';
if (!isdigit(*(wrkptr + 11)))
*(wrkptr + 11) = '0';
if (!isdigit(*(wrkptr + 14)))
*(wrkptr + 14) = '0';
if (!isdigit(*(wrkptr + 17)))
*(wrkptr + 17) = '0';
}
Jorge Neto,
September 10, 1998
I read the pages about the year 2000 bug.
Some time ago my concern for this mater was big. There was a big confusion and
some people were thinking it was related with that old legend that predicts the
world ends in the year 2000. Of course my concerns were different and I had to
look for better information. My problem was to know how this could affect my
Pragma programs. I ended up with this conclusions.
There are two kinds of problems:
- Hardware
- Software
The hardware problem is very simple and will affect everything: O.S., programs,
etc.
The clock doesn't reach the year 2000 and when the date of 31 of December
1999 arrives the clock will stop there or will return to the first date of the
bios clock.
Imagine a very old car. The speed this car can reach is 100Km/h
(kilometers per hour). Now imagine this car going down in a long road. When it
reaches the maximum speed it is still going down, so the car is increasing the
velocity up to 101 Km/h, 110, ... and so on. But the speedometer will keep
marking 100Km/h.
To check this problem we should try in all computers if they are
correctly dated after 1999. If they don't we can try to update the bios or
change hardware. (see Ron Fish technical bulletin).
If a computer is working as a network workstation I believe that, if the machine
that works as the server can handle the Y2K, all the workstations will be
synchronized with the network. So will Pragma.
The software problem affects several aspects of programming.
The most common problem is that vestige of the times when space was a concern
and to represent a date the programmer only used the last two numbers of the
year, 98 to represent 1998, 99 to represent 1999 and 2000 is 00. The year
2000 was too far away to be of concern at the time.
Pragma programmers can handle this problem as Ron Fish explained.
Some languages use parts of the date to create random numbers. This
command exists in languages like BASIC and is usually named
RANDOMIZE. Imagine that the programmer who invented the algorithm used the
last two numbers of the year to calculate this random number. Everything is OK
for all arithmetic operations except for the division by zero and most languages
will abort.
I believe Pragma doesn't abort if we DIVIDE a number by zero.
Other problem with the date is the leap year. This can be a hardware and
software problem. As we all know one year lasts 365,25 days. After 4
years the 0,25 day of each year will give us one more day, which is why the leap
year in February has 29 days. The year 2000 is a leap year.
This will happen every two millenniums. Because there was no
zero year. The counting of the years started in the year one.
The problem is that some applications don't calculate well the leap year. As an
example the MS Excel 97 calculates correctly the 2000 year as a leap year
but wrongly the year 1900 as leap year too. Imagine what could happen if the
computer system of a bank doesn't have the 29 of February 2000. That day will be
the 1st of March in that system.
If you have any function like CALC FUTURE DATE make sure you have correctly
calculated the leap year.
For the machine see if you get the date 29 of February 2000.
In Pragma 5 I use the CONVERT DATE to know if the year is a leap year. The
conversion style 803 converts a string of date of the format YYYYMMDD to
the day of the week. If the date we convert isn't a leap year the 29 of February
have the same day of week of the 1st of March of that year (YYYY).
The noun YEAR is the year we want to know if it is a leap year
The number of objects this verb uses is :0
|
1 |
JOIN the value YEAR to the value "02" |
|
2 |
JOIN the value HEAD to the value "29" |
|
3 |
COPY the value HEAD to the noun LAST OF FEB |
|
4 |
CONVERT DATA in noun LAST OF FEB convert style 803 return to the noun DAY OF WEEK |
|
5 |
JOIN the value YEAR to the value "03" |
|
6 |
JOIN the value HEAD to the value "01" |
|
7 |
COPY the value HEAD to the noun FIRST OF MAY |
|
8 |
CONVERT DATA in noun FIRST OF MAY convert style 803 return to the noun DAY OF WEEK 2 |
|
9 |
IF the value DAY OF WEEK "=" the value DAY OF WEEK 2 |
| do |
|
10 |
COMMENT text is It isn't a leap year |
| (...) |
|
| else | |
| 11 | COMMENT text is It is a Leap year |
| (...) | |
| end |
I tested several years including 1900 and 2000 and it gave
correct results.
I believe Pragma 5 will not have any Y2K problem as long as the
O.S. and the machine clock are Y2K compliant. The Pragma programmers
should be concerned with their verbs only if used to calculate any sort of date.
Ron Fish,
August 24, 1998
UNIX Pragma, in and of itself has no problems with Y2K (Year
2000). The PUT TIME command pulls information from the computer which, as
far as I know is the only date related standard verb in Pragma. On SCO 3.2.4 I
changed the system date at startup to Dec 31, 1999 2358 hours. It rolled
over and the program I wrote to pull the system date off the computer (a Pentium
90 - Paul's machine - about 3 years old) pulled up the date as "2000 01 01
00 00 52". No errors. The version of UNIX Pragma was
4.30. If the computer could had not made the change, it would have had the
"1900" year.
Any noncompliant Y2K problem is strictly that of the application created by a
programmer. In my software, I have but 1 or 2 verbs that use the
system date for accounting functions (CALC AGE, CALC FUTURE DATE and AMORT which
are used to compute interest). These were fixed by adding 2 IF
statements with 2 lines in each statement and 2 other lines. These IF statement
fixes will work even if the computer is not Y2K compliant. These IF statements
infer that no date older than the year 1920 is needed to compute an age.
It can be set to as far back 1901 and still work. With a 1 to 20 year time
frame, programs can be gradually changed to include the year in the databases
(currently I do not store the century in my dates, and that could take a couple
of days to fix all those).
The IF statements are (for calculating the age of something - NEW YEAR = newest
date, OLD YEAR = oldest date of the 2 date computation):
IF NEW YEAR "<" 20
do JOIN 20 NEW YEAR
else JOIN 19 NEW YEAR
COPY HEAD NEW YEAR
IF OLD YEAR "<" 20
do JOIN 20 OLD YEAR
else JOIN 19 OLD YEAR
COPY HEAD OLD YEAR
At this time, I see no reason to re-compile or change Pragma in order to be Y2K
compliant as it has demonstrated that it is - at least, it is capable of pulling
the year from the computer.
