bobr@zeus.tek.CSNET (Robert Reed) (11/17/86)
** Forwarded Message Follows ** Path: zeus!bobr From: bobr@zeus.UUCP (Robert Reed) Newsgroups: mod.computers.apollo Subject: Domain/IX signals, subprocesses and psuedottys question Date: 13 Nov 86 22:24:32 GMT Reply-To: bobr@zeus.UUCP (Robert Reed) Organization: CAE Systems Division, Tektronix, Inc., Beaverton, OR. Lines: 30 In trying to port a program currently running under UNIX[TM of AT&T] 4.3BSD to Apollo Domain/IX, I've run into a series of hitches. The program forks a shell which execs a program after setting up a pty/tty pair to receive the data. The data is received in the parent process by issuing a select call and then reading from the file descriptors which respond. The parent program has defined a signal handler to catch the death of the child process and initial processing will clean up the select mask. The problem is that the signalling mechanism apparently fails somewhere along the way. The parent program gets caught in a loop where the select fails due to an improper mask (the pty/tty having apparently been closed), and although there are indications that the signal handler has been called, nothing seems to come of its action. Has anyone had any similar experiences? Am I dealing with some sore of Apollo bug? Are there known differences in dealing with Domain/IX processes rather than 4.3BSD processes? Here are some particulars: There is a signal handler instantiated to respond to SIGCLD (the Apollo Child Died signal). Using debug, a breakpoint at the head of this routine is reached if it is the only breakpoint. But if breakpoints are set both here and at the head of the select loop, the signal handler breakpoint is apparently never reached. This particular circumstance sounds almost like a race condition, where interrupts caused by the debugger are sufficient to cause the loss of the signal. I have a call into Apollo central, but so far they've been no help. -- Robert Reed, Tektronix CAE Systems Division, bobr@zeus.TEK ** End Forwarded Message **
hidinger@cod.nosc.arpa@nosc.UUCP (12/04/86)
Path: cod!hidinger From: hidinger@cod.UUCP (Ronald M. Hidinger) Newsgroups: mod.computers.apollo Subject: trapping a full disk Message-ID: <411@cod.UUCP> Date: 3 Dec 86 21:40:19 GMT Organization: Naval Ocean Systems Center, San Diego Lines: 12 I have a program which consumes massive amounts of dynamic memory. The inevitable problem is that the disk fills up and the program stops. It seems the new and rws_$alloc procedures don't detect that the disk is full. The fault occurs when the pointer is dereferenced. I have been able to trap this fault, but I haven't been able to do anything about it. When I dispose of some memory and return from the fault handler with the value pfm_$return_to_faulting_code the process dies without a clue as to what happened. Any suggestions about how to deal with this? sdcsvax!noscvax!hidinger
dennis@cod.nosc.arpa@nosc.UUCP (Dennis Cottel) (12/05/86)
Path: cod!dennis From: dennis@cod.UUCP (Dennis Cottel) Newsgroups: mod.computers.apollo Subject: Experience with DQC connectors? Message-ID: <414@cod.UUCP> Date: 4 Dec 86 23:18:21 GMT Organization: Naval Ocean Systems Center, San Diego Lines: 13 What are the world's experiences with the new DQC connectors (standard equipment on the DN3000s)? Of the first two DQC receptacle boxes we installed, one worked fine while the other was sensitive to position of the connector. Bending up the little tabs in the box (Ugh!) seemed to do the trick, but this gives me a bad feeling. We have more DN3000s coming. I'm wondering if I should just plan on ordering the DSUB-to-BNC adapter cable for each DN3000 and forget the DQC scheme. Dennis Cottel Naval Ocean Systems Center, San Diego, CA 92152 (619) 225-2406 dennis@nosc.ARPA sdcsvax!noscvax!dennis
dennis@cod.nosc.arpa@nosc.UUCP (12/05/86)
Path: cod!dennis From: dennis@cod.UUCP (Dennis Cottel) Newsgroups: mod.computers.apollo Subject: Apollo Modula-2 Message-ID: <415@cod.UUCP> Date: 4 Dec 86 23:24:53 GMT Organization: Naval Ocean Systems Center, San Diego Lines: 14 I recently requested information on any Modula-2 compilers available for the Apollos. There is now a California company selling such a compiler. We have no experience with the product, but I thought I would pass their address along. Djavaheri Brothers 697 Saturn Court Foster City, California 94404 415-341-1768 I have no connection, etc. ... Dennis Cottel Naval Ocean Systems Center, San Diego, CA 92152 (619) 225-2406 dennis@nosc.ARPA sdcsvax!noscvax!dennis
chris@ducall.UUCP ("Christopher C. Brooks") (12/10/86)
Path: ducall!chris From: chris@ducall.UUCP (Christopher C. Brooks) Newsgroups: mod.computers.apollo Subject: Analog-Digital Converters Message-ID: <243@ducall.UUCP> Date: 10 Dec 86 02:23:03 GMT Organization: none Lines: 9 I am currently searching for an anolog to digital converter to be used on an Apollo DN3000 node. The converter will be used for voice and video processing. Has anyone had any experiences with any digitizers (good or bad)? I am presently groping in the dark and would appreciate any words of wisdom. --CCB
don@ducall.UUCP ("Donald C. Mullen") (12/12/86)
Path: ducall!don From: don@ducall.UUCP (Donald C. Mullen) Newsgroups: mod.computers.apollo Subject: Two-byte character discriptors Message-ID: <245@ducall.UUCP> Date: 12 Dec 86 20:57:56 GMT Reply-To: don@ducall.UUCP (Donald C. Mullen) Distribution: usa Organization: Humanities Computing Facility, Duke University Lines: 12 Keywords: foreign characters I'm interested in getting the Apollo DN3000 to use various foreign character sets. Edfont, as is, only supports something like 96 characters per font. Does anyone have any experience in getting font files to contain greater that 128 characters. We'd eventually like to be able to do Chinese, Japanese, and other character sets which are very large. I've heard rumors of some way to get the Apollo to use two-byte character discriptors, but don't know if any of it is true. Can someone help me out. ------------------------------------------------------------------------- Don Mullen UUCP: mcnc!ethos!ducall!don Humanities Computing, Duke University 104 Languages Bldg, Durham NC 27706 (919) 684-3637
chris@ducall.UUCP.UUCP (12/14/86)
Path: ducall!chris
From: chris@ducall.UUCP (Christopher C. Brooks)
Newsgroups: mod.computers.apollo
Subject: Analog-Digital Converters (Correction)
Message-ID: <246@ducall.UUCP>
Date: 13 Dec 86 21:15:01 GMT
Reply-To: chris@ducall.UUCP (Christopher C. Brooks)
Distribution: na
Organization: Humanities Computing Facility, Duke University
Lines: 18
PLEASE POST THIS IN PLACE OF MY PREVIOUS NOTICE, WHICH DID NOT CONTAIN
A REFERENCE ADDRESS. SORRY. CHRIS.
---------------------------------------------------------------------
I am currently looking for an analog to digital converter to
be used on an Apollo 3000 node. The converter will be used for
voice and video processing.
Has anyone had any experiences with any digitizers (good
or bad)? I am presently groping in the dark and would appreciate
any words of wisdom.
-- CCB
>>---------------------------------------------------------------------<<
Chris Brooks UUCP: mcnc!ethos!ducall!chris
Humanities Computing, Duke University
104 Languages Building, Durham NC 27706 (919) 684-3637
-- paul@sdcsvax.ucsd.edu@hp-sdd.UUCP (Paul K Johnson) (01/12/87)
Path: hp-sdd!paul
From: paul@hp-sdd.HP.COM (Paul K Johnson)
Newsgroups: mod.computers.apollo
Subject: Mentor software/Apollo equipment for sale
Keywords: Mentor Apollo for sale
Message-ID: <665@hp-sdd.HP.COM>
Date: 11 Jan 87 21:01:59 GMT
Organization: Hewlett-Packard, San Diego Division
Lines: 30
We have the following Mentor software/Apollo equipment for sale:
Apollo DN560, computational node
-3 MB memory, Sun-Flex antiglare screen
-two - 70 MB disk drives
*software
-Apollo: Aegis 9.2, Domain IX, Unix System V, BSD 4.2, Pascal
-Mentor: Idea 5.1, Quick Fault, Mspice, Piced, TTL, CMOS, PLD,
Quick Parts Builder, Smart Parts Building, HPPlot, Sci-Cards
Apollo DN330, computational node
-3 MB memory, Sun-Flex antiglare screen
-70 MB disk drive, 1.2 MB floppy disk drive
*software
-Apollo: Aegis 9.2
-Mentor: Idea 5.1
Apollo DSP-80, server node
-500 MB disk drive
-9 track, 6250/1600 BPI tape drive
-imagen printer
*software
-Apollo: Aegis 9.2
We currently have this complete system listed for sale at $180k.
Please give me a call for further information:
Paul Johnson
(619) 592-4402mdg%UUCP@YALE.ARPA@cbosgd.MIS.OH.ATT.COM (01/13/87)
Path: cbosgd!mdg From: mdg@cbosgd.ATT.COM (Mike Gale) Newsgroups: mod.computers.apollo Subject: HELP, kermit for Apollo Message-ID: <3244@cbosgd.ATT.COM> Date: 13 Jan 87 12:49:11 GMT Organization: AT&T Bell Laboratories, Columbus, Oh Lines: 20 Keywords: novices lack of info Request for a friend. Does anybody have a copy of kermit for the Apollo. My friend is running Aegis something or other. He said that he had gotten some distribution of kermit but that it wouldn't talk to something else running kermit. Sorry for lack of facts. This is due to his security requirements (that's why he's not on the net) and my lack of knowledge of Apollos. Please send replies or further questions to me. Thank you. Michael D. Gale Consultant for State of the Art Technology at AT&T Bell Labs cbosgd!mdg (614) 860-7417 I would rather do file processing in TECO then COBOL.
dukelow@cod.nosc.arpa@nosc.UUCP (01/13/87)
Path: cod!dukelow From: dukelow@cod.UUCP (Robert A. Dukelow) Newsgroups: mod.computers.apollo Subject: DN3000 I/O hogging Keywords: DN3000 I/O Message-ID: <464@cod.UUCP> Date: 13 Jan 87 15:58:47 GMT Organization: Naval Ocean Systems Center, San Diego Lines: 8 We can't be the only ones that have noticed that disk or cartridge tape I/O on a DN3000 seems to take over the entire machine for extended periods of time. Changing process priorities doesn't seem to help. Is there a solution to the problem? Is this something Apollo is known to be working on? Bob Dukelow (dukelow@nosc.arpa)
krowitz@EDDIE.MIT.EDU@mit-kermit.UUCP (David Krowitz) (01/13/87)
I have noticed the same thing with a DN560 with the 190MB disk drive ... backups (via a tape drive on a DSP80) cause the DN560 to get *very* slow in responding to the keyboard. Programs that are running still seem to be getting CPU time, but issuing new shell or DM commands takes 5 to 10 seconds apiece. Our DN460 and DN660's are nearly as bad when they are being backed up. -- David Krowitz mit-erl!mit-kermit!krowitz@eddie.mit.edu (Apollo, are you listening?)
jph%UUCP@YALE.ARPA@rutgers.UUCP (01/14/87)
Path: eta!jph From: jph@eta.ETA.COM (John P. Hesterberg) Newsgroups: mod.computers.apollo Subject: Re: Kermit for Apollos Message-ID: <8700073@eta.ETA.COM> Date: 14 Jan 87 16:24:55 GMT References: <8701131249.AA20289@cbosgd.MIS.OH.ATT.COM> Reply-To: jph@eta.ETA.COM (John P. Hesterberg) Organization: ETA Systems, Inc., St Paul, MN, USA Lines: 18 In article <8701131249.AA20289@cbosgd.MIS.OH.ATT.COM> mdg%UUCP@YALE.ARPA@cbosgd.MIS.OH.ATT.COM (Mike Gale) writes: >Does anybody have a copy of kermit for the Apollo. My friend is >running Aegis something or other. He said that he had gotten some >distribution of kermit but that it wouldn't talk to something else >running kermit. We use C-Kermit, compiled on DOMAIN/IX. It will run from Aegis, but I suspect that you will need DOMAIN/IX to make it, since you will need support for the DOMAIN/IX system and library calls, not to mention "make". We have used this version to talk to ms-dos kermit, as well as to C-kermit running on a vax and 3b2. It may have also talked to kermit running on NOS, but I'm not sure. -- John Hesterberg USPS: ETA03J, 1450 Energy Park Dr, St Paul, MN 55108 ETA Systems, Inc. UUCP: jph@eta.ETA.COM, {ihnp4,caip}!meccts!eta!jph
i91@seismo.CSS.GOV@nikhefh.UUCP (01/16/87)
Path: nikhefh!i91
From: i91@nikhefh.UUCP (Fons Rademakers)
Newsgroups: mod.computers.apollo
Subject: Need help, read the message.
Message-ID: <246@nikhefh.UUCP>
Date: 16 Jan 87 20:16:52 GMT
Reply-To: i91@nikhefh.UUCP (Fons Rademakers)
Distribution: world
Organization: Nikhef-H, Amsterdam (the Netherlands).
Lines: 32
Hello Apollo experts,
I need some help!
Introductuon to the question:
I made an interprocess communications package using
IPC calls. With this package it is possible to send messages
from one program to another, wait for messages from one or more
programs, etc. The package works basically very nice, also
when the programs are spread over different nodes. However, problems
can occur when one program tries to send something to another
program while that other program is not listening. To prevent
this I could use MUTEX locks as semaphores, i.e. a program may
only send to another program when the semaphore of that program is set.
I also tried the technique of creating/deleting a little file as semaphore,
but this turned out to be very time consuming.
Problem:
With this solution I lose the possibility of running the
programs on different nodes.
Question:
Is there an elegant solution to this problem? If so, let me know.
If not, let me also know.
Thanks in advance,
Fons Rademakers
--
Org: NIKHEF-H, National Institute for Nuclear and High-Energy Physics.
Mail: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands
BITNET: U00029@HASARA5.BITNET Telex: 10262 (hef nl)
UUCP: {decvax,cernvax,uck,unido,vmucnam,seismo}!mcvax!nikhefh!i91miner%UUCP@YALE.ARPA@clyde.ATT.COM (Richard Miner) (01/19/87)
Path: ulowell!miner From: miner@ulowell.cs.ulowell.edu (Richard Miner) Newsgroups: mod.computers.apollo Subject: Need help doing pixels reads/writes on a DN660s, 560s, 550s... Message-ID: <955@ulowell.cs.ulowell.edu> Date: 19 Jan 87 16:01:58 GMT Organization: University of Lowell Lines: 29 We are moving a device independent image processing environment from micros to the Apollos and are having a few problems. The system has three main functional areas that we would display simulataneously: a command line, a menu, and a window with the image. We would like to do this with Apollo windows in display mode. The problem is that there does not seem to be any way to read and write individual pixels to a window in display mode. According to the manuals this can only be done in imaging mode with the display in borrow mode. This unfortunately means no Apollo windows can be used and we would need to do ALL window management ourselves. Is there some sort of library where we can manipulate the bitplane layers of a display window ourselves? Finally, even in imaging mode, block transfers are quick, but individual pixel reads/writes are VERY S-L-O-W. A program to copy a 512x512x24 image using pixel reads/writes took over 15minutes on a DN660, it was a two line loop reading and writing?? I suppose one problem was the 24 bits deep (which we do not need) but it still took too long. Can we get into 1024x1024x8? Documents seem to indicate we cannot. -- Rich Miner ...!wanginst!ulowell!miner Ulowell, Center for Productivity Enhancement (617) 452-5000 x2693 HAL hears the Amiga9000 series is not selling. "Please explain Dave. Why aren't Amiga9000's selling?" Bowman hesitates, "You aren't IBM compatible."
gopstein%UUCP@YALE.ARPA@rutgers.UUCP (01/24/87)
Path: topaz!gopstein
From: gopstein@topaz.RUTGERS.EDU (Richard Gopstein)
Newsgroups: mod.computers.apollo
Subject: Urgent disk help needed
Keywords: disk
Message-ID: <8585@topaz.RUTGERS.EDU>
Date: 23 Jan 87 21:10:22 GMT
Organization: Rutgers Univ., New Brunswick, N.J.
Lines: 41
Help!
I have a DFS-500M (DSP-80A with CDC 500MB drive) which can no
longer be mounted on the system. In particular, the node hangs
when trying to boot from the drive, and when the node is booted
diskless, a mount commands complains "disk data check" and fails.
There are a large number of files in one directory that I
MUST get off of this drive.
I ran fstest in read mode on the entire disk, and found out that
there is a "Hard ECC Error" during read on head 0, cyl 0, sector 1.
There were a couple of other bad sectors reported, but none
were near the beginning of the disk.
I tried running some of the read only options from INVOL, but
they also failed to read the disk.
The Apollo service person found out that a copy of that sector
is kept on the disk, and tried to rewrite sector 1 from the copy
using rwvol. The write suceeds, but subsequent attempts to read
sector 1 still failed with disk data check.
Is there any other hope? I suggested to the service person that
we could mount another disk on the DSP-80 and perform a sector for
sector copy of the bad disk to the good disk, and then restore
sector 1 from the copy on the disk. UNfortunately, I really don't
know how to do a sector for sector copy. Is there some Apollo utility
that might help, or am I going to have to write it? Does anyone even
know how to do absolute sector read/write from aegis?
Thanks in advance for any help.
Rich Gopstein
(201) 685-7337
--
Rich Gopstein
uucp: ...{harvard, seismo, ut-sally, sri-iu, ihnp4!packard}!topaz!gopstein
arpa: GOPSTEIN@RUTGERSnews@seismo.CSS.GOV@bigtex.UUCP (01/29/87)
Path: bigtex!topaz!gopstein
From: gopstein@topaz.RUTGERS.EDU (Richard Gopstein)
Newsgroups: mod.computers.apollo
Subject: Urgent disk help needed
Keywords: disk
Message-ID: <8585@topaz.RUTGERS.EDU>
Date: 23 Jan 87 21:10:22 GMT
Organization: Rutgers Univ., New Brunswick, N.J.
Lines: 41
Help!
I have a DFS-500M (DSP-80A with CDC 500MB drive) which can no
longer be mounted on the system. In particular, the node hangs
when trying to boot from the drive, and when the node is booted
diskless, a mount commands complains "disk data check" and fails.
There are a large number of files in one directory that I
MUST get off of this drive.
I ran fstest in read mode on the entire disk, and found out that
there is a "Hard ECC Error" during read on head 0, cyl 0, sector 1.
There were a couple of other bad sectors reported, but none
were near the beginning of the disk.
I tried running some of the read only options from INVOL, but
they also failed to read the disk.
The Apollo service person found out that a copy of that sector
is kept on the disk, and tried to rewrite sector 1 from the copy
using rwvol. The write suceeds, but subsequent attempts to read
sector 1 still failed with disk data check.
Is there any other hope? I suggested to the service person that
we could mount another disk on the DSP-80 and perform a sector for
sector copy of the bad disk to the good disk, and then restore
sector 1 from the copy on the disk. UNfortunately, I really don't
know how to do a sector for sector copy. Is there some Apollo utility
that might help, or am I going to have to write it? Does anyone even
know how to do absolute sector read/write from aegis?
Thanks in advance for any help.
Rich Gopstein
(201) 685-7337
--
Rich Gopstein
uucp: ...{harvard, seismo, ut-sally, sri-iu, ihnp4!packard}!topaz!gopstein
arpa: GOPSTEIN@RUTGERSbobr@zeus.tek.com.UUCP (01/31/87)
Path: zeus!bobr From: bobr@zeus.TEK.COM (Robert Reed) Newsgroups: mod.computers.apollo Subject: Re: CAPS LOCK Message-ID: <1174@zeus.TEK.COM> Date: 30 Jan 87 21:55:05 GMT References: <8701292300.AA03506@yale-eli.YALE.ARPA> Reply-To: bobr@zeus.UUCP (Robert Reed) Organization: CAE Systems Division, Tektronix Inc., Beaverton OR Lines: 8 I think that Apollo keyboards in general are poorly engineered. I hadn't run into a keyboard with contact bounce for YEARS--until I recently started using a low profile DN300 keyboard. I hadn't SEEN a keyboard using the archaic REPEAT key--until I started using an Apollo. The 3000 doesn't seem to have corrected the latter problem. I haven't used the 3000 enough to notice whether the contact bounce has been fixed. -- Robert Reed, Tektronix CAE Systems Division, bobr@zeus.TEK
hucka@UTAH-CS.ARPA.UUCP (02/02/87)
In article <8701302155.AA15447@zeus.TEK> bobr@zeus.tek.com (Robert Reed) writes: > >I think that Apollo keyboards in general are poorly engineered. I hadn't >run into a keyboard with contact bounce for YEARS--until I recently started >using a low profile DN300 keyboard. I hadn't SEEN a keyboard using the >archaic REPEAT key--until I started using an Apollo. The 3000 doesn't seem >to have corrected the latter problem. I haven't used the 3000 enough to >notice whether the contact bounce has been fixed. I must admit I was surprised to see a <REPEAT> key on a keyboard when I first began using Apollo systems, but since getting used to it I find it's one of best things about them (and it's very easy to get used to that key). It gives you much better control over your keyboard and speeds input, because when <REPEAT> is held down the other keys repeat *immediately*, unlike regular keyboards where there is a noticeable pause between the time you press the key and the time it begins to repeat. I now always miss this feature when I must use other keyboards. The keyboard bounce is indeed an annoyance. I gather it was only present on older DN3xx machines; at Utah we have a mix of Apollos, and the newer DN3xx and DN3000 have no bounce and no metallic click. Mike -- */\/\ Michael Hucka, PASS Research Group, University of Utah /\ /\ /\ / \/\ {ihnp4, decvax}!utah-cs!hucka hucka@utah-cs.ARPA / \/\/ \/ \
cantrell@cae780.tek.com.UUCP (02/04/87)
Path: cae780!cantrell From: cantrell@cae780.TEK.COM (Keith Cantrell) Newsgroups: mod.computers.apollo Subject: Re: Caps Lock Message-ID: <3415@cae780.TEK.COM> Date: 4 Feb 87 15:02:12 GMT References: <8702020403.AA14439@nlm-mcs.arpa.ARPA> Reply-To: cantrell@cae780.UUCP (Keith Cantrell) Organization: Tektronix, Inc., Beaverton, OR. Lines: 28 In article <8702020403.AA14439@nlm-mcs.arpa.ARPA> martin%NLM-MCS.ARPA@tektronix.tek.com (Brian Martin) writes: >I agree. The CAPS LOCK key is poorly placed, and I find it especially annoying >when in an editor such as vi where caps make a distinct difference in what >function the editor performs. I also think that the repeat key is a bad >idea. > >Brian K. Martin I don't what you all are talking about, the CAPS LOCK key is put in the same place as any typewriter. The only thing that I don't like about the CAPS LOCK on the DN3000 keyboard is that it doesn't stay down when it is on, and therefore you can not just reach over to it and feel if it is on or not. Keith Cantrell ---------------------------------------------------------------- FROM: Keith Cantrell, CAE Systems Division of Tektronix, Inc. UUCP: tektronix!cae780!cantrell {ihnp4, decvax!decwrl}!amdcad!cae780!cantrell {hplabs, resonex, qubix, leadsv}!cae780!cantrell USMAIL: 8111 L.B.J. Freeway Suite 655 Dallas, Texas 75251 AT&T: 214-669-8161 ----------------------------------------------------------------
bobr@zeus.tek.com.UUCP (02/04/87)
Path: zeus!bobr From: bobr@zeus.TEK.COM (Robert Reed) Newsgroups: mod.computers.apollo Subject: Re: Bouncy key boards Message-ID: <1193@zeus.TEK.COM> Date: 4 Feb 87 20:48:21 GMT References: <870202145758.270266@HI-MULTICS.ARPA> Reply-To: bobr@zeus.UUCP (Robert Reed) Organization: CAE Systems Division, Tektronix Inc., Beaverton OR Lines: 14 In article <870202145758.270266@HI-MULTICS.ARPA> Winkler@HI-MULTICS.ARPA writes: >Apollo keyboards bounce. All switches bounce. This is a subject near >to my heart since I'm one of the original heavy handed typists. The >answer to my prayer would be the ability to set keyboard sensitivities. >Actualy what one would want to set would be the delay between key >repeats. Some Apollo keyboards do bounce. Some switches do bounce. That does not mean that all keyboards do bounce. Keyboard debouncing circuits have been used in some keyboards FOR YEARS! (Try to get keyboard bounce out of any Tektronix keyboard). This has nothing to do with key repeat rate. It's the difference between microseconds and miliseconds. -- Robert Reed, Tektronix CAE Systems Division, bobr@zeus.TEK
bobr@zeus.tek.com.UUCP (02/05/87)
Path: zeus!bobr
From: bobr@zeus.TEK.COM (Robert Reed)
Newsgroups: mod.computers.apollo
Subject: Re: Submission for mod-computers-apollo
Message-ID: <1194@zeus.TEK.COM>
Date: 4 Feb 87 21:00:57 GMT
References: <8701302155.AA15447@zeus.TEK> <8702021823.AA24187@utah-cs.ARPA>
Reply-To: bobr@zeus.UUCP (Robert Reed)
Organization: CAE Systems Division, Tektronix Inc., Beaverton OR
Lines: 27
In article <8702021823.AA24187@utah-cs.ARPA> utah-cs!hucka (Michael Hucka) writes:
I must admit I was surprised to see a <REPEAT> key on a keyboard when I
first began using Apollo systems, but since getting used to it I find
it's one of best things about them (and it's very easy to get used to
that key).
I am happy for you that you have been able to adapt so easily. For my part,
I don't think that I will. Repeating a control key (such as ^F or ^B) is
such an awkward endevor (little finger of left hand holding down both
control and repeat keys while index finger of same hand holds down the F or
B) that I doubt I'll ever get used to it. This is a fairly frequent
occupation when using an editor other than then toy editor Apollo calls the
Pad Editor.
It gives you much better control over your keyboard and speeds input,
because when <REPEAT> is held down the other keys repeat *immediately*,
unlike regular keyboards where there is a noticeable pause between the
time you press the key and the time it begins to repeat. I now always
miss this feature when I must use other keyboards.
I have never had trouble with the delay before key repeat. The delay is an
essential feature, allowing character entry without key doubling, and
providing a simple mechanism for repeated keys without requiring additional
action by the user.
--
Robert Reed, Tektronix CAE Systems Division, bobr@zeus.TEKminer%UUCP@YALE.ARPA@rutgers.UUCP (02/08/87)
Path: ulowell!miner From: miner@ulowell.cs.ulowell.edu (Richard Miner) Newsgroups: mod.computers.apollo Subject: Communicating over ethernet to non-apollo systems. Message-ID: <1023@ulowell.cs.ulowell.edu> Date: 8 Feb 87 15:01:54 GMT Organization: University of Lowell Lines: 24 I have seen demos between Apollos and other systems, such as the TI-explorer, that demonstrate the ability to communicate over ethernet. My favorite it the net-work bouncing ball demo, but between completely different systems like the two mentioned above. We are going to be receiving some ethernet boards for several souped-up Commodore Amiga workstations I would like to develop and demonstrate an ability to closely couple these systems with our 30+ node apollo network. Once Apollo gets their NFS out the door (soon I hear) we will be able to move files around; but getting remote processes to communicate is also a goal. Does anyone one know what routines and protocalls I would need to support remote process communication on the Amiga? Should these routines be suplied with my ethernet card? Are there sources available for the Apollo specific routines? I believe that there is source for network-balls, would it need to be changed much once I had the proper software up on the Amiga? Thanks, -- Rich Miner ...!wanginst!ulowell!miner Ulowell, Center for Productivity Enhancement (617) 452-5000 x2693 HAL hears the Amiga9000 series is not selling. "Please explain Dave. Why aren't Amiga9000's selling?" Bowman hesitates, "You aren't IBM compatible."
cod:dennis@nosc.UUCP.UUCP (02/25/87)
Path: cod!dennis
From: dennis@cod.UUCP (Dennis Cottel)
Newsgroups: mod.computers.apollo
Subject: remote backups
Message-ID: <518@cod.UUCP>
Date: 24 Feb 87 22:50:52 GMT
Organization: Naval Ocean Systems Center, San Diego
Lines: 20
I would like to backup our Apollo file systems to our central VAX BSD
4.3 UNIX machines where we have a large tape library and operators
available at night who will retrieve, mount, and store the tapes. We
are connected via TCP/IP/COM-ETH, the DOMAIN/IX r-commands work, but
where is rdump?
A call to Apollo brought the reply that "they don't support that
command," as well as a comment that it couldn't be ported because the
Apollo file system is too different. Why is this? Or has someone
ported rdump to the Apollos? Why isn't it included with DOMAIN/IX?
Apollo suggested that I use tar and pipe the output to "rsh dd" on the
VAX. However, tar can't select files by modification date. WBAK knows
about file modification dates, but you can't make WBAK write to the
standard output. I know everyone's got backup problems--has anyone tried
to do something similar to this?
Dennis Cottel Naval Ocean Systems Center, San Diego, CA 92152
(619) 225-2406 dennis@NOSC.MIL sdcsvax!noscvax!dennistimj@tekchips.tek.com.UUCP (03/02/87)
Path: tekchips!timj From: timj@tekchips.TEK.COM (Tim Johnson) Newsgroups: mod.computers.apollo Subject: Backup across TCP/IP Keywords: backup Message-ID: <1091@tekchips.TEK.COM> Date: 2 Mar 87 16:25:34 GMT Distribution: na Organization: Tektronix Inc., Beaverton, Or. Lines: 40 I do not advise using 'tar | rsh dd' for backing up files on the Apollos. I was warned that characters can be lost. Sure enough when I went back and tried to read some of my backup tapes, tar was very unhappy with me. The occurance of these errors is a function of the load on the TCP/IP network when the backup is being done. I am presently VERY selectively backing up to cartridge tape ( I have 1.2 GIG of mass storage ). Apollo seems to be accepting the fact that in order for them to survive their machines must operate in a non-homogeneous environment and are begining to face up to problems such as backing-up across the TCP/IP network. In our situation we have lots of UNIX and VMS systems with a several small (3-5nodes)networks of Apollos. There is no way we can rationalize spending the bucks for a 9-track for three of four machines even though they typically have .5 - 1.5 GIG of disk. We do have two larger Apollo networks (>30 nodes) that have their own 9-track. All of these rings are physically and politically separated and therefore cannot share 9-tracks. The response I got from Apollo ranged from don't be so damn cheap (the old Apollo folks speaking) to asking what our exesting environment is and what to we need to solve the the problem (hopefully the new Apollo speaking). By the way I came from a UNIX world and I find wbak a real joy to use and hope Apollo enhances it to write to a socket. A server could be started over on the HOST the could read from this socket and preserve the blocking factor. A person familar with sockets could write this tool in a day. The hard part is what to do about non BSD hosts that don't support sockets. I just hope Apollo sees fit to release the easy part rather than wait for years to find the `ideal solution'. I suppose just a version of wbak that writes to standard out would allow me to write the server on the host no matter what OS it was running. Maybe Apollo should just distribute sources for utilities such as wbak- but then that is a whole other issue. Tim Johnson Tektronix Beaverton, Oregon
weber_w@EDDIE.MIT.EDU@apollo.UUCP (03/04/87)
dennis@nosc.UUCP (Dennis Cottel) writes: >Message-ID: <518@cod.UUCP> >Date: 24 Feb 87 22:50:52 GMT > >I would like to backup our Apollo file systems to our central VAX BSD >... >... >................................................... Or has someone >ported rdump to the Apollos? Why isn't it included with DOMAIN/IX? Nat Mishkin answered this well in another article. >Apollo suggested that I use tar and pipe the output to "rsh dd" on the >VAX. However, tar can't select files by modification date. OK, then, how about using find(1) with the appropriate arguments and shoving the list of files to /sys5/bin/cpio , which would then rsh the dd to the tape? Granted, cpio is sys5 specific, but this should work correctly.
i91@seismo.CSS.GOV@nikhefh.UUCP (Fons Rademakers) (03/06/87)
Path: nikhefh!i91
From: i91@nikhefh.UUCP (Fons Rademakers)
Newsgroups: mod.computers.apollo
Subject: DOMAIN/IX Unix and inlib -> crash!!!
Message-ID: <257@nikhefh.UUCP>
Date: 6 Mar 87 16:23:41 GMT
Reply-To: i91@nikhefh.UUCP (Fons Rademakers)
Distribution: world
Organization: Nikhef-H, Amsterdam (the Netherlands).
Lines: 81
Could somebody (from Apollo) tell me why the following
crashes Apollo's Unix (csh and Bourne):
Compile these two little routines:
==========================================
subroutine c1
common // b(5)
print *, 'c1: b(1)= ', b(1)
print *, 'c1: b(5)= ', b(5)
call c2
return
end
subroutine c2
common // c(5)
print *, 'c2: c(1)= ', c(1)
print *, 'c2: c(5)= ', c(5)
c(1) = 111
c(5) = 111
return
end
==========================================
Compile this little main program:
==========================================
*
*-- main program to intialize static data
*
common // b(5)
print *, 'blank common initialized'
stop
end
==========================================
Make an installed library from these three
routines:
==========================================
#! /bin/sh
bind -b foo.inlib -<<\!
main.bin
-looks -all
-marks -all
-allmark
c1.bin
!
==========================================
Install the library (in DOMAIN/IX Unix):
==========================================
inlib foo.inlib
==========================================
And flash, super crash.
Note, in the Aegis (/com/sh) this works fine.
BTW, the contents of the two little routines
does not matter. The only problem is the main program that
initializes the static data. Remove the main program
(and change the routine c1 so it uses a parameter to get
its value for b) and everything works well.
I am running SR9.2.4 and inprocess is set in the csh.
Is this a BUG or a feature???
Cheers,
Fons Rademakers
--
Org: NIKHEF-H, National Institute for Nuclear and High-Energy Physics.
Mail: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands
BITNET: U00029@HASARA5.BITNET Telex: 10262 (hef nl)
UUCP: {decvax,cernvax,uck,unido,vmucnam,seismo}!mcvax!nikhefh!i91haroldt@teklds.tek.com.UUCP (03/07/87)
Path: teklds!haroldt From: haroldt@teklds.TEK.COM (Harold Trollinger) Newsgroups: mod.computers.apollo Subject: Vt100 emulator Message-ID: <3244@teklds.TEK.COM> Date: 6 Mar 87 21:24:13 GMT Distribution: na Organization: Tektronix Inc., Beaverton, Or. Lines: 9 I have been having problems getting my DN3000 to emulate a vt100 through the sio1 line. It appears that command vt100, then emt in raw mode should work but the next line gets just a LF instead of CRLF. What am I doing wrong? Is there a different program like emt that is vt100 compatable? Thanks Haroldt
whna@cgcha.UUCP.UUCP (04/02/87)
Path: cgcha!whna From: whna@cgcha.UUCP (Heinz Naef) Newsgroups: mod.computers.apollo,comp.dcom.lans Subject: attaching apollo workstations to universal cabling system Keywords: apollo, domain, ring, cabling system. Message-ID: <315@cgcha.UUCP> Date: 2 Apr 87 16:09:48 GMT Organization: CIBA-GEIGY AG, FO/WIRZ/WRZ, CH-4002 Basel, Switzerland Lines: 7 Would it be possible to attach Apollo workstations to a universal cabling system (such as the one designed by IBM, etc) instead of using Apollo's own domain ring cabling hardware? If yes, which companies offer baluns for this purpose? Any experiences, or just hints? Please contact me via e-mail. Thanks, Heinz Naef.
wb@gamma.UUCP.UUCP (04/03/87)
Path: gamma!wb From: wb@gamma.UUCP (Bill Beblo) Newsgroups: mod.computers.apollo Subject: Re: TCP/IP Problems Summary: We have experienced the same problems. Apollo is aware of what is happening, but is unable to guarantee a fix for SR9.5 Message-ID: <371@gamma.UUCP> Date: 3 Apr 87 20:40:42 GMT References: <630*northover@cascade.carleton.cdn> Organization: Bellcore, Livingston, NJ Lines: 50 In article <630*northover@cascade.carleton.cdn>, northover@cascade.carleton.CDN (Stephen Northover) writes: > > Hi. I have just installed TCP/IP on our Apollo ring and have come across > the following bizzare behavior. From the gateway node, it is possible to access > external sites. From any node on the ring, it is possible to access any other > node on the ring. From a non-gateway node, it is NOT possible to access any external > sites. The error message indicates a timeout. > > Has anybody else seen this? > > Thanks in advance, > Steve Northover > <northover@cascade.carleton.cdn> I am running a ring of 24 Apollo nodes with a COM-ETH gateway on a DSP160. After installing TCP/IP version 2.1, I noticed that we'd be unable to make connections via the gateway after a few days. The network to which the Apollo ring was gatewayed was connected via point-to-point link (using local serial line IP code) to another network. Thinking the local code might be playing a factor, I lived with reinitializing TCP/IP on the gateway every few days since this link was going to disappear soon. We replaced the link with a Vitalink Translan bridge to a backbone network. Immediately, our MTTF on the Apollo gateway dropped to 5 minutes. Assuming a great increase in the number of broadcast packets received with the bridge replacing the point-to-point link and seeing a huge (>3000) number of rwho packets in the Rcv-Q when the gateway crashed, I decided not to run the rwhod on the gateway. MTTF increased to a few hours. At this point we called in Apollo. We discovered that the routed on the Apollo gateway was crashing. Although it would continue to receive routing packets from the network and maintains it's internal routing table, Apollo routed would cease to send out it's routing information. It was failing with some sort of an I/O error which Apollo reps clearly saw. Although the Apollo gateway could get to the requested node, the node could not get back to Apollo, hence the connection time out. We are currently running with static routing on the Apollo and static additions for the Apollo gateway on our non-Apollo nodes. Apollo cannot guarantee that this problem would be resolved in TCP/IP 3.0 which will be released in conjunction with SR9.5. As we will be installing SR9.5 soon after it arrives, I will post an update soon after the installation. Bill Beblo Bell Communications Research 290 West Mt. Pleasant Ave., Rm 1D-148 Livingston, New Jersey 07039 (201) 740-4421
usenet@gec-rl-hrc.co.UK.UUCP (04/09/87)
Path: hrc63!amrik From: amrik@hrc63.co.uk (Amrik Thethi) Newsgroups: mod.computers.apollo Subject: test Keywords: test Message-ID: <110@hrc63.co.uk> Date: 9 Apr 87 13:31:25 GMT Organization: GEC Hirst Research Centre, Wembley, England. Lines: 2 test.
i91@nikhefh.UUCP.UUCP (04/12/87)
Path: nikhefh!i91
From: i91@nikhefh.UUCP (Fons Rademakers)
Newsgroups: mod.computers.apollo
Subject: When can I get X through ADUS?
Message-ID: <262@nikhefh.UUCP>
Date: 12 Apr 87 14:45:02 GMT
Reply-To: i91@nikhefh.UUCP (Fons Rademakers)
Distribution: world
Organization: Nikhef-H, Amsterdam (the Netherlands).
Lines: 15
I mail this to the apollo newgroup since adus@apollo does not react.
Could somebody maybe tell me when I can order the X-window system
for the Apollo from ADUS? And could that somebody tell me the ADUS
address and what the costs of the tape will be?
Regards, Fons Rademakers.
--
Org: NIKHEF-H, National Institute for Nuclear and High-Energy Physics.
Mail: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands
BITNET: U00029@HASARA5.BITNET Telex: 10262 (hef nl)
UUCP: {decvax,cernvax,uck,unido,vmucnam,seismo}!mcvax!nikhefh!i91