68K XENIX 3.2 bugs

uhclem at trsvax.UUCP uhclem at trsvax.UUCP
Fri Apr 29 03:39:00 AEST 1988



<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



More information about the Comp.unix.xenix mailing list