Sun-Spots-Request@RICE.EDU (William LeFebvre) (07/07/88)
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@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: Sat, 25 Jun 88 16:01:39 BST From: James Davenport <jhd%maths.bath.ac.uk@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@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@uk.ac.bath.maths ------------------------------ Date: Mon, 27 Jun 88 16:38 BST From: Piete Brooks <pb%computer-lab.cambridge.ac.uk@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@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@uk.ac.ed AI Applications Institute, RPA: R.Tobin%uk.ac.ed@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@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@Sun.COM Sun Microsystems earle@mahendo.JPL.NASA.GOV Los Angeles Consultant earle%mahendo@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@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@eecs.nwu.edu Uucp: {ihnp4, chinet, gargoyle}!nucsrl!naim ------------------------------ Date: 27 Jun 88 21:04:50 GMT From: fed!m1rcd00@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@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@cs.cmu.edu BITNET: snl%cs.cmu.edu@cmccvb UUCP: beats me. here's a couple that seem to work: west coast: ...!ucsdhub!snl@cs.cmu.edu east coast: ...!harvard!snl@cs.cmu.edu ------------------------------ Date: 27 Jun 88 16:27:56 GMT From: era@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@ncar.ucar.edu (128.117.64.4) * {ames,gatech,noao,...}!ncar!era ------------------------------ Date: 27 Jun 88 15:26 +0100 From: Nicolas Mayencourt <nicolas@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@cui.cernvax.mcvax.uucp nicolas@cui.unige.ch ------------------------------ End of SUN-Spots Digest ***********************