Sun-Spots-Request@Rice.edu (William LeFebvre) (10/26/88)
SUN-SPOTS DIGEST Tuesday, 25 October 1988 Volume 6 : Issue 274 Today's Topics: Re: uuencode ASCII--EBCDIC Re: System V shared memory "zombies" Re: UUCP, bug or feature Xylogics 753 vs 7053? Xylogics 753 vs 7053 and 451 Upgrade 3/50 to 8 MBytes Better fix for NSTREAMS Responses to 'S' Query possible compiler bug on Sun 4, sys4-3.2 sun 4/260 Floating Point Problem Getting info from damaged system? Performance on 3/50's with SunOS 4.0? Send contributions to: sun-spots@rice.edu Send subscription add/delete requests to: sun-spots-request@rice.edu Bitnet readers can subscribe directly with the CMS command: TELL LISTSERV AT RICE SUBSCRIBE SUNSPOTS My Full Name Recent backissues are available via anonymous FTP from "titan.rice.edu". For volume X, issue Y, "get sun-spots/vXnY". They are also accessible through the archive server: mail the request "send sun-spots vXnY" to "archive-server@rice.edu" or mail the word "help" to the same address for more information. ---------------------------------------------------------------------- Date: Fri, 21 Oct 1988 14:32:06 CET From: A0096@DK0RRZK0.BITNET Subject: Re: uuencode ASCII--EBCDIC The problems using uuencoded files on bitnet are well known at this side. It is impossible for us to maintain comp.sources and GNU-diffs with a predictable amount of work. In oposite there is no need for any problems at all. The program dumas-uuen(de)code puts a character table in front of the actual uuencoded file which is affected by all conversions as well. Analyzing this header it can recover the original file. This procedure works well for years in the atari networld were most programs are distributed binary only. The program is extremely smart and can deal with most attacks like permuted characters, trailing blanks, any kinds of envelopes and so on. You can split the file to small pieces in case of more restrictive mailers and reconstruct it totally automatically. The best method of distributing files as tested for years is: compress (4.0) and dumas-uue in junks of 20Kb. If more sites would agree to that standard, mailing would be much faster due to reduced traffic and more secure for sites connected over whatever gateways. Thomas Pfenning ps: the C-source originally from berkeley adapted to european bitnet problems is available from server@marvin.eleceng.bradford.ac.uk mail based with the text send utils/dumas.arc University of Cologne, Institute for Theoretical Physics, West Germany ------------------------------ Date: Thu, 20 Oct 88 13:05:01 EDT From: John Ioannidis <ji@ncs.columbia.edu> Subject: Re: System V shared memory "zombies" Reference: v6n262 >From: harvard!ll-xn!munsell!jwf@gatech.edu (Jim Franklin) > > [Summary: shared memory segments created using shmget(2) outlive the > process that created them. They can be marked for deletion, but then > they become unusable by other processes while they still exist. > Even if all processes attach to the segment before it is flagged for > deletion, there are cases where this is just not enough] >Has anyone found a clean solution to this problem? There is nothing clean about System V-type IPC. :-) I have a solution that might be good for what you want. Remember the ftok(3) call? Reserve an ID, say, '\177' (the DEL character) to make keys for segments that should be deleted when all processes attached to them die. The ID appears as the high-order byte of the key. Then have an awk script that will go through the output of ipcs -m -o, look for segments whose key starts with 0x7f and for which the NATTCH field is 0 and delete them. The following script would do the trick: for i in `ipcs -mo | awk '$1=="m" && $3~/0x7f/ && $7==0 {print $2}'` do ipcrm -m $i done If you have nawk, it's just ipcs -mo | nawk \ '$1=="m" && $3~/0x7f/ && $7==0 {system(sprintf("ipcrm -m %s",$2))}' Now, there is a hitch: *** BUG REPORT (with fix) *** ipcs(1) on SunOS 4.0 reports NATTCH incorrectly. The problem lies in the fact that the shm_nattch field of the shmid_ds structure for the shared memory segment is not updated when a segment is attached -- there is no need to. Its value is actually the value of the refcnt field of the anon_map structure associated with the segment, and that's maintained properly. The only time shm_nattch is set is when you do a shmctl(IPC_STAT), and subsequent ipcs(1) report NATTCH correctly. If a process terminates, though, the shm_nattch field stays incorrect until YA proccess does a shmctl(IPC_STAT). Fixing this in the kernel is not worth it, as the field is ONLY used by the IPC_STAT code. Rather, the following fix to ipcs.c will follow the pointers properly and return the correct value for NATTCH. ____________________ CUT HERE ____________________ *** ipcs.c.orig Thu Oct 20 16:42:00 1988 --- ipcs.c Thu Oct 20 16:42:00 1988 *************** *** 17,18 **** --- 17,19 ---- #include <sys/shm.h> + #include <vm/seg_vn.h> #undef KERNEL *************** *** 90,92 **** char hostnm[64]; /* used for gethostname() */ ! /* Go through the options and set flags. */ --- 91,94 ---- char hostnm[64]; /* used for gethostname() */ ! struct anon_map amp; /* used to get refcount */ ! /* Go through the options and set flags. */ *************** *** 222,224 **** if(oflg) ! printf("%7u", mds.shm_nattch); if(bflg) --- 224,230 ---- if(oflg) ! { ! reade(mds.shm_amp, &, sizeof(amp)); ! printf("%7u", amp.refcnt-1); ! } ! if(bflg) ____________________ CUT HERE ____________________ Hope all this helps, (and I hope noone has posted this before -- I was out of touch for about a month). /ji In-Real-Life: John Ioannidis Organization: GIP ALTAIR [IN2-INRIA-LRI] P-Address: Domaine de Voluceau, BP 105 / Rocquencourt 78153 Le Chesnay / France V-Address: +33 1 39635417 E-Address: ...!mcvax!inria!bdblues!ji, ji@bdblues.altair.fr Alt-E-Address: ji@columbia.edu ------------------------------ Date: Fri, 21 Oct 88 10:02:29 PDT From: vsi1!lmb@ames.arc.nasa.gov (Larry Blair) Subject: Re: UUCP, bug or feature I discovered a "feature" in uucp that will let you do what you want to. If you begin the phone number in the L.sys file with a alphabetic string, the value for that string in the L-dialcodes file is prepended to the number that follows. More importantly, if the replacement string begins with an "S", the Hayes dialer prepends only "AT" rather than the usual "ATDT". I use this feature to set registers on my Trailblazer. L.sys: site Any ACUHAYES 19200 fast999-9999 ogin: vsi1 L-dialcodes: fast S50=255DT Note that since the Hayes dialer was no longer generating the "DT", I had to do it at the end of the string. Larry Blair ames!vsi1!lmb lmb%vsi1.uucp@ames.arc.nasa.gov ------------------------------ Date: Thu, 20 Oct 88 17:52:07 PDT From: Richard Smith <smiddy@spam.istc.sri.com> Subject: Xylogics 753 vs 7053? What is the difference between the Xylogics 753 and the Xylogics 7053? I know we have a couple of 7053s here, but no 753s. Smiddy@spam.istc.sri.com ------------------------------ Date: Fri, 21 Oct 88 7:16:56 EDT From: "Tim G. Smith" (Mechanical) <tsmith@usna.mil> Subject: Xylogics 753 vs 7053 and 451 > I just received a 4/280 with 2 of the 900 Meg disks, and it has the same > tired old Xylogics 451 controller... > Has anyone been able to swap their 451 for a 753 or 7053?... I haven't swapped any 451's but I have bought some 753's. I would suggest just trashing the 451 if need be and ordering a 753. Your system is going to be so slow with those nice fast drives being choked to death by the 451. I belive the 753 is availible for about $2500 or so- not very expensive and well worth the money for the performance gain over the 451. If I were you I would avoid getting a 7053 as I don't think it supports 3.0MBy/sec data transfer (I belive it is limited to 2.4MBy/sec). Many of the newer disk drives support 3.0MBy/sec (Fujitsu M2382K, CDC Saber among others). I have been told that sun will maintain the 753 as well as the 7053. I know that it is possible to get a 753 from Sun Federal if you are a big customer who REQUIRES 3.0MBy/sec transfer rates. Check with the normal third party vendors if you want more info. I have had good experiences with: Software Associates (215) 967-1846 (800) 4551-2875 My sales rep is Dave Suter. Usual disclaimer.... I am just a satisfied customer- I don't work for the folks or anything devious like that... Good luck, Tim Smith US mail:ECSD/CADIG mailstop: 11G E-mail: US Naval Academy internet:tsmith@USNA.MIL Annapolis, MD 21402 uucp :...!uunet!usna!tsmith MaBell :(301)267-4413 ------------------------------ Date: Fri, 21 Oct 88 14:31:38 EDT From: mitel!avalon!carter@uunet.uu.net (Mike Carter) Subject: Upgrade 3/50 to 8 MBytes Clearpoint is working on a product to upgrade SUN 3/50 memory to 8 MBytes. It's not available yet, but it's an option to keep in mind for those who are running OS4.0. Contact Clearpoint for availability and pricing info. In the US, call 1-800-CLEARPT, and in Canada call (416) 620-7242. (No, this is not a paid advertisement!) We're using Clearpoint memory for SUN 3/60's and SUN 4/110's, and are happy with the results. The price is a lot better than SUN's price (but still a whole lot higher than it was 12 months ago...). Mike Carter Mitel Corporation uucp: uunet!mitel!carter ------------------------------ Date: Fri, 21 Oct 88 09:07:06 EDT From: ehrlich@shire.cs.psu.edu (Dan Ehrlich) Subject: Better fix for NSTREAMS Machine Type: Sun 4/260S O/S Version: SunOS 4.0 Organization: Computer Science Department, The Pennsylvania State University 333 Whitmore Laboratory, University Park, PA 16802 Phone Number: +1 814 865 9723 Description: The number of stream data strutures allocated in the kernel is controlled by the definition of NSTREAMS in /sys/conf.common/param.c. Unfortunately as shipped this is hard coded as 32. The enclosed patch attempts to compute a 'better' value based on the number of ptys, installed mcp/alm boards, etc. The other stream constants (also hard coded as shipped) should probably be based on NSTREAMS, but time has prevented me from delving that deeply into the source code to determine whom is related to whom and in what way. Fix: Apply the following patch to /sys/conf.common/param.c and recompile the kernel. *** /tmp/geta9750 Fri Oct 21 08:56:19 1988 --- /tmp/getb9750 Fri Oct 21 08:56:19 1988 *************** *** 153,159 **** #define NBLK (NBLK4096 + NBLK2048 + NBLK1024 + NBLK512 + NBLK256 + NBLK128 + \ NBLK64 + NBLK16 + NBLK4) ! #define NSTREAM 32 #define NMUXLINK 87 #define NSTRPUSH 9 #define NSTREVENT 256 --- 153,167 ---- #define NBLK (NBLK4096 + NBLK2048 + NBLK1024 + NBLK512 + NBLK256 + NBLK128 + \ NBLK64 + NBLK16 + NBLK4) ! #include "pty.h" ! #include "zs.h" ! #include "mcp.h" ! /* ! * NPTY - # of pty from config file ! * NZS - # of CPU serial port controllers (almost always 2) ! * NMCP - # of ALM/MCP boards from config file ! */ ! #define NSTREAM (NPTY + (2*NZS) + (17*NMCP) + 16) #define NMUXLINK 87 #define NSTRPUSH 9 #define NSTREVENT 256 ------------------------------ Date: 21 Oct 88 14:55:00 EDT From: Greg Morrison <MORRISON@CARLETON.BITNET> Subject: Responses to 'S' Query Hi -- thanks very much to the 20(!) people who took time to send me information about where to get the S and S-PLUS statistical programs... the information has been very helpful to us. A representative mailing was that from Douglas Bates: > The latest version of S is documented in the book "The New S Language: > A Programming Environment for Data Analysis and Graphics" by Richard > A. Becker, John M. Chambers, and Allan R. Wilks (Wadsworth, 1988). > In there they state that information on obtaining source code for > S can be obtained from > > AT&T Software Sales > P.O. Box 25000 > Greensboro, North Carolina 27420 > (800) 828-UNIX > > S includes a device driver for SunWindows but does not include dynamic > graphics facilites for SunWindows. These facilities are available in > S-PLUS, an enhanced version of S, sold by > > Statistical Sciences Inc. > 2825 Eastlake Avenue East, Suite 106 > P.O. Box 85625 > Seattle, Washington 98145-1625 > (206) 322-3841 Greg Morrison <MORRISON@CARLETON.BITNET> ------------------------------ Date: Thu, 20 Oct 88 18:27:11 MST From: mc%miranda.uucp@moc.jpl.nasa.gov (Mike Caplinger) Subject: possible compiler bug on Sun 4, sys4-3.2 Consider the following C program: typedef union { int *i; char *s; float *f; } vp; main() { int i; char *s = "hi there"; float f; printf("%x %x %x\n", &i, s, &f); foo(&i); foo(s); foo(&f); } foo(a) vp a; { printf("%d %x %x %x\n", sizeof(a), a.i, a.s, a.f); } On a Sun 3, this yields the correct (?) result: effff50 20034 effff48 4 effff50 effff50 effff50 4 20034 20034 20034 4 effff48 effff48 effff48 On a Sun 4 under sys4-3.2, the result is incorrect: fefffe8c 8008 fefffe84 4 0 0 0 4 68692074 68692074 68692074 4 0 0 0 If we examine the assembler output, we find, preceding the call to printf in foo, the sequence ld [%i0],%o2 ld [%i0],%o3 ld [%i0],%o4 call _printf,5 which should in fact be mov %i0,%o2 mov %i0,%o3 mov %i0,%o4 call _printf,5 by my reading of the definition of C unions. Has this been fixed in 4.0 on the Sun-4 (or perhaps broken on the Sun 3 with 4.0?) [[ I just checked on our Sun 3 running 4.0, and it produces the correct result (modulo pointer value differences, of course). --wnl ]] Mike Caplinger, mc@moc.jpl.nasa.gov ------------------------------ Date: Fri, 21 Oct 88 10:24:09 EDT From: marc@aplpy.jhuapl.edu (Marcus Gates) Subject: sun 4/260 Floating Point Problem I was running a simple-minded floating point benchmark on our sun4 and ran into a problem (The benchmark is just a loop which does floating-point computations). If I don't optimize when I compile, the program runs quickly and uses mostly user time. If I optimize it then it runs for an VERY LONG time and uses mostly system time. I suspect that the usage of system time indicates that the sun is emulating floating-point, somehow forgetting that it has the FPA available. Has anyone else seen this problem?? We are running the 4.0 OS. marc gates johns hopkins applied physics lab, laurel, md UUCP: ...bpa!cp1!aplcen!aplvax!marc Internet: marc@aplpy.jhuapl.edu ------------------------------ Date: Fri, 21 Oct 88 09:56:52 EST From: David Pipes 6-2248 <PIPES@nssdca.gsfc.nasa.gov> Subject: Getting info from damaged system? We have a Sun-2 which has been severely heat-damaged. It will not run reliably for more than an hour or so. It has no ethernet connection, and we have discovered that the tape drive attached to it is also broken. (The machine was out of use for a long period of time...). I have been asked to get some data off of the disk and onto some other medium before the machine is carted off. The method I am considering is to take the disk out and daisy-chain it to either a Sun-3 (Sunos 3.4) or a Sun-4 (Sunos 4.0). It could then presumably be accessed like any other, and the necessary files copied over to the regular system disk. I believe I understand the hardware procedure to do this, but what do I need to do to access the disk? Can I just mount it like any other device and go? If not, how should I go about reading it? Is this idea just plain crazy? Please respond to me. I will summarize replies to here. Thanks in advance! David Pipes Reply to: pipes@nssdca.gsfc.nasa.gov David Pipes NSSDCA NASA Goddard Greenbelt, Md. 20771 301-286-2248 ------------------------------ Date: Fri, 21 Oct 88 10:37:48 PDT From: sytek!syteka!sridhar@hplabs.hp.com (Sridhar Acharya) Subject: Performance on 3/50's with SunOS 4.0? We have a 3/160 server and a bunch of 3/50's with local disks. We were thinking of upgrading to Sun0S 4.0. I keep hearing that 4.0 requires a lot of memory and there may be performance degradation in 3/50's when we migrate to 4.0 since the 3/50 have only 4 Meg. Does anybody have an idea how the performance is with 4.0 on 3/50's with the above/similar configuration. Thanks. Sridhar Acharya sun!sytek!syteka!sridhar or hplabs!sytek!syteka!sridhar ------------------------------ End of SUN-Spots Digest ***********************