microp@b-tech.UUCP (Microport mailing list) (07/27/87)
This list is targeted towards technical discussions of Microport's Sys V/AT Unix for the IBM PC-AT. It not officially related to Microport Systems Inc. Any input you have should be sent to: seismo!umix!b-tech!microp microp%b-tech.uucp@umix.cc.umich.edu -- Jon Zeeff (b-tech!zeeff) -------------------------------------------------------------------------- From: b-tech!zeeff Subject: Important news about this mailing list I had to cut back the automated mailing of all the back issues because of the volume it was creating. From this site, it is now limited to the 2 most recent issues. Several sites are in the process of setting up archiving, I hope to hear more on this soon. I'm going to be posting this list to the usenet group comp.unix.xenix (for now) so that people with news feeds can read it there. Additional people wanting to join this list should contact one of the following redistribution sites: louden@gateway.mitre.org (internet) seismo!scubed!sdcsvax!amos.ling.LOCAL!sdeggo!dave (southern CA area) tektronix!reed!percival!nerd rutgers!umnd-cs!umn-cs!rosevax!herman!k0jfv!alan (Minneapolis/St. Paul area) ...{gatech,seismo}!meccts!kksys!gk ihnp4!madsen!vijit pst@ai.ai.mit.edu sdcsvax!sdics!nprdc!wulfeck thos@cca.ucsf.edu BITNET: thos@ucsfcca -------------------------------------------------------------------------- Date: Sun, 12 Jul 87 13:16:16 EDT From: umix!CAF.MIT.EDU!soft21.UUCP!root To: umix!b-tech.UUCP!mit-caf!microp Subject: 2.23 Microport just sent the 2.23 release to me. (This is still being tested) The video problem has been fixed! Unfortunately, they sent me a kernel with shared memory etc. turnecd off. They did NOT send a new linkkit. Also, the operator (me) did it again. Is there any way to recover a floppy of data when it's not a valid file system? ---------------------------------------------------------------------------- Date: 14 Jul 87 22:26:31 EDT (Tue) From: lewis@m-net.UUCP The Microport release of the Text Preparation System contains troff with font software for Xerox 9700, Imagen, Autologic APS, Wang CAT, and some support for Tektronix 4015 via the tc postprocessor. Since none of the aforementioned devices will fit conveniently on a table next to my computer, it is not immediately apparent how I might take advantage of all this swell software. Is anyone aware of any troff postprocessors which might be used to drive simple dot matrix printers and console screens (Hercules)? Is anyone working on such a thing for Microport? A crude implementation might be done with a Tektronix screen driver in concert with tc, so if anyone has such a thing, it might also be a candidate. ----------------------------------------------------------------------------- Subject: Re: Microp list From: itivax!umix!seismo!qetzal!root I want to announce the formation of a Microport Users' group and bug list. The purpose of this group is mainly to get Microport to schedule/fix those bugs which you've been living with for the last year. To date, we have received some positive feedback, and I do believe Microport is willing to work with us. They are in the midst of trying to establish a bug-reporting/fixing system where problems don't fall through the cracks! On August 1, I will print out a copy of the list and mail it to management at Microport, along with a letter of explanation. This group is not intended to be adversarial. We simply want these prolems solved! I have also asked Henry Seltzer to send a little note along giving us a status report for this newsletter. When we have more specifics, I'll pass them along. I'm asking all of you to do some things: * Please send me your name/phone/path if you are interested in the list. * Please send me information on all of the bugs you know about. Please be very specific about how to reproduce the problem, what release it ocurrs in. * How urgent is the problem? Do you need it NOW, or the next release? We will do our best to: * Acknowledge receipt of your bugs/give you a bug number. * Let you know as soon as anything is fixed/available. By the way, this list in no way should conflict with this newsletter. It is strictly for bug resolution. Here is a copy of the list right now. Thanks! ------------------------------------------------- Here is the list of bugs which have been submitted thus far. They are not in a format suitable for Microport yet, and must be placed on the forms. Please feel free to elaborate. Send any bugs to isis!qetzal!uportlist or ihnp4!upba!qetzal!uportlist. Bugs already documented by Microport, unless extremely obnoxious, are omitted from this list. 1. dd(1) and mail(1) need to be recompiled with a unsigned long data length so that they don't say wrong things. (5 minute fixes). 2. csh(1) needs to have variables exported properly. This would fix several broken programs that require these variables like newgrp(1). 3. malloc(3) and malloc(3X) produce different results sometimes ending in a core dump (segmentation violation). Working code usig malloc(3) will fail to run when compiled identically with malloc(3X). This is a '286 architechure problem with sbrk(2) that Microport knows about and hates. 4. TSS and double fault panics for seemingly no good reason. No OS should "just crash". Problem still occurrs in 2.2.2. 5. fdisk(1) has some undocumented features like destroying bad sector information when changing partitions. Why does Microport need to use a different means of bad sector forwarding that does the rest of the DOS/ Xenix world? Fdisk(1) should never destroy bad sector information even when the active partion or any other partition boundry is changed. 6. Shell layering is necessary for people on terminals to do efficient development. It was promised in advertising in 8/86 and is still in the to-be-in-the-next-release category. 7. Release of source code for attaching shared memory as the code so far in packaged form is extremely lacking. (Both shmcreate and shmvidkey were buggy and not efficient calls from within C.) 8. Console keys can give too many characters to vi(1). This is a SVr2 bug in vi(1) that uses the alarm call. It could be fixed. Also, vi(1) has a bug in which it will enter ex(1) mode after fast keystrokes (like "yy") even on terminals. 9. Problems with SIO crashes. This is problem #1 for us right now. The system will drop characters at any baud rate over 300, and it doesn't take a lot of coaxing to make it occur (just some load on the serial ports). Also, the system panics in the driver, routine 'rmsd'). Compiler problems -- specifically: 10. Passing (char *) NULL to a function in a large model program can cause a core dump/program abort. This makes some programs, which work under small model, fail under large for no apparent reason. Symptom is that the dump occurs between the function call and the first executable instruction in the function itself (usually a Mem fault or Segv) This blows up a LOT of things, including printf("%s", (char *) NULL) (or equivalent). Since you quite often are in this situation when you are reading/writing files in the standard I/O system, you have to code around the possibility (ie: test first before allowing it to be called). Not nice! One problem with this in particular is that it is not consistant -- at least not in terms of what must precede it to cause a fault. Sometimes it works, sometimes not (more often not). 11. You cannot use an array of pointers to point to >64K of data. This is a very significant irritant. 12. Varargs problems (dumps core on statements using this capability). This may be the same problem as (a), in that the unused arguments are not declared and could default to anything. 13. Potential memory allocation problems -- occasionally a well-behaved program, ESPECIALLY if using Microports' 'improved' malloc library, will core dump for no apparent reason. Investigation with 'sdb' shows that a malloc dumped it, or sometimes a function call will pass junk instead of the values (instant dump if there's a pointer being passed!) 14. Uucp problems -- these have been acknowledged (jmsully@microp), and they have told me that HoneyDanber will be an installable option on release 2.3. This might fix the uucp problem entirely. What I get now is an inordinate number of failed calls, lost packets, etc. Probably at least mildly related to problem (9). Also, core dumps in -x1-9 modes (probably related to one or more of the compiler problems). 15. Providing what you say you will. Specically, we received the dialer upgrade some months ago. The documentation specifically mentions two programs that are not included in the 'upgrade', and this was a PD package! We've also had things 'left out' or 'not included' when we order upgrades, stuff that ANYONE doing development would need -- like a link kit. Then, of course, they want to charge you (again) to complete your order...Along this line is the revelation of problems like the serial panics when asked -- their sales staff has been less than truthful about this stuff with us in the past. If it simply is a case of 'I don't know', then they need more education and/or a current bug list on their desks. 16. 2.2.2's wall is broken. No idea how that happened, but 'wall' now gives a complaint and exits (Bus error - core dumped). 17. Along the same line, so is 'ps' with no arguments (produces nothing, should show your processes.) 'ps' with arguments works fine. New problem with 2.2.2. 18. Sdb will sometimes complain "can't allocate memory for symbol table; Goodbye" Seems as though this is related to the garbaged memory allocation and/or the (char *) NULL problem, as those traps always seem to produce these failures of sdb to read the file. (Note: we have 4.5M of memory here, there is NO reason why SDB cannot get enough core to debug a 250K executable file!) Happens on large model programs only. 19. File systems larger than 300,000 blocks get trashed repeatedly. [Need more info - ed.] 20. The version of easyinstall for 2.2.2 is broken. The shell script crashes after the second question. 21. The documentation is extremely inadequate when attempting to install a secondary hard disk. I've destroyed the partition table on my PRIMARY hard disk numerous times. 22. The requirements for adding additional memory cards to the system needs to be stated. NMI errors occur if the wrong types of cards are used. 23. Many if not all shell scripts distributed do not include a ':' character at the beginning. This means that the user must edit each shell script when it is distributed so that it will run under csh. 24. System will panic if the line printer is switched off during printing. This problem is reproducible. I hope YOUR printer doesn't suddenly run out of paper. 25. vi will hang occasionally when editing text files. Half of the file will be displayed, vi will not then respond to any keystrokes. User must log on to another tty then kill -9 the process, then do stty to restore sanity. This problem is not easily reproduced. 26. Cron likes to fire up jobs more than once. This is very nasty when the job scheduled to run is rnews. 27. Microport clock still can not keep sane time. The clock worked lots better in 1.3.8. This becomes a real pain when using nifty things like pc-pursuit which one must'nt call at the wrong time. 28. Preconditions for re-linking the kernel are not well documented. You must be using /bin/sh, and the variable SHELL must be set to /bin/sh. 29. When compiling a few large programs (hack, jove) I found that ld will hang if there is no space left on the disk. It would be nice if microport had provided a "no space left" message on the system console. [ed. 30. 2.2 still doesn't work with Bell Tech drive as a second drive mounted on /usr.] ---------------------------------------------------------------------- P.S. Workarounds will be posted to the net/microp list as soon as available. Robert C. White, Jr. Graphics Information, Inc. **************** UUCP: ihnp4!upba!qetzal!rcw isis!qetzal!rcw * OIL/GAS/LAND * USPS: 3067 Robin Way, Denver, CO 80222 * CARTOGRAPHY * ATT : +1 303 759-3666 **************** ---------------------------------------------------------------------------- From: umix!MCC.COM!ghostwheel.DB.MCC.COM!dan To: umix!MCC.COM!umix.cc.umich.edu!b-tech.UUCP!root Subject: News letter By the way, I've diddled with Unify under Microport a bit (used it as a database for my wedding). It's real easy to set up an application, and the database itself is pretty quick, but it core dumps on a VERY regular basis. This was version 3.6 for the 6300+; perhaps there is a later one that doesn't bite the big one, leaving records locked. Among the core dump locations are: using the full screen interface to modify a record, and using the full screen interface to print a report. You know, the sort of stuff you don't do very often :-). Also, there is a bug in the record locking that lets you update locked records from SQL. This is NOT a feature, near as I can tell. SQL knows about the locks - you can tell that because it won't let you delete locked records. The fact that you can modify them seems to be an oversight. Also, SQL appears to have a bug, in that the UNIQUE keyword is ignored within the inner query of a nested query. For example: select count(*) from customer where cust_num in select unique (cust_num) from customer, order where cust_num = order_cust_num/ Theoretically, the inner query should generate a set of customer numbers, with duplicates removed. The outer query then selects a set of customer records whose customer numbers are in that set, and counts them (you have to go through these contortions because you can't use the UNIQUE keyword with an aggregate function like COUNT). When the inner query is run by itself, it generates a duplicate free set of customer numbers. When the entire query is run, the count is too high if there is more than one order per customer (i.e. duplicates are not being removed from the inner query any more). I wouldn't use Unify for a critical business application (are there any NON-critical business applications?). But then, I'm just fussy that way. -- Dan