Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!shadooby!samsung!zaphod.mps.ohio-state.edu!mips!apple!fox!portal!cup.portal.com!thad
From: thad@cup.portal.com (Thad P Floryan)
Newsgroups: comp.sys.att
Subject: Re: problem using tar under system V
Message-ID: <25602@cup.portal.com>
Date: 5 Jan 90 00:22:22 GMT
References: <1295@amethyst.math.arizona.edu> <368@gtenmc.UUCP>
  <3456@cbnewsl.ATT.COM> <369@gtenmc.UUCP>
Organization: The Portal System (TM)
Lines: 21

In <369@gtenmc.UUCP> fst@gtenmc.UUCP (Fariborz "Skip" Tavakkolian) writes

	About raising the ulimit on the SVR3.1 on the VAXEN, well I am glad
	you brought it up.  Our SVR3.1 comes from DEC.  Our SA can't do what
	you recommend, since the ULIMIT is apparently hard coded to 2048, even
	when you set the tunable ULIMIT to what you want (I don't have all the
	gory details).  (BTW: Blocks on this system are 1024 bytes. Sdb
	crashes the system, using STREAMS crashes the system; and lately I
	noticed that sneezing crashes the system :-) )

Omigosh.  Now DEC is doing to UNIX what they did to VMS?!?!

VMS, with its eleventy-seven thousand fences, quotas, restrictions, etc., is
definitely NOT a development system.  Consider the case where, at 3 A.M.,
being the only logged-in online or batch user on a 64 MB RAM system, one
would be unable to use more than 1MB RAM due to all those quotas,
restrictions, etc.  Guess DEC has never heard of dynamic resource sharing.

(And note the absence of a ":-)" after that last line above)

Thad Floryan [ thad@cup.portal.com (OR) ..!sun!portal!cup.portal.com!thad ]