HDTenEightyP/NetNews huggingface dataset:
From: chuck@edsi.plexus.COM (Chuck Tomasi)
Newsgroups: comp.sys.apollo
Subject: Re: Favourite DOMAIN/OS features (or mis-features)
Date: 22 Jul 92 22:07:16 GMT
Article-I.D.: edsi.1992Jul22.220716.22331
Organization: Enterprise Data Systems Incorporated, Appleton WI

ced@APOLLO.HP.COM (Carl Davidson) writes:

:)|> My biggest gripe about Domain was in dealing with nodes on an internet
:)|> (not THE internet, just a site that had net IDs.)

:)Fixed in SR10.4. 

Someone is getting a Christmas card from me for thinking up this one.
Much thanks to whoever is responsible for doing away with one major
annoyance in my life.

Then again in 18 months I won't have but a handful of the DN machines I
have today.  What a pity.
-- 
Chuck Tomasi             |     "Mom, it's Data.  I heard you know
chuck@edsi.plexus.COM    |      how to turn him on." 
spool!cserver!edsi!chuck |                    -Wesley  "Datalore"
------<Enterprise Data Systems Incorporated, Appleton Wisconsin>------
From: xx123yyy@cardinal.ksu.ksu.edu (Brian Gregory Howard)
Newsgroups: comp.sys.apollo
Subject: Re: Narcoleptic DN10000
Date: 21 Jul 1992 16:18:16 -0500
Organization: Kansas State University
NNTP-Posting-Host: cardinal.ksu.ksu.edu

system@alchemy.chem.utoronto.ca (System Admin (Mike Peterson)) writes:

>In article <9207151318.AA00876@ievalts.aeem.iastate.edu> root@IEVALTS.AEEM.IASTATE.EDU (John O. Ievalts - The Rocket) writes:
>>
>>I appear to have a single processor DN10000 that is suffering from
>>something that resembles narcolepsy in humans.  The machine will
>>periodically, with no provocation, just shut down.  The shutdowns
>>are *not* catalogued so that the "lsyserr" command can  detect them.
>>The machine can just be sitting there, idling, and suddenly the 
>>screen is dark and the machine is quiet, as if the power were turned
>>off.  The breaker on the back is okay.  I can turn it on by hiiting
>>the power switch on the front and it comes back to life.  It doesn't
>>even want to do a salvol.

>You almost certainly have the flaky power supply problem, and/or your
>power supply is a few "bricks short of a full load" if your DN10000 is
>quite old. This problem, and the solution (other than calling HP
>hardware support if you have it, which we always did when this
>happened), should go onto the FAQ.

Not to long ago, I had a capacitor die in our DN 10000.  Since then, the silly
machine was up and down like a yo-yo.  It would stay "on-line" no longer than
two hours before the "5V undervoltage" light would come on, and the DN10000
would go off.

As a bold measure, I dipped a little of the compound shown below on each pin
of each "power brick" and fired the DN10000 up.  It has been one week since
then (not one hour).  I even used the computer to backup our network today! It
hasn't been long enough to say how well this idea will work, but this could be
something to try for the needy sys-admins (without maint. support) out there.

	DN10000 saving compound (I hope)

	CRAMOLIN (R)
	R-100L
	CAIG Laboratories
	PO. Box J
	Escondido Ca 92025

WARNING:  I can not guarentee that ANY the above information is correct.
          (I'm just a $5/hour student - what do I know!)

		Good-Luck

			Brian G. Howard
			brian@grace.ecc.ksu.edu
			xx123yyy@matt.ksu.ksu.edu
Newsgroups: comp.sys.apollo
From: pato@apollo.HP.COM (Joe Pato)
Subject: Re: Changing registries
Date: Thu, 30 Jul 1992 14:06:37 GMT
Organization: Hewlett-Packard Company, Chelmsford, MA
Keywords: rgyadm

In article <5357@naucse.cse.nau.edu>, jdc@naucse.cse.nau.edu (John Campbell) writes:
|> This is possibly easy, but I've read the man pages and experimented
|> enough to be pretty frustrated...
|> 
|> I acquired three apollos (res, ind, cap) from another department.
|> These ran with the master registry on res.  I want to join these three 
|> machines to the existing network of four four other apollos (hyd, oxy, 
|> car, nit) where car holds the master registry.  
|> 
|> None of the accounts (or user files) are needed from the old machines.
|> It would be "perfect" if I could simply get them to accept that the
|> master registry was now on car instead of res.  However, the procedures I've
|> read seem to involve copying and not replacing master registries.  I
|> naively hoped stopping glbd on res would "magically" let everyone find
|> the new master registery.
|> 
|> Fiddling with rgy_admin and trying to permanently change the master
|> (change_master) doesn't seem to work.  I get "current master is unknown,
|> default host: unspecified".   /com/lcnode reports all the above machines 
|> just fine.  They are all catalogued properly (I believe).  Right now, 
|> I've stopped glbd and rgyd on res.  This means every log in currently
|> uses local registry and fails to find a global server.
|> 
|> What do I need to do to get res, ind, and cap to use car as the registry
|> master?
|> -- 
|> 	John Campbell               jdc@naucse.cse.nau.edu
|>                                     CAMPBELL@NAUVAX.UCC.NAU.EDU

The procedures that are documented for merging networks assume that
you want to preserve the user base from the old environment.  This 
appears to not be the case for you.  In general what you have done
(killing the glbd and rgyd for the now defunct network) should be
enough.  If the machines do not find the new registry (the registry
on //car, then it is probably because either one or the other or
both of the previously independent networks were running as unique
glbd "cells".

Normally all Domain/OS machines look for a glbd running with a
well known universal unique identifier (UUID).  If you want to run
multiple "logically independent" domain networks on a common physical
network, it becomes necessary to introduce a per-logical network UUID
for each glbd.  This is stored in the file /etc/ncs/glb_obj.txt on each
machine of the logical network.

You should check your machines and verify that //res //ind and //cap contain
a file that is identical with the glb_obj.txt file on the rest of the 
machines (or none if the other machines did not have one).

-- 
                    -- Joe Pato
                       Distributed Object Computing Program / East
                       Hewlett-Packard Company
                       pato@apollo.hp.com
From: hkarhune@hydra.Helsinki.FI (Heikki Karhunen)
Newsgroups: comp.sys.apollo
Subject: A minor oddity in 10.4's XR4 server
Date: 24 Jul 92 18:59:10 GMT
Distribution: comp.sys.apollo
Organization: Department of Theoretical Physics, University of Helsinki,
	Finland

While tinkering with a HP9000/710 and Clarity Rapport we have on loan,
I noticed a minor annoyance in the 10.4's X server.

I mailed a document to a friend on an Apollo from Clarity Rapport
using FrameMaker's MIF format for all the artsy bits (actually the
_only_ graphical object in the test document was a rectangle with
rounded corners). The friend got it and opened it in Frame.

The texts in the document survived the transferral unscathed, but the
rectangle with the rounded corner (it was filled, too) lost a corner.

Actually the rectangle's outline was unbroken, but the filling inside
lacked the upper right hand corner. How odd, we thought and started
experimenting. No, the reason was not in Clarity, the document looked
all right when it left Clarity. No, the problem was not with the Frame
either, as we run Frame from the same Apollo to the HP9000/710's
screen and the document was all right. 

But when we tried to draw similar rectangles with rounded corners on
the Apollo we invariably lost the upper right hand corner's color.

Something similar happened with the filled arcs. Here is a crude
reconstruction of a pair of malformed arcs:


    XXXXXXX*                   X#########*######## 
       ###XXXXX      	       X################## 
       #######XXX    	        X################# 
    *  #########XX * 	       * XX###########*### 
       ###########X  	          XXX############# 
       ############X 	            XXXXX######### 
       #####*######X 	                X*XXXXX   

Ummh... the # is the fill color, X is the edge of the arc and *'s are
the resize handles.

Then we took out the Sniffer and took a little peek at the traffic going
around in the net. As one drew a rounded rectangle, Frame sent all the
necessary bits and pieces as it should to the X server which dutifully
managed to lose the last piece of information, the upper right hand
corner's filling.

Anyone else managed to get surprised with this?

Oh, by the way, we tried it out with both the borrowed mode X server
(about R2+) and the native R4 server, and the Apollo we experimented
with is DN3000 with 8 Megs of memory and 1280x1024 black and white
display.

	Heikki Karhunen

/-----------------------------+-----------------------------------------\
| hkarhune@kruuna.helsinki.fi | There is always a job for a theoretical |
| Heikki.Karhunen@helsinki.fi | physicist -- at least in theory.        |
\-----------------------------+-----------------------------------------/
Newsgroups: comp.sys.apollo
From: janes_g@apollo.hp.com (Greg Janes)
Subject: Re: Bernie
Date: Thu, 23 Jul 1992 22:26:54 GMT
Organization: Hewlett-Packard Corporation, Chelmsford, MA
Keywords: dn10000

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.
From: eba0@kete.kete (Bob Bunting)
Newsgroups: comp.sys.apollo
Subject: Seeking discussion on TCP/IP between IBM and HP/Apollo
Date: 28 Jul 92 15:01:38 GMT
Reply-To: bbunting@iworks.ecn.uiowa.edu
Distribution: world
Organization: The Internet


Seeking discussion on TCP/IP between IBM and HP/Apollo

We are trying to set up TCP/IP between our HP/Apollo network and
our IBM Mainframe and would like to discuss som issues with
others who have already done this. Our network is currently 
made up of a variety of Domain/OS machines but we are getting
ready to add HP-UX and hope to access IBm from both platforms
semi transparently. Direct E-mail responses are preferred and please
include if you plan to attend the IWORKS meeting in New Orleans.

                               Thanks,
                                        Bob Bunting
                                        bbunting@iworks.ecn.uiowa.edu
                                        EBDiv/GD

Newsgroups: comp.sys.apollo
From: roc@apollo.HP.COM (R. O. Curtis)
Subject: Re: Favourite DOMAIN/OS features (or mis-features)
Date: Thu, 23 Jul 1992 19:16:28 GMT
Distribution: na
Organization: Hewlett-Packard Company, Chelmsford, MA

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
From: thompson@PAN.SSEC.HONEYWELL.COM ((jt) John Thompson)
Newsgroups: comp.sys.apollo
Subject: re: Upgrade DN3550?
Date: 23 Jul 92 16:04:49 GMT
Organization: The Internet



> <<forwarded message>>
> I am currently running two DN3550s.  One has OS 10.3.1 and I have
> put OS 10.4 on the other.  I have contacted HP/Apollo's help line and
> they suggested that I upgrade my systems to a DN5500 for more power.
> 
> If anyone has been through this process, could you please let me know
> how it went, and any bugs/problems I should be prepared to deal with.

(This is personal opinion / flame )
Why would ANYONE want to do this???!!!  HP has successfully chopped the
neck off the DN5500, to the point that they're giving people half their
money back!  It is a machine with no future, no significant past, and
nobody who wants to maintain its present.


Now, that said, if you _REALIZE_ that you have Domain/OS 10.4 as the
high point of your future, and you _REALIZE_ that the machine will be 
less and less supported as more people throw them out and go to 425s, 
433s, and 7xx machines, and you _STILL_ want the added speed that the
68040 gives to this system, please think again.

If you are staying with Domain/OS for a long time, consider the 900/4xx
series instead.  They have an upgrade path to the 700 series (for the
eventual plunge), have the same speed, and will get OSF capabilities
put on them.

If you want to chuck it all, consider the 9000/7xx machines, or <gasp>
other vendors' product lines.  This fall looks like a fun time in the
workstation market, as everyone brings out the next line of "my stuff
is fastest" machines.


-- 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: comp.sys.apollo
From: rees@dabo.citi.umich.edu (Jim Rees)
Subject: Re: Favourite DOMAIN/OS features (or mis-features)
Reply-To: Jim.Rees@umich.edu
Organization: University of Michigan IFS Project
Date: Sat, 25 Jul 1992 15:22:41 GMT

In article <1992Jul23.080828.23127@eurotherm.co.uk>, nc00@eurotherm.co.uk (Neil Corlett) writes:

  How do you use the 'compress' feature on DOMAIN/OS?

Use 'compress' to compress the file, then change its type (with obty) to
'compress'.

I've got a compress type manager that runs on pre-sr10.4 systems, but I
don't know if it's redistributable.

  * I think the typed filesystem is a nice feature
    but you pay for it with desparately [sic] slow reading and writing from
    disk.

Actually, ios isn't what makes disk io slow.
Newsgroups: comp.sys.apollo
From: rees@pisa.citi.umich.edu (Jim Rees)
Subject: re: Favourite DOMAIN/OS features (or mis-features)
Reply-To: Jim.Rees@umich.edu
Organization: University of Michigan IFS Project
Date: Wed, 29 Jul 1992 14:00:30 GMT

In article <199207281604.AA11993@pan.ssec.honeywell.com>, thompson@PAN.SSEC.HONEYWELL.COM ((jt) John Thompson) writes:

  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.

It's actually been around for a while, but didn't make it into the release
until 10.4.  I would be very surprised if the 10.4 compress type manager
didn't work on 10.3.  It might work on 10.2, but probably not on 10.1
or before without recompiling.
From: unruh@physics.ubc.ca (William Unruh)
Subject: Apollo 2500 BW monitor died
Summary: Apollo 2500 monitor died
Keywords: Apollo 2500, monitor
Organization: University of British Columbia, Vancouver, B.C., Canada
Date: Tue, 28 Jul 1992 23:40:03 GMT

 The BW 15(?) inch monitor on one of our Apollo 2500's died yesterday-
 no image at all even when you sewitch it on or off there is no flash 
 (Yes it is plugged in- the on off light comes on). Does anyone have
 scematics for the beast or knwo where a cheap one can be had?
 Bill Unruh
 unruh@physics.ubc
From: bmcm@beech.lle.rochester.edu (Brian McMaster)
Newsgroups: comp.sys.apollo
Subject: BZONE on the Spark or PC
Date: 23 Jul 92 17:15:05 GMT
Reply-To: bmcm@beech.lle.rochester.edu (Brian McMaster)
Organization: UofR Laboratory for Laser Energetics

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)
From: alanc@ocf.berkeley.edu (Alan Coopersmith)
Newsgroups: comp.sys.apollo
Subject: Re: compress file type (was: Favourite DOMAIN/OS ...)
Date: 25 Jul 1992 19:23:10 GMT
Organization: U.C. Bezerkeley Overloaded Computing Facility
NNTP-Posting-Host: hailstorm.berkeley.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: comp.sys.apollo
From: bshaw@bobasun.hc.ti.com (Bob Shaw)
Subject: bitmap to PostScript converter ?
Organization: Texas Instruments
Date: Fri, 24 Jul 1992 22:29:36 GMT


At one time, I had a util to convert Apollo bitmaps to PostScript.
I no longer have this .  If anyone has this and would email it to
me, it would be much appreciated.

This would be Apollo OS 10.3 

Thanks in advance

Bob
bshaw@hc.ti.com
From: alanc@ocf.berkeley.edu (Alan Coopersmith)
Newsgroups: comp.sys.apollo
Subject: Problems with 10.4
Date: 23 Jul 1992 00:39:36 GMT
Organization: U.C. Bezerkeley Overloaded Computing Facility
Distribution: world
Reply-To: alanc@ocf.berkeley.edu
NNTP-Posting-Host: ocf.berkeley.edu
Summary: Woes caused by the panacea of all our 10.3 woes

We recently finished upgrading our cluster of 16 machines (2 DN 4500's + 14
3500's) to 10.4 - and since then we've been having several problems:

- csh/tcsh will go into a "can't find any commands" mood, from which the only
	way to do anything is exec /bin/ksh.  (It seems to be linked to the
	tty's as some tty's have the problem & others don't...rebuilding the
	tty's "cures" the problem for a few days, but then it comes back)

- processes aren't dying properly.  For example a user telnet's in, and
	starts reading news.  The telnet will die, but it's child csh and the
	trn will keep going.  In fact, the last process in the chain will
	start using huge amounts of processor time.  The only solution we've
	found for this so far is to check the process table every 10 minutes
	and kill -HUP every process who's unix_PPID is 1 (and is not owned
	by root/daemon/user/etc.)  kill(-9, -1) is also failing at times.

- vuelogin/Xdomain keeps complaining about:
	"InitShareExt: Can't initialize extension"

Any suggestions on how to fix these?  

-- 
------------------------------------------------------------------------
Alan Coopersmith			Internet: alanc@ocf.berkeley.edu
University of California, Berkeley	Bitnet:   alanc@UCBOCF.BITNET
Newsgroups: comp.sys.apollo
From: braham@physics.ubc.ca (Stephen Braham)
Subject: WANTED: X11R4 Server binaries for 10.2
Keywords: X11R4 server
Organization: University of British Columbia, Vancouver, B.C., Canada
Date: Tue, 28 Jul 1992 17:31:35 GMT

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  |
From: uhl@oracle (Walter Uhl)
Newsgroups: comp.sys.apollo
Subject: Re: Mtools on Apollo
Date: 27 Jul 92 16:47:29 GMT
X-Newsreader: Tin 1.1 PL4

afgun@engin.umich.edu (Andrew F. Gunnesch) writes:
: In article <1992Jul21.122116.22999@rhrk.uni-kl.de> uch024@zx1.hrz.uni-dortmund.de writes:
: >Well, i encountered the problem when i tried to compile the mtools.
: >So what is the device one should use for mtools.
: >
: >?(mtvol) Unable to mount volume - no right to perform operation 
: >(OS/ACL manageer)
: >
: 
: It looks like you aren't trying to mtvol as root, and you aren't in
: the ACL listing of `node_data/node_owners.  Try having your sysadmin
: add you to the ACL on that file, and see if the mtvol works then.
: -- 
: ===============================================================================
: Andrew F. Gunnesch          |  Evil CAEN sysadmin   |  I'm a Sun worshipper
: afgun@caen.engin.umich.edu  |What?  I just work here|  not a DEC dog.......
: ==============================================================================

I am not sure why mtvol is being used while attempting to execute any of the
MTOOL tools.  Programs like mdir or mread should access the floppy drive
directly through /dev/fda? as is coded in devices.c before the program is 
compiled.  

Going back to my original posting,  I get an initialize failure when attemping
to mdir a dos floppy.  I was wondering, because we use an ESDI controller, if
the out-of-the-box source must be modified.  And if it must be modified,  what 
should I be looking to add?

Thanks again

Walter Paul Uhl

email  uhl@solaria.hac.com


Newsgroups: comp.sys.apollo
From: ganek@apollo.hp.com (Dan Ganek)
Subject: Re: Favourite DOMAIN/OS features (or mis-features)
Date: Wed, 22 Jul 1992 15:38:34 GMT
Organization: Hewlett-Packard Corporation, Chelmsford, MA

>>>   Recent versions of GPR have the mouse handling screwed up. Try playing
>>>   "star wars" on a DN3500 to see what I mean.
>>                                 
>>HUh??? Explain, please.
>
>The easist way to see what's going in is to play Revenaugh's Star Wars on
>a DN580 and then try it on a DN3500. The difference should be immediately
>noticable. The 3500 (and other newer models) buffer the mouse input
>"incorrectly".
>
>The problem is that gpr_$cond_event_wait will return a gpr_$no_event
>even when there is still mouse information in the buffer. Graphics-intensive
>programs such as Star Wars therefore have the response to mouse input
>lagging behind the actual mouse movements. The program believes that it
>

First, where can I get a copy of the program? For investigation purpose
only, of course :-)

Second, keeping in mind that I haven't seen the code nor do I have ANY
idea of the expertise of the author, but this sound like the classic 
mistake that EVERYONE seems to make when first using eventcounts. (Yours
truely included). i.e.

instead of the correct sequence, or some CYCLIC variation thereof
   
    REPEAT
      ec2_$wait(..);
      ec2_$read(..);
      xxx_$cond_event_wait(...);       
      process_event(...);
      UNTIL tired;

the programmer uses something like::

    REPEAT
      ec2_$wait(..);
      xxx_$cond_event_wait(...);       
      {an event can be queued HERE before the ec2_$read but after the cond_event_wait}
      ec2_$read(..);                   
      process_event(...);
      UNTIL tired;  

On slower machines or machines with less memory , i.e. a 580,
the probability of queueing an event is significantly less. 

There is no difference in input event processing on any of the 
machine types.

/dan ganek
ganek@apollo.hp.com



Newsgroups: comp.sys.m68k