Small Y2k fix for the makezones Perl Script

[Martin McCormick]

	We have been using Philip Hazel's excellent makezones perl
script to help ride hurd on the syntax of our dns files since about
1994 or so.  It has worked flawlessly until after New Year's day.
What I found was a SOA record that had suffered a mutation and looked
like:

;
;   okstate.hosts
;

@       IN     SOA  ns.cis.okstate.edu. martin.dc.cis.okstate.edu.  (
                                2000010306
 Serial
                                    1802; Refresh
                                    901; Retry
                                  4838400; Expire
                                   43200 ) ;Minimum

	The Serial comment is on a line by itself and there is no ;
after the sequence number.

	While studying the makezones script, I saw that Philip Hazel
had thought of Y2k a long time ago and had written the script to use
4-digit year numbers.  The original perl code to generate the first
serial number of any given day follows:

# Calculate the serial number for the first update of
# today, allowing for the impending millenium.

local($today_serial) = `date +20%y%m%d01`;
$today_serial -= 100000000 if (substr($today_serial, 2, 2) > 90);

# If the existing serial number is already >= today's
# start, increment it by one. Otherwise use today's start.

$value = ($value >= $today_serial)? $value+1 : $today_serial;

# Re-write the start of the second record with the new serial number.

	It seems in perl that data are treated as numerical if one
does any arithmetic on them or as alphanumeric characters if not.
Before January 1 of 2000, there was always a subtraction done on the
date value to make the result yield a four-digit year beginning with
19.  After Y2k, this calculation was not done and the string
representing the date could still be either numbers or characters at
the time the first sequence number of the day is produced.  I was
looking down the wrong path for omitted syntax or something along
those lines when one of our sharper staff members pointed out why the
mutation always occurred on the first serial number of any new date.
It was quite clear after that what to do.

	Our fix was to stick a little arithmetic in there and simply
add 0 to the value gotten from the date and the script now works
perfectly again.  Here is the modified code.

# Calculate the serial number for the first update of
# today, allowing for the impending millenium.

local($today_serial) = `date +20%y%m%d01`;
#$today_serial -= 100000000 if (substr($today_serial, 2, 2) > 90);
$today_serial += 0;

# If the existing serial number is already >= today's
# start, increment it by one. Otherwise use today's start.

$value = ($value >= $today_serial)? $value+1 : $today_serial;

# Re-write the start of the second record with the new serial number.

	I hope this helps anyone who uses this script in solving the
problem that I know they are now having.  This is an excellent script
and my thanks to Philip Hazel for allowing us to use the script for
all these years.  This is only a Y2k problem because that's when the
logic of the program created the ambiguity.  It has nothing to do with
two-digit VS four-digit dates.

Martin McCormick WB5AGZ  Stillwater, OK 
OSU Center for Computing and Information Services Data Communications Group