barriost@gtephx.UUCP (Tim Barrios) (05/11/89)
We are a large Apollo site (about 700 nodes) running 9.7.1
(soon to be 10.1) Domain/IX. We use primarily Unix Sys V
since we are now part of an ATT JV.
Our users use generic Sys V mail and mailx. For the last
year or so, more and more of our users have been using
the USENET network mail and news but determining the relative
address path of another site has been a matter of 'grep'ing
the output of a mailpath based on the map and using that
address in the mail/mailx command line.
I had heard good things about the Elm mailer which would let
our users get automatic net addressing via <user>@<node>
addressing. So, we installed Elm on a test basis about
a month ago. We have very mixed reviews of it running
on Apollo. First, it seems to lock up the mail file now and
then (especially using newmail) which disallows other users from
adding to the mailbox (all 700 nodes are linked to one /usr/mail dir).
More serious is that recently, we have noticed that when
reading volutile mail files (more than 20 messages while
10 or so new ones come in while reading), our users can lose
their entire mailbox with the error 'mail file corrupt'
(this morning i lost over 60 mail messages)!
Here's the questions I have for other Apollo Sys 5 users:
Does anyone have positive/negative comments about using Elm on Apollo?
Is there another mail system that is better than mailx for Apollo?
I've heard about 'smail'. Is this available for Apollo? What's
different about it v.s. mailx and Elm?
What do other Apollo users use to send/receive network mail?
--
Tim Barrios (barriost@gtephx)
UUCP: {ncar!noao!asuvax | uunet!zardoz!hrc | att}!gtephx!barriost
AGCS (formerly GTE), Phoenix
(602) 582-7101nazgul@apollo.COM (Kee Hinckley) (05/16/89)
In article <43290411.f81c@gtephx.UUCP> barriost@gtephx.UUCP (Tim Barrios) writes: >We are a large Apollo site (about 700 nodes) running 9.7.1 >(soon to be 10.1) Domain/IX. We use primarily Unix Sys V >since we are now part of an ATT JV. ... >adding to the mailbox (all 700 nodes are linked to one /usr/mail dir). This is really not a good idea. Very few mail programs check to make sure that their 'write()'s succeed. If the network gets flakey, or something else goes wrong you could easily lose your entire mailbox. In addition you have the cost of 700 users beating on a single directory every few minutes checking to see if there is new mail. With that said I don't have any really good answers however. The best alternative is probably a series of distributed postoffices using sendmail to handle delivery, however the setup and configuration of such a system will probably be non-trivial at the least. In general however, Elm has a very good reputation, particularly in sites where people are not real familiar with Email. Other PD mailers which should also work include Mush (Mail Users SHell), mh (Mail Handler?), xmh (X-based version of same), and mm (??). -kee -- ### User Environment, Apollo Computer Inc. ### Public Access ProLine BBS ### ### {mit-eddie,yale}!apollo!nazgul ### nazgul@pro-angmar.cts.com ### ### nazgul@apollo.com ### (617) 641-3722 300/1200/2400 ### I'm not sure which upsets me more; that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's.
okamoto@hpccc.HP.COM (Jeff Okamoto) (05/18/89)
barriost@gtephx.UUCP (Tim Barrios) asks: [ Questions about Elm ]: Disclaimer: I am only an engineer within HP. I do not support Elm. First question: Which version of Elm did you install? The latest USENET version is 2.2, which Syd Weinstein et al are supporting. If you have an earlier version (e.g., 1.5b, 1.7, 2.0, 2.01), then I'm afraid you're pretty much on your own. They are not supported by HP. Second question: How well does your implementation of NFS (I assume that's what you have?) support file locking? Elm tries to use either flock or lockf, plus creating a lock file. Some versions of NFS are not very robust w.r.t. file locking. Please let me know if you have any more questions. -- \ oo The New Number Who, \____|\mm Jeff Okamoto //_//\ \_\ HP Corporate Computing Center /K-9/ \/_/ okamoto%hpccc@hplabs.hp.com /___/_____\ ..!hplabs!hpccc!okamoto ----------- (415) 857-6236
nlouie@hpirs.HP.COM (Nancy Louie) (05/18/89)
I have a more biased opinion about Elm and mh. Our two secretaries started out on mh and absolutely hated dealing with Unix mail since they were used to a different system which was much more user friendly. I got them to try using Elm and now they are more adventurous than they ever were on the system that they had used for 7 years. They find Elm much easier and more intuitive than mh. I also use Elm and have to admit that it is more useful to me than mailx.
weiner@novavax.UUCP (Bob Weiner) (05/19/89)
> In article <43290411.f81c@gtephx.UUCP> barriost@gtephx.UUCP (Tim Barrios) writes: > > Here's the questions I have for other Apollo Sys 5 users: > > Is there another mail system that is better than mailx for Apollo? > > I've heard about 'smail'. Is this available for Apollo? What's > different about it v.s. mailx and Elm? > > What do other Apollo users use to send/receive network mail? We run a small ring of SR10.1 BSD UNIX DN4500s with modem connections to other local hosts and to USENET. To answer his questions it is important to distinguish between mail delivery agents, such as BSD's Sendmail (the standard delivery agent for all e-mail users under SR10), and mail program interfaces which abound on UNIX and Apollo systems. Some mail systems include both delivery agents and user interfaces for reading and sending mail. We use Sendmail as the delivery agent. Unfortunately, Apollo's default sendmail configuration file under SR10.1 does not properly resolve UUCP '!' addresses. There is a file under /domain_examples/sendmail (I believe) call uucpproto.cf which looks like it handles this address style but has not as yet worked for us. Apollo should juice up the default config file since there is no reason user's should have to install this facility. For a mail interface, we currently use GNU Emacs Rmail/mail since all of our users use Emacs, rather than vi, to edit. This gives them all of their editor capabilities while reading and composing mail. They can also scroll through messages, delete messages, or randomly jump among messages by clicking with one mouse button on an message header summary line. (GNU Emacs also offers an interface to the RAND mh mail handling system distributed with AT&T's SysV.3.) The Emacs interface expands basic mail address aliases. In general, Sendmail resolves all other address routing functions such as domain name parsing. Sendmail does not work with the USENET UUCP address map tables to find appropriate UUCP routes for mail given a user and hostname combination. This is the major purpose of the USENET project's 'smail' program; it finds the best route that it can. Hence, you probably want to configure both of these programs on your system. Unfortunately, Apollo currently does not distribute either smail or GNU Emacs, though they could if they cared enough to support better interactive environments and communication interfaces. (HP probably will distribute at least GNU code sometime in the future.) You can get 'smail' from the UUNET source archives. GNU Emacs comes from the Free Software Foundation, Cambridge, MA. -- Bob Weiner, Motorola, Inc., USENET: ...!gatech!uflorida!novavax!weiner (407) 738-2087
nazgul@apollo.COM (Kee Hinckley) (05/23/89)
In article <1274@novavax.UUCP> weiner@novavax.UUCP (Bob Weiner) writes: >Unfortunately, Apollo currently does not distribute either smail or GNU >Emacs, though they could if they cared enough to support better >interactive environments and communication interfaces. (HP probably >will distribute at least GNU code sometime in the future.) Apollo's policy has always been, right or wrong, not to ship things that we don't have the resources to support. We are fully aware that there are *lots* of utilities, tools, etc. that we should ship and support. But we can't do them all, so the best we can do is make them available via ADUS for those people who are willing to work with unsupported software. -kee -- ### User Environment, Apollo Computer Inc. ### Public Access ProLine BBS ### ### {mit-eddie,yale}!apollo!nazgul ### nazgul@pro-angmar.cts.com ### ### nazgul@apollo.com ### (617) 641-3722 300/1200/2400 ### I'm not sure which upsets me more; that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's.
weiner@novavax.UUCP (Bob Weiner) (06/01/89)
In article <43657eac.1b147@apollo.COM> nazgul@apollo.COM (Kee Hinckley) writes: In article <1274@novavax.UUCP> weiner@novavax.UUCP (Bob Weiner) writes: >Unfortunately, Apollo currently does not distribute either smail or GNU >Emacs, though they could if they cared enough to support better >interactive environments and communication interfaces. (HP probably >will distribute at least GNU code sometime in the future.) Apollo's policy has always been, right or wrong, not to ship things that we don't have the resources to support. We are fully aware that there are *lots* of utilities, tools, etc. that we should ship and support. But we can't do them all, so the best we can do is make them available via ADUS for those people who are willing to work with unsupported software. I sure Kee believes Apollo is doing the right thing. But there is no justification for any of the following: 1. Not sending every customer a full listing (at least once a year) of the full complement of ADUS distributed software including summaries. 2. Not shipping up to date, complete 3rd party software listings for Apollo platforms for at least the last year. As I understand, marketing (I have to say, a very feeble organization, at best) cannot decide whether it is 'appropriate' to print these catalogs now due to the HP acquisition. No amount of pounding for the last six months has put one in my hands. Lest you think I want something for nothing, my group of less than 15 people put $250,000 in Apollo's hands in January. 3. Not documenting, in print, the many useful examples loaded under the /domain_examples directory. 4. Not providing a simple way of writing programs to access the high performance features of Apollo systems. Something along the lines of the NeXTStep programming environment is what I have in mind. We have 100's of Apollos down here used by software engineers (mostly cross-compiling for other platforms) and I don't know one who is fluent in Apollo's large set of system calls. Hence no one can write an application that makes good use of the graphics, network communication, or other powerful parts of Apollos systems. 5. Not educating vendors as to the current state of Apollos system. Most software vendors I speak to have not ported their software to Domain/OS (SR10) and truly believe in their hearts that Apollo's OS is Aegis and Aegis alone. 6. Not putting an alias facility in the Aegis shell and then providing a set of common UNIX aliases. Do you know how many people are in the process of weaning themselves from the Aegis shell and command naming conventions. Many, many. Apollo's support of this is virtually nil. In my sleep, I could write the alias facility, in fact I did (I was awake though) two years ago. Then I would put together a simple two page summary that maps common Aegis commands and options into their UNIX equivalents. Apollo should do this so that all users benefit. There is more to say, but I won't burden everyone. The point is, there was much more behind my original statement about good environments. I hope you understand my vantage point, Kee, and that I wouldn't take the time to write this if I didn't feel that there were seeds of greatness buried below Apollo's surface. -- Bob Weiner, Motorola, Inc., USENET: ...!gatech!uflorida!novavax!weiner (407) 738-2087
nazgul@apollo.COM (Kee Hinckley) (06/07/89)
In article <1314@novavax.UUCP> weiner@novavax.UUCP (Bob Weiner) writes: >In article <43657eac.1b147@apollo.COM> nazgul@apollo.COM (Kee Hinckley) writes: > Apollo's policy has always been, right or wrong, not to ship things that > we don't have the resources to support. We are fully aware that there are > *lots* of utilities, tools, etc. that we should ship and support. But > we can't do them all, so the best we can do is make them available via > ADUS for those people who are willing to work with unsupported software. > >I sure Kee believes Apollo is doing the right thing. But there is no >justification for any of the following: Did I say that I agreed with that policy? I spent three years trying to get my keydefs shipped as unsupported products. I gave up trying to ship my mkmodel script for DSEE, and sent it to this list instead (anyone interested in the SR10 version?). I'd fully like to see Apollo ship unsupported software as a separate piece of the releases. >3. Not documenting, in print, the many useful examples loaded under the >/domain_examples directory. Now we're back to resources again. >4. Not providing a simple way of writing programs to access the high >performance features of Apollo systems. Something along the lines of >the NeXTStep programming environment is what I have in mind. We have >100's of Apollos down here used by software engineers (mostly >cross-compiling for other platforms) and I don't know one who is fluent >in Apollo's large set of system calls. Hence no one can write an >application that makes good use of the graphics, network communication, >or other powerful parts of Apollos systems. Open Dialogue is a step in that direction. We have a problem here. Apollo has concentrated on getting out base technology that provides you with the means to deal with a lot of hard problems. In the process we have *not* had time to provide the higher level tools which make it *easy* to deal with easy problems. This means that we have tools like DSEE and DDE which are capable of doing very complex things, but which you have to learn in depth before you can even do easy things. You mention NextStep. That's a very sexy system. It lets you do simple things very quickly and easily. It does *not* let you do complicated things at all - you're right back to normal coding, and the WYSIWYG just gets in the way. Now maybe, by the time this becomes an issue, they will have solved those problems too. That's the gamble you have to make. Should we have done the sexy stuff first and then worried about the hard things? Maybe so. It's pretty hard to sell a system when it answers problems people don't know they have. >5. Not educating vendors as to the current state of Apollos system. >Most software vendors I speak to have not ported their software to >Domain/OS (SR10) and truly believe in their hearts that Apollo's OS is >Aegis and Aegis alone. That's an interesting one. How do you recommend that we do it? (I'm very serious here. I know we haven't suceeded, I don't know why.) >6. Not putting an alias facility in the Aegis shell and then providing >a set of common UNIX aliases. Do you know how many people are in the >process of weaning themselves from the Aegis shell and command naming >conventions. Many, many. Apollo's support of this is virtually nil. >In my sleep, I could write the alias facility, in fact I did (I was >awake though) two years ago. Then I would put together a simple two >page summary that maps common Aegis commands and options into their UNIX >equivalents. Apollo should do this so that all users benefit. The summary follows. I wrote it several years ago for a video course on Unix shell programming (for Apollo support people). As to the alias feature in the com shell, I don't see that this gets you what you want. Should we have provided an alias feature in the Unix shells to alias common Aegis commands? That would make sense for a transition, but why the other way around? And why not just add /com (or the Unix paths) to your PATH or CSR variables? >There is more to say, but I won't burden everyone. The point is, there >was much more behind my original statement about good environments. I >hope you understand my vantage point, Kee, and that I wouldn't take the >time to write this if I didn't feel that there were seeds of greatness >buried below Apollo's surface. I definitely understand, and I agree. From my standpoint in the trenches I have two choices - put out as much functionality as possible to keep ahead of the competition, or put out very little functionality, but make it easy to use. We've been doing the first, and so we haven't provided things like alias packages for the shells, templates and defines for Open Dialogue or Domain Dialogue, standard macro packages for DDE, scripts to build and update DSEE models, etc.... Some of these things exist, but have no one to support them, some of them never get written. (It's rather like Emacs. Everyone who uses it swears they'll write a good novice use package for it, but by the time they learn how to do it they don't need it any more.) Now maybe Apollo should have comitted the non-trivial resources to do these things (unfortunately they can't be done by grunts or new-hires), but we didn't. Personally I sincerely hope this is something we will gain from becoming part of HP - they have the reputation for that kind of quality, we have the reputation for the technology. These opinions are of course, my own. What follows are excerpts from my slides on Unix shell programming for Aegis shell programmers. They are doubtlessly out of date and incomplete, but I hope that they may be of help to someone. (BTW. If you asked for the GIF code and didn't get it, please let me know. I sent it to everyone I could, but I may have missed some. Be sure to include a reply address in your message - someone's mailer is truncating From: lines occasionally.) ----------- Walk on the Wild Side Aegis Bourne Shell C Shell egrep/sed/awk/ed/ex... ? ? ? . % no-period * * ?* * * .* [ ] [ ] [ ] [ ] ~ ^ (only in the editors) ... Some commands take a -r option, otherwise use "find dir -print". = ( ) { } \( \) @n \n @ \ \ \ Meta-characters - or - What not to put in your filenames CH Meaning Aegis Equiv. Notes $ Variable expansion ^ \ Escape character @ ( ) Pipeline IO ( ) This pushes a level! & Put in background & && cmd1 AND cmd2 || cmd1 OR cmd2 ; cmd1 THEN cmd2 ; > redirect stdout > < redirect stdin < >> append stdout >> << read from heredoc << | pipe | ` Active function ^"" * Wildcard ?* ? Wildcard ? [ ] Wildcards [ ] : Null command - Begin a flag - Where did it go? - Shell Builtins Aegis Unix Where? if/then/else/endif if/then/elif/else/fi builtin while/do/enddo while/do/done builtin select/oneof/allof/case/to/ case/in/esac builtin otherwise/endselect for/in/by/char/word/line/endfor for/in/do/done builtin for/to/endfor expr command von/xon/voff/xoff set -v -x - builtin -n -n option -i -i option args echo builtin eqs test command existf test command csr $PATH variable rdym times builtin hlpver man comand abtsev set -e builtin inlib inlib builtin bon/boff >/dev/null 2>&1 redirect return exit builtin existvar = builtin read/readln read (but no pipes) builtin dlvar unset/unsetenv (csh) builtin lvar set builtin and/or/mod/not expr command true/false true/false command readc exit break builtin next continue builtin eon/eoff $noglob (csh) export export builtin set set/eval builtin source . builtin setvar = builtin umask umask builtin Where Did It Go? - Shell Commands #1 Aegis Unix acl chmod/chown/chgrp/sup bind ld catf cat chn mv chpass passwd chpat sed/awk/expr cmf/cmt diff/cmp cpf/cpl cp cpt cp -r (bsd)/find -print | cpio -pdu (sys5) crd mkdir crl ln date date dcalc bc/dc debug dbx dlf/dll/dlt rm/rmdir ed sed/ed/ex edacl chmod/chown/chgrp/sup edstr sed exfld awk (bsd)/cut (sys5) flen wc fmt fmt (bsd)/nroff/troff fpat fgrep/grep/egrep fpatb awk help whatis (bsd)/man ld ls/file login login/su lusr who/rwho Where Did It Go? - Shell Commands #2 Aegis Unix lvolfs df/du macro m4/cpp mail Mail (bsd)/mail mvf mv nd $HOME ppri renice (bsd)/nice prf pr/lpr pst ps rbak cpio (sys5)/tar send_alarm write sigp kill siorf/siotf cu/uucp srf sort tctl tset (bsd)/stty tee tee tlc tr tz $TZ/$TZNAME uctob unlink wbak cpio (sys5)/tar wd cd