HDTenEightyP/NetNews huggingface dataset:
From: peter@merlin.acadiau.ca (Peter Steele)
Newsgroups: comp.sys.mips
Subject: Re: Growreg problems ????
Date: 16 Oct 92 11:06:12 GMT
Distribution: na
Organization: Acadia University

In comp.sys.mips you write:

>I keep getting this:

>NOTICE: uballoc - Insufficient memory to allocate 2 pages - system call failed

>NOTICE: growreg - Insufficient memory to allocate 509 pages - system call faile
d

>NOTICE: dupreg - Insufficient memory to allocate 321 pages - system call failed

We experienced these very same errors and discovered it was due to lack
of swap space. You should have roughly 2.5 times real memory defined
for swapping. If you have 40M of memory, you should have 100M of swap
space. This is approximate of course. You might be able get away with 
less, depending on what you're doing.
--
Peter Steele        Unix Services Manager            peter.steele@acadiau.ca 
Acadia Univ., Wolfville, NS, Canada B0P 1X0  902-542-2201  Fax: 902-542-4364
From: pho@dde.dk (Peter Holm)
Newsgroups: comp.sys.mips
Subject: The R4000 tlb
Date: 11 Oct 92 20:50:41 GMT
Organization: Dansk Data Elektronik A/S
X-Newsreader: Tin 1.1 PL5


I'm puzzled by the R4000 tlb design. Why is it that the R4000 tlb
contain 48 odd/even page pairs ? Why pairs ?

Now, what I need is 4 K pages, so in effect I get (at most) 2 * 48 4K
page entries in the tlb ?

Had it been possible to have 8 K pages, would it not achieve (almost)
the same, without the need for page pairs ?

-- 
Peter Holm                        Tel: int +45 42 84 50 11 (UTC + 1)
Dansk Data Elektronik A/S         Fax: int +45 42 84 52 20
Herlev Hovedgade 199              Telex: 35258 dde dk
DK-2730 Herlev, Denmark           E-mail:  pho@dde.dk
Newsgroups: comp.sys.mips
From: bruce@cs.su.oz.au (Bruce Janson)
Subject: RISC/os 5.0B (r4000): bug in "trap" in /bin/sh
Organization: Basser Dept of Computer Science, University of Sydney, Australia
Date: Thu, 15 Oct 1992 15:52:44 GMT

[I tried bugs@mips.com and csmail@mips.com but they bounced.
 Maybe they shouldn't have put all their mips into one baskett :-).]

$ cat > t <<EOF
#!/bin/sh

trap "trap '' 0; exit 1" 0
trap '' 0

trap "trap '' 0; echo hi; exit 1" 0
trap '' 0

exit 0
EOF
$ chmod +x t
$ ./t
hi
$ 

I expect the above script to say nothing but it says "hi" -- a bug?

Cheers,
bruce.

Bruce Janson					Email:	bruce@cs.su.oz.au
Basser Department of Computer Science		Phone:	+61-2-692-3423
University of Sydney, N.S.W., 2006, AUSTRALIA	Fax:	+61-2-692-3838
From: andrew@dino.qci.bioch.bcm.tmc.edu (Andrew Sharff)
Newsgroups: comp.sys.mips
Subject: AMD - automounter
Date: 13 Oct 1992 16:14:58 GMT
Organization: X-Ray Crystallography / Howard Hughes Medical Institute
NNTP-Posting-Host: dino.qci.bioch.bcm.tmc.edu

Has anyone got the automounter program amd (from Imperial College, London) 
to compile and run on a mips machine running risc-os.  More specifically an 
Evans & Sutherland ESV running bsd43.  

Any help would be appreciated.

Andrew Sharff.
From: bin@uakari.primate.wisc.edu (Brain in Neutral)
Newsgroups: comp.sys.mips
Subject: Current wisdom on 3rd party memory for M/120?
Date: 8 Oct 1992 15:54:32 -0500
Organization: Cafe Limbo
NNTP-Posting-Host: uakari.primate.wisc.edu

What's the current wisdom on obtaining 3rd party memory for a Mips
M/120?  (Suppliers, cost.)
-- 
Paul DuBois
dubois@primate.wisc.edu
From: haider@netcom.com (Jamal Haider)
Newsgroups: comp.sys.mips
Subject: NEC VR4000 RISC CPU
Date: 16 Oct 92 02:18:07 GMT
Distribution: na
Organization: Netcom - Online Communication Services  (408 241-9760 guest)

Newsgroups: all
Subject: NEC Vr-4000 RISC seminar
Summary: 
Followup-To: 
Distribution: 
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Keywords:RISC 


Let NEC give you the facts about RISC processors.  Join us at
the "Vr4000: The Processor for today, tomorrow and beyond" seminar.
Learn why the Vr4000 is and will continue to be the performance 
and price leader through the 90's.

    NEC Electronics will provide you with the opportunity to learn 
why the MIPS R4000 architecture is not only the architecture of choice
for today, but is also the cornerstone for future advances 
in microprocessor development.  Today, NEC's Vr4000 integrates 
a high performance 64 bit CPU with a primary cache and a floating
point unit all on one single die.  Versions of the Vr4000 with 
secondary cache interface and multiprocessor support are also 
available.  At our free seminar we'll take you through future 
migration paths, discuss packaging trends, pricing and performance,
and provide you with a detailed technical analysis.
4000 RISC-based systems offer a much higher level of 
graphical and computational performance compared to X86 systems. 

    If you design CISC or RISC systems, you can't afford to miss 
this seminar.  Join us at one of the following locations and learn 
why the Vr4000 should be your processor of choice for leading 
edge workstations, powerful PC's, multiprocessor and embedded 
control systems.

Locations:       October 20,1992 LeBaron Hotel San Jose California
                 October 22,1992 Burlington Marriott, Boston, Massachusetts
                 November 4, 1992 Red Lion, Costa Mesa, California

Signup:         Please call (415)695-6159 or fax 1(800)729-9288
 
Agenda:
9:00 - 9:15 NEC Company Profile
9:15 - 9:30 MIPS, An Open Architecture
9:30 - 10:00 NEC RISC Products
10:00 - 10:15 MIPS Architecture Review

10:15 - 10:30 Break

10:30 - 11:00 VR4000, The processor of choice for multiple platforms
11:00 - 11:30 VR4000 RISC Architecture
11:30 - 12:00 VR4000 Implementation

12:00 - 1:00 Complimentary Lunch

1:00 - 2:00 VR4000 Implementation
2:00 - 2:30 VR4000 Performance / Competitive Analysis

2:30 - 2:45 Break

2:45 - 3:00 Mips Development Tools
3:00 - 3:45 Third Party Development Tools
3:45 - 4:00 Future of MIPS Architecture
4:00 - 5:00 System Demonstrations

See you at this seminar!!!!!!!!
Xref: sparky comp.sys.mips:973 ba.market.computers:4896 misc.forsale.computers:36174
From: kirke@fox.csd.sgi.com (Kirk Erickson)
Newsgroups: comp.sys.mips,ba.market.computers,misc.forsale.computers
Subject: Mips 3330 for sale
Date: 7 Oct 92 18:54:36 GMT
Distribution: usa
Organization: Silicon Graphics, Inc.


All equipment 1 year old in mint condition:

    Magnum 33MHz (R3000A/R3010A)                        14990
        Unix-97 keyboard
        40MB of memory (70ns simms)
        19" Color Monitor (Sony GDM-1950 Trinitron)
    Maxtor 8760s (760M external disk drive)              1940
    Archive Viper 2150s (150M 1/4" tape drive)            750
    ---------------------------------------------------------
    total                                               17680
    8.25% sales tax                                      1458
    ---------------------------------------------------------
    retail value                                        19138

Asking $11k for everything.
Email kirke@sgi.com or phone (415)390-2149.
--
---------------------   o  ---------------------------------------------
Kirk Erickson         <(        Silicon Graphics Inc., Mountain View, CA
kirke@sgi.com          [\.                               uunet!sgi!kirke
Newsgroups: comp.sys.mips
From: narayan@aravali.everest.tandem.com (Pankaj Narayan)
Subject: Growreg problems ????
Reply-To: narayan@aravali.everest.tandem.com (Pankaj Narayan)
Organization: Tandem Computers Inc., Cupertino CA
Distribution: na
Date: Thu, 15 Oct 1992 21:59:02 GMT

I keep getting this:

NOTICE: uballoc - Insufficient memory to allocate 2 pages - system call failed

NOTICE: growreg - Insufficient memory to allocate 509 pages - system call failed

NOTICE: dupreg - Insufficient memory to allocate 321 pages - system call failed

This is despite my having 40 megabytes of RAM installed on a 25MHz R3000
machine. 

I have RiscOS 4.0.1 (I think) - not the latest version 5 (or whatever).

This seems to be a memory leak problem - is it documented somewhere ?
What am I supposed to do save shutting down my machine to do periodic
flushes of memory ????

Any ideas ? Please mail.  
------------------------------------------------------------------------
Pankaj Narayan			Email: narayan_pankaj@tandem.com
Tandem Computers
Newsgroups: comp.sys.unisys
Subject: Re: FTP File xfers
From: liam@amigans.gen.nz (Liam Greenwood)
Date: Mon, 12 Oct 92 11:07:33 GMT+1
Organization: Wanganui Amigans, Wanganui, New Zealand

cc971@cleveland.Freenet.Edu (Stephen  C. Fitch) writes:

> 
> Hi,
> 
> I am interested in gathering together peoples experience on
> the subject of file transfer. We have a 2200/433 + DCP 40s.
> This hardware runs DDN1100, CMS1100 7r2, along with the
> rest of CD5. What I would like to do is improve the efficiency
> of our FTP (TCP/IP) file transfers and therefore reduce the
> time to transfer our multi-megabyte files. The file transfers
> take place each night, down to UNIX hosts.
Get your Unisys Rep to get you PLE 15632224 - Improve performance of 
cms1100 using the TCP/IP stack.  PLE 15663901 may also be useful. There's a 
few other PLEs in this area so it may be worth your while to get your Rep to do 
a search of Primus for the keywords TCP  IP  DDN1100 against ther level of 
CMS1100 you're planning on running.

                         Hope this helps, Liam

                       
Liam Greenwood, Wanganui Amigans, Wanganui N.Z. (liam@amigans.gen.nz)
             Don't tell my mother I'm a programmer,
             she thinks I'm a piano player in a brothel.
Newsgroups: comp.sys.unisys
From: MPA15AB!COMPSYSU@TRENGA.tredydev.unisys.com
Subject: 2Re: Info about A Serie
Organization: C-S-U Gateway
Date: Wed, 14 Oct 1992 02:08:00 GMT
Comments: Actually-From: Randall "vive.hodie" Gellens <RANDY @ MPA15AB>

> Actually, the architecture is based on numerous stacks.  Generally,
> each task will have one code stack and one data stack.  The use of
> libraries will increase the number of stacks associated with a task.

All running programs exist as stacks.  The system maintains a stack tree,
with the operating system as the root stack.

To make it easier to do reentrant code, an extra stack is used for the
"segment dictionary" of every running program.  Only one of these is
needed per unique program, no matter how many copies of it are running.
The segment dictionary contains descriptors for every code segment in
the program, and static data (value arrays, etc.).  Since this stuff never
changes, there is no need for more than one of these.

The MCP is called D0 because it is the root of everything; Display register
zero points to the base of its activation.  Segment dictionaries are called
D1 stacks because Display register one points to the base of their activation.
The outer block of a program is called a D2 stack because Display register two
points at the base of its activation.  Blocks called by the outer block run
at higher D (lex) levels.

For practical purposes, the D2 stacks are the running programs.  This stack
contains all active procedures and all data and all active expressions.

  =====================================================================
  = sua cuique voluptas              (everyone has his own pleasures) =
  = Randy Gellens            randy%mpa15ab@trenga.tredydev.unisys.com =
  = >>>>>>> If mail bounces, forward to rgellens@mcimail.com <<<<<<<< =
  = Opinions are personal; facts are suspect; I speak only for myself =

                          Randomly selected tag:

Death is nature's way of telling you to slow down

Newsgroups: comp.sys.unisys
From: MPA15AB!COMPSYSU@TRENGA.tredydev.unisys.com
Subject: 2Re: Info about A Serie
Organization: C-S-U Gateway
Date: Wed, 14 Oct 1992 02:32:00 GMT
Comments: Actually-From: Randall "vive.hodie" Gellens <RANDY @ MPA15AB>

>> This makes A Series programs
>> quite easy to debug, as any invalid indexes, or pointer overflows to
>> a block are caught immediately, not at some later time, when the
>> real error has been obscured.

Plus, the fact that the running program exists as a data, expression, and
history stack all in one makes it easy to see from a dump (a listing of the
stack) just what it was doing, what the contents are of the variables, and
what the execution history was at the time of the trouble.

  =====================================================================
  = sua cuique voluptas              (everyone has his own pleasures) =
  = Randy Gellens            randy%mpa15ab@trenga.tredydev.unisys.com =
  = >>>>>>> If mail bounces, forward to rgellens@mcimail.com <<<<<<<< =
  = Opinions are personal; facts are suspect; I speak only for myself =

                          Randomly selected tag:

Excellent time to become a missing person.
From: DNA15A!STERN@TRENGA.tredydev.unisys.com
Newsgroups: comp.sys.unisys
Subject: Re:CTOS to Unix Tape Transfer
Date: 11 Oct 1992 10:59:32 -0500
Organization: UTexas Mail-to-News Gateway
NNTP-Posting-Host: cs.utexas.edu

> I am looking for a way to convert a 150 QIC archive, made on a
> CTOS SG5000 machine, to a UNIX readeble format.
> It's possible to read the tape with te 'dd' command.
> But the archive has a certain internal structure, it appears that
> it's build on blocks of 64 K with some control delimiters and within
> blocks you see a sort of 'tar' format.
>  Question: has someone out there a program that can read such a archiv
>            or is there a C-structure which gives me the layout of the
>            archive so that I can make a program on myself.
Probably the best way to create a tar or cpio tape that a Unix system
can read from an SG5000 is to restore the tape back to the SG5000
disk and use the POSIX.1 and POSIX.2 shell and utilities which
support the "pax" utility to create a new tape. "pax" is a POSIX
utility which inputs/outputs either in tar or cpio format. The old
CTOS Developers Toolkit which had a form of cpio is no longer
available or supported.

The CTOS format for archive has changed from std sw 11.x through 12.0
and 12.1 so it is not easy to copy the tape. But an engineer in the
Unisys McLean VA office  as written a program to copy the tape and
may be willing to "share" the code if asked. Contact Unisys VAM support
and ask for the McLean VA office.

This is the personal opinion of the sender and does not reflect an
official Unisys position.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joel Stern                           Protocol Products Group
Tredyffrin, Net2 385-3532            BTOS BNA, CP3680

Newsgroups: comp.sys.unisys
From: dave@dlb.com (Dave Buck)
Subject: Re: Gateway to Unisys Internal Mail System?
Reply-To: dave@dlb.com (Dave Buck)
Organization: D.L.Buck & Associates, Inc.; San Jose, Calif.
Date: Wed, 14 Oct 1992 15:41:57 GMT

In article <718889927snx@brimbank.apana.org.au> nick@brimbank.apana.org.au (Nick Langmaid) writes:
>I suspect that this question may have been asked before, but ...

Yup.  We need a FAQ, already.

>Does anybody know whether there is a gateway between Usenet and the
>Unisys internal mail system?  I'm thinking of the Mapper-based system.
>Does it work in both directions?

Yes, and Yes, for the smart-alec answer.

Now, for the nice one.  If you have mail to send to XXXX/CORP, for
example, send mail to the gateway address "postmstr@unislc.slc.unisys.com"
(note the funny spelling "postmstr"), then include a line anywhere in the
body:
#To: CORP.XXXX

XXXX/CORP can send to me, for example, by addressing mail to "postmstr/un49",
and including a line in the body:
#To: dave@dlb.com

Multiple "#To:" lines are allowed.
The gateway IS CASE SENSITIVE.
-- 
Dave Buck   dave@dlb.com   {amdahl,ames,daver,netcomsv,sun,zygot}!dlb!dave
D. L. Buck and Associates, Inc.;   San Jose, California;    (408) 972-2825
From: jgd@csd4.csd.uwm.edu (John G Dobnick)
Newsgroups: comp.sys.unisys
Subject: Re: 2Re: Info about A Serie
Date: 15 Oct 1992 22:49:32 GMT
Organization: University of Wisconsin - Milwaukee
Reply-To: jgd@csd4.csd.uwm.edu
NNTP-Posting-Host: 129.89.7.4
Originator: jgd@csd4.csd.uwm.edu

From article <1992Oct15.065208.6824@timesink.chi.il.us>, by harry@timesink.chi.il.us (Harold Platypus):
> 
>                                             Unisys also has a terrible
> reputation for bad customer support on the boxes they OEM'ed from dead
> and dying manufacturers like Arete/Arix and Sequent.

Not to mention CCI.  [So I won't. :-{ ]

-- 
John G Dobnick (Exec-8 guru, ret.)      ATTnet: (414) 229-5727
Computing Services Division             INTERNET: jgd@uwm.edu
University of Wisconsin - Milwaukee     UUCP: uunet!uwm!jgd

"Knowing how things work is the basis for appreciation,
and is thus a source of civilized delight."  -- William Safire
Newsgroups: comp.sys.unisys
From: MPA15AB!COMPSYSU@TRENGA.tredydev.unisys.com
Subject: 2Re: Info about A Serie
Organization: C-S-U Gateway
Date: Wed, 14 Oct 1992 02:29:00 GMT
Comments: Actually-From: Randall "vive.hodie" Gellens <RANDY @ MPA15AB>

> It's a very interesting and powerful architecture.  Too bad that it
> didn't capture a larger market share.

I'm not sure I like the use of the past tense "didn't" here!  ;-)  I like to
think that more and more people will discover the advantages of the A Series.

  =====================================================================
  = sua cuique voluptas              (everyone has his own pleasures) =
  = Randy Gellens            randy%mpa15ab@trenga.tredydev.unisys.com =
  = >>>>>>> If mail bounces, forward to rgellens@mcimail.com <<<<<<<< =
  = Opinions are personal; facts are suspect; I speak only for myself =

                          Randomly selected tag:

"Procedures!  Of course, that's what you'd use with a *sophisticated*
machine like this.  Procedures."
                                    -- Ceaser Smith in _Hot_Millions_
Newsgroups: comp.sys.unisys
Subject: Re: FTP File xfers
From: liam@durie.amigans.gen.nz (Liam Greenwood)
Date: 9 Oct 92 18:39:55 GMT+12
Organization: It's Home, really...
X-Newsreader: TIN [version 1.1 PL6]

Stephen  C. Fitch (cc971@cleveland.Freenet.Edu) wrote:
>
> I am interested in gathering together peoples experience on
> the subject of file transfer. We have a 2200/433 + DCP 40s.
> This hardware runs DDN1100, CMS1100 7r2, along with the
> rest of CD5. What I would like to do is improve the efficiency
> of our FTP (TCP/IP) file transfers and therefore reduce the
    We don't actually run all of those things however I'm currently
migrating to CD5R2A (Telcon 9R1A) and to CMS1100 7R2C from SB4R4 and there's
a number of improvements in that area in these levels, so it may be
worth your while looking at those levels.

--
 Liam Greenwood ------ liam@durie.amigans.gen.nz ------ Wanganui, N.Z.
                 Don't tell my Mother I'm a programmer,
               she thinks I'm a piano player in a brothel

Newsgroups: comp.sys.unisys
From: martin@unislc.uucp (Martin Cryer)
Subject: Re: 2Re: Info about A Serie
Reply-To: martin@unislc.UUCP (Martin Cryer,D1Z01,5754)
Organization: Unisys, Salt Lake City
Date: Wed, 14 Oct 1992 18:35:12 GMT

In article <AMPU1411B21767@MPA15AB> MPA15AB!COMPSYSU@TRENGA.tredydev.unisys.com writes:
>> Odd tags indicate that the contents of the memory may not be accessed
>> as normal data.  They do not distinguish whether a word is read-only;
>> a separate bit in the descriptor indicates read-only status.  And
>> even a read-only word can be written to with the overwrite instruction.
>> Odd tags are used for a variety of purposes - e.g., the start and
>> end of arrays in memory, data descriptors, instruction words, IRWs, PCWs.
>> Attempting to access an odd tagged word as data for either reading or
>> writing causes a hardware interrupt.
>

As an aside, there is a discussion of tag field machines (including the
B5500 and B6700 which perhaps A series borrowed or built on?).

	BASIC MACHINE PRINCIPLES
	John K. Iliffe
	Second Edition, 1972
	MACDONALD & CO LTD (UK) ISBN 0 356 03575 1
	AMERICAN ELSEVIER PUBLISHING CO (USA) ISBN 0 444 19582 3

Martin Cryer
UNIX SVR4.0/MP Development
UNISYS Salt Lake City

All opinions are my own and are NOT those of my employer.
Newsgroups: comp.sys.unisys
From: MPA15AB!COMPSYSU@TRENGA.tredydev.unisys.com
Subject: 2Re: Info about A Serie
Organization: C-S-U Gateway
Date: Wed, 14 Oct 1992 02:11:00 GMT
Comments: Actually-From: Randall "vive.hodie" Gellens <RANDY @ MPA15AB>

> The different Emode levels are not fully compatible.  Three levels
> exist because of the incompatibility.  It is possible to transition
> from alpha to beta, and later from beta to gamma.  You cannot mix
> alpha and gamma, at least not without obtaining "unpredictable
> results".

The levels are close enough to ignore differences for the high level of
our discussions here.  In general, programs will run on any level.  There
are of course exceptions, such as older programs that use features that
were deimplemented on later versions (such as direct access to indexed
data discriptors via the REAL intrinsic), or newer programs that use features
introduced on later versions.

  =====================================================================
  = sua cuique voluptas              (everyone has his own pleasures) =
  = Randy Gellens            randy%mpa15ab@trenga.tredydev.unisys.com =
  = >>>>>>> If mail bounces, forward to rgellens@mcimail.com <<<<<<<< =
  = Opinions are personal; facts are suspect; I speak only for myself =

                          Randomly selected tag:

"Computers are useless.  They can only give you answers."
                             -- Pablo Picasso (1881-1973)

Newsgroups: comp.sys.unisys
From: cc971@cleveland.Freenet.Edu (Stephen  C. Fitch)
Newsgroups: comp.sys.unisys
Subject: Re: FTP File xfers
Date: 12 Oct 1992 08:18:13 GMT
Organization: Case Western Reserve University, Cleveland, OH (USA)
Reply-To: cc971@cleveland.Freenet.Edu (Stephen  C. Fitch)
NNTP-Posting-Host: hela.ins.cwru.edu


We experience file transfer rates of around 2.5Mb/minute and
we are transfering files from the UNiSYS host to UNIX machines.
We have also noted that the DCP is 100% busy during the transfers.

Over the past few days I have been investigating the channel between
the 2200 and the DCP, we have seen the following messages:

NCH            11:21:38.447     015/001                    020000 $(11)  NCH
            CODE=102 DCPA
            THE TOTAL NUMBER TIMES THAT THE HOST WAS ASKED TO RESEND A FRAME SINCE 00:03:06 10/02/92 IS  9
            THE NUMBER OF TIMES THAT A HOST FRAME HAD TO BE RESENT BECAUSE A STOP BIT WAS SET IN THE DATA IS 8

from CMSUTILITY, ltanalysis log file runs.


I decided to look at the channel arrangements we have because I
thought that the frame-sz parameter on the FEP NDS might have
been optimized for character based terminal traffic rather than
for burst mode file transfers.


If anyone could explain the NCH log file entries I'd appreciate
it. What FEP frame-sz values do people use in their CMS configs?


Steve Fitch                            o          ,__o        o   /\/\
Open University                       <\        _-\_<,     []<\  /~~\ \/\
Management Services Division        __/__,     (*)/'(*)      /> /    \ \ \
Milton Keynes, England.       +44 (0908)65 2733  s.c.fitch@open.ac.uk


Newsgroups: comp.sys.unisys