rcodi@chudich.co.rmit.oz (Ian Donaldson) (11/17/89)
como@max.bnl.gov (Andrew T. Como) writes: > Has anyone heard when the release of Umax4.3 is going to >be out. It was due in October and I have heard nothing yet. Does anybody know if it supports more than 64k of shared memory? (Umax 4.2 had this limitation and it was the *only* reason we went to Umax V; regretting it ever since) Ian D
lawley@cs.mu.OZ.AU (Michael Lawley - ELISPer) (11/17/89)
On 17 Nov 89 00:15:48 GMT, rcodi@chudich.co.rmit.oz (Ian Donaldson) said: > Sender: news@minyos.xx.rmit.oz > Does anybody know if it [Umax 4.3] supports more than 64k of shared memory? > (Umax 4.2 had this limitation and it was the *only* reason we went > to Umax V; regretting it ever since) > Ian D Funny, we did exactly the same thing; regretting it ever since. (Although working from within emacs takes away a lot of the pain of SysV != BSD.) I wonder if this has been a common path for Multimax users? mike -- /-------------------------------------------------------\ | If lawley@cs.mu.OZ.AU doesn't work, try: | | | | ACSnet: lawley@munnari.oz | | UUCP: {uunet,ukc,ubc-cs,mcvax}!munnari!lawley | | ARPA: lawley%munnari.oz.au@uunet.uu.net | \-------------------------------------------------------/
goldman@maxzilla.encore.com (Steve Goldman) (11/17/89)
From article <1761@minyos.xx.rmit.oz>, by rcodi@chudich.co.rmit.oz (Ian Donaldson): > como@max.bnl.gov (Andrew T. Como) writes: >> Has anyone heard when the release of Umax4.3 is going to >>be out. It was due in October and I have heard nothing yet. > > Does anybody know if it supports more than 64k of shared memory? > > (Umax 4.2 had this limitation and it was the *only* reason we went > to Umax V; regretting it ever since) > > Ian D Huh? I don't know of any such limitation on Umax4.2. I've run programs on Umax4.2 that used many megabytes of shared memory as far back as early 1986. There must be more to this story... Steve Goldman, Encore Computer Corp (919) 481-3730 901 Kildaire Farm rd., bldg D Cary, NC 27511 USA arpa: goldman@encore.com uucp: {bu-cs,decvax,gould}!encore!goldman
.com (Steve Goldman) (11/17/89)
From article <1761@minyos.xx.rmit.oz>, by rcodi@chudich.co.rmit.oz (Ian Donaldson): > como@max.bnl.gov (Andrew T. Como) writes: >> Has anyone heard when the release of Umax4.3 is going to >>be out. It was due in October and I have heard nothing yet. > > Does anybody know if it supports more than 64k of shared memory? > > (Umax 4.2 had this limitation and it was the *only* reason we went > to Umax V; regretting it ever nince) > > Ian D Huh? I don't know of any such limitation on Umax4.2. I've run programs on Umax4.2 that used many megabytes of shared memory as far back as early 1986. There must be more to this story... Steve Goldman, Encore Computer Corp (919) 481-3730 901 Kildaire Farm rd., bldg D Cary, NC 27511 USA arpa: goldman@encore.com uucp: {bu-cs,decvax,gould}!encore!goldman
como@max.bnl.gov (Andrew T. Como) (11/17/89)
como@max.bnl.gov (Andrew T. Como) writes: Has anyone heard when the release of Umax4.3 is going to >be out. It was due in October and I have heard nothing yet. > > Does anybody know if it supports more than 64k of shared memory? > > (Umax 4.2 had this limitation and it was the *only* reason we went > to Umax V; regretting it ever since) > > Ian D Huh? I don't know of any such limitation on Umax4.2. I've run programs on Umax4.2 that used many megabytes of shared memory as far back as early 1986. There must be more to this story... Steve Goldman, Encore Computer Corp (919) 481-3730 901 Kildaire Farm rd., bldg D Cary, NC 27511 USA arpa: goldman@encore.com uucp: {bu-cs,decvax,gould}!encore!goldman ======================================================= This is typical of Encore....Goldman look at the original posting. When is bsd4.3 and nfs client coming out. Many sites are being very patient and AGAIN Encore is making promises it cannot keep. We bought NFS in July of 1988 and nothing yet with the client. como@bnl.gov BITNET: como@bnl.BITNET UUCP: ....philabs!sbcs!bnl!como
jdarcy@pinocchio.encore.com (Jeff d'Arcy) (11/18/89)
como@max.bnl.gov (Andrew T. Como): > Has anyone heard when the release of Umax4.3 is going to > be out. It was due in October and I have heard nothing yet. someone else [attribution lost]: > Does anybody know if it supports more than 64k of shared memory? > > (Umax 4.2 had this limitation and it was the *only* reason we went > to Umax V; regretting it ever since) goldman@encore.com (Steve Goldman): > Huh? I don't know of any such limitation on Umax4.2. I've run programs on > Umax4.2 that used many megabytes of shared memory as far back as early 1986. > There must be more to this story... Andrew Como: > This is typical of Encore....Goldman look at the original > posting. > > When is bsd4.3 and nfs client coming out. Many sites are > being very patient and AGAIN Encore is making promises it cannot keep. > > We bought NFS in July of 1988 and nothing yet with the client. At risk of getting myself in trouble by being rude to a customer... I don't know Steve Goldman or what role he serves at Encore. It seems to me that he's trying to gather information that will allow him to answer *one* of the questions posed here. It's completely unfair to expect that he should therefore answer *all* of the above questions. Mr. Como, would you perhaps prefer that Mr. Goldman provide premature answers regarding problems that are outside his area? I think that the complaints we've seen from others in this group refer to *exactly* that behaviour, and you shouldn't encourage it. We're all in this together, folks. Like everyone else I see around me, I want Encore's customers to be happy. I'd like this newsgroup to become a forum where Encore customers, developers, support and sales people, etc. can discuss issues in a mutually beneficial manner. Somehow I don't think that taking pot-shots at any Encore employee unfortunate enough to speak up will help anyone. Considering the forum, I'd like to strengthen my usual disclaimer. The thoughts I've expressed in this article are *entirely* my own; they do not represent Encore's official policy or the beliefs of any other Encore employee in any way or to any degree. Jeff d'Arcy OS/Network Software Engineer jdarcy@encore.com Encore has provided the medium, but the message remains my own
dwm@pinocchio.Encore.COM (Dave Mitchell) (11/18/89)
>> Does anybody know if it supports more than 64k of shared memory? >> >> (Umax 4.2 had this limitation and it was the *only* reason we went >> to Umax V; regretting it ever since) >> > > Huh? I don't know of any such limitation on Umax4.2. I've run programs on >Umax4.2 that used many megabytes of shared memory as far back as early 1986. The second poster's answer is alluding to the use of the share(2) system call - indeed there is no built in limit to the use of shared memory. But, the first poster's question is apparently asking about the sysV compatible shmop(2) routines. This limit is built into the system configuration program, sysparam(8), and there is no particular reason for its (the limit's) existence. You should talk to customer service, and request a custom version of sysparam to work around your problem - it's a very simple change. dave Dave Mitchell Usenet: ...!{bu-cs,decvax,necntc,talcott}!encore!dwm Internet: dwm@encore.com *<8-O) Yow!
prc@erbe.se (Robert Claeson) (11/19/89)
In article <LAWLEY.89Nov17135939@mullauna.cs.mu.OZ.AU>, lawley@cs.mu.OZ.AU (Michael Lawley - ELISPer) writes: > > (Umax 4.2 had this limitation and it was the *only* reason we went > > to Umax V; regretting it ever since) > > Funny, we did exactly the same thing; regretting it ever since. (Although > working from within emacs takes away a lot of the pain of SysV != BSD.) I > wonder if this has been a common path for Multimax users? Even more funny, we went to UMAX V about one year ago and haven't regret it since then. And the latest version of UMAX V, 2.2, even includes a complete 4.3BSD environment with all 4.3BSD libraries, system calls, commands, job control, nroff/troff/ditroff, merged SYSV/BSD tty drivers and tape device drivers and more. No, I'm quite happy with UMAX V (but then, I often have the /bsd directory hierarchy first in my PATH). -- Robert Claeson E-mail: rclaeson@erbe.se ERBE DATA AB
rcodi@chudich.co.rmit.oz (Ian Donaldson) (11/20/89)
dwm@pinocchio.Encore.COM (Dave Mitchell) writes: >>> Does anybody know if it supports more than 64k of shared memory? >>> >>> (Umax 4.2 had this limitation and it was the *only* reason we went >>> to Umax V; regretting it ever since) > But, the first poster's question is apparently asking about > the sysV compatible shmop(2) routines. This limit is built > into the system configuration program, sysparam(8), and > there is no particular reason for its (the limit's) > existence. We tested both share(2) and shmop(2) and both would give us no more than 64k. 64k appeared to be the limit that sysparam(8) would give us. Not having access to include files documenting the format of /Umax.param didn't help any. > You should talk to customer service, and request a custom > version of sysparam to work around your problem - it's > a very simple change. Now thats more like it! A decent answer. FLAME ON What I want to know is why a previous poster from Encore claims that the problem has been fixed in 1986 and its 1989 (thats 3 years later!) that we receive a software release and it STILL isn't fixed!! FLAME OFF Would somebody at Encore be willing to mail an tar'd/uuencoded binary of such a sysparam(8) utility to me please (for Umax 4.2, rel 3.3.0, for APC's, which is the latest we had until we switched)? If we can get a new sysparam(8) that lets us have more than 64k shared memory we will probably switch back to Umax 4.2 . FLAME ON We told our vendor of this problem and gave them several weeks to come up with the answer. We repeatedly asked them to tell us on progress of the request and insisted it was the prime reason we couldn't make use of the 64MB memory that we bought. (its a research machine for parallel processing architectures) What the hell happened I don't know, but we didn't get one, so we were forced by this action to switch from our quite reliable Umax4.2 to a very buggy UmaxV. It now crashes one or two times a day for various reasons (lately mostly due to runaway processes filling up the swap devices, requiring a reboot to clear it... we have 192Mb of swap; the rest of the time it crashes due to kernel bugs, mostly activated by processes using lots of shared memory; and then there's those processes that are stuck in the run state and are unkillable, unreschedulable, but just renicable, hogging our cpus; and then theres the problems with pty's due to a lack of a vhangup(2) after rlogind opens them... letting other people access your session and shell!!!; the list is VERY long... [we're running 2.2h]) FLAME OFF Is there a customer support service for Encore customers via email? (DIRECT to Encore, NOT via vendors) I fear our bug reports are NOT getting through to the right people. (yes we have full software and hardware maintenance) Ian D BTW: what is the current release number for Umax 4.[23] (a proper release, not a beta release)
rcodi@chudich.co.rmit.oz (Ian Donaldson) (11/22/89)
prc@erbe.se (Robert Claeson) writes: >Even more funny, we went to UMAX V about one year ago and haven't regret it >since then. And the latest version of UMAX V, 2.2, even includes a complete ^^^^^^^^??? >4.3BSD environment with all 4.3BSD libraries, system calls, commands, job ^^^^ ???? >control, nroff/troff/ditroff, merged SYSV/BSD tty drivers and tape device >drivers and more. No, I'm quite happy with UMAX V (but then, I often have the >/bsd directory hierarchy first in my PATH). This is FAR from correct. Sure, under 2.2f, there are lots of BSD things, but the set is far from complete. For instance, the following indicates incompatability with BSD: cc no -M option chgrp no -R option chmod no -R option chown no -R option, can't set group & user at the same time cp no -p option df it reports 512 byte blocks, not 1k, output format is totally different du it reports 512 byte blocks, not 1k, doesn't work right over NFS last doesn't exist lastcomm doesn't exist lpc doesn't exist lpq doesn't exist lpr doesn't exist lprm doesn't exist lptest doesn't exist ls (it reports 512 byte blocks in the -s option, doesn't do multi-column output if output is to a tty, -g option default reversed) make pmake is closest (we symlink it to make) man SV man. Yuk! It doesn't even invoke a pager! mkdep doesn't exist pac doesn't exist ping doesn't exist ---<< serious deficiency pwd broken on NFS filesystems (it just hangs) ranlib doesn't exist (we've got a 1-line script to replace it) su doesn't check for group wheel permission before su to root doesn't set the environment to the target user tip doesn't exist gcore doesn't exist pi/px/pdx doen't exist dbx doesn't exist (cdb has a few dbx commands, but not many) script doesn't exist window doesn't exist users doesn't exist w doesn't exist pstat doesn't exist quotackeck -- the one supplied generates bad counts for random users binmail has serious security problems. ucbMail invokes the wrong vi (the AT&T one) which doesn't know about job control ps is the SV version... how do you tell the RSS of a process? vmstat doesn't exist (sar is not quite as nice & compact) iostat doesn't exist (sar is not quite as nice & compact) Now many of the above we ported from 4.3-tahoe to 2.2f and 2.2h, just to make the machine bearable. The lack of BSD network line printer system is really sad. We ported Berkeley lpd (after hacking it due to lack of Unix domain sockets) The above list isn't complete either. There are lots of other BSD things missing. We only ported the things we needed most. In addition, one MAJOR problem with UMAXV is that ordinary users can't mv directories around, other than rename them. Even over NFS!! Also, there are 2 rename(2) system calls (one in the AT&T library, and one in the BSD) and BOTH of them don't work, forcing you to write your own using link(2)/unlink(2) stat(2) returns bogus numbers for the blocks in a file, even over NFS, making du and 'ls -s' over NFS useless. We even ported 4.3-tahoe csh as the one supplied hung under 2.2f and crapped out under 2.2h (the problem is that the Encore C compiler is being smart with register allocation, which csh can't tolerate without modification.... use -q nocompilerregisters to work around it) The way BSD is merged with AT&T on the Encore leaves lots to be desired. For instance, many routines (such as statfs(2), ftok(3)) are only in the AT&T libraries, and you can't link code that is compiled in one universe with libraries compiled in the other due to kernel struct differences (mainly due to two different stat(2) structures). The way Sun have put it together in SunOS is FAR superior, although they started from BSD and added SV in where necessary. UMAXV is the reverse. However I must praise Encore for fixing a few major bugs for 2.2h that were present in 2.2f (eg: rlogind importing TERM). The list of bugs is still huge however. A few things broke in 2.2h too, notably NFS client mode and symbolic links, making NFS client mode useless and impossible to use in our environment (and probably everybody elses' too). NFS server mode is almost OK however except for lack of mv'ing directories and the blocksize reported by stat(2). Also, truncate(2) doesn't work over NFS and certain files (eg: a.out files) get mode 777 when you create them over NFS for some odd reason, indicating some low level NFS bug. Enough! Ian D