mikes@ncoast.UUCP (Mike Squires) (04/26/88)
I have heard of the following bugs in XENIX 3.2: 1. The tsh restore won't pick files off a disk; must use tar instead. (This was not broken under XENIX 3.1.x). 2. The /etc/inittab option for getty passes parameters to getty incorrectly; fix requires getty sources. 3. The 3.2 time function and software created under 3.1 and earlier XENIX systmes are incompatible; between the current date for the change to daylight saving and the old date the "date" command yields the correct date but uucp, cron, etc., report standard time. Fix: lie about whether daylight saving time applies and the location when setting time zone. 4. My own experience suggests that 3.2 z80ctl is more sensitive to timing problems; two 12 with 6000 upgrades glitched with strange HD errors (including an inability to read track 32000 and something) but both systems have been rock solid before under 3.1.2. Minor problems: 1. help files are not included with new OS, not even those commands that are updated or completely new. 2. Install disks are identified in such a way as to lead the unwary to attempt to install the wrong disks, leading to major hassles. 3. tar install disks are DS, not SS; no II upgrades need apply (the letter sent out says that only 6000's are now supported). Questions: where is the MMU? Now that the whole 6000 world knows about it it would seem that release is imminent. Also, how about the 3.2 developement system (especially inlight of (3) above. Mike Squires Allegheny College Meadville, PA 16335 814 724 3360 uucp: ..!mandrill!ncoast!{mikes,peng!sir-alan!mikes} or ..!pitt!sir-alan!mikes BITNET: mikes%sir-alan@pitt.UUCP (VAX) MIKES AT SIR-ALAN!PITT.UUCP (IBM)
uhclem@trsvax.UUCP (04/29/88)
<Crossposted response from comp.sys.tandy> <> B>ncoast.UUCP!mikes writes regarding: "68K XENIX 3.2 bugs" B>I have heard of the following bugs in XENIX 3.2: B> B>1. The tsh restore won't pick files off a disk; must use B> tar instead. (This was not broken under XENIX 3.1.x). There is an easy workaround. Add a null option like: restore :0 -ds - /foofile ^ B>2. The /etc/inittab option for getty passes parameters to getty B> incorrectly; fix requires getty sources. Another easy workaround. Put one space (blank) after each inittab entry that does not have a parameter. By the way, both of these problems were discovered in-house. Up to now, no one has reported them to Customer Service. Sadly, problems reported on the net are usually not turned into official problem reports. So if you don't report them to Customer Service by phone or letter, they may never be listed as field complaints and may result in no future updates. B>3. The 3.2 time function and software created under 3.1 and earlier B> B> XENIX systmes are incompatible; between the current date for the B> change to daylight saving and the old date the "date" command B> yields the correct date but uucp, cron, etc., report standard B> time. Fix: lie about whether daylight saving time applies and B> the location when setting time zone. Now, that is a bit unfair, since those programs come with the development system, and it was last released in 1985. Keep in mind that the kernel in ALL UNIX/XENIX systems keep the time in seconds (or some unit) since the "beginning" at GMT. It is up to *each* program to do the conversion to local time and most use the standard library which is linked into each program. So each program has to be relinked (at minimum) to become aware of new time conventions. Contact Bell Labs about the dumb handling of time conversions in UNIX/XENIX if you don't like this. The 3.2 development system upgrade is scheduled to update all programs in XENIX which need the new date algorithms. You also get the libraries and can relink any applications that you have .o's for. Applications bought from companies that are no longer supporting the machine or who did not provide the .o's will be stuck with old DST rules. B>4. My own experience suggests that 3.2 z80ctl is more sensitive to B> timing problems; two 12 with 6000 upgrades glitched with strange B> HD errors (including an inability to read track 32000 and something) B> but both systems have been rock solid before under 3.1.2. If you haven't reported this problem(s) to Customer Service, your chances of seeing a fix (if needed) is low. (Private mail continues this discussion.) B>Minor problems: B> B>1. help files are not included with new OS, not even those commands B> that are updated or completely new. Since the help system contains pages on the complete XENIX system, the help pages were delayed until the 3.2 development system was finished. The upgrade does include printed pages on all new commands, even if they go in the sections of the manuals that do not come with the core. I assume you have called or written to the product buyer to tell him/her that you *want* help pages. No requests or demand, no product. B>2. Install disks are identified in such a way as to lead the unwary to B> attempt to install the wrong disks, leading to major hassles. "Upgrade", "Install 1", "Install 2", "File Maintenance", "Boot". Dunno, seems straightforward to me. All prompts call out disks by name and there is an upgrade procedure in the documentation. (The "Disk n of 5" is to assure you get all the disks in the package and does not indicate loading order for all situations. If you are upgrading, start with Upgrade. If starting with a new system, start with Boot.) B>3. tar install disks are DS, not SS; no II upgrades need apply (the B> letter sent out says that only 6000's are now supported). The idea was that most people had double sided drives and we could reduce the cost of the release by using double sided media (five vs seven disks). The small group of Model II owners who still did not have double sided drives can contact Customer Service for the single-sided install disks (four). (I think all you need is proof of purchase of the upgrade. Contact them for details.) B>Questions: where is the MMU? Now that the whole 6000 world knows about it B>it would seem that release is imminent. Also, how about the 3.2 developement B>system (especially inlight of (3) above. Seems like the MMU should be ready. It isn't. The 6000, and anything for it is not #1 in the eyes of the people who set priorities for building the gadgets. MicroChannel(tm) and all other PC-clone projects take precedence. In recent weeks it started making progress again, (possibly because of Tangent) and my guess would be that a store might take an order during the summer. <This information is provided by an individual and is not nor should be construed as being provided by Radio Shack or Tandy Corp. Radio Shack/Tandy Corp has no obligation to support the information provided in any way. Most of the company secretaries have already disavowed all knowledge of me anyway.> "Thank you, Uh Clem." Frank Durda IV @ <trsvax!uhclem> ...decvax!microsoft!trsvax!uhclem ...convex!infoswx!hal6000!trsvax!uhclem ...sys1!hal6000!trsvax!uhclem