Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!haven!adm!news From: postmaster@sandia.gov (SMTP MAILER) Newsgroups: comp.unix.wizards Subject: Mail Delivery Problem Message-ID: <24223@adm.BRL.MIL> Date: 20 Aug 90 13:30:16 GMT Sender: news@adm.BRL.MIL Lines: 592 ----Reason for mail failure follows---- Sending mail to : Could not be delivered for three days. ----Transcript of message follows---- Date: 17 Aug 90 05:23:00 MDT From: unix-wizards@BRL.MIL Subject: UNIX-WIZARDS Digest V10#119 To: "math!ckaul" Return-Path: Received: from SEM.BRL.MIL by sandia.gov with SMTP ; Fri, 17 Aug 90 05:13:44 MDT Received: from SEM.BRL.MIL by SEM.BRL.MIL id aa01304; 17 Aug 90 5:55 EDT Received: from sem.brl.mil by SEM.BRL.MIL id aa01271; 17 Aug 90 5:45 EDT Date: Fri, 17 Aug 90 05:45:03 EST From: The Moderator (Mike Muuss) To: UNIX-WIZARDS@BRL.MIL Reply-To: UNIX-WIZARDS@BRL.MIL Subject: UNIX-WIZARDS Digest V10#119 Message-ID: <9008170545.aa01271@SEM.BRL.MIL> UNIX-WIZARDS Digest Fri, 17 Aug 1990 V10#119 Today's Topics: "to big" error on PDP-11/73 Re: sed bug? Re: csh weirdness (HELP!) Re: shmat() system call? UNIX System Administration/Programming Positions Available Re: Vi fails on a Sun-4 Re: Checkpoint/Restart (was "no subject - file transmission") Re: Another "why won't this work" program Re: Is HDB locking safe? Problems with DIGIBOARD PC/4 ----------------------------------------------------------------- From: "Jay A. Snyder" Subject: "to big" error on PDP-11/73 Date: 15 Aug 90 21:28:40 GMT To: unix-wizards@sem.brl.mil I compiled C-Kermit ver. 4E on a Tektronix model 8061 (DEC LSI 11/73). The OS is called TNIX (tek's version of V7). When I tried to run the executable, it said: kermit: to big The machine has 512K of RAM and 4700 blocks of swap. The executable is only 114K. The largest executables I could find on the machine where less than 64K. Is there a limit to the executable size on 11/73's? I'm also trying to get Micro-Emacs to compile, and I get "too many defines" error from the c-compiler. Any one have any ideas there? Thanks, J ...uunet!wa3wbu!gdx!jay -- ============================================================================== Jay A. Snyder "Let Me Up! I've had enough" wa3wbu!gdx!jay@uunet.uu.net uunet!wa3wbu!gdx!jay ----------------------------- From: "John F. Haugh II" Subject: Re: sed bug? Date: 16 Aug 90 04:40:16 GMT X-Clever-Slogan: Recycle or Die. To: unix-wizards@sem.brl.mil In article <24172@adm.BRL.MIL> stanonik@nprdc.navy.mil (Ron Stanonik) writes: >We've run into what appears to be a sed bug in sunos4.X (sun3 snd sun4) >and in sysVr3 (on a 3b2). Here's a little sed program to demonstrate it > >1 s/.*/&/p >d > >I'd expect this to print only the first line, and indeed that's what happens >in 4.3bsd (on a vax 780). In sunos4.X and sysVr3, however, nothing is printed. By all accounts it is fixed in BSD 4.3 and broken in every other version of SED I've had my hands on. The way the bug was reported for AIX 3.1 was % sed -e 's/abc/ABC/p' -e d << EOF abc abc123 EOF and the output should have been ABC ABC123 but instead, nothing at all was printed. >Bug? Yes. Bug. -- John F. Haugh II UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 832-8832 Domain: jfh@rpp386.cactus.org ----------------------------- From: Guy Harris Subject: Re: sed bug? Date: 16 Aug 90 19:41:54 GMT To: unix-wizards@sem.brl.mil >Bug? Or misfeature, although some scripts in S5 (among others, "lint", I think) depend on that behavior. As I remember, the behavior exhibited by S5 was also exhibited in UNIX/32V (or, at least, the part of the code that differs was basically the same as in S5), while in V7 it worked the BSD way. I think the 32V code was older (yes, 32V was allegedly a V7 port to the VAX, but they may have started with something older than V7), so it *seems* the change from the 32V/S5 behavior to the V7/BSD behavior might have been intended as a bug fix or improvement. I think the S5 "lint"s dependency on the 32V/S5 behavior can be fixed; I think there are cases where dependency on the V7/BSD behavior cannot. POSIX 1003.2 may specify that this has to be done the V7/BSD way. ----------------------------- From: Rob McMahon Subject: Re: csh weirdness (HELP!) Date: 16 Aug 90 09:04:17 GMT Sender: Network news To: unix-wizards@sem.brl.mil In article <8000007@hpopd.HP.COM> bd@hpopd.HP.COM (Bob Desinger) writes: >> to kill every instance of a.out I get >> `ps | grep a.out | awk '{printf("%d ",$1);}'`: Ambiguous. > >Can you work around this by changing the awk program to generate the >kill commands, then piping the awk output to the shell? ... The best workaround is just to use \kill `ps | grep a.out | awk '{printf("%d ",$1);}'` to avoid using the shell builtin. Rob -- UUCP: ...!mcsun!ukc!warwick!cudcv PHONE: +44 203 523037 JANET: cudcv@uk.ac.warwick INET: cudcv@warwick.ac.uk Rob McMahon, Computing Services, Warwick University, Coventry CV4 7AL, England ----------------------------- From: Thomas Tornblom Subject: Re: shmat() system call? Date: 16 Aug 90 10:32:52 GMT Sender: Thomas Tornblom To: unix-wizards@sem.brl.mil In article <187@n4hgf.Mt-Park.GA.US> wht@n4hgf.Mt-Park.GA.US (Warren Tucker) writes: In article <27@astph.UUCP> jeff@astph.UUCP (8592x2) writes: > >Question concerning the shared memory attach call: > >I am writing a shared memory allocation manager for a multi-user >database. >I need to know if additional attaches by other processes will be >guaranteed to return the same address as that the first process >was returned. To be sure, specify the attach address, regardless of what the FM says. Make a small program that passes 0 for the address and see what it returns. Then, use that value hardcoded, possibly #defined for each arcitecture you plan to run the program on. [example deleted] This is not guaranteed to work. Typically the kernel allocates the addresses depending of the memory layout of the running process. Our sysV.2 68k kernel uses the current end of bss rounded up with some constant as the lowest base for shm. It also checks that the segment doesn't overlap into the stack or other shared memory segments. If you must have the same addresses between the processes (which is nice for pointers and stuff) I'd pick some high constant address, say 0x[48c]0000000 or so that isn't likely to map onto anything on the architectures you're using. Thomas -- Real life: Thomas Tornblom Email: thomas@uplog.se Snail mail: TeleLOGIC Uppsala AB Phone: +46 18 189406 Box 1218 Fax: +46 18 132039 S - 751 42 Uppsala, Sweden ----------------------------- From: Christopher R Volpe Subject: Re: shmat() system call? Date: 16 Aug 90 17:47:23 GMT Sender: news@crdgw1.crd.ge.com To: unix-wizards@sem.brl.mil In article , thomas@uplog.se (Thomas Tornblom) writes: |> |>If you must have the same addresses between the processes (which is nice for |>pointers and stuff) I'd pick some high constant address, say 0x[48c]0000000 |>or so that isn't likely to map onto anything on the architectures you're using. |> I was working on a project with a couple of people last summer where we had to use shared memory segments and processes had to exchange pointers. We decided is just wasn't worth it to take chances on a hardcoded address that might fail on any particular run because the kernel couldn't attach the segment at the address specified. So we just did all the pointer exchanging in terms of offsets from the base address of the segment and let each individual process convert between offsets and virtual addresses. It's a little tedious at most (like when you're sharing linked lists), but the added flexibility and reliability is worth the effort, IMHO. ================== Chris Volpe G.E. Corporate R&D volpecr@crd.ge.com ----------------------------- From: Warren Tucker Subject: Re: shmat() system call? Date: 16 Aug 90 19:15:40 GMT To: unix-wizards@sem.brl.mil In article thomas@uplog.se (Thomas Tornblom) writes: >In article <187@n4hgf.Mt-Park.GA.US> wht@n4hgf.Mt-Park.GA.US (Warren Tucker) writes: > > In article <27@astph.UUCP> jeff@astph.UUCP (8592x2) writes: > To be sure, specify the attach address, regardless of what the FM says. >This is not guaranteed to work. Typically the kernel allocates the addresses >depending of the memory layout of the running process. In all of the implementations I have used, the kernel performs this optimzation. And of course, it has been working me for 4 years. ----------------------------------------------------------------------- Warren Tucker, TuckerWare gatech!n4hgf!wht or wht@n4hgf.Mt-Park.GA.US "Tell the moon; don't tell the March Hare: He is here. Do look around." ----------------------------- From: Warren Tucker Subject: Re: shmat() system call? Date: 16 Aug 90 19:17:35 GMT To: unix-wizards@sem.brl.mil In article <12638@hydra.gatech.EDU> gt0178a@prism.gatech.EDU (BURNS,JIM) writes: >in article <187@n4hgf.Mt-Park.GA.US>, wht@n4hgf.Mt-Park.GA.US (Warren Tucker) says: >< In article <27@astph.UUCP> jeff@astph.UUCP (8592x2) writes: >< To be sure, specify the attach address, regardless of what the FM says. >< Make a small program that passes 0 for the address and see what it >< returns. Then, use that value hardcoded, possibly #defined for each >< arcitecture you plan to run the program on. > >What if yours is not the only application creating and deleting shared >memory segments? Are you saying you always get the same address? Yes, in a virtual system where the shmat'd address is virtual. ----------------------------------------------------------------------- Warren Tucker, TuckerWare gatech!n4hgf!wht or wht@n4hgf.Mt-Park.GA.US "Tell the moon; don't tell the March Hare: He is here. Do look around." ----------------------------- From: Suu Quan Subject: Re: shmat() system call? Date: 16 Aug 90 19:39:15 GMT To: unix-wizards@sem.brl.mil / hpcc01:comp.unix.wizards / jeff@astph.UUCP (8592x2) / 1:11 pm Aug 15, 1990 / > >Question concerning the shared memory attach call: > >I need to know if additional attaches by other processes will be >guaranteed to return the same address as that the first process >was returned. I am aware that you can request a particular address, >but why bother communicating that information between the processes >if the same address is returned anyway? I would appreciate any >answers or direction to documentation. In spite of other positive answers, the real answer is NO. The exactly same program, run on different kernels, will most probably result in different attached address. The attached address depends on too many different kernel parameters to discuss here in a few lines. On the other hand, if you want to request a particular address, the down side of it is that you don't know whether any other applications has used that segment of address or not. This practice is definitely not recommended. ----------------------------- From: Randolph Gary Smith Subject: UNIX System Administration/Programming Positions Available Keywords: UNIX,Mach,MIMD,SIMD,kernel,UNICOS,CONVEX,SunOS Date: 16 Aug 90 12:52:54 GMT Sender: fpst@hubcap.clemson.edu Approved: parallel@hubcap.clemson.edu To: unix-wizards@sem.brl.mil Following are two Senior Operating System Specialist job positions currently available at The University of Texas System Center for High Performance Com- puting located in northwest Austin, Texas. Instructions for applying follow the job descriptions. ------------------------------------------------------------------------------ Position 1: Senior Operating System Specialist Posting Number: 0-08-01-07-9365 Monthly Salary: $3017 or more Date Available: 8/8/90 40 hours/week; work hours flexible Required Qualifications: Bachelor's degree and five years of programming or systems analysis experience, of which two years are in operating systems programming; or high school graduation or equivalent and nine years of programming or systems analysis experience, of which two years are in operating systems programming Initial Qualifications: Extensive experience as a system administrator for large-scale UNIX production system(s). Experience in coding in C an FORTRAN. Expe- rience with computer networking concepts, including experience with Sun's NFS, Apollo's NCS, and the lower-level protocols on which they are built. Preferred Qualifications: Knowledge of the fundamental algorithms and data structures implemen- ting the System V UNIX operating system or the 4.2/4.3 BSD UNIX ope- rating system, including the file subsystem and process control sub- system of the kernel. Understanding of the kernel system call inter- face to user-level processes. Experience with the CRAY UNICOS, CONVEX UNIX, and SunOS UNIX systems at the system administration and develop- ment levels. Experience with computer networking administration. Thorough knowledge and understanding of computer architecture. Job Duties: To be explained during interview. ------------------------------------------------------------------------------- Position 2: Senior Operating System Specialist Posting Number: 0-08-09-02-9365 Monthly Salary: $3017 or more Date Available: 9/1/90 40 hours/week; work hours flexible Required Qualifications: Bachelor's degree and five years of programming or systems analysis experience, of which two years are in operating systems programming; or high school graduation or equivalent and nine years of programming or systems analysis experience, of which two years are in operating systems programming Initial Qualifications: Extensive experience as a system administrator and resource scheduling and accounting software developer for UNIX and/or Mach systems. Under- standing of the fundamental opportunities and limitations in moderately to massively parallel SIMD and MIMD computer systems. Preferred Qualifications : Extensive experience with systems software development on massively parallel SIMD and MIMD computer systems in a distributed computing environment. Familiarity with architectural details of most massively parallel SIMD/MIMD distributed- and shared-memory computer systems. Bachelor's degree in computer science or engineering. Job Duties: To be explained during interview. ------------------------------------------------------------------------------- If you are interested in either position, send a current resume to: Janet McCord UT System CHPC Balcones Research Center 10100 Burnet Rd Austin, TX 78758-4497 Telephone: 512/471-2418 FAX: 512/471-2445 email: jnet@hermes.chpc.utexas.edu ----------------------------- From: Bertrand Meyer Subject: Re: Vi fails on a Sun-4 Keywords: Illegal instruction Date: 16 Aug 90 17:23:50 GMT To: unix-wizards@sem.brl.mil In the article referenced above I mentioned a problem I was having with vi under csh, failing in inexplicable ways on a Sun-4 running 4.0. Many thanks to the several people who responded overnight and allowed me to correct the problem. For the benefit of others, here is one of the responses by Nick W. Holloway, I believe from the University of Warwick: > This is a bug with SunOS 4.0 (even up to 4.0.3). If the size of your > environment and the arguments passed to vi are of a magic size, then vi > will core dump with an illegal instruction. It is not unique to vi, it > just happens that it occurs frequently with vi. If you have access to > back issues of sunspots, have a look at the message in Volume 7, Issue > 26, Subject "Obscure SunOS Bug". This particular bug is fixed in 4.1. > > I imagine the reason that it fails differently in different windows is > that the environment is different sizes. To see this, try using the > command 'printenv | wc -c'. > > The workaround is to just put some junk environment variables in your > environment to take it over this magic number, or remove some to take > it under. The workaround suggested by Mr. Holloway (and several others in essentially equivalent terms) does work so far for me. Thank you very much. -- -- Bertrand Meyer bertrand@eiffel.com ----------------------------- From: Randolph Langley Subject: Re: Checkpoint/Restart (was "no subject - file transmission") Date: 16 Aug 90 21:29:15 GMT Sender: news@sun13.scri.fsu.edu To: unix-wizards@sem.brl.mil There is a paper, "Job and Process Recovery In A UNIX-based Operating System", by Brent Kingsbury and John Kline, that talks about UNICOS's checkpointing/restarting capabilities. It is available in the Cray documentation distribution, and I would guess directly from Cray. I also note that the authors have e-mail addresses: they are brent@yafs.cray.com and jtk@hall.cray.com. rdl ----------------------------- From: Guy Harris Subject: Re: Another "why won't this work" program Date: 16 Aug 90 19:35:50 GMT To: unix-wizards@sem.brl.mil "BKEHOE@widener" isn't a very usable email address, and the Path: line ended with "news", so I was unable to mail this. Methinks you should have a talk with your mail or netnews administrator, asking them to fix the From: line on outgoing postings.... >/* > * This is being run on a Sun SS1 under 4.0.3. > * Theoretically, according to the Design & Implementation of 4.3BSD Unix, > * this should print out the ascii version of each process's current > * directory...instead, it chokes on u->u_cwd->cw_dir, which is in the > * u struct in sys/user.h .. any help, suggestions, etc would be greatly > * appreciated. Well, actually, 4.3BSD UNIX doesn't *have* a "u_cwd" member of the "u" structure, so I'd hope that the BSD book *doesn't* suggest that it should work. That field is a SunOS-ism, introduced as part of the C2 security stuff so that the auditing code can get the full pathname of a file. > while ((proc = kvm_nextproc (kd))) > if (proc->p_stat != SZOMB && proc->p_uid) { > if (!(user = kvm_getu(kd, proc))) > continue; > (void) printf("%s\n", (getpwuid(proc->p_uid))->pw_name); Well, you probably want to call "getpwuid()" and store the result somewhere, and then check if it's NULL, before using it; it may not be *likely* to fail, but it *can* fail. >/* Curtains & Slow Music */ > (void) printf("%s\n", user->u_cwd->cw_dir); >/* It dies, but the user structure's fine (printing user->u_comm works); I > stepped thru it with gdb & discovered that the pointer user->u_cwd > is off in never-never-land; is it a valid entry in the user structure? */ Do you mean "is 'u_cwd' a valid entry in the user structure?" Well, maybe. I'm not sure if it's kept up-to-date if you haven't configured the C2 security stuff into your kernel (SYSAUDIT). However, even if it *is* kept up-to-date, it doesn't quite point into user-mode data, obviously. You'll have to grab the pointer value from "u_cwd" and use "kvm_read()" to read it from the *kernel's* address space into a private copy. Then, once you've done that, bear in mind that the "cw_dir" and "cw_root" members of the structure pointed to by "u_cwd" are *themselves* pointers into the kernel's address space, and read the strings to which they point using "kvm_read()" as well. Stepping through kernel data structures is more subtle than you might think. Pointers in kernel data structures *cannot*, in most systems, simply be dereferenced; even if the kernel-mode and user-mode address spaces are common, the kernel data is probably read-protected (for obvious reasons!). ----------------------------- From: Peter da Silva Subject: Re: Is HDB locking safe? Date: 16 Aug 90 19:49:10 GMT To: unix-wizards@sem.brl.mil In article <4024@rtifs1.UUCP> trt@rti.rti.org (Thomas Truscott) writes: > (a) A "sleep(1);" is not enough to avoid a race on a very busy system. No sleep is ever enough. The system could simply be busier than you ever imagined. You don't solve a race problem by narrowing the window: try checking the return value of the "unlink": that's the point of failure. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com (currently not working) peter@hackercorp.com ----------------------------- From: John Palmer Subject: Problems with DIGIBOARD PC/4 Date: 17 Aug 90 00:28:27 GMT Followup-To: comp.unix.xenix To: unix-wizards@sem.brl.mil I'm running SCO Xenix 2.3.2 on a AT clone (386/20MHz) and I have a DIGIBOARD PC/4 (4 ports, dumb controller chips). I'm having some problems with this setup: 1> Sometimes, when someone hangs up, the modem is left in such a state that it will not answer the phone until it is power-cycled. The RD (rcv data) and SD (send data) lights remain on and the modem will not answer the phone. 2> Many times, output gets garbled, especially right before a read operation. I have heard that the I/O chips on this board can be replaced by more "intelligent" chips. Is this the case, and if so, what is the part number of the intelligent chip. On a related topic, is there anyway to flush typeahead in Xenix?? I am using the Xenix equivalent of cbreak() (by setting various flags with ioctl()). fflush(stdin) doesn't seem to work, although it doesn't return an error code. Thanks ahead of time. jpp@ddmi.com -- = CAT-TALK Conferencing Network, Prototype Computer Conferencing System = - 1-800-825-3069, 300/1200/2400/9600 baud, 8/N/1. New users use 'new' - = as a login id. E-Mail Address: jpp@ThunderCat.COM = - <<>>> - ----------------------------- End of UNIX-WIZARDS Digest **************************