Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/5/84; site mtx5a.UUCP Path: utzoo!linus!decvax!bellcore!ulysses!mhuxr!mhuxt!houxm!whuxl!whuxlm!akgua!akguc!mtunh!mtuni!mtune!mtunf!mtx5c!mtx5d!mtx5a!mat From: mat@mtx5a.UUCP (m.terribile) Newsgroups: net.singles Subject: Re: Re: Titles Message-ID: <1203@mtx5a.UUCP> Date: Fri, 21-Feb-86 03:30:22 EST Article-I.D.: mtx5a.1203 Posted: Fri Feb 21 03:30:22 1986 Date-Received: Mon, 24-Feb-86 08:29:03 EST References: <4514@kestrel.ARPA> <3407@nsc.UUCP> <276@sdcc7.UUCP> <165@ttidcc.UUCP> Organization: AT&T Information Systems, Middletown, NJ 07748-4801. Lines: 28 > Some do. I concede they're rare exceptions. There's a 13 year old in San > Diego who consults for HP. I'm told he knows more about the HP3000 than > anyone and did a lot of the design for their security systems. I worked with a 3000. It's got the most brain-damaged architrecture I've ever encountered -- has to do a final link at execute time and needs to have the compiler, assembler, and linker as trusted programs. Executing the COBOL compiler can require over 100 disk accesses to do the run-time link. The disks are slow ... you are lucky to get 30 blocks/sec. The sectors are 256 bytes and the file system is based on a variable blocking factor, with variable sized buffers (no decent lookahead strategy) that are allocated as program segments and then SWAPPED! The cache actually increases disk I/O rather than decreasing it, and the only way to get decent performance out of the machine is to bypass the the cache all together (we had a package from a fellow operating in Vancouver under the name Robelle Consutling ...) Total brain damage. I hope when that kid gets to be 21 or so he sues HP for psychological damage. Talk about an open-and-shut case! What in the hell are we doing discussing this on net.singles? -- from Mole End Mark Terribile (scrape .. dig ) mtx5b!mat (Please mail to mtx5b!mat, NOT mtx5a! mat, or to mtx5a!mtx5b!mat) ,.. .,, ,,, ..,***_*.