Sun-Spots Digest, v6n144
William LeFebvre
Sun-Spots-Request at RICE.EDU
Tue Jul 19 12:29:32 AEST 1988
SUN-SPOTS DIGEST Monday, 18 July 1988 Volume 6 : Issue 144
Today's Topics:
Re: SunOS 4.0 on Sun2's
Re: sharing an Imagen between VAX/VMS and Suns
Re: Why is my 3/60 so slow - and why is mine unusable
Re: MacPaint/Draw -> Sun Raster
Source for undump that works under 4.0
Experiences with 4.0
Pascal Compiler Distributed with UNIX 4.2BSD & Unsigned Byte
Problems with Sun DDN X.25 software (hanging FTP and RCP)
Disappearing suntools background image
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 Jul 88 09:05:19 PDT
From: stevo at jane.jpl.nasa.gov (Steve Groom)
Subject: Re: SunOS 4.0 on Sun2's
Reference: v6n139
[[ This is a followup to his posting in v6n139. --wnl ]]
With help from Sun we managed to figure out where the problem was, and we
have devised a patch for it. We installed the patch, removed the 701
jumper, and have been running without difficulty for two days now.
The speedup (due to removal of the jumper) is noticeable, and although
elroy is still slower than before 4.0 (because of increased paging and
swapping under 4.0), it is much better than before the patch.
The problem is in trap.o, in two places. The old code:
_trap+0x16e: andl #0xffffff77,d0
and
_trap+0x3ae: andl #0xffffff77,d0
The patch is to change these two instructions to:
_trap+0x16e: andl #0xffffff67,d0
and
_trap+0x3ae: andl #0xffffff67,d0
NOTE: THE FOLLOWING IS *NOT* AN OFFICIAL PATCH FROM SUN. IT IS SOMETHING
THAT WE WORKED OUT ON OUR OWN. APPLY AT YOUR OWN RISK.
Also note that this patch will only help you if you were forced to install
the 701 jumper to get 4.0 to run on your system. There are legitimate
reasons for needing this jumper in, and in those cases, removing the
jumper will cause problems for you whether or not this patch is installed.
In general, if you ran *without* the jumper before 4.0, then this patch is
for you. If you ran *with* the jumper, check with someone knowledgeable
before trying to remove it now.
Apply as follows:
# cp /vmunix /vmunix.save
# adb -w /vmunix
trap+0x172?w 0xff67
trap+0x3b2?w 0xff67
# halt
(Remove 701 jumper from CPU board and reboot)
To permanently install the patch:
# cd /usr/sys/sun2/OBJ
# cp trap.o trap.o.dist
# adb -w trap.o
trap+0x172?w 0xff67
trap+0x3b2?w 0xff67
#
Then rebuild your kernel. Any future kernels you build will contain this
patch.
-steve
/* Steve Groom, MS 168-522, Jet Propulsion Laboratory, Pasadena, CA 91109
* Internet: stevo at elroy.jpl.nasa.gov UUCP: {ames,cit-vax}!elroy!stevo
* Disclaimer: (thick German accent) "I know noothingg! Noothingg!"
*/
------------------------------
Date: Thu, 7 Jul 88 16:40:00 EDT
From: "Ruth Milner, Systems Manager x2746" <SYSRUTH at UTORPHYS.BITNET>
Subject: Re: sharing an Imagen between VAX/VMS and Suns
Reference: v6n125
John Benjamins at McMaster asks about sharing an Imagen laser printer
between a VMS VAX and a network of Suns. I don't know about any
multiplexors designed specifically for this; we opted for a different,
broader, technique.
Our systems programmer, James MacEwan, wrote a program that will open a
DECnet channel to the VAX and connect to a DCL task there. A script checks
arguments, file type (ever had an executable printed on your laser
printer? we have), etc., and the executable copies the file over using
dnacp and transfers the print command to the VAX, which executes it.
Qualifiers are supported, though only one file can be printed per command.
All the user has to do, apart from typing the initial command, is enter
his/her VMS password when prompted (and if you don't care about page
accounting, this wouldn't be needed either). There is a script to be
executed from other Suns which do not run DNI, since the procedure is
somewhat different. A file which can be source'd in .cshrc contains all
the aliases for accessing various printers, with some aliases provided for
common qualifiers as well.
This should work for any printer on the VAX(es) that you have. We just
assign a number to each, and take different actions depending on which
printer-number was specified. We have 3 line printers, 4 Imagens, an Apple
LaserWriter, and a Versatec plotter, on various VAXes. This works for all
of them.
I am willing to shar this up and make it available through the archives,
with the following caveats to anyone who picks it up:
1. We have only tested it at 3.4 running DNI 5.0, on a Sun 3/180. The
remote printing part is just a script and is in constant use on a Sun
4/280 at 3.2FCS, and Sun 3/50's running 3.5 (clients of the Sun 4).
I have no doubt it will break at 4.0, since DNI will probably be changed
(at least I hope it will be). On the VMS end, this has worked from V4.4
through V4.7 (we skipped 4.6, but it should work there too).
2. The setup is highly site-specific and will require a fair amount of
tailoring for such things as where the file to be printed is copied,
whether one uses each user's VMS username (as we do, from DNA_USER) or
a common account, printer numbers, exact commands, etc. etc.
3. We cannot be responsible for support; we have only two full-time people
to manage 8 VMS VAXes, the Suns, and about 400 users. We just won't have
time. If there is interest in this I will attempt to make clear docu-
mentation, but there is nothing especially complicated about any of the
steps involved. And, in the usual manner of PD software, we cannot be
responsible for *any* problems the software may cause on your system(s).
("It works for us" :-) ).
If there is enough interest indicated to me, I will put this together.
This may be adequate for many people; at any rate it is fairly transparent
to the users - just a little slow (it is DECnet, after all :-) ). I don't
know precisely how many people out there are in this situation, but I have
heard of about three sites.
Since we are in the gradual process of migrating everyone to the Suns,
this will not do for us in the long term. I intend to buy an Imagen with
PostScript capability in the near future and hook it up to a Sun (or the
Ethernet, if page accounting is kept properly). There are a number of
plotting programs here that produce imPRESS output, so we do need both.
Just as a further comment ...
>If you already have an Ethernet and are willing to get an Ethernet card
>for the Imagen (assuming the Imagen you have has this as an option---you
>didn't specify the model number) then you can hook all of them up to the
>Ethernet and share the printer that way. --wnl
This is a terrific alternative, provided your VAX(es) talk TCP, which is
the only protocol the Imagens can use on the Ethernet. And, as wnl
mentions, as a solution it depends very much on the model of Imagen you
have. The smaller ones, ImageStations or IP/III's, don't have this as a
retrofit---if you didn't buy it with an Ethernet interface, you can't add
one later (at least, that's what the company who maintains our Imagens
tells me). The bigger models, 2308, 3320's etc., can have this option
installed in the field.
Please let me know if you are interested in these programs. I hope they
can help somebody.
Ruth Milner
Systems Manager
University of Toronto Physics
BITNET: sysruth at utorphys Internet: sysruth at helios.physics.toronto.edu
------------------------------
Date: Fri, 8 Jul 88 15:09:22 EDT
From: david at pyr.gatech.edu (David Brown)
Subject: Re: Why is my 3/60 so slow - and why is mine unusable
We purchased 4 sun 3/60's, each with it's own 70 Meg disk. I configured a
two servers, each using two of the disks (yes, this IS a dumb way to do
it). When a client would cause ND traffic, both of the machines would all
but lock up until one or the other was halted. After about a week of
complaining to Sun, they finally tried it for themselves and found out
that there really was a problem. We sent the four 71 Meg disks back and
got 2 141's.
Try using etherfind on another workstation to see if your server and
client (I'm assuming you're a client) are jabbering too much. If so,
complain to Sun that they sold your a configuration that doesn't work.
Hope this helps!
-David Brown
David Brown
Armstrong State College, Savannah, Georgia
uucp: ...!{akgua,allegra,amd,hplabs,ihnp4,seismo,ut-ngp}!gatech!gitpyr!david
ARPA: david at pyr.gatech.edu
------------------------------
Date: Fri, 8 Jul 88 8:38:06 EDT
From: Marty Hall <apl_aimh at jhunix.hcf.jhu.edu>
Subject: Re: MacPaint/Draw -> Sun Raster
esosun!kobryn at seismo.css.gov (Cris Kobryn) asks about converting
MacPaint files to Sun raster files.
Jef Poskanzer's "Portable Bitmap Toolkit" converts bitmaps among the
following formats: Sun Raster, Sun Icon, MacPaint, X10, X11, PBM (his own
format), PostScript (only "to", not "from"), and Printronix printer
graphics (also only "to"). It is available via anonymous ftp from
expo.lcs.mit.edu (18.30.0.212) as "pbm.tar". Also note a huge (815
entries, 47 megabytes uncompressed!) collection of bitmaps there also.
- Marty Hall
apl_aimh at jhunix.hcf.jhu.edu Artificial Intelligence Laboratory, MS 100/601
...uunet!jhunix!apl_aimh AAI Corporation
apl_aimh at jhunix.bitnet PO Box 126
(301) 683-6455 Hunt Valley, MD 21030
------------------------------
Date: Thu, 7 Jul 88 05:41:06 EDT
From: Jean-Francois Lamy <lamy at ai.toronto.edu>
Subject: Source for undump that works under 4.0
undump for a Sun 4 is essentially the same as for a sun 3. The program
normally uses a routine called scanargs, which does not use varargs.
Enclosed is a shar file that includes a version which does argument
parsing with absolutely no finesse and does not call to the problematic
scanargs (which I've omitted). cc -Dsun4 produces a result that is
usable on Sun 3s as well, so we might as well forget about scanargs
altogether.
This version has been sent to Pierre Mackay, the Unix TeX coordinator, and
the fix should appear in some form or other on the distribution.
Jean-Francois Lamy lamy at ai.utoronto.ca, uunet!ai.utoronto.ca!lamy
AI Group, Department of Computer Science, University of Toronto, Canada M5S 1A4
[[ The source has been placed in the archives under "sun-source" as
"undump4.shar". It can be retrieved via anonymous FTP from the host
"titan.rice.edu" or via the archive server. It is 11596 bytes long. For
more information about the archive server, send a mail message containing
the word "help" to the address "archive-server at rice.edu". --wnl ]]
------------------------------
Date: Fri, 8 Jul 88 11:00:33 EDT
From: Tim Bray <tbray at watsol.waterloo.edu>
Subject: Experiences with 4.0
I recently ported a few applications, somewhere between 50 and 100k lines
of C, to a new Sun4 running SunOS 4.0. Thought I'd share my experiences.
This stuff runs on various other vaxes, suns, under VM on IBM, and on
other unix machines, so is pretty portable
The bottom line is good - except for one item discussed below, the
software ported fine and appeared to work fine. The performance was
pleasing - about that of a Vax 8650.
1. Compiler smartness
The 4.0 compiler detected a few places where a variable declared unsigned
(unsigned short I believe) was compared to -1. No other compiler has
caught this; however I think on most machines the compiler would probably
arrange for the `right thing' to be done.
2. Irritating nit with /bin/time
Namely, it's now /usr/bin/time. This was the only place the 4.0 directory
reorg bit me. Our test suite is driven by a csh script (hey, I didn't
write it, I'd have used sh) which contains a lot of:
/bin/time $test-program $test-script >& $test-output
to avoid the silly output from the csh builtin. So the whole validation
suite failed, causing a bit of panic. Wouldn't be surprised if this bit a
few more people.
3. Portability gotcha
One of our big programs prints out the elapsed CPU time when it finishes.
It was claiming, in all cases, to have used 0.0 CPU sec. Didn't think
Sun4's were *that* fast. The offending code fragment was:
printf("used %.2f CPU seconds\n", CpuTime());
The problem: CpuTime() wasn't declared float; obviously the Sun4 does
some magic in the way it passes float args and/or return values around.
Yes, we're wrong here, and lint would have caught it, sigh.
4. Really Irritating Item
All the tests in the suite with floating point output failed. It turns
out that on most unix systems, the construct
printf("%g\n", 0.1); produces:
0.1
On the Sun-4, it produces:
.1
This is well within the letter of the law as expressed by the man page.
Nonetheless, it seems to me a gratuitous portability violation that will
probably break all sorts of technical applications.
Anyhow, could have been a lot worse.
Tim Bray,
New Oxford English Dictionary Project, U. of Waterloo, Ont., Canada
------------------------------
Date: Thu, 7 Jul 88 13:15:31 EDT
From: sundc!student!tukey!mac at seismo.css.gov (Mary Ann Ciuffini)
Subject: Pascal Compiler Distributed with UNIX 4.2BSD & Unsigned Byte
I have the Pascal compiler that was distributed with UNIX 4.2BSD.
Unfortunately there is no such thing as an unsigned byte. The only way to
get 8 bits (that isn't a boolean or char) is to define byte = -128..127.
I tried defining byte = 0..255 (which is what I want, an unsigned byte)
and I ended up with, you guessed it, 2 bytes.
Now I hear that the new Pascal compiler, version 1.1?, may support an
unsigned byte. Is this true? I need to know immediately. Also does
Pascal 1.1 run only under Sun-OS 4.0?
Mary Ann Ciuffini <...!uunet!seismo!sundc!student!tukey!mac>
------------------------------
Date: Fri, 8 Jul 88 13:06:46 EDT
From: John T. Nelson <jtn at potomac.ads.com>
Subject: Problems with Sun DDN X.25 software (hanging FTP and RCP)
At Advanced Decision Systems in the Arlington office we have a Sun III/180
running release 5.0 of the DDN and X.25 software. We talk to a
neighboring PSN through a pair of 9600 baud syncrhonous modems.
I seem to be having problems with FTP and RCP hanging. The behavior is
similar to the famous sequence number problem in the 3.4 TCP code, however
I have the TCP patches installed and I'm still having problems.
SYMPTOMS:
I start FTP or RCP on a large file, say 100,000 - 1,000,000 bytes long.
About 50 - 100 K bytes through the file, the rcp or FTP process will
suddenly stop transfering data. The process itself goes into an idle
state which is normal becuase these processes often are idle as they wait
for data to come across the line. I suspect that the process is waiting
for an acknowledgement or some other signal and never gets it.
If I try doing the transfer in the early morning hours (EST), when the
network is most likely quiescent, then the transfer often succeeds. We're
going to start testing with the NOC pretty soon too see if it is a problem
with the network or PSN.
Has anyone seen these sort of symptoms before? Has anyone devised a fix
yet?
------------------------------
Date: Fri, 8 Jul 88 18:47:58 EDT
From: Ellery Chan <ellery at trantor.harris-atd.com>
Subject: Disappearing suntools background image
I have a Sun 3/60 with the color option. I like to run with 2 suntools
because the monochrome overlay plane scrolls faster. Often, however, the
background image or pattern on the color (/dev/cgfour0) side disappears,
but never while I'm looking at it. A redisplay will bring it back. The
monochrome (/dev/fb) side doesn't exhibit this problem. I start the color
side first, then the monochrome, then start adjacentscreens.
I have seen windows that seem to lose their backing pixrects when swap
space gets tight, but a redisplay doesn't help there. (This was back when
I had a 3/50 with much less swap.)
My question is: why does the background disappear, and what can be done
to prevent it from doing so? Also, how is it that backing pixrects of
windows can seemingly get clobbered on a whim, and with no indication that
anything is amiss?
[[ Submitters are going to have to start specifying exactly what version
of the operating system they are running when reporting apparent software
bugs. Otherwise, those who want to respond will not be able to help as
easily. --wnl ]]
Ellery Y. Chan | Phone : (407) 729-3364
Advanced Technology Department | ARPA : ellery at trantor.harris-atd.com
Harris Corporation (GSS) | USmail: PO Box 37, MS 3A-1912
Melbourne, FL 32901 | Melbourne, FL 32902
------------------------------
End of SUN-Spots Digest
***********************
More information about the Comp.sys.sun
mailing list