Mail Delivery Problem
SMTP MAILER
postmaster at sandia.gov
Mon Aug 20 23:30:16 AEST 1990
----Reason for mail failure follows----
Sending mail to <math!ckaul at cs.sandia.gov> :
Could not be delivered for three days.
----Transcript of message follows----
Date: 17 Aug 90 05:23:00 MDT
From: unix-wizards at BRL.MIL
Subject: UNIX-WIZARDS Digest V10#119
To: "math!ckaul" <math!ckaul at cs.sandia.gov>
Return-Path: <incoming-unix-wizards-request at sandia.gov>
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) <Unix-Wizards-Request at BRL.MIL>
To: UNIX-WIZARDS at BRL.MIL
Reply-To: UNIX-WIZARDS at BRL.MIL
Subject: UNIX-WIZARDS Digest V10#119
Message-ID: <9008170545.aa01271 at 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" <jay at gdx.uucp>
Subject: "to big" error on PDP-11/73
Date: 15 Aug 90 21:28:40 GMT
To: unix-wizards at 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 at uunet.uu.net
uunet!wa3wbu!gdx!jay
-----------------------------
From: "John F. Haugh II" <jfh at rpp386.cactus.org>
Subject: Re: sed bug?
Date: 16 Aug 90 04:40:16 GMT
X-Clever-Slogan: Recycle or Die.
To: unix-wizards at sem.brl.mil
In article <24172 at adm.BRL.MIL> stanonik at 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 at rpp386.cactus.org
-----------------------------
From: Guy Harris <guy at auspex.auspex.com>
Subject: Re: sed bug?
Date: 16 Aug 90 19:41:54 GMT
To: unix-wizards at 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 <cudcv at warwick.ac.uk>
Subject: Re: csh weirdness (HELP!)
Date: 16 Aug 90 09:04:17 GMT
Sender: Network news <news at warwick.ac.uk>
To: unix-wizards at sem.brl.mil
In article <8000007 at hpopd.HP.COM> bd at 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 at uk.ac.warwick INET: cudcv at warwick.ac.uk
Rob McMahon, Computing Services, Warwick University, Coventry CV4 7AL, England
-----------------------------
From: Thomas Tornblom <thomas at uplog.se>
Subject: Re: shmat() system call?
Date: 16 Aug 90 10:32:52 GMT
Sender: Thomas Tornblom <thomas at uplog.se>
To: unix-wizards at sem.brl.mil
In article <187 at n4hgf.Mt-Park.GA.US> wht at n4hgf.Mt-Park.GA.US (Warren Tucker) writes:
In article <27 at astph.UUCP> jeff at 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 at 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 <volpe at underdog.crd.ge.com>
Subject: Re: shmat() system call?
Date: 16 Aug 90 17:47:23 GMT
Sender: news at crdgw1.crd.ge.com
To: unix-wizards at sem.brl.mil
In article <THOMAS.90Aug16123252 at uplog.uplog.se>, thomas at 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 at crd.ge.com
-----------------------------
From: Warren Tucker <wht at n4hgf.mt-park.ga.us>
Subject: Re: shmat() system call?
Date: 16 Aug 90 19:15:40 GMT
To: unix-wizards at sem.brl.mil
In article <THOMAS.90Aug16123252 at uplog.uplog.se> thomas at uplog.se (Thomas Tornblom) writes:
>In article <187 at n4hgf.Mt-Park.GA.US> wht at n4hgf.Mt-Park.GA.US (Warren Tucker) writes:
>
> In article <27 at astph.UUCP> jeff at 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 at n4hgf.Mt-Park.GA.US
"Tell the moon; don't tell the March Hare: He is here. Do look around."
-----------------------------
From: Warren Tucker <wht at n4hgf.mt-park.ga.us>
Subject: Re: shmat() system call?
Date: 16 Aug 90 19:17:35 GMT
To: unix-wizards at sem.brl.mil
In article <12638 at hydra.gatech.EDU> gt0178a at prism.gatech.EDU (BURNS,JIM) writes:
>in article <187 at n4hgf.Mt-Park.GA.US>, wht at n4hgf.Mt-Park.GA.US (Warren Tucker) says:
>< In article <27 at astph.UUCP> jeff at 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 at n4hgf.Mt-Park.GA.US
"Tell the moon; don't tell the March Hare: He is here. Do look around."
-----------------------------
From: Suu Quan <quan at hpcc01.hp.com>
Subject: Re: shmat() system call?
Date: 16 Aug 90 19:39:15 GMT
To: unix-wizards at sem.brl.mil
/ hpcc01:comp.unix.wizards / jeff at 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 <ut-emx!gary at emx.utexas.edu>
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 at hubcap.clemson.edu
Approved: parallel at hubcap.clemson.edu
To: unix-wizards at 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 at hermes.chpc.utexas.edu
-----------------------------
From: Bertrand Meyer <bertrand at eiffel.uucp>
Subject: Re: Vi fails on a Sun-4
Keywords: Illegal instruction
Date: 16 Aug 90 17:23:50 GMT
To: unix-wizards at 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 at eiffel.com
-----------------------------
From: Randolph Langley <langley at ds1.scri.fsu.edu>
Subject: Re: Checkpoint/Restart (was "no subject - file transmission")
Date: 16 Aug 90 21:29:15 GMT
Sender: news at sun13.scri.fsu.edu
To: unix-wizards at 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 at yafs.cray.com and jtk at hall.cray.com.
rdl
-----------------------------
From: Guy Harris <guy at auspex.auspex.com>
Subject: Re: Another "why won't this work" program
Date: 16 Aug 90 19:35:50 GMT
To: unix-wizards at sem.brl.mil
"BKEHOE at 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 <peter at ficc.ferranti.com>
Subject: Re: Is HDB locking safe?
Date: 16 Aug 90 19:49:10 GMT
To: unix-wizards at sem.brl.mil
In article <4024 at rtifs1.UUCP> trt at 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 at ferranti.com (currently not working)
peter at hackercorp.com
-----------------------------
From: John Palmer <jpp at ddmi.com>
Subject: Problems with DIGIBOARD PC/4
Date: 17 Aug 90 00:28:27 GMT
Followup-To: comp.unix.xenix
To: unix-wizards at 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 at 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 at ThunderCat.COM =
- <<<Redistribution to GEnie PROHIBITED!!!>>>> -
-----------------------------
End of UNIX-WIZARDS Digest
**************************
More information about the Comp.unix.wizards
mailing list