ray@seismo.css.gov@dsiramd.nz (12/12/86)
Path: dsiramd!ray
From: ray@dsiramd.nz (Ray Brownrigg)
Newsgroups: mod.computers.pyramid
Subject: S on Pyramid 98x?
Keywords: S, Pyramid 98x
Message-ID: <141@dsiramd.nz>
Date: 9 Dec 86 23:14:59 GMT
Reply-To: ray@dsiramd.UUCP (Ray Brownrigg)
Distribution: world
Organization: Applied Maths Division, DSIR, Wellington, New Zealand
Lines: 19
The Fisheries Research Division of the NZ Ministry of Agriculture and
Fisheries is intending to purchase the Bell Labs' S statistical system
to run on their Pyramid 98x system.
Does anyone out there have any experience of implementing S on such a
system, and/or are the hints provided with the S distribution
sufficient?
Please respond to me or to the FRD contact, who is Dave Esterman, to be found
at:
..!vuwcomp!nzfish!dbe
Thanks
Ray
--
Ray Brownrigg UUCP: {alberta,ubc-vision}!calgary!vuwcomp!dsiramd!ray
Applied Maths Div, DSIR ACSnet: ray@dsiramd.nz
(New Zealand Govt.) System: OLIVETTI/AT&T 3B2/400B+, System V R2.1
Wellington, New Zealand "UNX -rules -OK"andrew@seismo.css.gov@vuwcomp.UUCP (02/02/87)
Path: vuwcomp!andrew
From: andrew@vuwcomp.UUCP (Andrew Vignaux)
Newsgroups: mod.computers.pyramid
Subject: Problems with chgstack()
Keywords: chgstack
Message-ID: <12615@vuwcomp.UUCP>
Date: 2 Feb 87 04:33:58 GMT
Organization: Comp Sci, Victoria Univ., Wellington, New Zealand
Lines: 43
I am having problems getting chgstack() to work. I can set up a
context but when I try returning to a previous context I get a Bus
error. This seems to be because chgstack() is placing a strange value
in the "codeaddr" field of the context and the system call has nowhere
to go when it returns.
Example:
struct context *to_context, *from_context;
extern int my_routine ();
. . .
malloc space etc.
. . .
to_context -> codeaddr = my_routine;
. . .
ret = chgstack (to_context, from_context);
. . . (much later in my_routine())
ret = chgstack (from_context, to_context);
Bus error!
"my_routine" gets called but the "from_context->codeaddr" is set
to a value inside the stack "range" and nowhere near my program. We
are running OSx 3.1.
The manual entry does not give an example so I am probably passing
something wrong. I am also confused about the pointers "stktop",
"stkcfp" and "stkbottom" and what I should initialise them to when I
make a new context.
Could someone either:
(a) tell me (e-mail) what I am doing wrong,
(b) send me an example program,
(c) tell me to give up and get back to my masters (:-)
Thanks,
Andrew
-------------------------------------------------------------
Rule Six: The winning team shall be the first team that wins.
UUCP: ...!{alberta,ubc-vision}!calgary!vuwcomp!andrew
ACSnet: andrew@vuwcomp.nzgenerous@seismo.css.gov@dgis.UUCP (02/23/87)
Path: dgis!generous
From: generous@dgis.UUCP (Curtis Generous)
Newsgroups: mod.computers.pyramid
Subject: Problem with printer spooler under OSx 3.1
Keywords: printer, spooler
Message-ID: <200@dgis.UUCP>
Date: 23 Feb 87 20:39:57 GMT
Organization: Defense Gateway Info. System, Alexandria, VA
Lines: 49
Has anyone had difficulties getting the accounting to work
with the line printer daemon under OSx 3.1? The printing function
works fine, but the accounting file never seems to grow. I have a 98x,
with an IOP based parallel printer, with all printing functions executing
under the UCB universe. Again, everything else with the printer seems to work.
Here are some files of interest:
/etc/printcap:
lpr|lp|lp0|Band Printer:\
:lp=/dev/lp:\
:of=/usr/lib/lpf:\
:sd=/usr/spool/lp:\
:af=/usr/adm/lp.acct:\
:lf=/usr/adm/lp-errs:
Permissions on various relevant files:
-rw-rw-r-- 1 daemon daemon 0 Jan 11 1986 /usr/adm/lp-errs
-rw-rw-r-- 1 daemon daemon 0 Feb 19 17:31 /usr/adm/lp.acct
-rws--s--x 1 root daemon 79872 Jan 10 1986 /usr/lib/lpd*
-rwxr-xr-x 1 root sys 26624 Jan 10 1986 /etc/pac*
c-w--w---- 2 daemon daemon 48, 3 Feb 21 11:52 /dev/lp
-rwxr-xr-x 1 bin sys 18432 Jan 10 1986 /usr/lib/lpf*
Here is my kernel configuration (strings /vmunix)
| # makesys configuration for 128 user system
| users=128
| logins=64
| multiprocessor
| optimizer
| quotas
| nfs rpc
| gpsc x25if
| itp sxt
| iocload
| iopload iopdisk ioptape iopprint iopether
Any help/pointers/suggestions are welcomed.
-curtis-
--
Curtis C. Generous
Lawrence Livermore National Labs
ARPA: generous@lll-tis-b.ARPA
UUCP: {seismo,vrdxhq}!dgis!generousera@mimsy.umd.edu@seismo.UUCP (02/24/87)
Path: scdpyr!era
From: era@scdpyr.UUCP (Ed Arnold)
Newsgroups: mod.computers.pyramid
Subject: wanted: "best" tape drive for 90x
Keywords: pyramid 90x tape fujitsu kennedy
Message-ID: <40@scdpyr.UUCP>
Date: 23 Feb 87 23:57:53 GMT
Distribution: na
Organization: Natl Ctr Atmospheric Research, Boulder, CO
Lines: 31
I'm seeking info from anyone who has attached either a Fuji M2444 or
Kennedy 9401 to a 90x (thru an IOC, of course). Since the 90x (OSx 3.0)
I'm working on isn't source licensed, I can't look at the tape driver.
I'm trying to evaluate a loaner 2444. It's set up in Cipher F880
compatible mode (CE manual, page 6-35) and with the buffer xsfer rate
at 250 kbyte/sec (CE manual, page 4-58). In this configuration, at
6250 density, the best transfer rate to tape (single-user mode, 10240-byte
blocks) is about 104 kbyte/sec, which doesn't seem very good. (Setting
higher buffer transfer rates causes tapeintr() to croak.)
My questions are:
(1) Is there any combination of Fuji parameters which will give us a
better transfer rate on a 90x? In particular, if we should be
using the Fuji's CDC or PERTEC modes, what value of "ioctapetype"
in conf.c does this correspond to? (We're currently using "MT_UNKNOWN".
There is a "MT_FUJITSUM2444AC" type, but the sys admin manual doesn't
reveal whether that corresponds to CDC or PERTEC mode, and using that
value in Cipher mode doesn't work at all.)
(2) Is there anyone out there with a 90x/Kennedy 9401 who achieves a
significantly better transfer rate than 104 kbyte/sec? (If we can get
better throughput with a 9401, we would consider spending the extra
money.)
Thanks for your assistance ...
--
Ed Arnold * NCAR (Nat'l Center for Atmospheric Research)
PO Box 3000 * Boulder, CO 80307-3000 * 303-497-1253
era@ncar.csnet * era@scdsw1.{arpa,ucar.edu} * era@scdpyr.uucp *
era%scdsw1.arpa@wiscvm.bitnetgenerous@seismo.css.gov@dgis.UUCP (02/24/87)
Path: dgis!generous
From: generous@dgis.UUCP (Curtis Generous)
Newsgroups: mod.computers.pyramid
Subject: Problem with printer spooler accounting under OSx3.1
Keywords: spooler,accounting
Message-ID: <201@dgis.UUCP>
Date: 24 Feb 87 02:49:14 GMT
Organization: Defense Gateway Info. System, Alexandria, VA
Lines: 47
Has anyone had difficulties getting the accounting to work
with the line printer daemon under OSx 3.1? The printing function
works fine, but the accounting file never seems to grow. I have a 98x,
with an IOP based parallel printer, with all printing functions executing
under the UCB universe. Again, everything else with the printer seems to work.
Here are some files of interest:
/etc/printcap:
lpr|lp|lp0|Band Printer:\
:lp=/dev/lp:\
:of=/usr/lib/lpf:\
:sd=/usr/spool/lp:\
:af=/usr/adm/lp.acct:\
:lf=/usr/adm/lp-errs:
Permissions on various relevant files:
-rw-rw-r-- 1 daemon daemon 0 Jan 11 1986 /usr/adm/lp-errs
-rw-rw-r-- 1 daemon daemon 0 Feb 19 17:31 /usr/adm/lp.acct
-rws--s--x 1 root daemon 79872 Jan 10 1986 /usr/lib/lpd*
-rwxr-xr-x 1 root sys 26624 Jan 10 1986 /etc/pac*
c-w--w---- 2 daemon daemon 48, 3 Feb 21 11:52 /dev/lp
-rwxr-xr-x 1 bin sys 18432 Jan 10 1986 /usr/lib/lpf*
Here is my kernel configuration (strings /vmunix)
| # makesys configuration for 128 user system
| users=128
| logins=64
| multiprocessor
| optimizer
| quotas
| nfs rpc
| gpsc x25if
| itp sxt
| iocload
| iopload iopdisk ioptape iopprint iopether
Any help/pointers/suggestions are welcomed.
-curtis-
--
Curtis C. Generous
Lawrence Livermore National Labs
ARPA: generous@lll-tis-b.ARPA
UUCP: {seismo,vrdxhq}!dgis!generoushedrick@topaz.rutgers.edu@rutgers.UUCP (02/25/87)
Path: topaz!hedrick
From: hedrick@topaz.RUTGERS.EDU (Charles Hedrick)
Newsgroups: mod.computers.pyramid
Subject: Re: S on Pyramids
Message-ID: <9603@topaz.RUTGERS.EDU>
Date: 25 Feb 87 11:00:46 GMT
References: <8702241332.AA16663@osiris>
Organization: Rutgers Univ., New Brunswick, N.J.
Lines: 205
Here are the instructions that we supply for bringing up S. It has
enabled several sites to do it.
From: hedrick@topaz.rutgers.edu (Charles Hedrick)
This document describes how to bring up ATT's S system on the Pyramid.
It was used with a copy of S from ATT labelled as the version of Jan
9, 1984. It was compiled under version 3.2.0 of Pyramid's Fortran
compiler, which was distributed with operating system release 3.1.
The following instructions are based on a mail message from someone at
Pyramid, with additional comments based on our experience:
Read "S Installation Procedures"
Read "Maintaining S"
Use the Bourne shell (/bin/sh) exclusively.
Use the UCB universe consistently throughout.
Use the 'att' version of /usr/bin/m4 by editing $C/makehead to
change M4 to /usr/.attbin/m4. (C is set in ENVIRONMENT -- don't
forget to set SHOME also).
OSx 3.0 F77 plus ratfor and efl. [We used a newer F77, which no doubt
explains why we needed some patches that the original installer didn't
need. They are shown below. --Rutgers]
Edit $I/u/mach.m t set the arithmetic constants for the 90x. Set them
the same as the 3B20 -- they both use IEEE floating point. [For your
convenience, mach.m is included at the end of this file. --Rutgers]
Due to funky arithmetic conversion, edit $A/infun.awk. Change
print "is(infnum+ii-1)=" nline
to
printf("is(infnum+ii-1)=%d\n",nline)
Ignore exit status of f77 and icomp by inserting a leading dash (-)
in the lines that invoke these programs in $C/makehead
Typically, /usr/S has been chosen as the S home directory (SHOME)
if space available.
Set OPSYS=Berkeley, SHELL=/bin/sh in $SHOME/ENVIRONMENT
Set MAXFILELEN=255 in $I/u/mach.m
Copy $M/big.list to $M/infun.list
Make the following changes to source under /src/fun. < is old > is new
hp2627/zpolyz.r:
43c43
< i = -ifix(col)
---
> i = -col
macro/argno.r:
20a21
> litral=0
optiter/optlp.r:
131c131
< sum = amax0(sum - q, 0.0)
---
> sum = amax1(sum - q, 0.0)
stare/Smakefile:
22c22,23
< $(F77) $(LDFLAGS) $(STRIP) -o dev.dummy $L/device.z dummy.o dinitz.o $L/defer.z $(GRZLIB)
---
> @echo defer_dum.z must be produced using emacs
> $(F77) $(LDFLAGS) $(STRIP) -o dev.dummy $L/device.z dummy.o dinitz.o defer_dum.z $(GRZLIB)
usa/usa.i
27c27
< coord=amin0(px/dx,py/dy) # inches per degree longitude
---
> coord=amin1(px/dx,py/dy) # inches per degree longitude
defer_dum.z is an altered version of $L/defer.z. The problem is that
there is some sloppy code, which when loaded will proceduce 1 multiply
defined symbol, amdiff. Unfortunately, the current version of the
Pyramid loader treats this as a fatal error, so you can't just ignore
it as the instructions say. The simplest solution is to produce an
altered version of defer.z (which is an object file) that has a dummy
symbol instead of the symbol amdiff. I did this by copying $L/defer.z
to the local directory (~s/src/fun/stare) as defer_dum.z, and then
editing it with Emacs. I simply searched for all occurences of amdiff
and replaced them with amdumm. Since this is an object file, you must
be very careful to change only those charcters, and to make the new
symbol the same length as the old one. I don't know any editor other
than Emacs that I would trust to edit object files. You could also
produce a local copy of the source used to produce defer.z, and edit it.
Note that the other changes are of two kinds:
- several cases where the original code passed the wrong type of
variable to a Fortran function, typically an integer to
a function that expected a real. The newest Pyramid compiler
detects those as errors.
- one uninitialized variable.
It is certainly possible that newer versions of the compiler, or further
testing, will turn up more problems of the same sort.
---
The file below is mach.m
---
divert(-1)
#Pick one of the following operating systems:
define(`OpSys',`Berkeley')
define(`F77_MAIN',`MAIN_')
#define(`OpSys',`BellSystem')
#define(`F77_MAIN',`MAIN__')
#Pick one of the following machine types:
#define(`NA',`ifelse($1,,1073741825,natst($1)!=0)')define(`NOARG',1073741827) # for Vaxes, etc
define(`NA',`ifelse($1,,1996490069,natst($1)!=0)')define(`NOARG',1996490067) # for 3B machines
#define(`NA',`ifelse($1,,2139095041,natst($1)!=0)')define(`NOARG',2139095143) # for 68000 based machines
# common block and subroutine names generated by f77 end in underscore
define(`F77_COM',`$1_')
define(`F77_SUB',`$1_')
#number of bytes into a pipe before blocking
define(`PIPESIZE',4096)
# max file name length - dataset names truncated to this size
define(`MAX_FILE_NAME_LEN',255)
define(`NCPW',4)define(`NBPC',8)#chars per word, bits per char
define(`DEPS',1.d-17)
define(`LARGEINT',1073741824)define(`BIGINT',LARGEINT)
define(`PRECISION',1.2e-7) # 1e-6 for Inter
define(`NDIGITS',7)
define(`BIGEXP',38)define(`BIG',1e`'BIGEXP)define(`SMALL',1e-BIGEXP)
define(`PI',3.1415926)define(`DEG2RD',.0174533)
define(`NASET',`call setna($1)')
# special FORTRAN features
define(`SAVE',`save $*') # only for F77
define(`CHARACTER',`ifelse($1,,CHAR,$2,*,`character*(*) $1',`character*$2 $1') dnl
ifelse($3,,,`(shift(shift($*)))')')
define(`EOS',`\\0')
define(`ESCAPE',`\\\\')define(`NEWLINE',`\\n')
define(`BACKSPACE',`\\b')
define(`LINEWIDTH',126)define(`LWIDTH',80)define(`FWIDTH',14)define(`MAXSTRING',511)
define(`ERRORFC',2)define(`STDIN',0)define(`STDOUT',1)
define(`MAXFC',15) # size of stack for attach
define(`FILECODE',`$1-1')define(`WHICHFILE',`$1+1')
define(`INCLUDE',`InClUdE($*)')
define(`InClUdE',`ifelse($1,,,
`include(SHOME/newfun/`include'/$1.m)
InClUdE(shift($*))')')
define(`XNAME',`substr(z$1,0,6)') # definition of interface function name
define(`EXTERN',extern)
define(`NOEXTERN',`define(`EXTERN',`')')
define(`TAB',`\\t')
define(`GCOS',`')define(`UNIX',`$*')
define(`STDPERMS',0775)
define(`READ',`ifelse($1,,0,`_READ($*)')')
define(`WRITE',1)define(`READWRITE',2)
define(`EXECUTE',2)
define(`MSG_FILE',`s/msg.d') #relative to S home directory
define(`SYSDB_FILE',`s/data')
define(`SDEFAULT',`s') # standard chapter
define(`SLOCAL',`slocal') # local installation-dependent chapter
define(`WORK_FILE',`swork')
define(`DB_FILE',`sdata')
define(`DUMP_FILE',`sdump')
define(`EDIT_FILE',`sedit')
define(`GRAPH_FILE',`sgraph')
define(`HELP_WHERE',`/.help')
define(`ICHAR',`ichar($1)') # for macro processor
define(`CHARMAKE',`char($1)')
define(`LIST',`$*')
# from PORT
# 3B or 90x constants
define(`R1MACH',`ifelse($1,1,0.11754944E-37,
$1,2,0.34028235E39,
$1,3,0.59604645E-07,
$1,4,0.11920929E-06,
$1,5,0.30103001E00)')
define(`I1MACH',`ifelse(
$1,9,2147483647,
$1,10,2,
$1,11,24,
$1,12,-125,
$1,13,128)')
define(`STACK_SAVE_LEN',4)
define(`MAXPROC',15)define(`MAXNAME',20)
define(`DSIZE',6)
define(`RSIZE',eval(2*DSIZE))
define(`ISIZE',eval(2*DSIZE))
define(`LSIZE',eval(2*DSIZE))
define(`SIZEOF',`ifelse($1,DBL,2,1)')
define(`ON_ERROR',1)define(`ON_BREAK',2)define(`PROBLEM_DONE',3)# for interface
divert(0)dnlgenerous@dgis.UUCP (Curtis Generous) (03/17/87)
Path: dgis!generous
From: generous@dgis.UUCP (Curtis Generous)
Newsgroups: mod.computers.pyramid
Subject: Moving the wtmp files on OSx3.1
Keywords: wtmp, osx3.1
Message-ID: <217@dgis.UUCP>
Date: 17 Mar 87 19:07:49 GMT
Distribution: usa
Organization: Defense Gateway Info. System, Alexandria, VA
Lines: 16
Does anyone know of any reasons why the .attwtmp and the .ucbwtmp
are located in /etc instead of /usr/adm under OSx3.1? (/usr/adm/wtmp
is just a conditional symbolic link to either /etc/.attwtmp or /etc/.ucbwtmp).
Our root file system is normally pretty full, and operating constantly around
the 90% mark is not acceptable (Our /usr file system is another disk partition).
Here are the vital stats: Pyramid 98x, OSx3.1, 4 iop's, 1 ioc, 6 NEC2352's
drives.
-curtis-
Curtis C. Generous
Lawrence Livermore National Labs
ARPA: generous@lll-tis-b.ARPA
UUCP: {seismo,vrdxhq}!dgis!generousuucp@DECWRL.DEC.COM.UUCP (04/07/87)
Path: decwrl!pyramid!sas From: sas@pyrps5 (Scott Schoenthal) Newsgroups: comp.unix.wizards,mod.computers.pyramid Subject: Re: Errors that can't happen ! Summary: Pyramid directory NFS fix Message-ID: <1856@pyramid.UUCP> Date: 7 Apr 87 16:36:10 GMT References: <535@ssl-macc.co.uk> <106@otc.OZ> Sender: daemon@pyramid.UUCP Lines: 38 Received: from pyrps5 by pyramid.UUCP (5.52/UUCP-Project/rel-1.0/09-16-86) id AA13205; Tue, 7 Apr 87 07:36:05 PDT Received: by pyrps5.pyramid.com (5.52/UUCP-Project/rel-1.0/09-29-86) id AA16411; Tue, 7 Apr 87 07:30:15 PDT In article <106@otc.OZ>, adjg@otc.OZ (Andrew Gollan) writes: > in article <535@ssl-macc.co.uk>, ray@ssl-macc.co.uk (Ray Saxton) says: > > ... > > rfs_read: attempt to read from non-file > > rfs_read: attempt to read from non-file > > ... > > .... > > > > We get it on a small network of a Pyramid 90X and two sun 3/50s (one > server, one client). It seems to happen when the Pyramid mounts a sun > FS. We also have some other funnies with the Sun-Pyramid NFS since we > upgraded the Suns to Release 3.2 (Directories cannot be read by the ATT > universe read system call). We're in the process of making available the fix for the case in which the user attempts to read a directory from the att universe via NFS to a Sun running SunOS 3.2 or later. The "rfs_read" message occurs when the server side detects that a client wishes to read a vnode which is not a regular file. This may be either a directory, a block special, or character special. The Sun NFS 3.2 reference implementation (that is the Vax/NFS implementation provided to NFS vendors such as Pyramid) provides hooks to the client to interpret special devices locally rather than ship the read (or write) over the wire. Very useful when one begins to consider the issues of accessing a root partition from a diskless NFS client. I can't speak for the scenario in which both the client and server are Suns except to note the previous paragraph. On the Pyramid, ucb universe directory reads (and all reads, for that matter) should work with SunOS 3.2. In the att universe, directory reads will work versus servers earlier than SunOS 3.2 without the fix. sas ------------------------- Scott Schoenthal Pyramid Technology Corp. Mountain View, Ca. {allegra,decwrl,hplabs,ut-sally,utzoo}!pyramid!sas
news@oliveb.ATC.OLIVETTI.COM.UUCP (04/07/87)
Path: oliveb!pyramid!sas From: sas@pyrps5 (Scott Schoenthal) Newsgroups: comp.unix.wizards,mod.computers.pyramid Subject: Re: Errors that can't happen ! Summary: Pyramid directory NFS fix Message-ID: <1856@pyramid.UUCP> Date: 7 Apr 87 16:36:10 GMT References: <535@ssl-macc.co.uk> <106@otc.OZ> Sender: daemon@pyramid.UUCP Lines: 38 Received: from pyrps5 by pyramid.UUCP (5.52/UUCP-Project/rel-1.0/09-16-86) id AA13205; Tue, 7 Apr 87 07:36:05 PDT Received: by pyrps5.pyramid.com (5.52/UUCP-Project/rel-1.0/09-29-86) id AA16411; Tue, 7 Apr 87 07:30:15 PDT In article <106@otc.OZ>, adjg@otc.OZ (Andrew Gollan) writes: > in article <535@ssl-macc.co.uk>, ray@ssl-macc.co.uk (Ray Saxton) says: > > ... > > rfs_read: attempt to read from non-file > > rfs_read: attempt to read from non-file > > ... > > .... > > > > We get it on a small network of a Pyramid 90X and two sun 3/50s (one > server, one client). It seems to happen when the Pyramid mounts a sun > FS. We also have some other funnies with the Sun-Pyramid NFS since we > upgraded the Suns to Release 3.2 (Directories cannot be read by the ATT > universe read system call). We're in the process of making available the fix for the case in which the user attempts to read a directory from the att universe via NFS to a Sun running SunOS 3.2 or later. The "rfs_read" message occurs when the server side detects that a client wishes to read a vnode which is not a regular file. This may be either a directory, a block special, or character special. The Sun NFS 3.2 reference implementation (that is the Vax/NFS implementation provided to NFS vendors such as Pyramid) provides hooks to the client to interpret special devices locally rather than ship the read (or write) over the wire. Very useful when one begins to consider the issues of accessing a root partition from a diskless NFS client. I can't speak for the scenario in which both the client and server are Suns except to note the previous paragraph. On the Pyramid, ucb universe directory reads (and all reads, for that matter) should work with SunOS 3.2. In the att universe, directory reads will work versus servers earlier than SunOS 3.2 without the fix. sas ------------------------- Scott Schoenthal Pyramid Technology Corp. Mountain View, Ca. {allegra,decwrl,hplabs,ut-sally,utzoo}!pyramid!sas
uucp@DECWRL.DEC.COM.UUCP (04/07/87)
Path: decwrl!pyramid!sas From: sas@pyrps5 (Scott Schoenthal) Newsgroups: comp.unix.wizards,mod.computers.pyramid Subject: Re: Errors that can't happen ! Summary: Pyramid directory NFS fix Message-ID: <1857@pyramid.UUCP> Date: 7 Apr 87 18:56:14 GMT References: <535@ssl-macc.co.uk> <106@otc.OZ> Sender: daemon@pyramid.UUCP Lines: 38 Received: from pyrps5 by pyramid.UUCP (5.52/UUCP-Project/rel-1.0/09-16-86) id AA16561; Tue, 7 Apr 87 09:56:10 PDT Received: by pyrps5.pyramid.com (5.52/UUCP-Project/rel-1.0/09-29-86) id AA16411; Tue, 7 Apr 87 07:30:15 PDT In article <106@otc.OZ>, adjg@otc.OZ (Andrew Gollan) writes: > in article <535@ssl-macc.co.uk>, ray@ssl-macc.co.uk (Ray Saxton) says: > > ... > > rfs_read: attempt to read from non-file > > rfs_read: attempt to read from non-file > > ... > > .... > > > > We get it on a small network of a Pyramid 90X and two sun 3/50s (one > server, one client). It seems to happen when the Pyramid mounts a sun > FS. We also have some other funnies with the Sun-Pyramid NFS since we > upgraded the Suns to Release 3.2 (Directories cannot be read by the ATT > universe read system call). We're in the process of making available the fix for the case in which the user attempts to read a directory from the att universe via NFS to a Sun running SunOS 3.2 or later. The "rfs_read" message occurs when the server side detects that a client wishes to read a vnode which is not a regular file. This may be either a directory, a block special, or character special. The Sun NFS 3.2 reference implementation (that is the Vax/NFS implementation provided to NFS vendors such as Pyramid) provides hooks to the client to interpret special devices locally rather than ship the read (or write) over the wire. Very useful when one begins to consider the issues of accessing a root partition from a diskless NFS client. I can't speak for the scenario in which both the client and server are Suns except to note the previous paragraph. On the Pyramid, ucb universe directory reads (and all reads, for that matter) should work with SunOS 3.2. In the att universe, directory reads will work versus servers earlier than SunOS 3.2 without the fix. sas ------------------------- Scott Schoenthal Pyramid Technology Corp. Mountain View, Ca. {allegra,decwrl,hplabs,ut-sally,utzoo}!pyramid!sas