Kermit software is not, for the most part, date dependent. It makes
connections, performs terminal emulation (in those versions that include this
feature), transfers files, translates character sets, and, in most cases,
executes scripts regardless of the date.
"Year 2000 compliance" depends on the Kermit program and the underlying
platform. If the operating system, file system, BIOS, hardware, and/or other
critical component is not ready for the year 2000, then most likely Kermit
isn't either, since it relies on the underlying OS and hardware for date / time
service.
The primary relevance of this question to Kermit software is whether
post-millenium file dates are recognized, transmitted, received, and reproduced
correctly during the file transfer process. This consideration, in turn,
applies only to those Kermit versions that implement the optional "Attribute
Packet" feature. These include C-Kermit, Kermit 95, MS-DOS Kermit, Kermit-370,
and PDP-11 Kermit, all of which are coded to write and read 4-digit years in
all protocol messages. (Note that these programs also include a command to
disable file-date processing altogether, in the event that it does not work as
intended.)
If post-millenium dates are not processed correctly, file transfer will
still take place, but the creation or modification date of the received file
might be incorrect. An exception would be if the "file collision update"
feature is being used to prevent unnecessary transfer of files that have not
changed since the last time a transfer took place; in this case, a file might
be transferred unnecessarily, or it might not be transferred when it should
have been. Correct operation of the update feature depends on both
Kermit programs having the correct date and time.
Another exception would be when using the /BEFORE: or
/AFTER: file-selection switches during file transfer. If dates are
not processed correctly, files could be skipped that should have been sent, or
vice versa.
If an incoming file is stored with the wrong date, for example with a year
of 1900 rather than 2000, this might affect backup, archival, and cleanup
procedures, perhaps resulting in unwanted file deletion. For example (in VMS):
Of secondary importance are the time stamps in the transaction and/or debug
logs, and the date-related script programming constructs, such as \v(date),
\v(ndate), \v(day), \v(nday), and perhaps also the time-related ones, \v(time)
and \v(ntime), insofar as they might be affected by the date. Note: the
aforementioned script programming constructs are available only in C-Kermit,
Kermit 95, and MS-DOS Kermit. The \v(ndate) is a numeric-format date of the
form yyyymmdd, suitable for comparison and sorting: e.g. 19970208 or 20011231.
If the underlying operating system returns the correct date information, these
variables will have the proper values. If not, then scripts that make
decisions based on these variables might not operate correctly, but then
neither will any other date-related software on your computer.
Here is the current situation for the most popular Kermit software
products. The minimum version known to be Year-2000 compliant is shown. We
make no claims whatsoever about the underlying operating systems or file
systems. The situation with Kermit programs not listed here is at present
unknown.
29 Is Kermit Software Year-2000 Compliant?
$ delete/before="-90-" *.*;*
$ dir/since=1-jan-2000
$ purge/before=login *.*
Kermit FAQ / Columbia University / kermit@kermitproject.org