Sun-Spots Digest, v6n42

William LeFebvre Sun-Spots-Request at RICE.EDU
Sun Apr 3 05:29:03 AEST 1988


SUN-SPOTS DIGEST           Friday, 1 April 1988        Volume 6 : Issue 42

Today's Topics:
            Re: Problems rewinding a cartridge tape on a SUN-3
                        How to lock a sun under X
                              some f77 bugs
              Open systems & controllers; in defense of Sun
           Problem with terminal ports ttys[0123] on Sun 2/120
                   Need advice on SUN - VAX connection
                    Implementations of PHIGS and GKS?
                      Videotape digitizers on Suns?
                          Info about SunOS 4.0?

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 stored on "titan.rice.edu".  For volume X, issue Y,
"get sun-spots/vXnY".  They are also accessible through the archive
server:  mail the word "help" to "archive-server at rice.edu".

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

Date:    Mon, 21 Mar 88 10:25:39 PST
From:    vsi1!lmb at ut-sally.UUCP (Larry Blair)
Subject: Re: Problems rewinding a cartridge tape on a SUN-3
Reference: v6n30

The problem you are having is with the SCSI controller, not the the
software.  The problem, fixed with the new SCSI "3" controller, is that
the controller does not properly respond to a "disconnect".

Larry Blair
VICOM Systems Inc.     sun!pyramid----\
2520 Junction Ave.     uunet!ubvax----->!vsi1!lmb
San Jose, CA  95134    ucbvax!tolerant/
+1-408-432-8660

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

Date:    21 Mar 88 18:04:27 GMT
From:    avr at mtgzz.UUCP (XMRP50000[jcm]-a.v.reed)
Subject: How to lock a sun under X

Our company policy on protecting proprietary information requires that all
workstations and terminals be locked when left unattended, however
briefly.  Under suntools, this is readily accomplished with the "Lock
Screen" selection in the top-level menu, which calls /usr/bin/lockscreen.
Since there is as yet no comparable program under the X Window System, the
easiest way to be able to lock the screen under X is to run X 11 (made
with -DSUN_WINDOWS) over suntools.  I do this automatically by placing

    alias -x  x='XRUN=XRUN;export XRUN;/usr/bin/suntools -s $HOME/.xst;clear'

and the clause

    if [ `tty` = /dev/ttyp0 -a "$WINDOW_PARENT" -a "$XRUN" ]
	then
	sleep 16
	trap "" 1 15
	. $HOME/.xrun 2>/dev/null
	kill `ps -g|/bin/grep suntools|cut -c1-5`
	trap 1 15
	fi

in my ksh $ENV file. When I invoke "x" from the login shell, the alias
fires up suntools with the startup script $HOME/.xst, which contains the
one line

cmdtool    -Wp    0   0 -Ws 590  55 -WP    0   0 -Wl "<< CONSOLE >>" -WL console -C 

The ksh that automatically fires up in cmdtool runs into the "if" clause
above, and executes $HOME/.xrun, which contains my X startup (I don't use
xinit; and I won't post my opinion of xinit where it might be read by
minors :-) :

    # PATH=:/usr/mtgzfs1/avr/x11r2.core/usr/bin/X11$PATH
    TTY=`tty`
    DISPLAY=adam:0;export DISPLAY
    (sleep 2 ; xterm -fn 6x10 -b 2 -bw 3 =80x24+0-450 -C) 2>/dev/null &
    (sleep 3 ; xterm -fn 6x10 -b 2 -bw 3 =81x44-0-0) 2>/dev/null &
    (sleep 4 ; xterm -fn 6x10 -b 2 -bw 3 =81x44-0+0) 2>/dev/null &
    (sleep 5 ; xterm -fn 6x10 -b 2 -bw 3 =81x44+0-0) 2>/dev/null &
    (sleep 6 ; xterm -fn 6x10 -b 2 -bw 3 =81x89+573+0) 2>/dev/null &
    (sleep 7 ; xterm -fn 6x10 -b 2 -bw 3 =81x89-573+0) 2>/dev/null &
    (sleep 8 ; xclock -analog =83x83+0+0 -update 1) 2>xclock.out &
    (sleep 9 ; xsetroot -gray) 2>/dev/null &
    (sleep 12 ; uwm) 2>uwm.out &
    (sleep 14 ; xset -r m 4 2 s 600 ) 2>/dev/null &
    Xsun -mono -fp /usr/mtgzfs1/avr/x11r2.core/fonts/snf -a 4 -t 2 \
	    -co /usr/mtgzfs1/avr/x11r2.core/util/rgb/rgb -r \
	    >/$HOME/xsun.out 2>&1
    case $TTY in
	    /dev/ttyp* )
		    kbd_mode -e
		    ;;
	    * )
		    kbd_mode -a
		    setkeys reset
		    ;;
	esac
    clear

Once in x, I can lock the screen with the alias "xlock", also in my $ENV:

    alias -x xlock='xset s off;/usr/bin/lockscreen;xrefresh;xset s;kbd_mode -u'

And to quit, I just type "xkill":

    alias -x xkill='kill `ps -g|/bin/grep Xsun|cut -c1-5`'

Adam Reed
(mtgzz!avr)

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

Date:    Mon, 21 Mar 88 11:33 EST
From:    Rob Kutschke <KUTSCHKE at utorphys.bitnet>
Subject: some f77 bugs

I would like to contribute four examples which illustrate failings or
weaknesses in SUN's fortran and to answer a question about f77 raised by
Roberto Gomez in v6n27.

  The examples which follow concern:
  1) An optimization error.
  2) Library function rindex does not work
  3) Unusual (maybe even incorrect ?) behaviour of the character
     assignment statement when the same variable appears on both the
     left and right hand sides.
  4) Improper scope determination for dummy variables in a statement
     function definition.  This example also core dumps f77cvt, the
     preprocessor for VMS fortran.

These examples dervive from difficulties encountered while porting several
applications to our SUN 3/280 running SUN UNIX 4.2 Release 3.4; we use the
fortran compiler shipped with the system (spring 1987).  The problems also
occur when the examples are run on

SUN 3/180  running SUN UNIX 4.2 Release 3.4
           compiler: SUN Fortran with VMS Extensions
SUN 4/280  running SunOS Release Sys4-3.2
           compiler: Gamma version of the SUN 4 fortran compiler

The f77 sample program which Mr. Gomez sent to SUN-SPOTS v6n27 MUST have a
'double precision func' declaration in order to work correctly; this is
true on all machines.  To illustrate this, replace x=1.0 with
x=1.23456789123456789 and one will find that, under VMS fortran, s is
truncated to the single precision value of x.  Alternatively, try the
example, as is, on a VAX but use the /G_FLOAT qualifier on the compiler;
that will produce results similar to those experienced on the SUN.

When the declaration is missing, the compiler will take the output of
func, which is in fact a real*8 datum and run it through the
real*4-->real*8 converter, clearly not what was intended.  Because of
differences in the internal data representations between the two machines,
this conversion process has only subtle effects on the VAX but
catastrophic consequences on the SUN.  In a nutshell, on a VAX, the first
32 bits of a REAL*8 datum are identical to the 32 bits of the REAL*4 datum
of the same value; on a SUN, this is not true.  See the respective Fortran
manuals for details.  In the SUN fortran manual, in the section giving
hints about porting programs, there is a warning about this difference in
internal format.

Sincerely,
Rob Kutschke

University of Toronto           bitnet:   kutschke at utorphys
Department of Physics           internet: kutschke at oldkat.toronto.edu
Toronto, Ont
M5S 1A7


C Example 1:
C
C The code below demonstrates an error in the sun fortran optimizer.
C
C With the optimizer off, or with f77 -P, the output is correct:
C   1
C   2
C With the full optimizer on, f77 -O, the output is incorrect:
C   1
C   2
C   ...
C   10
C
      implicit integer*4 (a-z)
      integer*2 mts(20), erreg
      equivalence ( mts(3), erreg )

      do 100 i = 1, 10
        stat = getbuf ( mts )
        if ( stat  .ne. 1 ) stop
        if ( erreg .eq. 3 ) stop
        print *, i, stat
100   continue
      stop
      end

      integer*4 function getbuf ( mts )
c
c     Respond with an error in the third buffer
c
      integer*2 mts(*)
      data n / 0 /
      save n
      n    = n + 1
      mts(3) = n
      getbuf = 1
      return
      end
C
C Example 2)
c
c     The code below prints the value 0 when it should print 8.
c     rindex is a sun fortran77 library call.
c
      implicit integer*4 (a-z)
      k = rindex ( 'Harry Tuttle', 'uttle' )
      print *, k
      stop
      end
c
c Example 3
c
c I do not know what the ansi standard says about this example but
c Suns implementation is, in my experience, unqiue.
c
c On a vax running vms fortran or an ibm running vs fortran, the program
c below will print, as I expected,
c xxab
c but on the sun it prints,
c xxxx
c
      character*4 c1
      data c1 / 'abcd' /
      c1  = 'xx'//c1(1:2)
      print *, c1
      stop
      end
c
c Example 4)
c
c This file contains a bonus example. Not only is there a compiler
c error,  but it also crashes f77cvt, version 1.0.  It works correctly
c on an IBM running vs fortran or fortran hxe and on a vax running
c vms fortran.
c
c This example illustrates a compiler error which occurs when processing
c statement functions.  The compiler encounters 3 scalar, dummy variables,
c A,B and COS, in the statement function definition.  The scope of these
c definitions is supposed to be limited to the statement function definition;
c that is, A,B and COS can be unambiguously used elsewhere in the module,
c as if no statement function were present.  In the third line of the
c example below, however, the intrinsic function COS is not recognized
c because of the preceeding dummy variable COS.
c
c Certainly this example is sloppy for the human to read but is should
c be well defined for the machine.
c
c A CURSORY test indicates that A and B can be correctly used as either
c scalar or array variables in the remainder of the module.
c
c The correct output is c = 2.
c
      parameter ( piby4 = 3.1415927 / 4. )
      f(a,b,cos) = a + b*cos*cos
      d = cos(piby4)
      c = f(1.,2.,d)
      print *, c
      stop
      end

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

Date:    Mon, 21 Mar 88 17:20:08 PST
From:    mips!mash at ames.arc.nasa.gov (John Mashey)
Subject: Open systems & controllers; in defense of Sun

Tim Richardson's note <sunspots v6n31> expressed concern about Sun's
apparent unwillingness to let some vendors add code to bootproms, such
that desirable controllers could not be made available.  I've seen similar
complaints earlier, especially from folks wanting to buy the most
stripped-down systems available (i.e., without disks, tapes, or
controllers).

Without commenting on the specific case (i.e.,we use&like Interphase
controllers in our own systems), basic fairness says that even with the
best will in the world, and maximal open-systemness, anything that needs
to play with bootproms is more painful logistically than you'd think, and
I have sympathy for Sun's approach:

To support this, a systems company would need to:
	a) Release bootproms to controller vendors as linkable .o's.
	b) Release the development environment that you use to create
	your own bootproms (including compiler versions, if they make
	any difference, which sometimes happens.)
	c) Release documentation that describes any special attributes of
	your bootprom environment.
	d) Say something about diagnostics and how they fit.
	e) Whenever you change bootprom code for any reason, you have to
	do an extra layer of update (i.e., to other vendors).
	f) There are a zillion things that have to be checked, in terms of
	compatibility, and the original vendor (like Sun) has little control
	over this, even though the system that sits in a customer's location
	has that name on it.
	g) For systems that you ship, if people want to buy them stripped,
	you have to burn them in with disks/controllers to test them,
	and then take the disks/controllers back out, a pain for manufacturing.

Of course, there certainly can be benefits of doing this [we (MIPS) sell
source for all of our bootprom & standalone code, for example], but from
experience, it costs time and money and effort to support this mode of
working.

It's sometimes hard to justify, since what you are asking the systems
vendor to do is a) Do a lot of integration work whose main result is b) To
reduce the amount of money they make per system, in the hope that c)
They'll sell enough more systems to make up for a) and b). 

Anyway, this is not to say that it's a bad idea (it's not), but that it's
hard to blame a systems vendor for not doing very much of it.

How many systems vendors actually let others link things into bootprom code?

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

Date:    Mon, 21 Mar 88 18:05:21 EST
From:    utgpu!utas1!utas!russ at uunet.uu.net
Subject: Problem with terminal ports ttys[0123] on Sun 2/120

I have a SUN2/120 configured with the 2 standard serial ports (ttya and
ttyb) as well as four additional serial ports configured as ttys[0-3]. The
two cpu ports (tty[ab]) work fine either driving serial devices (a printer
in my case) or with a login enabled.  The other four ports however display
quite peculiar behaviour: Output from the port to the terminal will halt
at random intervals.  On occasion characters will be lost. The only way I
have discovered to restart the output is to issue first a control S then a
control Q.  I have tried many different baud rates, parity settings etc.
All seem to show the same problem behavior on ttys[0-3]. The kernel is
currently configured so that NO hardware carrier signal is needed. 

	# Zilog serial lines
	device		zs0 at virtual ? csr 0xeec800 flags 3 priority 3
	device		zs1 at virtual ? csr 0xeec000 flags 0x103 priority 3
	device		zs2 at mbmem ? csr 0x80800 flags 3 priority 3
	device		zs3 at mbmem ? csr 0x81000 flags 3 priority 3
	device		zs4 at mbmem ? csr 0x84800 flags 3 priority 3
	device		zs5 at mbmem ? csr 0x85000 flags 3 priority 3

Has anyone else out there experienced the same problem and if so what is
the solution?

Russell Sutherland		...utzoo!utas1!russ
Deans Office
Faculty of Arts and Science
University of Toronto

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

Date:    Tue, 22 Mar 88 12:39:15 -0100
From:    unido!fkihh!marcus at uunet.uu.net (Marcus Moehrmann)
Subject: Need advice on SUN - VAX connection

We connected a SUN 2 (/dev/ttya) via RS232-line with a VAX under VAX/VMS
and now the SUN appears to be a terminal to the VAX. Only pins 2, 3 and 7
of the line could have been wired. Now we want to use
Software-flow-control between the two machines, but it appears, that some
XOFF's (CTRL-S) aren't reaching the other machine and some data is lost.
The VAX-terminal is set correct (TTSYNC and HOSTSYNC).

Now my questions:

(1) It is possible to connect the two machines via 3-wired cable and
    use XON/XOFF ?

[[ Yes.  XON/XOFF is an "in-band" form of control.  --wnl ]]

(2) If it is, which is the appropriate setting for /dev/ttya on a
    basis of /usr/include/sys/ioctl.h ?

[[ TANDEM should be on.  Normally it is not.  DECCTQ should also probably
be on, although it normally is.  --wnl ]]

We want to use UUCP (uucico with F-protocol) with a VAX-relay.

Marcus Moehrmann	marcus%fkihh at unido.uucp

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

Date:    Fri, 18 Mar 88 18:02:08 EST
From:    "Tim G. Smith" (Mechanical) <tsmith at usna.mil>
Subject: Implementations of PHIGS and GKS?

Has anyone investigated PHIGS implementations for Sun gear? I am
particuliarly interested in PHIGS for the 3/50 and 3/60. Has anyone heard
of any PD versions of PHIGS, or GKS? 

I have used an early version of Sun GKS and found it adequate. I have
noticed that alot of vendors are now offering packages meeting various
levels of the GKS standard - does anyone have any experience with them?

I have found only one vendor so far for PHIGS- an outfit called Template
Graphics Software. Anyone out have experience with them? They seem to be a
reasonably large company- according to the sales glossies their version of
PHIGS (called Figaro) supports hardware ranging from Alliant to Tektronix.

	Tim Smith
E-Mail :<tsmith at usna.mil>
US mail:Tim Smith
	CADIG mailstop: 11G
	US Naval Academy
	Annapolis, MD 21402
Tel #  :(301)267-4413

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

Date:    Mon, 21 Mar 88 17:05 PST
From:    SHERWOOD at icdc.llnl.gov
Subject: Videotape digitizers on Suns?

Has anyone out there had any experience with videotape digitizers which
are based on digital disks?  I am interested in obtaining a subsystem to
plug into a Sun 3/160 which will digitize at least 30 seconds of videotape
in a single pass, writing it to local digital disk.  I would then read the
frames out of the subsystem one at a time and store them as binary disk
files on the Sun.

This is a relatively new technology, and I would be particularly
interested in hearing from anyone who actually has such a system, what
their likes and dislikes about their system are, and what pitfalls to
avoid.  Suggested vendors would also be appreciated.

Thank you.

Bob Sherwood
sherwood at icdc.llnl.gov

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

Date:    Mon, 21 Mar 88 18:19:06 EST
From:    trudel at topaz.rutgers.edu (Jonathan D.)
Subject: Info about SunOS 4.0?

Does anyone have any info regarding it? I'm looking for anything that Sun
has announced for 4.0 and beyond.  I'm under the impression that it's
supposed to allow diskless machines to run off other architectures and
such, but not much else.  What is Sun admitting to, and how stable is that
information with respect to AT&T's future plans for the merger of the
Berkeley and System V unices?

Jon

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

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



More information about the Comp.sys.sun mailing list