Sun-Spots-Request@RICE.EDU (William LeFebvre) (04/17/88)
SUN-SPOTS DIGEST Sunday, 17 April 1988 Volume 6 : Issue 55
Today's Topics:
Re: Problems reading tar tapes (2)
Re: LAT on SUN
Re: Apollo <> Sun cartridge tape conversions
TCP bug in 3.5 - not a bug after all
sun bcopy (yet again...)
disk trashing problem
Problems adding SCSI disk to Sun 2/120
Problems using cgpixwindd color maps
Getting mail between Suns and VAX/VMS DECNET?
Positioning icons on the screen?
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: 8 Apr 88 14:36:14 GMT
From: Rich Salz <rsalz@bbn.com>
Subject: Re: Problems reading tar tapes (1)
Reference: v6n47
Person A:
>I suspect the problem is byte ordering. ...
>... The tar headers have miscellaneous ints and shorts, hence it matters.
>
Person B:
>... you're completely incorrect here. The header for
>a tar file is an array of character strings....
So? If there are byte-ordering problems they will show up even if
the header is written in ASCII:
'/' 't' 'm' 'p' '/' 'f' 'o' 'o'
't' '/' 'p' 'm' 'f' '/' 'o' 'o'
[[ So everything! Tar headers do NOT have "miscellaneous ints and
shorts". If ASCII strings work, then so does tar. --wnl ]]
Anyhow, yes, it's possible that the problem is byte-ordering. There are
some machines out there with really stupid device drivers (not just
controllers). In particular, the Integrated Solutions has a set of
/dev/srt0..8 tape drivers; the 's' stands for 'swap the bytes.'
Try reading in your tape with dd and byteswapping, as in:
dd conv=swap </dev/st0 | tar vtf -
/rich $alz
------------------------------
Date: 11 Apr 88 09:24:56 PST (Mon)
From: hendrick@cel.fmc.com (Jim Hendrickson)
Subject: Re: Problems reading tar tapes (2)
Reference: v6n47
Sorry to disagree, but byte-order problems *do* affect ASCII strings.
Byte-order refers to order within a word, so swapping will render the
headers unreadable.
We routinely read tapes, generated on SUNs (with rst8) on Silicon Graphics
machines. Byte swapping is necessary to read them at all:
dd if=foo bs=126b conv=swab | tar xf -
To see if this is the problem, use dd alone (to stdout). A string like
abcdef ghi will look like badcfeg ih if byte order is incorrect. Most
tapes will have some English text near the front to examine.
Jim Hendrickson
FMC-Advanced Systems
hendrick@cel.fmc.com
[[ But the point is that it isn't tar's fault, and tar does NOT have
shorts and ints like the original poster stated. When I said that tar
files "are not subject to byte ordering problems", I meant that they are
not subject to the conventional well-known byte ordering problems of 16
and 32 bit binary data. It seems that some tape drive manufacturers have
assumed that the ONLY data you will be writing with their tape drives is
16-bit binary data. I would quickly find another tape drive manufacturer,
or at least complain rather loudly. The tar format uses ASCII strings for
a very good reason: you can't get much more universal than a string of
ASCII characters (despite what IBM thinks). --wnl ]]
------------------------------
Date: Thu, 7 Apr 88 14:01 EST
From: SYSRUTH@UTORPHYS.BITNET
Subject: Re: LAT on SUN
Reference: v6n45
In v6n45, Chris Simatos raises a question about getting LAT, DEC's
terminal server protocol, on Suns.
Well, the code is proprietary, so I wouldn't hold your breath for it. DNA
(although "DNA" itself can't be used, hence "DNI" now) is not, at any rate
not in the same way. Granted, Emulex has now come out with a
"LAT-compatible" terminal server which, from what I've seen, works well,
but there is a major caveat involved here.
To be specific, if DEC ever changes anything in LAT, any company which has
a compatible product will have to compensate for those changes in their
software and then distribute the new version (or patches) to their
customers. This can often take, quite literally, several months. Second
(and at least as important), if it isn't SUN who develops the product, the
third-party vendor involved will very likely have to make changes every
time Sun comes out with a new version of the operating system - and
actually, so would Sun if they *did* put it together. (I think the chances
of Sun developing it are small because, for one thing, there are TCP
terminal servers available; and for another, Emulex is working on a
terminal server that is both TCP- *and* LAT-compatible, which is much
more useful. DECnet was different and in fact there are now something
like 20 companies which have DECnet available on their machines. See
_Digital_Review_, March 21, p.1).
This means that if someone were to come out with LAT-compatible software
for the Sun, they would be hit by a double whammy, dependent on two
totally independent companies' implementations of proprietary software,
and would have to keep their product up-to-date with both. And anyone
using it would be caught in a cycle of which-version-of-DEC-LATplus-goes-with-
which-version-of-product-goes-with-which-version-of-Sun-UNIX and not
being able to upgrade either their VAXes or their Suns until they had the
right combinations. Yuck, not for me, thanks. Although I do have third-party
software, hardware, and patches on my machines, at least I can keep the
Suns separate from the VAXes!
So, although it's theoretically possible, I don't think you'll see it.
Disclaimer: Of course, this is just a personal opinion, and it could be
totally out in left field. Sorry to be so discouraging, but I feel very
strongly that it wouldn't be worth the time and effort for anyone to do
it.
Ruth Milner
Systems Manager
University of Toronto Physics
------------------------------
Date: Thu, 7 Apr 88 15:16:49 cdt
From: Rod Montrose <texsun!cadretx!montrose@sun.com>
Subject: Re: Apollo <> Sun cartridge tape conversions
Reference:v6n34
Some notes on how to move files between Apollo and Sun machines.
o You need to use the /dev/rct8 on the Apollo, and /dev/rst8 (both are
QIC24 I believe), and use tar on both machines. This requires Domain/IX
on the Apollo nodes.
o After the tape is loaded on the Apollo, before reading or writing to the
tape you have to "prep" the tape drive. Do a "rbak -dev ct -rewind". You
should then be able to get tar to recognize the drive.
o When writing a tar cartridge tape drive on the Apollo, you MUST use a
blocksize of 1. If you look hard enough into the Apollo manuals you will
find this documented.
I routinly move files between Apollos and Suns using 1/4 inch cartridge
tape using the above routines. If you have any further questions please
give me a call or mail.
Rod Montrose
Cadre Technologies, Dallas Office
(817) 261-4174 uucp: texsun!cadretx!montrose
------------------------------
Date: Thu, 7 Apr 88 13:27 EST
From: SYSRUTH@UTORPHYS.BITNET
Subject: TCP bug in 3.5 - not a bug after all
The following is from a message I received via one of our local SUN field
service engineers after he noticed my posting on sun-spots (thank you!).
It essentially says that the value of x200 for tcp_mss still seen in 3.5
is not a bug, but is part of a change in the way TCP is being implemented.
As far as I can tell, the original author was Ray Jang. I hope he does
not object to my posting this. It is very informative and should be useful
to a number of people who may be running an incorrectly-patched 3.5 TCP
(like me :-) ).
Incidentally, I feel this could have been infinitely better documented in
the list of bug-fixes at 3.5. It is not unnatural for people to assume the
bug is still there if a) there is no mention of a fix, and b) the value of
that kernel variable is unchanged. Nor should it be surprising that many
people probably didn't even bother to test it, when the only mention of
anything that could be related is:
"TCP Performance Problem TCP performance has been improved."
(Release 3.5 Manual, Ch. 5, p. 84)
Ruth Milner
Systems Manager
University of Toronto Physics
--------
"Some background....the original logic intended for 3.4 tcp packet size
was to use 1024 (1078) byte packets if transfer was within local net and
512 (566) byte packets if transfer was to be routed through a gateway to
another net. In 3.4 this logic didn't work correctly and was sending all
packets out as 512. The adb patch changed this tcp mss value to 1024 so
all packets would default to 1024 instead. But still after patch the
intended logic was not fixed - all packets sent were 1024 regardless of
route.
"In 3.5 the logic was fixed (at least confirmed in my testing) so local
net tcp transfer from a 3.5 machine used 1024 and tcp routing through
gateway used 512. An adb look at the 3.5 tcp mss value shows it set to
512, so there is obviously more code involved in 3.5 affecting tcp packet
size. The simple 3.4 fix DOES NOT apply to 3.5 unless there's proof
otherwise. Because of this logic it is real important for a customer, who
says the problem was not fixed in 3.5, to specify exactly under what
circumstances he is observing this, because in my observations with
etherfind:
"1) Is customer SENDING from a 3.5 machine? If it's a 3.4 sending and a 3.5
RECEIVING then the original 3.4 problem will exist, sender dictates.
"2) Where is transmission going to? If sending machine is 3.5 and sending
to machine on local net then tcp packet size should be 1024 (1078). If
sending to machine over gateway on another net then packets should be
512 (566).
"In a nutshell, the problem *is* fixed in 3.5.
"For those non-believers, you can monitor this using `etherfind -proto
tcp`, restricting it to a specific dst and src to make things simpler.
Ftp'ing a file shows the length to be 1078 under 3.5 (running off-the-
distribution-tape software) where as the same test under 3.4 shows the
length to be 566."
------------------------------
Date: Thu, 7 Apr 88 18:12:56 EDT
From: schwartz@gondor.cs.psu.edu (Scott Schwartz)
Subject: sun bcopy (yet again...)
In v6n40, casey at llnl talks about bcopy speed on sun3s. I tried his
sample program on a sun 3/160 and a sun 4/260.
Sun 3/160. with 24 char offset
6.7u 3.6s 0:13 75% 0+256k 2+0io 0pf+0w
Sun 3.160. without 24 char offset
5.8u 0.4s 0:06 98% 0+256k 2+0io 0pf+0w
Sun 4/260. (24 char offset made no difference.)
16.5u 0.1s 0:16 100% 0+65k 2+0io 0pf+0w
Pretty sad, no?
-- Scott Schwartz
------------------------------
Date: Thu, 7 Apr 88 15:49 EST
From: SYSRUTH@UTORPHYS.BITNET
Subject: disk trashing problem
Reference: v6n45
In v6n45, David Maynard described a problem at a site with a Sun 4/280, a
Xylogics 451, and 1 Eagle and 1 Super-Eagle hanging off the controller.
It's hard to tell if what I explain below has anything to do with that
problem, but it is something I think people should be aware of anyway. My
apologies for being a bit vague in some of the description; I couldn't get
a really clear full explanation myself.
Back when we were having severe problems with our Sun 4's second Ethernet
controller, one of the things Sun service investigated was whether the
problems might have anything to do with the fact that we have an Eagle and
a Swallow (550 MB 8" Fuji drive) on our Sun 4's 451. There is something
picky about the "drive type" you specify when formatting and labelling a
new disk. If you have two different types of drives on the same
controller, you have to be careful that they are specified with different
"drive type" numbers (this is common sense, of course, but I expect it is
possible to do it wrong :-) ). This drive type value is part of the
information written into the header of every block on the disk when it is
formatted. Thus there is an easy way to check (with your system shut down)
whether drives have been set up correctly. Boot stand/diag off the system
disk, and use the rhdr command. The section in the manual on rhdr
describes the layout of the header bytes. The drive type is the first two
bits of the third byte. So by first using xy0 and then xy1, you can get a
short listing from each drive and compare them. If your drives are
different geometries (i.e. # cylinders/tracks/sectors), this byte should
be different on each. If it isn't, you're in trouble. Note that you can't
have two different "Other" types on the same 451; the controller will
become very confused.
Our service person had to dig to find some of this information. The header
contents are used at some point when writing to the disk (he wasn't sure
exactly when), and if the type has been specified incorrectly the drive
could very easily be trashed because the wrong geometry might be used. I
suspect this would be easy to do with an Eagle/Supereagle combination,
particularly if one were using an older version of diag which didn't offer
M2361 as a choice.
As I said, I don't know whether this could be the problem David Maynard
described, but it would certainly be something for the hardware people at
that site to check. (I would also not settle for "it happens". Whether or
not Sun can do anything about it, a customer who has lived with a problem
like this deserves a better explanation than that, even if it's only "We
don't know why but we're working on it" - and I hope they are).
Ruth Milner
Systems Manager
University of Toronto Physics
------------------------------
Date: 7 Apr 88 03:16:28 GMT
From: prcrs!decuac!elijah!tarsa@uunet.uu.net (Greg Tarsa)
Subject: Problems adding SCSI disk to Sun 2/120
I have a Sun 2/120 that has the dual Fujitsu 2322 disk option and the SCSI
tape drive and I would like to add a SCSI disk to it. I have no manuals,
so everything I have done to date has been from comparing my system to
another at a client site that has a SCSI disk already.
It appeared that the power cables are included for the SCB-4000 controller
and one SCSI disk come as part of the basic Sun 2/120 package.
The SCSI target adaptor and SC-4000 also come for free, since I have the
1/4" tape drive subsystem. I have acquired an ACB-4000 to control the
disk and I have daisy chained with the SC-4000 and plugged in my disk.
Unfortunately, nothing happens.
I am obviously missing something. Can anyone help?
Greg Tarsa
Tarsa Software Consulting
33 Seabee Street
Bedford, NH 03102
(603)668-8349 {decuac,decvax}!elijah!tarsa
------------------------------
Date: Fri, 8 Apr 88 02:03:18 EST
From: mcintyre@csv.rpi.edu (David McIntyre)
Subject: Problems using cgpixwindd color maps
I have had no success using the SunCore function define_color_indices to
alter the colormap of a cgpixwindd. With dbx I can see that the color map
size of the view surface does not change from 2.
I have had no problems with cg4dd's colormaps, but cgpixwindd doesn't seem
to want to cooperate. Any help would be appreciated.
Dave "mr question" McIntyre
home : 518-276-5842
office : 518-276-8633
mcintyre@cs.rpi.edu
------------------------------
Date: Thu, 7 Apr 88 15:29:58 CDT
From: Dave Capshaw <capshaw@austin.lockheed.com>
Subject: Getting mail between Suns and VAX/VMS DECNET?
What is the state of the art in exchanging mail between Suns and a DECNET
of VAX/VMS systems ? I have retrieved the dnamail file from Titan; have
things improved since then ?
What are other people doing for mail service when they add Suns to an
existing DECNET network ?
Thanks
Dave
------------------------------
Date: Fri, 8 Apr 88 12:40:52 +0200
From: Markus Pabst <unido!exunido.irb.informatik.uni-dortmund.de!pabst@uunet.uu.net>
Subject: Positioning icons on the screen?
I have problems with the position of an icon on the screen. How can i get
and set the icons position using SUN View programmers guide?
Markus
[[ Check the manual page for suntools(1). About 88% of the way through is
a section entitled "Generic Tool Arguments". It says that the argument
"-WP x y" will position the icon at (x, y). Another alternative is to
position it by hand once suntools is running and use toolplaces. That
will get you a command line for every tool which would start up the tool
with the same size and at the appropriate position (icnonic and open).
Look at the manual page for toolplaces(1), also. --wnl ]]
------------------------------
End of SUN-Spots Digest
***********************