LISTSERV@IRLEARN.BITNET (Revised List Processor, 1.5b) (11/04/86)
Received: from SRI-KL.ARPA by wiscvm.wisc.edu on 11/03/86 at 22:18:57 CST Received: from WISCVM.WISC.EDU by SRI-KL.ARPA with TCP; Mon 3 Nov 86 04:08:12-PST Received: from (SCHOMAKE)HNYKUN53.BITNET by WISCVM.WISC.EDU on 11/03/86 at 06:08:03 CST Date: Mon, 3 Nov 86 11:10 N From: <SCHOMAKE%HNYKUN53.BITNET@WISCVM.WISC.EDU> Subject: RE: monitoring CPU usage inside a program To: info-vax@sri-kl.arpa X-Original-To: infovax, SCHOMAKER [] >Does anybody out there know of a VMS utility (I can't find anything obvious) or >a program they have written, which will monitor an executing image and produce >statistics (e.g. histograms) on how much time it is spending on which portions >of the program? ...... Try Decus's VAX-77 named "INFO: Performance Measurement Tool to Display Top CPU Procedure Within Program". I haven't used it myself but the description seems to fit your requirements. * ^^^^^ KKKKKUUUUNNNNN KKK UUUU NNNN Lambert Schomaker K UUUU NNN SCHOMAKER@HNYKUN53.BITNET KKK UUUU NN Nijmegen, The Netherlands. KKKKK UU N
LISTSERV@IRLEARN.BITNET (Revised List Processor, 1.5b) (11/05/86)
Received: from SRI-KL.ARPA by wiscvm.wisc.edu on 11/04/86 at 15:48:05 CST
Received: from Hamlet.Caltech.Edu by SRI-KL.ARPA with TCP; Mon 3 Nov 86
12:42:50-PST
Received: from Phobos.Caltech.Edu by Hamlet.Caltech.Edu with DECNET ;
Mon, 3 Nov 86 12:42:49 PST
Received: from OVRO.Caltech.Edu by Phobos.Caltech.Edu with DECNET ;
Mon, 3 Nov 86 12:42:37 PST
Date: Mon, 3 Nov 86 19:43:49 GMT
From: rpf%OVRO.Caltech.Edu@Hamlet.Caltech.Edu (Ray Finch)
Message-Id: <861103194349.013@OVRO.Caltech.Edu>
Subject: Parsing VMS filenames
To: info-vax%OVRO.Caltech.Edu@Hamlet.Caltech.Edu
I am writing a user interface program for radio telescopes and
am trying to locate a piece of code to parse VMS file names. I
would prefer C but we also have Fortran and Pascal compilers. I'm
trying to avoid having figuring out the call to SYS$PARSE and would
rather not have to open the file at this point in the program.
Thanks in advance for any helpful responses.
Ray Finch
Owens Valley Radio Observatory
P.O. Box 387
Big Pine, CA. 93513
(619)938-2828LISTSERV@IRLEARN.BITNET (Revised List Processor, 1.5b) (11/05/86)
Received: from SRI-KL.ARPA by wiscvm.wisc.edu on 11/04/86 at 16:34:27 CST Received: from WISCVM.WISC.EDU by SRI-KL.ARPA with TCP; Mon 3 Nov 86 20:26:35-PST Received: from (MAILER)IRLEARN.BITNET by WISCVM.WISC.EDU on 11/03/86 at 22:26:14 CST Received: by IRLEARN (Mailer X1.23) id 7519; Tue, 04 Nov 86 04:25:09 GMT Date: Tue, 4 Nov 1986 04:25 GMT From: Revised List Processor(1.5b) <LISTSERV%IRLEARN.BITNET@WISCVM.WISC.EDU> Subject: File: "INFO-VAX MAIL" being sent to you To: <INFO-VAX@SRI-KL.ARPA> Received: from SRI-KL.ARPA by wiscvm.wisc.edu on 11/03/86 at 22:18:57 CST Received: from WISCVM.WISC.EDU by SRI-KL.ARPA with TCP; Mon 3 Nov 86 04:08:12-PST Received: from (SCHOMAKE)HNYKUN53.BITNET by WISCVM.WISC.EDU on 11/03/86 at 06:08:03 CST Date: Mon, 3 Nov 86 11:10 N From: <SCHOMAKE%HNYKUN53.BITNET@WISCVM.WISC.EDU> Subject: RE: monitoring CPU usage inside a program To: info-vax@sri-kl.arpa X-Original-To: infovax, SCHOMAKER [] >Does anybody out there know of a VMS utility (I can't find anything obvious) or >a program they have written, which will monitor an executing image and produce >statistics (e.g. histograms) on how much time it is spending on which portions >of the program? ...... Try Decus's VAX-77 named "INFO: Performance Measurement Tool to Display Top CPU Procedure Within Program". I haven't used it myself but the description seems to fit your requirements. * ^^^^^ KKKKKUUUUNNNNN KKK UUUU NNNN Lambert Schomaker K UUUU NNN SCHOMAKER@HNYKUN53.BITNET KKK UUUU NN Nijmegen, The Netherlands. KKKKK UU N
LISTSERV@IRLEARN.BITNET (Revised List Processor, 1.5b) (11/05/86)
Received: from SRI-KL.ARPA by wiscvm.wisc.edu on 11/04/86 at 18:42:19 CST
Received: from MC.LCS.MIT.EDU by SRI-KL.ARPA with TCP; Mon 3 Nov 86 07:01:11-PST
Received: from PFC-VAX.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 3 NOV 86
09:56:17 EST
Date: 3 Nov 86 09:55:23 EST
From: MRL%PFCVAX@XX.LCS.MIT.EDU
To: INFO-VAX@SRI-KL@MC
Subject: BULLETIN utility mailed out.
I received many requests for the sources to the BULLETIN utility I posted
last week. I may have misplaced some requests, so if you had sent me a
request and have not received the sources, please resend your request. I
did have some problems in sending mail to certain users, so I might have
to resend them if they have not arrived.
Mark LondonLISTSERV@IRLEARN.BITNET (Revised List Processor, 1.5b) (11/05/86)
Received: from SRI-KL.ARPA by wiscvm.wisc.edu on 11/04/86 at 18:59:37 CST
Received: from violet.berkeley.edu ([128.32.136.22].#Internet) by SRI-KL.ARPA
with TCP; Mon 3 Nov 86 07:05:29-PST
Received: from jade.berkeley.edu
by violet.berkeley.edu (5.54 (CFC 4.22.2)/1.16.3)
id AA05764; Mon, 3 Nov 86 07:05:39 PST
Received: by jade.Berkeley.Edu (5.54 (CFC 4.22.3)/5.7.1)
id AA10863; Mon, 3 Nov 86 07:05:33 PST
Message-Id: <8611031505.AA10863@jade.Berkeley.Edu>
Received: from CLVMS(ABSTINE) by CLVM (Mailer X1.23a) id 4163;
Mon, 03 Nov 86 10:03:20 EST
Received: by CLVMS (Jnet BSMTP V0.06) id 1321; Mon, 3 Nov 86 10:04 EST
Date: Mon, 3 Nov 86 10:04 EST
From: AB Stine <ABSTINE%CLVMS.BITNET@violet.berkeley.edu>
Subject: SPICE 3A6
To: info-vax@sri-kl.arpa
Original_To: ARPA%"info-vax@sri-kl.arpa"
HELP!!! Can somebody please send me the latest version of SPICE? Our
EE VLSI class needs it and we are ordering from DECUS, but we need it sooner
than they will deliver. Many thanks.
Art Stine
Systems Programmer
Clarkson University
Educational Resources Center
Potsdam, NY 13676
Phone: (315)268-2292
BITNET: ABSTINE@CLVMSLISTSERV@IRLEARN.BITNET (Revised List Processor, 1.5b) (11/05/86)
Received: from SRI-KL.ARPA by wiscvm.wisc.edu on 11/04/86 at 19:11:21 CST
Received: from WISCVM.WISC.EDU by SRI-KL.ARPA with TCP; Mon 3 Nov 86
11:21:50-PST
Received: from (WELCH)UMASS.BITNET by WISCVM.WISC.EDU on 11/03/86 at
13:21:09 CST
Date: Sun, 2 Nov 86 13:38 EDT
From: welch%UMass.BITNET@WISCVM.WISC.EDU
To: info-vax@sri-kl.arpa
Subject: VMS Shadowing bug/gotcha
Here's an interesting "gotcha" I just came across having to do with
VMS shadowing:
After installing the shadow key on our clustered CPUs we tried using
shadowing. It worked only on out 8600 - DEC software support
checked things out and said everything looked fine. After much
head scratching we realized the difference between our 8600 and
the other CPUs was the type of system disk. The 8600 is on
a DU disk and the rest on RM05s.
As an experiment we booted another CPU off a spare DU disk and lo and
behold shadowing worked for that CPU, too.
So (at least for now) anyone planning to use shadowing should be warned
that for it to work you must boot from a DU (I suppose any DSA type
disk would work) to get the shadow driver to load instead of the
DUDRIVER.
Bitnet: Jhwelch@Amherst or
Welch@Umass
-Jonathan.LISTSERV@IRLEARN.BITNET.UUCP (11/05/86)
Received: from SRI-KL.ARPA by wiscvm.wisc.edu on 11/04/86 at 19:33:02 CST
Received: from WISCVM.WISC.EDU by SRI-KL.ARPA with TCP; Mon 3 Nov 86
14:51:24-PST
Received: from (MAILER)UWOCC1.BITNET by WISCVM.WISC.EDU on 11/03/86 at
16:49:49 CST
Received: by UWOCC1 (Mailer X1.23b) id 0817; Mon, 03 Nov 86 12:22:54 EDT
Date: Mon, 3 Nov 1986 11:59 EDT
From: Brent Sterner <A105%UWOCC1.BITNET@WISCVM.WISC.EDU>
Subject: VMS tape insecurity
To: INFO-VAX-SUBMIT <info-vax@sri-KL.ARPA>
Well, it finally happened. I had heard that VMS didn't handle tapes
very well, having grown to adolescence from PDP-11s. Last week two of
our users tangled over our single tape drive. The user with the most
data on his tape lost (and may now be convinced that I*M is a safer place
to live.
Scenario: 1st user (loser) issues a mount request.
Operator locates the tape, and begins to mount it.
1st user changes his mind and cancels the tape request.
Operator completes the tape mount, unaware of the cancellation.
2nd user's batch job mounts a tape, mount gives him the
loser's tape, which is written all over. Result is
a very bitter feeling in one of our users.
Both tapes were labelled, and were written using VMS BACKUP.
What can be done about this? It has since been suggested that our
site write a MOUNT.COM to attempt to identify labelled tapes before they
are given away. This will not address any unlabelled tapes which we may
use on the VAX from time to time (there are 2 other manufacturers systems
in the same shop), but it might help a little.
What do INFO-VAX sites do about this? Have you written such a MOUNT
procedure? I have DECUS SIG tapes from Spring and Fall 85, but don't
recall seeing anything like this. Whatever you can suggest will be
appreciated. If you are actually USING something that might help us out,
that would be better than theory.
BTW, I called Collarado TSC about this. They are generally helpful,
and always friendly, but this time the best answer I could get was that
"I think someone else here has addressed a similar problem for another
customer - I'll call you back". This request is nothing more than a
parallel request for help. TSC may have a solution, but if they do I've
not heard it as yet.
I've also heard that a TOPS-like GALAXY system is in the works for
some future VMS release. This should solve the problem, but our site
needs a work-around NOW, not in 2 years. I invite ANYONE within Digital
to suggest such a work-around for a relatively large shop (6000 users).
I'll share the best replies (Digital and non-Digital) with the net.
Thanks in advance to all who will no doubt reply. Covering my head
from the avalanch of replies, I remain
Brent Sterner
Computing & Communications Services
Natural Sciences Building
The University of Western Ontario
London, Ontario, Canada
N6A 5B7
Telephone (519)661-2151 x6036
Network <A105@UWOCC1.BITNET>LISTSERV@IRLEARN.BITNET (Revised List Processor, 1.5b) (11/05/86)
Received: from SRI-KL.ARPA by wiscvm.wisc.edu on 11/04/86 at 20:07:00 CST
Received: from WISCVM.WISC.EDU by SRI-KL.ARPA with TCP; Mon 3 Nov 86
20:42:12-PST
Received: from (TBLAKE)BINGVAXA.BITNET by WISCVM.WISC.EDU on 11/03/86
at 15:50:56 CST
Date: Mon, 3 NOV 1986 16:11 EST
From: THOMAS R. BLAKE <TBLAKE%BINGVAXA.Bitnet@WISCVM.WISC.EDU>
Subject: DECUS
To: INFO-VAX@SRI-KL
Original_To: ARPA%"INFO-VAX@SRI-KL"
Folkies (And Floksettes),
We have something to write in VS-FORTRAN here, (Yes VS-FORTRAN), and
it appears VS-FORTRAN has no DO WHILE structure (Like VAX/11 FORTRAN). Well
back some time ago I used a FORTRAN Pre-Processor on a DEC 10 called FLECS.
DECUS shows a FLECS for PRO-300.
Does anybody know of a FLECS written in plain vanilla FORTRAN which
could be adapted to VS-FORTRAN? (VS-FORTRAN ~ FORTRAN-77).
TBLAKE@BINGVAXB.BITNET Thomas R. Blake
TBLAKE@suny-bing.CSNET SUNY Computer Center
Binghamton, NY 13901LISTSERV@IRLEARN.BITNET.UUCP (11/05/86)
Received: from SRI-KL.ARPA by wiscvm.wisc.edu on 11/04/86 at 22:14:25 CST Received: from WISCVM.WISC.EDU by SRI-KL.ARPA with TCP; Mon 3 Nov 86 21:19:20-PST Received: from (MAILER)UWOCC1.BITNET by WISCVM.WISC.EDU on 11/03/86 at 16:00:20 CST Received: by UWOCC1 (Mailer X1.23b) id 0829; Mon, 03 Nov 86 12:38:44 EDT Date: Mon, 3 Nov 1986 12:30 EDT From: Brent Sterner <A105%UWOCC1.BITNET@WISCVM.WISC.EDU> Subject: DECserver-200 s/w - thanks to all To: INFO-VAX-SUBMIT <info-vax@sri-KL.ARPA> Shortly after I asked for help regarding DECserver-200 s/w, I had a call from ??? (sorry I lost the name) who is responsible for DECservers for North America for DEC. I guess it pays to be a squeaky wheel. Thanks to Digital for responding to my cry for help, as well to all who provided alternate sources for the s/w. It is gratifying to be a part of such a community. The server s/w arrived last Thursday, was installed the same day. I started the LAT Friday after the obligatory reboot, and we have had it running ever since. Digital's s/w installations are comparative dreams relative to other systems I've used (names withheld to protect the innocent). Thanks again to everyone involved in getting this act together. Brent Sterner Computing & Communications Services Natural Sciences Building The University of Western Ontario London, Ontario, Canada N6A 5B7 Telephone (519)661-2151 x6036 Network <A105@UWOCC1.BITNET>
LISTSERV@IRLEARN.BITNET (Revised List Processor, 1.5b) (11/05/86)
Received: from SRI-KL.ARPA by wiscvm.wisc.edu on 11/04/86 at 22:25:47 CST Received: from WISCVM.WISC.EDU by SRI-KL.ARPA with TCP; Mon 3 Nov 86 23:59:28-PST Received: from (SYSRUTH)UTORPHYS.BITNET by WISCVM.WISC.EDU on 11/03/86 at 18:45:47 CST Date: Mon, 3 Nov 86 17:27 EST From: <SYSRUTH%UTORPHYS.BITNET@WISCVM.WISC.EDU> Subject: responses to question on CPU usage monitoring within a program To: info-vax@sri-kl.arpa X-Original-To: info-vax@sri-kl.arpa, SYSRUTH Last week I put out a request for suggestions on programs to monitor CPU and resource utilization within a program. Many thanks to all who responded (many more than anticipated!). Here are the results: The overwhelming majority of replies concerned DEC's layered product PCA (Performance and Coverage Analyzer), which is apparently fairly sophisticated and thorough. It will work with any language which supports the VAX Symbolic Debugger, and produces information on such things as which parts of the program are/aren't being used, resource usage in various modules, etc. and puts it all in nice displays. Price estimates ranged from $4000 U.S. (I assume) to $9000 U.S., for MicroVAX licences. In addition, I got some recommendations for SPM (System Performance Monitor), which apparently has some Application Programming Tuning features I was unaware of. Finally, a couple of people mentioned a DECUS product called P.M.E., and said that it would do very similar things (perhaps not as fancy, but that doesn't matter to us). Thanks again. Hope this will in turn be of some use to someone else. Ruth Milner Systems Manager Physics/Astronomy VAX University of Toronto
LISTSERV@IRLEARN.BITNET (Revised List Processor, 1.5b) (11/05/86)
Received: from SRI-KL.ARPA by wiscvm.wisc.edu on 11/05/86 at 01:22:56 CST
Received: from WISCVM.WISC.EDU by SRI-KL.ARPA with TCP; Mon 3 Nov 86
20:00:52-PST
Received: from (MAILER)UWOCC1.BITNET by WISCVM.WISC.EDU on 11/03/86 at
22:00:23 CST
Received: by UWOCC1 (Mailer X1.23b) id 0819; Mon, 03 Nov 86 12:29:53 EDT
Date: Mon, 3 Nov 1986 12:25 EDT
From: Brent Sterner <A105%UWOCC1.BITNET@WISCVM.WISC.EDU>
Subject: MAIL Prospectus
To: INFO-VAX-SUBMIT <info-vax@sri-KL.ARPA>
WOW! I was deluged with requests. Pardon this mailing if you've
already received a direct reply, but I'd like to head this one off at
the pass. I'd rather not spend a lot more time sending out individual
copies. If you would like more information, please contact Reg Quinton
(not me) since he is the primary wizard in this area. Brent.
................................................................
From: Reg Quinton <111_362@uwovax.UWO.CDN>
To: mail_project@uwovax.UWO.CDN
Date: Tue, 28 Oct 86 12:13:43 EST
Subject: VAX/VMS[/DECNET[/JNET]] Mail project at Western
Message-id: <0530885623@uwovax.UWO.CDN>
To all and sundry who replied to me as a362@uwocc1.BITNET regarding Brent
Sterner's cryptic comment to info-vax that we at Western were working on a
project to develop a RFC821/22 Mail system .... you have not been forgotten.
Although it has taken me a very long time to get back to you, sorry.
To the fellow who offered his first born son .... thanks, but I think there
are probably laws against that.
To the people at Weslyan (sp?) and elsewhere who are working on similar
projects, let me know if you think the following is off the mark.
Some brief comments to let you know what we've been up to and where we stand.
We'd like to send out a beta-test distribution (and probably will to a couple
of neighbors) but cannot send out to the many people who responded... Sorry,
perhaps by Jan. '87 we'll be in a better position.
What are we doing? ... In brief we've ported a version of Kurt Shoen's Mail
program (the version we've ported is very far removed from the Berkeley
distribution ...). As well we've implemented a simple MAIL-DAEMON which runs
as a detached job (under an ordinary user account). MAIL-DAEMON's are proxied
together on the DecNET and submit BSMTP messages to one another by writing to
simple tasks which 'suck in the message' and 'wake' the daemon. (Note that this
is considerably different from the VAX/VMS Mail strategy which requires that
you a) have Decnet priviledges (here the daemon needs it but the users doesn't)
and b) that a circuit be established to the remote mail box). Likewise Mail
communicates to the daemon by writing a file and waking the daemon (the
communication here is also via BSMTP messages). So also is the protocol to
JNET -- JNET writes the required file and wakes the daemon. (We communicate
with the RSCS world through MAILER@UWOCC1 although we have enough exits that
we could communicate directly with anyone on the RSCS net... but we'd rather
the interface to Western be at one machine... this machine may replace the IBM
though and we'd have to communicate with everyone directly then).
The MAIL-DAEMON is usually in a hibernate state waiting to be awakened (by
a remote daemon or Mail as noted above) or for an alarm to ring. When the
DAEMON awakens he first spawns an "OFTEN.COM" task --- typically we put in
here resubmission of messages queued because of DECNET down, and (if you want
to support VAX/VMS mail) dequeuing of any VMS/MAIL (more on this latter).
Then the MAIL-DAEMON tries to get rid of any messages that have been queued
for him (by remote daemons, by local Mail, by even JNET). The queue is simply
implemented by VAX/VMS version numbers (so the DAEMON cycles processing a
file called "MAIL.BSMTP" until such time as there are none left). Determining
who a message is for is simple given the BSMTP protocol. The disposition of
messages is table driven (although the table is, at the moment, compiled in
as a seperate file). The table is a lot like Crosswell's (at least in spirit)
consisting of a "pattern" (eg. "*@uwovax.*" with '*' as a wild card), an
exit function (eg. local, jnet-direct, jnet-mailer, bsmtp, vmslocal), and a
string parameter. For example, one might have an table entry saying
"*@*.CDN", jnet-mailer, "MAILER@CANADA01"
to specifiy that mail for the CDN domain should be processed by the "jnet-
mailer" exit, with the string "MAILER@CANADA01" as a parameter. ie. send a
BSMTP message to the indicated MAILER on the RSCS network using JNET. We have
implemented only a very few functions (which meet our needs) but others could
be added with minimal fuss.
We *do not* implement the strategy of MAILING an RFC822 message to a MAILER;
the terrible :mailer.MAILER BITNET exit implemented by the Columbia mailer.
This is a really bad one and I'm afraid that some of the people on the mail
explosion are not going to get this message because they want that kind of
guff...
Everything is written in 'C' (I'm the local Unix wizard and have just gotten
'into' VMS) and ought to be pretty simple to maintain. We don't do any
fork/exec, instead we do system("command") and have implemented this using
LIB$SPAWN. We're also not doing any racy tty stuff (no glossy screens,
reverse-video, etc.) although we do signal trapping. On-line help is
implemented by spawning the help system.
System stuff (where people sometimes get scared)
a) we define some logicals
sys$mail (the daemon's directory)
sys$mail_name (the system name eg. uwovax.UWO.CDN)
b) we install some programs
sys$mail:daemon (This guy needs basically "SYSTEM" priviledges so he
can read the UAF, write to people's directory, change file ownership,
exceed quotas, use Decnet, write to your screen, etc.)
sys$mail:waker (this guy needs to be able to wake the daemon, at the
moment our UA has no priviledges to do this (or much of anything else).
this likely will disappear when we're confident about the UA).
sys$mail:forger (well, if you like to support VMS mail you'll need
this.)
c) we modify the system startup.com to include mail_startup.com which
defines the logicals, installs the programs, and submits a batch job
under the DAEMON user id (at our site it's user MLNET). This job then
shoves the required stuff at loginout.exe to get a detached job going
under user MLNET (hence the batch) with a DCL (hence the loginout.exe)
--- the DCL is required so he can do LIB$SPAWNS. If you trusted this guy
you could avoid installing the daemon.exe by just doing the loginout.exe
and avoid the batch. That would give you user SYSTEM (who has lots of
priv's) as the DAEMON-- but this is dangerous 'cause you proxy them
together.
d) small mod to the JNET source (a one page program) to make sure that
BSMTP messages to the DAEMON get written to the right place and that
the DAEMON gets awakened (if you're using JNET you need to make sure that
your DAEMON is at least in the same group as JNET... this is usually the
SYSTEM group... scary I know!)
Mail Design (the UA)
As noted above this is a port of Kurt Shoen's program so the user from
Unix land sees something very familiar. We rely on the C argument parsing
so when installed as a foreign command (at the moment we call ours
"xmail") you can say..
$xmail help (we'll put the help library into the system when we
formally decomission VAX/VMS mail).
$xmail (to check your mail/read your mail)
$xmail user user ... (to send mail)
$xmail -s subject user user .. (to send mail and set the subject)
$xmail -f (to read your default folder)
$xmail -f foo.bar (to read your foo.bar folder)
There's tons of deviations from the original program, some intended to make
the move from VAX/VMS easier. The major deviations are:
MAIL.BOX resides in the user's login directory formatted as RFC822 messages
seperated by lines saying
Contents: x pages, y lines, z characters
i.e. we don't have the silly "From user date remote from host" format
and don't need to alter any of the contents of the message, in particular
no need for the silly ">From ..." lines.
UAF control -- some users can be refused access to mail in the UAF, we honour
this control. (seems like a nice idea since I occassionally see slanderous
messages.)
MAIL.FORWARD since it's processed by the DAEMON is expected to contain fully
qualified addresses in a syntax
userid: address [,address...]
(The userid is required since different ones can map to the same directory,
eg. I am also the postmaster).
The syntax allows for simple mailing lists... you're getting this note
because of such an expansion on the SYS$MAIL:MAIL.FORWARD file (this is
a bit like the "aliases" of 4.2BSD).
Construct RFC 822 dates, Reply-to, Return-Receipt-to (actually this one is
only recognized by sendmail Unix guys).
The UA constructs fully qualified addresses (since the DAEMON doesn't do any
munging) and makes no assumptions about a network configuration. We
prefer the "comments <address>" construction
The "set" command is used for all sorts of interesting things...
set name="Reg Quinton" !to define my name in the From:
set editor=eve !to define an alternate editor
set pagesize=20 !display is "paged" to user
etc.
Racy terminal stuff to allow one to edit a header line is not implemented.
Since the version of Mail we worked on was a *very* old one (it ran on an
11/34 and came from a 2.8 distribution tape so it's from about 1980). There's
a few commands we haven't implemented ... ignore and folder being the most
important ones. But we'll probably put these in.
The communication between UA and MTA is pretty simple ... no fork, exec but
instead the writting of a file and the waking of a daemon.
VAX/VMS mail....
Well, I'm not too keen about this one but we do provide some minimal support
without getting our hands too dirty... i.e. we didn't want to get into the
infamous "exit%blah.blah.blah" stuff. Instead, we rely on the fact that
VMS/MAIL will let you type..
$MAIL
MAIL> Send
To: USER!blah blah blah
Likewise if you receive using VAX/VMS mail a message saying it was
From: USER!blah blah blah
Typing a reply will construct the same kind of thing that the send did above.
Given this observation we provide a minimal interface to VAX/VMS mail (although
we'll pull this shortly). User MLNET is the "USER" mentioned above and this is
the account the DAEMON runs under.
Getting mail out of VAX/VMS world... people mail to MLNET!address. Daemon, in
the often.com sequence, empties his mail box munging VAX/VMS messages into the
BSMTP queue.
Getting mail into the VAX/VMS world... daemon does a spawn to MAIL a file to
the user and run the forger to modify the header. The spawned task takes care
of any NAKs.
BUT...you have to wait for the daemon to wake up, doesn't handle multiple
recipients, forwarding (given the forger) doesn't work very well (you get
the forwarded message but the forger doesn't get to forge the From:), you
can't forward out of DECNET, you need a silly address syntax, you can't
use the silly address syntax on the DCL line, etc. etc.
Limitations/Problem areas:
1. At the moment the UA runs non-priviledged, to write into the DAEMON spool
area we leave it writable by the world (well we could give the UA priv's
and push them up and down as needed).
2. By RFC821 I really mean BSMTP as implemented on the RSCS net --- i.e.
rather than a synchronous communication as in SMTP we just 'batch' up
an SMTP dialogue and let the recipient DAEMON take care of things. A
DAEMON who receives a BSMTP message is on his own, ... ie. he must deliver
and/or return NAK if required. A BSMTP message which isn't gets flogged to
the local postmaster.
3. By RFC822 I really mean
comment <user@host.domain>
(comment) user@host.domain
ie. I do not implement "routing" of the form <@host,@host:user@host>. Well
one can handle these within the framework implemented but I don't.
4. I don't allow for addresses which 'split' lines,
eg. From: I am not a crook
Nixon@disgrace
5. I'm not too keen about quoted fragments either ...
eg. From: I am not a crook <"Richard Nixon"@disgrace>
well this could easily be handled but since not too many can handle it,
why bother?
6. My UA implements From:, Reply-to:, Bcc:, Cc:, Return-Receipt-to: and
recognizes the Resent- variants. (Note I don't construct any Resent-
and I don't do any Sender: stuff).
7. The DAEMON doesn't honor Return-Receipt-to: when making local delivery...
this is easy to add and will likely be done soon.
8. The JNET exits simply spawn a DCL command... I really need to analyze the
output from the command to make sure that the host was valid. This isn't
a problem (yet) at our site since we interface to the RSCS net by talking
with our MAILER@UWOCC1.BITNET
9. The JNET inbound interface should really do some authorization checks..
ie. is the sender really an authorized mailer?
10. Profs/notes/etc. As far as I'm concerned these aren't mail.. My JNET
interface will pull them in and preface them with a proper mail header.
NOTE I do not munge them! And I never will... these guys should be
discouraged (if not beaten over the head).
11. I need a program to create the table from the NAME(s) files.
12. I'd like to be able to mail to files and processes.
Problems, comments, questions, etc. can be directed to my address (in
the Reg Quinton 'From:').LISTSERV@IRLEARN.BITNET (Revised List Processor, 1.5b) (11/05/86)
Received: from SRI-KL.ARPA by wiscvm.wisc.edu on 11/05/86 at 03:21:14 CST
Received: from WISCVM.WISC.EDU by SRI-KL.ARPA with TCP; Tue 4 Nov 86
05:18:28-PST
Received: from (MAILER)UKACRL.BITNET by WISCVM.WISC.EDU on 11/04/86 at
07:18:04 CST
Return-path: EMAILDEV@UKACRL.BITNET
Received: By UK.AC.RL.IB (MAILER) ; Tue, 04 Nov 86 11:24:52 GMT
Via: UK.AC.KCL.PH.IPG; 4 NOV 86 11:24:42 BST
Date: 4-NOV-1986 11:24:18
From: SYSMGR%UK.AC.KCL.PH.IPG@AC.UK
To: INFO-VAX@SRI-KL.ARPA
Subject: Re: reading a 'corrupt' stream_LF file
Since this has been going for days and nobody has made the suggestion
that I was anticipating...
If all else fails, map the file into VM with $CRMPSC. Then pass it to
a program written in a language of your choice which interprets it as
a string of bytes and inserts a correct record structure, writing a
new file with RMS.
Caveat - I have used this trick before but not for the case under
discussion.
Nigel Arnot (Dept. Physics, Kings college, Univ. of London; U.K)
Bitnet/NetNorth/Earn: sysmgr@ipg.ph.kcl.ac.uk (or) sysmgr%kcl.ph.vaxa@ac.uk
Arpa : sysmgr%ipg.ph.kcl.ac.uk@ucl-cs.arpaLISTSERV@IRLEARN.BITNET (Revised List Processor, 1.5b) (11/05/86)
Received: from SRI-KL.ARPA by wiscvm.wisc.edu on 11/05/86 at 03:31:37 CST Received: from WISCVM.WISC.EDU by SRI-KL.ARPA with TCP; Tue 4 Nov 86 05:40:34-PST Received: from (MAILER)IRLEARN.BITNET by WISCVM.WISC.EDU on 11/04/86 at 07:40:14 CST Received: by IRLEARN (Mailer X1.23) id 7982; Tue, 04 Nov 86 10:51:29 GMT Date: Tue, 4 Nov 1986 10:51 GMT From: Revised List Processor(1.5b) <LISTSERV%IRLEARN.BITNET@WISCVM.WISC.EDU> Subject: File: "INFO-VAX MAIL" being sent to you To: <INFO-VAX@SRI-KL.ARPA> Received: by IRLEARN (Mailer X1.23) id 7979; Tue, 04 Nov 86 10:50:31 GMT Date: Tue, 04 Nov 86 10:50:19 GMT From: Niall O'Reilly UCD <NOREILLY@IRLEARN> Subject: Test Message - please ignore To: VAX Information Mailing List <INFO-VAX@IRLEARN>
campbell@maynard.UUCP (11/09/86)
Some BITNET gateway somewhere is posting messages with the identical,
useless subject line `File: "INFO-VAX MAIL" being sent to you'. Would
whoever owns this gateway please fix it? It is truly annoying to try
to get a subject listing of 35 new messages and have half of them
claiming the same useless subject, meaning I have to read them individually.
Here is a sample header from an offending message:
Path: maynard!wjh12!husc6!rutgers!nike!ucbcad!ucbvax!IRLEARN.BITNET!LISTSERV
From: LISTSERV@IRLEARN.BITNET (Revised List Processor, 1.5b)
Newsgroups: mod.computers.vax
Subject: File: "INFO-VAX MAIL" being sent to you
Message-ID: <8611051319.AA28722@ucbvax.Berkeley.EDU>
Date: 5 Nov 86 02:12:00 GMT
Date-Received: 5 Nov 86 21:00:06 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 26
Approved: info-vax@sri-kl.arpa
--
Larry Campbell MCI: LCAMPBELL The Boston Software Works, Inc.
UUCP: {alliant,wjh12}!maynard!campbell 120 Fulton Street, Boston MA 02109
ARPA: campbell%maynard.uucp@harvisr.harvard.edu (617) 367-6846campbell@maynard.UUCP (11/09/86)
Oh, NO!! Not only is the new BITNET gateway redistributing messages
after having substituting a useless subject line, it now seems to be
looping! Watch our for overflowing disks, everyone...
--------------------begin sample message header--------------------
Path: maynard!wjh12!husc6!seismo!lll-crg!nike!ucbcad!ucbvax!IRLEARN.BITNET!LISTSERV
From: LISTSERV@IRLEARN.BITNET (Revised List Processor, 1.5b)
Newsgroups: mod.computers.vax
Subject: File: "INFO-VAX MAIL" being sent to you
Message-ID: <8611090137.AA07274@ucbvax.Berkeley.EDU>
Date: 4 Nov 86 22:41:00 GMT
Date-Received: 9 Nov 86 09:16:45 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 39
Approved: info-vax@sri-kl.arpa
Received: from SRI-KL.ARPA by wiscvm.wisc.edu on 11/04/86 at 16:34:27 CST
Received: from WISCVM.WISC.EDU by SRI-KL.ARPA with TCP; Mon 3 Nov 86
20:26:35-PST
Received: from (MAILER)IRLEARN.BITNET by WISCVM.WISC.EDU on 11/03/86 at
22:26:14 CST
Received: by IRLEARN (Mailer X1.23) id 7519; Tue, 04 Nov 86 04:25:09 GMT
Date: Tue, 4 Nov 1986 04:25 GMT
From: Revised List Processor(1.5b)
<LISTSERV%IRLEARN.BITNET@WISCVM.WISC.EDU>
Subject: File: "INFO-VAX MAIL" being sent to you
To: <INFO-VAX@SRI-KL.ARPA>
--------------------end sample message header--------------------
--
Larry Campbell MCI: LCAMPBELL The Boston Software Works, Inc.
UUCP: {alliant,wjh12}!maynard!campbell 120 Fulton Street, Boston MA 02109
ARPA: campbell%maynard.uucp@harvisr.harvard.edu (617) 367-6846