[comp.sys.sun] Sun-Spots Digest, v6n178

Sun-Spots-Request@RICE.EDU (William LeFebvre) (08/15/88)

SUN-SPOTS DIGEST          Friday, 12 August 1988      Volume 6 : Issue 178

Today's Topics:
                Re: vt100 session messes up Sun screen (2)
                     Re: LWP context switch for Sun/4
                Re: login problem when NFS server crashes
                    Re: Windows driver for 386i...YES!
                         Re: hardware gripe list
                     Custom memory systems 380DT disk
                            Discs for SUN-3/60
                               GNU and Mach
                           troff to postscript
          Modem signals on tty-lines, ALM-2, and DECserver 200MC
                         SunLink/ibmftp problems
                              tcsh and ^Cs?
                               window_dump?
                              Screen dumper?
                    third party hardware maintenance?
                              Kic and MAGIC?

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, 5 Aug 88 20:00:22 PDT
From:    carl@csli.stanford.edu (Carl Schaefer)
Subject: Re: vt100 session messes up Sun screen (1)
Reference: v6n166

>From:    cnrdean2@violet.berkeley.edu
>
>...If an application requires a terminal type of vt100, we find
>the workstation will not scroll properly for subsequent non-vt100
>applications...

[[ Note:  applications that do not reset the scrolling region upon exiting
are ill-behaved.  --wnl ]]

>`reset' or `clear' will not clear this up: the only solution we find that
>works is to reboot....

You need to send ESC[1r the tty to reset scrolling to one line at a time.
Rebooting could be considered overkill.  :-)

Carl

------------------------------

Date:    Fri, 5 Aug 88 14:59:16 EDT
From:    John Delsignore <jdelsign@bfly-vax.bbn.com>
Subject: Re: vt100 session messes up Sun screen (2)

Vt100 escape sequences put the Sun console into a funny scrolling mode.
If you type:

	% echo '<ESC>[1r'

that fixes it.  This escape sequence specifies how many lines to jump when
the cursor attempts to go off the bottom of the screen.  The `1' in the
above sequence causes it to be one line, which is the scrolling mode most
people prefer.

Cheers, John D.

------------------------------

Date:    Fri, 5 Aug 88 17:16:10 PDT
From:    daw@sun.com (Doug Ward)
Subject: Re: LWP context switch for Sun/4

>Anyhow, it works this way:  To start a lightweight process, you do a
>setjmp and then call the process's procedure.  To suspend the active
>process, you copy the stack, do a setjmp to be used to restart the
>process, then longjmp back to the scheduler.  To restart the process,
>alloca enough memory to restore the process's stack, then longjmp to the
>process's setjmp.  It's this last step that will not work on all machines.
>Some systems insist that the longjmp go back toward the base of the stack.
>If you try to longjmp the other way, they'll shreek, "longjmp botch," at
>you and crash.  How rude.


As it turns out, things get a little strange with SPARC processors.
Because of the register windows, a lot of the "stack" ends up living in
the register windows.  Space is allocated in the stack frame for each
routine to save the register values in case of a window register overflow.

ta 3 (software trap 3) will invoke some kernel code which will flush the
user process's register windows to it's stack, and leave things in such a
state that restores will cause window underflows, which will read the
register window back in out of the stack frame.

You should use this trap before you save the stack, and probably before
the setjmp's and longjmps.  I'm a little confused by the scheme outlined
above, so there may be other glitches to worry about.  In particular, if A
calls B, then B's frame pointer is the same register as A's stack pointer.
I'm not sure exactly what will happen with that arrangement as you do the
switch.

If the above made absolutely no sense to you, look at the explanation of
register windows in the SPARC Architecture Manual, P/N 800-1399  (I never
put in all that rev. and date stuff, cause they change much more often
than the part number).  It can be ordered through your Sales office and
costs something like $20.00.

The other point of interest is that Sun has a light-weight process library
in 4.0, so you may not have to do your own.

	-Doug Ward
	daw@sun.com

------------------------------

Date:    Thu, 4 Aug 88 20:16:53 EDT
From:    mstan!dff@uunet.uu.net (Daniel F. Fisher)
Subject: Re: login problem when NFS server crashes
Reference: v6n162

Godfrey Lee writes:

> Thanks for the explanation, I was wondering about that myself. But, isn't
> it easier if one just puts the nfs mounts under a separate subdirectory
> under the / directory? e.g. /n/xxxx. I know it is not as nice, and I must
> admit that I would probably just live with the problem unless it becomes
> unbearable.

William LeFebvre replies:

> Yes, that is easier from an administrative position, but a little
> harder from a user's standpoint.  As a user, I like having all the
> servers' main partitions available at the root (until one of them goes
> down, anyway).  --wnl

Here's what I have to say:

In our facility, we have solved both of these problems.

The root partition of every host has a directory for each NFS server.  The
mount points for each file system exported by a given server reside in the
host's directory for that server.  For example, our server s1 has three
exported file systems: u1, u2 and u3.  The mount points for these are
/s1/u1, /s1/u2 and /s1/u3, respectively.  Barring stupidity (see below)
this is sufficient to prevent this kind of pwd hang.  If I'm in /s1/u2/foo
pwd will not stat any file systems mounted from, say, s2, because these
are mounted at /s2/u1, /s2/u2, etc.  It will only stat the /s2 directory,
which is safe to do, since it is on the root file system.  So if s2 is
down, my pwd won't hang waiting for it.  In general, the only NFS mount
points stat'ed during a pwd, besides / and /usr, are those exported by the
server that also exported the current directory.  Note that root and usr
are exported by the client's boot server so if it's not available, a pwd
hang is the least of your problems.

I should say that our solution to the pwd hang problem was inadvertent.  I
know that this because, stupidly, we do have one network file system
mounted directly on the root and sure enough, whenever its server is down
(which as been a lot recently), pwd hangs.  So we just got lucky on this
one, but at least we now understand the problem.

The problem of making life easy for users (the scheme outlined above is
even harder on users than mounting in /n) is solved by having a /u
("universal") directory of symbolic links to directories in the NFS
mounted file systems.  What we do is to place a home directory on for
example /s1/u2.  Then we create a symlink from /u to the home directory
("ln -s /s1/u2/dff /u/dff").  rdist is used to keep the /u directory the
same on all clients.  In fact, where we have converted to SunOS 4.0, we
only distribute the /u directory to servers.  Then each client mounts its
boot server's copy on the /u directory.  In this way, /u/xxxx provides a
logical of a file.  The physical location being of the form /s?/u?/xxxx.
We have found that this is very convenient for users.  I don't even have
to know where my home directory is today.  We have also avoided a
proliferation of hard coded physical locations.  Moving a directory, such
as our production source tree from one machine to another, we don't have
to hunt for references to its physical location, since all references
refer to "/u/src".

Dan

------------------------------

Date:    Fri, 5 Aug 88 14:26:58 EDT
From:    gfr%wolfgang@gateway.mitre.org (Glenn Roberts)
Subject: Re: Windows driver for 386i...YES!
Reference: V6n161

I had asked:

> "Does anyone know if Sun (or someone else) has plans to write a Microsoft
> Windows driver for the 386i's 1152x900 color screen?"

The answer is yes!  Sun will release this in "SunOS 4.0.1" for the 386i.
Should be generally availble in a month or two.

(Thanks to the many people at Sun who called me to report this).

- Glenn Roberts, MITRE Corp., McLean VA (703) 883-6820
  gfr%wolfgang@gateway.mitre.org

------------------------------

Date:    Fri, 05 Aug 88 13:16:56 -0400
From:    (Jeffrey A. Edelheit) <edelheit%smiley.mitre.org@gateway.mitre.org>
Subject: Re: hardware gripe list

I personally think that gripes shouldn't be segregated into
hardware/software.  Further, I'd rather just see it in sun-spots rather
than a separate list.

Regards,

Jeff Edelheit		(edelheit@gateway.mitre.org)
The MITRE Corporation	7525 Colshire Drive
McLean, VA   22102		(703) 883-7586

------------------------------

Date:    Thu, 4 Aug 88 17:40:58 EDT
From:    Mark Feblowitz <mdf0%shemesh@gte.com>
Subject: Custom memory systems 380DT disk

Watch out for the Custom memory systems 380DT disk. We had one fail twice
within 3 months (within the warranty period), had it repaired once,
replaced once, and the new one also failed within three months, this time,
with at least 8 weeks required for repairs.  The people there are quite
friendly and helpful, but they maintain _no inventory_, which means that
turnaround time for repairs is unreasonable. Our Sun 3/60 was down for _3_
of the 6 months that we relied on the disk drive.  Further, when we
received a "new" disk in another portion of our company, it was the _same_
disk as the first one that we returned (after two failures) (same cabinet
and serial number, and identical disk defects, with the exception that
there were twice as many defects!).

Just the facts...
--
Mark Feblowitz   GTE Laboratories, Inc., 40 Sylvan Rd.  Waltham, MA 02254
						(617) 466-2947
CSNET:  mfeblowitz@GTE.com
UUCP:   mfeblowitz@bunny.UUCP       old UUCP:  harvard!bunny!mfeblowitz


------------------------------

Date:    Thu, 4 Aug 88 16:13:04 BST
From:    Paul Hudson <mcvax!moncam!paul@uunet.uu.net>
Subject: Discs for SUN-3/60

We use WREN-IVs which work fine.

Some abbreviated info.  Sintrom charged us about about 1180 + VAT.
Unpackaged, added a power supply. Used standard 50way SCSI cables. Have
used 3.4, now using 4.0.  Formatting under 4.0 works, formatting with 3.4
requires pretending you have and Emulex controller (becase the Adaptec
controller which SUN use is brain-damaged). Driver worked fine, although
we have had the occasional error from somewhere, which hasn't caused any
problems.  Anything else?

If you have two or more, remember to take the terminators off all but the
last one (important). We didn't believe the tracks/cylinder stuff that
came with the drive, so extrapolated from the WREN-III, which we build
into things.

Any more help, please ask.

(Quantity discounts start at 5+, so ask your friends :-)).

Paul Hudson 

Snail mail: Monotype ADG	Email:	...!ukc!acorn!moncam!paul
	    Science Park,		paul@moncam.co.uk
	    Milton Road,
	    Cambridge,
	    CB4 4FQ

------------------------------

Date:    Thu, 4 Aug 88 16:07:57 BST
From:    Paul Hudson <mcvax!moncam!paul@uunet.uu.net>
Subject: GNU and Mach

The last GNUsletter we got says they hope to use Mach. (and the bits of
BSD that are becoming free).

Send them a donation.
Paul Hudson 

Snail mail: Monotype ADG	Email:	...!ukc!acorn!moncam!paul
	    Science Park,		paul@moncam.co.uk
	    Milton Road,
	    Cambridge,
	    CB4 4FQ

------------------------------

Date:    Thu, 4 Aug 88 16:10:35 BST
From:    Paul Hudson <mcvax!moncam!paul@uunet.uu.net>
Subject: troff to postscript

I don't know of a PD filter, but a quick and dirty (And slow) one
shouldn't take too long. If there's any demand, I'll knock one up.

Paul Hudson 

Snail mail: Monotype ADG	Email:	...!ukc!acorn!moncam!paul
	    Science Park,		paul@moncam.co.uk
	    Milton Road,
	    Cambridge,
	    CB4 4FQ

------------------------------

Date:    Fri, 5 Aug 88 07:00:36 CDT
From:    Stephan Wasserroth <wasserroth@fokus.berlin.gmd.dbp.de>
Subject: Modem signals on tty-lines, ALM-2, and DECserver 200MC

Hello, World!

My last message regarding the configuration of our ALM-2 has one error:
The ALM-2 is configured with a flags word of 0x10000 (use hardware
carrier), NOT with 0x0ffff!

Sorry for causing confusion!

DFN-EAN:       <wasserroth@fokus.berlin.gmd.dbp.de>
ARPA:          <wasserroth%fokus.berlin.gmd.dbp.de@relay.cs.net>

                     GMD-FOKUS
Stephan Wasserroth   Hardenbergplatz 2
System Manager for   D-1000 Berlin 12
VAXes and Sun-WS     Fed. Rep. of Germany

------------------------------

Date:    Fri, 5 Aug 88 08:50:28 CDT
From:    texsun!edsr!neptune!jcn@sun.com (Jim Niemann)
Subject: SunLink/ibmftp problems

IND$FILE is a program product you must purchase from IBM.  Page 39 (1st
page of Chapter 4) in SunLink 3270 users guide:

"The host side of file transfer function is provided by either the IBM
program product 5664-281 (VM/CMS) and 5665-311 (TSO) or the program
offering PO 5798-DQH (CICS)."

One tip:  your mainframe mode table (MODTAB) must have a special bit on
that tells the mainframe your Sun is a 3270PC.

Jimmy Niemann
EDS

------------------------------

Date:    Thu, 4 Aug 88 23:19:42 EDT
From:    Peter Marshall <peter%hadrian.uwo.ca@cornellc.ccs.cornell.edu>
Subject: tcsh and ^Cs?

I would like to use tcsh as my default shell on out SunOS 3.5 systems here
but for some reason it will not tolerate ^Cs typed at it.  I have the same
code running without problem on an Ultrix v1.1 system.  ^Cs work ok until
you return from the first program run after invoking tcsh (like ls).  If
you type it at that point the shell just exits and the window folds up.
It seems to be someone not restoring the interrupt to its original state.
I.e.  after running a program ^C gets treated as if it were a ^D.

If anyone else is using tcsh and has fixed this problem, I would be very
interested in finding out about it.  Any suggestions are welcome.

BTW. tcsh is a set of patches to the 4.2/4.3 csh to give it command recall
using standard emacs commands (and a bunch of other features).  I think
that it was distributed in one of the USENET source groups a few months
ago.
--
Peter Marshall, Data Comm. Manager
CCS, U. of Western Ontario, London, Canada N6A 5B7
(519)661-2151x6032
peter.marshall@uwo.ca pm@uwovax (BITNET); peter@julian.uucp

------------------------------

Date:    Thu, 04 Aug 88 15:16:35 SET
From:    Danielle Heinzer <ESC1298@ESOC.BITNET>
Subject: window_dump?

Is there any program already existing to dump a specified window
(rasterfile format) by means of a command such :

     <WS ID>%"windowdump" <window identifier><Return>
     <WS ID>

     or by changing the window menu to : Close
                                         Move
                                         Resize
                                         Expose
                                         Hide
                                         Redisplay
                                         dump      <------
                                         quit
     ????

Danielle Heinzer
ECD/CS
European Space Operations Centre
Robert-Bosch-Str. 5
6100 Darmstadt
West-Germany
(49)-6151-886540
ESC1298%ESOC.BITNET@cunyvm.cuny.edu

[[ Don't know about that, but there is a program that dumps just a
selected region of the screen.  See the next message...  --wnl ]]

------------------------------

Date:    5 Aug 88 08:05:15 PDT (Friday)
From:    sk.LSBGEGPCAD@xerox.com
Subject: Screen dumper?

Is there a hack that will dump selected part of the screen in the sunview
environment ?. I know there is one in NeWS, but I need it in the SUn View.

Thanx
--sk

[[ Yes.  It is in the sun-spots archives under "sun-source" as
"dumpregion.c".  It is only 3215 bytes in length.  It can be retrieved via
anonymous FTP from the host "titan.rice.edu" or via the archive server
with the request "send sun-source dumpregion.c".  For more information
about the archive server, send a mail message containing the word "help"
to the address "archive-server@rice.edu".  --wnl ]]

------------------------------

Date:    Fri, 5 Aug 88 14:07:47 EDT
From:    Edward Keegan <keegan%yale-celed.UUCP@yale.arpa>
Subject: third party hardware maintenance?

Other than self-maintenance or depot service, are there any companies
(other than SUN of course) offering SUN maintenance service alternatives?

--ed

------------------------------

Date:    Fri, 5 Aug 88 17:43:40 CDT
From:    strong%stetsun@mcc.com (Michael Strong)
Subject: Kic and MAGIC?

Can you tell me what Kic and MAGIC are?

Thanks in advance.

Michael Strong
@ MCC VLSI CAD Program [512] 338-3642
P.O. Box 200195, Austin, TX 78720
3500 West Balcones Center Drive, Austin, Tx 78759
ARPA: strong@mcc.com
UUCP: {ihnp4,seismo,harvard,gatech,pyramid}!ut-sally!strong%mcc.com

------------------------------

End of SUN-Spots Digest
***********************