Sun-Spots-Request@RICE.EDU (William LeFebvre) (10/06/87)
SUN-SPOTS DIGEST Tuesday, 6 October 1987 Volume 5 : Issue 48
Today's Topics:
Questions and answers about Sun software support
Multibus to VME Adapter Switch Setting Problem Solved
Re: Help needed with console device
Version 3.4 C-library routines (memory mgmt)
How to locate the NFS file system for a file (or directory)?
Accounting Software?
Through nfpipe
Another Fishy Icon
----------------------------------------------------------------------
Date: Tue, 29 Sep 87 09:31:06 PDT
From: William LeFebvre <phil@Rice.edu>
Subject: Questions and answers about Sun software support
Steve Damron at Sun Microsystems has been kind enough to participate on a
question and answer session about Sun's software support policies. I hope
that this exchange is beneficial to all Sun-Spots readers. When composing
the questions, my primary concern was what Sun would do to handle reports
of clear-cut bugs in their software. There are several similar issues
that were purposefully not addressed: helping a customer to locate a
problem (when the customer does not know who's software is at fault) and
the ethical question of charging money for bug fixes. Mr. Damron said
that he was willing to provide a "more philsophical reply later" if enough
questions arise regarding the latter issue.
I am not nearly clever enough to think of all the pertinent questions, so
Mr. Damron and I will provide an opportunity to let you, the Sun-Spots
readers, ask questions as well (see the last question in this message).
This lead-off message is large, but I think it is an important enough
issue to warrant the extra space.
So, here we go. I am asking the questions and Steve Damron is providing
the answers.
Q: Recently, Sun has been trying hard to make their customer service a
more positive force. One way in which service would be improved,
naturally, would be for users to report bugs in Sun's software
(whether it is a bug in the kernel itself, system software, or
applications programs). When a user finds a clear-cut bug, what
method should he use to report it to Sun?
A: Anyone who has e-mail access to Sun may send a bug report to
sun!sunbugs. Sun customers who have a Software Service contract which
includes phone support may phone 800 USA-4-SUN to report a software bug
directly to a Software Support Engineer.
When you report a bug, please remember that Sun needs a reliable way to
reproduce the bug in order find the delinquent code. A short piece of
code (a page or less) really helps us verify the problem. If it is an
intermittent problem, give the best description you can of the
circumstances which appear to cause the problem. Details like software
products in use, hardware products in use, frequency of problem, and
example code all help.
If you e-mail a bug report to sun!sunbugs, please include your name,
the name of the firm you work for, your address (both surface and
e-mail), and your phone number. That helps Sun find you if we need
further information about your report. Sun always sends an
acknowledgement that your bug report got through so, if you don't get
an acknowledgement in three or four days, you should re-transmit the
report.
Q: Would this method be any different for a user that is not covered by a
service contract?
A: I'll cover this in response to the next questions. Support customer or
not, you can always report a bug via sun!sunbugs.
Q: What type of response can the user expect to receive after the bug
report has been made (i.e.: immediate bug fix, a fix in the next
release, a work-around, only an acknowledgement)? How long should he
or she expect this response to take?
A: Sun has made some important improvements in its ability to track and
fix bugs, and in distributing bug fixes. Two significant improvements
are the Customer Distributed BugList and "Dot Dot" releases. The
Customer Distributed BugList appears every quarter in the Software
Technical Bulletin (STB). If you have a software support contract, Sun
sends you a copy of the STB every month. The BugList details all the
outstanding bugs in all of Sun's software products, and also gives an
identifying number for each bug. If you call Sun about a bug you see
in the STB, Sun's Service Engineers can give you the current status of
the bug if you give them the bug identifying number published in the
STB. Before you report a bug, check the STB to see if the problem has
already been reported. The STB will tell you if there is a known
workaround or patch available for the bug.
As of last month, Sun started shipping Dot Dot releases, so-called
because they have two dots in their appellation, like 3.4.1 (or, "3 dot
4 dot 1"). Sun plans to create a new Dot Dot release every eight
weeks. Every eight weeks, the bugs with the highest severity are
targeted for repair, and then they are incorporated in the next Dot Dot
release. If you're a support customer and you've reported a bug, Sun
automatically will send you a copy of the Dot Dot release when the bug
you've reported is fixed. Also, you can check the STB to find out what
bugs have been fixed in a Dot Dot release. If you have a software
support contract and you need a Dot Dot release, call 800 USA-4-SUN and
request the specific Dot Dot release you want from the service
dispatcher.
In summary, Sun plans to fix high severity bugs in Dot Dot releases.
Bugs of lower severity will be fixed in major and minor releases of the
software. Bugs with no workaround are given priority over bugs with
known workarounds.
Customers with support contracts can report bugs by phone or by
sun!sunbugs, and will receive information about bugs through the
Software Technical Bulletin. In addition, AnswerLine customers can
call for the current status of a bug, and Personal AnswerLine customers
can have updates about bug status mailed to them automatically every
two weeks. Support customers receive software upgrades automatically,
and can request Dot Dot releases by calling 800 USA-4-SUN.
Customers without contracts can report bugs via sun!sunbugs, and can
purchase upgrades and Dot Dot releases on a per-incident basis. At
this time, the way a non-contract customer can obtain information about
a specific bug (whether there is a workaround or what release it is
fixed in) is to call Sun on a time-and-materials basis. Most of the
services Sun provides to contract customers are available to
non-contract customers, but Sun charges for the services on a time-
and-materials basis.
Q: Would Sun object to that user (whether or not he/she is covered by a
service contract) seeking other aid in solving the problem, such as
sending a query to Sun-Spots?
A: Not at all. In fact, Sun is looking at some lower-cost alternatives
for on-line service. One service under active investigation is an
on-line bugs database.
Q: If Sun is willing to supply patches for certain bugs, how can other
Sun customers find out about these patches before they inadvertently
uncover the bugs?
A: As mentioned above, check the Software Technical Bulletin. If you do
not have a software support contract and you know the upgrade release
or Dot Dot release which contains the fix you need, you can order these
on a per-incident basis from your sales representative without calling
the AnswerCenter. Check with your sales representative for current
prices. If you need help from a Service Engineer, you can call the
U.S. AnswerCenter on a time-and-materials basis.
Q: Would Sun-Spots be a reasonable forum for such information?
A: Traditionally, Sun has not participated in Sun-Spots in order to allow
Sun-Spot readers to maintain a "big brother"-free forum. My concerns
with Sun participating in Sun-Spots are volume and accuracy of
information.
Moderator's note: I understand Sun's position on this. I was merely
thinking of using Sun-Spots to distribute solid facts about bugs and their
fixes. I don't see this as "big brother" interference, but merely getting
some important factual information out to a vast body of customers in a
timely fashion. Sun-Spots already handles bugs and bug fixes, but only
between Sun users. It is still a vague idea and may not even be a very
good one at that.
Q: Finally, I would like to extend the Q&A to encompass all the
Sun-Spots readers (because I'm sure that I can't think of all the
pertinent questions others might have). To do this, I would field
one round of questions from Sun-Spots readers about this topic,
screen them and forward them on to you so that you could answer them.
The questions and answers would then appear in the next digest.
Would you object to this?
A: That's fine. Also, if Sun-Spots readers have
questions/concerns/suggestions regarding any of Sun's software support
programs, they can contact me through uucp mail at sun!sdamron or by
phone at (408) 945 3813. If they have a problem with actual service
delivery, they should contact Marion Brown, Manager of the U.S.
AnswerCenter, at sun!robin!mbrown or (415) 691 2113. International
customers should contact their local subsidiary or distributor about
local programs and policies. Thanks for the opportunity to present Sun
Software Services in this forum.
Thank you, Mr. Damron, for taking the time to answer these questions.
Sun-Spots readers who want to ask Mr. Damron questions about customer
support can mail the question to Sun-Spots. Please make it clear that the
message is a question for Mr. Damron. I will filter the questions out and
pass them along to him. When I get a sufficient number of questions and
answers, I will send them out in a Sun-Spots digest.
------------------------------
Date: Wed, 30 Sep 87 17:50:46 EDT
From: cmcl2!rochester!srs!lee@hp-pcd.UUCP (Lee Hasiuk)
Subject: Multibus to VME Adapter Switch Setting Problem Solved
I have written a program (enclosed) which will hopefully make it much
easier for those of you faced with having to set up VME to Multibus
adapters. The program is called vme2mb and takes as arguments a
description of your device and outputs a complete list of switch settings.
Enjoy!
Lee Hasiuk
Speech Recognition Systems
Rochester, NY
{rutgers, ames, allegra}!rochester!srs!lee
[[ The source has been placed the archives as "sun-source/vme2mb.shar".
It can be retrieved via anonymous FTP from the host "titan.rice.edu" or
via the archive server. For more information about the archive server,
send a mail message containing the word "help" to the address
"archive-server@rice.edu". --wnl ]]
------------------------------
Date: Wed, 30 Sep 87 14:46:58 EDT
From: Skip Montanaro <steinmetz!montnaro@uunet.uu.net>
Subject: Re: Help needed with console device
In Sun-Spots Digest v5n45 Bob Clark writes:
>We don't want the workstation to be the console, so that anyone can crash
>the machine with a "L1 a".
This question has popped up in Sun-Spots a couple of times recently. The
concensus seems to be that you can't do what Bob is asking using the
software as delivered by Sun. But that's not what I'm writing about.
Wanting to make the graphics monitor publicly accessible and preventing
L1-A crashes is a noble goal. But beware! If you have are using a
terminal as the console device on a Sun, the BREAK key functions just like
L1-A. Just so you know.
[[ I believe that Mr. Clark wants to place the ASCII console (presumably
along with machine itself) in a separate and less accessible room. --wnl ]]
Skip (montanaro@ge-crd.arpa or uunet!steinmetz!sprite!montanaro)
------------------------------
Date: Wed, 30 Sep 87 16:28:30 EDT
From: sheffler@gateway.mitre.org
Subject: Version 3.4 C-library routines (memory mgmt)
We have version 3.4 and I seem to be having a problem with something in
the standard C library. To begin with, I have my own memory management
routines (bypassing malloc and family) because the CAD tool type things I
write need vast amounts of memory. What seems to be happening is this:
something in the standard library calls "f_prealloc" which seems to be
defined along with "valloc". I think it has something to do with opening
files. Anyway, since we don't have a source-code license (does anybody?)
I would appreciate it if someone could tell me what this routine thinks it
does. If I write my own, then the library one shouldn't be loaded. (BTW
- I will NOT use malloc)
Thanks in advance for any help.
Tom Sheffler
sheffler@gateway.mitre.org OR sheffler@faraday.ece.cmu.edu
[[ If you are using a stdio stream (a "FILE *") without explicitly setting
your own buffer (i.e.: with "setbuffer") then it will call some malloc
derivative on the first read/write operation. I believe it even does this
with the standard descriptors: stdin, stdout, and stderr. --wnl ]]
------------------------------
Date: 1 Oct 87 01:53:56 GMT
From: tony%linus@mitre-bedford.arpa (Tony E. Davis)
Subject: How to locate the NFS file system for a file (or directory)?
Question:
Given a file (or directory) how would one determine the NFS file
system from which it is mounted.
Example:
Say I want to find out which NFS file system mounts the home
directory for 'genericusername'. If genericusername's home
directory is /usr/oddusers/ourgroup/genericusername and the local
machine mounts /usr, /usr/oddusers, and /usr/oddusers/ourgroup
from different places (perhaps even different NFS servers, or
different names: for example, /usr might be mounted from
/usr.private), what is the appropriate way to determine that
/usr/oddusers/ourgroup/genericusername gets mounted with
/usr/oddusers/ourgroup.
The Problem:
I'm using Sun's remote execution protocol (rex) to run processes
remotely. The rex protocol takes arguments which allow one to
specify the directory that will become the current working
directory for the remote process, but one specifies that directory
via two arguments: the NFS file system and the directory within
that file system. With the two arguments, the rex protocol can
run the remote process in the requested working directory even if
that directory is not normally mounted on the remote machine. It
first ensures that the specified NFS file system is mounted (if it
isn't mounted, rex will mount it for the duration of the remote
process). Then it changes to the desired directory within that
file system.
The remote processes I'm running are started from a program on the
local machine (rather than from the command line), and I want the
remote process to have the same current working directory as the
local program. So, to give rex the appropriate arguments, I need
to be able to find the NFS file system from which the current
working directory of the local program is mounted.
Details:
Sun 3/110 running SunOS 3.2
I scanned the backlog of news articles for similar questions and found none.
Nonetheless, my apologies if this has been answered already.
Thanks in advance,
Tony Davis
The MITRE Corporation (617) 271-2146
MS A455 tony@linus.b.mitre.org
Burlington Road linus!tony
Bedford, MA 01730 tony%linus@mitre-bedford.ARPA
U.S.A.
------------------------------
Date: Wed, 30 Sep 87 11:13:10 +0100
From: mcvax!olsen!lance@uunet.uu.net
Subject: Accounting Software?
We'd like to move our business accounting off of PCs to Suns, but are
having trouble finding any accounting software. Can anyone offer me
pointers? Surely this can't be an original request. Does Sun do their
accounting on Suns?
Lance Berc
olsen!lance@uunet.uu.net
------------------------------
Date: 27 Sep 87 02:09:00 GMT
From: sundc!radigan%smu@seismo.css.gov
Subject: Through nfpipe
The following program uses a null modem between 2 rs232 ports on a Sun 3.
All I want to do is send charaters at a time but this does not work. The
second write read will show that the second char written is in wbuff[1]
rather than wbuff[0]. I am in raw mode and there is no buffering ? If I
open and close fd1 and fd2 in between all is OK.
FOR 64 dollars .. do you see anything wrong here?
P.S.
I have several other versions that instantly crash a sun 3 ...
its fun to watch for the whole family.
#include "/usr/include/sys/file.h"
#include "/usr/include/sys/ioctl.h"
#include <stdio.h>
struct sgttyb my_parms1, tmp_parms1, my_parms2, tmp_parms2;
void set_raw(fd)
{
ioctl(fd,TIOCGETP, &my_parms1);
my_parms1.sg_flags |= RAW;
my_parms1.sg_flags |= LITOUT;
my_parms1.sg_flags |= FLUSHO;
my_parms1.sg_flags |= ~ECHO;
ioctl(fd,TIOCSETP, &my_parms1);
}
main()
{
int f = O_RDWR ,m= 0777;
unsigned char buff[20];
char *n1 = "/dev/ttya" ,*n2 = "/dev/ttyb";
char c;
int fd1,fd2,i;
extern int errno;
char wbuff[128];
int cc;
if((fd1 = open(n1,f,m)) == -1){
return;
}
else{
set_raw(fd1);
}
if( (fd2 = open(n2,f,m)) == -1){
return;
}
else{
set_raw(fd2);
}
buff[0] = 0xFF;
if ( write(fd1,buff,1 ) == 0){
return;
}
if( (cc = read(fd2,buff,1)) == 0){
return;
}
printf("\n read 1 --->%x<<< \n", buff[0]);
printf(" %d\n",ioctl(fd1,TIOCFLUSH,0));
wbuff[0] = 7;
if ( write(fd2,wbuff,1 ) == 0){
return;
}
if( (cc = read(fd1,wbuff,1)) == 0){
return;
}
printf("\n read 2--------->%x %x %x %x<----\n",wbuff[0],wbuff[1],wbuff[2],wbuff[3]);
exit(0);
}
------------------------------
Date: Mon, 28 Sep 87 20:27:22 EDT
From: Steve Simmons <umix!itivax!lokkur!scs@rutgers.edu>
Subject: Another Fishy Icon
After seeing the various icons offered around, my favorite remains
one done by Doug Scobel at Applicon. Great for fans of fishing,
and it can of course be used to hid other activities....
/* Format_version=1, Width=64, Height=64, Depth=1, Valid_bits_per_item=16
*/
0xFFFF,0xFFFF,0xFFFF,0xFFFF,0x8000,0xB000,0x1F57,0xE001,
0x8000,0x0500,0x0000,0x0001,0x8000,0x0040,0x0000,0x0001,
0x8000,0x0000,0x0014,0x28D1,0x8000,0x0000,0x0DE1,0x4201,
0x8000,0x0000,0x3000,0x8201,0x8000,0x0000,0x0000,0x8201,
0x8000,0x0000,0x0000,0x0001,0x8006,0x0000,0x01C0,0x0001,
0x8009,0x0000,0x0700,0x0001,0x8029,0x0000,0x0500,0x0001,
0x8059,0x0000,0x0000,0x0001,0x804A,0x0000,0x0000,0x0001,
0x802F,0x8000,0x0000,0x0101,0x801F,0x81C0,0x0000,0x03C3,
0xA01C,0x013E,0x0000,0x73F7,0xFB00,0x010D,0xE000,0xFBFF,
0xFFF3,0x01A7,0x7E01,0xFFFF,0xFFFF,0x8189,0xBF81,0xFFFF,
0xFFFF,0xFF92,0xAFFF,0xFFFF,0x8000,0x0182,0x3AF8,0x0001,
0x8000,0x01C3,0xC7BC,0x0001,0x8000,0x0146,0xC37E,0x0001,
0x8000,0x0147,0xF74F,0xFE01,0x8000,0x014F,0xE8D7,0xC381,
0x8000,0x0159,0xA02B,0xFE81,0x8000,0x0169,0x3423,0xF0E1,
0x8000,0xFD29,0x950D,0xFFE1,0x8000,0x87A1,0x3566,0xBC39,
0x8007,0xFFA1,0x1582,0xFFF9,0x8004,0x78C3,0x1490,0x1EDD,
0x8003,0x0600,0x1CB3,0x4F7D,0x8000,0xC010,0x0CF8,0x27FD,
0x8000,0x3144,0x0DFF,0x55AD,0x8000,0x0C00,0x09FF,0x07FD,
0x8000,0x0310,0x1B3F,0xD6E9,0x8000,0x00C0,0x760F,0xE3F9,
0x8008,0x0037,0xEFF9,0xCFF1,0x8008,0x000F,0xFD3D,0xE4E1,
0x8004,0x0401,0x1495,0xF5E1,0x8004,0x0400,0x974C,0x71F1,
0x8004,0x0018,0x66A6,0x7171,0x8C00,0x0424,0x2556,0x1E71,
0xB01C,0x0422,0x25AC,0x1EB1,0x8A23,0x0420,0x24FC,0x0E71,
0x8020,0xC210,0x3600,0x0361,0x8190,0x2204,0x1F80,0x0761,
0x824C,0x1203,0x01F0,0x07E1,0x8123,0x0900,0x815C,0x03C1,
0x8000,0xC40C,0x81EB,0x03C1,0x81F8,0x2303,0x31E4,0x8381,
0x8E07,0x10E0,0x13B1,0xC701,0x8800,0xE010,0x06DF,0x7C01,
0x8C00,0x1808,0x0FAF,0xF001,0x8380,0x0018,0x0BFF,0xC3F1,
0x807F,0x0000,0x1EBF,0x1C09,0x8001,0xCF00,0x1FF8,0x6009,
0x8180,0x2808,0x1BE0,0x0031,0x8601,0xC070,0x1F00,0x0FC1,
0x881E,0x0308,0x0C0F,0x8001,0x8010,0x0808,0x0000,0x2041,
0x8000,0x5003,0x000C,0x0E29,0xFFFF,0xFFFF,0xFFFF,0xFFFF
Happy angling,
Steve Simmons
steve_simmons@um.cc.umich.edu
...ihnp4!itivax!lokkur!scs
[[ Available in the archives as "sun-icons/scs-fish.icon". -wnl ]]
------------------------------
End of SUN-Spots Digest
***********************