campbell@maynard.BSW.COM (Larry Campbell) (12/30/86)
I'm finally undergoing the pain of switching from V7 to System V, and I'm
not convinced it's an improvement. I'll confine this posting to my most
pressing complaint - ulimit.
For those fortunate enough not to have encountered System V, it has a thing
called "ulimit" which is a per-process limit on the maximum size a file can
attain. It is inherited from your parent, and the default on my system
(Microport) is 2048 blocks, or one lousy megabyte.
What really hurts is that there appears to be NO WAY to alter this default
value. Sure, you can change it for yourself and your children, but there
seems to be no way to globally remove the limit, or to set it to a reasonable
value. The obvious (to me, anyway) solution would be a special type of entry
in inittab -- since init is the grandpappy of all processes, if init changes
its ulimit, all processes inherit the change. But I sure can't find anything
in the manual about an inittab entry to set the ulimit.
Is there really no way short of patching the kernel (gag, choke) to change
the system-wide default ulimit? Is the rest of System V as poorly thought
out as this "feature" would portend?
It's amusing to note that my SYSLOG file (on my V7 system) is now (at month's
end) over 1.2 megabytes, which wouldn't fly under System V.
--
Larry Campbell The Boston Software Works, Inc.
Internet: campbell@maynard.bsw.com 120 Fulton Street, Boston MA 02109
uucp: {alliant,wjh12}!maynard!campbell +1 617 367 6846
ARPA: campbell%maynard.uucp@harvisr.harvard.edu MCI: LCAMPBELLcampbell@maynard.BSW.COM (Larry Campbell) (01/02/87)
Many thanks to all those people, too numerous to reply to individually,
who responded to my plaint about ulimit. Everyone considered ulimit
to be a pain (are you listening, AT&T?). It's an extremely poor
substitute for disk quotas.
Many people suggested workarounds that are embarrassingly (because I
should have thought of them) obvious. These generally involve writing
a substitute for /etc/init or /bin/login, that set ulimit to a
reasonable number then exec the real init or login. One of these
approaches should solve the immediate problem - uucp'ing a large file
to my SysV system.
Again, thanks to all those who responded.
--
Larry Campbell The Boston Software Works, Inc.
Internet: campbell@maynard.uucp 120 Fulton Street, Boston MA 02109
uucp: {alliant,wjh12}!maynard!campbell +1 617 367 6846
ARPA: campbell%maynard.uucp@harvisr.harvard.edu MCI: LCAMPBELLdet@herman.UUCP (Derek Terveer) (01/02/87)
You can change the system-wide default value for ulimit by, assuming of course that you have a source code license, changing a constant in the unix source and simply recompiling. I believe the constant is called MAXWRITE or something like that. If you really want to know the details, get back to me.
paul@devon.UUCP (Paul Sutcliffe Jr.) (01/04/87)
In article <790@maynard.BSW.COM>, campbell@maynard.BSW.COM (Larry Campbell) writes: > [ complaining(?) about ulimit ] > > What really hurts is that there appears to be NO WAY to alter this default > value. Sure, you can change it for yourself and your children, but there > seems to be no way to globally remove the limit, or to set it to a reasonable > value. The obvious (to me, anyway) solution would be a special type of entry > in inittab -- since init is the grandpappy of all processes, if init changes > its ulimit, all processes inherit the change. But I sure can't find anything > in the manual about an inittab entry to set the ulimit. The problem here is that ulimit is a builtin to the Bourne shell (the csh does not know about ulimit, but does honor the default). At a place I work that used to sell Onyx, we did put a line similar to this in the inittab file: 2:02:/usr/bin/ulimit 8192 /etc/getty 5 tty02 (Onyx used System III, so the inittab syntax is a little different from SysV). This required an "external" program to set ulimit. When we encountered the same problem you're having with XENIX V, I wrote a ulimit program that did the same actions as the Onyx one. XENIX does not have an inittab, so I implemented it differently, but it does work. If anyone is interesed in the code, send me mail. If I get enough requests, I post the source to net.sources (mod.sources if I get around to creating a man page!). > It's amusing to note that my SYSLOG file (on my V7 system) is now (at month's > end) over 1.2 megabytes, which wouldn't fly under System V. It's also interesting to note that _any_ process running as set[e]uid root does not adhere to the ulimit value (e.g. can write to any size file). -paul -- Paul Sutcliffe, Jr. UUCP: {seismo,ihnp4,allegra,rutgers}!cbmvax!devon!paul Devon Computer Services COMPUSERVE: 76176,502 Allentown, Penna. Sarek: "Any message for your mother, Spock?" +1 215 398 3776 Spock: "Yes. Tell her 'I feel fine.'"
guy%gorodish@Sun.COM (Guy Harris) (01/05/87)
> You can change the system-wide default value for ulimit by, assuming of > course that you have a source code license, changing a constant in the > unix source and simply recompiling. I believe the constant is called > MAXWRITE or something like that. Nothing so straightforward; it's called CDLIMIT. One hopes that in S5R3 they've at least come to their senses to the extent of making it a constant tunable without source (one *could* hope they realize that the "ulimit" scheme is the wrong solution, implement quotas instead, and either crank the default ulimit up to 2^31-1 or set it to 0 and have that mean "no limit").
james@bigtex.uucp (James Van Artsdalen) (01/05/87)
IN article <166@herman.UUCP>, det@herman.UUCP (Derek Terveer) wrote: >You can change the system-wide default value for ulimit by, assuming of course >that you have a source code license, changing a constant in the unix source and >simply recompiling. I believe the constant is called MAXWRITE or something >like that. If you really want to know the details, get back to me. It isn't even necessary to have a source code license. For the record, all that appears necessary is to up the ulimit in rc2 so that cron and processes cron runs hvae a higher ulimit, and to modify one of the public domain login programs to up the ulimit. The cron ulimit should be as high or higher than the ulimit for any user from login; if not, there is a problem trying to run "at" or "batch" jobs (or you could modify /usr/lib/cron/.proto I suppose). -- James R. Van Artsdalen ...!ut-sally!utastro!bigtex!james "Live Free or Die" Voice: (512)-323-2675 Modem: (512)-323-2773 5300B McCandless, Austin TX 78756
james@bigtex.uucp (James Van Artsdalen) (01/05/87)
IN article <196@devon.UUCP>, paul@devon.UUCP (Paul Sutcliffe Jr.) wrote: > The problem here is that ulimit is a builtin to the Bourne shell (the > csh does not know about ulimit, but does honor the default). csh does not exactly have a choice in whether or not to obey the ulimit. And I don't see what the built-in command ulimit has to do with the problem. > It's also interesting to note that _any_ process running as set[e]uid > root does not adhere to the ulimit value (e.g. can write to any size > file). It is indeed interesting, as root *does* adhere to the ulimit in System V (unless vendors outside AT&T have changed the code from S5r2.0.4). Set "ulimit 50" from root and try to "cat big_file >/tmp/q" and cat will return an error. cpio also catches the error (I have run into this more than once working with very large backup files). It makes no difference whether or not uid == euid. -- James R. Van Artsdalen ...!ut-sally!utastro!bigtex!james "Live Free or Die" Voice: (512)-323-2675 Modem: (512)-323-2773 5300B McCandless, Austin TX 78756
mark@cogent.UUCP (Mark Steven Jeghers) (01/06/87)
In article <210@bigtex.uucp> james@bigtex.UUCP (James Van Artsdalen) writes: > >It isn't even necessary to have a source code license. For the record, all >that appears necessary is to up the ulimit in rc2 so that cron and processes >cron runs hvae a higher ulimit, and to modify one of the public domain login >programs to up the ulimit. We moved the login object file to ``login2'' and made a new program called ``login'' which simply set ulimit to our wishes and exec'ed to ``login2''. However, we didn't get cron and other daemons to use a higher ulimit as you've mentioned above, and we probably should have. -- +----------------------------------------------------------------------------+ | Mark Steven Jeghers ECHOMPGULP - process has eaten it | | cryptography, terrorist, DES, drugs, cipher, secret, decode, NSA, CIA, NRO | | | | {ihnp4,cbosgd,lll-lcc,lll-crg}|{dual,ptsfa}!cogent!mark | | | | Cogent Software Solutions can not be held responsible for anything said | | by the above person since they have no control over him in the first place | +----------------------------------------------------------------------------+
monte@oblio.UUCP (Monte Pickard) (01/06/87)
In article <10943@sun.uucp>, guy%gorodish@Sun.COM (Guy Harris) writes: > > You can change the system-wide default value for ulimit by, assuming of > > course that you have a source code license, changing a constant .... > > Nothing so straightforward; it's called CDLIMIT. > > One hopes that in S5R3 they've at least come to their senses to the extent > of making it a constant tunable without source (one *could* hope they > realize that the "ulimit" scheme is the wrong solution, implement quotas > instead, and either crank the default ulimit up to 2^31-1 or set it to 0 and > have that mean "no limit"). System V, Release 3 still has CDLIMIT as a 'source code' based parameter. But, most vendors porting UNIX since Version 7, brought this out to their configuration step provided to all users at the administration level. So any site could, if so desired, with binary license, change this value. The other 'psuedo getty' solutions work in the other cases. To declare this approach in terms like "...come to their senses..." and "...is the wrong solution...", on the other hand seems a bit arrogant. Possibly 'a better way...', but wrong? Wording of a response can make it so much more acceptable and more pleasant to read. Monte Pickard - Counterpoint Computers
guy%gorodish@Sun.COM (Guy Harris) (01/06/87)
> To declare this approach in terms like "...come to their senses..." and > "...is the wrong solution...", on the other hand seems a bit arrogant. The arrogance here is AT&T-IS's, not mine; by hardwiring the limit to 1MB or so (count your blessings - at least it's a #define constant; in S3 it was a hardwired 1L<<11!) and providing no way of changing this without hackery, they declared that nobody should ever want to create files larger than 1MB unless they're running as "root" or want to go through that hackery. Sticking this into the kernel without making it a configurable parameter *is* senseless; the complaints that surface periodically on the net about this should be sufficient evidence of that. > Possibly 'a better way...', but wrong? Wording of a response can > make it so much more acceptable and more pleasant to read. Yes, *wrong*. If some people find it unacceptable to state that, that's their problem. If the intent is to limit people's usage of disk space, "ulimit" doesn't succeed in many cases. Individual users are quite likely to have lots of small files, and "ulimit" does nothing about that. Disk quota mechanisms can control that. If the intent is to control runaway programs, it should be user-controllable and should default to "infinity", not 1MB. There's no reason whatsoever to penalize database programs and the like, as they often have quite legitimate reasons to have files larger than 1MB. 4BSD has a mechanism which is almost identical (it also sends a signal if you exceed the file size limit, and also provides limits for other resources such as CPU time), but the kernel doesn't set "init"s file size limit to 1MB.
ekrell@ulysses.homer.nj.att.com (Eduardo Krell) (01/07/87)
In System V Release 3, ULIMIT is a tunable parameter that can be changed
(and then a new kernel can be made) without sources.
--
Eduardo Krell AT&T Bell Laboratories, Murray Hill
{ihnp4,seismo,ucbvax}!ulysses!ekrellwyatt@cfa.harvard.EDU (Bill Wyatt) (01/07/87)
Just to add my two cents: I have only used bsd/Ultrix systems, and never
realized this file size limitation existed in Sys5. It may have seemed
reasonable at one time, but in my applications (astronomical image
processing), it would be FATAL. A typical data file for me is 1/2 Mbyte,
many are from 1 to 8 Mbytes. Some people in my group have 128 Mbyte files,
and these are by no means the largest I know of.
--
Bill UUCP: {seismo|ihnp4}!harvard!talcott!cfa!wyatt
Wyatt ARPA: wyatt@cfa.harvard.edu
(or) wyatt%cfa.UUCP@harvard.harvard.edu
BITNET: wyatt@cfa2cwd@cuae2.ATT.COM (Chris Donahue) (01/07/87)
In my last beta update for UNIX System V Release 3.1 (maintenance upgrade to SVR3.0), ULIMIT was changed to A TUNABLE PARAMETER. Even those of us at AT&T who work with major customers have wanted this modification for a long time. Well, it finally made it. UNIX SVR3.1 should be out in late Spring or thereabouts for the 3B2 Computer Family. I no longer have to provide bogus "login" programs or "big shells" to the customers I support. Chris Donahue AT&T Info. Sys. Systems Engineering
gwyn@brl-smoke.ARPA (Doug Gwyn ) (01/07/87)
The 1Mb initial ulimit is without doubt the single stupidest
feature of vanilla UNIX System V. Since only the super-user
can raise the ulimit, one cannot even fix this in his .profile.
The correct solution is to change the kernel's initial ulimit
setting to be "infinite"; it is easy enough to lower it when
so desired (e.g. in /etc/profile). If you can't patch the
kernel, then modify init(1M) to raise the ulimit, which it can
do since it runs as super-user. Failing that, you could try
running a "pre-login shell" that is set-UID 0, which would
simply raise the ulimit, change the UID, and exec a real shell.
By the way, users on our systems routinely process files much
bigger than 1Mb. A 1Mb file limit doesn't make sense in any
case except for toy computers. Come to think of it, even my
Apple //e frequently has to deal with larger files!
I don't know how one gets AT&T to remedy mistakes such as this
one; if you submit an MR you will probably be told to use some
unacceptable work-around and the matter would then be dropped
("MR resolved"). Perhaps you should nag your system vendor.gwyn@brl-smoke.ARPA (Doug Gwyn ) (01/08/87)
In article <7012@cuae2.ATT.COM> cwd@cuae2.UUCP (-Chris Donahue) writes: >In my last beta update for UNIX System V Release 3.1 (maintenance upgrade to >SVR3.0), ULIMIT was changed to A TUNABLE PARAMETER. ... > UNIX SVR3.1 should be out in late Spring >or thereabouts for the 3B2 Computer Family. Thanks for clarifying this situation. Any idea whether it will be any more expensive for a commercial upgrade from 2.0 to 3.1 than from 2.0 to 3.0?
rbl@nitrex.UUCP (01/08/87)
In: >From: ekrell@ulysses.homer.nj.att.com (Eduardo Krell) >Message-ID: <1607@ulysses.homer.nj.att.com> >Eduardo says: >In System V Release 3, ULIMIT is a tunable parameter that can be changed >(and then a new kernel can be made) without sources. >-- > > Eduardo Krell AT&T Bell Laboratories, Murray Hill Last January, AT&T Hot Line provided us a program that permitted the ulimit to be raised without recompiling. Our system is SVR2 on a 3B2/300 upgraded to a 3B2/310. This C program required creating a new /bin/login. P.S. I have nothing but praise for the Hot Line support staff!!! They have been kind, patient and persistent in solving any and all problems. Robin Lake decvax!cwruecmp!nitrex!rbl ihnp4!cbatt!nitrex!rbl
SofPasuk@imagen.UUCP (Munach Rvi'i) (01/09/87)
In article <1607@ulysses.homer.nj.att.com>, ekrell@ulysses.homer.nj.att.com (Eduardo Krell) writes: > In System V Release 3, ULIMIT is a tunable parameter that can be changed > (and then a new kernel can be made) without sources. > Regen of the system is totally almost totally useless in application shops. To require that the system be brought "down" and that a new kernel be relinked is absurd - If there are to be user-oriented "limits" as part of the system, the default and/or system-wide maximum should be dynamically setable by the system administrator via command. This is just another example of what happens when operating system design is performed by persons who do not understand how real world computer systems are used (i.e., where commercial applications programs are run and possibly developed by non-computer-nerd, real world people). No wonder AT&T is having problems selling their concept of computers and software ...
guy%gorodish@Sun.COM (Guy Harris) (01/09/87)
> Regen of the system is totally almost totally useless in application shops. > To require that the system be brought "down" and that a new kernel be > relinked is absurd - If there are to be user-oriented "limits" as part of > the system, the default and/or system-wide maximum should be dynamically > setable by the system administrator via command. The "ulimit" is a default, not a system-wide, maximum. As such, there's not much that command can really do. It wouldn't have any effect on processes that have already been started. The most that could be done would be to set the "ulimit" when a user logs in, and have the value it's set to be the value set by this command.
karl@cbrma.att.com (Karl Kleinpaste) (01/09/87)
# gwyn@brl.arpa writes: # >The correct solution is to change the kernel's initial ulimit # >setting to be "infinite"; it is easy enough to lower it when # >so desired (e.g. in /etc/profile). If you can't patch the # >kernel, then modify init(1M) to raise the ulimit, which it can # >do since it runs as super-user. Failing that, you could try # # Modifying init is not possible for sites running sourceless 3Bs. # # >running a "pre-login shell" that is set-UID 0, which would # >simply raise the ulimit, change the UID, and exec a real shell. # # Inserting a program as a pre-login shell will take care of normal # mortals who login in the routine manner. It won't do anything for # things like cron-initiated stuff (including, significantly, large cron # logs). We use the following script on a small army of our machines # around here. I offer it without any guarantees whatever, but with the # evidence that we have BIG ulimits on our machines. # # Caveat: Heaven help you if you screw up the installation of this # hack. It installs a pre-init program in init's place. # # This article is a shar script. You can "w|sh" from an rn prompt to # save the script "ulimit.hack" below. # cat > ulimit.hack << \ENDOFFILE # Create an intermediate program for use in between # kernel initialization and init startup. cat > ulimit.init.c << \EOF main(argc, argv) int argc; char *argv[]; { ulimit(2, 32768L); /* "2" sets ulimit. 32768 = 16Mb. */ /* roll your own size if that's not big enough. */ execv("/etc/real.init", argv); } EOF # Compile it and put it in place of the usual init program. cc ulimit.init.c -o ulimit.init mv /etc/init /etc/real.init mv ulimit.init /etc/init chmod 0754 /etc/init # same as old init # Done. The next time the machine is booted, the # ulimit will be suitably enlarged. exit 0 ENDOFFILE exit 0 -- Karl
gwyn@brl-smoke.ARPA (Doug Gwyn ) (01/09/87)
In article <752@imagen.UUCP> SofPasuk@imagen.UUCP (Munach Rvi'i) writes: >This is just another example of what happens when operating system design is >performed by persons who do not understand how real world computer systems are >used (i.e., where commercial applications programs are run and possibly >developed by non-computer-nerd, real world people). No wonder AT&T is having >problems selling their concept of computers and software ... I don't know "where you're coming from", but it is perhaps instructive to observe that ulimit was introduced by the real-world, commercially- oriented people inside AT&T. Those whom you would probably (unjustly) brand as "computer nerds" knew better.
det@herman.UUCP (Derek Terveer) (01/10/87)
In article <10943@sun.uucp>, guy%gorodish@Sun.COM (Guy Harris) writes: > One hopes that in S5R3 they've at least come to their senses to the extent > of making it a constant tunable without source (one *could* hope they > realize that the "ulimit" scheme is the wrong solution, implement quotas > instead, and either crank the default ulimit up to 2^31-1 or set it to 0 and > have that mean "no limit"). The treatment of the "ulimit problem" (to tell you the truth, I'm not really sure what the "problem" that ulimit is supposed to be solving is..) seems to me to be rather endemic of Unix in general. I.e., the implementation of a general scheme to solve what, to many people, appears to be, by its nature, a specific problem. Disk quotas is one example. My gripe happens to be security. I find the user/group/world security quite cumbersome and tedious to manage as a system administrator with a brood of ~70 users. To me, a security scheme should be a tad more specific than Unix allows. (All right, a lot more specific) Or am I opening up the wrong box with my soliloquy (previously owned by Pandora)?
det@herman.UUCP (Derek Terveer) (01/10/87)
In article <354@cfa.cfa.harvard.EDU>, wyatt@cfa.harvard.EDU (Bill Wyatt) writes: > Just to add my two cents: I have only used bsd/Ultrix systems, and never > realized this file size limitation existed in Sys5. It may have seemed > reasonable at one time, but in my applications (astronomical image > processing), it would be FATAL. A typical data file for me is 1/2 Mbyte, > many are from 1 to 8 Mbytes. Some people in my group have 128 Mbyte files, > and these are by no means the largest I know of. I had to up the ulimit on our system (Vr2) quite early in the game because the compiler that we use for our program development (cms-2m) seems to think it is quite funny to create 2-6Meg *scratch* files!!! (it is an old compiler that we are, sigh.., yes STILL using and was originally written to use several tape drives for compiler interphase scratch)
ekrell@ulysses.homer.nj.att.com (Eduardo Krell) (01/10/87)
In article <752@imagen.UUCP> SofPasuk@imagen.UUCP (Munach Rvi'i) writes: > >Regen of the system is totally almost totally useless in application shops. To >require that the system be brought "down" and that a new kernel be relinked is >absurd - If there are to be user-oriented "limits" as part of the system, the >default and/or system-wide maximum should be dynamically setable by the >system administrator via command. > Sure enough. There is a system call to change the ulimit (you have to be the super-user). the korn-shell provides a built-in "ulimit" command to make it even easier. How you would use this feature to raise everyone's ulimit is left as an exercise to the reader. -- Eduardo Krell AT&T Bell Laboratories, Murray Hill {ihnp4,seismo,ucbvax}!ulysses!ekrell
brandon@tdi2.UUCP (Brandon Allbery) (01/12/87)
Quoted from <196@devon.UUCP> ["Re: ulimit considered braindamaged ?"], by paul@devon.UUCP (Paul Sutcliffe Jr.)... +--------------- | It's also interesting to note that _any_ process running as set[e]uid | root does not adhere to the ulimit value (e.g. can write to any size | file). +--------------- Not under AT&T System V.2. I once managed to screw up our Plexus by assuming that v.v_cdlimit was unsigned and patching it to (1<<31) -- which promptly failed spectacularly when I tried to go multiuser. I ended up using the shell ulimit command (I am glad that I refuse to use the Plexus-supplied csh on the root login -- no ulimit command!) to set my ulimit to something reasonable, then re-patching the kernel for (1<<30) and rebooting. ++Brandon -- ``for is he not of the Children of Luthien? Never shall that line fail, though the years may lengthen beyond count.'' --J. R. R. Tolkien Brandon S. Allbery UUCP: cbatt!cwruecmp!ncoast!tdi2!brandon Tridelta Industries, Inc. CSNET: ncoast!allbery@Case 7350 Corporate Blvd. INTERNET: ncoast!allbery%Case.CSNET@relay.CS.NET Mentor, Ohio 44060 PHONE: +1 216 255 1080 (home) +1 216 974 9210
brandon@tdi2.UUCP (Brandon Allbery) (01/12/87)
Quoted from <5486@brl-smoke.ARPA> ["Re: ulimit considered braindamaged ?"], by gwyn@brl-smoke.ARPA (Doug Gwyn )... +--------------- | The 1Mb initial ulimit is without doubt the single stupidest | feature of vanilla UNIX System V. Since only the super-user | can raise the ulimit, one cannot even fix this in his .profile. | The correct solution is to change the kernel's initial ulimit | setting to be "infinite"; it is easy enough to lower it when | so desired (e.g. in /etc/profile). If you can't patch the | kernel, then modify init(1M) to raise the ulimit, which it can | do since it runs as super-user. Failing that, you could try | running a "pre-login shell" that is set-UID 0, which would | simply raise the ulimit, change the UID, and exec a real shell. +--------------- Don't forget cron. The underlying assumption in many of the postings is that the ulimit is set in init (or for init). WRONG! When the kernel constructs its own process table entry prior to doing the fork/exec to start /etc/init, it sets the cdlimit for itself. Under the first version of Plexus System III I was forced to adb an immediate move at the start of /unix; later releases put it in /usr/src/utx/m68/cf/conf.c, making life much simpler. ++Brandon -- ``for is he not of the Children of Luthien? Never shall that line fail, though the years may lengthen beyond count.'' --J. R. R. Tolkien Brandon S. Allbery UUCP: cbatt!cwruecmp!ncoast!tdi2!brandon Tridelta Industries, Inc. CSNET: ncoast!allbery@Case 7350 Corporate Blvd. INTERNET: ncoast!allbery%Case.CSNET@relay.CS.NET Mentor, Ohio 44060 PHONE: +1 216 255 1080 (home) +1 216 974 9210
henry@utzoo.UUCP (Henry Spencer) (01/17/87)
> ... Any idea whether it will > be any more expensive for a commercial upgrade from 2.0 to 3.1 > than from 2.0 to 3.0? Silly question, Doug -- when you ask AT&T "will <new> be more expensive than <old>?", the answer is invariably "yes"! :-) -- Legalize Henry Spencer @ U of Toronto Zoology freedom! {allegra,ihnp4,decvax,pyramid}!utzoo!henry
gwyn@brl-smoke.ARPA (Doug Gwyn ) (01/20/87)
In article <7531@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes:
-> ... Any idea whether it will
-> be any more expensive for a commercial upgrade from 2.0 to 3.1
-> than from 2.0 to 3.0?
-Silly question, Doug -- when you ask AT&T "will <new> be more expensive
-than <old>?", the answer is invariably "yes"! :-)
The reason I am concerned is that $22K is already approaching the
limit for relatively simple procurement for many organizations.
If the amount crosses the $25K line, it may actually generate
less revenue for AT&T, not more. (Not that I want to maximize
AT&T profits, but I would like to be able to get the upgrade.)michael@stb.UUCP (02/02/87)
Well, I'm glad that Sys3 (ok, Radio shacks version of SCO's port of microsofts implementation of ATnT's sys3) has no default ulimit; I've managed to make 30-35 meg backup files in /usr/tmp. (this was find / -print > /usr/tmp/tarlist tar -cfF /usr/tmp/tar.out /usr/tmp/tarlist / . Works fine. Eats up all the disk space, though :-) ) -- Michael Gersten ihnp4!ucla-cs!cepu!ucla-an!remsit!stb!michael "Hey, you look a lot better since you got her back" "Yea, and now I'm going to take her out and shoot her"
grr@cbmvax.UUCP (02/05/87)
In article <837@stb.UUCP> michael@stb.UUCP (Michael) writes: >Well, I'm glad that Sys3 (ok, Radio shacks version of SCO's port of >microsofts implementation of ATnT's sys3) has no default ulimit; I've >managed to make 30-35 meg backup files in /usr/tmp. (this was >Michael Gersten ihnp4!ucla-cs!cepu!ucla-an!remsit!stb!michael A number of "System III" ports are actually 7th Edition ports with some of the newer S III system calls added. Zilog's Zeus, and I believe non Sys V Xenix fall into this category. Zeus implements the ulimit system call, but the disk limit part of it is a no-op. -- George Robbins - now working for, uucp: {ihnp4|seismo|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@seismo.css.GOV Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
paul@devon.UUCP (02/05/87)
In article <1343@cbmvax.cbmvax.cbm.UUCP>, grr@cbmvax.cbm.UUCP (George Robbins) writes: > A number of "System III" ports are actually 7th Edition ports with some of > the newer S III system calls added. Zilog's Zeus, and I believe non Sys V > Xenix fall into this category. Zeus implements the ulimit system call, but > the disk limit part of it is a no-op. Actually, Xenix V (Microsoft and SCO) are also V7 ports with sys3 and sys5 system calls added. (Microsoft originally ported V7 UN*X to form their Xenix 2.x; they probably just built on that for 3.0 and sys V). For instance, Xenix V/286 still has /etc/ttys and /etc/ttytype (no /etc/inittab). The uucp is even V7 based. But it does have semiphores (as does Xenix 3.0), shared mem calls, etc. What I'd like to see is a _REAL_ Sys V Xenix!!! (I heard rumors that something like this was seen at UniForum). - paul@devon.UUCP -- Paul Sutcliffe, Jr. paul@devon.UUCP (or, if you prefer:) Devon Computer Services {seismo,ihnp4,allegra,rutgers}!cbmvax!devon!paul Allentown, PA "I love work. I could sit and watch people do it all day!"