HDTenEightyP/NetNews huggingface dataset:
From: mcsun!dxcern!vxcrna.cern.ch!roeber@uunet.uu.net
Subject: re: Favourite DOMAIN/OS features (or mis-features)
Organization: CERN -- European Organization for Nuclear Research
Distribution: fj
Date: Wed, 22 Jul 1992 10:03:18 GMT
Return-Path: <apollo-list-errors@srvr1.engin.umich.edu>

In article <199207212228.AA01227@pan.ssec.honeywell.com>, thompson@PAN.SSEC.HONEYWELL.COM ((jt) John Thompson) writes:
> [...]
> o   The keyboard.  Biilllioonnns and biillionnns (sorry C. Sagan) of keys all
>     waiting to be redefined.  I _hate_ having to point and click and pulldown
>     and popup everything.

Ah, yes.  Especially for touch-typists like myself.  If I'm dragged (kicking and
screaming) to our new snakes, I'm going to hack (binary-only kernel hack, if I
have to) and wire so I can use the Domain keyboard.

> o   The USER-extensible, typed, file system!  [...]
>       (Thanks, guys -- I love the COMPRESS file type.)

Is it just me, or does anybody else have the hunch that the compress file type
was written by a remaining Apollo guy, who had read the perennial "on-the-fly
compression?/It can't be done" dialogs on comp.unix.wizards, and wanted to 
prove it *could* be done before the possibility slipped away?

The other day, somebody was wanting to boot normal BSD on a 3500.
I'd like to do the reverse: boot Domain on our snakes, suns, 386s, etc.
Anybody else interested?

-- 
Frederick G. M. Roeber | CERN -- European Center for Nuclear Research
e-mail: roeber@cern.ch or roeber@caltech.edu | work: +41 22 767 31 80
r-mail: CERN/PPE, 1211 Geneva 23, Switzerland | home: +33 50 42 19 44
Newsgroups: fj.mail-lists.apollo
From: destroyer!ubc-cs!unixg.ubc.ca!physics.ubc.ca!braham@gumby.wisc.edu  (Stephen Braham)
Subject: WANTED: X11R4 Server binaries for 10.2
Organization: University of British Columbia, Vancouver, B.C., Canada
Distribution: fj
Date: Tue, 28 Jul 1992 17:31:35 GMT
Return-Path: <apollo-list-errors@srvr1.engin.umich.edu>

Greetings Folks,
	We have a few Apollos running DomainOS Release 10.2
(BSD 4.3, of course) and we're in reasonably desperate need
of the BINARIES for an X11R4 server. We're low on disk space,
and thus want to avoid bringing in the entire MIT X11R4
distribution (as well as having other technical problems).
Do any of you have a copy of an R4 Xapollo that we can
grab from you? We'd be EXTREMELY appreciative.

		Thanks in advance,
				Steve Braham

--
| Name: Stephen P. Braham | Perversion: Quantum Cosmologist|
| Hangout: UBC physics    | Signature:  Euclidean          |
|          Vancouver, BC  |--------------------------------+
|          Canada         | E-mail: braham@physics.ubc.ca  |
Newsgroups: fj.mail-lists.apollo
From: agate!alanc@ucbvax.Berkeley.EDU  (Alan Coopersmith)
Subject: Re: compress file type (was: Favourite DOMAIN/OS ...)
Organization: U.C. Bezerkeley Overloaded Computing Facility
Distribution: fj
Date: Sat, 25 Jul 1992 19:23:10 GMT
Return-Path: <apollo-list-errors@srvr1.engin.umich.edu>

In article <BCR.92Jul25124722@hpl3sn02.cern.ch> bcr@cernapo (Bill Riemers) writes:
)> Compress a file using the standard /usr/ucb/compress routine.
)> Change the type on it to be compress, by using '/etc/obty pathname... compress'
)
)a88k:3% /etc/obty stupid.1.Z compress
)?(obty) Unable to get type uid for type "compress" - type not found (object based systems/type manager)
)
)Could you elaborate on how to make the compress file type?

Make sure you're running Domain O/S 10.4 (use the bldt command to see what
version you have).

)Will the files be accessable to fortran programs directly?  (Emacs already uncompresses
)text files ...)

They will show up as normal files, with one major difference - they are
read-only (no editing).


-- 
------------------------------------------------------------------------
Alan Coopersmith			Internet: alanc@ocf.berkeley.edu
University of California, Berkeley	Bitnet:   alanc@UCBOCF.BITNET
Newsgroups: fj.mail-lists.apollo
From: johnb@hobbes.mdc.com (John Breen)
Subject: Swapping disks between DN4000 & DN3000
Organization: McDonnell Douglas Missile Systems Company
Distribution: fj
Date: Mon, 27 Jul 1992 14:59:36 GMT
Return-Path: <apollo-list-errors@srvr1.engin.umich.edu>

This should be an easy one...:-)

We've got a DN4000 with a MSD-170M disk, and a DN3000 with a MSD-86M disk. 
We're going to upgrade the DN4000 to a 380M disk, but naturally I would like
to take its old disk and put it in the DN3000.

Is there any reason why this can't be done? Are there (potential) differences
in the disk controllers that I need to watch out for?  Any serial number
ranges or board revision numbers I should check?

Any help much appreciated.
--
-- 
John A. Breen                           |  johnb@hobbes.mdc.com
McDonnell Douglas Missile Systems Co.   | "I have no personal opinions;
Tel: (314)234-4341                      |  I'm a product of my environment."
Newsgroups: fj.mail-lists.apollo
From: van-bc!ubc-cs!unixg.ubc.ca!kakwa.ucs.ualberta.ca!chopin.eche.ualberta.ca!barton@ucbvax.Berkeley.EDU  (Bob Barton System Administrator (403)492 5160)
Subject: Help. 15" monitor died
Organization: University Of Alberta, Edmonton Canada
Distribution: fj
Date: Tue, 21 Jul 1992 14:32:24 GMT
Return-Path: <apollo-list-errors@srvr1.engin.umich.edu>

The 15" monochrome monitor on our DN2500 just died. Probably switching power-
supply problem. Are there any substitute monitors that may be more readily
available than the HP/Apollo ones?
Newsgroups: fj.mail-lists.apollo
From: dwv@engin.umich.edu (Doug Vander Wilt)
Subject: Re: Mtools on Apollo, sidetrack on DPCC/DPCE
Organization: Electrotechnical Laboratory, Tsukuba Science City
Distribution: fj
Date: Wed, 29 Jul 1992 21:23:37 GMT
Return-Path: <apollo-list-errors@srvr1.engin.umich.edu>

sun-barr!cs.utexas.edu!usc!snorkelwacker.mit.edu!bloom-picayune.mit.edu!pegasus.mit.edu!bri@ames.arc.nasa.gov (Brian D. Carlstrom) writes:
> question about DPCE/DPCC. the DPCE part is the emulator.
> the DPCC part is the card? do i need the card to run the emulator...
> or will just the software alone work...

DPCE (Domain PC Emulator) is a complete software only solution for Domain/OS:
    "The dpce command starts DPCE in a window on your workstation.  DPCE
     consists of software that emulates an IBM PC/AT, allowing you to use DOS
     commands and run PC application programs." (from 'help dpce')

DPCC (Domain PC Coprocessor) consists of (80286-based) hardware and software
to perform the same function as well as AT-bus device support.  I'm not sure
DPCC is still available but DPCE on a 400 series machine runs faster that
DPCC.  There was another company called "Applied Reasoning" that made a
386-based coprocessor.  That company is now defunct.  SoftPC is a product
the performs PC emulation (in software) on HP-UX.

Doug Vander Wilt
Honeywell MICRO SWITCH Division
dwv@cadnet.micro.honeywell.com
Newsgroups: fj.mail-lists.apollo
From: clsi!mitch@uunet.uu.net  (Mitchell N. Perilstein)
Subject: Does /bin/cc take only 16 -D options?
Organization: CAD Language Systems, Inc.
Distribution: fj
Date: Thu, 30 Jul 1992 23:36:15 GMT
Return-Path: <apollo-list-errors@srvr1.engin.umich.edu>

Compiling "int main() { ; }" on a DN3500 with /bin/cc (v.6.7.m, I think)
running 10.3.2 in BSD mode, we get this:

	/bin/cc -Da -Db -Dc -De -Df -Dg -Dh -Di -Dj -Dk -Dl -Dm -Dn -Do -Dp 
	-Dq -Dr -Ds -Dt a.c
	a.c: 0: too many -D options, ignoring -Dr
	a.c: 0: too many -D options, ignoring -Ds
	a.c: 0: too many -D options, ignoring -Dt

This smells really bad. Can it only take 16 defines? Is there a
graceful solution? All I can think of is putting this in my makefiles:
	
	cat << EOF > temp.c
	echo #define a
	echo #define b 
	echo #define c 
	EOF
	cat a.c >> temp.c
	/bin/cc temp.c

Thanks,
---
Mitchell N. Perilstein                               5457 Twin Knolls Rd
CAD Language Systems, Inc.                           Suite 101
410-992-5700                                         Columbia, MD 21045-3259
Newsgroups: fj.mail-lists.apollo
From: ub!galileo.cc.rochester.edu!beech.lle.rochester.edu!bmcm@rutgers.edu  (Brian McMaster)
Subject: BZONE on the Spark or PC
Organization: UofR Laboratory for Laser Energetics
Distribution: fj
Date: Thu, 23 Jul 1992 17:15:05 GMT
Return-Path: <apollo-list-errors@srvr1.engin.umich.edu>

I've been looking for the fortran code for BZONE (I'm the one who started
this thread).  I have found BZONE on interworks but it runs only under X
on an HP nothing for a Sun and no Fortran code.  It _is_ a pleasure to use, 
just like I remember! 

I also recieved email from nazgul@alfalfa.com who said he seams to have
the original Fortran code.

What I realy want is to be able to run BZONE on my Spark and/or a PC.  The 
Fortran code would be great, I could compile on both platforms.  If nazgul or 
anyone else has a version for X on the Sun, bitmap on the Sun or one that will 
run on a PC, please email me the location! The internet number with an anon
ftp would be great!


Thanks to all who have responded (esp. Dave Krowitz)
Newsgroups: fj.mail-lists.apollo
From: paladin.american.edu!darwin.sura.net!Sirius.dfn.de!news.uni-stuttgart.de!rz.uni-karlsruhe.de!uni-heidelberg!vm.urz.uni-heidelberg.de!L58@gatech.edu  (Dieter Menszner)
Subject: Re: Favourite DOMAIN/OS features (or mis-features)
Organization: University of Heidelberg, Germany
Distribution: fj
Date: Fri, 24 Jul 1992 17:16:20 GMT
Return-Path: <apollo-list-errors@srvr1.engin.umich.edu>

In article <Bruw7G.9z1@apollo.hp.com>
roc@apollo.HP.COM (R. O. Curtis) writes:

>
>Around here, perhaps the most commonly-cited
>piece of vanishing Apollo wonderfulness is the
>semi-standard definition of m3 to "click
>open" a file.  This "feature" has an infinity
>of valuable uses, and does not seem likely to
>reemerge through any combination of other stuff
>(X and DCE?) that I can imagine.
>
>-r
>
>
>
On our Apollos and HP's we are using the Epoch editor (GNU emacs +
X features). It can do everything the dm editor can, including the "m3"
feature.

Dieter
Newsgroups: fj.mail-lists.apollo
From: cis.ohio-state.edu!zaphod.mps.ohio-state.edu!sdd.hp.com!hpscdc!hplextra!otter.hpl.hp.com!hpltoad!hpopd!hpwin052!dan@ucbvax.Berkeley.EDU  (Dan Bennett)
Subject: Re: Auto reboot problem
Organization: HP Response Centre, Berkshire, England.
Distribution: fj
Date: Mon, 20 Jul 1992 12:55:13 GMT
Return-Path: <apollo-list-errors@srvr1.engin.umich.edu>

Hi,

You've got a dreaded E-code, which is a more hardware-ish type of thing 
than the usual OS-type error codes. stcode won't tell you what it means
but I will:

  E1800892     ATR Digital loopback initialize controller RAM failure

Does that help?
ATR = Apollo Token Ring, so probably your ring card is knackered.
Regards,

Dan Bennett.
Newsgroups: fj.mail-lists.apollo
From: agate!spool.mu.edu!news.cs.indiana.edu!mips!sdd.hp.com!apollo.hp.com!netnews@ucbvax.Berkeley.EDU  (Greg Janes)
Subject: Re: Bernie
Organization: Hewlett-Packard Corporation, Chelmsford, MA
Distribution: fj
Date: Thu, 23 Jul 1992 22:26:54 GMT
Return-Path: <apollo-list-errors@srvr1.engin.umich.edu>

Hi:
     If I remember correctly this file was only on Beta
 or early seed units as debugging switch. The existance
 of the file name (it was a empty file) caused the logging
 of system call faults - usually unimplimented UNIX calls.
 I do not believe the OS any longer looks for this file.

 -  Greg Janes

BTW - Bernie Stumpf was is a small plane accident 2 weeks
      ago and is still in the hospital.
Newsgroups: fj.mail-lists.apollo
From: hplextra!hpfcso!mev@hplabs.hpl.hp.com  (Mike Vermeulen)
Subject: Re: an annoying bug in the C compiler ...
Organization: Hewlett-Packard, Fort Collins, CO, USA
Distribution: fj
Date: Thu, 30 Jul 1992 14:48:31 GMT
Return-Path: <apollo-list-errors@srvr1.engin.umich.edu>

The interpretation of the constant -2147483648 is one area that the ANSI C
standard has subtlely changed from many existing implementations.

In the standard, there is no syntax for a negative constant, instead this is
interpreted as a constant expression with a unary - operator over a positive
constant.  Section 3.1.3.2 states that the type of an unsuffixed integer
constant is the first of a list in which its value can be represented.
This list is

   int, long int, unsigned long int

The positive value 2147483648 is one too large for the int or long int type,
so it has type unsigned long int.  A unary - operator applied to an unsigned
long int value of 0x8000000 results in the same bit pattern and has the type
unsigned long int.

This is the reason for the behavior you are seeing.  It is also the reason
header files (on Domain/OS and hp-ux) contain:

	#define INT_MIN (-2147483647-1)

My suggestion would be to alter your program to either use INT_MIN or a similar
expression as above.

--mev

Disclaimer: Not an official response from Hewlett Packard
Newsgroups: fj.mail-lists.apollo
From: thompson@pan.ssec.honeywell.com ((jt) John Thompson)
Subject: re: Favourite DOMAIN/OS features (or mis-features)
Organization: Electrotechnical Laboratory, Tsukuba Science City
Distribution: fj
Date: Tue, 28 Jul 1992 16:04:20 GMT
Return-Path: <apollo-list-errors@srvr1.engin.umich.edu>


Since I've now received 2 e-mails requesting info on the compress filetype at
pre sr10.4 releases, I'm answering to comp.sys.apollo too.


> :)> How do you use the 'compress' feature on DOMAIN/OS? I come from the
> :)> Unix side of the universe and don't use 'typeing features of the
> :)> filesystem.
> 
> :)Compress a file using the standard /usr/ucb/compress routine.
> :)Change the type on it to be compress, by using '/etc/obty pathname... compress'
> :)Use the object.
> 
> John, is this something new to 10.4 or has it been there for a while
> (i.e. 10.3 and up, 10.1 and up) and just one of those things I've had to
> wait years to learn from some reply to a reply on the net?

This is a 10.4 feature.  There is no particular reason that I'm aware of preventing
it from existing at 10.[123], or even at 9.x.  However, it wasn't written then.

>From an implication that I read in to a message, I would have doubts as to whether
you could simply install the new type on a pre-10.4 machine.  You could certainly
do it, but I don't know whether it'd work.  Regardless, I'm not gonna try it.


-- jt --
John Thompson
Design Services Engineer / Sys-Admin
Honeywell, SSEC
Plymouth, MN  55441
thompson@pan.ssec.honeywell.com

What do I know?  I'm just a Token Administrator.
*************************************************************************
* This e-mail correspondence is a work of fiction.  Any similarity      *
* between the views presented and actual views, personal or corporate,  *
* living, dead, or still to be conceived, is pure coincidence.          *
*************************************************************************


Newsgroups: fj.mail-lists.apollo
From: elroy.jpl.nasa.gov!usc!sol.ctr.columbia.edu!titan.ucc.umass.edu!a10j102@ames.arc.nasa.gov  (Matt Kimmel)
Subject: WANTED: Used color Unix/X workstation
Organization: University of Massachusetts, Amherst
Distribution: fj
Date: Thu, 30 Jul 1992 03:40:49 GMT
Return-Path: <apollo-list-errors@srvr1.engin.umich.edu>

I'm looking to buy a used Unix workstation.  I'm interested in a
workstation with a color monitor and hard drive, which includes an
operating system and X windows (or some variation).  Other than those
criteria I'm not too picky.  So, if you're selling such a system, please
e-mail me with the system's specs and an asking price, and maybe we can
work out a deal.

Thanks!
-Matt
-- 
Matt Kimmel            University of Massachusetts              Amherst, MA

Internet: a10j102@titan.ucc.umass.edu
Newsgroups: fj.mail-lists.apollo
From: cis.ohio-state.edu!zaphod.mps.ohio-state.edu!mips!mips!munnari.oz.au!bruce.cs.monash.edu.au!merlin!ianh@ucbvax.Berkeley.EDU  (Ian Hoyle)
Subject: Re: Favourite DOMAIN/OS features (or mis-features) (slow i/o)
Organization: BHP Research - Melbourne Laboratories, AUSTRALIA
Distribution: fj
Date: Sun, 26 Jul 1992 22:25:22 GMT
Return-Path: <apollo-list-errors@srvr1.engin.umich.edu>

rees@dabo.citi.umich.edu (Jim Rees) writes:

>Actually, ios isn't what makes disk io slow.

Then what does??

We have a DN5500 with a (supposedly) fast 700Mb disk acting as a news server
and it just gets appallingly slow whenever it has to do anything that
resembles a lot of i/o eg news unpacking, omniback backups, compress for
news batching etc. In fact it comes close to stopping if these operations
happen to overlap :-(

I'd **luv** to be able to tune _something_ to make it go just a teensy bit
faster,

	ian
--
   /\/\     :  Ian Hoyle,  Senior Research Scientist
  / / /\    :  Image Analysis Group
 / / /  \   :  BHP Research - Melbourne Laboratories
/ / / /\ \  :  245 Wellington Rd, Mulgrave, 3170, AUSTRALIA
\ \/ / / /  :  Phone    +61-3-560-7066
 \  / / /   :  E-mail   ianh@resmel.bhp.com.au
  \/\/\/    :
            : "The kernel IS a continuously running random number
            :  generator" -- Larry Wall
Newsgroups: fj.mail-lists.apollo
From: ogicse!henson!news.u.washington.edu!zeus!davidb@uunet.uu.net  (David W. Barts)
Subject: Re: Favourite DOMAIN/OS features (or mis-features)
Organization: University of Washington
Distribution: fj
Date: Wed, 22 Jul 1992 04:01:06 GMT
Return-Path: <apollo-list-errors@srvr1.engin.umich.edu>


Generally I'm no big Domain/OS fan, but I'll have to agree with this:
In article <199207212228.AA01227@pan.ssec.honeywell.com>, thompson@PAN.SSEC.HONEYWELL.COM ((jt) John Thompson) writes:
> I figured someone else would have mentioned these already....
> 
> o   The keyboard.  Biilllioonnns and biillionnns (sorry C. Sagan) of keys all
>     waiting to be redefined.  I _hate_ having to point and click and pulldown
>     and popup everything.

Especially when compared to the HP standard keyboard (you mean I gotta
type SHIFT-ESCAPE to get ^? -- gimme a break!)

Not to mention the veritable minefield of funky HP-specific keys (that
mess up the terminal if you press them) surrounding the Shift and Return
keys, just waiting for an errant finger to stumble upon them...

--
David Barts  N5JRN                      UW Civil Engineering, FX-10
davidb@zeus.ce.washington.edu           Seattle, WA  98195
    If AT&T is 'Ma Bell', does this make ITT 'Cousin ITT'?
Newsgroups: fj.mail-lists.apollo
From: think.com!paperboy.osf.org!paperboy!drand@ames.arc.nasa.gov  (Douglas Rand)
Subject: Re: C++ V2.1.0 versus OSF/Motif ANSI/NON-ANSI. Help needed
Organization: Open Software Foundation
Distribution: fj
Date: Tue, 21 Jul 1992 20:59:35 GMT
Return-Path: <apollo-list-errors@srvr1.engin.umich.edu>

In article <510@kommu.UUCP> pfander@kommu.UUCP (Dr Gotthard Pfander) writes:

   C++ V2.1.0 as supplied by HP/Apollo uses ANSI-calling convention as default.

   The supplied libraries: libC.a, libOstream.a, ... all expect ANSI-calling.

   Using OSF/Motif, being NON-ANSI as supplied by HP/Apollo,
   thus creates a serious compatibility-problem.

   Using C++ requires at least the library libC.a for the _main an similar things.

   Anyone got a good idea, how to solve this decently.

   Please, don't tell me things like RTFM ....

Oh.  But that's my favorite answer.  Try including the include
files in a extern "C" { ... } block so you get K&R C compliance.  
You might need extern "C--" for some C++ compilers.  Motif 1.1.x
included ANSI prototypes,  so I'm not sure why HP would have 
stripped them.  I'm presuming you're not using Motif 1.0.

--
Douglas S. Rand <drand@osf.org>		OSF/Motif Dev.
Snail:         11 Cambridge Center,  Cambridge,  MA  02142
Disclaimer:    I don't know if OSF agrees with me... let's vote on it.
Amateur Radio: KC1KJ
Newsgroups: fj.mail-lists.apollo
From: mcsun!Germany.EU.net!unido!kommu!pfander@uunet.uu.net  (Dr Gotthard Pfander)
Subject: C++ V2.1.0 versus OSF/Motif ANSI/NON-ANSI. Help needed
Organization: Electrotechnical Laboratory, Tsukuba Science City
Distribution: fj
Date: Tue, 21 Jul 1992 10:01:15 GMT
Return-Path: <apollo-list-errors@srvr1.engin.umich.edu>

C++ V2.1.0 as supplied by HP/Apollo uses ANSI-calling convention as default.

The supplied libraries: libC.a, libOstream.a, ... all expect ANSI-calling.

Using OSF/Motif, being NON-ANSI as supplied by HP/Apollo,
thus creates a serious compatibility-problem.

Using C++ requires at least the library libC.a for the _main an similar things.

Anyone got a good idea, how to solve this decently.

Please, don't tell me things like RTFM ....

pfander@kommu.erls01.siemens.de

Gotthard Pfander
SIEMENS AG, ANL A 593
Werner von Siemens Str. 50
D W8520 Erlangen
Tel +49/9131/7-28711
Newsgroups: fj.mail-lists.apollo
From: mcsun!dxcern!dxcern!bcr@uunet.uu.net  (Bill Riemers)
Subject: Re: compress file type (was: Favourite DOMAIN/OS ...)
Organization: CERN, European Research Center for High Energy Physics
Distribution: fj
Date: Sat, 25 Jul 1992 11:47:22 GMT
Return-Path: <apollo-list-errors@srvr1.engin.umich.edu>

> Compress a file using the standard /usr/ucb/compress routine.
> Change the type on it to be compress, by using '/etc/obty pathname... compress'

a88k:3% /etc/obty stupid.1.Z compress
?(obty) Unable to get type uid for type "compress" - type not found (object based systems/type manager)

Could you elaborate on how to make the compress file type?  Also, please
indicate any steps that require root privledge.  (I can not do these steps myself.)

> Use the object.

Will the files be accessable to fortran programs directly?  (Emacs already uncompresses
text files ...)


                                  Bill
Newsgroups: fj.mail-lists.apollo
From: Andrew F. Gunnesch <afgun@engin.umich.edu>
Subject: rgy weirdness?
Organization: Electrotechnical Laboratory, Tsukuba Science City
Distribution: fj
Date: Thu, 30 Jul 1992 19:23:52 GMT
Return-Path: <apollo-list-errors@srvr1.engin.umich.edu>

I had a registry die on //fleming the other day.  Look at
//fleming/sys/node_data/system_logs/rgyd_error_log

--afgun
Newsgroups: fj.mail-lists.apollo