Dear SCO Customer, Support Level Supplement (SLS) PTF3391C, the Year 2000 Supplement for SCO UnixWare 2.1.1 and 2.1.2, provides the following fixes and features: 1. CMOS RAM byte 0x32 (or 0x37 on PS/2) is defined to hold the century (as binary coded decimal). UNIX does not use that byte, and has not in the past maintained it, but a few machines have a BIOS that does make use of it. On such a machine, changing the year from 19YY to 20YY (or the reverse) under UNIX, then running System Setup, DOS or Windows on reboot, can cause the system date to be reset incorrectly. The UNIX Real Time Clock (RTC) driver in this SLS maintains the CMOS century byte consistent with the year, in order to avoid such problems as much as possible; some such problems may reside in the machine's BIOS itself. 2. For compatibility with System Setup, DOS or Windows, UNIX maintains the Real Time Clock in local time, so it must be adjusted when entering or leaving Daylight Savings Time. If you arbitrarily set your system date forward or backward (as you might when testing Year 2000 issues), into or out of Daylight Savings Time, then /stand/boot TZ_OFFSET may lose sync with the date. This causes the hour to advance, or go back, each time UNIX is rebooted. The dst_sync program in this SLS keeps /stand/boot TZ_OFFSET and the kernel's difference between UNIX system time and RTC in sync with the local time according to /etc/TIMEZONE TZ. It is run at startup and shutdown, and by daily cron(1M) job. The at(1) job is no longer used. /usr/lib/dstime/dst_sync could also be run by a privileged user, to synchronize it after changing the date or Time Zone: but the daily cron job or shutdown script will soon make the necessary correction automatically. 3. at(1) permitted the date "Feb 29" only when the current year was a leap year, regardless of the year for the at(1) job itself. At one point, it did not treat the year 2000 as a leap year, scheduling jobs for Mar 1, 2000 to Dec 31, 2000 a day early. But neither of these errors occurred when using the "-t time" syntax, nor when using the environment variable DATEMSK (typically DATEMSK=/etc/datemsk) to parse the date. atrm(1) did not have a Year 2000 problem, but it sometimes failed with "Segmentation Fault - core dumped". Since atrm(1) is used by the installation of this SLS to replace the at job by a daily cron job, a fix for this problem has been included. crontab(1) did not have a Year 2000 problem, but like at(1) and atrm(1), it was liable to fail with "Cannot open message queue: Resource temporarily unavailable". These fixes are included, with atq(1), batch(1) and cron(1M) completing the cron suite, to avoid an incompatibility with PTF3096, which fixed the message queue problem, but omitted UnixWare 2.1.1 POSIX changes. 4. Accounting programs acctcms(1M), acctcon(1M) and acctcon1, acctprc(1M) and acctprc1, divide time spent into prime time and non-prime time (off-hours or holiday) time, according to entries inserted by the administrator in /etc/acct/holidays. Year 2000 was accepted, but years 2001 onward were rejected. The daily "LAST LOGIN" report could never advance from a 99-MM-DD login to a 00-MM-DD login, fixed and sorted. However, 00-00-00 accounts that never logged in are now omitted. 5. NetWare server's Admin_Tools/Networking/DS_Repair (Directory Services Repair) program which showed year 20YY as 1YY, now shows YY. NetWare UNIX client's Admin_Tools/Networking/NetWare_Access program which showed login year 20YY as 191YY, now shows 20YY. 6. lp/model banners, and sv .437 locales, showed year 20YY as 19YY. lp/model scripts all have a regular expression fix from the standard interface script. 7. ftpd(1M) responded to "modtime" with a modification of year 20YY to 191YY. ftp(1) "newer" ignored modtime century, and often misjudged whether it was actually newer. ftp(1) "newer" and "modtime" now allow for an uncorrected ftpd(1M) modtime response, correcting its 191YY to 20YY. 8. uucico(1M) and uuxqt(1M) logged times to /var/uucp/.Admin/perflog showing the year as 1YY, where it is now YY. uustat(1C) -t processed perflog times as if year 99 came after year 00, where now it recognizes year 99 as being before year 00. 9. auditrpt(1M) -s and -h rejected time YY 00-69, where it now rejects 38-69. prt(1BSD) -c and -r rejected the cutoff YY 00-69, where it now rejects 38-69. 10. Using the year 2000 as an example: passwd(1) -s showed the year of the last password change as 100, where it now shows 00. smtpd(1M) "Received: from" line showed the year as 100, where it now shows 00. w(1BSD) showed the year of week-old login time as 100, where it now shows 00. whodo(1M) -l showed the year of week-old login as " 0", where it now shows 00. In the UnixWare/OpenServer Development Kit 7.0.0, /udk/usr/ccs/bin/prs -d:Dy: showed the year as 100, where it now shows 00. 11. uptime(1BSD) is a copy of w(1BSD). touch(1) had been fixed in UnixWare Release 2.1.1, but its acp package link to settime(1XNX) was broken. 12. In libc, getdate(3C) and strptime(3C) now interpret years 69-99 as 1969-1999, years 00-68 as 2000-2068 (in accordance with the UNIX98 standard), allowing user account administration menus to accept expiry years 00 onwards. However, note that getdate(3C), like touch(1), rejects UTC times that cannot be stored in 31 bits. The first few weeks of 2038, and the final hours of 1969 in a time zone west of GM are accepted, but most times before 1970 and after 2037 are rejected. 13. Additional fixes to libc's time handling are included, unrelated to the year 2000: mktime(3C)'s normalization of out-of-range tm fields was incorrect near a leap year; mktime(3C)'s decision on tm_isdst (daylight savings) could go wrong; strftime(3C) went wrong on times before 1970 due to bad leap day calculations; and strftime(3C)'s %E era-specific handling depended incorrectly on the %O modifier. 14. In libc, there is also a possibility of buffer overflow in catopen(3C), and of a core dump when memory is exhausted from malloc(3C). 15. SLS PTF3391C supersedes PTF3391A, whose RTC driver caused CMOS corruption on some systems. SLS PTF3391C supersedes PTF3391A and PTF3096, to avoid incompatibility between batch and at (see problem 3). If you have already installed PTF3391A, install PTF3391C only if your system reports CMOS corruption on reboot, or if PTF3096 was installed. SLS PTF3391C contains: /etc/conf/pack.d/rtc/Driver_atup.o /etc/conf/pack.d/rtc/Driver_mp.o /etc/init.d/dstsync /etc/rc0.d/K10dstsync /etc/rc1.d/S10dstsync /etc/rc2.d/S10dstsync /etc/security/audit/auditrpt/auditrptv1 /etc/security/audit/auditrpt/auditrptv4 /udk/usr/ccs/bin/prs /usr/X/bin/NetWare_Access /usr/bin/at /usr/bin/atq /usr/bin/atrm /usr/bin/batch /usr/bin/crontab /usr/bin/ftp /usr/bin/passwd /usr/bin/settime /usr/bin/touch /usr/bin/uustat /usr/ccs/lib/libc.a /usr/ccs/lib/libc.so /usr/ccs/lib/libp/libc.a /usr/ccs/lib/libp/libc.so /usr/lib/acct/acctcms /usr/lib/acct/acctcon /usr/lib/acct/acctcon1 /usr/lib/acct/acctprc /usr/lib/acct/acctprc1 /usr/lib/acct/lastlogin /usr/lib/dstime/dst_sync /usr/lib/libc.so.1 /usr/lib/libc.so.1.1 /usr/lib/libnds.so /usr/lib/locale/sv_FI.437/LC_MESSAGES/Xopen_info /usr/lib/locale/sv_FI.437/LC_TIME /usr/lib/locale/sv_SE.437/LC_MESSAGES/Xopen_info /usr/lib/locale/sv_SE.437/LC_TIME /usr/lib/lp/model/B2.banntrail /usr/lib/lp/model/PS /usr/lib/lp/model/PS-j /usr/lib/lp/model/dosmodel /usr/lib/lp/model/standard /usr/lib/mail/surrcmd/smtpd /usr/lib/uucp/uucico /usr/lib/uucp/uuxqt /usr/sbin/cron /usr/sbin/dsrepair /usr/sbin/in.ftpd /usr/sbin/whodo /usr/ucb/prt /usr/ucb/uptime /usr/ucb/w SLS PTF3391C addresses these SCO tracking numbers: 500289 500598 500615 500721 500752 500762 500824 500825 500858 710125 710232 710324 710341 710342 710343 710344 710349 710350 710352 710477 710606 501076 501079 789 ul96-19301 ul96-24103 ul96-31805 ul97-00709 ul97-05102 ul97-11401 ul97-11504 ul97-11812 ul97-20310 ul97-20544 ul97-28809 ul97-29701 ul97-29703 ul97-29704 ul97-29705 ul97-30203 ul97-30204 ul97-30750 ul98-01623 ul98-02601 ul98-08612 ul98-11103 ul98-18014 ul98-21001 ul98-25001 ul98-25120 ul98-25202 ul98-27802 ul98-28008 ul98-29504 ul98-29507 ul98-32203 ul99-00613 ul99-10401 ul99-10413 ul96-16201 Software Notes and Recommendations ---------------------------------- SLS PTF3391C should only be installed on: SCO UnixWare Application Server Release 2.1.1, 2.1.2 SCO UnixWare Personal Edition Release 2.1.1, 2.1.2 Note that UnixWare 2.1.1 is not supported or warranted by SCO. SCO strongly recommends that you upgrade to SCO UnixWare 2.1.3 by applying the SCO UnixWare 2.1.3 Update and then applying SLS PTF4003C, rather than this SLS, PTF3391C. SLS PTF3391C spans many packages: acp audit base bsdcompat ccs cmds inet jale lp ls merge demerge esmerge frmerge itmerge jamerge nsu nuc nwsrvr nwsrvrJ osmp and the UnixWare/OpenServer Development Kit Release 7.0.0 A fix is only installed from PTF3391C if that file is already installed on the system. A fix is not installed from PTF3391C if another package (SLS, PTF, or the UDK) has already provided that fix to a file. If one of the packages listed above is installed after PTF3391C, then PTF3391C must be reinstalled. If the UnixWare/OpenServer Development Kit 7.0.0 (UDK) is installed after PTF3391C, then PTF3391C must be reinstalled. SLS PTF3391C supersedes PTF3391A, whose RTC driver caused CMOS corruption on some systems. SLS PTF3391C supersedes PTF3391A and PTF3096, to avoid incompatibility between batch and at (see problem 3). If you have already installed PTF3391A, install PTF3391C only if your system reports CMOS corruption on reboot, or if PTF3096 was installed. Installation Instructions ------------------------- 1. Download the ptf3391c.Z file to the /tmp directory on your machine. 2. As root, uncompress the file and add the SLS package to your system using these commands: $ su Password: # uncompress /tmp/ptf3391c.Z # pkgadd -d /tmp/ptf3391c # rm /tmp/ptf3391c 3. Reboot the system after installing this SLS package. The release notes displayed prior to installation can be found in: /var/sadm/pkg/ptf3391/install/ptf3391.txt Removal Instructions -------------------- 1. As root, remove the SLS package using these commands: $ su Password: # pkgrm ptf3391 2. Reboot the system after removing this SLS package. If you have questions regarding this SLS, or the product on which it is installed, please contact your software supplier.