Path: utzoo!utgpu!watserv1!watmath!att!dptg!ulysses!andante!mit-eddie!snorkelwacker.mit.edu!usc!sdd.hp.com!uakari.primate.wisc.edu!aplcen!aplcomm!uunet!ncrlnk!wright!dcourte From: dcourte@valhalla.wright.edu (Dale Courte) Newsgroups: comp.sys.encore Subject: Misc. Umax 4.3 Problems Message-ID: <1990Nov19.182329.868@cs.wright.edu> Date: 19 Nov 90 18:23:29 GMT Sender: dcourte@cs.wright.edu (Dale Courte) Organization: Wright State University Lines: 119 (I am sorry if this is posted multiple times. We are experiencing some posting problems here.) Before I start a game of phone tag with Encore, I thought I'd find out if the following are "known bugs". Below I describe several problems I have been encountering under Umax 4.3. Feel free to provide any help or guidance if any of you have had similar problems. We have a Multimax 320, 2 APC boards, 64 Meg, and 2 NEC 650 Meg drives. 1) Problems with 'dump'. I have encountered two problems with the 'dump' program distributed with 4.3. Oe of them is minor, the other caused me a couple of days work. First, dump seems more liberal in determining how much can fit onto a tape than the previous (4.2) version. Using the same tapes we had been using in backup rotation for about two years, suddenly dump would write clear to the end of tape, at which point a write error would occur. This happenen at least three weeks in a row during routine backups. The problem was solved by using the -s option and giving a size of 2150, rather than 2300 for tape length. Secondly, I discovered the hard way that the new dump program does not seem to be writing end-of-file markers at the end of all but the last volume in multiple-volume dumps. I backed up all file systems, repartitioned the disks, and attempted a restore. Restore failed with a read error at the end of the first tape volume for both file systems I had backed up. This was a near disaster, as these were user file systems. I then did some investigating and found that all weekly backups done since 4.3 was installed had the same problem (A simple 'dd if=/dev/rtape of=/dev/null' resulted in a read error at the end of tape each time). So, I had no immediate backup of the file systems I had repartitioned, and no usable weekly backups. After considerable head-scratching, I discovered that if I ran these tapes out to the point of error, without rewind, then used mt to backspace two records and write an end-of-file mark, the tapes could be used. I have since resorted to using the old (4.2) version of dump, reloaded from tape. Anyone have a clue on this? 2) Problems with rmt. We recently purchased and installed NFS on our Multimax in the hopes that we could mount remote file systems that cost much less per byte than any storage options available from Encore. The plan was to have backups done across the net via rdump on the file server. The server in this case is a DECstation 3100, but in testing we have found identical problems to occur with a VAXstation 3100 and a SUN 3 system. The problem is best shown by an example: zebra # rdump 0of /deeve:/dev/rtape /dev/rz1a DUMP: Date of this level 0 dump: Tue Oct 23 09:16:17 1990 DUMP: Date of last level 0 dump: the epoch DUMP: Dumping /dev/rrz1a (/) to /dev/rtape on host eve DUMP: Mapping (Pass I) [regular files] DUMP: Mapping (Pass II) [directories] DUMP: Estimates based on 2300 feet of tape at a density of 1600 BPI... DUMP: This dump will occupy 905 (10240 byte) blocks on 0.23 tape(s). DUMP: Protocol to remote tape server botched (in rmtgets). Lost connection to remote host. Try using the -o option. The -o option is an Ultrix option to allow for "non-Ultrix" systems. Note that the option is already being used, so the message suggesting it can be ignored. Note also that the same problem occurs from a SUN 3 system, which rules out the possibility of an Ultrix compatibility problem. This could be a big problem, becuase the only other way I have to back up a Gigabyte of storage is via a _very_ slow DEC TK50 drive. Again, any info would be appreciated. 3) Problems with the new 'date' program. The 4.3 date program does not seem to want to realize daylight savings time. The paramter in /Umax.param is set to indicate EDT, but date will only display EST. If I set the time and display it with the old (4.2) date program, it displays one hour ahead of what the new 'date displays, and clearly indicates EDT, while new date will only display EST. 4) New sh very slow. This isn't really a big problem, but tests I have run on several scripts I run frequently show that the new sh is very slow compared to the old sh. using 'time' to time the scripts under both shells has revealed a slowdown of nearly 100%. The slow down is significant enough that I have put "#!/usr/old/sh" in most of my scripts. Anyone else encounter this? 5) Looking for a "watcher" program. Untamo has broken. I had been using a pd piece of software named 'untamo' to log idle users off the system. This seems to have broken under 4.3. I can start the daemon. It works for a while, then seems to just hang. Goes into a permanent wait state of some kind. Never logging anyone off, and never using any additional CPU time. Does anyone have any alternative daemons they use for this task. Right now I am doing it by hand. Sorry to be so long winded here, but I have been saving these up. All in all, 4.3r4.0 has been quite reliable for a major release ending in '.0', and I do not mean for this posting to indicate I am unhappy with it. My only complaint is that resolving problems via Encore's 1-800 number is often slow and tedious (numerous phone calls, having to re-explain the problem multiple times, etc.). Is there an electronic alternative to the 1-800 number at Encore? -Dale Courte Wright State University CSNET: dcourte@eve.wright.edu -- ----------------------------- ------------------------------------- Dale Courte CSNET: dcourte@eve.wright.edu University Computing Services BITNET: dcourte@wsu Wright State University UUCP: ..!uunet!ncrlink!wright!dcourte