Sun-Spots-Request@RICE.EDU (William LeFebvre) (04/18/88)
SUN-SPOTS DIGEST Monday, 18 April 1988 Volume 6 : Issue 56 Today's Topics: Re: Fast Zoom Re: Sun WARNING (follow-up) Re: Problems configuring cua0 on a 3/160 zs0 Object oriented programming techniques for information databases Another small calentool fix Mixing SMD and XSMD drives on a Xylogics 451 Controller Problems with X25 software start-up Problem connecting a Hayes modem Reading TAR and CPIO format SUN cartridges on a PC? Package for color presentation graphics? 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, 8 Apr 88 10:30:55 CDT From: vuse!ip1!hsc@uunet.uu.net (Hsuan Chang) Subject: Re: Fast Zoom I presume the original image is in pixrect format already (or else you have to assemble it into a little pixrect to speed up). I do it the following way: 1) use pr_rop to blow a line at a time into the "tmp array" which is also a memory pixrect; 2) then use pw_rop to blow the "tmp array" onto the pw structure. In other words, I blow the original image in one direction internally via memory pixrect, then in the another direction in a visible way. To further speed it up, use the "pw_batch_*" system call when you do the pw_rop part of the zoom. I'd be glad to give you a piece of code if you send me a mail directly. H. Chang Vanderbilt University hsc@vuse.vanderbily.edu ..!uunet!vuse!hsc ------------------------------ Date: Fri, 8 Apr 1988 15:11-EDT From: David.Maynard@k.gp.cs.cmu.edu Subject: Re: Sun WARNING (follow-up) Reference: v6n45 I wanted to follow up on my recent (rather strong) post about our experience with General Dynamics' Sun-4's. GD's Sun-4's are back up again after two more visits from Sun. It appears that their disk problems were actually due to an improperly configured XY451. Sites with both an Eagle and a SuperEagle on a single 451 can relax now. Apparently this configuration WILL work (GD hasn't tried it though--they turned a Sun-3 into a second fileserver). I do not know why the Dallas Sun office told us that this was our problem. As far as the 2nd ethernet in the Sun-4 is concerned: In a response to my last posting, I received a fix which hopefully will solve the problem. Apparently the VME-Multibus adapter card switches were improperly set when it was installed on the Sun-3 last year. The improper settings will work on the Sun-3, but not on the Sun-4. GD plans to try the change next week. If anyone would like the fix, I will be happy to mail it to them. We ended up moving our whining disk (at CMU) into a 160 cabinet where it is oriented differently. The noise seems to have stopped for now. I have received numerous suggestions about how to stop the noise (see previous Sun-Spots issues) which we will try if it comes back. I previously said that Sun had sold and installed a system which they knew would not work. I do not how to word a statement properly now. They definitely installed a system with a mis-configured 451. I do not believe that they intentionally installed a non-working system, but their initial explanation of what was wrong would make you wonder. About the ethernet controller, the Sun support line was unable to tell GD anything more than "Well, it should work." I can understand their not knowing how to fix the problem, but I cannot understand why they did not try to find a solution. I want to reiterate that I really do think that Suns are wonderful machines. I have also had some very good experiences with Sun support (both hardware and software). I do not want to see Sun's reputation ruined. I simply want to alert them that such things are happening. David Maynard (dpm@cs.cmu.edu) Dept. of Electrical and Computer Engineering Carnegie Mellon University Pittsburgh, PA 15213 ------------------------------ Date: Fri, 8 Apr 88 14:21:31 EST From: lynxys!jim@ee.ecn.purdue.edu (Jim Wildman) Subject: Re: Problems configuring cua0 on a 3/160 zs0 Reference: v6n31 In v6n31 Michael van Biema <MICHAEL@cs.columbia.edu> asks why he can't get /dev/cua0 working right so that he can dialin and dialout on the same line. He wraps up with: > I assume that among the things I've supposedly configured correctly, there > is something that I've overlooked or just plain screwed up, but maybe I've > just missed something completely.... We use a single line for dialin and dialout on our 3/160. The following steps are necessary. 1) Make the changes specified on page 150 of the System Administration Manual, ie change zs0 line of your configuration file from device zs0 at mb0 csr 0xeec80 flags 0x3 priority 2 to device zs0 at mb0 csr 0xeec80 flags 0x2 priority 2 ^^^ (for modem on ttya) 2) Make /dev/cua0 be major device number 12 and minor device #128 /etc/mknod /dev/cua0 c 12 128; chmod 644 ttyd0 Make sure also that uucp owns /dev/cua0 so mail works. 3) Make /dev/ttyd0 be major device number 12 and minor device #0 /etc/mknod /dev/ttyd0 c 12 0; chmod 622 ttyd0 In our case, root owns ttyd0. 4) Enable logins on ttyd0 (edit /etc/ttys) 5) Assign a terminal type to ttyd0 (edit /etc/ttytype). I am not the one who devised this, my predecessor did but it works nicely. The reasoning is that the maximum minor device number is 127, sooooo 0 == 128 and the same minor device has 2 names, /dev/ttyd0 and /dev/cua0. Correct me if my explanation is wrong, but it does work! Jim Wildman jim@lynxys.com 317/497-0309 ------------------------------ Date: Fri, 8 Apr 88 10:17:22 EDT From: Nathaniel Mishkin <apollo!mishkin@eddie.mit.edu> Subject: Object oriented programming techniques for information databases You said: [[ Object-oriented programming: treat the database as an object and "send" messages to it to extract the information you want. Only the object (and thus only the machine/s that "houses" that object) knows how to access it. --wnl ]] In fact, this is *exactly* the approach NCS has taken. All remote calls are considered to be operations (Smalltalk "messages") on abstract "objects". All object have "types" (Smalltalk "classes"). The first argument to all remote procedures is a "self" argument identifying the object on which the procedure (operation) is to operate. Objects, types, operations, interfaces (collections of operation) are identified by fixed-length unique identifiers. Objects are dynamically located by consulting a distributed location database object (which is itself located by broadcast) which contains object UID => network address mappings. The "servers" are intended to be only implementation details -- they are contexts in which a type manager (i.e. the code that knows the internal format of a particular type of object) runs. The idea is that applications execute operations on objects. If the object is local to the caller, the type manager is invoked locally, in the same process as the caller; if the object is remote from the caller, a remote call is made to the "home" of the object (determined by querying the location database). (This last bit of local/remote transparency is not yet completely implemented.) Since all this object-oriented stuff is fairly radical to (say) many Fortran programmers that want to use NCS, we've set things up so that you can pretty much ignore it if you have a one-client / one-server view of the world. (An interface can say that procedures have "implicit" self arguments -- i.e. that a global variable should be consulted to determine the location where the call should be executed.) -- Nat Mishkin Apollo Computer Inc. ...!decvax!apollo!mishkin [[ It's an excellent paradigm to use for that application. --wnl ]] ------------------------------ Date: Fri, 8 Apr 88 19:07:18 EST From: Matt Landau <mlandau@diamond.bbn.com> Subject: Another small calentool fix Calentool 1.4 was failing to remove its temp files when killed by a signal, as it is when you normally exit SunView. The following patch should take care of it. Note that this assumes you've installed my earlier changes to the fix the -f and add the -r flags. If not, your line numbers and context will vary enough to confuse patch. Matt Landau mlandau@bbn.com *** /tmp/,RCSt1a06470 Fri Apr 8 20:03:55 1988 --- calentool.c Fri Apr 8 20:01:09 1988 *************** *** 96,101 **** --- 96,109 ---- struct itimerval cal_timer; int check_calendar(); + static void remove_temp_file() + { + if (access(tmpapts_pathname, R_OK) == 0 && unlink(tmpapts_pathname) < 0) + perror(tmpapts_pathname); + exit(0); + } + + main(argc,argv) int argc; char **argv; *************** *** 179,184 **** --- 187,197 ---- if (access(apts_pathname, W_OK) == -1) read_only = 1; + + /* Make sure temp file is removed later, if necessary */ + (void)signal(SIGHUP, remove_temp_file); + (void)signal(SIGINT, remove_temp_file); + (void)signal(SIGTERM, remove_temp_file); /* Create the tool. */ tool = tool_make(WIN_LABEL, read_only ? "Calendar Tool V1.4 [Read Only]" ------------------------------ Date: Fri, 8 Apr 88 12:56:18 EDT From: Skip Montanaro <montanaro@sprite.steinmetz.ge.com> Subject: Mixing SMD and XSMD drives on a Xylogics 451 Controller Reference: v6n45 In v6n45, David Maynard (Maynard@k.gp.cs.cmu.edu) wrote: The problem was obvious when we thought about it. They put both an Eagle and a Super-Eagle on a 451 controller on the ND server. The controller is known to randomly trash your disks in this configuration. .... [General Dynamics] is VERY close to abandoning Sun altogether after this incident! If Sun does this to other people their reputation will quickly be ruined! When the Super Eagles first came out we asked our local Sun folks, "Gee, can we mix and match Eagle and Super Eagle drives on 450 and 451 controllers?" The response was an emphatic "No!" I suspect the people at General Dynamics got bitten more by inadequately trained local support/sales folks or bad communication than by Sun's attitude as a whole. I think the above incident (I hope it's the exception, rather than the rule) can be attributed to their huge growth in the last couple of years. As customers we have to pressure them to put a properly trained sales and support force in the field. If they don't, we will be forced to move to other vendors. If you believe what Scott MacNealy is saying these days, we will have that opportunity in the near future, as System V/Release 4 and the SPARC/386/680x0 application binary interfaces become available and are marketed by other vendors. Skip Montanaro (montanaro@sprite.steinmetz.ge.com, montanaro@ge-crd.arpa) ------------------------------ Date: Fri, 8 Apr 88 15:47:01 BST From: Ida <ida@EAGLE.WARWICK.AC.UK> Subject: Problems with X25 software start-up I received so many helpful replies to my last query (thanks), I thought I would try another problem we have. We have an X25 link on our Sun 3/280. Starting it by hand is fairly simple: eagle# /usr/sunlink/x25/x29/svr/x29 & eagle# /usr/sunlink/sunuk/ybts/ybts.inetd & eagle# /usr/sunlink/x25/x25config eagle# /usr/sunlink/x25/x25start zss1 9600 These commands were placed in the /etc/rc.local file so the X25 would start when the machine was booted. The following lines show the appropriate entries. (The "sleep" was just in case the X25 daemons needed a little time to settle in). After booting, the daemons are running but the X25 link does not work .. even when I do the "config" and "start" commands by hand afterwards. #-rc.local excerpt---------------------------------------------------------- # # start up the x25 link # # daemon to handle outgoing calls /usr/sunlink/x25/x29/svr/x29 & (echo -n ' x25') >/dev/console # daemon to listen for incoming calls /usr/sunlink/sunuk/ybts/ybts.inetd & (echo -n ' ybts') >/dev/console # sleep to give the x25 time to settle in (sleep 100; /usr/sunlink/x25/x25config; /usr/sunlink/x25/x25start zss1 9 # #--------------------------------------------------------------------------- Has anyone had similar problems? Any ideas? Thanks.. Russ russ@uk.ac.warwick.eagle ------------------------------ Date: 9 Apr 88 19:52:16 GMT From: eric@eddie.mit.edu (Eric Van Tassell) Subject: Problem connecting a Hayes modem I'm trying to connect a Hayes modem to my sun 3-50 and dont know what I've done wrong. When I try to connect with tip, I get "can't sycronize with HAYES" after much flashing of led's on the modem. When I try to go out with uucico -r1 -x7 -smamma I get "AT\015\015\012OK\015\012Line open failed, DIALUP LINE open ". Any clues? Thanks in advance. eric@eddie.mit.edu ------------------------------ Date: Thu, 7 Apr 88 17:23:46 -0500 From: "Robert Cape"@ncrlnk.dayton.ncr.com Subject: Reading TAR and CPIO format SUN cartridges on a PC? I am posting this for a friend who doesn't yet have net access: ********** With this equipment: NCR PC-8 (your basic PC/AT(tm) clone) with 60mb QIC-60 1/4" streaming tape drive OEM'd from Colorado Memory Systems (The drive and controller info I have: 60mb 1/4-inch streaming tape drive Mfgr: Wangtek Model: 55099EN24 Ass'y: 30132-018 Rev.A Controller board (8-bit bus) Mfgr: Wangtek Model: ? Rev.F3 Ass'y: 30850-003 ) Here's needs to be done: At least read (if not read and write) TAR- and CPIO-format tapes produced on a SUN 3/260 with the above-described equipment. Why?: To use said pc to read Postscript files off of SUN tape cartridges and dump them offline to either Postscript-compatible typesetters or 600 dpi laser printers in a graphics production environment. I assume that the drive is likely compatible; the controller - who knows? If the hardware is compatible, what's needed is the software. The person who wants to do this would like to do it under MS-DOS 3.x. Software that runs under XENIX would also be acceptable. ******** If you respond via email, please use the explicit path (bang) method - our mail router has distemper right now. Thanks, Bob Robert M. Cape DOMAIN: cape@stpaul.ncr.com NCR Comten, Inc. UUCP: {backbone}!ncrlnk!ncrcce!cape Information Services Voice: (612) 638-7211 2700 Snelling Ave. N. St. Paul, MN 55113 652-7211 (NCR Internet) ------------------------------ Date: Fri, 8 Apr 88 17:04:56 +0200 From: per@ifi.uio.no Subject: Package for color presentation graphics? We are looking for a program package for interactive design of color presentation graphics. The package should have the following features: -- Operate on Sun 3 using X-windows. -- Interaction preferably through menus and not through a cryptic command language. -- Produce 'business graphics' (xy-plots, bar plots etc) from data stored in ASCII format or any other simple format. -- Good tools for free-hand drawing, painting, creation of standard objects like boxes, circles, polygons and spline operations. -- Easy color manipulation including grading. Palette of 3 x 8 bits would be nice. -- Text generator with scalable and rotatable fonts. -- Device independent format (i.e. vector-based, not bitmapped). Storage format should be well defined for easy access. -- Drivers for output to color thermal printer (Mitsubishi), camera recorder (Matrix QCR) and black-and-white lasers (Imagen). If anybody knows about any such product, we would be grateful for suggestions and addresses of vendors. Best regards, Per Grottum Institute of Informatics University of Oslo Norway ARPA-address: per@ifi.uio.no ------------------------------ End of SUN-Spots Digest ***********************