HDTenEightyP/NetNews huggingface dataset:
From: dbrown@tron.bwi.wec.com (Darryl Brown)
Subject: Re: Colour maps on DN4500 (again??)
Organization: Westinghouse Electric Corporation, Baltimore MD.
Date: Wed, 9 Sep 1992 20:19:54 GMT


> <S9209041457.AA28091@uk.ac.aberdeen.sysc> writes
> We have a DN4500 running SR10.3 (no patches) which has an 8 plane
> 19 inch colour monitor.

> The command "lcm" was typed in at one of the pads and this changed
> the colour map. The question is, how do I get it back to "normal".


       I experienced what seems to be the same problem with mixed-up
colors on a DN4500 when I swapped the mono display out of it for an
8-plane color monitor.  
     At the time the machine was running SR 10.1.  I noticed that
all of the reds and blues were swapped on the display, and that lcm
did not change anything.  My solution was to swap the red and blue
BNC cables on the back of the monitor so the Red wire goes to the
Blue input and vice-versa.  It is still running with the same
mis-configuration under SR 10.3.      

                               -Darryl Brown
-- 
#  Darryl K. Brown  |  brown@sky00.tron.bwi.wec.com             #
#  Westinghouse ESG |                                           #
#  Baltimore, MD    |                                           #
Newsgroups: comp.sys.apollo
From: wonga@steam.chem.su.oz.au (Adrian Wong)
Subject: Strange login behaviour
Organization: Dept. of Theoretical Chemistry, University of Sydney
X-Newsreader: Tin 1.1 PL5
Date: Thu, 10 Sep 1992 06:05:21 GMT

We have recently upgraded to 10.4 and OCCASIONALLY when we login
the shell is not able to exec anything (except built-in shell commands).
Thus 'cd' works but 'ls' fails with the error message 

'ls : Command not found.'

Even '/bin/ls' fails.
However subshells do work, e.g.
'(cd /bin ; ./ls )'
works fine.

What's happened? I suspect it's specifically a C-shell problem, because
when I use Korn shell it's never occurred.


-----------------------------------------------------------------------------
Adrian Wong, Dept.of Theoretical Chemistry     wong_a@summer.chem.su.oz.au
University of Sydney NSW 2006 Australia        061-2-692 4137
From: kgallagh@digi.lonestar.org (Kevin Gallagher)
Newsgroups: comp.sys.apollo
Subject: Re: rz/sz doesn't work on our machines
Date: 8 Sep 92 18:12:02 GMT
Organization: DSC Communications Corp, Plano, TX

In article <1992Sep04.184127.17533@edsi.plexus.COM> chuck@edsi.plexus.COM (Chuck Tomasi) writes:
>We're running mostly DN3550/DN4500/DN5500 machines on our site (with a
>few 425Ts) under Domain/OS 10.3.5.  We compiled the rz/sz sources with
>SYSTYPE=sys5.3 and everything appeared to go alright.  The problem is
>that they don't work.  The same sources work fine from an HP-UX v8.0
>machine however it seems that something is being blocked or trapped when
>we invoke them from the Domain machines.

I compiled the rz/sz sources under Domain/OS 10.3.0.8 on a DN3550 in SYSTYPE
bsd4.3.  I connect from my PC at home to my Apollo through a DECserver to a
VAX (running VMS) and from the VAX to the Apollo via telnet.  The connection
turns out to be very robust.  The modem runs at 2400 baud.  On the PC, I use
Crosstalk Mk.4, the latest version,  using the build-in implementation of
ZMODEM. 

I can upload files from my Apollo node to my PC by invoking the sz command at
the Unix shell prompt.  The transfer rate is outstanding at around 232
characters per second.  However, I can't get the rz command to download files
from my PC to my Apollo.  I do suspect the ZMODEM implementation in Crosstalk
is, at least, partially at fault, but I can't be sure.  The version of Kermit
we have installed doesn't handle downloads to the Apollo as well as it handles
uploads.  We have to use smaller packets when downloading than when uploading,
and download failures happen often.  So it is possible that there is something
about the Apollo that causes problems here.


-- 
----------------------------------------------------------------------------
Kevin Gallagher        kgallagh@digi.lonestar.org OR ...!uunet!digi!kgallagh
DSC Communications Corporation   Addr: MS 152, 1000 Coit Rd, Plano, TX 75075
----------------------------------------------------------------------------
Newsgroups: comp.sys.apollo
From: levesque@mprgate.mpr.ca (Steve Levesque)
Subject: Help Changing Network Numbers.
Organization: MPR Teltech Ltd., Burnaby, B.C., Canada
Date: Wed, 9 Sep 92 23:13:55 GMT

We have a network of about 25 apollo stations and I have to split them
into two totally seperate rings, so they don't see each other at all.

Because they are currently on both ethernet and token ring, we have two 
seperate network numbers, so I will have to change the network number on 
one of the networks back to 0.

Reading the "Managing Domain O/S and Domain Routing in an Internet" manual,
it first tells me to make sure I have a slave registry somewhere on the 
new network (network 0), and then make it the master after the split. 

Rather than waiting and using the slave and deleting all the uneccessary
accounts after the split, I used rgy_create to create a new registry,
and tried to make all the necessary accounts before the split.

To do this I ran rgyd on the Soon To Be Master node, but didn't tell
any of the other machines about this new registry, and then ran edrgy,
and set my site to this S.T.B.M. node.

However, when I tried to add a new account or to change the properties it said:

"Unable to add "whatever" - Not authorized to perform operation (RGYC/Server)"

Even though I did this as root. 

Any Ideas? Should I be able to do this?

Also, has anybody out there changed network numbers before?

Does the book tell all, or are there some unwritten surprises?



Any help would be appreciated.


Steve Levesque
From: culmer@uoft02.utoledo.edu
Newsgroups: comp.sys.apollo
Subject: DN4500 Problems
Date: 14 Sep 92 13:36:30 EST
Organization: University of Toledo, Computer Services

I have problems.  We have two apollo DN4500's running OS10.2.

When I try logging into one of them, the pad automatically
closes.  Also, when I try to pop a new pad, I get nothing
except a warning message:  (CP) $(shell) - file not found.

When I try to access the apollo through telnet, I connect,
then get kicked out with the message: telnetd:  All network
ports in use.

The second apollo seems to be working fine.  I can access the
first apollo's disk and directory structure by simply changing
directory to that node, I just cannot seem to log into it
directly.  Does anyone have any ideas as to what I might try?

Thanks,
Chuck Ulmer (culmer@uoft02.utoledo.edu)
D.A.Smith Group
University of Toledo
Toledo, OH.
From: wjw@ebh.eb.ele.tue.nl (Willem Jan Withagen)
Newsgroups: comp.sys.apollo
Subject: Re: XDR on Apollos?
Date: 11 Sep 92 11:27:13 GMT
Organization: Eindhoven University of Technology, The Netherlands

In article <13074@ztivax.UUCP> paulisch@ztivax.UUCP (Dr. Frances Paulisch) writes:
=>I have an application which uses the XDR routines to save data in an 
=>efficient, (supposedly) machine-independent binary format.  Upon porting 
=>it to our Apollo workstations (DN3000), we noticed that the XDR include 
=>files and system calls are not available on our Apollo systems.
=>
=>Does anyone know whether the XDR routines are, in fact, available on 
=>Apollo? If not, does anyone know of public-domain version of the 
=>XDR-routines which we could then port ourselves?

Sun make it's RPC libraries freely available in source form.
We required it to be able to compile the PC-NFS daemons.

I retrieved ours from ftp.uu.net. I'm sorry that I can't give you the 
original directory.

The versions with small modifications for APOLLO are available in:
	ftp.eb.ele.tue.nl:/pub/apollo/tcp/sunrpc3.9a.tar.Z
	ftp.eb.ele.tue.nl:/pub/apollo/tcp/sunrpc4.0.zip

(for the last one you can find the unzip exec in:
	ftp.eb.ele.tue.nl:/pub/local/bin/unzip
)

	Willem Jan


Digital Information Systems Group, Room EH 10.35 
Eindhoven University of Technology   
P.O. 513                     		Tel: +31-40-473401,Fax: +31-40-448375
5600 MB Eindhoven            		The Netherlands
Xref: sparky comp.sys.apollo:3477 comp.sys.hp:10113
From: sartin@88opensi.88open.ORG (Rob Sartin)
Newsgroups: comp.sys.apollo,comp.sys.hp
Subject: Re: Strange packaging technique
Date: 5 Sep 92 21:07:47 GMT
Reply-To: sartin@88opensi.UUCP (Rob Sartin)
Organization: 88open Consortium Ltd., San Jose

In article <0ylnpl#.snow@netcom.com> snow@netcom.com (Tim Szeliga) writes:
>"HP P/N 19511-80014".  

Ahh, yes, the Eagle shipping braces.  I got one that had a defect
(knot hole) and we called up to see if there was a repair/replace kit
or service manual.  We were aghast to discover that there was NO SUPPORT
for this HP product!

Rob
From: hall@bcstec.ca.boeing.com (Robert J. Hall)
Newsgroups: comp.sys.apollo
Subject: Apollo Password Problem
Date: 4 Sep 92 19:00:35 GMT
Organization: Boeing Computer Services, Seattle


I'm trying to write a custom screen lock program on the HP/Apollo for
my group. This program requires the user to enter their correct pass-
word in order to release the display. The password is then encrypted
and compared to the encrypted password in /etc/passwd. Unfortunately,
this method doesn't seem to work consistently on the Apollo. It works
for some accounts, but not others. I've got a sneaking suspicion that
it's because the encrypted password in the /etc/passwd file does not
match the one in the registry.

Has anyone else figured out a workaround, or way to fix this problem?
Here's a code snippet of the program I'm using to check the password:

----snip----snip----snip----snip----snip----snip----snip----snip----

	extern struct passwd *getpwent();
	struct passwd *pwent;
	unsigned int uid;
	int result;

	/* Initialization */
	result = FALSE;

	/* Rewind the password file */
	setpwent();

	/* Get the UID of this process */
	uid = getuid();

	/* Get the account password */
	pwent = getpwuid(uid);

	/* Compare the passwords */
	if ( strcmp( pwent->pw_passwd, (char *)crypt( input, pwent->pw_passwd ) ) == 0 )
		result = TRUE;

	/* Close the password file */
	endpwent();

----snip----snip----snip----snip----snip----snip----snip----snip----

The 'input' string is the user's (hidden) password input. Thanks for
any information you can provide.

-- 
 Bob Hall,                 | "If at first you don't succeed, try, try again.
 Workstation Peripheral    | Then give up. No use being a damn fool about it."
 Boeing Computer Services  |                                     -Groucho Marx
Newsgroups: comp.sys.apollo
From: pmarriot@nyx.cs.du.edu (Paul Marriott)
Subject: Diskless 9000/400 won't boot off DN4500 anymore
Organization: Nyx, Public Access Unix @ U. of Denver Math/CS dept.
Date: Wed, 9 Sep 92 13:44:51 GMT

Yesterday, we had our DN4500 crash. After running salvol etc. everything
rebooted without any problems. However, we have a 9000/400dl booted
diskless off the 4500 and now it refuses to boot. It gets as far as loading
in DOMAIN_OS but fails when it tries to create the /sys/node_data.nodeid
directory. It gives the error message:

81270001 Boot error UID request failed
NO DEVICE FOUND

stcode 81270001 gives
operation attempted on unopened stream (stream manager/IOS)

Doing a pst on the 4500 reveals a zombie process forked from netman. A
traceback of this process gives: 

tb 5B102C18.D002C83F 
Process        1102 (parent 1065, group 0)
Time           92/09/09.11:02(MET)
Program        //vlsi01/install/ri.apollo.os.v.10.3/bsd4.3/bin/sh
Status         00040004: reference to illegal address (OS/MST manager)
In routine     "dfile_$pre_fork" line 171
Called from    "ios_$pre_fork" line 97
Called from    "pm_$fork" line 2407
Called from    "fork" line 99
Called from    "execute" line 405
Called from    "execute" line 580
Called from    "exfile" line 256
Called from    "main" line 146
Called from    "unix_$main" line 114
Called from    "_start" line 132
Called from    "PM_$CALL" line 176
Called from    "pgm_$load_run" line 903
Called from    "pgm_$invoke_uid_pn" line 1124

where process 1065 is netman

Any clues as to what the problem is? The ownership of the node_data.nodeid
directory seems ok

Please mail me at paul@zeus.ci.ua.pt as I don't use the account this was
posted from very much.

Cheers,

Paul.
From: jrp%telford@aberdeen.ac.uk (jrp, J.R.Penny)
Newsgroups: comp.sys.apollo
Subject: Soln. to colour map problem
Date: 9 Sep 92 11:25:54 GMT
Organization: The Internet


The connections to the monitor at the back of the Apollo were pushed in the wrong way.

The person in question insisted that the colours suddenly changed while using the machine.
This should obviously have been interpreted as he suddenly noticed that the colours had changed!
Perhaps I should ignore what I'm told happpened/what the problem is/.....


Thanks to those who replied.

Jon Penny
j.r.penny@aberdeen.ac.uk
Newsgroups: comp.sys.apollo
From: lampi@polari.online.com
Subject: Re: 3rd Party Hard Disks for Apollo's
Organization: R Squared, Redmond, WA (206) 883-3116
Distribution: usa
Date: Wed, 9 Sep 1992 18:09:31 GMT

In article <1992Sep3.203424.28298@iscnvx.lmsc.lockheed.com> hecke@iscnvx.lmsc.lockheed.com (Peter M. Hecke) writes:
>I am interested in adding non-HP 1.3 Gbyte hard drives to a
>HP/Apollo 425t, 425s, and DN10000 workstations.  I am looking
>for non-HP disks in order to keep the cost of the disks down.
>
>The 425t has two 200 MByte internal drives, so I plan to buy
>an HP model 660D Mass Storage System.  I would then buy a 1.3
>GByte drive and install it into the 660D.
>

I'd recommend getting the complete external disk system from the 3rd party,
rather than piecing together the HP cabinetry & 3rd party gear. You are
more likely to get a working solution this way (in general).

>The 425s was purchased with a 1.3 GByte (HP) disk and I wish
>to install another disk.
>
>The DN10000 has one 697 Mbyte internal drive and I would like
>to add a 1.3 GByte drive onto the single controller.
>
>My questions are as follows:
>
>  1.  What non-HP 1.3 GByte drives are compatible with the
>      above mentioned machines and configurations?

The DN-10K requires ESDI drives; the others require SCSI drives.
Most SCSI drives will work (if adjusted appropriately) on the 425t/s, so
I'd go with the ones that fit your price/performance/support requirements.
The Seagate Elite 1's and Fujitsu 2652's are higher performing drives in
this category, and the HP 97560 isn't too bad, either.
>
>  2.  What hardware (ie: screws, mounts, etc) if any do I
>      need to mount the drives?

4 screws are needed to mount disks inside the 425s, cables & screws &
mounts are required for the DN-10K and for the 660D (if you go that way).
Of course, your 3rd party should include these with their products, along
with a handy "How To" manual :-)

>  3.  Should I expect any compatibility problems between the
>      HP and non-HP hardware?

If there are, then I'd suggest that the 3rd party doesn't really have a
product to sell.

>  4.  What 3rd party vendors sell hard disk upgrades for the
>      above mentioned Apollo's?

The FAQ list has several vendors listed (but seems to forget about me :-().

>  5.  Is there anyone out there in net land that has had
>      some experience with adding disks to their Apollo's?

Most certainly "yes"!

-- 
-----
+-+  Michael Lampi       lampi@polari.online.com
|R|  R Squared           16398 NE 85th St., Suite 101, Redmond, WA 98052
+-+                      (206) 883-3116       fax (206) 883-2676
Xref: sparky comp.sys.apollo:3516 comp.sys.hp:10265
From: vds7789@aw2.fsl.ca.boeing.com (Vincent D. Skahan)
Newsgroups: comp.sys.apollo,comp.sys.hp
Subject: Re: diskless 425e off 425s
Date: 10 Sep 92 17:41:14 GMT
Distribution: usa
Organization: none

yywang@magnus.acs.ohio-state.edu (Yong-Yi Wang) writes:

>I am trying to run a diskless HP/Apollo 425e off a HP/Apollo 425s.
>The OS on the 425s is SR 10.3.4. We also have a diskless 425t off the
>same 425s using the token ring. Now the 425e only has ethernet. When
>we tried to boot the 425e off the 425s, the 425s did not repond to
>the boot (call).

>The 425s is on the outside network using its ethernet card. 
>(So the ethernet on the 425s seems to be OK.)
>However, the principle network on the 425s is token ring.

>My question is:

>Given the token ring as the principal network and the ethernet as
>the secondary network, is it possilbe to boot the 425e and the 425t
>off the 425s at the same time? (There is no problem to boot the 425t 
>as it stands now.)

>Another note:

>To boot the 425e off the 425s, we tried to switch the 
>principal network to ethernet. Then the 425s did not boot. 
>(Well, it went through all the self-tests, loaded the OS and the 
>local files. However, the window did not come up.)


I'm not sure I understand your setup completely, but basically
my understanding is that you can boot a node of any node on
your ATR network, regardless of the media you're using (ethernet
or coax or...)

are you really running the 425t with *token ring* on the ethernet
and token ring on the ring interface ? In other words, if you
type 'lcnet', do you see two distinct networks (one for eth and
one for the token ring) ?
-- 
   ---------   Vince Skahan   -----------   vince@atc.boeing.com   ---------   
	I've finally realized that if you throw enough money and bodies
	at non-existant problems, that they really do appear...
Newsgroups: comp.sys.apollo
From: kylscott@mksol.dseg.ti.com (kyl w scott)
Subject:  sendmail: daemon owner of /usr/spool/mail entries
Organization: Texas Instruments Inc
Distribution: usa
Date: Fri, 11 Sep 1992 19:40:17 GMT

The problem appears to have been caused by /bin/mail no
longer have root + setuid.  Thanks...


-Kyl

Newsgroups: comp.sys.apollo
From: szabo_p@maths.su.oz.au (Paul Szabo)
Subject: Re: 425e: diskless -> disked ?? SOLVED
Keywords: 425e internal SCSI cable
Reply-To: szabo_p@maths.su.oz.au (Paul Szabo)
Organization: Mathematics, University of Sydney
Date: Mon, 7 Sep 1992 02:32:10 GMT

What a fool I am! In article <1992Sep7.003730.9234@ucc.su.OZ.AU> I wrote
about the trouble I had creating a disked 425e. I then descibed the exact
same symptoms as reported in article <9112231551.AA07041@gw1.ags.bnl.gov> by
roger@GW1.AGS.BNL.GOV (Roger A. Katz). While I did not see any followup on
that, I blissfully ignored article <do.696638606@oberon.css.beckman.com> by
do@oberon.css.beckman.com (Hung Do):
> A couple months back, I posted a problem I had with connecting a Maxtor LXT-213
> (200MB) 3.5" disk to a 425e. It turned out that HP had thrown us a curved ball:
> the pin-1 mark for the scsi connector on our diskless 425e is reversed (the
> actual pin 1 is the pin closest to the power supply). Many thanks to Mike Lampi
> at R-Squared who has helped us pin-pointed :-) the problem.

In summary (to save even bigger fools as me from themselves, if any exist):

The internal SCSI cable in 425e's is back-to-front. To make one of these,
you start with a perfectly good SCSI cable, which has pin 1 on one plug
connected to pin 1 on the other. Then you 'shave' off the little bump on one
of the connectors and plug it in 'upside down'. Voila!

Now if only I could understand why HP has done it... then I would quit my
job and seek employment with them.

Paul Szabo - System Manager   //        School of Mathematics and Statistics
szabo_p@maths.su.oz.au        //   University of Sydney, NSW 2006, Australia
Newsgroups: comp.sys.apollo,comp.sys.hp
From: lampi@polari.online.com
Subject: Call for HW/Peripherals SIG Members
Summary: We need just a few more active people to be "legal"
Keywords: InterWorks SIG
Organization: R Squared, Redmond, WA (206) 883-3116
Date: Fri, 4 Sep 1992 18:37:00 GMT

At InterWorks the Hardware and Peripherals SIG got off to a good start. We're
planning to produce articles for "The Works" on such hot topics as who has
what products for HP, HP/Apollo and Apollo computers, which products work
(according to *real* users), and in what directions HP should head with its
various products (e.g., increasing disk logical volume size from 4GB to 2TB,
for both HP-UX and Domain/OS; *supporting* - not just working with - 8mm
tape drives and 1/4" tape drives on HP-UX on 400's, 700's and 800's; etc.).

We need more people to commit to being active in this SIG over the next
year in order for it to be a 'valid' InterWorks Special Interest Group.

Please send your name, contact information, etc., to David Krowitz at
quake.mit.edu!krowitz or to me at lampi@polari.online.com

Thank you!

-- 
-----
+-+  Michael Lampi       lampi@polari.online.com
|R|  R Squared           16398 NE 85th St., Suite 101, Redmond, WA 98052
+-+                      (206) 883-3116       fax (206) 883-2676
Newsgroups: comp.sys.apollo,comp.sys.sun.apps
From: berliner@rmtc.Central.Sun.COM (Brian Berliner)
Subject: Re: rsh dump
Organization: Sun Microsystems, Inc.
Distribution: usa
Date: Sat, 12 Sep 92 17:31:04 GMT

In <1992Sep11.221138.22934@auto-trol.com> jacsch@auto-trol.com (Jack Schetrom) writes:
>This has occurred on more than one sparc station running
>4.1.2 (or from an HP/apollo node running X-windows) where
>the dump requires more than one ctape to complete
>the dump. If the command is run on the node where the ctape
>is physically attached, it also fails.
>If the coomand does not require more than one ctape for the
>dump, all runs OK.

>It seems that the problem lies in how the display is handled.

>Does anyone know of a patch/workaround/fix for this?

The only "fix" for this is to purchase the Sun Backup Copilot 1.0 product.
It includes a dump replacement program that knows how to communicate with a
new networked operator monitor.  When your remote dump hits end-of-tape, it
doesn't belch as you describe.  Instead, it connects to the only display it
has (the network monitor, that is) and you can answer the prompts from
there.  The same holds true for the restore program.  Backup Copilot, of
course, includes much more than this.

	-Brian
From: philip@cel.cummins.com (Philip D. Pokorny)
Newsgroups: comp.sys.apollo
Subject: Re: strange program behavior
Date: 15 Sep 92 19:05:15 GMT
Organization: The Internet

Thanks for all those that responded with suggestions on how a program might
write to the pad after a vt100 emulator was started on-top of it.

The vendor selling the software found the problem.  It seems that they were
dup() ing  the stdout stream and then latter calling tgetent (a termio
initialization routine)  It appears that tgetent tests to see whether stdout
is a DM PAD and if so, starts a vt100 window on the pad and then REPLACES
stdout with a connection to the vt100 pty.  Because the product dup'd stdout
and was writing to the old stream, the output was going to the pad and not
the vt100 emulator.  Moving the tgetent call before the dup solves the problem
as does not dup'ing stdout at all.

Thanks again for the input.

Sincerely,
Philip D. Pokorny
philip@cel.cummins.com
:)
From: dan@hpwin052.uksr.hp.com (Dan Bennett)
Date: Tue, 8 Sep 1992 10:28:07 GMT
Subject: Re: Colour maps on DN4500 (again??)
Organization: HP Response Centre, Berkshire, England.
Newsgroups: comp.sys.apollo

Hi,

Just to point out that the rs -f and rs -o business is probably your
solution. At 10.2 (I think) colour map management was changed to accommodate
the 400 series PVRX displays (true colour emulation). The issue is that
although lcm -p filename DOES load the colourmap according to your colourmap
file, the allocation of WHICH colour does WHAT in the slots 1-15 as used
by the Display Manager. rs -o seems to be the thing that reorders the slot
allocation as expected.

Dan Bennett.