Sun-Spots Digest, v6n56
William LeFebvre
Sun-Spots-Request at RICE.EDU
Tue Apr 19 02:09:47 AEST 1988
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 at rice.edu
Send subscription add/delete requests to: sun-spots-request at 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 at 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 at 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 at vuse.vanderbily.edu
..!uunet!vuse!hsc
------------------------------
Date: Fri, 8 Apr 1988 15:11-EDT
From: David.Maynard at 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 at 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 at ee.ecn.purdue.edu (Jim Wildman)
Subject: Re: Problems configuring cua0 on a 3/160 zs0
Reference: v6n31
In v6n31 Michael van Biema <MICHAEL at 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 at lynxys.com
317/497-0309
------------------------------
Date: Fri, 8 Apr 88 10:17:22 EDT
From: Nathaniel Mishkin <apollo!mishkin at 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 at 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 at 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 at sprite.steinmetz.ge.com>
Subject: Mixing SMD and XSMD drives on a Xylogics 451 Controller
Reference: v6n45
In v6n45, David Maynard (Maynard at 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 at sprite.steinmetz.ge.com, montanaro at ge-crd.arpa)
------------------------------
Date: Fri, 8 Apr 88 15:47:01 BST
From: Ida <ida at 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 at uk.ac.warwick.eagle
------------------------------
Date: 9 Apr 88 19:52:16 GMT
From: eric at 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 at 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 at 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 at 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 at ifi.uio.no
------------------------------
End of SUN-Spots Digest
***********************
More information about the Comp.sys.sun
mailing list