Sun-Spots Digest, v6n132

William LeFebvre Sun-Spots-Request at RICE.EDU
Fri Jul 8 02:39:40 AEST 1988


SUN-SPOTS DIGEST          Thursday, 7 July 1988       Volume 6 : Issue 132

Today's Topics:
                   Re: Problems with SUN-Link X.25 (2)
                            Re: rf2spec in Tex
   Sun customers with old Sun-2's attempting to bring up 4.0 take note
                          SunOS 4.1 Release date
                        15-pin ethernet connector
              Problems with SPARC Assembler Directives & KCL
               wanted: system evaluation/benchmarking tools
                         8mm video backup device?

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:    Sat, 25 Jun 88 16:01:39 BST
From:    James Davenport <jhd%maths.bath.ac.uk at nss.cs.ucl.ac.uk>
Subject: Re: Problems with SUN-Link X.25 (1)
Reference: v6n117

There are indeed many problems with this package - the major one is that
SUN (at least in the UK) is not serious about supporting it. Let me list
one major bug that rmohr did not mention - it loops (burning CPU) when
people disconnect. I agree about the log files and the echoing of
passwords and other "features".

I have long ago abandoned the use of the "pad" program - I use "spad",
which I obtained from pb at uk.ac.cam.cl. Until Sun provide a working
replacement, I would urge all people to do the same. 

He also has a server replacement - we don't use that, but a locally
written one, which keeps track of the sort of authentication data rmohr
wants (not exactly, but close).

What really worries me is the following - what is happening to the money
we pay SUN for these products? Given that they aren't available for 4.0 at
all, and aren't supported unter 3.x, one can only assume that the money is
being used to fund something else.

James Davenport
jhd at uk.ac.bath.maths

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

Date:    Mon, 27 Jun 88 16:38 BST
From:    Piete Brooks <pb%computer-lab.cambridge.ac.uk at nss.cs.ucl.ac.uk>
Subject: Re: Problems with SUN-Link X.25 (2)
Reference: v6n117

As I have been unable to obtain sources for pad or x.29 I have written
upwards compatible (I hope) versions.  Note that I know exactly how my
code works, but can only guess how SUN's works & what causes the bugs.

> 1. If running 'x.29' (host-server):
>    There is nothing available in the shell we desparately need:
>    a) Where are the X.25 User date (no shellvariable),
>    b) Where is the calling DTE (utmp, ok),
>    c) Where is the called DTE (need it for recognition of Sub-address).
* This info is available to the user.

>    The file x29authorization is very nice, but unsufficient:
>    It should allow to check userdate, calling and called DTE,
>    facilities (reverse charge!), and be able to set environment
>    variables for later use. Best thing would be a shell script
>    and/or c-program (user made) doing all this things.
* There are two SUN Kernel bugs which I have had to code round
* [ Well, actually there are a lot more, but two relevant ones here ]
* 1) you cannot determine the called DTE
* 2) you cannot determine whether you were called with reverse charge calls.
* My code gets round these by:
* 1) listening to specific subaddresses and then using the file descriptor to
*    work out what the called address was.
* 2) have two listeners with different auth files -- one for non-rev charge,
*    and the other for rev charge, again using different sub-address ranges.
*    The assumption is then that if the call is to one of the sub-addresses
*    which is meant to be rev-charge, then it WAS a reverse charge call.
*    [ i.e. only error is if a user calls a rev-charge subaddress but does
*      NOT reverse charge the call, the code still thinks it IS rev-charge
*    ]

* I have also greatly extended the auth file capabilties to allow things like
* relaying on to ethernet-only hosts running x29d and also an X.29 -> telnet
* relay for non-unix machines.

>    There seems to be no possibility to set the remote X.3/X.29
>    parameters. This is necessary fo instance to allow remote users
>    to use screen oriented programs (line 'news') and set their
>    parameters accordingly before starting the application and also
>    switch off the remote echo (2:0).
* My code changes parameters as the tty values are changed.
* Is that what you require ?
* If not, how can it be asked for ?

>    We are also missing the possibilty to get accounting information
>    on the running connection from within the running login-shell.
>    Especially when allowing reverse charge calls there should be a
>    way to get the required information (packets, time of connect etc.).
* How would you like this to be done ?
* Using some existing IOCTL to the pty ?

>    The logfiles in /tmp are
>    a) at the wrong location there and
>    b) lacking sufficient information (user, uid, pid, etc.).
* Fixed in my code.

>    Passwords at login are echoed. Very bad.
* Ditto.

> 2. Running the x25manager
>    leaves a connection between the two 'networks' (here two suns)
>    running all the time ( 60 sec * 60 min * 24 hours * 30 days * $$$ +
>    pckt.cnt * $$$ = $^$ !!).
>    This is a costly and not very elegant solution.
* I use someone's code (called tund) which supports the RFC, but is a much
* more general a flexible package.
* It is a simple ip interface which passes the packets up to user space.
* One of the possible clients (the relevant one in this case) accepts the IP
* packets, checks that the X.25 link is up (opening it if it isn't) and then
* sends it over X.25.
* If a link has been quiet for a certain time, it closes the VC.
* Note that it can be set up so that either/both ends are master/slave/both.
* Note also that it is NOT a good idea to run routed over these links ...

>    The documentation of the X25 package concerning internetwork
>    routing via X.25 is wrong.
* Can't comment as I don't know how ...

> 3. pad
>    using ^P<CR> does not always result in the expected prompt. There
>    is also a 'rset' command missing to send Q-Bit data to the remote
>    Host/computer/pc/pad.
> 
>    Accounting information missing.
* My alternative version (called spad) which can be used on any machine on the
* ethernet, gatewaying through a machine with X.25 comms [ e.g. a SUN running
* Sunlink ] has neither of the above problems.

> 4. Host setting parameters of callers
>    When called by a user via X.25 the SUN Link X.25 package sets
>    the parameters of the caller to a strange 3:54. This is very
>    unusual and some commercial PAD's just stop working after
>    connecting to a sun.
* Again, this is not a problem.

> 5. Strange behavior when calling from a sun:
>    If you use the command 'pad <host>' you get connected
>    immediately, but the remote host gets some characters
>    first. This unwanted transmission is very annoying.
* Likewise.

[[ Well...  How can we get a copy?  --wnl ]]

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

Date:    Mon, 27 Jun 88 14:55:24 BST
From:    Richard Tobin <richard%aiai.edinburgh.ac.uk at nss.cs.ucl.ac.uk>
Subject: Re: rf2spec in Tex

> I haven't had any problems including rasterfiles in LaTeX documents using
> rf2spec, but haven't yet sucessfully included one in a TeX document.  

Well, I never use plain tex, but I tried inserting a rasterfile into the
"Mr. Drofnats" story from the texbook.  It seemed to work ok (you'll need
to use \vskip instead of \vspace, of course).  What happened when you
tried?  Did tex give you an error, or dvi2ps, or did it just not print
out?

-- Richard

Richard Tobin,                 JANET: R.Tobin at uk.ac.ed             
AI Applications Institute,     RPA:  R.Tobin%uk.ac.ed at nss.cs.ucl.ac.uk
Edinburgh University.          UUCP:  ...!ukc!ed.ac.uk!R.Tobin

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

Date:    Mon, 27 Jun 88 18:35:00 PDT
From:    Greg Earle <earle at mahendo.jpl.nasa.gov>
Subject: Sun customers with old Sun-2's attempting to bring up 4.0 take note

If any Sun-Spots readers have very old Sun-2/120 or Sun-2/170 models,
please take note before attempting to install SunOS 4.0:

If your CPU board part number is 501-1007, the jumper J701 *must* be
installed in order to bring up Memory UNIX and/or minifs UNIX and
subsequently configure your system.  This goes against information given
in the `Hardware Installation Manual for the Sun-2/120' and also the
`Hardware Installation Manual for the Sun-2/170', but must be done
nonetheless.

Please note that Sun-2/120's and 170's with a later CPU board (501-1051)
do not have this problem, and need no adjustment to run 4.0.

What happens is that without this jumper, when the kernel goes to exec
init(8) and feed it the boot flags, it creates a stack space for the
process and then goes to stuff the boot flags in.  The very first byte
that gets moved causes a page fault.  Not having the jumper installed
causes bit 0x10 in the Bus Error register to be set (it has no meaning and
is unassigned), and the 4.0 code checking is stricter, thus any
combination other than the valid bit and the protect bit (0x80, 0x8) being
set causes a Bus Error panic.

Jumper J701 is CBRQ, for Common Bus Request Arbiter (in case you're
wondering or care).  This applies to PROM Rev. `N' boards on up, and the
official Sun bug number is 1011724.

Greg Earle		tsunami!valley!earle at Sun.COM
Sun Microsystems	earle at mahendo.JPL.NASA.GOV
Los Angeles Consultant	earle%mahendo at elroy.JPL.NASA.GOV
...!{cit-vax,ames}!elroy!{jplgodo!mahendo,valley}!earle

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

Date:    Fri, 24 Jun 88 19:07:38 CDT
From:    Naim Abdullah <naim at eecs.nwu.edu>
Subject: SunOS 4.1 Release date

On a visit to a local Sun office, I was told that SunOS 4.1 is due to be
released in November. This will have the merged NeWS/X11 server as part of
the release. SunView will be implemented on top of *X11* ("assuming no
performance problems" (I found that surprising too, but the sales creature
may have been wrong)).

Although it is good that Sun fixes bugs and releases the fixes so quickly,
I found it a bit amusing that they are already planning to ship 4.1 when
many customers are just receiving their copy of 4.0.

Regarding people urging Sun to ship BIND with their systems instead of
static lookups in /etc/hosts, I agree. However Sun may be reluctant
because BIND is far from nailed down and bug free. The BIND mailing list
still reports lots of problems with 4.8. Perhaps Sun is leery of
committing support to something that is still in a transient state ? But
they still should give people an easy way to use the resolver based
routines rather than static lookups. We should have a choice, even if they
aren't prepared to support BIND.

Naim Abdullah
Dept. of EECS,
Northwestern University

Internet: naim at eecs.nwu.edu
Uucp: {ihnp4, chinet, gargoyle}!nucsrl!naim

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

Date:    27 Jun 88 21:04:50 GMT
From:    fed!m1rcd00 at uunet.uu.net (Bob Drzyzgula)
Subject: 15-pin ethernet connector

Our opinions on this matter are along the lines of some of the cruder
thoughts of previous correspondents, so there is no need to go into that
kind of detail here. But could someone please tell me *why* did they
specify them in the first place, and *why* do they refuse to offer an
alternate standard?

What we did *do* about them was approach our systems integrator and ask
them to propose something more reliable. Together with their
subcontractor, Cabletron Systems, they proposed modified 15-pin connectors
that had RS-232-C style screw-in fasteners, and replaced the slide-catch
posts on the Sun ethernet port with screw posts.  I think that we had to
say many times over that we really didn't care that it would no longer be
an 802.3 standard network before they would do this. This move has had a
couple of drawbacks:

1. We now have only one source for AUI cables. (But we only used that one
anyway)

2. It becomes an issue every time we buy a new Sun server and every time
we have a CPU board replaced.

But you know what? The network *still works*, even though it isn't 802.3
standard any more! And you know what else? We really don't care about the
drawbacks, because we no longer have problems with the network seizing up
every time the cleaning crew sweeps behind a server.

Anyway, my vote goes for the Mac-style "Thumbscrew" connectors -- Sun is
already using them on disk & SCSI cables, and they're great.

Bob Drzyzgula
Federal Reserve Board, Washington, DC, 20551; uunet!fed!rcd

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

Date:    Sun, 26 Jun 88 05:01:51 -0400 (EDT)
From:    Sean Levy <snl at cs.cmu.edu>
Subject: Problems with SPARC Assembler Directives & KCL

Help. I'm trying to get KCL running on a Sun4. There is a stupid little
assembly-language hack for each kind of machine that intends to attach a
global name to a 2k table 1k into the data segment.  The file for the Sun3
looks like:

        .data
        .even
        . = . + 1024
        .globl _character_table
_character_table:
        .space 1024

I've removed .even and changed .space to .byte, but am stumped on how to
hack the '. = . + 1024' bit. The manuals that came with our Sun4 included
a SPARC Architecture manual, but it only documents the "Suggested Assembly
Language Syntax," which does not cover assembler directives. Does anyone
out there 1) know what to do for this particular case, 2) have a pointer
to a more general document for the damned SPARC assembler, or 3) have a
version of char_table.s for KCL that works on SPARC? (The assembler
complains about any hint of using '.' in this style... why did the Kyoto
people feel this perverse need to define a table in assembler?)

Thanks in advance,

Sean Levy
Engineering Design Research Center, CMU
Internet: snl at cs.cmu.edu
BITNET: snl%cs.cmu.edu at cmccvb
UUCP: beats me. here's a couple that seem to work:
      west coast: ...!ucsdhub!snl at cs.cmu.edu
      east coast: ...!harvard!snl at cs.cmu.edu

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

Date:    27 Jun 88 16:27:56 GMT
From:    era at scdpyr.ucar.edu (Ed Arnold)
Subject: wanted: system evaluation/benchmarking tools

We are preparing to issue an RFP for a mid-range ($250K) unix system.  I
would be interested in hearing from others who have evaluated systems in
this class, esp. what tools you bought/built/filched/etc. to do your
evaluation.  [I suppose this has been discussed before, so if you happen
to know in which group(s), I would appreciate a pointer with which to flog
the archives.]

We're interested both in cpu-i/o-network benchmarking, and in a test suite
which can give some measure of a system's functional conformance to "pure"
4.3 and/or pure S/V.  Since we don't have a S/V source license, we have to
look outside of AT&T for SVID conformance info.

Please reply directly to me via mail.  Results will be returned by mail to
correspondents.  If I receive a significant number of responses, I will
summarize to these groups.

Thanks for your assistance -

Ed Arnold * NCAR (Nat'l Center for Atmospheric Research) * Mesa Lab
PO Box 3000 * Boulder, CO  80307-3000 * 303-497-1253
era at ncar.ucar.edu (128.117.64.4) * {ames,gatech,noao,...}!ncar!era

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

Date:    27 Jun 88 15:26 +0100
From:    Nicolas Mayencourt <nicolas at cui.unige.ch>
Subject: 8mm video backup device?

We are planning to purchase a 8mm video unit for ours backups (~4GB).  Has
anyone experimented such devices? We would like some advice on the
fiability of such tapes.

Nicolas MAYENCOURT
Centre Universitaire d'informatique
1207 GENEVE
nicolas at cui.cernvax.mcvax.uucp
nicolas at cui.unige.ch

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

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



More information about the Comp.sys.sun mailing list