Archive-Date: Mon, 01 Mar 1993 06:51:04 CST Sender: list-mgr@WKUVX1.BITNET Date: Mon, 01 Mar 1993 06:50:43 CST From: "Hunter Goatley, WKU" Reply-To: MX-List@WKUVX1.BITNET To: mx-list@WKUVX1.BITNET Message-ID: <00968D86.4B88F7C0.1677@WKUVX1.BITNET> Subject: MX-LIST Administrivia: Monthly Post Last modified: 2-JUL-1992 00:40 01:26 (Created) Welcome to MX-List@WKUVX1.BITNET, an electronic mailing list established for the discussion of the Message Exchange mail software. This is a routine posting you will see from time to time on MX-List. The MX-List archives are maintained at ARCHIVES@WKUVX1.BITNET. To get a copy of any month's postings, send an e-mail message with the body SEND MX-List.yyyy-mm to ARCHIVES@WKUVX1.BITNET, where "yyyy" is the year and "mm" is the numeric representation of the month. For example, the message SENDME MX-List.1992-04 will send the archives for April 1992. To remove yourself from the mailing list, send the following command to LISTSERV@WKUVX1.BITNET: SIGNOFF MX-List LISTSERV supports a few other commands for your convenience. The following commands can be handled automatically by the list processor: SIGNOFF MX-List - to remove yourself from the list REVIEW MX-List - to get a list of subscribers QUERY MX-List - to get the status of your entry on the list SET MX-List NOMAIL - to remain on the list but not receive mail SET MX-List MAIL - to resume receiving mail from the list SET MX-List CONCEAL - to not report your address in a REVIEW SET MX-List NOCONCEAL - to report your address in a REVIEW SET MX-List REPRO - to receive posts you make to MX-List SET MX-List NOREPRO - to not receive posts you make to MX-List LIST - to get a list of mailing lists served by WKUVX1 HELP - to receive a help file By default, subscriptions are set to MAIL, REPRO, NOCONCEAL. If you have any questions, comments, or suggestions about MX-List, please contact the list owner at the address below. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Hunter Goatley, VAX Systems Programmer goathunter@WKUVX1.BITNET Western Kentucky University Academic Computing, STH 226 (502) 745-5251 Bowling Green, KY 42101 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- ================================================================================ Archive-Date: Mon, 01 Mar 1993 07:50:58 CST Sender: list-mgr@WKUVX1.BITNET Date: Mon, 01 Mar 1993 14:44:22 EST From: Michael Juenemann Reply-To: MX-List@WKUVX1.BITNET To: MX-LIST@WKUVX1.BITNET Message-ID: <00968DC8.76636740.1188@venus.IPA.FhG.de> review MX-List ================================================================================ Archive-Date: Mon, 01 Mar 1993 08:40:31 CST Sender: list-mgr@WKUVX1.BITNET From: Reply-To: MX-List@WKUVX1.BITNET Subject: Re: a1mail address garbling Message-ID: <1993Mar1.133129.10872@gandalf.ca> Date: Mon, 1 Mar 1993 13:31:29 GMT To: MX-List@WKUVX1.BITNET In <00968B86.B085C3F0.24658@nuconvex.com> Paul Simons writes: >This doesn't directly have to do with MX, but I have been trying to deal with >that problem as well. Is DDS an ALLIN1 product or a part of MessageBus? >Where is any documentation for DDS? DDS is a component of the Message Router product set as you thought. It is often associated with ALL-IN-1, but is not a part of it. If you have the Message Router product documentation set, DDS will be found within... David -- dhuddles@gandalf.ca David J. Huddleson Gandalf Data Ltd., Nepean, Ontario (613) 723-6500 Days (613) 822-1315 Otherwise ================================================================================ Archive-Date: Mon, 01 Mar 1993 10:28:37 CST Sender: list-mgr@WKUVX1.BITNET Date: Mon, 01 Mar 1993 11:02:37 EST From: "Andy Miller, ext. 0595" Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <00968DA9.7BBD6E80.3364@vaxrb.niehs.nih.gov> Subject: SIGNOFF MX-List SIGNOFF MX-List -------------------------------------------+------------------------------------ Andrew Miller | RRRRR TTTTTT OOOOO X X System Analyst & anything that needs doing | R R T O O X X Mantech Enviromental Sciences / NIEHS-RTOX | RRRR T O O X Internet: MILLER_A@VAXRB.NIEHS.NIH.GOV | R R T O O X X Bitnet : MILLER_A@NIEHS | R R T OOOOO X X -------------------------------------------+------------------------------------ ================================================================================ Archive-Date: Mon, 01 Mar 1993 12:15:59 CST Sender: list-mgr@WKUVX1.BITNET From: Reply-To: MX-List@WKUVX1.BITNET Subject: errors-to v. return-path Message-ID: <1993Mar1.172721.13594@netcom.com> Date: 1 Mar 93 17:27:21 GMT To: MX-List@WKUVX1.BITNET i just installed mx 3.1c and am having a problem with the mailing list component's headers. according to my internet-forwarder (i'm using uucp), in order for bouncing to work correctly (i.e. not go back to the list, but rather to the errors-to address), the return-path field in the header should be set to same address as the errors-to address. is there a way to gain control over this? second, is there a way to (a) have MX archive every message that goes through MX (i.e. leave them FINISHED, but on queue for a longer period of time) and (b) is it possible to examine the full headers of messages which are on queue (e.g. mcp> queue show/header). thanks, all. -- -- -- bob pasker -- rbp@netcom.com -- ================================================================================ Archive-Date: Mon, 01 Mar 1993 15:06:55 CST Sender: list-mgr@WKUVX1.BITNET Date: Mon, 01 Mar 1993 15:04:50 CST From: Hunter Goatley Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET CC: rbp@netcom.com Message-ID: <00968DCB.5279F440.6234@WKUVX1.BITNET> Subject: RE: errors-to v. return-path writes: > >i just installed mx 3.1c and am having a problem with the mailing list >component's headers. according to my internet-forwarder (i'm using >uucp), in order for bouncing to work correctly (i.e. not go back to >the list, but rather to the errors-to address), the return-path field >in the header should be set to same address as the errors-to >address. is there a way to gain control over this? > First off, unless I fixed this is v3.2 and don't remember doing so, the "Return-path:" is the same as the "Errors-To:", as shown in the headers for this message: >Return-Path: >[...] >Errors-To: list-mgr@WKUVX1.BITNET >Sender: list-mgr@WKUVX1.BITNET Note that I added the redundant "Sender:" in v3.2 to try to cope with brain-dead mailers. The "Errors-To:" header is actually not an RFC-defined standard, though some packages support it. The final receiving systems may add info to the "Return-Path:". As far as my interpretation of "Return-Path:" goes, it's to be used only as a last resort. When bouncing mail, a mailer should look first at the "Sender:" address. I don't remember---does MX v3.1 not put a "Sender:" line in? >second, is there a way to (a) have MX archive every message that goes >through MX (i.e. leave them FINISHED, but on queue for a longer period >of time) You can change the definition of MX_FLQ_CHECK_WAIT (FLQ_CHECK_WAIT under MX v3.1). That logical controls the about of time a queue entry should remain in the queue after it has been processed. The default is 15 minutes. >and (b) is it possible to examine the full headers of >messages which are on queue (e.g. mcp> queue show/header). > No. MCP QUE SHOW/FULL/ALL shows the maximum amount of info currently available. Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@WKUVX1.BITNET (or goathunter%wkuvx1.bitnet@UKCC.UKY.EDU) ================================================================================ Archive-Date: Mon, 01 Mar 1993 15:40:38 CST Sender: list-mgr@WKUVX1.BITNET Date: Mon, 01 Mar 1993 15:35:44 CST From: Hunter Goatley Reply-To: MX-List@WKUVX1.BITNET To: mx-list@WKUVX1.BITNET CC: fsupdate@WKUVX1.BITNET Message-ID: <00968DCF.A38BE740.6256@WKUVX1.BITNET> Subject: MX V3.2 is now available! At last, I've just released MX v3.2! It's only been almost a year since the MX v3.1C update went out. Hopefully, there'll be no problem that slipped through the field test cycle. I'd like to publicly thank my field testers for their time and patience. More MX information is included below my sig. What's New ---------- NOTE: this version of MX changes the format of the MX file queue FLQ_DIR:SYSTEM_QUEUE.FLQ_CTL. If you install MX v3.2 on a system with messages still in the READY state in the file queue, you'll be unable to go back to v3.1 after installing v3.2 (at least, not without reinstalling v3.1 from scratch). The MX installation automatically converts your queue file. Also, MX v3.2 uses 10 subdirectories under MX_FLQ_DIR: to hold the files. This was done in an attempt to help with performance problems caused when the QUEUE.DIR file grows larger than 128 blocks (which it won't with MX v3.2). There have been a lot of changes made, though many of them will not be noticable by end-users. A new utility, MXALIAS, has been added to let users maintain their own personal MX aliases for addresses. MXALIAS does *not* use logical names---it's integrated with MX_MAILSHR. MX v3.2 features: o FLQ routines rewritten in BLISS o MX_FLQ_DIR subdirectories o Local delivery error messages compatible with LISTSERV o Proper support for BSMTP continuation lines in MX Jnet. o A number of enhancements to the MLF agent. o X25_SMTP bug fixes. o MX SITE breaks the DCL command line into pieces for longer commands. o MX_MAILSHR correctly handles logicals defined as lists of logicals. o Lots, lots more! How To Get It ------------- Via anonymous ftp: You can get MX v3.2 via anonymous ftp from ftp.spc.edu ([192.107.46.27]). You'll need: [.MX]UNZIP.EXE [.MX.MX032]MX032.ZIP !VMSINSTAL kits [.MX.MX032]MX032_SRC.ZIP !The MX sources, if you want them Also, [.MX.MX032]MX032_DOCS_ONLY.ZIP contains only the .K saveset, which contains the MX v3.2 documentation files, if you want to get just the docs first. Via e-mail: You can get MX v3.2 via e-mail by sending the following commands in the body of a mail message to FILESERV@WKUVX1.BITNET: SEND MX032 SEND FILESERV_TOOLS FILESERV_TOOLS includes MFTU.EXE and UNZIP.EXE, which are needed to unpack the files. NOTE: MX032 consists of 91 VMS_SHARE parts that are 60-blocks each. Given the speeds of my net connections, it may take a couple of days for you to receive all the parts. Please be patient! Via VMS Store (BITNET users only): If you're on BITNET, you can have the MX v3.2 files sent to you as VMSDUMP files from Eric Thomas's VMS Store. SEND or mail to LISTSERV@SEARN the command INDEX [MX.MX032] and GET the files you want, or GET [MX.MX032]*.*. Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@WKUVX1.BITNET (or goathunter%wkuvx1.bitnet@UKCC.UKY.EDU) --------------------------------------------------------------------------- [26-FEB-1993] Message Exchange V3.2 Message Exchange (MX) is electronic mail software for VAX systems running VMS V5.0 or later, including VMS V5.5. It supports Internet mail over CMU-Tek TCP/IP, VMS/ULTRIX Connection, TGV MultiNet, and Process Software's TCPware; BITNET mail over Jnet; and UUCP mail over DECUS UUCP. Also included is support for SMTP message transfers over DECnet and X.25 (using VAX P.S.I). MX uses VMS Mail for local message entry and delivery, and includes support for mailing lists and mail-based file servers. Features: * Users send and receive messages using VMS MAIL. Support for "signature" files is included in the VMS MAIL interface. Full support for automatic forwarding with the VMS MAIL SET FORWARD command is included. User-defined alias databases for e-mail addresses is supported. * Provides SMTP (RFC 821) message transfers over CMU-OpenVMS TCP/IP (aka CMU-Tek TCP/IP), DEC TCP/IP Services for OpenVMS (aka VMS/ULTRIX Connection, TGV MultiNet, and TCPware from Process Software. Includes support for Internet domain system MX records. Also supports SMTP over DECnet and X.25 (using VAX P.S.I.). * Provides BSMTP message transfers with other BITNET mailers over Jnet, compatible with the CU Mailer package for VM systems. Fully supports BITNET-Internet gateways for non-Internet-connected systems. When combined with the SMTP support, can also provide a BITNET/Internet gateway service. * Interfaces with DECUS UUCP to provide a single mail interface to all mail protocols. Can also gateway between UUCP and other networks. * Provides a mailing list processor with automatic subscription requests. Mailing lists can be configured to restrict postings only to subscribers or list owners, and to restrict the automatic subscription handling. Internet mailing list conventions and a subset of LISTSERV commands are supported. * Supports one or more file servers that can be set up by the system manager to handle automatic distribution of packages of files using mail as the distribution medium. Large transfers can be deferred to off-hours, and daily per-user, per-system, and/or per-server limits can be placed on each server. * Provides interfaces for a site-provided custom mail transport and custom address processing routines. Files in this directory: ------------------------ MX032.ZIP The installation kits for MX v3.2 (for use with VMSINSTAL). MX032_SRC.ZIP Source code, in a zipped saveset. MX032_DOCS_ONLY.ZIP The MX032.K saveset containing the docs. This separate .ZIP file is provided for those who want to start with just the docs. NOTE: The K saveset of the installation kit contains the documentation for MX in PostScript, Bookreader, and plain ASCII formats. <<< You will need the UNZIP program in the [ANONYMOUS.MACRO32] directory >>> <<< to expand the compressed files. >>> -------------------------------------------------------------------------------- CONTACTING THE AUTHORS Comments, suggestions, and questions about this software can be directed to the current maintainer at one of the following addresses: Mail: Hunter Goatley Western Kentucky University Academic Computing, STH 226 Bowling Green, KY 421201 E-mail: goathunter@WKUVX1.BITNET goathunter%wkuvx1.bitnet@ukcc.uky.edu Phone: 502-745-5251 (e-mail is preferred) The original author of MX is Matthew Madison: Mail: Matthew Madison TGV, Inc. E-Mail: (Internet) madison@tgv.com COPYRIGHT NOTICE This software is COPYRIGHT © 1993, MadGoat Software. ALL RIGHTS RESERVED. Permission is granted to copy and redistribute this software for no commercial gain, providing all copyright notices remain intact. DISCLAIMER This software is provided "AS IS". The author and their respective employers disclaim all warranties on the software, including without limitation, all implied warranties of merchantability and fitness. ================================================================================ Archive-Date: Mon, 01 Mar 1993 15:51:41 CST Sender: list-mgr@WKUVX1.BITNET Date: Mon, 01 Mar 1993 15:49:03 CST From: Hunter Goatley Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET CC: fsupdate@WKUVX1.BITNET Message-ID: <00968DD1.7FAE2980.6280@WKUVX1.BITNET> Subject: RE: MX V3.2 is now available! Hunter Goatley writes: > >At last, I've just released MX v3.2! It's only been almost a year >since the MX v3.1C update went out. Hopefully, there'll be no problem >that slipped through the field test cycle. I'd like to publicly thank >my field testers for their time and patience. > A couple of other things I meant to mention: o This release does not yet support OpenVMS AXP. That's next on my "to do" list. o This release incorporates the latest version of Matt's NETLIB routines (NETLIB v1.5B). It includes a couple of bug fixes. You can get the NETLIB sources, if desired, via ftp from ftp.spc.edu in [.MADISON.NETLIB] and via e-mail by sending SEND NETLIB015 in the body of a mail message to FILESERV@WKUVX1.BITNET. Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@WKUVX1.BITNET (or goathunter%wkuvx1.bitnet@UKCC.UKY.EDU) ================================================================================ Archive-Date: Mon, 01 Mar 1993 21:11:56 CST Sender: list-mgr@WKUVX1.BITNET Subject: Re: errors-to v. return-path Message-ID: <1993Mar2.014944.22175@netcom.com> From: Reply-To: MX-List@WKUVX1.BITNET Date: Tue, 2 Mar 1993 01:49:44 GMT To: MX-List@WKUVX1.BITNET hunter, thanks for your thoughtful response. i will check with my neighboring sysadmin. on another note, the bookreader format seems to be different than on my system; i get "invalid book versin"; do they not work on 5.2? thanks, -- -- -- bob pasker -- rbp@netcom.com -- ================================================================================ Archive-Date: Tue, 02 Mar 1993 00:57:18 CST Sender: list-mgr@WKUVX1.BITNET From: system@swdev.si.com Reply-To: MX-List@WKUVX1.BITNET Subject: BULLETIN and MX signature files Message-ID: <1MAR93.19412973@swdev.si.com> Date: Mon, 1 Mar 1993 19:41:29 GMT To: MX-List@WKUVX1.BITNET MX interfaces with Mark London's BULLETIN file. Both MX and BULLETIN allow signature files to be appended to the end of any message. If I define MX_SIGNATURE and BULL_SIGNATURE to be the same file, will the signature file be appended twice? Actually, this message will give me the answer, since I'm posting it by way of BULLETIN and I have both logical names defined. SO, the question is academic. ================================================================================ Archive-Date: Tue, 02 Mar 1993 00:57:24 CST Sender: list-mgr@WKUVX1.BITNET From: Reply-To: MX-List@WKUVX1.BITNET Subject: RE: BULLETIN and MX signature files Message-ID: <1MAR93.23141271@swdev.si.com> Date: Mon, 1 Mar 1993 23:14:12 GMT To: MX-List@WKUVX1.BITNET The posting asking about MX and BULLETIN's signature file interaction was really posted by me. I happened to use the wrong account, so my experiment was faultly. Now I'm using the correct account (my own) and so I'll answer my own question. Thanks for your patience. -----------------------------+-------------------------------- Brian Tillman | Internet: tillman@swdev.si.com Smiths Industries, Inc. | tillman_brian@si.com 4141 Eastern Ave., MS129 | Hey, I said this stuff myself. Grand Rapids, MI 49518-8727 | My company has no part in it. -----------------------------+-------------------------------- ================================================================================ Archive-Date: Tue, 02 Mar 1993 05:51:16 CST Sender: list-mgr@WKUVX1.BITNET Date: Tue, 02 Mar 1993 05:50:50 CST From: Hunter Goatley Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <00968E47.18651BA0.6477@WKUVX1.BITNET> Subject: Re: errors-to v. return-path writes: > >hunter, thanks for your thoughtful response. i will check with my >neighboring sysadmin. > OK. >on another note, the bookreader format seems to be different than on >my system; i get "invalid book versin"; do they not work on 5.2? > That's a really good question. I know of no reason that they wouldn't work. Do the Supervisor Series docs work for you? Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@WKUVX1.BITNET (or goathunter%wkuvx1.bitnet@UKCC.UKY.EDU) ================================================================================ Archive-Date: Tue, 02 Mar 1993 14:03:02 CST Sender: list-mgr@WKUVX1.BITNET Date: Tue, 02 Mar 1993 13:37:07 EST From: "Kenneth J. Hoover" Reply-To: MX-List@WKUVX1.BITNET To: mx-list@WKUVX1.BITNET Message-ID: <00968E88.3BF7F240.507@psuedvax.psu.edu> Subject: trouble getting MLF running on 3.2 I've been working on MX 3.2, and it seems to go OK, but my mailing lists aren't running because I can't get the "MX MLF" process to start. the MX_STARTUP.COM file seems to just skip over it (i.e. the section of the .COM file which startf the MLF process doesn't appear in the .LOG file when I run mx_startup in the batch queue. Everything else seems OK. Any tips/hints? - Ken Hoover -- Kenneth J. Hoover | "Not one shred of evidence exists ITSS Supervisor of Systems & Ops | that life is serious." Penn State College of Education | - Joseph Campbell Internet: ken@psuedvax.psu.edu / kjh6@psuvm.psu.edu BITNET : ken@psuedvax ================================================================================ Archive-Date: Tue, 02 Mar 1993 14:07:00 CST Sender: list-mgr@WKUVX1.BITNET Date: Tue, 02 Mar 1993 14:06:32 CST From: Hunter Goatley Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <00968E8C.57FF1960.6706@WKUVX1.BITNET> Subject: RE: trouble getting MLF running on 3.2 "Kenneth J. Hoover" writes: > > I've been working on MX 3.2, and it seems to go OK, but my mailing >lists aren't running because I can't get the "MX MLF" process to start. the >MX_STARTUP.COM file seems to just skip over it (i.e. the section of the .COM >file which startf the MLF process doesn't appear in the .LOG file when I run >mx_startup in the batch queue. Everything else seems OK. > You should be able to get it started using: $ @sys$startup:mx_startup mlf As to why it's not there, is the MLF agent listed in your MX_DIR:MX_STARTUP_INFO.DAT file? For example: 001NETLIB:* 002ROUTER:* 003LOCAL:* 004DNSMTP:* 004SMTP:* 004SMTP_SERVER:* 005MLF:* Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@WKUVX1.BITNET (or goathunter%wkuvx1.bitnet@UKCC.UKY.EDU) ================================================================================ Archive-Date: Tue, 02 Mar 1993 14:07:45 CST Sender: list-mgr@WKUVX1.BITNET Date: Tue, 02 Mar 1993 14:13:19 EST From: "Kenneth J. Hoover" Reply-To: MX-List@WKUVX1.BITNET To: mx-list@WKUVX1.BITNET Message-ID: <00968E8D.4A2B8F20.528@psuedvax.psu.edu> Subject: problem fixed, please disregard. I fixed the problem with MLF not starting. It turns out that I shut down JNET too far (to a "cold" state rather than the "warm" state). I shut it down to "warm" and re-installed and it went OK. Sorry to bother you. - Ken PS: Thanks to Matt for including a "digestifier" :-) in the distribution. I was just about to ask if one existed! -- Kenneth J. Hoover | "Not one shred of evidence exists ITSS Supervisor of Systems & Ops | that life is serious." Penn State College of Education | - Joseph Campbell Internet: ken@psuedvax.psu.edu / kjh6@psuvm.psu.edu BITNET : ken@psuedvax ================================================================================ Archive-Date: Tue, 02 Mar 1993 15:50:50 CST Sender: list-mgr@WKUVX1.BITNET From: Reply-To: MX-List@WKUVX1.BITNET Subject: Strange, selective mail delivery failure Message-ID: Date: Tue, 2 Mar 1993 20:23:19 GMT To: MX-List@WKUVX1.BITNET A problem arises for users with Pathworks remote notification enabled after starting MX. When someone sends a mail message to one of these people the following message appears: %MAIL-E_ERRACTRNS, error activating transport PCSA %LIB-E-ACTIMAGE, error activating image DOM$DKA0:[SYS0.SYSCOMMON.][SYSLIB]NETBIOSSHR.EXE;4 -SYSTEM-F-PRIVINSTALL, shareable images must be installed to run privileged image This doesn't occur before MX is started, so there must be some strange interaction between these two packages. Can anybody shed any light on this? ================================================================================ Archive-Date: Tue, 02 Mar 1993 17:12:59 CST Sender: list-mgr@WKUVX1.BITNET From: Reply-To: MX-List@WKUVX1.BITNET Subject: Re: errors-to v. return-path Message-ID: <1993Mar2.202000.17219@netcom.com> Date: Tue, 2 Mar 1993 20:20:00 GMT To: MX-List@WKUVX1.BITNET Hunter Goatley writes: > writes: >>on another note, the bookreader format seems to be different than on >>my system; i get "invalid book versin"; do they not work on 5.2? >> >That's a really good question. I know of no reason that they >wouldn't work. Do the Supervisor Series docs work for you? is this where i make the astonishing admission that i'm not running the supervisor series :-)? i guess i should download photo, spy, and advisor & see how they've changed over the years. -- -- -- bob pasker -- rbp@netcom.com -- ================================================================================ Archive-Date: Tue, 02 Mar 1993 18:32:34 CST Sender: list-mgr@WKUVX1.BITNET Date: 02 Mar 1993 17:18:43 -0700 (MST) From: Dan Wing Reply-To: MX-List@WKUVX1.BITNET Subject: Re: errors-to v. return-path To: MX-List@WKUVX1.BITNET Message-ID: <01GVC9II3KZ600005N@VAXF.COLORADO.EDU> bob pasker, rbp@netcom.com, writes: >is this where i make the astonishing admission that i'm not running >the supervisor series :-)? Hmmmm, lesse... WHOIS shows Netcom is in San Jose, CA, but just shows a PO Box.... We'll send a hit squad to getcha, Bob. ;-) >i guess i should download photo, spy, and advisor & see how they've >changed over the years. They're excellent - Hunter's done a great job of improving them since he's taken over the Supervisor Series. Very useful for our helpdesk. Hunter also setup the list SUPSER-L@WKUVX1.BITNET for the product. -Dan Wing, dwing@uh01.colorado.edu or wing_d@ucolmcc.bitnet (DGW11) Systems Administrator, University Hospital, Denver ================================================================================ Archive-Date: Tue, 02 Mar 1993 22:46:24 CST Sender: list-mgr@WKUVX1.BITNET Date: Tue, 02 Mar 1993 20:11:12 GMT From: Chris Higgins - System Administrator Reply-To: MX-List@WKUVX1.BITNET Subject: MX 3.2.... The modifications.... To: MX-LIST@WKUVX1.BITNET Message-ID: <00968EBF.494429A0.12141@csvax1.ucc.ie> Hmmmmm... Just installed MX 3.2 , and this is what I think... 1/ The 10 Subdirectories of QUEUE are a bit of a load on a machine, this is because each message is placed into a directory based on the last digit in its queue entry number... This results in a lot of disk jumping for me, as each message generates a file in a separate directory..... I think that it might be better to base the decision on the 'hundreds' value giving 100 files per directory before moving on. A message would only have it's associated files split into different directories occasionally rather than all the time.... 2/ Bounced mail is still not forwarded to POSTMASTER... I was under the impression that this was on the 'wish-list'.. Is it still there ? Is it implemented ? (I could find no mention of it in the documentation).. 3/ FLQU will be missed... The amount of information imparted by a simple FLQU SHO was very useful. I can't see MCP QUEUE SHO/ALL taking over. 4/ MXAlias is nice, but not essential... I would have preferred more expansion MCP rather than the addition of extra utilities. 5/ It's nice that someone is actually putting work into it, and I know that Hunter doesn't have the time to be doing major work on it, but I'm not sure that the changes I've seen warrant a jump to 3.2 (maybe 3.1f) (OK, so the Config file format has changed, and the data file format has changed, and the queue entries have changed... so it NEEDS a version change.. but is there all that much of a difference in the actual package from the Sys. Admin side of things { except not being able to FLQU SHO }) Anyway enough whining... Thanks Hunter for putting the work into it... When do we expect 3.2a :-) Chris. + J.C. Higgins, Sys Admin + Auditor, Computer Science Society, U.C.C. + Chris@csvax1.ucc.ie + + Chris@odyssey.ucc.ie + If you love something, set it free. If it doesn't + C.Higgins@iruccvax.ucc.ie + come back to you, hunt it down and KILL it. ================================================================================ Archive-Date: Tue, 02 Mar 1993 23:10:36 CST Sender: list-mgr@WKUVX1.BITNET Date: Tue, 02 Mar 1993 23:07:41 CST From: Hunter Goatley Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <00968ED7.F0ED6140.6883@WKUVX1.BITNET> Subject: RE: MX 3.2.... The modifications.... Chris Higgins - System Administrator writes: > >Hmmmmm... Just installed MX 3.2 , and this is what I think... > >1/ The 10 Subdirectories of QUEUE are a bit of a load on a machine, this > is because each message is placed into a directory based on the [...] > on the 'hundreds' value giving 100 files per directory before moving > on. A message would only have it's associated files split into > different directories occasionally rather than all the time.... > I have seen no performance degradation with the 10 subdirectories. At least none that I noticed. The performance is, according to my tests, much better than it was with a single directory. Your way could still create larger .DIR files than the implemented scheme, I think. In any case, this was merely the first step toward a queue overhaul down the road. I expect that this will change again some way in v3.3. >2/ Bounced mail is still not forwarded to POSTMASTER... I was under the > impression that this was on the 'wish-list'.. Is it still there ? > Is it implemented ? (I could find no mention of it in the > documentation).. > It was not implemented, but is still on the wish list. >3/ FLQU will be missed... The amount of information imparted by a simple > FLQU SHO was very useful. I can't see MCP QUEUE SHO/ALL taking over. > The only thing I remember missing from MCP QUE SHOW/FULL is the next process to handle the message. I intend, sometime, to look at FLQU and see just what needs to be done to get all the info in MCP. >4/ MXAlias is nice, but not essential... I would have preferred more expansion > MCP rather than the addition of extra utilities. > Not essential for you maybe, but something I've wanted for a *long* time. Early reports from my field testers indicated that this was a much-appreciated feature. >5/ It's nice that someone is actually putting work into it, and I know that > Hunter doesn't have the time to be doing major work on it, but I'm not Major work is coming. I didn't actually start any real work on MX until around 1-DEC-1992 because of several other prior commitments. Once I *did* start on it, there was a lot to learn. There are some major changes I didn't make to v3.2 just because I didn't feel comfortable making them yet. > sure that the changes I've seen warrant a jump to 3.2 (maybe 3.1f) > (OK, so the Config file format has changed, and the data file format > has changed, and the queue entries have changed... so it NEEDS a > version change.. but is there all that much of a difference in the > actual package from the Sys. Admin side of things { except not being > able to FLQU SHO }) > No, there's not much outward change, but there's a ton of internal changes, as documented in the release notes. Where I come from, that says new version. I could have held up v3.2 for a few more months adding more features, but I wanted to a) get the new FLQ stuff in the field, as I believe it represents an increase is performance, and b) be able to have a stable version to port to Alpha. >Anyway enough whining... Thanks Hunter for putting the work into it... >When do we expect 3.2a :-) > Next up: porting MX v3.2 to OpenVMS AXP. I don't anticipate that that'll take very long, once I have the time to do it. I hope to be neck-deep in that by early next week. (In addition to my DSJ articles, I have a real job too! 8-) Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@WKUVX1.BITNET (or goathunter%wkuvx1.bitnet@UKCC.UKY.EDU) ================================================================================ Archive-Date: Wed, 03 Mar 1993 06:44:43 CST Sender: list-mgr@WKUVX1.BITNET Date: Wed, 3 Mar 93 13:28+0100 To: mx-list@WKUVX1.BITNET Subject: gruss aus tuebingen From: SYSTEM Reply-To: MX-List@WKUVX1.BITNET Message-ID: <12*system@mpib-tuebingen.mpg.dbp.DE> SIGNOFF MX-List ================================================================================ Archive-Date: Wed, 03 Mar 1993 08:04:12 CST Sender: list-mgr@WKUVX1.BITNET Date: Wed, 03 Mar 1993 08:58:16 EST From: ANIL KHULLAR Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <00968F2A.723F58D2.31401@cunyvms1.gc.cuny.edu> Subject: RE: MX 3.2.... The modifications.... Chris Higgins - System Administrator > > Hmmmmm... Just installed MX 3.2 , and this is what I think... > [.....] > > 3/ FLQU will be missed... The amount of information imparted by a simple > FLQU SHO was very useful. I can't see MCP QUEUE SHO/ALL taking over. > MCP QUEUE SHOW/FULL/ALL gives more than FLQU SHOW as far as information necessary for managing stuck stuff is concerned. > Chris. > > + J.C. Higgins, Sys Admin + Auditor, Computer Science Society, U.C.C. > + Chris@csvax1.ucc.ie + > + Chris@odyssey.ucc.ie + If you love something, set it free. If it doesn' t > + C.Higgins@iruccvax.ucc.ie + come back to you, hunt it down and KILL it. Anil Khullar (AK112) 212-642 2705 ank@cunyvms1.gc.cuny.edu ================================================================================ Archive-Date: Wed, 03 Mar 1993 11:33:49 CST Sender: list-mgr@WKUVX1.BITNET Date: 03 Mar 1993 09:39:52 -0700 (MST) From: "Louis B. Moore" Reply-To: MX-List@WKUVX1.BITNET Subject: RE: MX 3.2.... The modifications.... To: MX-List@WKUVX1.BITNET Message-ID: <00968F30.41B0B3E0.29996@tchden.org> >>4/ MXAlias is nice, but not essential... I would have preferred more expansion >> MCP rather than the addition of extra utilities. >> >Not essential for you maybe, but something I've wanted for a *long* >time. Early reports from my field testers indicated that this was a >much-appreciated feature. Indeed, MXalias was *THE* reason we volunteered to beta test. > (In addition to my DSJ articles, I have a real job too! 8-) Oh, say it ain't so Hunter. Louis B. Moore Internet: lbmoore@tchden.org Systems Programmer Phone: +1 303 837 2513 The Children's Hospital of Denver Denver, Colorado USA 80218 ================================================================================ Archive-Date: Wed, 03 Mar 1993 13:24:41 CST Sender: list-mgr@WKUVX1.BITNET Date: Wed, 03 Mar 1993 19:14:19 GMT From: Chris Higgins - System Administrator Reply-To: MX-List@WKUVX1.BITNET Subject: RE: MX 3.2.... The modifications.... To: MX-LIST@WKUVX1.BITNET Message-ID: <00968F80.811DD440.13373@csvax1.ucc.ie> In a previous article, wrote: > Chris Higgins - System Administrator > >MCP QUEUE SHOW/FULL/ALL gives more than FLQU SHOW as far as information >necessary for managing stuck stuff is concerned. True.. but each entry takes several lines, which can scroll off screen quickly... I had just gotten used to doing a `flqu sho' periodically, and it provided me with just the information I was looking for.... I'm not saying that `mcp queue sho/all/full' won't do the job, just that I'll miss the simplicity of `flqu sho' > >Anil Khullar (AK112) >212-642 2705 >ank@cunyvms1.gc.cuny.edu Chris. + J.C. Higgins, Sys Admin + Auditor, Computer Science Society, U.C.C. + Chris@csvax1.ucc.ie + + Chris@odyssey.ucc.ie + If you love something, set it free. If it doesn't + C.Higgins@iruccvax.ucc.ie + come back to you, hunt it down and KILL it. ================================================================================ Archive-Date: Wed, 03 Mar 1993 13:29:22 CST Sender: list-mgr@WKUVX1.BITNET Date: Wed, 03 Mar 1993 19:19:24 GMT From: Chris Higgins - System Administrator Reply-To: MX-List@WKUVX1.BITNET Subject: RE: MX 3.2.... The modifications.... To: MX-LIST@WKUVX1.BITNET Message-ID: <00968F81.3733E760.13388@csvax1.ucc.ie> In a previous article, wrote: >>>4/ MXAlias is nice, but not essential... I would have preferred more expansio n >>> MCP rather than the addition of extra utilities. >>> >>Not essential for you maybe, but something I've wanted for a *long* >>time. Early reports from my field testers indicated that this was a >>much-appreciated feature. > >Indeed, MXalias was *THE* reason we volunteered to beta test. I wasn't saying that it isn't useful, neither was I saying that I didn't appreciate it, but I was disappointed that more of the stuff that was on the wish-list wasn't included....(what can I say, I'm greedy, but I do appreciate the effort Hunter is putting into it...) > >> (In addition to my DSJ articles, I have a real job too! 8-) >Oh, say it ain't so Hunter. > > Louis B. Moore Internet: lbmoore@tchden.org > Systems Programmer Phone: +1 303 837 2513 > The Children's Hospital of Denver Denver, Colorado USA 80218 Chris. + J.C. Higgins, Sys Admin + Auditor, Computer Science Society, U.C.C. + Chris@csvax1.ucc.ie + + Chris@odyssey.ucc.ie + If you love something, set it free. If it doesn't + C.Higgins@iruccvax.ucc.ie + come back to you, hunt it down and KILL it. ================================================================================ Archive-Date: Wed, 03 Mar 1993 16:02:36 CST Sender: list-mgr@WKUVX1.BITNET Date: Wed, 03 Mar 1993 15:55:34 EST From: ANIL KHULLAR Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <00968F64.BE93B432.518@cunyvms1.gc.cuny.edu> Subject: RE: MX 3.2.... The modifications.... > Chris Higgins - System Administrator > In a previous article, wrote: > > Chris Higgins - System Administrator > > > >MCP QUEUE SHOW/FULL/ALL gives more than FLQU SHOW as far as information > >necessary for managing stuck stuff is concerned. > > True.. but each entry takes several lines, which can scroll off screen > quickly... I had just gotten used to doing a `flqu sho' periodically, and > it provided me with just the information I was looking for.... I'm not saying > that `mcp queue sho/all/full' won't do the job, just that I'll miss the > simplicity of `flqu sho' > Well, I agree. FLQU SHOW is/was simple. But in my neck-of-the-woods life just got wee bit complicated ;-). I know this is non-related to this group (So I apologize in advance), BUT: Where would I begin, if I had to write a report/develop a plan for disaster recovery for a VAX/VMS based shop ?. ( I have info/prices frm Comdisco, and various other vendors.... no that is not what I want.) A basic set of guidlines, questions, issues to consider while writing a kind-of-a-outline for adminstrators. Since this is not related to MX, I'd welcome direct e-mail. I would if there is interest, post whatever I do come up with. Anil Khullar (AK112) 212-642 2705 ank@cunyvms1.gc.cuny.edu ================================================================================ Archive-Date: Wed, 03 Mar 1993 18:04:54 CST Sender: list-mgr@WKUVX1.BITNET From: Reply-To: MX-List@WKUVX1.BITNET Subject: Re: MX 3.2.... The modifications.... Date: 3 Mar 1993 23:06:51 GMT Message-ID: <1n3dmbINNbud@CS.UTK.EDU> Keywords: VMS, MX, 3.2 To: MX-List@WKUVX1.BITNET Thanks indeed to Hunter G. for his work on MX. We installed it at LRC.EDU last week, in a version leap from 2.3. The difficulties we found were mostly those from taking such a big change at once. Thanks for the "SEND/FOREIGN/TYPE=1" feature. This will be a great convenience in running the Info-Stratus list, since a prominent mail gateway used by our list members insists on splashing mail intended for the list into the list-owner's mailbox. Perhaps I missed something in the documentation, but what do you have to set to get a meaningful value into the outbound "Warnings-To:" header field? -- ...Richard S. Shuford | "Plans fail for lack of counsel, ...shuford@cs.utk.edu | but with many advisers they succeed." ...Info-Stratus Coord. | Proverbs 15:22 NIV ================================================================================ Archive-Date: Wed, 03 Mar 1993 18:18:00 CST Sender: list-mgr@WKUVX1.BITNET Date: 03 Mar 1993 09:14:32 -0700 (MST) From: Dan Wing Reply-To: MX-List@WKUVX1.BITNET Subject: Re: MX 3.2.... The modifications.... To: MX-List@WKUVX1.BITNET Message-ID: <01GVD6YO04Z6007DF2@VAXF.COLORADO.EDU> Hunter wrote: >Chris Higgins - System Administrator writes: >> >>Hmmmmm... Just installed MX 3.2 , and this is what I think... >> >>1/ The 10 Subdirectories of QUEUE are a bit of a load on a machine, this >> is because each message is placed into a directory based on the >[...] >> on the 'hundreds' value giving 100 files per directory before moving >> on. A message would only have it's associated files split into >> different directories occasionally rather than all the time.... >> >I have seen no performance degradation with the 10 subdirectories. At >least none that I noticed. The performance is, according to my tests, >much better than it was with a single directory. Your way could still >create larger .DIR files than the implemented scheme, I think. Chris, I don't understand how there could be any measurable performance degradation by deciding which directory to put a file into. Or am I missing something. The change was done so that none of the directories would exceed 128 blocks. >>4/ MXAlias is nice, but not essential... I would have preferred more expansion >> MCP rather than the addition of extra utilities. >> >Not essential for you maybe, but something I've wanted for a *long* >time. Early reports from my field testers indicated that this was a >much-appreciated feature. The MX alias feature is great! It allows captive users to create and maintain their own list of aliases, without the possibility of creating logical names that would otherwise interfere with other programs. -Dan Wing, dwing@uh01.colorado.edu or wing_d@ucolmcc.bitnet (DGW11) Systems Administrator, University Hospital, Denver ================================================================================ Archive-Date: Wed, 03 Mar 1993 18:20:26 CST Sender: list-mgr@WKUVX1.BITNET Date: Wed, 03 Mar 1993 18:19:25 CST From: Hunter Goatley Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <00968F78.D5D8C880.7295@WKUVX1.BITNET> Subject: Re: MX 3.2.... The modifications.... writes: > >Perhaps I missed something in the documentation, but what do you have >to set to get a meaningful value into the outbound "Warnings-To:" >header field? > You can't. It's hardcoded to "<>". As far as I know, "Warnings-To:" is PMDF-only record. PMDF sends warnings for each day that a message is undeliverable, then, when it gives up, it sends an error to the "Errors-To:" address. The "Warnings-To: <>" header (which only appears in mailing list and fileserv messages, just keeps PMDF systems from bombarding you with warnings that you can't do anything about. At least, that's what it's *supposed* to do! 8-) Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@WKUVX1.BITNET (or goathunter%wkuvx1.bitnet@UKCC.UKY.EDU) ================================================================================ Archive-Date: Wed, 03 Mar 1993 18:20:38 CST Sender: list-mgr@WKUVX1.BITNET Date: Wed, 03 Mar 1993 16:21:23 GMT From: Chris Higgins - System Administrator Reply-To: MX-List@WKUVX1.BITNET Subject: Possible BUG in MX 3.2 To: MX%goathunter@WKUVX1.BITNET, MX-LIST@WKUVX1.BITNET Message-ID: <00968F68.58EB8840.13209@csvax1.ucc.ie> I noticed the following earlier today. I can't state that it WASN'T in MX 3.1 or MX 3.1c I have a forwarding address set in VMSMail set as follows. MAIL> sho forward/user=test TEST has mail forwarded to MX%"SCCS6002@BUREAU.UCC.IE" I'm on CSVAX1.UCC.IE (Connected via DECNET and via TCP/IP to BUREAU.UCC.IE) $ multinet sho/version TGV Multinet V3.2 Rev A, MicroVAX 3400 Series, VAX/VMS 5.4 I have the 'default transport' mail patch installed. The following are two messages sent to user TEST. The first is to 'test' The second is to 'test@csvax1.ucc.ie' (*** MESSAGE 1*) >From: BUREAU::IN%"chris@csvax1.ucc.ie" "Chris Higgins - System Administrator" 3-MAR-1993 15:06:14.23 >To: IN%"test@csvax1.ucc.ie" >CC: >Subj: this is a test > >Date: Wed, 03 Mar 1993 13:49:56 GMT >From: Chris Higgins - System Administrator >To: test@csvax1.ucc.ie > >This is a test message.. > >TO TEST (*** MESSAGE 2*) >From: BUREAU::IN%"test@csvax1.ucc.ie" 3-MAR-1993 15:06:30.27 >To: IN%"SCCS6002@IRUCCVAX.UCC.IE" >CC: >Subj: to TEST@csvax1.ucc.ie > >Date: Wed, 03 Mar 1993 13:49:56 GMT >From: Chris Higgins - System Administrator >To: test@csvax1.ucc.ie > >This is a test message.. > >TO TEST@CSVAX1.UCC.IE Can you see the problem... The second one arrives on the remote node, FROM THE ALIAS I've setup using VMS-Mail forwarding... This shouldn't happen, should it? I read over the 'bugs/restrictions' section of the release notes and couldn't find any mention of it... And I can't guarantee that it hasn't been the same in in versions prior to MX3.2.... Should this be happening...Or is it impossible to get around ? Chris. + J.C. Higgins, Sys Admin + Auditor, Computer Science Society, U.C.C. + Chris@csvax1.ucc.ie + + Chris@odyssey.ucc.ie + If you love something, set it free. If it doesn't + C.Higgins@iruccvax.ucc.ie + come back to you, hunt it down and KILL it. ================================================================================ Archive-Date: Wed, 03 Mar 1993 19:49:29 CST Sender: list-mgr@WKUVX1.BITNET From: Subject: RE: MX 3.2.... The modifications.... Message-ID: <1993Mar4.020011.1@sejnet.sunet.se> Reply-To: MX-List@WKUVX1.BITNET Date: Thu, 4 Mar 1993 02:00:11 GMT To: MX-List@WKUVX1.BITNET In article <00968F81.3733E760.13388@csvax1.ucc.ie>, Chris Higgins - System Administrator writes: >>Indeed, MXalias was *THE* reason we volunteered to beta test. > > I wasn't saying that it isn't useful, neither was I saying that I didn't > appreciate it, but I was disappointed that more of the stuff that was on > the wish-list wasn't included....(what can I say, I'm greedy, but I do > appreciate the effort Hunter is putting into it...) You know, Hunter has been very nice and polite in his reply. Other developers are a lot less nice when people start whining that "yes, I'm sure feature such and such is useful to some other people, but don't you understand??? I don't have much of a need for it myself, and you didn't even implement my pet feature! This is ridiculous! But hey, thanks for the software anyway <-- I'm a nice guy you see, by thanking you I make it ok to whine like a spoiled brat, and I'll jump on my high horses if you dare to suggest otherwise!" :-) In fact, this is one of the best way to discourage a developer from spending more time on his product in general, and on your pet peeve in particular. Especially when you have been told that the feature you find of little use was added because the developer needed it for himself. Eric ================================================================================ Archive-Date: Wed, 03 Mar 1993 22:39:18 CST Sender: list-mgr@WKUVX1.BITNET Date: Wed, 03 Mar 1993 09:45:55 CST From: "George D. Greenwade" Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <00968F31.1A1435E0.26582@SHSU.edu> Subject: RE: MX 3.2.... The modifications.... On Wed, 03 Mar 1993 08:58:16 EST, Anil Khullar posted: > Chris Higgins - System Administrator > > > > 3/ FLQU will be missed... The amount of information imparted by a simple > > FLQU SHO was very useful. I can't see MCP QUEUE SHO/ALL taking over. > > > MCP QUEUE SHOW/FULL/ALL gives more than FLQU SHOW as far as information > necessary for managing stuck stuff is concerned. I haven't installed 3.2 yet, so I can't say anything about it, per se. I am aware that MCP QUEUE SHOW provides more information than FLQU did, but it always took longer and quite often failed to complete before it crashed for us with: %MX-F-MEMALLOC, error allocating memory from zone RCPTZONE -LIB-F-INSVIRMEM, insufficient virtual memory (this came about half way through our queue just now with 3.1C; I only know that because I have access to FLQU!) The speed at which FLQU operated was a far superior factor, as far as I was concerned (and it is an old habit as we go back a way in using MX -- this was probably the first beta we didn't participate in since 1989 as our production environment is quite busy and we can't afford down time any more). Given that we commonly turn the counter at least three times a week, has the crashiness of MCP QUEUE SHOW been eliminated on large queues or are we stuck at 3.1C? I really want to migrate quickly to the searchpath queue directories as we rarely are below 128 blocks, but we have to have reliable access to FLQU-type information or we'll be hosed. Regards, George %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% George D. Greenwade, Ph.D. Bitnet: BED_GDG@SHSU Department of Economics and Business Analysis THEnet: SHSU::BED_GDG College of Business Administration Voice: (409) 294-1266 P. O. Box 2118 FAX: (409) 294-3612 Sam Houston State University Internet: bed_gdg@SHSU.edu Huntsville, TX 77341 bed_gdg%SHSU.decnet@relay.the.net %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% ================================================================================ Archive-Date: Thu, 04 Mar 1993 04:02:13 CST Sender: list-mgr@WKUVX1.BITNET Date: Thu, 04 Mar 1993 09:54:04 GMT From: Chris Higgins - System Administrator Reply-To: MX-List@WKUVX1.BITNET Subject: RE: MX 3.2.... The modifications.... To: MX-LIST@WKUVX1.BITNET Message-ID: <00968FFB.67AF3FA0.14047@csvax1.ucc.ie> In a previous article, eric@sejnet.sunet.se wrote: >Subject: RE: MX 3.2.... The modifications.... > >> I wasn't saying that it isn't useful, neither was I saying that I didn't >> appreciate it, but I was disappointed that more of the stuff that was on >> the wish-list wasn't included....(what can I say, I'm greedy, but I do >> appreciate the effort Hunter is putting into it...) > >You know, Hunter has been very nice and polite in his reply. Other developers Thank you Hunter, this looks like a flame already, and that address is looking familiar, so Eric (of INFO-VAX flame fame I Think) if you want to continue the flame then please bring it to mail. No this is not a flame. (Just for clarity Eric. I'm not stating that is isn't a flame, just so that I can get in a flame, without it being a flame. Considering your interpretation of my other statements I think you'll see the meaning in that easily.) >are a lot less nice when people start whining that "yes, I'm sure feature such >and such is useful to some other people, but don't you understand??? I don't >have much of a need for it myself, and you didn't even implement my pet >feature! This is ridiculous! But hey, thanks for the software anyway <-- I'm a >nice guy you see, by thanking you I make it ok to whine like a spoiled brat, >and I'll jump on my high horses if you dare to suggest otherwise!" :-) I think that you've taken me up the wrong way. I do appreciate the effort that Hunter has been putting into MX, don't get me wrong... My initial message was my first reaction to MX v3.2, nothing more. Maybe I should have played around with it more, before posting.. Your interpretation of my statements is quite valid, just not the interpretation intended. My fault for not being clear.. > Eric Chris. + J.C. Higgins, Sys Admin + Auditor, Computer Science Society, U.C.C. + Chris@csvax1.ucc.ie + + Chris@odyssey.ucc.ie + If you love something, set it free. If it doesn't + C.Higgins@iruccvax.ucc.ie + come back to you, hunt it down and KILL it. ================================================================================ Archive-Date: Thu, 04 Mar 1993 08:32:56 CST Sender: list-mgr@WKUVX1.BITNET Date: Thu, 04 Mar 1993 09:13:09 EST From: "Russell O. Redman" Reply-To: MX-List@WKUVX1.BITNET To: MX-LIST@WKUVX1.BITNET CC: redman@hiaras.hia.nrc.ca Message-ID: <00968FF5.B0BC7A60.1527@hiaras.hia.nrc.ca> Subject: An FLQU replacement Judging from the messages on the list, most of the loyal users of FLQU use it to check whether MX is still alive and well. After a few experiences in the bad old days, I got paranoid and wrote a little com file which checks that all of the components are still present, but it has been much less useful since MX3.x appeared since components rarely exit anymore. I have been running FLQU fairly regularly just to see that the system is continuing to operate - if there are messages in INP and RDY as well as some in FIN, then everything is probably OK. If there are NO messages, or too many messages in funny states, I go looking for trouble. As best I can tell, this is the normal use for FLQU at other sites as well. If you have specific problems, MCP QUEUE SHOW/FULL is a better tool. What I think we want is a quick diagnostic of the state of the system which would summarise what is happening in less than one screen. It would be useful to check each of the MX components, showing that it is still present and reporting its internal state as best it can. As a minimum this would report the VMS state (HIB, RWAST, ...), but if the components maintain a record of their internal status in an accessible place, it might be better to construct a message from this. Next, it should report a few statistics on the state of the mail queue. This would include the total number of messages, the number in INP state, the number of messages waiting for processing by each of the MX components, the number of delayed messages which would not be delivered immediately, and the number in the FIN state. If there are any delayed messages, the age of the oldest message might also be useful. For myself, this kind of utility would remove the need for FLQU. Does anybody else have any thoughts? Add this to the wish-list maybe? Cheers, Russell O. Redman - redman@hiaras.hia.nrc.ca ================================================================================ Archive-Date: Thu, 04 Mar 1993 08:43:10 CST Sender: list-mgr@WKUVX1.BITNET Date: Thu, 04 Mar 1993 08:42:55 CST From: Hunter Goatley Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <00968FF1.775444A0.7569@WKUVX1.BITNET> Subject: RE: An FLQU replacement "Russell O. Redman" writes: > >Judging from the messages on the list, most of the loyal users of FLQU use it >to check whether MX is still alive and well. After a few experiences in the [...] OK. Give me a few days and I'll have FLQU ready for v3.2. I'm going to treat this, for now, as an unsupported CONTRIB utility. Perhaps I can do something in the next version of MX to address everyone's concerns. > What I think we want is a quick diagnostic of the state of the system >which would summarise what is happening in less than one screen. It would be >useful to check each of the MX components, showing that it is still present and >reporting its internal state as best it can. As a minimum this would report the >VMS state (HIB, RWAST, ...), but if the components maintain a record of their >internal status in an accessible place, it might be better to construct a >message from this. The MCP STATUS command will at least show you what's currently running.... >Next, it should report a few statistics on the state of the >mail queue. This would include the total number of messages, the number in INP >state, the number of messages waiting for processing by each of the MX >components, the number of delayed messages which would not be delivered >immediately, and the number in the FIN state. If there are any delayed >messages, the age of the oldest message might also be useful. > > For myself, this kind of utility would remove the need for FLQU. Does >anybody else have any thoughts? Add this to the wish-list maybe? > Done. Added to the wish list, that is. I think it sounds useful. Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@WKUVX1.BITNET (or goathunter%wkuvx1.bitnet@UKCC.UKY.EDU) ================================================================================ Archive-Date: Thu, 04 Mar 1993 10:50:06 CST Sender: list-mgr@WKUVX1.BITNET Date: Thu, 04 Mar 1993 10:48:21 CST From: Hunter Goatley Reply-To: MX-List@WKUVX1.BITNET To: mx-list@WKUVX1.BITNET Message-ID: <00969002.FCF5CD20.7637@WKUVX1.BITNET> Subject: FLQU for MX v3.2 OK, FLQU for MX v3.2 is now available via anonymous ftp and e-mail. I made the necessary changes and have tested it; it appears to work just fine. The file FLQU.ZIP in [.MX.MX032] on ftp.spc.edu contains the necessary .OBJ files for linking FLQU.EXE. A command procedure is provided---just unzip the files and execute @FLQU_LINK. That'll produce FLQU.EXE, which can then be copied to MX_EXE:. To get it via e-mail, send the following command in the body of a mail message to FILESERV@WKUVX1.BITNET: SEND FLQU You'll need MFTU.EXE and UNZIP.EXE to unpack it; if you need them, also get the FILESERV_TOOLS package. I'll see about implementing something like MCP QUEUE SHOW/BRIEF to get FLQU-like output in the next version of MX. BTW, it's undocumented, but MCP SHOW QUEUE is now the same as MCP QUEUE SHOW. Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@WKUVX1.BITNET (or goathunter%wkuvx1.bitnet@UKCC.UKY.EDU) ================================================================================ Archive-Date: Thu, 04 Mar 1993 12:21:45 CST Sender: list-mgr@WKUVX1.BITNET Date: Thu, 04 Mar 1993 12:04:27 CST From: "George D. Greenwade" Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET CC: redman@hiaras.hia.nrc.ca Message-ID: <0096900D.9FA89AC0.32675@SHSU.edu> Subject: RE: An FLQU replacement On Thu, 04 Mar 1993 09:13:09 EST, "Russell O. Redman" posted: >..... > What I think we want is a quick diagnostic of the state of the system which > would summarise what is happening in less than one screen. It would be > useful to check each of the MX components, showing that it is still present > and reporting its internal state as best it can. As a minimum this would > report the VMS state (HIB, RWAST, ...), but if the components maintain a > record of their internal status in an accessible place, it might be better > to construct a message from this. Attached is my MXWATCH.COM file we use here for this purpose. So long as the account which runs MX has fewer than 20 processes running in it, this is a very useful file. I extend my thanks to Ken Selvia who provided me with the base code for this which I have hacked upon. Comments on this are certainly welcome. --George %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% George D. Greenwade, Ph.D. Bitnet: BED_GDG@SHSU Department of Economics and Business Analysis THEnet: SHSU::BED_GDG College of Business Administration Voice: (409) 294-1266 P. O. Box 2118 FAX: (409) 294-3612 Sam Houston State University Internet: bed_gdg@SHSU.edu Huntsville, TX 77341 bed_gdg%SHSU.decnet@relay.the.net %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% $ !!! ====================================================================== $ !!! @VAX-VMS-shell-file{ $ !!! filename = "mxwatch.com", $ !!! version = "2.03", $ !!! date = "04 March 1993", $ !!! time = "11:29:17 CST", $ !!! author = "George D. Greenwade", $ !!! address = "Department of Economics and Business Analysis $ !!! College of Business Administration $ !!! P. O. Box 2118 $ !!! Sam Houston State University $ !!! Huntsville, Texas, USA 77341-2118", $ !!! email = "bed_gdg@SHSU.edu (Internet) $ !!! BED_GDG@SHSU (BITNET) $ !!! SHSU::BED_GDG (THENET)", $ !!! telephone = "(409) 294-1266", $ !!! FAX = "(409) 294-3712", $ !!! supported = "yes", $ !!! archived = "Niord.SHSU.edu:[FILESERV.MX]", $ !!! keywords = "MX, process monitor", $ !!! codetable = "ISO/ASCII", $ !!! abstract = "This is a DCL command shell which provides a $ !!! quick monitor of processes related to the $ !!! account MX is run under. The field delimited $ !!! by LOCAL below provides an area for local $ !!! customization of the MX mailer account name. $ !!! The default mailer account name is MXMAILER. $ !!! $ !!! Information shown includes process ID number, $ !!! process name, process state, elapsed CPU time, $ !!! node name, and image in use. Monitoring may $ !!! be continuous or one-pass. If one-pass, the $ !!! screen may be updated and redisplayed by $ !!! pressing at the inquiry line. To $ !!! run in continuous mode, include the character $ !!! * at either startup as P1 on the command line $ !!! or in response to the inquiry line. Continuous $ !!! view is ended by . To exit in either $ !!! mode, press F10 at the inquiry line (i.e, if $ !!! in continuous mode, press F10). $ !!! $ !!! Process killing is also supported. Processes $ !!! may be "hard killed" by indicating the process $ !!! process number (in column 1) at the inquiry $ !!! line. This option is provided primarily as a $ !!! control mechanism for other processes which may $ !!! be running under the mailer account. IT IS NOT $ !!! RECOMMENDED TO HARD KILL NATIVE MX PROCESSES -- $ !!! USE THE MCP SHUTDOWN SUITE TO ACHIEVE NATIVE $ !!! MX PROCESS SHUTDOWNS. $ !!! $ !!! This monitor is most useful if 20 or fewer $ !!! processes are running within the mailer $ !!! account at a point in time. $ !!! $ !!! You must have privileges to view the mailer $ !!! account in order to use this file.", $ !!! checksum = "25762 159 899 7049", $ !!! docstring = "The checksum field above contains a CRC-16 $ !!! checksum as the first value, followed by the $ !!! equivalent of the standard UNIX wc (word $ !!! count) utility output of lines, words, and $ !!! characters. This is produced by Robert $ !!! Solovay's checksum utility." $ !!! } $ !!! ====================================================================== $ !!!!!!!!!!----------LOCAL----------LOCAL----------!!!!!!!!!! $ MAILERNAME := MXMAILER $ !!!!!!!!!!----------LOCAL----------LOCAL----------!!!!!!!!!! $ FORMAT = "[!AS] PID #!8 !15 !6 !8 !6 !21" $ ESC[0,7] = %D27 $ RESET = "''ESC'[0m" $ REVERSE = "''ESC'[7m" $ CONT_MODE = "N" $begin: $ WRITE SYS$OUTPUT "''ESC'[2H''ESC'[2J " + - " ''REVERSE'MX Detached Process Info''RESET'" $ IF P1 .EQS. "*" $ THEN CONT_MODE = "Y" $ GOTO CONT $ ENDIF $CONT: $ WRITE SYS$OUTPUT "''ESC'[2;1H" $ IF F$TYPE(CTX) .EQS. "PROCESS_CONTEXT" THEN TMP = - F$CONTEXT("PROCESS",CTX,"CANCEL") $ CTX = "" $ TMP = F$CONTEXT("PROCESS",CTX,"NODENAME","*","EQL") $ TMP = F$CONTEXT("PROCESS",CTX,"USERNAME","''MAILERNAME'","EQL") $ PID_LIST = "" $ PID_LINE = 0 $LOOP: $ NPID = F$PID(CTX) $ IF NPID .EQS. "" THEN GOTO MENU $ PID_LINE = PID_LINE + 1 $ PID_LIST = PID_LIST + "''NPID'" + "," $ PNAME = F$GETJPI(NPID,"PRCNAM") $ NNAME = F$GETJPI(NPID,"NODENAME") $ IMODE = F$GETJPI(NPID,"MODE") $ ISPEC = F$GETJPI(NPID,"IMAGNAME") $ PSTATE = F$GETJPI(NPID,"STATE") $ PCPU = F$GETJPI(NPID,"CPUTIM") $ INAME = F$PARSE(ISPEC,,,"NAME") + F$PARSE(ISPEC,,,"DIRECTORY") $ IF F$PARSE(ISPEC,,,"NAME") .EQS. "" THEN INAME = "DCL" $ PID_ASCII = F$STRING(PID_LINE) $ IF PID_LINE .LT. 10 THEN PID_ASCII = " " + PID_ASCII $ GOSUB EDTIME $ WRITE SYS$OUTPUT F$FAO(FORMAT,PID_ASCII,NPID,PNAME,PSTATE,EDLINE,NNAME,INAME) $ GOTO LOOP $MENU: $ IF CONT_MODE $ THEN READ/PROMPT=""/TIME=5/ERROR=CONT/END=CONT SYS$COMMAND IPT $ CONT_MODE = "N" $ ENDIF $ WRITE SYS$OUTPUT "[*] Display in continuous mode. " + - " (Press RETURN to interrupt)" $CHOICE: $ READ/PROMPT= - "Enter selection (# to kill, to redisplay, F10 to EXIT) : " - SYS$COMMAND OPTN /END=EXIT $ OPTN = F$EDIT(OPTN,"UPCASE") $ IF OPTN .EQS. "" THEN GOTO BEGIN $ IF OPTN .EQS. "*" $ THEN CONT_MODE = "Y" $ GOTO CONT $ ENDIF $ KILL_LINE = F$INT(OPTN) $ IF (KILL_LINE .EQS. 0) .OR. (KILL_LINE .GT. PID_LINE) $ THEN WRITE SYS$OUTPUT "Invalid item number." $ GOTO CHOICE $ ENDIF $ KILL_PID = F$ELEMENT(KILL_LINE - 1,",",PID_LIST) $ PNAME = F$GETJPI(KILL_PID,"PRCNAM") $ NNAME = F$GETJPI(KILL_PID,"NODENAME") $ IMODE = F$GETJPI(KILL_PID,"MODE") $ ISPEC = F$GETJPI(KILL_PID,"IMAGNAME") $ PSTATE = F$GETJPI(KILL_PID,"STATE") $ Pcpu = F$GETJPI(KILL_PID,"cputim") $ INAME = F$PARSE(ISPEC,,,"NAME") + F$PARSE(ISPEC,,,"DIRECTORY") $ IF F$PARSE(ISPEC,,,"NAME") .EQS. "" THEN INAME = "DCL" $ PID_ASCII = F$STRING(KILL_LINE) $ IF KILL_LINE .LT. 10 THEN PID_ASCII = " " + PID_ASCII $ GOSUB EDTIME $ WRITE SYS$OUTPUT F$FAO(FORMAT,PID_ASCII,KILL_PID,PNAME,PSTATE,EDLINE,- NNAME,INAME) $ WRITE SYS$OUTPUT EDLINE $ READ/PROMPT="Stop process (Y/N): " SYS$COMMAND KILL_YN/END=CHOICE $ IF KILL_YN THEN STOP PROC/ID='KILL_PID' $ GOTO CHOICE $EDTIME: $ ED_SS=PCPU/100 $ ED_XX=PCPU-100*ED_SS $ ED_MM=ED_SS/60 $ ED_SS=ED_SS-60*ED_MM $ ED_HH=ED_MM/60 $ ED_MM=ED_MM-60*ED_HH $ EDLINE=F$FAO("!2ZL:!2ZL.!2ZL",ED_MM,ED_SS,ED_XX) $ RETURN $EXIT: $ EXIT ================================================================================ Archive-Date: Thu, 04 Mar 1993 13:02:44 CST Sender: list-mgr@WKUVX1.BITNET Subject: RE: MX 3.2.... The modifications.... Message-ID: <1993Mar4.175518.20823@news.arc.nasa.gov> From: Date: Thu, 4 Mar 1993 17:55:18 GMT Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET In article <00968F31.1A1435E0.26582@SHSU.edu>, "George D. Greenwade" writes: >I haven't installed 3.2 yet, so I can't say anything about it, per se. I >am aware that MCP QUEUE SHOW provides more information than FLQU did, but >it always took longer and quite often failed to complete before it crashed >for us with: > %MX-F-MEMALLOC, error allocating memory from zone RCPTZONE > -LIB-F-INSVIRMEM, insufficient virtual memory >(this came about half way through our queue just now with 3.1C; I only know >that because I have access to FLQU!) George, you might want to consider raising the PGFLQUO on your account to prevent this from occurring. The reason that FLQU cannot work under 3.2 is because the format of the queue control file has changed, mainly to allow MX to be ported to AXP systems. FLQU was written in PL/I, just like the old FLQ routines were; I don't think Hunter has either access to a PL/I compiler nor the knowledge (or perhaps desire) to try and update FLQU to work on the new-format queue file. Perhaps a reasonable alternative, if I might suggest one, would be a QUEUE SHOW/BRIEF command, which would provide the same sort of information that FLQU used to. -Matt -- Matthew Madison | madison@tgv.com | +1 408 427 4366 TGV, Inc. | 603 Mission Street | Santa Cruz, CA 95060 USA ================================================================================ Archive-Date: Thu, 04 Mar 1993 14:11:54 CST Sender: list-mgr@WKUVX1.BITNET Subject: Where are my dollar signs going? Message-ID: <1993Mar4.122647.1@ualr.edu> From: domiller@ualr.edu Reply-To: MX-List@WKUVX1.BITNET Date: 4 Mar 93 12:26:47 GMT To: MX-List@WKUVX1.BITNET Why is MX rewriting dollar signs in from addresses to periods? Can this behavior be changed? Is not the local part of the address sacred unless containing characters which require quoting? Can I do nothing but ask questions? Dale -- | Dale O. Miller - Systems Programmer | # # ### # #### | | University of Arkansas at Little Rock | # # # # # # # | | 2801 S. University | # # ##### # #### | | Little Rock, AR 72204-1099 USA | # # # # # # # | | (501)569-8714 | ### # # ##### # # | | DOMILLER@UALR.EDU | Disclaimer: This does not | | 92-20-28 W,34-43-30 N.ICBMNET | say what I say it doesn't say. | ================================================================================ Archive-Date: Thu, 04 Mar 1993 20:28:37 CST Sender: list-mgr@WKUVX1.BITNET Date: Thu, 04 Mar 1993 20:27:44 CST From: Hunter Goatley Reply-To: MX-List@WKUVX1.BITNET To: fsupdate@WKUVX1.BITNET CC: mx-list@WKUVX1.BITNET Message-ID: <00969053.ED4C8A20.7905@WKUVX1.BITNET> Subject: ftp.spc.edu is down.... Terry Kennedy's ftp site, ftp.spc.edu, is out of commission until the morning of Friday, 5-MAR-1993, at the earliest. Terry sent me the following message: >Hurricane-force winds and power failure forced a complete shutdown of >the computer center and a subsequent semi-evacuation. Our external >gateway is a smoldering ruin, and we have also lost an HSC and at >least 1 RA90. Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@WKUVX1.BITNET (or goathunter%wkuvx1.bitnet@UKCC.UKY.EDU) ================================================================================ Archive-Date: Fri, 05 Mar 1993 02:37:53 CST Sender: list-mgr@WKUVX1.BITNET Subject: Re: UUCP + MX = Ugly addresses Message-ID: <1993Mar4.233617.23502@infocomm.com> From: mark@infocomm.com Reply-To: MX-List@WKUVX1.BITNET Date: 4 Mar 93 23:36:17 PST To: MX-List@WKUVX1.BITNET In article <1993Feb25.175835.1@sejnet.sunet.se>, eric@sejnet.sunet.se (Eric Thomas) writes: > In article <009689B1.95A55C70.24537@nuconvex.com>, Paul Simons writes: >> help MX convert UUCP headers such as: >> >> CS.YALE.EDU!harvard.UUCP!WKUVX1.BITNET!list-mgr >> >> to instead of: >> >> WKUVX1.BITNET!list-mgr%harvard.UUCP@CS.YALE.EDU ? > > And why should MX do that? Routing information has been placed in the address > and, while it is usually redundant, there is no way for MX to know for a fact > that trashing everything but the last token is going to result in a working > address. Let me rephrase the original question/problem at least to how it applies to me. I've just installed MX 3.2 on a trial basis running with UUCP transport. I send a message which I explictly address as MX%"tcad!infopiz!mark" which really does a bounce off of my UUCP neighbor site tcad, but the exact same translations are done for any "bang" path style address. What leaves my system is: From infocomm.com!mark Thu, 4 Mar 93 09:56:23 PST remote from infopiz Received: by infocomm.com (DECUS UUCP /2.0/2.0/2.0/); Thu, 4 Mar 93 09:56:22 PST Received: by infocomm.com (MX V3.2) id 188; Thu, 04 Mar 1993 09:56:20 EST Sender: mark@infocomm.com Date: Thu, 04 Mar 1993 09:56:20 EST From: Mark Pizzolato 415-369-9366 To: tcad!infopiz!mark@infocomm.com Message-ID: <00968FFB.B89600C0.188@infocomm.com> Subject: test message to mx%"tcad!infopiz!mark" Please note the "To:" address form that is generated. The "Envelope" which is generated by the UUCP interface and appears as the B. file to be transmitted contains a "C rmail infopiz!mark" which is as expected AND seems to reflect any MAIL_REWRITE.RULES that may be appropriate (none happen to be relevant in this case, other cases certainly do interpret the rules correctly). The problem is: - the "To:" address as specified is only meaningful at my site and should the next site in line want to examine the "To:" address for interpretation and/or adjustment, the original meaning is not preserved. How can I coerce MX's configuration to simply preserve a "bang" form address for the outgoing "To:" case here? ======================================================== When messages arrive MX seems to be rather agressive when interpreting and transforming UUCP "From_" header lines. Although the "From_" header should end up being a sort of last resort origin of a message, it seems that it attempts to transform any path that may be indicated in the "From_" line to a domain name form: A message that arrives (before being processed by MX_RMAIL) with the following: From infopiz!infocomm.com!mark Thu, 4 Mar 93 21:05:59 PST remote from oms Ends up in my VMS mailbox with a "From_" header of: From infocomm.com!mark Thu, 04 Mar 1993 21:11:22 EST Now, some of this might be considered OK at times since "infocomm.com!mark" is a totally valid and unique address. I have another example that took: From uunet.UU.NET!media!vnunet!twarfield Thu, 04 Mar 1993 19:36:12 EST remote from decwrl And this ends up in my VMS mailbox with a "From_" header of: From uunet.UU.NET!media.!vnunet.!twarfield Thu, 04 Mar 1993 19:36:12 EST With the minor exception of the insertion of the extra "dots" after "media" and "vnunet", I guess this is probably OK. The bad news is that this message arrived in my mailbox with a "From:" header of: From: twarfield%vnunet%media@uunet.UU.NET which is possibly OK, BUT the incoming "From:" header started out as: From: decwrl!uunet.UU.NET!media!vnunet!twarfield My problem with the translation that happened is that what arrived will only be replyable if all the nodes in the path will handle the % hack translation correctly. Am I the only one who thinks these translations aren't quite kosher? If not, then: 1) how can I configure MX to avoid these undesireable translations? 2) how can we make the resulting configuration the default behavior for a UUCP only site? -- Mark Pizzolato - INFO COMM Computer Consulting, Redwood City, Ca PHONE: (415)369-9366 UUCP: decwrl!infopiz!mark or uunet!lupine!infopiz!mark DOMAIN: mark@infocomm.com ================================================================================ Archive-Date: Fri, 05 Mar 1993 03:33:55 CST Sender: list-mgr@WKUVX1.BITNET Date: Fri, 05 Mar 1993 09:24:19 GMT From: Chris Higgins - System Administrator Reply-To: MX-List@WKUVX1.BITNET Subject: ftp.spc.edu failure & MX032 for people in Europe... To: MX-LIST@WKUVX1.BITNET Message-ID: <009690C0.69FFF0E0.15005@csvax1.ucc.ie> Anyone in Europe who is looking for MX032.ZIP and FLQU.ZIP can get them from `odyssey.ucc.ie' while `ftp.spc.edu' is down. I'll keep them around for a short while after `ftp.spc.edu' is back online. The line isn't super fast, but it does the job.... Chris. + J.C. Higgins, Sys Admin + Auditor, Computer Science Society, U.C.C. + Chris@csvax1.ucc.ie + + Chris@odyssey.ucc.ie + If you love something, set it free. If it doesn't + C.Higgins@iruccvax.ucc.ie + come back to you, hunt it down and KILL it. ================================================================================ Archive-Date: Fri, 05 Mar 1993 03:46:36 CST Sender: list-mgr@WKUVX1.BITNET Date: Fri, 05 Mar 1993 03:39:59 CST From: Larry Horn Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET CC: hornlo@okra.millsaps.edu Message-ID: <00969090.50221660.21464@okra.millsaps.edu> Subject: RE: MX implementation of mailing lists Last August I wrote: > I've set up a few local mailing lists. Using the /REPLY_TO > qualifier with a single item (SENDER or LIST) works fine. If I issue >[...] > If /REPLY_TO=(LIST,SENDER), only the list name goes onto the "To:" > line. The "Reply-To:" header within the body of the message is > OK, but of course VAXmail pays no attention to it. [...] > would it be possible for MX to stuff BOTH addresses into the VAXmail > "From:" header, >[...] > In other words, I'd like to see, when I read a message from a list > with (LIST,SENDER), > > From: MX%"list@here",MX%"sender@here" > To: me > Subj: xxxx > body > > so than when I REPLY > > To: MX%"list@here",MX%"sender@here" > CC: > Subj: RE: xxxx > ... At the time, I believe the answer was "No" (I just happened to save my original message; the replies, if any, are gone). This week I started playing with callable MAIL (for reasons totally unrelated to MX) and discovered the MAIL$SEND_ADD_ATTRIBUTE() item code MAIL$_SEND_FROM_LINE. This will let you stuff an arbitrary string into the "From:" line. I have tested this briefly, and the "feature" I wished for above will work -- a REPLY will indeed stuff the "From:" text into the "To:" line of the reply and VAXmail will happily send the message to the multiple addresses. So, when can we expect to see this in MX ? (I've not installed V3.2 yet -- I'd be pleasantly surprised to find it already there.) - ---------------------------------- signed: 5-MAR-1993 03:38 C*T (USA) --- - Larry Horn / Millsaps College / Jackson, MS / hornlo@okra.millsaps.edu - -------------------------------------------------------------------------- - ================================================================================ Archive-Date: Fri, 05 Mar 1993 04:13:32 CST Sender: list-mgr@WKUVX1.BITNET Date: Fri, 05 Mar 1993 09:44:31 GMT From: Chris Higgins - System Administrator Reply-To: MX-List@WKUVX1.BITNET Subject: Oops... Location of MX032 on `odyssey.ucc.ie'. To: MX-LIST@WKUVX1.BITNET Message-ID: <009690C3.3CBC6340.15025@csvax1.ucc.ie> Silly me, forgot to mention that the MX032 stuff can be found in odyssey.ucc.ie /pub/vms/mx032 Chris. + J.C. Higgins, Sys Admin + Auditor, Computer Science Society, U.C.C. + Chris@csvax1.ucc.ie + + Chris@odyssey.ucc.ie + If you love something, set it free. If it doesn't + C.Higgins@iruccvax.ucc.ie + come back to you, hunt it down and KILL it. ================================================================================ Archive-Date: Fri, 05 Mar 1993 07:49:56 CST Sender: list-mgr@WKUVX1.BITNET Date: Fri, 05 Mar 1993 07:49:39 CST From: Hunter Goatley Reply-To: MX-List@WKUVX1.BITNET To: mx-list@WKUVX1.BITNET, fsupdate@WKUVX1.BITNET Message-ID: <009690B3.30BAE9A0.8066@WKUVX1.BITNET> Subject: BITNET backlog (AAARRRRGGGGHHHHHH!) Well, once again, the demand for FILESERV@WKUVX1.BITNET has greatly exceeded the capabilities of our BITNET links (not mine so much as a link upstream from me. As of this time ( 5-MAR-1993 07:45), there are almost 1900 files queued from ULKYVM to UKCC. This includes both BITNET files and Internet-bound files because UKCC serves as our gateway. This has been the situation for several days, so I'm going to temporarily take FILESERV off-line (your requests will be saved and processed when the links are clear). This means that an incredibly large number of people will be waiting for files for several more days. Sorry for the delays. You can REALLY help matters by *not* assuming nothing is coming and sending another request for files. They'll be there eventually.... Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@WKUVX1.BITNET (or goathunter%wkuvx1.bitnet@UKCC.UKY.EDU) ================================================================================ Archive-Date: Fri, 05 Mar 1993 08:34:04 CST Sender: list-mgr@WKUVX1.BITNET Message-ID: <009690B8.CFDABEC0.28994@uwwvax.uww.edu> Date: Fri, 05 Mar 1993 08:29:54 CST From: hunterl@uwwvax.uww.edu Reply-To: MX-List@WKUVX1.BITNET Subject: MX 3.2 To: mx-list@WKUVX1.BITNET MX 3.2 is installed and working. MXALIAS is a good new feature. Two questions: 1. Is [mx.queue]system_queue.flq_ctl still being used? 2. My [mx]queue.dir is 381 blocks big. What is the best way to reduce its size. Lyle Hunter Computer Center University Wisconsin-Whitewater hunterl@uwwvax.uww.edu ================================================================================ Archive-Date: Fri, 05 Mar 1993 09:20:35 CST Sender: list-mgr@WKUVX1.BITNET Date: Fri, 05 Mar 1993 09:20:18 CST From: Hunter Goatley Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET CC: hunterl@uwwvax.uww.edu Message-ID: <009690BF.DAB8DD20.8128@WKUVX1.BITNET> Subject: RE: MX 3.2 hunterl@uwwvax.uww.edu writes: > >MX 3.2 is installed and working. MXALIAS is a good new feature. >Two questions: >1. Is [mx.queue]system_queue.flq_ctl still being used? Yes, it is. >2. My [mx]queue.dir is 381 blocks big. What is the best way to reduce >its size. > Stop MX, rename QUEUE.DIR to something else, say QUEUE1.DIR, create a new QUEUE.DIR, then $ RENAME [.QUEUE1]*.*;* [.QUEUE]*.*;*. Included below is a .COM file that does this. Invoke it like: $ @rename_dir queue while you're in MX_DIR: (or whatever directory QUEUE.DIR is in). Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@WKUVX1.BITNET (or goathunter%wkuvx1.bitnet@UKCC.UKY.EDU) --------------------------------------------------------------------------- $ save_verify = 'f$verify(0)' $ proc = f$environment("PROCEDURE") $ save_default = f$environment("DEFAULT") $ set default 'f$parse(proc,,,"DEVICE")''f$parse(proc,,,"DIRECTORY") $ say := write sys$output $ rename := rename $ delete := delete $ create := create $ on error then goto common_exit $ on contrl_y then goto common_exit $ set proc/priv=bypass $ rename 'p1'.dir 'p1'1.dir $ crea/dir [.'p1'] $ say "Moving files...." $ rename [.'p1'1]*.*;* [.'p1']*.*;* $ delete 'p1'1.dir; $ common_exit: $ set default 'save_default' $ exit f$verify(save_verify).or.1 ================================================================================ Archive-Date: Fri, 05 Mar 1993 09:25:31 CST Sender: list-mgr@WKUVX1.BITNET Message-ID: <930305140956> Date: Fri, 5 MAR 93 16:16 GMT From: rok.vidmar@uni-lj.si Reply-To: MX-List@WKUVX1.BITNET Subject: MX V3.2 gamma (Help!) To: MX-List@WKUVX1.BITNET On an unclustered VAX/VMS V5.4-2 system I have moved from MX V3.1C to MX V3.2. I have selected NETLIB, MX_BASE, SMTP, DECNET_SMTP and MLF. The installation went smooth, but the ROUTER and DECNET_SMTP processes did not survive the startup, and SMTP_SERVER was unseen by MCP's STATUS command and deaf to RESET and SHUTDOWN with: %MCP-W-SHUTRESF, command .... failed -SYSTEM-F-INVBUFLEN, invalid buffer length Reboot did not help, neither did reinstallation of V3.2 and RTFM. Upon running of MX_ROUTER and MX_DNSMTP in interactive sessions both died with: %MX-F-AGENTALRDY, agent .... already running -SYSTEM-F-INVBUFLEN, invalid buffer length %TRACE-F-TRACEBACK, symbolic stack dump follows MX_ROUTER at line 116, MX_DNSMTP at line 29 read: STATUS = $ENQW (EFN=.ENQEF, LKMODE=LCK$K_PRMODE, LKSB=LOCKSB, FLAGS=LCK$M_NOQUEUE+LCK$M_SYSTEM+LCK$M_VALBLK, RESNAM=CONFIG [CFG_Q_LOCKNAM], BLKAST=BLKG_AST); IF NOT .STATUS THEN SIGNAL_STOP (MX__AGENTALRDY, 1, %ASCID %STRING (AGENT_NAME), .STATUS); That's how far I got. I would expect lock not to outlive process but ENQW knows better, and INVBUFLEN is void hint to me. What now? Regards, Rok Vidmar x.400: S=vidmar;G=rok;O=uni-lj;P=ac;A=mail;C=si UCC, University of Ljubljana inet: rok.vidmar@uni-lj.si Kardeljeva pl. 17 phone: +38 61 183579 61000 Ljubljana fax: +38 61 183534 Slovenia ================================================================================ Archive-Date: Fri, 05 Mar 1993 09:35:27 CST Sender: list-mgr@WKUVX1.BITNET Date: Fri, 05 Mar 1993 09:35:11 CST From: Hunter Goatley Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET CC: rok.vidmar@uni-lj.si Message-ID: <009690C1.EEC6EB20.8142@WKUVX1.BITNET> Subject: RE: MX V3.2 gamma (Help!) rok.vidmar@uni-lj.si writes: > > On an unclustered VAX/VMS V5.4-2 system I have moved from MX V3.1C >to MX V3.2. I have selected NETLIB, MX_BASE, SMTP, DECNET_SMTP and MLF. > > The installation went smooth, but the ROUTER and DECNET_SMTP >processes did not survive the startup, and SMTP_SERVER was unseen by >MCP's STATUS command and deaf to RESET and SHUTDOWN with: > >%MCP-W-SHUTRESF, command .... failed >-SYSTEM-F-INVBUFLEN, invalid buffer length > If I remember right, the problem is that you still have an FLQ_SHR.EXE installed. The new shareable image is MX_FLQ_SHR.EXE. I saw this same problem once during my testing. I had installed MX v3.2 in a new directory and, when the installation provided the new images, the old ones were not replaced in the known image list (via INSTALL) because VMSINSTAL did not see them. Try INSTALL/LIST and see if you don't have an FLQ_SHR.EXE installed along with MX_FLQ_SHR.EXE. > Reboot did not help, neither did reinstallation of V3.2 and RTFM. >Upon running of MX_ROUTER and MX_DNSMTP in interactive sessions both died >with: > Sounds like you're still executing the V3.1 startup? Or maybe you're installing the old images from some other .COM during startup? Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@WKUVX1.BITNET (or goathunter%wkuvx1.bitnet@UKCC.UKY.EDU) ================================================================================ Archive-Date: Fri, 05 Mar 1993 10:23:41 CST Sender: list-mgr@WKUVX1.BITNET Date: Fri, 05 Mar 1993 10:23:22 CST From: Hunter Goatley Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <009690C8.A9EC6820.8160@WKUVX1.BITNET> Subject: RE: Where are my dollar signs going? domiller@ualr.edu writes: > >Why is MX rewriting dollar signs in from addresses to periods? Can this >behavior be changed? Is not the local part of the address sacred unless >containing characters which require quoting? Can I do nothing but ask >questions? There's currently no way (short of a code change) to stop it from translating it. The reason, from Matt: >Because most, if not all, UNIX systems will interpret the $xxxx as a >shell variable reference, thus messing up the address on replies and >such. Now you know! 8-) Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@WKUVX1.BITNET (or goathunter%wkuvx1.bitnet@UKCC.UKY.EDU) ================================================================================ Archive-Date: Fri, 05 Mar 1993 12:08:23 CST Sender: list-mgr@WKUVX1.BITNET Date: Fri, 5 Mar 93 08:10:20 PST Message-ID: <009690B614328060.23E027F3@gi.com> From: "Thomas E. Surber Jr. x2358" Reply-To: MX-List@WKUVX1.BITNET Subject: UUCP and SMTP Question To: mx-list@WKUVX1.BITNET I have just installed MX032 on my system for the first time. I would like to have mail that is LOCAL (IE: has .gi.com) devlivered via SMTP. All other mail sent out over our UUCP, when MX%"user@host" format is used. Right now to send mail LOCAL I user MX% but to send out to the internet I use UUCP bang method or IN% for Internet style addresses. Both use DECUS UUCP. I only have Internet mail access, via UUCP. I am not sure how to do this is this a rewrite or doamin path or ?? $~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~$ | Thomas E. Surber Jr. | Voice: (619) 455-1500 x2358 | | General Instrument | | | VideoCipher Division | Internet: Tsurber@GI.COM | | 6262 Lusk Blvd | Local: VCA::TSURBER | | San Diego, CA 92121 | | $~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~$ ================================================================================ Archive-Date: Fri, 05 Mar 1993 12:17:14 CST Sender: list-mgr@WKUVX1.BITNET Date: Fri, 5 Mar 93 16:36 GMT From: "UK TeX Archive Manager " Reply-To: MX-List@WKUVX1.BITNET To: MX-LIST%BITNET.WKUVX1@NSFNET-RELAY.AC.UK Subject: RE: MX implementation of mailing lists In message <00969090.50221660.21464@okra.millsaps.edu> dated Fri, 05 Mar 1993 03:39:59 CST Larry Horn wrote: > Last August I wrote: > [...] > > In other words, I'd like to see, when I read a message from a list > > with (LIST,SENDER), > > > > From: MX%"list@here",MX%"sender@here" > > To: me > > Subj: xxxx > > body > > > > so than when I REPLY > > > > To: MX%"list@here",MX%"sender@here" > > CC: > > Subj: RE: xxxx > > ... > > At the time, I believe the answer was "No" (I just happened to save my > original message; the replies, if any, are gone). > > This week I started playing with callable MAIL (for reasons totally > unrelated to MX) and discovered the MAIL$SEND_ADD_ATTRIBUTE() item code > MAIL$_SEND_FROM_LINE. > > This will let you stuff an arbitrary string into the "From:" line. I have > tested this briefly, and the "feature" I wished for above will work -- a > REPLY will indeed stuff the "From:" text into the "To:" line of the reply > and VAXmail will happily send the message to the multiple addresses. > > So, when can we expect to see this in MX ? (I've not installed V3.2 > yet -- I'd be pleasantly surprised to find it already there.) In the UK, we're stuck with using something called CBS (Colour Book Software) for handling incoming Grey-Book Mail (the GBM standard is *very* close to RFC-822) arriving over the Janet (X.25-based) network. The VMS implementation sets the VMSmail to appropriate values taken from the RFC-822 (sorry, GBM) headers. In particular, the VMSmail From: line is set to a replyable address, taking, in order of preference, the Reply-To header, the From header or failing both of those, the Sender header. If the Reply-to field contains two (or more) addressees, they both/all appear in the VMSmail From header, for example: ... From: Some-List@uk.ac.tex Reply_to: Joe Bloggs , One of TeX's lists To: System@uk.ac.tex Subject: An example mail header Cc: This will not appear will appear in the VMSmail headers something like this: From: CBS%UK.AC.NSFNET-RELAY::COM.HOST::J_BLOGGS,CBS%UK.AC.TEX::SOME-LIST To: SYSTEM CC: Subj: An example mail header (You'll note that CBS presents "DECnet-style" addresses, and that source routing is included --- just *another* of the crosses we have to bear! Furthermore, the current CBS has the annoying "feature" of up-casing *all* usernames --- the previous version used to preserve these correctly. DEC are still promising to fix this, over two years after it was reported to them.) I'd always assumed that *any* mailer would do this sort of massaging of what appears in the VMSmail From line --- from Larry's message, it would appear that my assumption was wrong! (Incidentally, one reason that I won't be going over to MLF for the lists that I administer is that [apart from MX not yet being able to handle incoming CBS mail, but I'm hoping to get on top of that problem] it doesn't offer as much flexibility as my home-grown DCL+Deliver_Mailshr+Janet_Mailshr system. The latter, for example, allows me to generate a "double-address" Reply-To, such as that illustrated above, when mail arrives for an OPEN list from a non-subscriber --- such that any replies will go to the original sender, the non-subscriber, as well as the other subscribers to the list, whereas mail sent from a subscriber just gets the list's own normal From header, so that replies just get re-exploded out again. I don't believe MLF can do that...yet.) Brian {Hamilton Kelly} System Manager for the UK TeX Archive at Aston University ================================================================================ Archive-Date: Fri, 05 Mar 1993 12:31:17 CST Sender: list-mgr@WKUVX1.BITNET Subject: Re: BITNET backlog (AAARRRRGGGGHHHHHH!) Message-ID: <1993Mar5.180405.1@sejnet.sunet.se> From: Date: Fri, 5 Mar 1993 18:04:05 GMT Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET In article <009690B3.30BAE9A0.8066@WKUVX1.BITNET>, Hunter Goatley writes: > Well, once again, the demand for FILESERV@WKUVX1.BITNET has greatly > exceeded the capabilities of our BITNET links (not mine so much as a > link upstream from me. As of this time ( 5-MAR-1993 07:45), there > are almost 1900 files queued from ULKYVM to UKCC. This does not surprise me given that there are many MX sites and only one person ordered MX from the VMS store. The MX you get from the VMS store is exactly the same as the one you get from FILESERV, and it comes in a single piece, in VMSDUMP format, at T1 speed, and without causing problems for Hunter and his users. All you have to do is type: $ send listserv@searn get [mx.mx032]mx032.zip If you need UNZIP.EXE, it's in [MACRO32]. FLQU.ZIP is not available because FTP.SPC.EDU got hit by a hurricane shortly after Hunter placed it there. Eric ================================================================================ Archive-Date: Fri, 05 Mar 1993 13:12:56 CST Sender: list-mgr@WKUVX1.BITNET Subject: Re: UUCP + MX = Ugly addresses Message-ID: <1993Mar5.174939.2190@netcom.com> From: Reply-To: MX-List@WKUVX1.BITNET Date: Fri, 5 Mar 1993 17:49:39 GMT To: MX-List@WKUVX1.BITNET >mark@infocomm.com writes about inhibiting translations i have had similar undesirable translations take place. mail with from_ well!user ..... after arrival on halfdome.sf.ca.us (the MX machine) wind up in VMS mail FROM addresses of mx%"user%well.UUCP@halfdome.sf.ca.us" while i can reply to these addresses, they do seem somewhat bizarre. i think the issue, mark, is that MX wants domain-style addresses and mx%"foo!bar" doesnt cut it. the foo%bar@site.domain tranformation at least gives some semblance of domainishness, although the long bang-style addresses you're seeing are quite unweildy. -- -- -- bob pasker -- rbp@netcom.com -- ================================================================================ Archive-Date: Fri, 05 Mar 1993 13:35:24 CST Sender: list-mgr@WKUVX1.BITNET Date: Fri, 05 Mar 1993 13:35:05 CST From: Hunter Goatley Reply-To: MX-List@WKUVX1.BITNET To: fsupdate@WKUVX1.BITNET, mx-list@WKUVX1.BITNET Message-ID: <009690E3.725A60E0.8244@WKUVX1.BITNET> Subject: ftp.spc.edu ftp.spc.edu is back on-line again..... Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@WKUVX1.BITNET (or goathunter%wkuvx1.bitnet@UKCC.UKY.EDU) ================================================================================ Archive-Date: Fri, 05 Mar 1993 15:47:25 CST Sender: list-mgr@WKUVX1.BITNET Subject: Re: BITNET backlog (AAARRRRGGGGHHHHHH!) Message-ID: <1993Mar5.214558.1@sejnet.sunet.se> From: Date: Fri, 5 Mar 1993 21:45:58 GMT Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET In article <1993Mar5.180405.1@sejnet.sunet.se>, eric@sejnet.sunet.se (Eric Thomas) writes: > If you need UNZIP.EXE, it's in [MACRO32]. FLQU.ZIP is not available because > FTP.SPC.EDU got hit by a hurricane shortly after Hunter placed it there. FLQU.ZIP is now available: $ send listserv@searn get [mx.mx032]flqu.zip Eric ================================================================================ Archive-Date: Fri, 05 Mar 1993 18:02:30 CST Sender: list-mgr@WKUVX1.BITNET Date: Sat, 06 Mar 1993 00:20:09 EST From: Herve CHOPLIN - UNIVERSITE FRANCOIS RABELAIS - TOURS Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <0096913D.8FD482E0.4169@FRUTRS51> Subject: RE: BITNET backlog (AAARRRRGGGGHHHHHH!) I have downloaded the files: MX032.ZIP FLQU.ZIP UNZIP.EXE from LISTSERV@SEARN.BITNET These files should be avalaible from MONDAY 8 MARS 1993 for the FRENCH NODES with an access to the Decnet french network of Education (EDUNET) Please these nodes send me a request ( CHOPLIN@FRUTRS51 or RABLAI(51410)::CHOPLIN ) for the location of these files. ---------------------------------------------------------------------------- Herve CHOPLIN (System Manager and Node Administrator) UNIVERSITY FRANCOIS RABELAIS Computing Center (Bat. D) Parc de Grandmont 37200 TOURS FRANCE _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._. Phone: (33).47.36.69.03 E-mail: EARN/BITNET: CHOPLIN@FRUTRS51.BITNET X400: C=FR;AD=0;PR=UNIV-TOURS;S=CHOPLIN INTERNET: CHOPLIN@UNIV-TOURS.FR VMS PSI_MAIL: PSI%(2080)3708047411::CHOPLIN IXI VMS PSI_MAIL: PSI%2043083016::CHOPLIN VMS DecNet (EDUnet): RABLAI::CHOPLIN or 51410::CHOPLIN (node 50.210) Fax : (33).47.36.69.02 **************************************************************************** LA TOURAINE, JARDIN DE FRANCE - THE TOURAINE, GARDEN OF FRANCE ---------------------------------------------------------------------------- ================================================================================ Archive-Date: Mon, 08 Mar 1993 20:02:52 CST Sender: list-mgr@WKUVX1.BITNET From: daveh@vax.oxford.ac.uk Reply-To: MX-List@WKUVX1.BITNET Subject: Two Routers anyone?? Message-ID: <1993Mar8.161310.12438@vax.oxford.ac.uk> Date: 8 Mar 93 16:13:10 GMT To: MX-List@WKUVX1.BITNET Hi, Has anybody tried running two Routers simultaneously on the same system? If so, I would be interested in knowing what the result was. Thanks, Dave -- David Hastings | "The technical axiom that nothing is VAX Systems Programmer | impossible sinisterly conditions one to Oxford University Computing Services| the pitfall corollary that nothing is daveh@vax.oxford.ac.uk | ridiculous" ================================================================================ Archive-Date: Mon, 08 Mar 1993 22:47:49 CST Sender: list-mgr@WKUVX1.BITNET Date: Mon, 08 Mar 1993 23:43:46 EST From: "John Murphy, Library System Mgr" Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <00969393.F9A4C880.24576@hal.hahnemann.edu> Subject: Re: Two Routers anyone?? In a previous article, daveh@vax.oxford.ac.uk wrote: > >Hi, > >Has anybody tried running two Routers simultaneously on the same system? If so, >I would be interested in knowing what the result was. > We have been running two simultaneous router processes for the last four months with good results. I often see both router processes working at the same time. We also run two Local and two SMTP processes. The Local processes are also often both working at the same time. I like have multiple instances of these processes because: 1) They provide some backup and redundancy in case one of the processes chokes and dies. 2) They seem to speed up the delivery of mail during peak periods, ie early morning and late afternoon. We are running MX 3.1C on MicroVAX 3100/80 under VMS 5.5-2. We typically receive between 500 and 800 email messages a day. Hope this helps... John ----------------------------------------------------------------------------- |John Murphy (JM66) |Internet: murphy@hal.hahnemann.edu / / / /|Library System Manager |VMS Mail: HAL::MURPHY /---/ / / |Hahnemann University |Beeper #: 1864 / / /___/ |245 N. 15th St., MS 449 |Voice: (215) 762-1042 |Phila., PA 19102-1192 |Fax: (215) 762-8180 ----------------------------------------------------------------------------- "It's a small world, but I wouldn't want to have to paint it" - Steve Wright ================================================================================ Archive-Date: Tue, 09 Mar 1993 01:59:21 CST Sender: list-mgr@WKUVX1.BITNET Date: Tue, 09 Mar 1993 08:50:43 +0100 From: "Herve GILIBERT, Universite de St-ETIENNE." Reply-To: MX-List@WKUVX1.BITNET To: mx-list@WKUVX1.BITNET Message-ID: <009693E0.628C07E0.4573@stroph.univ-st-etienne.fr> Subject: Mailing lists and SMTP delivery errors. Hello, I need help from mail gurus : When an error occurs delivering a mail from a mailing list, MX sends back a SMTP delivery error message to the list itself (because the Reply-To,From, Sender and Return-Path headers point to the multiple recipients list). Is there a way to tell MX to send errors to the Errors-To header which points to the list manager address. Thanks in advance. Herve. --------------------------------------------------------------------- Herve GILIBERT UUUU UUUU Universite Jean Monnet St-Etienne UUUU UUUU 23,Rue du Dr. P. Michelon UUUU UUUU 42023 ST ETIENNE Cedex 2 UUUU UUUU Tel : 33 77 42 15 79 UUUU UUUU Fax : 33 77 42 15 75 UUUU UUUU RFC822: gilibert@univ-st-etienne.fr UUUUUUUUUUU DECNET: 51.31::gilibert UUUUUUUUU ================================================================================ Archive-Date: Tue, 09 Mar 1993 06:56:47 CST Sender: list-mgr@WKUVX1.BITNET Date: Tue, 09 Mar 1993 06:56:31 CST From: Hunter Goatley Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET CC: gilibert@univ-st-etienne.fr Message-ID: <009693D0.6E4E3C20.9668@WKUVX1.BITNET> Subject: RE: Mailing lists and SMTP delivery errors. "Herve GILIBERT, Universite de St-ETIENNE." writes: > >Hello, >I need help from mail gurus : >When an error occurs delivering a mail from a mailing list, MX sends back a >SMTP delivery error message to the list itself (because the Reply-To,From, >Sender and Return-Path headers point to the multiple recipients list). They shouldn't be. Something else must be changing them. These are the relevant headers from your message to MX-List: >Return-Path: >Errors-To: list-mgr@WKUVX1.BITNET >Sender: list-mgr@WKUVX1.BITNET >Date: Tue, 09 Mar 1993 08:50:43 +0100 >From: "Herve GILIBERT, Universite de St-ETIENNE." > >Reply-To: MX-List@WKUVX1.BITNET Note that only "Reply-To:" is set to the list. >Is there a way to tell MX to send errors to the Errors-To header which points >to the list manager address. It sounds like it's not MX's SMTP returning these things. Are you passing through another gateway or something? Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@WKUVX1.BITNET (or goathunter%wkuvx1.bitnet@UKCC.UKY.EDU) ================================================================================ Archive-Date: Tue, 09 Mar 1993 07:41:32 CST Sender: list-mgr@WKUVX1.BITNET Message-ID: <<00969396.C90C4380.25095@uni-lj.> Date: Tue, 9 MAR 93 14:33 GMT From: rok.vidmar@uni-lj.si Reply-To: MX-List@WKUVX1.BITNET Subject: RE: MX V3.2 gamma (Help!) To: MX-List@WKUVX1.BITNET > >%MCP-W-SHUTRESF, command .... failed > >-SYSTEM-F-INVBUFLEN, invalid buffer length > > > If I remember right, the problem is that you still have an FLQ_SHR.EXE > installed... Well, I did not still have FLQ_SHR.EXE installed and I was not executing the V3.1 startup. But FLQ stuff was very good lead indeed. Somehow I persuaded VMSINSTAL to define MX_FLQ_NODE_NAME as FNT.UNI-LJ.SI instead of plain VEGA on that machine. It was not a bit difficult so I suggest a tiny safeguard to be incorporated into MX's VMSINSTAL. Thanks, Hunter! ("Pozdrav" means "regards" in Slovene.) ================================================================================ Archive-Date: Tue, 09 Mar 1993 11:33:56 CST Sender: list-mgr@WKUVX1.BITNET Date: 09 Mar 1993 09:38:42 -0700 (MST) From: ccvax@academic.cc.colorado.edu Subject: Router looping To: MX-List@WKUVX1.BITNET Reply-To: MX-List@WKUVX1.BITNET Message-ID: <009693E7.168769A0.4661@academic.cc.colorado.edu> I just upgraded (finally) MX3.1c on a MicroVAX 3400 running VMS5.4-2 and UCX 3.1 (with virtually all the patches). I don't know what took me so long. After 4 days with MX keeping up with our abuse, last night the router appeared to go into a loop. The queue directory was up to 80 blocks (low for mx2.1, high for mx3.1). It continued to grow with new messages so it wasn't a directory space problem. I set the router debug logical but no log file showed up. I tried to shutdown and restart the router, but it wouldn't shutdown. I eventually did a STOP/ID=C7E to kill the router process, restarted all of MX, and the mail is again being delivered. When I did a sho/proc/cont on the router it appeared to be in a fairly tight loop that involved a lot of buffered i/o. Any ideas? Thanks, Karen Michels ********************************************************************* * Karen Michels * * Academic Computing ccvax@cc.colorado.edu (internet) * * The Colorado College ccvax%ccnode@colorado (bitnet) * * 14 E. Cache La Poudre * * Colorado Springs, CO 80903 719-389-6457 * ********************************************************************* ================================================================================ Archive-Date: Tue, 09 Mar 1993 11:51:32 CST Sender: list-mgr@WKUVX1.BITNET Date: Tue, 09 Mar 1993 11:50:55 CST From: Hunter Goatley Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET CC: ccvax@academic.cc.colorado.edu Message-ID: <009693F9.8EA4C060.9862@WKUVX1.BITNET> Subject: RE: Router looping ccvax@academic.cc.colorado.edu writes: > >I just upgraded (finally) MX3.1c on a MicroVAX 3400 running VMS5.4-2 and >UCX 3.1 (with virtually all the patches). I don't know what took me so >long. > Did you upgrade to MX v3.2? >After 4 days with MX keeping up with our abuse, last night the router >appeared to go into a loop. The queue directory was up to 80 blocks >(low for mx2.1, high for mx3.1). It continued to grow with new messages >so it wasn't a directory space problem. I set the router debug logical >but no log file showed up. I tried to shutdown and restart the router, >but it wouldn't shutdown. I eventually did a STOP/ID=C7E to kill the >router process, restarted all of MX, and the mail is again being delivered. > This has happened to a handful of sites and I have no clue as to why. Naturally, it's never happened to me. 8-) I've been inclined to think that during the v3.2 upgrade some existing record in the FLQ file doesn't get converted properly, but that's only a wild guess. In any case, shutting down MX and/or rebooting the system has always made the problem go away. Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@WKUVX1.BITNET (or goathunter%wkuvx1.bitnet@UKCC.UKY.EDU) ================================================================================ Archive-Date: Tue, 09 Mar 1993 13:59:48 CST Sender: list-mgr@WKUVX1.BITNET Date: 09 Mar 1993 14:45:41 -0500 (EST) From: "Jonathan E. Hardis" Reply-To: MX-List@WKUVX1.BITNET Subject: RE: Mailing lists and SMTP delivery errors. To: MX-List@WKUVX1.BITNET CC: gilibert@stroph.univ-st-etienne.fr, hardis@garnet.nist.gov Message-ID: <00969411.F92C8E00.10708@garnet.nist.gov> > When an error occurs delivering a mail from a mailing list, MX sends back a > SMTP delivery error message to the list itself (because the Reply-To,From, > Sender and Return-Path headers point to the multiple recipients list). > Is there a way to tell MX to send errors to the Errors-To header which points > to the list manager address. Your message isn't clear. Is your host sending mail from foreign mailing list back to that list, or is mail from a list that you maintain being bounced back to the list itself by a foreign host? For the second interpretation, look in the Management Guide manual, for the command MCP> DEFINE LIST You can either give an explicit "Errors-To" address, or accept the default, which is the list owner. Perhaps you have the list owner set incorrectly. ================================================================================ Archive-Date: Tue, 09 Mar 1993 14:46:27 CST Sender: list-mgr@WKUVX1.BITNET Date: Tue, 09 Mar 1993 12:04:11 PST From: "W. Todd Wipke" Reply-To: MX-List@WKUVX1.BITNET To: mx-list@RPIECSVX.BITNET Message-ID: <009693FB.695EE720.6056@SECS.UCSC.EDU> Subject: Moderated lists I would like to request the moderated list feature be implemented. I run several lists and would like to eliminate some noise msgs about SUBSCRIBE sent to the wrong address, and SIGNOFF, etc. I do not want to lose the address of the original sender though, i.e., I would like the moderating to essentially be invisible. Any plans for this in the near future? A simple interim solution might be to have the ability to add a parameter to a list called a filter that could run a dcl procedure that could try to recognize Subscribe and Signoff msgs and direct them to the errors-to address by returning good or error. It would be a handle that we could use for other purposes too. PS: I got the email voting working fine. validation gives assurance of vaild voter to 1 in 10**18, and it sends back vote confirmation with all kinds of error checking. It hooks in via site_deliver.com. -Todd Wipke UCSC ================================================================================ Archive-Date: Tue, 09 Mar 1993 14:51:34 CST Sender: list-mgr@WKUVX1.BITNET Date: Tue, 09 Mar 1993 14:51:09 CST From: Hunter Goatley Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET CC: wipke@SECS.UCSC.EDU Message-ID: <00969412.BC3DFE60.9941@WKUVX1.BITNET> Subject: RE: Moderated lists "W. Todd Wipke" writes: > >I would like to request the moderated list feature be implemented. >I run several lists and would like to eliminate some noise msgs about >SUBSCRIBE sent to the wrong address, and SIGNOFF, etc. I do not want >to lose the address of the original sender though, i.e., I would like >the moderating to essentially be invisible. Any plans for this in >the near future? Yes. I was going to add it to v3.2, but ran out of time. I hope to have it implemented in v3.3. BTW, you sent this to MX-List@RPIECSVX.BITNET---you should be using WKUVX1.BITNET. I don't know how much longer RPIECSVX will be forwarding messages here. >PS: I got the email voting working fine. validation gives assurance >of vaild voter to 1 in 10**18, and it sends back vote confirmation with >all kinds of error checking. It hooks in via site_deliver.com. Good! Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@WKUVX1.BITNET (or goathunter%wkuvx1.bitnet@UKCC.UKY.EDU) ================================================================================ Archive-Date: Tue, 09 Mar 1993 18:39:46 CST Sender: list-mgr@WKUVX1.BITNET Date: 09 Mar 1993 18:19:29 -0500 (EST) From: "Jonathan E. Hardis" Reply-To: MX-List@WKUVX1.BITNET Subject: RE: Moderated lists To: MX-List@WKUVX1.BITNET CC: hardis@garnet.nist.gov Message-ID: <0096942F.D6D2A060.10720@garnet.nist.gov> > I would like to request the moderated list feature be implemented. Ah! As an expert now in using the SITE agent, here's an idea for you. Have the Reply-To address be a normal account, from which you would screen messages. If the message is acceptable, FORWARD it to an address which, because of the PATH rules, ends up in the SITE agent. Have SITE.COM strip off the few lines at the beginning of the message that got there from VMS MAIL (the FORWARDing), perhaps process the headers if required, change the destination address to a real mailing list, so the message is on its way. Of course, the details are left as an exercise to the reader. (I presume that you know, or can figure out, that you can call an editor to operate on the mail files, for example EDIT/EDT/COMMAND=.) ================================================================================ Archive-Date: Tue, 09 Mar 1993 19:54:36 CST Sender: list-mgr@WKUVX1.BITNET Message-ID: <00969439.B2C1F220.8454@uwwvax.uww.edu> Date: Tue, 09 Mar 1993 19:30:03 CST From: hunterl@uwwvax.uww.edu Reply-To: MX-List@WKUVX1.BITNET Subject: request To: mx-list@WKUVX1.BITNET Does a facility exist that would allow me to return to a user, in the same manner as when the required number of retries has been completed, a message that has clear error and never will be delivered? The returned message needs to include the message and the address at a minumum. The result would be a saving of computer cycles and a timely return of the message to the user. I understand that MAILQUE will tell the user of the problem, but they do not tend to use it and the message reamins in the queue. Lyle Hunter Computer Center University Wisconsin-Whitewater hunterl@uwwvax.uww.edu ================================================================================ Archive-Date: Wed, 10 Mar 1993 01:38:31 CST Sender: list-mgr@WKUVX1.BITNET Subject: Re: Two Routers anyone?? Message-ID: <1993Mar10.021830.1@sejnet.sunet.se> From: Date: Wed, 10 Mar 1993 02:18:30 GMT Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET In article <00969393.F9A4C880.24576@hal.hahnemann.edu>, "John Murphy, Library System Mgr" writes: > 2) They seem to speed up the delivery of mail during peak periods, ie > early morning and late afternoon. You bet! I am temporarily running the BITNET<->.FI gateway on a 3400 and 8 SMTP's is what it takes for files to get out at a rate comparable to the input rate :-) And as you know, it is NOT in your interest to let the queue grow big because then all hell breaks loose. The .SE gateway + core INTERBIT I run on my VM system has 50 SMTP threads and that is about what it takes to get the files out at the rate they're coming in. However on VM all threads run on the same process so you don't waste much memory by having many. On the other hand once you've reached a certain number (about 50), you need to fire up a second process if you want more because your SMTP is plagued with enough synchronous calls to be unable to handle more. The larger INTERBIT sites run 2-5 such processes at 50 each, but this is due to their enormous load (over 300k messages a day for the largest one). In any case, if you are running a gateway between SMTP and either BITNET or DECNET with more than a couple hundred messages a day you will want to run at least 4 SMTP's to provide a smooth service. Don't forget that the SMTP protocol has enormous timeouts and that there are machines which actually need such timeouts :-( At any given time during peak hours I have up to half a dozen "waiting" SMTP threads on my VM system, connections to hosts which simply take 30 seconds to a couple minutes to answer a RCPT TO:, so if you only run one SMTP you can end up not having any service for long periods of time just because of multiple recipients on a sluggish host. Anyway, in order to handle the load on a machine of that size equipped with two RF71's (and also doing a number of other things), I had to make a number of changes to the indexed file housing the queue. After running the gateway for a few hours, FLQU took 5-10 seconds between each line of output, and there were hundreds! I found out that my queue file was seriously fragmented, which makes sense since the FDL file it was created from started with a small allocation and the extension was 0. I started by changing that, and then allocating 20 global buffers as there are many processes sharing the file. The improvement in performance was tremendous, but alas, it started slowing down a couple hours later (not quite as slow as before though). I then changed the bucket size as 3 blocks with 512 byte records = 2 records + almost one wasted block. Anyway, to make a long story short, here is the FDL I finally ended up using: FILE CONTIGUOUS no BEST_TRY_CONTIGUOUS yes FILE_MONITORING no GLOBAL_BUFFER_COUNT 20 EXTENSION 512 ORGANIZATION indexed OWNER [1,4] PROTECTION (system:RWED, owner:RWED, group:RE, world:RE) NOTE: I have world:RE, you may want to change that! RECORD BLOCK_SPAN yes CARRIAGE_CONTROL none FORMAT fixed SIZE 512 AREA 0 ALLOCATION 2000 BEST_TRY_CONTIGUOUS yes BUCKET_SIZE 16 EXTENSION 16 AREA 1 ALLOCATION 32 BEST_TRY_CONTIGUOUS yes BUCKET_SIZE 8 EXTENSION 8 KEY 0 CHANGES no DUPLICATES no NULL_KEY no DATA_AREA 0 DATA_FILL 100 DATA_KEY_COMPRESSION no DATA_RECORD_COMPRESSION no INDEX_AREA 1 INDEX_COMPRESSION no INDEX_FILL 100 LEVEL1_INDEX_AREA 1 NAME "QENT_L_ENTNUM" PROLOG 3 SEG0_LENGTH 4 SEG0_POSITION 0 TYPE bin4 Remember to stop MX completely, including all processes which may feed it (JNET, whatever), before running CONVERT/FDL. Unlike CONVERT/RECLAIM this makes a new file, which means other processes might (potentially - I haven't read the source code) still get a chance to change the input file. I don't know what locks are taken exactly, whether the file version number is used before getting the lock, how the processes spin on the lock, etc. Anyway, I have already suggested to Hunter that, if MX doesn't make use of RFA's, it would be a lot more efficient in the long run to use CONVERT/FDL rather than CONVERT/RECLAIM, after having taken an exclusive lock on the input file. CONVERT/FDL reorganizes the file, it gives you a clean file which is fairly contiguous both as a whole and when looking at the internal index structure. The execution time depends mostly on the amount of entries in the file, and in practice I found it to be faster than CONVERT/RECLAIM (but unfortunately I have to stop MX to do that). CONVERT/RECLAIM only recovers file blocks which have turned out to become free because all the records they contained were deleted. It also somehow cleans the index structure. Repeated applications of CONVERT/RECLAIM prevent the file from extending forever, but everytime it does extend due to a real increase in the queue, the file becomes more fragmented. Also I don't know how intelligently VMS orders the reclaimed blocks on the free list. Anyway your file rots little by little until maximum entropy is reached, at which point you think MX has reached its natural limit :-) Another change which could help a lot on machines with RF71's is a "MX purger" process, whose only job would be to purge files which have been sent. Setting the router to purge every 5 minutes keeps the queues and directories small, but it also ties up the router too frequently in my opinion. I didn't know you could run two routers and maybe I should try that, but I think it would be best with a purger process which would free the router from queue management (maybe it would still need to run the CONVERT jobs, I'm afraid I haven't got used to BLISS code yet ;-) ). The purger could keep track of the amount of entries it purged and run the CONVERT/FDL after a predefined amount of entries, rather than wall-clock time; this way you don't clean up the file for nothing at night and you don't suffer degraded performance and unnecessary extends during the day if you get a burst of traffic after a line comes back. Anyway, MX stills beat the hell out of PMDF. The reason I had to take this gateway on my MV3400 is that it had been moved from a VM system to a MV3600 with RA80's and PMDF 4.1 (both outside my control), and the load was such that the turnaround time I observed during the weekend (for mail to an invalid user) was 26h, while during the day it simply prevented JNET from moving files at a decent speed and I was getting better performance to Poland with a saturated 32kbps channel than to Finland (512kbps, just upgraded to 1Mbps) :-) Eric ================================================================================ Archive-Date: Wed, 10 Mar 1993 11:18:43 CST Sender: list-mgr@WKUVX1.BITNET Subject: Re: Moderated lists Message-ID: <1993Mar10.155413.6217@netcom.com> From: Reply-To: MX-List@WKUVX1.BITNET Date: Wed, 10 Mar 1993 15:54:13 GMT To: MX-List@WKUVX1.BITNET hardis@garnet.nist.gov (Jonathan E. Hardis) writes: >(I presume that you know, or can figure out, that you can call an editor to >operate on the mail files, for example EDIT/EDT/COMMAND=.) i think two very useful pieces of standard code for writing site_delivery would be: (1) a set of subroutines that will perform some frequent operations. for example: (a) parse an 822 header into a linked list (b) allow the insertion/deletion of arbitrary lines (c) remove certain lines (e.g. all "received" lines) (d) replace the "value" of a field. (e) create a "new" message header (with things like date and msgid filled in). (f) others??? (2) program which will read a mail message form a file, parse its 822 header and place the value of certain fields in DCL symbols. -- -- bob pasker -- rbp@netcom.com -- ================================================================================ Archive-Date: Wed, 10 Mar 1993 11:34:57 CST Sender: list-mgr@WKUVX1.BITNET Date: Wed, 10 Mar 1993 08:41:56 CST From: Howard Meadows Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <009694A8.52ABB640.10854@cslvax.weeg.uiowa.edu> Subject: MLF /RETURN_ADDRESS Qualifier I am running a mailing list here, and I'm trying to get the list to specify a different address for the Reply-To: address. It appears that the /RETURN_ADDRESS should do this based on the help text: The /RETURN_ADDRESS qualifier is used to specify an alternate address that is to be used as the Reply-To address when /REPLY_TO=LIST is specified. This qualifier is most useful when multiple lists should have a common return address. For example, it can be used to redirect replies to a "-Digest" list back to the non-digest address. Here's my list definition: MCP> show list Mailing lists: Name: premed-advisor Owner: "TTaylor@MEDADMIN-PO.MEDADMIN.UIOWA.EDU" "TBates@MEDADMIN-PO.MEDADMIN.UIOWA.EDU" "meadows@CSLVAX.WEEG.UIOWA.EDU" "cmdssr@VAXA.WEEG.UIOWA.EDU" Reply-to: List, NOSender Archive: DISK$VAXUSER4:[CMDSSR.PMADVISOR.ARCHIVES] Add message: DISK$VAXUSER4:[CMDSSR.PMADVISOR.MESSAGES]ADD_MESSAGE.TXT Remove message: DISK$VAXUSER4:[CMDSSR.PMADVISOR.MESSAGES]REMOVE_MESSAGE.TXT Forwarded-to-owner message: - DISK$VAXUSER4:[CMDSSR.PMADVISOR.MESSAGES]FORWARD_MESSAGE.TXT Description: Pre-Med Advisors ListServ Errors-to: thomas-taylor@uiowa.edu Return address: premed-advisor@uiowa.edu Strip header: NOReceived Protection: (SYSTEM:RWED,OWNER:RWED,GROUP:WD,WORLD) As you can see, the list name is "premed-advisor" and the complete, actual address for the list is : "premed-advisor@VAXA.WEEG.UIOWA.EDU". What I desire is when mail is received from the list, the From: line of VMS mail (what VMS mail uses when you type REPLY) is the address specified in the /RETURN_ADDRESS qualifier of the list definition (which in this case would be "premed-advisor@uiowa.edu". I think I have it defined properly, but mail received fromt he list still has the "premed-advisor@VAXA.WEEG.UIOWA.EDU" address in the VMS mail From: header. Can anyone tell me what I need to do to achieve the desired results? Thanks, Howard *************************************************************************** * Howard Meadows Sr. Systems Programmer Weeg Computing Center * * University Of Iowa Iowa City, Iowa 52242 Phone: 319-335-5519 * * email: howard-meadows@uiowa.edu * *************************************************************************** ================================================================================ Archive-Date: Wed, 10 Mar 1993 11:48:51 CST Sender: list-mgr@WKUVX1.BITNET Date: Wed, 10 Mar 1993 11:48:28 CST From: Hunter Goatley Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <009694C2.618B8C20.10317@WKUVX1.BITNET> Subject: RE: MLF /RETURN_ADDRESS Qualifier Howard Meadows writes: > > I am running a mailing list here, and I'm trying to get the list >to specify a different address for the Reply-To: address. It appears >that the /RETURN_ADDRESS should do this based on the help text: > Yes, it will. >Mailing lists: > Name: premed-advisor > Reply-to: List, NOSender > Return address: premed-advisor@uiowa.edu This should be right. >As you can see, the list name is "premed-advisor" and the complete, actual >address for the list is : "premed-advisor@VAXA.WEEG.UIOWA.EDU". What I >desire is when mail is received from the list, the From: line of VMS mail >(what VMS mail uses when you type REPLY) is the address specified in the >/RETURN_ADDRESS qualifier of the list definition (which in this case would >be "premed-advisor@uiowa.edu". I think I have it defined properly, but >mail received fromt he list still has the "premed-advisor@VAXA.WEEG.UIOWA.EDU" >address in the VMS mail From: header. > What do the RFC822 headers show? It should show "premed-advisor@uiowa.edu" on the "Reply-To:" line. Does it? > Can anyone tell me what I need to do to achieve the desired results? > That's how I've got one of my lists set up: Mailing lists: Name: Info-ZIP-Digest Owner: "goathunter@WKUVX1.BITNET" Reply-to: List, NOSender Archive: WKU$WORK:[MXMAILER.INFO-ZIP-DIGEST] Add message: MX_MLIST_DIR:INFO-ZIP_ADD_MESSAGE.TXT Description: Info-ZIP Digests Errors-to: goathunter@WKUVX1.BITNET Return address: Info-ZIP@WKUVX1.BITNET Strip header: NOReceived Protection: (SYSTEM:RWED,OWNER:RWED,GROUP:ED,WORLD:ED) Could the SMTP stuff be changing the host name? I haven't played with this part enough to know. Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@WKUVX1.BITNET (or goathunter%wkuvx1.bitnet@UKCC.UKY.EDU) ================================================================================ Archive-Date: Wed, 10 Mar 1993 11:50:27 CST Sender: list-mgr@WKUVX1.BITNET Return-Path: Date: Wed, 10 Mar 1993 18:44:36 EST From: Why not ? Reply-To: MX-List@WKUVX1.BITNET To: mx-list@WKUVX1.BITNET Message-ID: <009694FC.83BB2D9B.28859@cal.enst.fr> Subject: wish for next release I think mx_exe:mx_start.com should specify an UIC when creating detached processes... bad things can occur if several mx processes run with different uic. ================================================================================ ! Guillaume Gerard ! Email gerard@enst.fr ! ! Systems responsible ! X400 C=FR AD=ATLAS PD=TELECPARIS ! ! France Telecom University ! PSI *20807504128505::gerard ! ================================================================================ %SYSTEM-W-TMNYFNGRS, too many fingers on keyboard ================================================================================ Archive-Date: Wed, 10 Mar 1993 13:03:44 CST Sender: list-mgr@WKUVX1.BITNET Date: Wed, 10 Mar 1993 10:53 PDT From: TSAI@ACUSD.BITNET Reply-To: MX-List@WKUVX1.BITNET Subject: mx configuration To: mx-list@WKUVX1.BITNET I am the first timer of mx community, and your pointer to following questions is greatly appreciated. 1. For DECnet node to send/receive smtp mail to the Internet, is smtp-over- decnet the additional required component? 2. For machine with DECnet and Multinet(tcp/ip), can i install smtp-over-decnet over it to test its functionality while Multinet's smtp is running? 3. Can i install smtp-over-decnet onto routing node? During running mxconfig, i was informed "as end node with only smtp-over-decnet as your mail transport... 4. Are users are only allowed to send smtp mails to those nodes specified in the remote smtp-over-decnet during mxconfig session? Again, your valuable info is greatly acknowledged. Allen Tsai University of San Diego tsai@usdcsv.acusd.edu (Internet) tsai@acusd.BITNET ================================================================================ Archive-Date: Wed, 10 Mar 1993 15:51:49 CST Sender: list-mgr@WKUVX1.BITNET Date: Wed, 10 Mar 1993 13:39 PDT From: TSAI@ACUSD.BITNET Reply-To: MX-List@WKUVX1.BITNET Subject: mx mail gateway server To: mx-list@WKUVX1.BITNET Thank you for several responses to my earlier mx configuration. Now, the real thing we try to accomplish in my institution is to have DECnet-only nodes send/receive smtp mails to the Internet using a machine with DECnet and Multinet (tcp/ip) as mail gateway. How is it to be done? Do i put smtp-over-DECnet module on DECnet-only nodes while smtp interface on the latter node? Can anyone send to me samples of your site configurations or any caveats? Thanks! Allen Tsai University of San Diego tsai@usdcsv.acusd.edu tsai@acusd.bitnet ================================================================================ Archive-Date: Wed, 10 Mar 1993 18:01:04 CST Sender: list-mgr@WKUVX1.BITNET Subject: bouncy-bouncy Message-ID: <1993Mar10.230845.9657@netcom.com> From: Reply-To: MX-List@WKUVX1.BITNET Date: Wed, 10 Mar 1993 23:08:45 GMT To: MX-List@WKUVX1.BITNET i have a guy who keeps sending mail to which MLF cannot reply. the message goes out, bounces at his site, and gets passed back to MLF, which tries to reprocess the bounce message. how can i disable this guy from sending stuff? how about adding /NOACCESS=, where list-name is a mailing list of all the folks being excluded. this would work the smae way /MAILING_LIST would work, except it would *exclude* those users. -- -- bob pasker -- rbp@netcom.com -- ================================================================================ Archive-Date: Wed, 10 Mar 1993 18:26:56 CST Sender: list-mgr@WKUVX1.BITNET Subject: Multiple transports for lists. Message-ID: <1993Mar10.160542.183@vedur.is> From: Reply-To: MX-List@WKUVX1.BITNET Date: 10 Mar 93 16:05:42 GMT To: MX-List@WKUVX1.BITNET Hi. I am trying to set up mailing lists on my site. I can set it up so that Internet users can use it, no problem there. But DECnet-connected users is another matter. I don't seem to be able to get that working. If a DECnet user sends a message then it gets in alright, but when that is replied to by an Internet user, the From: address is wrong. It is in the form "node::user"@domain (ex. "kaldi::hb1"@vedur.is) and that address is not accepted by my domain mail gateway (UNIX). I have tried PSI-mail also and that format is even worse (something like "psi%icepak.hugbun::vsi02"@vedur.is ). If I change the /Reply_to to LIST,NOSender will the from address be somthing simple as list@domain? Well, what I am really asking about is, can MX/MLF be set up in such a way that both Internet, DECNET-connected and even PSI-MAIL users can use tha same mailing lists? (And the Internet users be happy with the From: header) Best regards, gulli -- --------------------------------------------------------------------------- Gunnlaugur Kristjansson Email......: gulli@vedur.is Systems Analyst PSImail....: 274011724200::gulli Data Processing Division DECUS mail.: EDCHUB::KRISTJANSSON Icelandic Meteorological Office COMPUSERVE.: 72461,2160 Bustadavegi 9 Telephone..: +354 1 600600 IS150 Reykjavik Telefax....: +354 1 28121 Iceland. --------------------------------------------------------------------------- ================================================================================ Archive-Date: Wed, 10 Mar 1993 19:55:24 CST Sender: list-mgr@WKUVX1.BITNET Date: 10 Mar 1993 13:48:07 -0700 (MST) From: Dan Wing Reply-To: MX-List@WKUVX1.BITNET Subject: Re: mx configuration To: MX-List@WKUVX1.BITNET CC: TSAI@ACUSD.BITNET Message-ID: <01GVN8M21SUA006I6A@VAXF.COLORADO.EDU> Allen Tsai, tsai@usdcsv.acusd.edu, writes: >I am the first timer of mx community, and your pointer to following questions >is greatly appreciated. >1. For DECnet node to send/receive smtp mail to the Internet, is smtp-over- >decnet the additional required component? >2. For machine with DECnet and Multinet(tcp/ip), can i install smtp-over-decnet >over it to test its functionality while Multinet's smtp is running? >3. Can i install smtp-over-decnet onto routing node? During running mxconfig, >i was informed "as end node with only smtp-over-decnet as your mail transport.. . >4. Are users are only allowed to send smtp mails to those nodes specified in >the remote smtp-over-decnet during mxconfig session? >Again, your valuable info is greatly acknowledged. SMTP-over-DECnet is useful if you have VAXes that don't have Multinet. You install Multinet on node A, and enable SMTP-over-DECnet -- then all the other nodes use SMTP-over-DECnet to communicate with node A to send/receive SMTP mail. Basically, node A acts as a SMTP <-> DECnet mail gateway, but is transparent to all your users (except that node A will appear in the RFC headers, which isn't a big deal). If all nodes are in a VAXcluster, you don't need to run SMTP-over-DECnet -- node A can run your TCP/IP package, and MX can run on just node A (some components (like the LOCAL agent, I believe) can run on all nodes if you prefer). I've got SMTP-over-DECnet about 1/2 setup between my system and a system running PMDF with UCX -- it works pretty well so far. -Dan Wing, dwing@uh01.colorado.edu or wing_d@ucolmcc.bitnet (DGW11) Systems Administrator, University Hospital, Denver ================================================================================ Archive-Date: Wed, 10 Mar 1993 19:57:20 CST Sender: list-mgr@WKUVX1.BITNET Date: Wed, 10 Mar 1993 12:04:45 CST From: Howard Meadows Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <009694C4.A7A04DC0.10901@cslvax.weeg.uiowa.edu> Subject: RE: MLF /RETURN_ADDRESS Qualifier > >Howard Meadows writes: >> >> I am running a mailing list here, and I'm trying to get the list >>to specify a different address for the Reply-To: address. It appears >>that the /RETURN_ADDRESS should do this based on the help text: >> >Yes, it will. > >>Mailing lists: >> Name: premed-advisor >> Reply-to: List, NOSender >> Return address: premed-advisor@uiowa.edu > >This should be right. > >What do the RFC822 headers show? It should show >"premed-advisor@uiowa.edu" on the "Reply-To:" line. Does it? > Yes, it does, but the VMS MAIL From: line shows "premed-advisor@vaxa.weeg.uiowa.edu" >> >> Can anyone tell me what I need to do to achieve the desired results? >> >That's how I've got one of my lists set up: > >Mailing lists: > Name: Info-ZIP-Digest > Owner: "goathunter@WKUVX1.BITNET" > Reply-to: List, NOSender > Archive: WKU$WORK:[MXMAILER.INFO-ZIP-DIGEST] > Add message: MX_MLIST_DIR:INFO-ZIP_ADD_MESSAGE.TXT > Description: Info-ZIP Digests > Errors-to: goathunter@WKUVX1.BITNET > Return address: Info-ZIP@WKUVX1.BITNET > Strip header: NOReceived > Protection: (SYSTEM:RWED,OWNER:RWED,GROUP:ED,WORLD:ED) > >Could the SMTP stuff be changing the host name? I haven't played with >this part enough to know. > >Hunter >------ Hunter; Thanks for the info. Your lists look just like the way I've got mine set up. I'm not sure about the answer to the question about the SMTP stuff changing the host name. What would cause this to happen? I don't have any special rewrite rules defined. I'm using UCX 2.0 with MX 3.2 if that gives you any clue. -Howard *************************************************************************** * Howard Meadows Sr. Systems Programmer Weeg Computing Center * * University Of Iowa Iowa City, Iowa 52242 Phone: 319-335-5519 * * email: howard-meadows@uiowa.edu * *************************************************************************** ================================================================================ Archive-Date: Wed, 10 Mar 1993 20:16:50 CST Sender: list-mgr@WKUVX1.BITNET Subject: Re: bouncy-bouncy Message-ID: <1993Mar10.173039.1@cudnvr.denver.colorado.edu> From: Reply-To: MX-List@WKUVX1.BITNET Date: 10 Mar 93 17:23:39 GMT To: MX-List@WKUVX1.BITNET In article <1993Mar10.230845.9657@netcom.com>, rbp@netcom.com (Bob Pasker) writes: > i have a guy who keeps sending mail to which MLF cannot reply. the > message goes out, bounces at his site, and gets passed back to MLF, > which tries to reprocess the bounce message. how can i disable this > guy from sending stuff? > > how about adding /NOACCESS=, where list-name is a mailing list > of all the folks being excluded. this would work the smae way /MAILING_LIST > would work, except it would *exclude* those users. Have you sent a message to POSTMASTER@site about the problem? -Dan Wing, dwing@uh01.colorado.edu or wing_d@ucolmcc.bitnet (DGW11) Systems Administrator, University Hospital, Denver ================================================================================ Archive-Date: Wed, 10 Mar 1993 21:16:17 CST Sender: list-mgr@WKUVX1.BITNET Date: Wed, 10 Mar 1993 21:15:57 CST From: Hunter Goatley Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <00969511.A8286280.10501@WKUVX1.BITNET> Subject: Re: bouncy-bouncy writes: > >In article <1993Mar10.230845.9657@netcom.com>, rbp@netcom.com (Bob Pasker) >writes: > >> i have a guy who keeps sending mail to which MLF cannot reply. the >> message goes out, bounces at his site, and gets passed back to MLF, >> which tries to reprocess the bounce message. how can i disable this >> guy from sending stuff? [...] > >Have you sent a message to POSTMASTER@site about the problem? > This is why I beefed up the RFC822 headers for MLF stuff in v3.2. I added the Sender:, Errors-To:, and Warnings-To: headers---if a site is not sending these back to Sender:, then, according to RFC822, they're in error and should be notified. Of course, they probably will argue with you.... Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@WKUVX1.BITNET (or goathunter%wkuvx1.bitnet@UKCC.UKY.EDU) ================================================================================ Archive-Date: Wed, 10 Mar 1993 21:31:10 CST Sender: list-mgr@WKUVX1.BITNET Date: 10 Mar 1993 16:29:12 -0700 (MST) From: Dan Wing Reply-To: MX-List@WKUVX1.BITNET Subject: Re: mx mail gateway server To: MX-List@WKUVX1.BITNET CC: tsai@usdcsv.acusd.edu Message-ID: <01GVNE4C148Y0036YY@VAXF.COLORADO.EDU> Allen Tsai, tsai@usdcsv.acusd.edu, writes: >Thank you for several responses to my earlier mx configuration. Now, the real >thing we try to accomplish in my institution is to have DECnet-only nodes >send/receive smtp mails to the Internet using a machine with DECnet and Multine t >(tcp/ip) as mail gateway. How is it to be done? Do i put smtp-over-DECnet modul e >on DECnet-only nodes while smtp interface on the latter node? Can anyone send >to me samples of your site configurations or any caveats? Thanks! 1. Install Multinet on node A. Disable Multinet's SMTP. 2. Install MX on node A, with: - SMTP - SMTP-over-DECnet Your PATH configuration would probably be something like: Domain="node1.usdcsv.acusd.edu", Path=DECnet_SMTP, Route=node1 Domain="node2.usdcsv.acusd.edu", Path=DECnet_SMTP, Route=node2 Domain="node3.usdcsv.acusd.edu", Path=DECnet_SMTP, Route=node3 Domain="node4.usdcsv.acusd.edu", Path=DECnet_SMTP, Route=node4 3. Install MX on all other nodes, with: - SMTP-over-DECnet The PATH configuration for these nodes will be something like: Domain="UH01.Colorado.EDU", Path=Local Domain="UH01", Path=Local Domain="UH01.Colorado", Path=Local Domain="*", Path=DECnet_SMTP, Route="A" where "A" should be replaced by the node that has Multinet installed. I've setup #3, but I've never needed to do #2, so my advice may be incorrect -- somone please correct me if necesary... This will allow all users on all nodes to send mail using the simple MX%"address" method. If your Multinet node is in a VAXcluster, the nodes in the VAXcluster don't need to have SMTP-over-DECnet installed, or running -- those nodes should have mail delivered with the LOCAL path. -Dan Wing, dwing@uh01.colorado.edu or wing_d@ucolmcc.bitnet (DGW11) Systems Administrator, University Hospital, Denver ================================================================================ Archive-Date: Wed, 10 Mar 1993 21:43:30 CST Sender: list-mgr@WKUVX1.BITNET Date: Wed, 10 Mar 1993 15:52 PDT From: SYSTEM@ACUSD.BITNET Reply-To: MX-List@WKUVX1.BITNET Subject: smtp mails still queued after MX configured and started To: mx-list@WKUVX1.BITNET Can anyone take a look at my config.mcp and mqueue output, and give some suggestions where may go wrong or where to start troublshooting? I have no smtp mails delivered to my unix node, after mx installed and started at node with DECnet and Multinet(tcp/ip). Thank you in advance. ---------------------- config.mcp ------------------ ! MX_DEVICE:[MX]CONFIG.MCP;9 ! Created: 10-MAR-1993 14:11:29.62 by MXCONFIG ! DEFINE PATH "usdcsv" LOCAL DEFINE PATH "usdcsv.acusd.edu" LOCAL DEFINE PATH "192.55.87.6" LOCAL DEFINE PATH *.UUCP SMTP/ROUTE="uunet.uu.net" DEFINE PATH *.BITNET SMTP/ROUTE="cunyvm.cuny.edu" DEFINE PATH "usdcsv.dnet" LOCAL DEFINE PATH "teetot.dnet" DECNET_SMTP/ROUTE=teetot DEFINE PATH "adp63.dnet" DECNET_SMTP/ROUTE=adp63 DEFINE PATH "lawsv1.dnet" DECNET_SMTP/ROUTE=lawsv1 DEFINE PATH "ursv1.dnet" DECNET_SMTP/ROUTE=ursv1 ! NOTE: The next path definition should always be LAST. DEFINE PATH * SMTP ! ! Done with routing information. ! ---------------------------- mqueue output -------------------- Entry: 359, Origin: [Local] Status: IN-PROGRESS SMTP entry #366, status: READY Recipient #1: , Route=teetot.acusd.edu Entry: 357, Origin: [Local] Status: IN-PROGRESS SMTP entry #369, status: READY Recipient #1: , Route=teetot Entry: 358, Origin: [Local] Status: IN-PROGRESS SMTP entry #370, status: READY Recipient #1: , Route=teetot Entry: 363, Origin: [Local] Status: IN-PROGRESS SMTP entry #371, status: READY Recipient #1: , Route=teetot.acusd.edu Entry: 361, Origin: [Local] Status: IN-PROGRESS SMTP entry #374, status: READY Recipient #1: , Route=cubldr.colorado.edu Entry: 377, Origin: [Local] Status: IN-PROGRESS SMTP entry #378, status: READY Recipient #1: , Route=teetot.acusd.edu ================================================================================ Archive-Date: Thu, 11 Mar 1993 01:06:52 CST Sender: list-mgr@WKUVX1.BITNET Subject: Re: bouncy-bouncy Message-ID: <1993Mar11.062035.19568@netcom.com> From: Reply-To: MX-List@WKUVX1.BITNET Date: Thu, 11 Mar 1993 06:20:35 GMT To: MX-List@WKUVX1.BITNET dwing@cudnvr.denver.colorado.edu (Dan Wing) writes: >In article <1993Mar10.230845.9657@netcom.com>, rbp@netcom.com (Bob Pasker) >writes: >> i have a guy who keeps sending mail to which MLF cannot reply. >Have you sent a message to POSTMASTER@site about the problem? if i can't reach the site.... -- -- bob pasker -- rbp@netcom.com -- ================================================================================ Archive-Date: Thu, 11 Mar 1993 03:56:03 CST Sender: list-mgr@WKUVX1.BITNET Date: Thu, 11 Mar 1993 13:04:52 -0305 From: ALI SHOKOUFANDEH Reply-To: MX-List@WKUVX1.BITNET To: mx-list@WKUVX1.BITNET Message-ID: <00969596.37E53680.3091@IREARN.BITNET> Dear Friends, I have a serious problem with Mx queue, durins last couple of days our communication line was disconnected after repairing if a lot of files have received by our Jnet, The mx hold them in the queue and didn't distribut them, I have tried the reset option but nothing didn't happen, Finally I rebooted the system, and then mx have started distributing files in queue but not completly after rebooting aging if emptized the queue. Is there anybody who can help me in this regard. Cheers Ali. ================================================================================ Archive-Date: Thu, 11 Mar 1993 08:45:59 CST Sender: list-mgr@WKUVX1.BITNET Date: Thu, 11 Mar 1993 09:05:24 EST From: "Brian Tillman, Smiths Industries, VAX Support, x8425" Reply-To: MX-List@WKUVX1.BITNET To: WKUVX1.BITNET!MX-list@esseye.si.com Message-ID: <00969574.C4AE4A60.4433@swdev.si.com> Subject: RE: ALI SHOKOUFANDEH (ali@IREARN.BITNET) writes: >Finally I rebooted the system, and then mx have started distributing >files in queue but not completly after rebooting aging if >emptized the queue. Ali, what does "aging if emptized the queue" mean in English? -----------------------------+-------------------------------- Brian Tillman | Internet: tillman@swdev.si.com Smiths Industries, Inc. | tillman_brian@si.com 4141 Eastern Ave., MS129 | Hey, I said this stuff myself. Grand Rapids, MI 49518-8727 | My company has no part in it. -----------------------------+-------------------------------- ================================================================================ Archive-Date: Thu, 11 Mar 1993 13:50:26 CST Sender: list-mgr@WKUVX1.BITNET Date: 11 Mar 1993 13:03:01 -0500 (EST) From: "Jonathan E. Hardis" Reply-To: MX-List@WKUVX1.BITNET Subject: Re: mx mail gateway server To: MX-List@WKUVX1.BITNET CC: hardis@garnet.nist.gov Message-ID: <00969595.F6053300.10843@garnet.nist.gov> > 1. Install Multinet on node A. > Disable Multinet's SMTP. > > 2. Install MX on node A, with: > - SMTP > - SMTP-over-DECnet > > Your PATH configuration would probably be something like: > Domain="node1.usdcsv.acusd.edu", Path=DECnet_SMTP, Route=node1 > Domain="node2.usdcsv.acusd.edu", Path=DECnet_SMTP, Route=node2 > Domain="node3.usdcsv.acusd.edu", Path=DECnet_SMTP, Route=node3 > Domain="node4.usdcsv.acusd.edu", Path=DECnet_SMTP, Route=node4 > > 3. Install MX on all other nodes, with: > - SMTP-over-DECnet > > The PATH configuration for these nodes will be something like: > Domain="UH01.Colorado.EDU", Path=Local > Domain="UH01", Path=Local > Domain="UH01.Colorado", Path=Local > Domain="*", Path=DECnet_SMTP, Route="A" > > where "A" should be replaced by the node that has Multinet installed. > > I've setup #3, but I've never needed to do #2, so my advice may be incorrect. > Someone please correct me if necesary... I can't verify what you said in all details, but it's also clear that you would have to have name server records (MX records) for node1.usdcsv.acusd.edu, node2.usdcsv.acusd.edu, etc. Also, the path statements for node1-node4 should have Path=Local for node1 node1.usdcsv node1.usdcsv.acusd node1.usdcsv.acusd.edu DECNET <-- the Decnet node name (perhaps more) ================================================================================ Archive-Date: Thu, 11 Mar 1993 17:58:18 CST Sender: list-mgr@WKUVX1.BITNET Date: Thu, 11 Mar 1993 16:12:45 CST From: sysmail@MNSMC1.MNSMC.EDU Reply-To: MX-List@WKUVX1.BITNET To: mx-list@WKUVX1.BITNET Message-ID: <009695B0.776FD980.18890@MNSMC1> Subject: compiling question I am looking at changing the code in one mx module. Given a bliss compiler, is it difficult to recompile one module of mx and reintegrate it with the rest of the executable code and vmsinstal it? Does anyone have any commmand files or hints to effect this? Thanks for any insight that you have on this job (i.e don't do it, do it etc!) ============================================================================== Daniel W. Bick St. Mary's College of Minnesota 700 Terrace Heights System Manager and Programmer Computer Center #17 dbick@mnsmc1.mnsmc.edu -or- Winona, MN 55987-1399 dwb@marys.mnsmc.edu (NeXTmail) (507)457-1732 ================================================================================ Archive-Date: Thu, 11 Mar 1993 20:31:27 CST Sender: list-mgr@WKUVX1.BITNET From: Subject: Re: bouncy-bouncy Date: 12 Mar 1993 01:43:14 GMT Message-ID: <1nopriINNh7f@gap.caltech.edu> Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET In article <1993Mar11.062035.19568@netcom.com>, rbp@netcom.com (Bob Pasker) writes: =dwing@cudnvr.denver.colorado.edu (Dan Wing) writes: =>In article <1993Mar10.230845.9657@netcom.com>, rbp@netcom.com (Bob Pasker) =>writes: =>> i have a guy who keeps sending mail to which MLF cannot reply. =>Have you sent a message to POSTMASTER@site about the problem? = =if i can't reach the site.... ...then neither can the mail from MLF, so you don't have a problem, right? By definition, you *CAN* reach the site that's bouncing the messages back to the list. That's the site to which you need to complain. -------------------------------------------------------------------------------- Carl J Lydick | INTERnet: CARL@SOL1.GPS.CALTECH.EDU | NSI/HEPnet: SOL1::CARL Disclaimer: Hey, I understand VAXen and VMS. That's what I get paid for. My understanding of astronomy is purely at the amateur level (or below). So unless what I'm saying is directly related to VAX/VMS, don't hold me or my organization responsible for it. If it IS related to VAX/VMS, you can try to hold me responsible for it, but my organization had nothing to do with it. ================================================================================ Archive-Date: Thu, 11 Mar 1993 20:38:01 CST Sender: list-mgr@WKUVX1.BITNET From: Subject: Re: mx mail gateway server Date: 12 Mar 1993 01:55:55 GMT Message-ID: <1noqjbINNh7f@gap.caltech.edu> Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET In article <01GVNE4C148Y0036YY@VAXF.COLORADO.EDU>, Dan Wing writes: >If your Multinet node is in a VAXcluster, the nodes in the VAXcluster don't >need to have SMTP-over-DECnet installed, or running -- those nodes should >have mail delivered with the LOCAL path. Note: That's true ONLY if the cluster is homogenous. For a non-homogenous cluster, this doesn't work (I manage a non-homogenous cluster since, from time to time, one or more of the nodes in the cluster do on the road; it's easier to just run a non-homogenous cluster than to reconfigure the nodes that move around all the time). -------------------------------------------------------------------------------- Carl J Lydick | INTERnet: CARL@SOL1.GPS.CALTECH.EDU | NSI/HEPnet: SOL1::CARL Disclaimer: Hey, I understand VAXen and VMS. That's what I get paid for. My understanding of astronomy is purely at the amateur level (or below). So unless what I'm saying is directly related to VAX/VMS, don't hold me or my organization responsible for it. If it IS related to VAX/VMS, you can try to hold me responsible for it, but my organization had nothing to do with it. ================================================================================ Archive-Date: Thu, 11 Mar 1993 21:57:28 CST Sender: list-mgr@WKUVX1.BITNET Date: Thu, 11 Mar 1993 10:40:44 CST From: Howard Meadows Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <00969582.155CF8A0.11023@cslvax.weeg.uiowa.edu> Subject: MX 3.2 with UCX 2.0 It seems I have sort of a catch-22 situation here with MX 3.2 and UCX 2.0. We have been running MX 3.2 successfully for a couple of weeks with UCX 1.3a. This weekend, we upgraded UCX to version 2.0 because we wanted to take advantage of the LPR support. We thought we were real smart when we disobeyed the documentation when the UCX$CONFIG asked for a host name and we gave it our FQDN of "vaxa.weeg.uiowa.edu". After the installation, MX worked flawlessly, and we fired up a couple of LPR queues. They also worked, but reported a host name of "vaxa.weeg.uiowa.edu.weeg.uiowa.edu" !?? The programmer who did the installation called DEC support and they said "oh, you defined UCX$INET_HOST incorrectly, it should be just 'vaxa'". Well, the programmer re-ran UCX$CONFIG and specified just "vaxa" for the host name, and viola' the LPR stuff worked fine, but now the MX mail reply address was incorrectly specifying just "user@vaxa". :-( Is there a fix to this dilemma? - I should say that the LPR printing *did* work, it's just that it showed the incorrect host node name. -Howard *************************************************************************** * Howard Meadows Sr. Systems Programmer Weeg Computing Center * * University Of Iowa Iowa City, Iowa 52242 Phone: 319-335-5519 * * email: howard-meadows@uiowa.edu * *************************************************************************** ================================================================================ Archive-Date: Thu, 11 Mar 1993 22:17:51 CST Sender: list-mgr@WKUVX1.BITNET Date: Thu, 11 Mar 1993 20:13:26 PST From: Virtual Bill Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <009695D2.169F2E40.21713@gtewd> Subject: A novice in need of Assistance Another novice looking for assistance. Early this week we implemented a domain name change. After making the necessary changes to the CONFIG.MCP file and one line in the MX_LOGICALS.DAT file It appeared that all was well. However, today seemed to turn out otherwise. I have a 5 node cluster with a cluster alias. There are various VAX work- stations, MAC/PC's and UNIX workstations on the LOCAL net that are accessible through the Internet. The problem: MX mail can be sent to the VAX Cluster from any location without a hitch, but the cluster can only send mail outside the LOCAL net. The CONFIG.MCP file looks the same before the domain name change except for the key name, example of one of the changes: DEFINE PATH "f.mtv.gsc.gte.com" LOCAL changed to DEFINE PATH "f.mtv.gtegsc.com" LOCAL I've set the various _debug logicals without any problem being identified. Although, I didn't get a log for the MX_SITE_DEBUG logical. The mail to the Postmaster shows the "To:" address to be correct. I ran he MXCONFIG.COM file a second time and created another copy of the CONFIG.MCP file and activated it through MCP, shutdown the MX Mail services across the cluster and restarted it, and still no go. Can someone give me a clue as to what I am not doing or what I'm doing wrong. Any assistance would be greatly appreciated. ================================================================================ Archive-Date: Fri, 12 Mar 1993 01:30:58 CST Sender: list-mgr@WKUVX1.BITNET From: Subject: Re: mx mail gateway server Date: 12 Mar 1993 01:52:18 GMT Message-ID: <1noqciINNh7f@gap.caltech.edu> Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET In article <11226676@MVB.SAIC.COM>, TSAI@ACUSD.BITNET writes: =Thank you for several responses to my earlier mx configuration. Now, the real =thing we try to accomplish in my institution is to have DECnet-only nodes =send/receive smtp mails to the Internet using a machine with DECnet and Multinet =(tcp/ip) as mail gateway. How is it to be done? Do i put smtp-over-DECnet module =on DECnet-only nodes while smtp interface on the latter node? Can anyone send =to me samples of your site configurations or any caveats? Thanks! First, get an MX record put in the nameservers' databases that points from your DECnet-only node to your DECnet and SMTP node (in my case, it's an MX record mapping from NEPTU1.GPS.CALTECH.EDU to SOL1.GPS.CALTECH.EDU). Then configure the mailer along the lines of: On SOL1 (which has both DECnet and TCP/IP): Domain-to-path mappings: Domain="SOL1", Path=Local Domain="SOL1.GPS.CALTECH.EDU", Path=Local Domain="[131.215.64.165]", Path=Local Domain="NEPTU1.GPS.CALTECH.EDU", Path=DECnet_SMTP, Route="NEPTU1" Domain="*", Path=SMTP On NEPTU1 (which has only DECnet): Domain-to-path mappings: Domain="NEPTU1", Path=Local Domain="NEPTU1.GPS.CALTECH.EDU", Path=Local Domain="*", Path=DECnet_SMTP, Route="SOL1" -------------------------------------------------------------------------------- Carl J Lydick | INTERnet: CARL@SOL1.GPS.CALTECH.EDU | NSI/HEPnet: SOL1::CARL Disclaimer: Hey, I understand VAXen and VMS. That's what I get paid for. My understanding of astronomy is purely at the amateur level (or below). So unless what I'm saying is directly related to VAX/VMS, don't hold me or my organization responsible for it. If it IS related to VAX/VMS, you can try to hold me responsible for it, but my organization had nothing to do with it. ================================================================================ Archive-Date: Fri, 12 Mar 1993 14:20:41 CST Sender: list-mgr@WKUVX1.BITNET Date: Fri, 12 Mar 1993 11:50:05 PST From: Virtual Bill Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <00969654.F03C47A0.22215@gtewd> Subject: More Kudos for Hunter Hunter, the information you provided helped greatly. Thank You! ------------------------------------------------------------------------------- Bill Powers GTE Government Systems (415) 966-2757 internet: powers@gtewd.mtv.gsc.gte.com fax: (415) 966-3401 ================================================================================ Archive-Date: Sat, 13 Mar 1993 07:38:32 CST Sender: list-mgr@WKUVX1.BITNET From: daveh@vax.oxford.ac.uk Reply-To: MX-List@WKUVX1.BITNET Subject: Re: Two Routers anyone?? Message-ID: <1993Mar12.150129.12535@vax.oxford.ac.uk> Date: 12 Mar 93 15:01:29 GMT To: MX-List@WKUVX1.BITNET In article <1993Mar10.021830.1@sejnet.sunet.se>, eric@sejnet.sunet.se (Eric Thomas) writes: > In article <00969393.F9A4C880.24576@hal.hahnemann.edu>, "John Murphy, Library System Mgr" writes: > > Anyway, in order to handle the load on a machine of that size equipped with two > RF71's (and also doing a number of other things), I had to make a number of > changes to the indexed file housing the queue. After running the gateway for a > few hours, FLQU took 5-10 seconds between each line of output, and there were > hundreds! I found out that my queue file was seriously fragmented, which makes > sense since the FDL file it was created from started with a small allocation > and the extension was 0. I started by changing that, and then allocating 20 > global buffers as there are many processes sharing the file. The improvement in > performance was tremendous, but alas, it started slowing down a couple hours > later (not quite as slow as before though). I then changed the bucket size as 3 > blocks with 512 byte records = 2 records + almost one wasted block. Anyway, to > make a long story short, here is the FDL I finally ended up using: > We had the same problem of the queue file fragmenting, and ended up with a similar FDL to the one you are using, except that we give it an initial allocation of 20640 blocks and make sure that it is in contiguous space. > < FDL deleted> > > Remember to stop MX completely, including all processes which may feed it > (JNET, whatever), before running CONVERT/FDL. Unlike CONVERT/RECLAIM this makes > a new file, which means other processes might (potentially - I haven't read the > source code) still get a chance to change the input file. I don't know what > locks are taken exactly, whether the file version number is used before getting > the lock, how the processes spin on the lock, etc. > We take down MX every night and rebuild the queue file using CONVERT/FDL. On our system it is rare for the router to get exclusive access to the queue file to perform a reclaim, so to prevent performance degrading too much during the day an explicit shutdown is the only solution. > > > Another change which could help a lot on machines with RF71's is a "MX purger" > process, whose only job would be to purge files which have been sent. Setting > the router to purge every 5 minutes keeps the queues and directories small, but > it also ties up the router too frequently in my opinion. I didn't know you > could run two routers and maybe I should try that, but I think it would be best > with a purger process which would free the router from queue management (maybe > it would still need to run the CONVERT jobs, I'm afraid I haven't got used to > BLISS code yet ;-) ). The purger could keep track of the amount of entries it > purged and run the CONVERT/FDL after a predefined amount of entries, rather > than wall-clock time; this way you don't clean up the file for nothing at night > and you don't suffer degraded performance and unnecessary extends during the > day if you get a burst of traffic after a line comes back. > > Eric Yes, a separate "MX Purger" process would be a good idea. Our system is a VAX 6620 which, amongst many other things, runs MX. We have around 1500-2000 outgoing messages a day, and 4500-5000 incoming per day. Until recently this lot was being handled by one router, two local and two SMTP agents. We now run two routers and four of each delivery agent, which seems to work much better. I would be interested to hear anybody's comments on this configuration. Dave -- David Hastings | "The technical axiom that nothing is VAX Systems Programmer | impossible sinisterly conditions one to Oxford University Computing Services| the pitfall corollary that nothing is daveh@vax.oxford.ac.uk | ridiculous" ================================================================================ Archive-Date: Sat, 13 Mar 1993 09:54:34 CST Sender: list-mgr@WKUVX1.BITNET Date: 13 Mar 1993 08:46:15 -0700 (MST) From: Dan Wing Reply-To: MX-List@WKUVX1.BITNET Subject: Translating errors To: mx-list@WKUVX1.BITNET Message-ID: <00969704.6C2F4920.5720@buckie.HSC.Colorado.EDU> Anyone know why this doesn't work? MX_SMTP_LOG.LOG contains: ... 12-MAR-1993 20:00:51.00 Recipient status=0C2680A4 for ... So I wanted to translate the error code: $ SET MESSAGE MX_MSG $ WRITE SYS$OUTPUT F$MESSAGE(%X0C2680A4) %NONAME-F-NOMSG, Message number 0C2680A4 (The logical MX_MSG points to the MX message file -- SET MESSAGE returns a file-not-found error if you attempt to use SET MESSAGE with a file that doesn't exist.) -Dan Wing, dwing@uh01.colorado.edu or wing_d@ucolmcc.bitnet (DGW11) Systems Administrator, University Hospital, Denver ================================================================================ Archive-Date: Sat, 13 Mar 1993 13:49:11 CST Sender: list-mgr@WKUVX1.BITNET Date: Sat, 13 Mar 1993 13:38:02 CST From: "George D. Greenwade" Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <0096972D.2EC6C760.28237@SHSU.edu> Subject: Re: Two Routers anyone?? On 12 Mar 93 15:01:29 GMT, David Hastings posted: > We take down MX every night and rebuild the queue file using CONVERT/FDL. > On our system it is rare for the router to get exclusive access to the > queue file to perform a reclaim, so to prevent performance degrading too > much during the day an explicit shutdown is the only solution. For quite some time now we have been shutting down MX early every morning, optimizing the SYSTEM_QUEUE.FLQ_CTL file, running FIXCOUNT to ensure an update of everyone's mail counts, and doing a few other things related to our archives (FILESERV archives share our ftp archives, so getting proper protections on files, purging directories, creating a daily-updated directory listing, etc., are necessary), all of which are non-standard (but really help our performance). I am attaching the basic command procedures in a VMS_SHARE package (69 blocks in size) below my signature. The file RESET.COM is enqueued to be run each morning at 0200. We use the QUEUE utility to achieve this -- it would be trivial DCL code to make this a self-submitting file (but QUEUE's data survives when the system goes down, which is why I recommend that path). > Yes, a separate "MX Purger" process would be a good idea. I have reported previously that this is how we run things to improve performance. The logic I used in designing this was to simply have a batch process under the MXMAILER account which runs MCP QUEUE PURGE, waits 2 minutes, then loops back. I included a four hour loop in it to exit the process as our SYSTEM_QUEUE file routinely gets rather large (it goes from about 300 blocks to about 11,000 blocks in each 24 hour time period -- in other words, going through a single MCP QUEUE PURGE pass has taken up to 4 hours in the past; possibly ther new structure of MX_FLQ_DIR will alleviate some of this). Since the purger file (MCP-QP.COM) is called by RESET.COM, it is included in the VMS_SHARE file below. > Our system is a VAX 6620 which, amongst many other things, runs MX. We have > around 1500-2000 outgoing messages a day, and 4500-5000 incoming per day. > Until recently this lot was being handled by one router, two local and two > SMTP agents. We now run two routers and four of each delivery agent, which > seems to work much better. I would be interested to hear anybody's comments > on this configuration. We run MX on two machines in our cluster -- ODIN:: (a 6420) and FREYA:: (a 6610, which is known as Niord.SHSU.edu and SHSU.edu on the Internet because of TCP/IP packages and naming -- it was easier to move the name Niord from the physical machine NIORD:: to FREYA::, but that's another story). These are the workhorse VMS machines here, each supporting academic and administrative missions in addition to mail, Gopher, and ftp (both machines support in excess of 250 interactive users last I saw). Our mail traffic is considerably heavier than what you report (we have between 8000-9000 outgoing daily and I haven't looked at inbound recently enough to even provide an educated guess, we were handling about 3000-3500 incoming daily about a year ago). In our configuration, ODIN:: runs 1 router, 1 local, 1 MLF, 2 JNET, and 3 SMTP processes, while FREYA:: runs 2 routers, 2 locals, 1 MLF, 1 SMTP server (with 7 threads), and 4 SMTP processes. The purger runs in a dedicated batch queue on FREYA::; the extra MLF process is pure redundancy as only one seems to really do anything (but if we lose the one which appears to be active, the other one kicks in quickly). Since upgrading to MX 3.2, our (MX_)FLQ_DIR consistently is below 128 blocks and we are getting out mail as fast as our 56kB line will allow (which is why I am glad the T1 is to be here within a few weeks). Thanks for that new dimension, Hunter -- line speed appears to be our limiting problem now exclusively in place of the queueing/line speed problems of the past. Regards, George %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% George D. Greenwade, Ph.D. Bitnet: BED_GDG@SHSU Department of Economics and Business Analysis THEnet: SHSU::BED_GDG College of Business Administration Voice: (409) 294-1266 P. O. Box 2118 FAX: (409) 294-3612 Sam Houston State University Internet: bed_gdg@SHSU.edu Huntsville, TX 77341 bed_gdg%SHSU.decnet@relay.the.net %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% $!! Save file as: MX_UTILS.VMS_SHARE, unpack with @MX_UTILS.VMS_SHARE $! ------------------ CUT HERE ----------------------- $ v='f$verify(f$trnlnm("SHARE_UNPACK_VERIFY"))' $! $! This archive created by VMS_SHARE Version 8.2 $! On 13-MAR-1993 12:40:36.46 By user BED_GDG ("George D. Greenwade ") $! $! The VMS_SHARE software that created this archive $! was written by Andy Harper, Kings College London UK $! -- December 1992 $! $! Credit is due to these people for their original ideas: $! James Gray, Michael Bednarek $! $! TO UNPACK THIS SHARE FILE, CONCATENATE ALL PARTS IN ORDER $! AND EXECUTE AS A COMMAND PROCEDURE ( @name ) $! $! THE FOLLOWING FILE(S) WILL BE CREATED AFTER UNPACKING: $! 1. [.MX_UTILS]ADDITIONS_CHECK.COM;33 $! 2. [.MX_UTILS]FIXCOUNT.EXE;1 $! 3. [.MX_UTILS]MCP-QP.COM;2 $! 4. [.MX_UTILS]MX_START_ODIN.COM;20 $! 5. [.MX_UTILS]OPTIMIZE.COM;3 $! 6. [.MX_UTILS]RESET.COM;1 $! $set="set" $set symbol/scope=(nolocal,noglobal) $f=f$parse("SHARE_UNPACK_TEMP","SYS$SCRATCH:."+f$getjpi("","PID")) $e="write sys$error ""%UNPACK"", " $w="write sys$output ""%UNPACK"", " $ if .not. f$trnlnm("SHARE_UNPACK_LOG") then $ w = "!" $ ve=f$getsyi("version") $ if ve-f$extract(0,1,ve) .ges. "4.4" then $ goto start $ e "-E-OLDVER, Must run at least VMS 4.4" $ v=f$verify(v) $ exit 44 $unpack: subroutine ! P1=filename, P2=checksum, P3=attributes $ if f$parse(P1) .nes. "" then $ goto dirok $ dn=f$parse(P1,,,"DIRECTORY") $ w "-I-CREDIR, Creating directory ''dn'" $ create/dir 'dn' $ if $status then $ goto dirok $ e "-E-CREDIRFAIL, Unable to create ''dn' File skipped" $ delete 'f'* $ exit $dirok: $ x=f$search(P1) $ if x .eqs. "" then $ goto file_absent $ e "-W-EXISTS, File ''P1' exists. Skipped" $ delete 'f'* $ exit $file_absent: $ w "-I-UNPACK, Unpacking file ", P1 $ n=P1 $ if P3 .nes. "" then $ n=f $ if .not. f$verify() then $ define/user sys$output nl: $ EDIT/TPU/NOSEC/NODIS/COM=SYS$INPUT 'f'/OUT='n' PROCEDURE GetHex(s,p)LOCAL x1,x2;x1:=INDEX(t,SUBSTR(s,p,1))-1;x2:=INDEX(t, SUBSTR(s,p+1,1))-1;RETURN 16*x1+x2;ENDPROCEDURE; PROCEDURE SkipPartsep LOOP EXITIF MARK(NONE)=END_OF(b);EXITIF INDEX(ERASE_LINE, "-+-+-+-+-+-+-+-+")=1;ENDLOOP;ENDPROCEDURE;PROCEDURE ProcessLine LOCAL c,s,l,b, n,p;c := ERASE_CHARACTER(1);s := ERASE_LINE;IF c = "X" THEN SPLIT_LINE; ENDIF; MOVE_HORIZONTAL(-1);l := LENGTH(s);p := 1;LOOP EXITIF p > l;c := SUBSTR(s,p,1); p := p+1;CASE c FROM ' ' TO '`' ['`']: COPY_TEXT(ASCII(GetHex(s,p))); p:=p+2;[ ' ']: p:=p+1;[INRANGE,OUTRANGE]: COPY_TEXT(c);ENDCASE;ENDLOOP;ENDPROCEDURE; PROCEDURE Decode POSITION(BEGINNING_OF(b));LOOP EXITIF MARK(NONE)=END_OF(b); IF INDEX(CURRENT_LINE,"+-+-+-+-+-+-+-+-")=1 THEN SkipPartSep;ELSE ProcessLine; MOVE_HORIZONTAL(1);ENDIF;ENDLOOP;ENDPROCEDURE;SET(FACILITY_NAME,"UNPACK");SET( SUCCESS,OFF);SET(INFORMATIONAL,OFF);t:="0123456789ABCDEF";f:=GET_INFO( COMMAND_LINE,"file_name");b:=CREATE_BUFFER(f,f);Decode;WRITE_FILE(b,GET_INFO( COMMAND_LINE,"output_file"));QUIT; $ if p3 .eqs. "" then $ goto dl $ open/write fdl &f $ write fdl "RECORD" $ write fdl P3 $ close fdl $ w "-I-CONVRFM, Converting record format to ", P3 $ convert/fdl=&f &f-1 &P1 $dl: delete 'f'* $ checksum 'P1' $ if checksum$checksum .nes. P2 then $ - e "-E-CHKSMFAIL, Checksum of ''P1' failed." $ exit $ endsubroutine $start: $! $ create 'f' X$!!`20Program`20Name`20`20`20`20`20`20`20`20`20`20`20`20:`20ADDITIONS_CHECK.CO VM X$!!`20`20`20Original`20Author`20`20`20`20`20`20`20:`20BED_GDG@SHSU.edu`20(Geor Vge`20D.`20Greenwade) X$!!`20`20`20Date`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20:`2028-S VEP-1991`20 X$!!`20`20`20Program`20Description`20`20`20:`20Automatically`20create`20files V`20for`20the`20ADDITIONS X$!!`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20 V`20:`20package`20on`20FILESERV X$!!`20References X$!!`20`20`20Files`20open`20for`20Input`20`20:`20DIR.7,`20DIR30,`20TOP.7,`20TOP V.30,`20ADDITIONS_BODY.TEXT X$!!`20`20`20Files`20open`20for`20Output`20:`20MX_ROOT:`5BFILESERV.ADDITIONS V`5DADDITIONS.7DAYS X$!!`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20 V`20:`20MX_ROOT:`5BFILESERV.ADDITIONS`5DADDITIONS.30DAYS X$!!`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20 V`20:`20MX_ROOT:`5BFILESERV.ADDITIONS`5D00SHSU.FILEDATES X$!!`20First,`20get`20a`20listing`20of`20files`20which`20are`20new`20within`20t Vhe`20last`2030`20days X$`20DIRECTORY/SIZE/DATE/SINCE='F$EXT(0,11,F$CVT("-30-","ABSOLUTE"))`20- X`20MX_ROOT:`5BFILESERV...`5D*.*/VER=1/OUTPUT=DIR.30/WIDTH=(FILENAME=30)/COLUMN V=1 X$!!`20Next,`20get`20a`20listing`20of`20files`20which`20are`20new`20within`20th Ve`20last`207`20days X$`20DIR/SIZE/DATE/SINCE='F$EXT(0,11,F$CVT("-7-","ABSOLUTE"))`20- X`20MX_ROOT:`5BFILESERV...`5D*.*/VER=1/OUTPUT=DIR.7/WIDTH=(FILENAME=30)/COLUMN= V1 X$!!`20Next,`20get`20a`20listing`20of`20all`20files`20in`20the`20archive X$`20DIR/SIZE/DATE`20- X`20MX_ROOT:`5BFILESERV...`5D*.*/VER=1/OUTPUT=DIR.ALL/WIDTH=(FILENAME=30)/COLUM VN=1 X$TOPPER30:`20`20!!Make`20a`2030`20day`20header X$`20CREATE`20TOP.30 X$`20OPEN/APPEND`20FILE`20TOP.30 X$`20WRITE`20FILE`20- X"ADDITIONS`20to`20Sam`20Houston`20State`20University`20Archives`20Since`20" V`20+`20- X`20''f$ext(0,11,f$cvt("-30-","ABSOLUTE")) X$`20WRITE`20FILE`20"Report`20date:`20''f$time()" X$`20WRITE`20FILE`20"" X$`20CLOSE`20FILE X$TOPPER7:`20`20`20!!Make`20a`207`20day`20header X$`20CREATE`20TOP.7 X$`20OPEN/APPEND`20FILE`20TOP.7 X$`20WRITE`20FILE`20- X"ADDITIONS`20to`20Sam`20Houston`20State`20University`20Archives`20Since`20" V`20+`20- X`20''f$ext(0,11,f$cvt("-7-","ABSOLUTE"))" X$`20WRITE`20FILE`20"Report`20date:`20''f$time()" X$`20WRITE`20FILE`20"" X$`20CLOSE`20FILE X$TOPPER_ALL:`20`20!!Make`20a`20header`20for`20the`20comprehensive`20listing X$`20CREATE`20TOP.ALL X$`20OPEN/APPEND`20FILE`20TOP.ALL X$`20WRITE`20FILE`20- X"FILEDATES`20of`20the`20complete`20Sam`20Houston`20State`20University`20Archiv Ves" X$`20WRITE`20FILE`20"Report`20date:`20''f$time()" X$`20WRITE`20FILE`20"" X$`20CLOSE`20FILE X$ADDITIONS_BODY:`20`20!!Make`20a`20brief`20explanation`20of`20the`20strange V`20filenaming`20and X$!!`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20how`20to`20get`20files X$`20CREATE`20ADDITIONS_BODY.TEXT X$`20OPEN/APPEND`20FILE`20ADDITIONS_BODY.TEXT X$`20WRITE`20FILE`20- X"`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20 V`20`20`20`20`20`20Please`20Note" X$`20WRITE`20FILE`20"" X$`20WRITE`20FILE`20- X"Files`20are`20available`20from`20FILESERV@SHSU.BITNET`20(FILESERV@SHSU.edu) V`20*if`20and" X$`20WRITE`20FILE`20- X"only`20if*`20the`20first`20level`20sub-directory`20name`20is`20identical`20to V`20the`20filename." X$`20WRITE`20FILE`20- X"For`20example`20the`20file`20`5BFILESERV.LZW`5DLZW.2OF7`20can`20be`20retrieve Vd`20via:" X$`20WRITE`20FILE`20- X"`20SENDME`20LZW.2OF7`20" X$`20WRITE`20FILE`20- X"in`20the`20body`20of`20a`20mail`20message`20to`20FILESERV;`20however,`20the V`20file" X$`20WRITE`20FILE`20- X"`5BFILESERV.LZW`5DLZ.HLP`20is`20only`20available`20via`20anonymous`20ftp`20fr Vom" X$`20WRITE`20FILE`20- X"Niord.SHSU.edu`20(192.92.115.8)." X$`20WRITE`20FILE`20"" X$`20WRITE`20FILE`20- X"To`20retrieve`20all`20files`20in`20a`20package`20(i.e.,`20all`20files`20in V`20a`20sub-directory`20with" X$`20WRITE`20FILE`20- X"the`20same`20filename`20as`20the`20sub-directory),`20you`20can`20use`20the V`20command:" X$`20WRITE`20FILE`20- X"`20SENDME`20package_name" X$`20WRITE`20FILE`20- X"in`20a`20mail`20message`20to`20FILESERV`20(package_name`20=`20sub-directory V`20name)." X$`20WRITE`20FILE`20"" X$`20WRITE`20FILE`20- X"File`20sizes`20are`20reported`20in`20512-byte`20blocks`20(2`20blocks`20=`201k V)." X$`20CLOSE`20FILE X$DOIT:`20`20`20`20`20`20`20`20!!Put`20these`20all`20together X$`20SET`20NOON X$`20RENAME`20MX_ROOT:`5BFILESERV.ADDITIONS`5DADDITIONS.30DAYS`20- X`20MX_ROOT:`5BFILESERV.ADDITIONS`5D30DAYS.OLD`20`20!keep`20yesterday's`20list V`20(in`20case...) X$`20RENAME`20MX_ROOT:`5BFILESERV.ADDITIONS`5DADDITIONS.7DAYS`20- X`20MX_ROOT:`5BFILESERV.ADDITIONS`5D7DAYS.OLD`20`20`20!keep`20yesterday's`20lis Vt`20(in`20case...) X$`20COPY/PROT=(S:RWE,O:RWED,G:RE,W:RE)`20TOP.30,ADDITIONS_BODY.TEXT,DIR.30`20- V X`20MX_ROOT:`5BFILESERV.ADDITIONS`5DADDITIONS.30DAYS`20`20!the`2030`20day`20fil Ve X$`20COPY/PROT=(S:RWE,O:RWED,G:RE,W:RE)`20TOP.7,ADDITIONS_BODY.TEXT,DIR.7`20- X`20MX_ROOT:`5BFILESERV.ADDITIONS`5DADDITIONS.7DAYS`20`20`20!the`207`20day`20fi Vle X$`20COPY/PROT=(S:RWE,O:RWED,G:RE,W:RE)`20TOP.ALL,ADDITIONS_BODY.TEXT,DIR.ALL V`20- X`20MX_ROOT:`5BFILESERV.ADDITIONS`5D00SHSU.FILEDATES`20`20!the`20comprehensive V`20file X$!!`20This`20file`20is`20way`20too`20big`20to`20be`20served`20as`20a`20single V`20file`20via`20FILESERV;`20we X$!!`20can`20break`20it`20down`20into`20smaller`20peices`20on`20a`20routine`20b Vasis`20and`20name`20the X$!!`20parts`20ADDITIONS.FILEDATES_nnOFmm`20for`20FILESERV`20use. X$`20PURGE/KEEP=1`20MX_ROOT:`5BFILESERV.ADDITIONS`5D`20`20`20`20!keep`20one`20v Version`20of`20everything X$!!`20`20`20`20Get`20rid`20of`20the`20working`20files X$`20DELETE/NOCONFIRM/NOLOG`20- X`20TOP.30.*,DIR.30.*,TOP.7.*,DIR.7.*,ADDITIONS_BODY.TEXT.*,TOP.ALL.*,DIR.ALL.* V X$`20SET`20ON X$EXIT: X$`20EXIT $ call unpack [.MX_UTILS]ADDITIONS_CHECK.COM;33 1394233200 "" $! $ create 'f' X`B0`000`00D`00`60`00`00`00`00`000205`01`01`00`00`FF`FF`FF`FF`FF`FF`FF`FF`00 V`00`00`00`A8`00`00`01`85`D0`B8R`00`00`00`00`00`0A`00`00h`DF`FE`7F`5C`05`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`08`00`00`00`00`00`00`00`01`00`00`00`00 V`00`00`00`00`00`00`00`01`00`00`00`00`00`00`00`08FIXCOUNT`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`04V1. V0`00`00`00`00`00`00`00`00`00`00`00`A0L`85`D0`B8`D2`95`00`0505-09`00`00`00`00 V`00`00`00`00`00`00`10`00`01`00`01`00`00`00`8A`00`00`00`02`00`00`00`10`00`03 V`00`02`00`00`00`80`00`00`00`03`00`00`00`10`00`02`00`05`00`00`00`0A`04`00`00 V`06`00`00`00`0C`00`14`00`EC`FF?`00`8C`00`00`FD`20`00`04`00`00`00`00`00!`00`00 V`03`00`00`00`00`03`00`00`04`0BVAXCRTL_001`1F`00`C3`00`00`00`00`00!`00`00`03 V`00`00`00`00`0E`00`00`01`0ALIBRTL_001`1F`00O`01`00`00`00`00!`00`00`03`00`00 V`00`00`0C`80`00`81`0AMTHRTL_001`20`00j`00`00`00`00`00!`00`00`01`00`00`00`00 V`00`00`00`01`0BMAILSHR_001!`00G`00`00`00`00`00!`00`04`01`00`00`00`00`00`00`00 V`01`0CMAILSHRP_001`00`00`FF`FF`FF`FF`FF`FF`FF`FF`FF`FF`FF`FF`FF`FF`FF`FF`FF V`FF`FF`FF`FF`FF`FF`FF`FF`FF`FF`FF`FF`FF`FF`FF`FF`FF`FF`FF`FF`FF`FF`FF`FF`FF V`FF`FF`FF`FF`FF`FF`FF`FF`FF`FF`FF`FF`FF`FF`FF`FF`FF`FF`FF`FF`FF`FF`FF`FF`FF V`FF`FF`FF`FF`FF`FF`FF`FF`FF`FF`FF`FF`FF`FF`FF`FF`FF`FF`FF`FF`FF`FF`FF`FF`FF V`FF`FF`FF`FF`FF`FF`FF`FF`FF`FF`FF`FF`FF`FF`FF`FF`FF`FF`FF`FF`FF`FF`FF XAdjusting`20%s`20new`20mail`20count,`20from`20%d`20to`20%d`0A`00NEWMAIL`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00 X`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`04`00 V`9E`CE0`FE`5E`16`FF`DF`04`00`00`9E`EF`91`FC`FF`FFR`D4`AD`F8`7C`CD`C2`FE`D4`CD V`CA`FE`B4`CD`AA`FE`B0`8F`01`0C`CD`AC`FE`7C`CD`AE`FE`7C`CD`B6`FE`D4`CD`BE`FE V`B4`CD`86`FE`B0`8F`02`0C`CD`88`FE`7C`CD`8A`FE`B4`CD`92`FE`B0`8F`02`10`CD`94 V`FE`7C`CD`96`FE`7C`CD`9E`FE`D4`CD`A6`FE`B4`CDb`FE`B0`8F`03`0C`CDd`FE`DE`AD`CB V`CDf`FE`D4`CDj`FE`B0`02`CDn`FE`B0`8F`10`0C`CDp`FE>`AD`EC`CDr`FE`7C`CDv`FE`7C V`CD`7E`FE`B0`20`CD2`FE`B0`8FF`0C`CD4`FE`DE`AD`CB`CD6`FE`DE`AD`F4`CD:`FE`9B X`8F`FC`CD>`FE`B0`8FI`0C`CD@`FE`DE`CD`CE`FE`CDB`FE`DE`AD`F0`CDF`FE`B0`02`CDJ V`FE`B0`8FJ`0C`CDL`FE>`AD`EE`CDN`FE`7C`CDR`FE`7C`CDZ`FE`DF`CD`C2`FE`DF`CD`C2 V`FE`DF`AD`F8`FB`03`FFC`04`00`00`E8P`04`D0`01P`04`DF`CD2`FE`DF`CD`AA`FE`DF`AD V`F8`FB`03`FF`26`04`00`00`E9Px`D5P`01`D0`AD`F4P`94@`AD`CB`D0`AD`F0P`94@`CD`CE V`FE`B5`AD`EE`15J`DF`CD`CE`FE`DF`AD`CB`FB`02`EFh`00`00`00`F7P`AD`EC`B1P`8F`FF V`FF`131`B1P`AD`EE`13+2P`7E2`AD`EE`7E`DF`AD`CB`DFb`FB`04`FF`A4`03`00`00`F7`AD V`F4`CDb`FE`DF`CD`C2`FE`DF`CDb`FE`DF`AD`F8`FB`03`FF`BC`03`00`00`DF`CD2`FE`DF V`CD`86`FE`DF`AD`F8`FB`03`FF`AE`03`00`00`E8P`8B`DF`CD`C2`FE`DF`CD`C2`FE`DF`AD V`F8`FB`03`FF`91`03`00`00`98`8F`01P`04`1C`00`9E`CE0`FF`5E`9E`EF`03`FB`FF`FFS V`CE`01R`7C`AD`F4`B0`01`AD`F2`7C`AD`E6`D4`AD`EE`B4`AD`CE`B0`8F`02`10`AD`D0`7C V`AD`D2`7C`AD`DA`D4`AD`E2`D0`AC`08T`DDT`FB`01`FF`1F`03`00`00`F7P`AD`AA`B0`8F V`05`04`AD`AC`D0T`AD`AE`D4`AD`B2`B4`AD`B6`B0`8F`02`10`AD`B8`7C`AD`BA`7C`AD`C2 V`D4`AD`CA`B0`04`AD`86`B0`8F`0A`08`AD`88`DE`AD`F4`AD`8A`D4`AD`8E`B4`AD`92`B0 V`8F`02`10`AD`94`7C`AD`96`7C`AD`9E`D4`AD`A6`B0`02`CDV`FF`B0`8F`0C`08`CDX`FF> V`AD`F2`CDZ`FF`D4`CD`5E`FF`B0`08`CDb`FF`B0`8F`0D`08`CDd`FF`DE`A3,`CDf`FF`D4`CDj V`FF`B4`CDn`FF`B0`8F`02`10`CDp`FF`7C`CDr`FF`7C`CDz`FF`D4`AD`82`B4`CD2`FF`B0`8F V`10`08`CD4`FF`7C`CD6`FF`B4`CD>`FF`B0`8F`02`10`CD@`FF`7C`CDB`FF`7C`CDJ`FF`D4 V`CDR`FF`DDT`FB`01`FFg`02`00`00`D5P`12`03`D4P`04`DF`AD`E6`DF`AD`CE`DF`AD`F4`FB V`03`FFl`02`00`00`E8P`031 X`8E`00`DF`AD`E6`DF`AD`AA`DF`AD`F4`FB`03`FFR`02`00`00`E9Pk`DF`AD`E6`DF`AD`86 V`DF`AD`F8`FB`03`FFS`02`00`00`E9PH`D4R`DF`AD`E6`DF`CDV`FF`DF`AD`F8`FB`03`FF9 V`02`00`00`E9P"`D5P`DF`AD`E6`DF`CD2`FF`DF`AD`F8`FB`03`FF`1F`02`00`00`CA`8F`FE V`FF`FF`FFP`13`02`D6R`D5P`12`E0`DF`AD`E6`DF`AD`CE`DF`AD`F8`FB`03`FF`FC`01`00 V`00`DF`AD`E6`DF`AD`CE`DF`AD`F4`FB`03`FF`E0`01`00`00`DF`AD`E6`DF`AD`CE`DF`AD V`F4`FB`03`FF`CC`01`00`00`D0RP`04`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 X`00`00`00`00`00`00`00`00@`00`00`00@`00`00`00`00`00`00`00`90`00`00`00`9C`00`00 V`00`06`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`03`00`00`00`01`00`00`00`0A`00`00`00`9C V`02`00`00`04`01`00`00`0C`00`00`00`04`00`00`00`B4`00`00`00`A0`00`00`00`D2`00 V`00`00`96`00`00`00d`00`00`00x`00`00`00`8C`00`00`00F`00`00`00`0E`01`00`00`FA V`00`00`00`F0`00`00`00`E6`00`00`00`00`00`00`00`01`00`00`00`00`08`00`00`02`00 V`0D`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00@`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`07VAXCRTL`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`06LIBRTL V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`06MTHRTL`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`07MAILSHR`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`08MAILSHRP`00`00`00 X`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00 X`0F`BC`00`07`00`00`00`08FIXCOUNT`0B`BE`00`5C`05`00`00`04main`06`BF`00`94`01 V`00`00`0F`BE`00`F0`06`00`00`08fix_user`06`BF`00`A4`01`00`00`09`B9`09`D5`01`10 V`5C`05`00`00c`B9`00`02`03`EC`02`01`FD`F8`E9`F1`F1`F8`EB`EA`FC`E8`E6`EA`02`01 V`FC`EE`02`01`F9`EE`FA`00`F8`F7`FB`00`EE`F3`00`ED`FA`EE`00`02`01`00`EE`02`01 V`FD`EE`02`05`FB`F2`FA`02`01`FC`FA`EE`E2`F4`FA`EE`F4`FA`EA`EA`F1`F9`F1`F1`02 V`01`F8`F3`02`01`FD`EA`00`ED`00`ED`00`FE`EF`FB`00`EF`F5`FC`F0`00`F0`00`F0`00 V`FC`0E`00`01`BD`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 V`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00`00 $ call unpack [.MX_UTILS]FIXCOUNT.EXE;1 - 2944247328 "FORMAT FIX;SIZE 512;CARRIAGE_CONTROL NONE" $! $ create 'f' X$!!`20Program`20Name`20`20`20`20`20`20`20`20`20`20`20`20:`20MCP-QP.COM X$!!`20`20`20Original`20Author`20`20`20`20`20`20`20:`20BED_GDG@SHSU.edu`20(Geor Vge`20D.`20Greenwade) X$!!`20`20`20Date`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20:`2013-M VAR-1992 X$!!`20`20`20Program`20Description`20`20`20:`20process`20to`20purge`20the`20MX V`20queue`20in`20batch X$!!`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20 V`20:`20MUST`20use`20STOP/ID`20or`20stop`20option`20of`20MXWATCH`20to X$!!`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20 V`20:`20stop`20this`20job`20--`20MCP`20SHUTDOWN`20will`20not`20get`20it X$`20SET`20PROC/PRIV=ALL`20`20`20`20!get`20as`20many`20privs`20as`20possible X$`20IF`20P1`20.EQS.`20"BATCH"`20THEN`20GOTO`20BATCH_RUN`20`20!trick`20to`20get V`20it`20to`20be`20submitted X$`20IF`20P1`20.NES.`20"BATCH"`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20 V`20`20`20`20`20`20!to`20submit`20itself X$`20`20`20THEN`20 X$`20`20`20QUENAME`20:=`20MX$BATCH_'F$GETSYI("NODENAME") X$`20`20`20QUEPARS`20:=`20"/NOPRINT/NOKEEP/NOLOG/PARAM="""BATCH"""/USER=MXMAILE VR" X$`20`20`20SUBMIT/QUE='QUENAME/NAME="MCP_Purge"`20'QUEPARS`20MX_MLF_DIR:FLQP.CO VM X$`20ENDIF X$`20EXIT X$BATCH_RUN: X$`20MCP`20:=`20$MX_EXE:MCP.EXE X$`20COUNT`20=`201`20`20`20`20`20`20`20`20`20`20`20`20!initialize`20counter X$LOOP:`20`20!!If`20it's`20after`202200`20and`20before`200200`20exit,`20otherwi Vse`20go`20again X$`20IF`20F$EXTRACT(12,2,F$TIME())`20.EQS.`20"22"`20THEN`20GOTO`20EXIT X$`20IF`20F$EXTRACT(12,2,F$TIME())`20.EQS.`20"23"`20THEN`20GOTO`20EXIT X$`20IF`20F$EXTRACT(12,2,F$TIME())`20.EQS.`20"00"`20THEN`20GOTO`20EXIT X$`20IF`20F$EXTRACT(12,2,F$TIME())`20.EQS.`20"01"`20THEN`20GOTO`20EXIT X$`20SET`20PROC/NAME="MCP_Purge''COUNT'"`20`20!show`20counter`20in`20process V`20name X$`20COUNT`20=`20COUNT`20+`201`20`20`20`20!step`20counter X$`20MCP`20QUEUE`20PURGE`20`20`20`20`20`20!purge`20the`20queue X$`20WAIT`2000:02:00`20`20`20`20`20`20`20`20!wait`202`20minutes,`20then`20try V`20again X$`20GOTO`20LOOP X$EXIT: X$`20EXIT $ call unpack [.MX_UTILS]MCP-QP.COM;2 2084468030 "" $! $ create 'f' X$!!`20Program`20Name`20`20`20`20`20`20`20`20`20`20`20`20:`20RESET_ODIN.COM X$!!`20`20`20Original`20Author`20`20`20`20`20`20`20:`20BED_GDG@SHSU.edu`20(Geor Vge`20D.`20Greenwade) X$!!`20`20`20Date`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20:`20`207 V-APR-1992`20 X$!!`20`20`20Program`20Description`20`20`20:`20Reset`20MX`20processes`20for`20n Vode`20ODIN X$!!`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20 V`20:`20ODIN`20is`20a`20special`20case`20as`20it`20runs`20JNET X$`20SET`20PROCESS/PRIV=ALL`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20 V`20`20`20`20`20`20`20`20`20!get`20as`20many`20privs`20as`20possible X$`20@SYS$STARTUP:MX_STARTUP`20LOGICALS`20`20`20`20`20`20`20`20`20`20`20`20`20 V`20!get`20the`20logicals`20defined X$`20DEFINE/SYS/EXEC`20JAN_MFSDISP`20MX_EXE:MX_MFSDISP`20!be`20sure`20this`20is V`20defined!!! X$`20@SYS$STARTUP:MX_STARTUP`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20 V`20`20`20`20`20`20`20!start`20up`20MX X$`20OPEN/READ`20TMPFILE`20$1$DUA0:`5BJANODIN.SYS`5DLMD.LOG/ERROR=JNET_RUNNING X$!!`20Here`20is`20the`20trick`20--`20if`20LMD.LOG`20is`20locked,`20JNET`20is V`20running`20on`20ODIN,`20so X$!!`20start`20JNET`20processes`20(JNET_RUNNING:);`20if`20LMD.LOG`20is`20not V`20locked,`20JNET`20is X$!!`20not`20running,`20so`20don't`20start`20JNET`20processes`20(JNET_DOWN:) X$`20CLOSE`20TMPFILE`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20 V`20`20`20`20`20`20`20`20`20`20`20`20`20`20!if`20we`20opened`20it,`20close`20it V X$`20GOTO`20JNET_DOWN`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20 V`20`20`20`20`20`20`20`20`20`20`20`20`20!do`20extra`20things X$JNET_RUNNING:`20`20`20!!Only`20way`20to`20get`20here`20is`20if`20we`20couldn' Vt`20open`20LMD.LOG,`20so X$`20@SYS$STARTUP:MX_STARTUP`20JNET`20`20`20`20`20`20`20`20`20`20`20`20`20`20 V`20`20`20`20!start`20JNET`20processes X$JNET_DOWN:`20`20`20`20`20`20!!No`20matter`20what,`20we`20want`20to`20do`20the V`20following: X$`20@MX_EXE:MX_START`20SMTP#2,SMTP#3`20`20`20`20`20`20`20`20`20`20`20`20`20 V`20`20`20!start`20up`20two`20more`20SMTP X$!!`20`20`20`20`20`20`20`20`20`20`20`20`20`20processes`20on`20ODIN`20--`20this V`20allows`20us`20to`20keep`20one`20defined`20for X$!!`20`20`20`20`20`20`20`20`20`20`20`20`20`20SMTP`20on`20ODIN`20in`20MX_STARTU VP_INFO.DAT`20as`20the`20default`20scenario X$`20@MX_EXE:FINGER_STARTUP`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20 V`20`20`20`20`20`20`20!we`20also`20run`20Matt`20Madison's X$!!`20`20`20`20`20`20`20`20`20`20`20`20`20`20UCX`20finger`20utility`20and`20ha Vve`20it`20under`20MXMAILER`20so`20we`20can X$!!`20`20`20`20`20`20`20`20`20`20`20`20`20`20find`20it`20quickly;`20also`20we V`20know`20MXMAILER`20has`20SYSPRV`20and`20WORLD X$!!`20`20`20`20`20`20`20`20`20`20`20`20`20`20privs`20at`20this`20point`20neces Vsary`20for`20everything`20to`20work`20right X$`20EXIT $ call unpack [.MX_UTILS]MX_START_ODIN.COM;20 940313963 "" $! $ create 'f' X$!!`20Program`20Name`20`20`20`20`20`20`20`20`20`20`20`20:`20OPTIMIZE.COM X$!!`20`20`20Original`20Author`20`20`20`20`20`20`20:`20BED_GDG@SHSU.edu`20(Geor Vge`20D.`20Greenwade) X$!!`20`20`20Date`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20:`2013-M VAR-1993`20 X$!!`20`20`20Program`20Description`20`20`20:`20Analyzes`20then`20converts`20ind Vexed`20files`20to X$!!`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20 V`20:`20reduce`20size`20of`20indexed`20files X$ON`20WARNING`20THEN`20GOTO`20ERR X$IF`20"''P1'"`20.EQS.`20""`20THEN`20INQUIRE`20P1`20"Enter`20the`20file`20name V`20to`20be`20optimized" X$IF`20"''P1'"`20.EQS.`20""`20THEN`20EXIT X$DOT`20=`20F$LOC(".","''P1'") X$IF`20DOT`20.EQS.`20F$LEN(P1)`20THEN`20P1`20=`20P1`20+`20".DAT" X$OPEN/READ`20XXX`20'P1 X$CLOSE`20XXX X$ORG`20=`20f$file_attributes("''p1'","ORG") X$IF`20"''ORG'"`20.NES.`20"IDX"`20THEN`20GOTO`20NOTIND X$BEGALQ`20=`20F$FILE("''P1'","ALQ") X$BEGEOF`20=`20F$FILE("''P1'","EOF") X$WRITE`20SYS$OUTPUT`20"File`20uses`20"`20+`20"''BEGEOF'"`20+`20"`20of`20"`20 X$WRITE`20SYS$OUTPUT`20"`20`20`20`20`20''BEGALQ'"`20+`20"`20blocks`20allocated" V X$WRITE`20SYS$OUTPUT`20"Analyzing`20input`20file..." X$ANALIZE/RMS/FDL/OUTPUT=TEMP.FDL`20'P1 X$WRITE`20SYS$OUTPUT`20"Optimizing`20file`20definition..." X$EDIT/FDL/NOINT/ANAL=TEMP.FDL`20TEMP.FDL X$WRITE`20SYS$OUTPUT`20"Converting`20file`20using`20optimized`20definition..." X$SET`20RMS_DEFAULT/BUFFER=40/INDEXED X$SET`20RMS_DEFAULT/BUFFER=40 X$SET`20RMS/BLOCK=40 X$SET`20WORK/LIM=1000 X$CONVERT/FDL=TEMP.FDL`20'P1`20'P1 X$WRITE`20SYS$OUTPUT`20"Conversion`20finished." X$ENDALQ`20=`20F$FILE("''P1'","ALQ") X$ENDEOF`20=`20F$FILE("''P1'","EOF") X$RECL`20=`20BEGALQ`20-`20ENDALQ X$WRITE`20SYS$OUTPUT`20"Optimized`20file`20uses`20"`20+`20"''ENDEOF'"`20+`20" V`20of`20"`20 X$WRITE`20SYS$OUTPUT`20"`20`20`20`20`20''ENDALQ'"`20+`20"`20blocks`20allocated" V X$WRITE`20SYS$OUTPUT`20"Optimization`20reclaimed`20"`20+`20"''RECL'"`20+`20" V`20blocks" X$DEL/NOLOG`20TEMP.FDL.* X$INQUIRE`20IPT`20"Purge`20file`20`5BN`5D" X$IF`20"''IPT'"`20.EQS.`20"Y"`20.OR.`20"''IPT'"`20.EQS.`20"Y"`20THEN`20PURGE/LO VG`20'P1 X$SET`20RMS_DEFAULT/BUFFER=0/INDEXED X$SET`20RMS_DEFAULT/BUFFER=0 X$SET`20RMS/BLOCK=0 X$SET`20WORK/LIM=800 X$EXIT X$NOTIND: X$BADFIL`20=`20"''P1'"`20+`20"`20IS`20NOT`20AN`20INDEXED`20FILE...ABORTING" X$WRITE`20SYS$OUTPUT`20BADFIL X$EXIT X$ERR: X$WRITE`20SYS$OUTPUT`20F$MES("''$STATUS'") X$WRITE`20SYS$OUTPUT`20"Error`20has`20occured...Aborting" X$EXIT $ call unpack [.MX_UTILS]OPTIMIZE.COM;3 1600487466 "" $! $ create 'f' X$!!`20Program`20Name`20`20`20`20`20`20`20`20`20`20`20`20:`20RESET.COM X$!!`20`20`20Original`20Author`20`20`20`20`20`20`20:`20BED_GDG@SHSU.edu`20(Geor Vge`20D.`20Greenwade) X$!!`20`20`20Date`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20:`2013-S VEP-1991 X$!!`20`20`20Program`20Description`20`20`20:`20Restart`20MX`20and`20related`20p Vrocesses X$!!`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20 V`20:`20 X$`20SET`20PROC/PRIV=ALL`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20 V`20`20`20`20`20`20!get`20as`20many`20privs`20as`20possible X$`20MCP`20:=`20$MX_EXE:MCP.EXE`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20 V`20`20`20`20!files`20potentially`20called`20by X$`20FLQ`20:=`20$MX_EXE:FLQU.EXE`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20 V`20`20`20!`20`20`20RESET.COM X$`20OPT`20:=`20@MX_DIR:OPTIMIZE.COM`20`20`20`20`20`20`20`20`20`20`20`20`20`20! V X$`20LISTINGS`20:=`20@MX_DIR:ADDITIONS_CHECK.COM`20`20! X$`20FIXCOUNT`20:=`20$MX_EXE:FIXCOUNT.EXE`20`20`20`20`20`20`20`20`20! X$`20IF`20P1`20.EQS.`20"WARM"`20THEN`20GOTO`20WARM`20`20`20`20`20`20`20`20!this V`20just`20restarts`20MX X$`20IF`20P1`20.EQS.`20"NOSHUTDOWN"`20THEN`20GOTO`20CHECK`20!maintenance`20of V`20archive`20area X$`20MCP`20SHUTDOWN/ALL/CLUSTER`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20 V`20`20!shut`20MX`20down X$`20MCP`20QUEUE`20PURGE`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20 V`20`20`20`20`20`20`20`20!then`20purge`20the`20queue X$CHECK:`20`20`20!!`20Archive`20maintenance`20stuff`20--`20this`20also`20gives V`20time`20for`20processes X$!!`20`20`20`20`20`20`20`20`20to`20shut`20down. X$!!`20`20`20`20`20`20`20`20`20NOTE:`20we`20can`20go`20directly`20here`20with V`20NOSHUTDOWN`20as`20the`20value`20of`20P1 X$`20PURGE/KEEP=1/NOCONFIRM`20MX_ROOT:`5BFILESERV...`5D*.*`20`20!purge X$`20SET`20FILE`20MX_ROOT:`5BFILESERV...`5D*.*/PROT=(S:RWE,O:RWED,G:RE,W:RE) V`20`20!prots X$`20LISTINGS`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20 V`20`20`20`20`20`20`20`20`20`20`20`20!directories`20-`20`5BFILESERV.ADDITIONS V`5D X$`20IF`20P1`20.EQS.`20"NOSHUTDOWN"`20THEN`20GOTO`20FIXMAILCOUNT`20!fix`20mail V`20counts X$`20SET`20DEFAULT`20MX_FLQ_DIR`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20 V`20`20`20`20!directory`20of`20SYSTEM_QUEUE.FLQ_CTL X$`20LOOP_COUNT`20=`200`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20 V`20`20`20`20`20`20`20`20`20!initialize`20a`20loop X$LOOP:`20`20`20!!simple`20loop`20process`20used`20in`20evaluation X$`20LOOP_COUNT`20=`20LOOP_COUNT`20+`201`20`20`20`20`20`20`20`20`20`20`20`20 V`20`20!step`20counter X$`20IF`20LOOP_COUNT`20.EQ.`20600`20THEN`20GOTO`20WARM`20`20`20`20!allow`20100 V`20minutes`20to`20close X$!!`20`20`20`20`20`20`20`20`20everything;`20give`20up`20on`20optimizing`20file V`20if`20it`20can't`20shut`20down`20 X$!!`20`20`20`20`20`20`20`20`20in`20that`20time`20period`20and`20restart`20MX X$`20OPEN/READ`20FILE`20SYSTEM_QUEUE.FLQ_CTL/ERROR=NOT_YET`20!if`20we`20can`20r Vead`20it,`20it's X$!!`20`20`20`20`20`20`20`20`20not`20locked,`20so`20we'll`20lock`20it;`20if`20i Vt's`20locked,`20go`20back`20to`20loop: X$`20BACK/IGN=INT`20SYSTEM_QUEUE.FLQ_CTL.0`20SYSTEM_QUEUE.FLQ_OPT.0`20`20!if V`20it's`20not X$!!`20`20`20`20`20`20`20`20`20locked,`20make`20a`20backup`20and`20optimize`20i Vt X$`20OPT`20SYSTEM_QUEUE.FLQ_OPT`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20 V`20`20!analyze`20and`20convert`20the`20file X$`20COPY`20SYSTEM_QUEUE.FLQ_OPT`20SYSTEM_QUEUE.FLQ_CTL`20!copy`20the`20optimiz Ved`20file`20to X$!!`20`20`20`20`20`20`20`20`20the`20file`20name`20SYSTEM_QUEUE.FLQ_CTL`20(the V`20optimized`20FLQ_CTL`20file) X$`20CLOSE`20FILE`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20 V`20`20`20`20`20`20`20`20`20`20`20!unlock`20the`20file X$WARM:`20`20`20`20`20!!restart`20MX,`20by`20node X$!!`20`20`20`20`20`20`20`20`20NOTE:`20we`20can`20go`20directly`20here`20with V`20WARM`20as`20the`20value`20of`20P1 X$`20SUBMIT/QUE=MX$BATCH_ODIN/USER=MXMAILER/KEEP/NOPRINT`20MX_DIR:MX_START_ODIN V X$!!`20`20`20`20`20`20`20`20`20NOTE:`20ODIN`20is`20a`20special`20case`20since V`20it`20has`20JNET`20on`20it.`20`20See X$!!`20`20`20`20`20`20`20`20`20MX_START_ODIN.COM`20to`20view`20how`20we`20have V`20handled`20this. X$`20SUBMIT/QUE=MX$BATCH_FREYA/USER=MXMAILER/KEEP/NOPRINT`20SYS$STARTUP:MX_STAR VTUP X$`20SUBMIT/QUE=MX$BATCH_NIORD/USER=MXMAILER/KEEP/NOPRINT`20SYS$STARTUP:MX_STAR VTUP X$`20SUBMIT/QUE=MX$BATCH_FREYA/USER=MXMAILER/NOKEEP/NOPRINT/NOLOG`20MX_DIR:MCP- VQP X$!!`20This`20starts`20the`20queue`20purger`20process`20in`20batch`20on`20FREYA V X$`20IF`20P1`20.EQS.`20"WARM"`20THEN`20EXIT X$`20DELETE/NOCON`20SYSTEM_QUEUE.FLQ_OPT.*`20`20`20`20`20`20!delete`20the`20bac Vkup`20file X$`20PURGE/KEEP=1`20SYSTEM_QUEUE.FLQ_CTL`20`20`20`20`20`20`20`20!save`20only V`20the`20latest`20FLQ_CTL`20file X$FIXMAILCOUNT:`20`20`20`20`20!!get`20the`20mail`20counts`20correct`20for`20all V`20users X$`20FIXCOUNT X$`20EXIT X$NOT_YET:`20`20`20`20`20`20`20`20`20`20!!used`20in`20the`20loop`20above`20-- V`20see`20LOOP: X$`20WAIT`2000:00:10 X$`20GOTO`20LOOP X$`20EXIT $ call unpack [.MX_UTILS]RESET.COM;1 107874686 "" $ v=f$verify(v) $ exit ================================================================================ Archive-Date: Sat, 13 Mar 1993 14:29:18 CST Sender: list-mgr@WKUVX1.BITNET Date: Sat, 13 Mar 1993 14:22:22 CST From: "George D. Greenwade" Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <00969733.605F8F40.28663@SHSU.edu> Subject: RE: MLF /RETURN_ADDRESS Qualifier On Wed, 10 Mar 1993 12:04:45 CST, Howard Meadows posted: >>>Mailing lists: >>> Name: premed-advisor >>> Reply-to: List, NOSender >>> Return address: premed-advisor@uiowa.edu >> >>This should be right. >> >>What do the RFC822 headers show? It should show >>"premed-advisor@uiowa.edu" on the "Reply-To:" line. Does it? >> > > Yes, it does, but the VMS MAIL From: line shows > "premed-advisor@vaxa.weeg.uiowa.edu" Sounds like the intent is to get @uiowa.edu into the RFC822 FROM: entry as the host name. Hunter may not be getting this as he is exclusively using @WKUVX1.BITNET as the host name (i.e., the code may be rewriting the username, but is not rewriting the host name and is still using the logical MX_VMSMAIL_LOCALHOST or MX_NODE_NAME for the host extension). Since @uiowa.edu points to @vaxa.weeg.uiowa.edu (at least I assume this is the case since you want mail to go back there), why not: $ DEFINE/SYS/EXEC MX_NODE_NAME "uiowa.edu" $ DEFINE/SYS/EXEC MX_VMSMAIL_LOCALHOST "@uiowa.edu" in place of what I presume is now: $ DEFINE/SYS/EXEC MX_NODE_NAME "vaxa.weeg.uiowa.edu" $ DEFINE/SYS/EXEC MX_VMSMAIL_LOCALHOST "@vaxa.weeg.uiowa.edu" This is included on or about lines 2-3 of MX_DIR:MX_LOGICALS.DAT (which you can *carefully* edit -- mainly just play with the stuff following the second backslash "\"). Regards, George %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% George D. Greenwade, Ph.D. Bitnet: BED_GDG@SHSU Department of Economics and Business Analysis THEnet: SHSU::BED_GDG College of Business Administration Voice: (409) 294-1266 P. O. Box 2118 FAX: (409) 294-3612 Sam Houston State University Internet: bed_gdg@SHSU.edu Huntsville, TX 77341 bed_gdg%SHSU.decnet@relay.the.net %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% ================================================================================ Archive-Date: Sat, 13 Mar 1993 19:08:21 CST Sender: list-mgr@WKUVX1.BITNET From: Subject: Re: Two Routers anyone?? Message-ID: <1993Mar14.013737.1@sejnet.sunet.se> Date: 14 Mar 93 01:37:37 GMT Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET In article <0096972D.2EC6C760.28237@SHSU.edu>, "George D. Greenwade" writes: > We use the QUEUE > utility to achieve this -- it would be trivial DCL code to make this a > self-submitting file (but QUEUE's data survives when the system goes down, > which is why I recommend that path). So does a job submitted with /RESTART since the queue manager changes in 5.5. > I included a four hour loop in it to exit the > process as our SYSTEM_QUEUE file routinely gets rather large (it goes from > about 300 blocks to about 11,000 blocks in each 24 hour time period -- in > other words, going through a single MCP QUEUE PURGE pass has taken up to 4 > hours in the past; possibly ther new structure of MX_FLQ_DIR will alleviate > some of this). MCP QUEUE PURGE can indeed take enormous amounts of time. But at any rate you should not allow your queue file to extend under normal circumstances. With the .FI gateway on my MV3400 I wrapped the counter in 2-3 days and had no trouble keeping the queue file to around 3000 blocks. Anyway if you know the file is going to take 11000 blocks at the end of the day, just create it with that size and CBT to prevent a continuous degradation of performance during the day. Eric ================================================================================ Archive-Date: Sat, 13 Mar 1993 20:15:11 CST Sender: list-mgr@WKUVX1.BITNET From: Subject: Re: Translating errors Date: 14 Mar 1993 01:37:15 GMT Message-ID: <1nu28bINN95q@gap.caltech.edu> Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET In article <00969704.6C2F4920.5720@buckie.HSC.Colorado.EDU>, Dan Wing writes: =MX_SMTP_LOG.LOG contains: = ... = 12-MAR-1993 20:00:51.00 Recipient status=0C2680A4 for = = ... = =So I wanted to translate the error code: = = $ SET MESSAGE MX_MSG = $ WRITE SYS$OUTPUT F$MESSAGE(%X0C2680A4) = %NONAME-F-NOMSG, Message number 0C2680A4 = =(The logical MX_MSG points to the MX message file -- SET MESSAGE returns a =file-not-found error if you attempt to use SET MESSAGE with a file that =doesn't exist.) What TCP/IP package are you using? Could it be that them message is one associasted with your TCP/IP package rather than specifically with MX? What else was in the MX_SMTP_LOG.LOG file? That often provides clues. -------------------------------------------------------------------------------- Carl J Lydick | INTERnet: CARL@SOL1.GPS.CALTECH.EDU | NSI/HEPnet: SOL1::CARL Disclaimer: Hey, I understand VAXen and VMS. That's what I get paid for. My understanding of astronomy is purely at the amateur level (or below). So unless what I'm saying is directly related to VAX/VMS, don't hold me or my organization responsible for it. If it IS related to VAX/VMS, you can try to hold me responsible for it, but my organization had nothing to do with it. ================================================================================ Archive-Date: Sun, 14 Mar 1993 14:00:15 CST Sender: list-mgr@WKUVX1.BITNET Date: 14 Mar 1993 12:53:00 -0700 (MST) From: Dan Wing Reply-To: MX-List@WKUVX1.BITNET Subject: Re: Translating errors To: MX-List@WKUVX1.BITNET Message-ID: <01GVSRTJG0XE002I77@VAXF.COLORADO.EDU> Carl wrote: >=So I wanted to translate the error code: >= >= $ SET MESSAGE MX_MSG >= $ WRITE SYS$OUTPUT F$MESSAGE(%X0C2680A4) >= %NONAME-F-NOMSG, Message number 0C2680A4 > >What TCP/IP package are you using? TCPware. Message file is SYS$MESSAGE:TCPWARE_MSG, and that error code isn't there, either. >What else was in the MX_SMTP_LOG.LOG file? That often provides clues. 12-MAR-1993 20:00:48.58 Processing queue entry number 5691 on node BUCKIE 12-MAR-1993 20:00:49.06 Recipient: , route=vaxf.colo rado.edu 12-MAR-1993 20:00:49.07 SMTP_SEND: looking up host name vaxf.colorado.edu 12-MAR-1993 20:00:49.13 SMTP_SEND: Attempting to start session with vaxf.color ado.edu. [128.138.129.9] 12-MAR-1993 20:00:49.15 SMTP_SEND: Connected 12-MAR-1993 20:00:50.27 SMTP_SEND: Rcvd: 220 vaxf.Colorado.EDU -- Server SMTP (PMDF#2335 V4.1) 12-MAR-1993 20:00:50.36 SMTP_SEND: Sent: HELO buckie.hsc.colorado.edu 12-MAR-1993 20:00:50.37 SMTP_SEND: Rcvd: 250 vaxf.Colorado.EDU OK. 12-MAR-1993 20:00:50.38 SMTP_SEND: Sent: MAIL FROM: 12-MAR-1993 20:00:50.39 SMTP_SEND: Rcvd: 250 Address Ok. 12-MAR-1993 20:00:50.39 SMTP_SEND: Sent: RCPT TO: 12-MAR-1993 20:00:50.78 SMTP_SEND: Rcvd: 553 unknown or illegal user: bounce@V AXF.COLORADO.EDU 12-MAR-1993 20:00:50.78 SMTP_SEND: Sent: QUIT 12-MAR-1993 20:00:50.79 SMTP_SEND: Rcvd: 221 Bye received. Goodbye. 12-MAR-1993 20:00:51.00 Recipient status=0C2680A4 for 12-MAR-1993 20:00:53.08 Entry now completely processed, no retries needed. 12-MAR-1993 20:00:53.20 *** End of processing pass *** -Dan Wing, dwing@uh01.colorado.edu or wing_d@ucolmcc.bitnet (DGW11) Systems Administrator, University Hospital, Denver ================================================================================ Archive-Date: Mon, 15 Mar 1993 00:54:44 CST Sender: list-mgr@WKUVX1.BITNET From: Reply-To: MX-List@WKUVX1.BITNET Subject: Re: bouncy-bouncy Message-ID: <1993Mar15.060405.14906@netcom.com> Date: Mon, 15 Mar 1993 06:04:05 GMT To: MX-List@WKUVX1.BITNET once upon a time rbp@netcom.com (Bob Pasker) wrote: >i have a guy who keeps sending mail to which MLF cannot reply. the >message goes out, bounces at his site, and gets passed back to MLF, >which tries to reprocess the bounce message. how can i disable this >guy from sending stuff? >how about adding /NOACCESS=, where list-name is a mailing list >of all the folks being excluded. this would work the smae way /MAILING_LIST >would work, except it would *exclude* those users. well, it has happened again at a different site. all the users on a mailing list got a copy of bunch of bounces because the bouncing site did not obey the headers properly, and returned the messages to the reply-to address. evidently the queueing gave that absurd "could not send message for three days" message. here's the MX3.2 description: Name: listname Owner: "bob@HALFDOME.SF.CA.US" Reply-to: List, NOSender Errors-to: POSTMASTER@HALFDOME.SF.CA.US Strip header: NOReceived Protection: (SYSTEM:RWED,OWNER:RWED,GROUP:RWED,WORLD:RWE) a suggestion was made that i contact the offending sites postmaster (which i have done), tell them what happened, and hope they change it. but the truth of the matter is that there are plenty of errant sites out there and i think that, in this case, the best offense is a good defense. with the software as it is now, i have two possibilities for defending against errant sites: (a) change the list to "reply-to: Sender, NOList" (b) set the protection so that only members can send to the list. what i had previously suggested is sounding better: i would like to provide a list of users and/or sites that are prohibited from sending submissions or commands to lists and file servers. a few that come to mind right off the bat are: "mailer-daemon" and "uucp". what do other folks do to prevent bounces from errant sites going back through the lists or looping between an errant site and a -request line? -- -- bob pasker -- rbp@netcom.com -- ================================================================================ Archive-Date: Mon, 15 Mar 1993 00:59:11 CST Sender: list-mgr@WKUVX1.BITNET Date: Mon, 15 Mar 1993 00:58:47 CST From: Hunter Goatley Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <00969855.73120000.12306@WKUVX1.BITNET> Subject: Re: bouncy-bouncy writes: > [...] >what i had previously suggested is sounding better: i would like to >provide a list of users and/or sites that are prohibited from sending >submissions or commands to lists and file servers. a few that come to >mind right off the bat are: "mailer-daemon" and "uucp". > I've added this to the wish list.... >what do other folks do to prevent bounces from errant sites going back >through the lists or looping between an errant site and a -request line? > As soon as I see one of these, I immediately remove the offending user/site from the mailing list. One or two bounces make it to the list, but removing the user stops the infinite bounce because the messages are no longer sent to that site. Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@WKUVX1.BITNET (or goathunter%wkuvx1.bitnet@UKCC.UKY.EDU) ================================================================================ Archive-Date: Mon, 15 Mar 1993 05:17:21 CST Sender: list-mgr@WKUVX1.BITNET From: Subject: Re: Translating errors Date: 15 Mar 1993 10:41:31 GMT Message-ID: <1o1mgrINNjtk@gap.caltech.edu> Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET In article <01GVSRTJG0XE002I77@VAXF.COLORADO.EDU>, Dan Wing writes: >Carl wrote: >12-MAR-1993 20:00:50.39 SMTP_SEND: Sent: RCPT TO: >12-MAR-1993 20:00:50.78 SMTP_SEND: Rcvd: 553 unknown or illegal user: bounce@V > AXF.COLORADO.EDU The remote system wasn't happy with the address. Return code 553 is described in RFC821. I personally can't see how it applies here. Maybe you'll be able to figure it out, but as best I can tell, this response isn't supposed to be one you see under these circumstances. -------------------------------------------------------------------------------- Carl J Lydick | INTERnet: CARL@SOL1.GPS.CALTECH.EDU | NSI/HEPnet: SOL1::CARL Disclaimer: Hey, I understand VAXen and VMS. That's what I get paid for. My understanding of astronomy is purely at the amateur level (or below). So unless what I'm saying is directly related to VAX/VMS, don't hold me or my organization responsible for it. If it IS related to VAX/VMS, you can try to hold me responsible for it, but my organization had nothing to do with it. ================================================================================ Archive-Date: Mon, 15 Mar 1993 08:41:23 CST Sender: list-mgr@WKUVX1.BITNET Date: Mon, 15 Mar 1993 08:32:57 CST From: "George D. Greenwade" Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <00969894.E4EFC920.31267@SHSU.edu> Subject: Re: BITNET backlog (AAARRRRGGGGHHHHHH!) On Fri, 5 Mar 1993 18:04:05 GMT, Eric Thomas posted: > In article <009690B3.30BAE9A0.8066@WKUVX1.BITNET>, Hunter Goatley > writes: > > Well, once again, the demand for FILESERV@WKUVX1.BITNET has greatly > > exceeded the capabilities of our BITNET links (not mine so much as a > > link upstream from me. As of this time ( 5-MAR-1993 07:45), there > > are almost 1900 files queued from ULKYVM to UKCC. > > This does not surprise me given that there are many MX sites and only one > person ordered MX from the VMS store. The MX you get from the VMS store is > exactly the same as the one you get from FILESERV, and it comes in a single > piece, in VMSDUMP format, at T1 speed, and without causing problems for > Hunter and his users. All you have to do is type: > > $ send listserv@searn get [mx.mx032]mx032.zip I assume that I was the one person since I did get it from there. Eric's VMS store is probably the least painful way to retrieve documents and files (especialy large transfers like the entire MX distribution) for those of you who are BITNET connected. Between my original request from Texas to Sweden and having everything UNZIPped for VMSINSTAL purposes took about 12 minutes total! Definitely the way to go!!! Let's be honest -- Eric's LISTSERV software, which the VMS store runs under, is probably the easiest to use and most efficient BITNET/RSCS package around for large transfers since it now supports VMSDUMP retrieval format. Now, if we could only convince Hunter to move more toward this direction of support for MX on BITNET-to-BITNET transfers....... 8-) If you should need an alternate ftp site for retrieval of MX 3.2, BTW, it's available from Niord.SHSU.edu (192.92.115.8) in [FILESERV.MX] in both the ZIP sets and the individual VMSINSTALlable sets. Regards, George %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% George D. Greenwade, Ph.D. Bitnet: BED_GDG@SHSU Department of Economics and Business Analysis THEnet: SHSU::BED_GDG College of Business Administration Voice: (409) 294-1266 P. O. Box 2118 FAX: (409) 294-3612 Sam Houston State University Internet: bed_gdg@SHSU.edu Huntsville, TX 77341 bed_gdg%SHSU.decnet@relay.the.net %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% ================================================================================ Archive-Date: Mon, 15 Mar 1993 08:41:29 CST Sender: list-mgr@WKUVX1.BITNET Date: Mon, 15 Mar 1993 08:31:58 CST From: Howard Meadows Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <00969894.C203A940.11222@cslvax.weeg.uiowa.edu> Subject: RE: MLF /RETURN_ADDRESS Qualifier On Sat, 13 Mar 1993 14:22:22 CST, George D. Greenwade wrote: > >On Wed, 10 Mar 1993 12:04:45 CST, >Howard Meadows posted: > >>>>Mailing lists: >>>> Name: premed-advisor >>>> Reply-to: List, NOSender >>>> Return address: premed-advisor@uiowa.edu >>> >>>This should be right. >>> >>>What do the RFC822 headers show? It should show >>>"premed-advisor@uiowa.edu" on the "Reply-To:" line. Does it? >>> >> >> Yes, it does, but the VMS MAIL From: line shows >> "premed-advisor@vaxa.weeg.uiowa.edu" > >Sounds like the intent is to get @uiowa.edu into the RFC822 FROM: entry as >the host name. Hunter may not be getting this as he is exclusively using >@WKUVX1.BITNET as the host name (i.e., the code may be rewriting the >username, but is not rewriting the host name and is still using the logical >MX_VMSMAIL_LOCALHOST or MX_NODE_NAME for the host extension). > Yes, this was exactly the intent. "@uiowa.edu" is a mail exchanger on campus that translates aliases to "real" addresses. In this case, mail sent to "premed-advisor@uiowa.edu" gets sent to this machine first, then gets sent on to the "real" address which in this case is "premed-advisor@vaxa.weeg.uiowa.edu". What I want is similar to a general MX users who has set up the logical MX_REPLY_TO to point to a different return address. In this case, the address defined by the logical name gets inserted in the VMS Mail's "From:" header. I guess what I want is something that works that way for the LIST. > >Since @uiowa.edu points to @vaxa.weeg.uiowa.edu (at least I assume this is >the case since you want mail to go back there), why not: > $ DEFINE/SYS/EXEC MX_NODE_NAME "uiowa.edu" > $ DEFINE/SYS/EXEC MX_VMSMAIL_LOCALHOST "@uiowa.edu" >in place of what I presume is now: > $ DEFINE/SYS/EXEC MX_NODE_NAME "vaxa.weeg.uiowa.edu" > $ DEFINE/SYS/EXEC MX_VMSMAIL_LOCALHOST "@vaxa.weeg.uiowa.edu" >This is included on or about lines 2-3 of MX_DIR:MX_LOGICALS.DAT (which you >can *carefully* edit -- mainly just play with the stuff following the >second backslash "\"). > The thing with changing the logicals above is that makes the change global. Everyone's address on this machine will then have a return address ending in "@uiowa.edu". We only want that to happen for specific LISTs. :-) -Howard *************************************************************************** * Howard Meadows Sr. Systems Programmer Weeg Computing Center * * University Of Iowa Iowa City, Iowa 52242 Phone: 319-335-5519 * * email: howard-meadows@uiowa.edu * *************************************************************************** ================================================================================ Archive-Date: Mon, 15 Mar 1993 09:56:10 CST Sender: list-mgr@WKUVX1.BITNET Date: 15 Mar 1993 08:43:18 -0700 (MST) From: Dan Wing Reply-To: MX-List@WKUVX1.BITNET Subject: Re: Translating errors To: MX-List@WKUVX1.BITNET Message-ID: <01GVTVSS6GKI0098V9@VAXF.COLORADO.EDU> Carl wrote: >In article <01GVSRTJG0XE002I77@VAXF.COLORADO.EDU>, Dan Wing > writes: >>Carl wrote: >>12-MAR-1993 20:00:50.39 SMTP_SEND: Sent: RCPT TO: >>12-MAR-1993 20:00:50.78 SMTP_SEND: Rcvd: 553 unknown or illegal user: > bounce@VAXF.COLORADO.EDU > >The remote system wasn't happy with the address. Return code 553 is described >in RFC821. I personally can't see how it applies here. Maybe you'll be able >to figure it out, but as best I can tell, this response isn't supposed to be >one you see under these circumstances. PMDF is running on the remote system (VAXF), and PMDF sent it back. My question, though, was why the error code returned by MX (and was in the MX_SMTP_LOG.LOG file) couldn't be translated using SET MESSAGE. The error message was translated by MX itself, but I couldn't do it "by hand"??? Part of the message sent by POSTMASTER@mx_site: Error occurred sending to the following user(s): (via vaxf.colorado.edu): %MX_SMTP-F-MBX_SYNTAX_ERRO, action not taken: mailbox name not allowed -Dan Wing, dwing@uh01.colorado.edu or wing_d@ucolmcc.bitnet (DGW11) Systems Administrator, University Hospital, Denver ================================================================================ Archive-Date: Mon, 15 Mar 1993 11:27:15 CST Sender: list-mgr@WKUVX1.BITNET From: Reply-To: MX-List@WKUVX1.BITNET Subject: Upgraded from V3.1C to V3.2 - did I do it correctly? Message-ID: <15MAR93.11093205@swdev.si.com> Date: Mon, 15 Mar 1993 11:09:32 GMT To: MX-List@WKUVX1.BITNET Last night I upgraded from V3.1C of MX to V3.2. The installation apparently went fine, as there were no errors. I then executed MX_STARTUP on every node in my homogeneous cluster and sent myself a couple of messages. I also started a batch job that performs a MCP QUEUE SHOW/ALL every hour and went home. I did not delete any old logicals or REMOVE and old images with INSTALL. I assumed running MX_STARTUP would define everything properly. When I got back this morning, only one execution of the QUEUE SHOW command had been completed and th second one was still executing. I tried the command myself and it ran for about 20 minutes with no results. My queue file is about 6300 blocks long. Message numbers start at 6143 and end at 6383, but the SMTP server is continuing to accept messages, so the high number grows. Everything below 6272 has been delivered. Everything from there above is READY. I enabled DEBUG, but the debug logs just didn't appear, except for the SMTP server. Any suggestions on what part of MX I can examine to determine what's happening? -----------------------------+-------------------------------- Brian Tillman | Internet: tillman@swdev.si.com Smiths Industries, Inc. | tillman_brian@si.com 4141 Eastern Ave., MS129 | Hey, I said this stuff myself. Grand Rapids, MI 49518-8727 | My company has no part in it. -----------------------------+-------------------------------- ================================================================================ Archive-Date: Mon, 15 Mar 1993 16:04:35 CST Sender: list-mgr@WKUVX1.BITNET Date: Mon, 15 Mar 93 16:23:21 -0500 Message-ID: <9303152123.AA27409@genrad.com> From: Reply-To: MX-List@WKUVX1.BITNET X-MX-Warning: Warning -- Invalid "To" header. To: "mx-list%wkuvx1.bitnet@ukcc.uky.edu" Subject: MX Local dies... Due to causing a mail loop with my own mail forwarding (which involved two nodes running MRGATE), I managed to generate hundreds on messages which were undeliverable as it's trying to send them to MRGATE, which, of course, translates via system logical to MR%, so is invalid, e.g. MCP> que show/full 9999 Entry: 9999, Origin: [Local] <"cdclu1::cdclu1::cdclu1::cdclu1::cdclu1::cdclu1:: mrgate::\"CD3101::MRGATE\""@cdclu1> Status: IN-PROGRESS, size: 1487 bytes Created: 13-MAR-1993 09:09:02.82, expires 12-APR-1993 09:09:02.82 Last modified 13-MAR-1993 09:10:03.36 MLIST/FSRV entry #10003, status: READY, size: 1487 bytes Created: 13-MAR-1993 09:10:02.78, expires 12-APR-1993 09:09:02.82 Last modified 13-MAR-1993 09:10:03.48 Recipient #1: ListServ, Route=CDCLU1 That isn't the problem. I've fixed the mail loop and assume they will (eventually) all get rejected. The problem is that "MX Local" dies, with an error tranlating as "file not found". I was running 3.1C and upgrade to 3.2 in the hope it would fix it. Here's MX_LOCAL_DIR:MX_LOCAL_CD4000.LOG 15-MAR-1993 21:06:14.01: MX Local (pid 2B006978) starting 15-MAR-1993 21:11:59.74: MX Local (pid 2B006978) exiting, status = 10018294 and MX_LOCAL_DIR:MX_LOCAL_LOG.LOG 15-MAR-1993 21:11:58.58 Processing queue entry number 9051 %X10018294 translates to "%RMS-F-FNF, file not found". Can anyone suggest which file it's not finding, or, better, a way for "MX Local" to ignore this entry and proceed? Each time I restart it the entry number increments, so presumably it will eventually sort itself out. But I'd like to avoid restarting it several hundred times!! Thanks. -------------------------------------------------------------------------------- Name :Derek Dongray, Systems Manager, GenRad Ltd. Phone :061 486 1511 InterNet : Dongray@GenRad.com UKnet : Derek.Dongray@GenRad.co.uk PSS : 234261600119::Dongray CompuServe : 70374,2745 Address : Monmouth House, Monmouth Road, Cheadle Hulme, Cheshire, SK8 7AY, UK. ================================================================================ Archive-Date: Mon, 15 Mar 1993 16:14:18 CST Sender: list-mgr@WKUVX1.BITNET Date: Mon, 15 Mar 1993 14:14:25 EST From: "Brian Tillman, Smiths Industries, VAX Support, x8425" Reply-To: MX-List@WKUVX1.BITNET To: WKUVX1.BITNET!mx-list@esseye.si.com Message-ID: <009698C4.990D5C40.6743@swdev.si.com> Subject: RE: Upgraded from V3.1C to V3.2 - did I do it correctly? I've fixed my own problem. The problem was simply that the queue file was very large. I shut MX down, CONVERTed the file and restarted it. Everything went out then, and MCP QUEUE SHOW was no longer slow. -----------------------------+-------------------------------- Brian Tillman | Internet: tillman@swdev.si.com Smiths Industries, Inc. | tillman_brian@si.com 4141 Eastern Ave., MS129 | Hey, I said this stuff myself. Grand Rapids, MI 49518-8727 | My company has no part in it. -----------------------------+-------------------------------- ================================================================================ Archive-Date: Mon, 15 Mar 1993 16:20:46 CST Sender: list-mgr@WKUVX1.BITNET Date: Mon, 15 Mar 1993 16:20:18 CST From: Hunter Goatley Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <009698D6.2EDC2100.12729@WKUVX1.BITNET> Subject: RE: MX Local dies... writes: > >Due to causing a mail loop with my own mail forwarding (which involved two >nodes running MRGATE), I managed to generate hundreds on messages which were >undeliverable as it's trying to send them to MRGATE, which, of course, >translates via system logical to MR%, so is invalid, e.g. > [...] >%X10018294 translates to "%RMS-F-FNF, file not found". Can anyone suggest which >file it's not finding, or, better, a way for "MX Local" to ignore this entry >and proceed? Each time I restart it the entry number increments, so presumably >it will eventually sort itself out. But I'd like to avoid restarting it several >hundred times!! > If I remember right, this is caused by MX Local looking for the .MSG_TEXT or .LOCAL_INFO or something and not finding it. As you've seen, it doesn't handle that well. I've seen this happen too when a disk fills up. I had intended to do something about that in v3.2, but never did. I'll look at it for v3.2a. The only thing I know to suggest is MCP QUE CANCEL on the entry or entries.... Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@WKUVX1.BITNET (or goathunter%wkuvx1.bitnet@UKCC.UKY.EDU) ================================================================================ Archive-Date: Mon, 15 Mar 1993 17:32:59 CST Sender: list-mgr@WKUVX1.BITNET From: Subject: Re-routing xxx-request messages Date: 15 Mar 1993 22:06:43 GMT Message-ID: <1o2uljINNmv5@usenet.INS.CWRU.Edu> Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET I'm running a digest using the mx-digest software (works great!), but I do have one request. In my case, I am trying to only send the digest list, not the individual mail list. Unfortunately, that violates the "if xxx is the list to post to, then xxx-request is the list admin address" rule. Right now, I have the xxx list set up with world:W access, which bounces all the subscribe/signoff requests to me. Anyway to forward the xxx-request list to xxx-digest-request automatically? Aliasing didn't seem to work. Jim Carey by703@cleveland.Freenet.Edu ================================================================================ Archive-Date: Mon, 15 Mar 1993 23:51:41 CST Sender: list-mgr@WKUVX1.BITNET Date: Mon, 15 Mar 1993 21:42:12 PST From: "W. Todd Wipke" Reply-To: MX-List@WKUVX1.BITNET To: mx-list@WKUVX1.BITNET Message-ID: <00969903.272535A0.7796@SECS.UCSC.EDU> Subject: Queue entries that can not be cancelled I have a few entries that when you try queue cancel on them says that it can not find the record for that entry. What should I do to get rid of them? -Todd Wipke wipke@secs.ucsc.edu ================================================================================ Archive-Date: Tue, 16 Mar 1993 04:52:00 CST Sender: list-mgr@WKUVX1.BITNET Date: Tue, 16 Mar 93 05:33:41 -0500 Message-ID: <9303161033.AA08565@genrad.com> From: Reply-To: MX-List@WKUVX1.BITNET X-MX-Warning: Warning -- Invalid "To" header. To: "mx-list%wkuvx1.bitnet@ukcc.uky.edu" CC: Subject: RE: MX Local dies... Hunter writes: > writes: >> >>Due to causing a mail loop with my own mail forwarding (which involved two >>nodes running MRGATE), I managed to generate hundreds on messages which were >>undeliverable as it's trying to send them to MRGATE, which, of course, >>translates via system logical to MR%, so is invalid, e.g. >> > [...] >>%X10018294 translates to "%RMS-F-FNF, file not found". Can anyone suggest which >>file it's not finding, or, better, a way for "MX Local" to ignore this entry >>and proceed? Each time I restart it the entry number increments, so presumably >>it will eventually sort itself out. But I'd like to avoid restarting it several >>hundred times!! >> > If I remember right, this is caused by MX Local looking for the > .MSG_TEXT or .LOCAL_INFO or something and not finding it. As you've > seen, it doesn't handle that well. I've seen this happen too when a > disk fills up. I had intended to do something about that in v3.2, but > never did. I'll look at it for v3.2a. > > The only thing I know to suggest is MCP QUE CANCEL on the entry or > entries.... I tried cancel for a few, but after a while wrote the following. Someone else may find it useful. $ ! Kick start MX Local (and MX Router) $start: $ item="Local" $next: $ context="" $loop: $ pid="" $ pid=f$pid(context) $ if pid .nes. "" $ then $ procname=f$edit(f$getjpi("''pid'","prcnam"),"trim") $ if procname .nes. "MX ''Item'" then goto loop $ if item .nes. "Router" $ then $ item="Router" $ goto next $ endif $ wait 00:01:00 $ goto start $ endif $ write sys$output "Restarting MX ''item' at ''f$time()'" $ @mx_exe:mx_start 'item' $ goto start BTW, the mail loop actually involved Postmaster, which was why the problem occurred in the first place. It had a loop, which resulted in a message from MRGATE back to sender. However, this also had a loop, so MX tried to reply to a message from MRGATE, and, if you have Message Router, you will know that MRGATE is a system wide logical that translates to "MR%", which, of course, is an invalid recipient, so MRGATE bounces it... Personally, I blame DEC for choosing to use the username MRGATE to send the error messages when it is also a logical for the transport! The logical is translated first so forwarding of MRGATE never gets seen! Has anyone fixed this? Derek. -------------------------------------------------------------------------------- Name :Derek Dongray, Systems Manager, GenRad Ltd. Phone :061 486 1511 InterNet : Dongray@GenRad.com UKnet : Derek.Dongray@GenRad.co.uk PSS : 234261600119::Dongray CompuServe : 70374,2745 Address : Monmouth House, Monmouth Road, Cheadle Hulme, Cheshire, SK8 7AY, UK. ================================================================================ Archive-Date: Tue, 16 Mar 1993 05:58:40 CST Sender: list-mgr@WKUVX1.BITNET Date: Tue, 16 Mar 1993 12:38:09 CET From: Hans-Joachim Koch Reply-To: MX-List@WKUVX1.BITNET To: mx-list@WKUVX1.BITNET CC: sys_hjk@lifra.lif.de Message-ID: <00969980.50EBE960.20407@lifra.lif.de> Subject: MX cluster operation? Hello, I know, MX will run in the cluster. But I have a special question: I'm running a 8530 and a 4300 in a CI-cluster (4300 with ciqba). Only one node (the 8530) has Multinet installed and therefore can deal with smtp. Currently all MX processes are running on the old and heavy loaded 8530. I want to switch most of the MX processes to the 4300. What processes must stay on the 8530? Is it only the smtp agent, or the router also,... ? Thank you for any help. Hans. -- Hans-Joachim Koch, Computer department of Lahmeyer International Lyoner Strasse 22, POB 71 06 51, D-6000 Frankfurt (Main) 71, Germany Phone: +49 69 6677-642, Fax: +49 69 6677-571, Tx: 413478 li d EUnet: koch@lifra.lif.de, AMPRnet: dk9om@db0lj.ampr.org ================================================================================ Archive-Date: Tue, 16 Mar 1993 10:05:02 CST Sender: list-mgr@WKUVX1.BITNET Date: 16 Mar 1993 08:44:23 -0700 (MST) From: Dan Wing Reply-To: MX-List@WKUVX1.BITNET Subject: Re: MX cluster operation? To: MX-List@WKUVX1.BITNET CC: sys_hjk@lifra.lif.de Message-ID: <01GVVBUNLT2A006YJG@VAXF.COLORADO.EDU> >I'm running a 8530 and a 4300 in a CI-cluster (4300 with ciqba). Only >one node (the 8530) has Multinet installed and therefore can deal with >smtp. Currently all MX processes are running on the old and heavy loaded >8530. I want to switch most of the MX processes to the 4300. What >processes must stay on the 8530? Is it only the smtp agent, or the >router also,... ? The only thing that needs to run on the Multinet node is the SMTP delivery agent(s) and the SMTP Server. -Dan Wing, dwing@uh01.colorado.edu or dwing@buckie.hsc.colorado.edu Systems Administrator, University Hospital, Denver ================================================================================ Archive-Date: Tue, 16 Mar 1993 10:47:49 CST Sender: list-mgr@WKUVX1.BITNET From: Subject: Re: MX cluster operation? Message-ID: <1993Mar16.160854.29091@news.arc.nasa.gov> Reply-To: MX-List@WKUVX1.BITNET Date: Tue, 16 Mar 1993 16:08:54 GMT To: MX-List@WKUVX1.BITNET In article <00969980.50EBE960.20407@lifra.lif.de>, Hans-Joachim Koch writes: >I'm running a 8530 and a 4300 in a CI-cluster (4300 with ciqba). Only >one node (the 8530) has Multinet installed and therefore can deal with >smtp. Currently all MX processes are running on the old and heavy loaded >8530. I want to switch most of the MX processes to the 4300. What >processes must stay on the 8530? Is it only the smtp agent, or the >router also,... ? The SMTP delivery agent and server must both run on the 8530. The Router must also run there if you want MX to be able to properly handle host name expansion. Any others can run on the 4300. -Matt -- Matthew Madison | madison@tgv.com | +1 408 427 4366 TGV, Inc. | 603 Mission Street | Santa Cruz, CA 95060 USA ================================================================================ Archive-Date: Tue, 16 Mar 1993 11:33:03 CST Sender: list-mgr@WKUVX1.BITNET Date: 16 Mar 1993 10:11:27 -0700 (MST) From: Dan Wing Reply-To: MX-List@WKUVX1.BITNET Subject: Re: MX cluster operation? To: MX-List@WKUVX1.BITNET CC: madison@tgv.com Message-ID: <0096996B.D26B5BC0.5962@uh01.colorado.edu> >The SMTP delivery agent and server must both run on the 8530. The Router >must also run there if you want MX to be able to properly handle host name >expansion. Any others can run on the 4300. What sortof problems can you see if the router is running on the other node? I've got two nodes in my cluster, and one running TCP/IP. The router is running on the node that *isn't* running TCP/IP. Both nodes claim to be UH01.COLORADO.EDU, which is an MX record that (now) points to the node running the TCP/IP software. -Dan Wing, dwing@uh01.colorado.edu or wing_d@ucolmcc.bitnet (DGW11) Systems Administrator, University Hospital, Denver ================================================================================ Archive-Date: Tue, 16 Mar 1993 13:10:50 CST Sender: list-mgr@WKUVX1.BITNET Date: Tue, 16 Mar 93 13:45:00 -0500 Message-ID: <9303161845.AA17459@genrad.com> From: Reply-To: MX-List@WKUVX1.BITNET X-MX-Warning: Warning -- Invalid "To" header. To: "mx-list%wkuvx1.bitnet@ukcc.uky.edu" Subject: "MCP>SHOW QUE" spins its wheels? Since "blowing up" my MX process by getting it into an argument with MRGATE :-) I now have a problem ithat MCP> SHOW QUEUE doesn't do anything except lots of I/O!. I cleared the junk messages by repeated QUEUE CANCELs followed by deleteing all the files from the [QUEUE.%] subdirectories. Now SHOW QUEUE just seems to spin its wheels. Message delivery 'seems' to OK though. Here's the control-t output ... $ r mx_exe:mcp MCP> show que/full CD4000::DONGRAY 18:43:56 MCP CPU=00:06:57.15 PF=37664 IO=108192 MEM=786 CD4000::DONGRAY 18:43:59 MCP CPU=00:06:57.21 PF=37664 IO=108263 MEM=786 CD4000::DONGRAY 18:44:08 MCP CPU=00:06:57.37 PF=37664 IO=108462 MEM=786 CD4000::DONGRAY 18:44:14 MCP CPU=00:06:57.51 PF=37664 IO=108577 MEM=786 CD4000::DONGRAY 18:45:54 MCP CPU=00:06:59.92 PF=37665 IO=110712 MEM=787 CD4000::DONGRAY 18:49:17 MCP CPU=00:07:04.65 PF=37666 IO=114728 MEM=788 Is there some way to figure out what it's doing? And repair it? or should I just junk the queue file and start again? I've already tried optimizing it using ANAL/RMS/FDL, EDIT/FDL/SCRIPT=OPTIMIZE, CREATE/FDL and CONVERT/MERGE. This indicated that there were 933 records in the file. -------------------------------------------------------------------------------- Name :Derek Dongray, Systems Manager, GenRad Ltd. Phone :061 486 1511 InterNet : Dongray@GenRad.com UKnet : Derek.Dongray@GenRad.co.uk PSS : 234261600119::Dongray CompuServe : 70374,2745 Address : Monmouth House, Monmouth Road, Cheadle Hulme, Cheshire, SK8 7AY, UK. ================================================================================ Archive-Date: Tue, 16 Mar 1993 13:22:18 CST Sender: list-mgr@WKUVX1.BITNET Date: Tue, 16 Mar 93 14:05:37 -0500 Message-ID: <9303161905.AA17953@genrad.com> From: Reply-To: MX-List@WKUVX1.BITNET X-MX-Warning: Warning -- Invalid "To" header. To: "mx-list%wkuvx1.bitnet@ukcc.uky.edu" Subject: Re: "MCP> SHOW QUEUE" spins its wheels Ok, I found out what it was. FLQ was doing a purge and because I'd junked some 3000+ messages .... Derek. Dongray@GenRad.com ================================================================================ Archive-Date: Tue, 16 Mar 1993 14:30:29 CST Sender: list-mgr@WKUVX1.BITNET From: Subject: Re: Translating errors Date: 16 Mar 1993 19:37:07 GMT Message-ID: <1o5a93INN1c0g@rs1.rrz.Uni-Koeln.DE> Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET In article <00969704.6C2F4920.5720@buckie.HSC.Colorado.EDU>, Dan Wing writes: >Anyone know why this doesn't work? > >MX_SMTP_LOG.LOG contains: > ... > 12-MAR-1993 20:00:51.00 Recipient status=0C2680A4 for > > ... > >So I wanted to translate the error code: > > $ SET MESSAGE MX_MSG > $ WRITE SYS$OUTPUT F$MESSAGE(%X0C2680A4) > %NONAME-F-NOMSG, Message number 0C2680A4 > If I remember correctly, this message class is for CMU IP-transport (you have to look it up in the manual, or link the neterror.obj message object file to a .exe file and use that). -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ KOSMA = Koelner Observatorium fuer SubMillimeter-Astronomie Andreas Moravec TEL +49 (221) 470 3558 I. Physikalisches Institut FAX +49 (221) 470 5162 Universitaet zu Koeln TELEX 888 2291 UNIK D Zuelpicher Str. 77 INTERNET moravec@ph1.Uni-Koeln.DE 5000 Koeln 41, Germany X.400 S=Moravec;OU=Ph1;P=Uni-Koeln;A=DBP;C=DE ================================================================================ Archive-Date: Wed, 17 Mar 1993 03:52:12 CST Sender: list-mgr@WKUVX1.BITNET Subject: Rewriting, Decus UUCP, MX and ALL-In-1 Message-ID: <1993Mar17.150521.673@hhcs.gov.au> From: Carl Makin Reply-To: MX-List@WKUVX1.BITNET Date: 17 Mar 93 15:05:20 +1100 To: MX-List@WKUVX1.BITNET I'm having a problem in getting outbound mail addresses right. When sending from VMS mail through UUCP I had a rewrite rule setup in Decus UUCP to change VMS Mail addresses like CBR::MAKINC to makinc@cbr.hhcs.gov.au As far as I can see this is not possible with MX as MX automatically writes this as "cbr::makinc"@cnb07v.hhcs.gov.au (cnb07v is the only node running MX) Now I *much* prefer the previous format. I do have a MX rewrite rule in that does convert the former address into VMS Mail properly so the problem is only on outbound messages. Is there any way of modifying those outbound from addresses? Carl. -- Carl Makin (VK1KCM) Internet: makinc@hhcs.gov.au Amprnet: vk1kcm@vk1kcm.act.aus.oc "Life is something to do when you can't get to sleep." - Fran Lebowitz ================================================================================ Archive-Date: Wed, 17 Mar 1993 05:41:15 CST Sender: list-mgr@WKUVX1.BITNET Date: Wed, 17 Mar 1993 13:37 +0200 From: Eugenie Staicut Reply-To: MX-List@WKUVX1.BITNET Subject: Tools for VAX administration To: mx-list@WKUVX1.BITNET I am using a VAX node (with JNET, UCX, MX mailer) which is new in BITNET and Internet. I am looking for some tools useful for node administration on Vax. Can anybody give me some suggestions how can I get such tools? Thank you very much. Eugen Staicut ================================================================================ Archive-Date: Wed, 17 Mar 1993 12:48:48 CST Sender: list-mgr@WKUVX1.BITNET From: Subject: Re: Rewriting, Decus UUCP, MX and ALL-In-1 Message-ID: <1993Mar17.182106.2025@news.arc.nasa.gov> Reply-To: MX-List@WKUVX1.BITNET Date: Wed, 17 Mar 1993 18:21:06 GMT To: MX-List@WKUVX1.BITNET In article <1993Mar17.150521.673@hhcs.gov.au>, Carl Makin writes: >When sending from VMS mail through UUCP I had a rewrite rule setup >in Decus UUCP to change VMS Mail addresses like > >CBR::MAKINC >to >makinc@cbr.hhcs.gov.au > >As far as I can see this is not possible with MX as MX automatically >writes this as > >"cbr::makinc"@cnb07v.hhcs.gov.au [...] >Is there any way of modifying those outbound from addresses? Yes. Look at the NAME_CONVERSION stuff in the examples directory, or the DECNET_NAME_CONVERSION stuff Earle Ake wrote, which is in the user-contributed software directory. (That's if you installed those when you installed MX.) -Matt -- Matthew Madison | madison@tgv.com | +1 408 427 4366 TGV, Inc. | 603 Mission Street | Santa Cruz, CA 95060 USA ================================================================================ Archive-Date: Wed, 17 Mar 1993 13:09:21 CST Sender: list-mgr@WKUVX1.BITNET Date: Wed, 17 Mar 1993 11:25:43 CST From: "George D. Greenwade" Reply-To: MX-List@WKUVX1.BITNET To: mx-list@WKUVX1.BITNET Message-ID: <00969A3F.5C99D140.7963@SHSU.edu> Subject: Losing transport entries (maybe...) I have a problem (which may not be a problem, but...). I have moved our cluster installation to "pure" MX 3.2 (under VMS 5.5, with JNET, MultiNet [SMTP and SMTP server], UCX [SMTP only]) and have taken out the continuous purge process. NETLIB is properly initializing on each node as it should (i.e., it starts up for MultiNet on the MultiNet node and for UCX on the UCX node). I'm not suspicious of NETLIB because a few other things which rely on it are running fine (but maybe I'm just being naive). It appears that we are losing transport agent entries -- the ROUTER entries still show up under FLQ and MCP QUE SHOW in INP state, but related SMTP (especially) queue entries appear to have vanished. This is especially true for MLF-related entries, although I can see a few personal entries in that state as well. I have a funny feeling about this as I've had a few inquiries from people subscribed to a few lists here and they complain that they've received nothing recently (and that should not have been the case on these lists!). MCP QUE SHOW/FULL on such an entry indicates that it is IN_PROGRESS, but there is absolutely no indication that mail has been delivered, is going to be delivered, or is aware that it has apparently tried to do something previously, but isn't doing anything now. The MSG_TEXT and *_INFO files are where they're supposed to be and appear (via SEARCH) to have all of the proper information in them. I don't really want to MCP QUEUE READY these entries if it can be avoided as we are talking about quite a few subscribers in some cases and I would just as soon not have to re-use bandwidth (or bother the subscribers with what is likely a local problem). Any ideas, folks? Or is this an "optimized" use of queue space along the lines we have been talking about since 2.xx which I didn't see documented? Regards and thanks in advance for any insights on this, George %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% George D. Greenwade, Ph.D. Bitnet: BED_GDG@SHSU Department of Economics and Business Analysis THEnet: SHSU::BED_GDG College of Business Administration Voice: (409) 294-1266 P. O. Box 2118 FAX: (409) 294-3612 Sam Houston State University Internet: bed_gdg@SHSU.edu Huntsville, TX 77341 bed_gdg%SHSU.decnet@relay.the.net %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% ================================================================================ Archive-Date: Fri, 19 Mar 1993 14:53:23 CST Sender: list-mgr@WKUVX1.BITNET From: Reply-To: MX-List@WKUVX1.BITNET Subject: Re: Rewriting, Decus UUCP, MX and ALL-In-1 Message-ID: <1993Mar19.201610.25371@tigger.jvnc.net> Date: Fri, 19 Mar 1993 20:16:10 GMT To: MX-List@WKUVX1.BITNET >>When sending from VMS mail through UUCP I had a rewrite rule setup >>in Decus UUCP to change VMS Mail addresses like >> >>CBR::MAKINC >>to >>makinc@cbr.hhcs.gov.au Folks, I am trying to setup email on an Ultrix system (sendmail) which is a relay for All-In-1 mail to the Internet (via UUCP). The problem that I have is that the headers on the Ultrix system from the All-In-One mail looks like: hanv02::hanv02::mrgate::"a1::user" Well, I have managed to setup the sendmail so that email from the Internet can be sent to the A1 users using: user@hanv02.a1.internet-domain However, the problem that I have is that I can't seem to grab/rewrite the headers on the mail from the All-IN-1 to the Internet. As a result, the headers on the Internet host look like: "a1::user"%mrgate.dnet%hanv02.dnet.IP-Domain" Anyone else play with this ? Any idea how I can parse the headers from the A1 host and then rewrite them into a syntax like: user@host.a1.IP-domain Thanks, and please do email me directly also. -vikas (609) 258-2403 vikas@jvnc.net ...rutgers!jvncnet!vikas ------------------------------------------------------------------------- ================================================================================ Archive-Date: Fri, 19 Mar 1993 15:42:47 CST Sender: list-mgr@WKUVX1.BITNET Date: Fri, 19 Mar 1993 15:42:12 CST From: Hunter Goatley Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET CC: by703@cleveland.freenet.edu Message-ID: <00969BF5.860EAD40.14187@WKUVX1.BITNET> Subject: RE: Re-routing xxx-request messages writes: > >I'm running a digest using the mx-digest software (works great!), but Thanks. 8-) I wondered if anyone else was using that. I've got two digested lists (and boy were they tasty....). >I do have one request. In my case, I am trying to only send the digest >list, not the individual mail list. Unfortunately, that violates the >"if xxx is the list to post to, then xxx-request is the list admin address" >rule. Right now, I have the xxx list set up with world:W access, which >bounces all the subscribe/signoff requests to me. Anyway to forward the >xxx-request list to xxx-digest-request automatically? Aliasing didn't seem >to work. > The Router checks for the "-Request" address before it tries any aliasing, etc. How about this: get rid of the "real" list and set up aliases for that list and the "-request" list. For example, say you have list YYZ and you really only want YYZ-Digest. You could set up a dummy list (ZZZ) that includes YYZ@DIGEST.SITE as a subscriber. You could then alias YYZ to ZZZ and YYZ-Request to YYZ-Digest-request. I think that should work. Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@WKUVX1.BITNET (or goathunter%wkuvx1.bitnet@UKCC.UKY.EDU) ================================================================================ Archive-Date: Sat, 20 Mar 1993 00:10:53 CST Sender: list-mgr@WKUVX1.BITNET From: bleau@umdsp.umd.edu Subject: No incoming mail on cluster w/Multinet Date: 20 Mar 1993 01:41:10 GMT Message-ID: <1odsnm$sr@umd5.umd.edu> Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Hi. I've just transitioned two (existing) systems into a homogenous cluster, and all appears to be working except for incoming email. Both systems are running VMS V5.5-2 and MX V3.1C. I have the SMTP server, Local, and Router components running on each system. The quirk is that the boot node (SAMPX2) is running UCX V2.0 while the satellite node (SAMPX1) is running Multinet V3.0. Since I had MX running on each while the systems were standalone I thought there'd be no problem when clustered. When I clustered and MX stopped receiving I reconfigured MX, telling it that both my sytems were local nodes. This still didn't work. I then completely reinstalled MX (with the version C patch), and reinstalled NETLIB, too. I told it I'm using both UCX and Multinet, and it made two NETLIB_*_SHR sharable images for me. I edited NETLIB_STARTUP.COM and put in some conditional code to define the logicals as one or the other of the images. Still no go. Now for the strange part. On a third system (standalone) I send a short message to SYSTEM on each of my two clustered nodes. It gets received on SAMPX2 (the boot node, which has UCX) properly. The other message never shows up. I checked the queue and it isn't there at all: no FINISH, no IN_PROGRESS, no nothin' :-( I then defined the debugging logicals on both my clustered nodes, setting them to look at SMTP, SMTP_SERVER, ROUTER, and LOCAL. The log files appear for incoming email on the boot node and everything looks kosher. On SAMPX1 (the satellite node) the log file never gets created. That is to say, every log file that gets created in, say, MX_SMTP_DIR:, was put there by SAMPX2 receiving mail, as evidenced by the To: lines in the messages. I enabled debugging on the sending system, and for the SAMPX1 messages it reports that it connected to Multinet and transferred the message without any error (status 00000001, no retry needed). I _have_ disabled the SMTP server on the Multinet node. BTW, I did not reinstall Multinet after I went to a cluster. Since it was already on SAMPX1's old system disk, I just edited a dummy startup file to invoke Multinet's startup file from the proper directory. Oh yes, I had to extract the .CLD files and update DCLTABLES with Multinet's commands. I created a different copy of DCLTABLES so the UCX commands wouldn't get clobbered and installed it in SAMPX1's SYS$SPECIFIC:[SYSLIB]. That part works fine, anyway. I have incoming and outgoing TELNET and FTP on SAMPX1 working. This has turned into quite a puzzle, and I'm starting to run out of ideas/leads. Does anyone have a suggestion or two? Enclosed is a copy of my MX configuration file. Let me know if you want one form Multinet, too. Larry Bleau University of Maryland bleau@umdsp.umd.edu 301-405-6223 Configuration file: MX_DEVICE:[SYS.MXMAILER]MX_CONFIG.MXCFG;1 MX version id is: MX V3.1C Domain-to-path mappings: Domain="sampx1.umd.edu", Path=Local Domain="sampx1", Path=Local Domain="sampx2.umd.edu", Path=Local Domain="sampx2", Path=Local Domain="[128.8.162.54]", Path=Local Domain="[128.8.162.55]", Path=Local Domain="*.UUCP", Path=SMTP, Route="uunet.uu.net" Domain="*.BITNET", Path=SMTP, Route="cunyvm.cuny.edu" Domain="*", Path=SMTP Aliases: LocalName="Postmaster", Address="bleau@umdsp.umd.edu" LocalName="POSTMAST", Address="bleau@umdsp.umd.edu" SMTP agent settings: Retry interval: 0 00:30:00.00 Maximum number of retries: 96 Number of DNS failure retries: 12 Accounting: disabled Default router: (none) LOCAL agent settings: DECnet delivery retry interval: 0 00:30:00.00 Maximum number of retries: 96 Accounting disabled. Top headers: FROM,SENDER,TO,RESENT_TO,CC,RESENT_CC,BCC,RESENT_BCC,MESSAGE_ID, RESENT_MESSAGE_ID,IN_REPLY_TO,REFERENCES,KEYWORDS,SUBJECT, ENCRYPTED,DATE,REPLY_TO,RECEIVED,RESENT_REPLY_TO,RESENT_FROM, RESENT_SENDER,RESENT_DATE,RETURN_PATH,OTHER Bottom headers: (none) ROUTER agent settings: Automatic percent-hack handling: enabled ================================================================================ Archive-Date: Mon, 22 Mar 1993 12:06:46 CST Sender: list-mgr@WKUVX1.BITNET Date: Mon, 22 Mar 1993 12:56:10 EST From: jim@immune.med.utoronto.ca Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <00969E39.D3B6DEA0.1401@immune> Subject: MX work with ALL-IN-1 for Macintosh We are using MX mail. I try to use all-in-1 mail for macintosh, I do not know all-in-1 mail can work under MX or not. Thank you very much for any information Jim Wei University of Toronto ================================================================================ Archive-Date: Mon, 22 Mar 1993 12:28:09 CST Sender: list-mgr@WKUVX1.BITNET From: Subject: "Organization:" line? Date: 22 Mar 1993 17:20:00 GMT Message-ID: <00969E23.9F0BE800@buckie.HSC.Colorado.EDU> Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Any plans on adding support for an "Organization:" header to MX? This doesn't seem to be be an RFC822 "standard", but I've noticed some mailers using it, and it could be useful...? -dan -Dan Wing, Systems Administrator, University Hospital, Denver dwing@uh01.colorado.edu or wing_d@ucolmcc.bitnet ================================================================================ Archive-Date: Mon, 22 Mar 1993 14:19:57 CST Sender: list-mgr@WKUVX1.BITNET From: Reply-To: MX-List@WKUVX1.BITNET Subject: Re: "Organization:" line? Message-ID: Date: Mon, 22 Mar 1993 19:15:01 GMT To: MX-List@WKUVX1.BITNET dwing@uh01.colorado.edu (Dan Wing) writes: >Any plans on adding support for an "Organization:" header to MX? >This doesn't seem to be be an RFC822 "standard", but I've noticed some >mailers using it, and it could be useful...? what would be truly useful is to have MX translate logical names of the form: MX-X-* and insert the resultant string into the header. e.g.: $ assign "ABC, Corp." MX-X-ORGANZIATION would result in X-Organization: ABC, Corp. in the header. alternatively: $ assign/table=LNM$MX "ABC, Corp." X-ORGANIZATION -- -- bob pasker -- rbp@netcom.com ================================================================================ Archive-Date: Mon, 22 Mar 1993 14:20:22 CST Sender: list-mgr@WKUVX1.BITNET From: bleau@umdsp.umd.edu Subject: Re: No incoming mail on cluster w/Multinet Date: 22 Mar 1993 17:46:03 GMT Message-ID: <1oku0r$kvf@umd5.umd.edu> Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Hello again. Well, the ``MX mail non-delivery in a cluster'' problem has been solved. First, thanks to those who sent me email and really helped to solve the problem, notably Dan Wing and Matt Madison. The problem, it turned out, was quite simple: the SMTP Server agent was not running on my SAMPX1 system. Using MCP STATUS showed this quite well. I also checked MX_STARTUP_INFO.DAT to make sure it is supposed to start up on each system; it was, there was a '*' in the node field. I was able to shut down and restart MX on both systems, and all agents came up this time. I've no idea what the SMTP Server didn't start on SAMPX1 last Friday, but I'll keep an eye on it in case it happens again. Other ideas put forth on why the SMTP Server might fail in this manner are: ----------------------------------------------------------------------------- From: Andreas Moravec have you switched off the smtp server code of MultiNet ? (necessary for MX to receive smtp messages, test with multinet configure/server show/full smtp it should show up as DISABLED; if not, disable it) ----------------------------------------------------------------------------- From: Dan Wing What happens if you try to TELNET to port 25 of each system? Does each system respond properly? (after the initial announcement of what node you connected to, you just type QUIT to make the SMTP server on the remote node give up on you and disconnect). Not much of an idea, but it might help you out a little. How about output from MCP> STATUS ? BTW, most recent version of MX is V3.2, available from ftp.spc.edu and Hunter's FILESERV. Although this probably isn't related to your problem. ----------------------------------------------------------------------------- From: Matt Madison It looks like the SMTP server on SAMPX1 isn't running. You might want to check the following to see why: - Check the NETLIB_SHR logical name to make sure it's pointing to NETLIB_DIR:NETLIB_MULTINET_SHR. - Check the MX_DIR:MX_STARTUP_INFO.DAT file to make sure that the SMTP server is set up to run on SAMPX1. You could try firing up the SMTP server interactively on SAMPX1 to see if it fails: $ RUN MX_EXE:SMTP_SERVER (from a suitably privileged account, of course). BTW, you might want to consider upgrading your MultiNet installation to V3.2; V3.0 is no longer supported. ----------------------------------------------------------------------------- From: "Pasztor Miklos" My guess is, that you didn't RESTART the Multinet server. Try to telnet in the smtp port of the machine, by entering: Telnet/port=25 It will tell you if your "MX SMTP server is ready". Hope this helps a bit. ----------------------------------------------------------------------------- ================================================================================ Archive-Date: Mon, 22 Mar 1993 18:48:06 CST Sender: list-mgr@WKUVX1.BITNET From: Subject: DidYouKnow... Message-ID: <1993Mar22.231805.21233@midway.uchicago.edu> Reply-To: MX-List@WKUVX1.BITNET Date: Mon, 22 Mar 1993 23:18:05 GMT To: MX-List@WKUVX1.BITNET Today Japan owns the 7/11 store chain, Dunlop, Universal Pictures, Columbia Pictures, Loews Theaters, MCA Home Entertainment, Tri-Star Pictures, CBS Records, Columbia Records, Spencers stores, Ciniplex Odeon (a big part), Firestone Tires and many many more very large US companies while Americans are prevented from owning any important Japanese concerns. To find out more about this (and get a more complete list of the above), read (JAPANYES) "Does America Say Yes To Japan?";Louis Leclerc 1992,93 which is available free on INTERNET. (most recent edition is v031993). This thoughtfully written and important article has been circulating widely in many of America's biggest corporations & universities like IBM & Harvard. When you read it (it takes about 30 minutes), you'll see why. The essay provides a frightening yet fascinating detailed, referenced overview of the Japanese industrial machine at work and how Japan practices 'business is war' strategies to target and take over strategic critical U.S. industries like high technology, popular media and heavy industry as well as influence the decisions of the US government in favor of Japan. It is a very moving piece and is filled with many verifiable and disturbing examples. You can get JAPANYES 1 of 3 ways: 1)FTP to monu6.cc.monash.edu.au it's in directory: pub/nihongo as: JAPANYES 2)The article has been posted in its entirety (in three sections however) in the misc.test & soc.culture.usa & sci.econ newsgroups. Search on the author 'buzy' or the title 'article' to find the posts. 3)Email a request for JAPANYES to ar12@midway.uchicago.edu He will email you a copy. ================================================================================ Archive-Date: Mon, 22 Mar 1993 20:37:32 CST Sender: list-mgr@WKUVX1.BITNET From: Subject: Re: No incoming mail on cluster w/Multinet Date: 23 Mar 1993 01:29:17 GMT Message-ID: <1olp5dINN9ih@gap.caltech.edu> Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET In article <1oku0r$kvf@umd5.umd.edu>, bleau@umdsp.umd.edu writes: =The problem, it turned out, was quite simple: the SMTP Server agent was not =running on my SAMPX1 system. Using MCP STATUS showed this quite well. I also =checked MX_STARTUP_INFO.DAT to make sure it is supposed to start up on each =system; it was, there was a '*' in the node field. I was able to shut down and =restart MX on both systems, and all agents came up this time. I've no idea =what the SMTP Server didn't start on SAMPX1 last Friday, but I'll keep an eye =on it in case it happens again. Here's a guess: SAMPX1 is the machine running MULTINET? Well, when I start MX immediately after starting MULTInet, sometimes SMTP_SERVER and MX_SMTP die immediately. I suspect that there's some sort of race condition between MULTInet starting up something internally and MX creating these processes. I.e., if MX creates the processes before MULTInet manages to get something critical done, the processes immediately die. You don't have to restart MX, just start those processes after you're sure MULTInet's all the way up. -------------------------------------------------------------------------------- Carl J Lydick | INTERnet: CARL@SOL1.GPS.CALTECH.EDU | NSI/HEPnet: SOL1::CARL Disclaimer: Hey, I understand VAXen and VMS. That's what I get paid for. My understanding of astronomy is purely at the amateur level (or below). So unless what I'm saying is directly related to VAX/VMS, don't hold me or my organization responsible for it. If it IS related to VAX/VMS, you can try to hold me responsible for it, but my organization had nothing to do with it. ================================================================================ Archive-Date: Mon, 22 Mar 1993 22:26:31 CST Sender: list-mgr@WKUVX1.BITNET From: frzmtdb@aspentec.com Reply-To: MX-List@WKUVX1.BITNET Subject: HELP! MX uucp Intfc is dying!!!! Message-ID: <1993Mar22.214614.946@aspentec.com> Date: 22 Mar 93 21:46:13 EST To: MX-List@WKUVX1.BITNET Help!!! After upgrading my MX to 3.2 (from 3.1c) I find that my MX uucp Intfc process dies every few minutes with a traceback as show below:  22-MAR-1993 21:38:36.71: MX uucp Intfc (pid 2AC01133) starting %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=00000000, PC=0000279F, PSL=03C00000 %TRACE-F-TRACEBACK, symbolic stack dump follows module name routine name line rel PC abs PC UUCP_PARSE MX_TO_UUCP 94 0000005B 0000279F DELIVER DELIVER 146 00000154 00001BE4 PROCESS PROCESS 223 000002B6 000019ED MX_UUCP MX_UUCP 30 00000313 00001313 22-MAR-1993 21:39:47.41: MX uucp Intfc (pid 2AC01133) exiting, status = 1000000C FRZMTDB job terminated at 22-MAR-1993 21:39:47.92 Accounting information: Buffered I/O count: 244 Peak working set size: 1111 Direct I/O count: 1156 Peak page file size: 4978 Page faults: 14554 Mounted volumes: 0 Charged CPU time: 0 00:00:04.56 Elapsed time: 0 00:01:27.27 Any ideas??? My VMS is 5.5-2 thanks, fred ----- Fred R. Ziegler Email: Aspen Technology, Inc. tel: +1-617-577-0100 x262 Ten Canal Park fax: +1-617-577-0303 Cambridge, Ma. 02141 telex: +1-948-038(ASPEN TECH) U.S.A. Internet Society Member (#1315080) since Feb 1992 ================================================================================ Archive-Date: Tue, 23 Mar 1993 02:26:33 CST Sender: list-mgr@WKUVX1.BITNET Date: Tue, 23 Mar 1993 09:21:06 MEZ From: Peter Kobe Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <00969EE4.F265FA60.7914@pib1.physik.uni-bonn.de> Subject: SMTP_SERVER exits Helo, SMTP_SERVER stops with error message %STR-F-STRTOOLON, string is too long (greater than 65535) must that be? Cant SMTP_SERVER just discard messages which are of that non handable type? We had yesterday a backlog of some 400 mails. the reason was that user INNOCENT@A.B.C.D sent a 90 kbyte Postsript-file via mail. That message killed SMTP_SERVER. So it was hold by our main campus mailer. That machine tried to send that nasty file to the VAX every time I had restarted MX3.2 and again and again killed SMTP_SERVER until I finally found out about that beast and we took it from the mailer. Peter [ ===================================================================== Peter Kobe Internet: Peter.Kobe@uni-bonn.de Physikalisches Institut HEPNET: 13562::SYSTEM Universitaet Bonn Tel: (49) 228 73 3222 D 53 Bonn FAX: (49) 228 73 7869 Nussallee 12 ================================================================================ Archive-Date: Tue, 23 Mar 1993 09:28:06 CST Sender: list-mgr@WKUVX1.BITNET Date: Tue, 23 Mar 1993 09:02:58 EST From: "Brian Tillman, Smiths Industries, VAX Support, x8425" Reply-To: MX-List@WKUVX1.BITNET To: WKUVX1.BITNET!MX-list@esseye.si.com CC: buzy@quads.uchicago.edu, ar12@midway.uchicago.edu Message-ID: <00969EE2.69BEAE20.11385@swdev.si.com> Subject: RE: Does America Say YES to Japan writes: >Today Japan owns the 7/11 store chain, Dunlop, Universal Pictures, Columbia >Pictures, Loews Theaters, MCA Home Entertainment, Tri-Star Pictures, CBS >Records, Columbia Records, Spencers stores, Ciniplex Odeon (a big part), >Firestone Tires and many many more very large US companies while Americans >are prevented from owning any important Japanese concerns. >...more stuff deleted... I am offended by the posting of this type of crud in a discussion of the MX mailer and I wish the poster would have thought a little more clearly before posting. Not only is the posting misplaced, but it shows an almost racist attitude, in my opinion. The British own a much greater percent of American-based business than Japan, yet no one seems to squawking about how we're selling our seed corn to them. Why? Because people still carry a hatred left over from World War II, because the Japanese are so clearly different from the WASP in the United States, and because they have been apparently so successful in going the US one better in the world economy and we're embarrassed, so we take it out on the Japanese by promulgating tripe such as the above. If you really want to stop this type of encroachment (and I, for one, do not believe it necessary), then find ways to make US businesses more productive, instead of wasting your time fomenting discord with the Japanese. The former will get you somewhere. The latter is nothing more than wringing your hands and feeling sorry for yourself. -----------------------------+-------------------------------- Brian Tillman | Internet: tillman@swdev.si.com Smiths Industries, Inc. | tillman_brian@si.com 4141 Eastern Ave., MS129 | Hey, I said this stuff myself. Grand Rapids, MI 49518-8727 | My company has no part in it. -----------------------------+-------------------------------- ================================================================================ Archive-Date: Tue, 23 Mar 1993 09:53:48 CST Sender: list-mgr@WKUVX1.BITNET Date: Tue, 23 Mar 1993 09:47:56 CST From: Hunter Goatley Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <00969EE8.B25DEE60.15207@WKUVX1.BITNET> Subject: RE: Does America Say YES to Japan "Brian Tillman, Smiths Industries, VAX Support, x8425" writes: > > writes: > >>Today Japan owns the 7/11 store chain, Dunlop, Universal Pictures, Columbia [...] > >I am offended by the posting of this type of crud in a discussion of the MX >mailer and I wish the poster would have thought a little more clearly before [...] He apparently posted it to almost every group out there. Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@WKUVX1.BITNET (or goathunter%wkuvx1.bitnet@UKCC.UKY.EDU) ================================================================================ Archive-Date: Wed, 24 Mar 1993 05:53:20 CST Sender: list-mgr@WKUVX1.BITNET Subject: Re: Rewriting, Decus UUCP, MX and ALL-In-1 Message-ID: <1993Mar24.140619.684@hhcs.gov.au> From: Carl Makin Reply-To: MX-List@WKUVX1.BITNET Date: 24 Mar 93 14:06:19 +1100 To: MX-List@WKUVX1.BITNET In article <1993Mar19.201610.25371@tigger.jvnc.net> Vikas Aggarwal, aggarwal@tigger.jvnc.net writes: > The problem that I have is that the headers on the Ultrix system from > the All-In-One mail looks like: > hanv02::hanv02::mrgate::"a1::user" > However, the problem that I have is that I can't seem to grab/rewrite > the headers on the mail from the All-IN-1 to the Internet. As a result, > the headers on the Internet host look like: > "a1::user"%mrgate.dnet%hanv02.dnet.IP-Domain" This is the exact problem I'm also trying to solve, only I have a further problem. Our All-In-1 usernames have a space in them so the VMS mail address comes out like; cbr::mrgate::"a1::lastname firstname" ^ note the space. :-( The best bet so far looks like using the host and domain rewriting exits supported under MX 3.1c. (Thanks Mathew) Carl. -- Carl Makin (VK1KCM) Internet: makinc@hhcs.gov.au Amprnet: vk1kcm@vk1kcm.act.aus.oc "Life is something to do when you can't get to sleep." - Fran Lebowitz ================================================================================ Archive-Date: Thu, 25 Mar 1993 18:56:57 CST Sender: list-mgr@WKUVX1.BITNET Subject: Mail to News Gateway Message-ID: <1993Mar25.111342.685@hhcs.gov.au> From: Carl Makin Reply-To: MX-List@WKUVX1.BITNET Date: 25 Mar 93 11:13:42 +1100 To: MX-List@WKUVX1.BITNET I just installed the mail to news gateway that comes as part of the .contrib directory with mx031c. I had one problem (so far. :-), the file SITE-DELIVER.COM seems to have been written for mx2.x and wasn't updated for 3.1. You have to change the following references P1 to P2 P2 to P3 in the open addfile 'p2 line and !notify postmaster (mail 'p1 ..., del 'p1, del 'p2 lines) proc_list: (mail 'p1 ..., del 'p1, del 'p2 lines) gate_err: (mail 'p1 ..., del 'p1, del 'p2 lines) subroutines. P1 and P4 arn't used. Carl. -- Carl Makin (VK1KCM) Internet: makinc@hhcs.gov.au Amprnet: vk1kcm@vk1kcm.act.aus.oc "Life is something to do when you can't get to sleep." - Fran Lebowitz ================================================================================ Archive-Date: Thu, 25 Mar 1993 18:57:38 CST Sender: list-mgr@WKUVX1.BITNET Subject: MLF -Request function and .sig files Message-ID: <1993Mar24.152357.2614@vixvax.mgi.com> From: lokhorst@vixvax.mgi.com Reply-To: MX-List@WKUVX1.BITNET Date: 24 Mar 93 15:23:56 CDT To: MX-List@WKUVX1.BITNET Hello, I have a question about the -Request service provided by the MLF. In older versions -Request used to handle single commands. With the newer versions of MX (>= 3.0) MLF started answering multiple commands. At our site many people have a signature file automatically included into their mail messages. Therefore, when they send a message to a list's -Request address they get the expected response as well as a message from the PostMaster complaining that it can't interpret their .sig lines. Is their any way around this short of telling people "don't do that"? Thanks, Mark. /*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-\ * | | Mark Lokhorst Internet: lokhorst@mgi.com * * Management Graphics, Inc. Voice Mail: (612) 851-6174 | | 1401 East 79th Street Operator: (612) 854-1220 * * Minneapolis, MN 55425 Fax: (612) 851-6159 | | * \-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*/ ================================================================================ Archive-Date: Thu, 25 Mar 1993 19:04:05 CST Sender: list-mgr@WKUVX1.BITNET Subject: Re: MLF -Request function and .sig files Message-ID: From: Reply-To: MX-List@WKUVX1.BITNET Date: Thu, 25 Mar 1993 19:38:02 GMT To: MX-List@WKUVX1.BITNET madison@tgv.com (Matt Madison) writes: >Maybe Hunter could add an "END" command, or something along those lines, which >will tell MLF to stop processing any more of the message. Of course, you'd >then have to get people to use the new command. unless i'm mistaken,i think 3.2 includes a "QUIT" command. -- -- bob pasker -- rbp@netcom.com -- ================================================================================ Archive-Date: Thu, 25 Mar 1993 19:04:29 CST Sender: list-mgr@WKUVX1.BITNET Subject: Re: MLF -Request function and .sig files Message-ID: <1993Mar25.231349.1@sejnet.sunet.se> From: Date: 25 Mar 93 23:13:49 GMT Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET >>Maybe Hunter could add an "END" command, or something along those lines, which >>will tell MLF to stop processing any more of the message. Of course, you'd >>then have to get people to use the new command. >> > I'd like to see a "QUIT" command like the file server now has (in 3.2), > but until then, I've been using /nosig at the end of my mail to the > -Request server. In my experience this isn't a problem. Once users understand that the errors are due to the signature, they don't care: typing /NOSIG or END or QUIT or // EOJ is a waste of keystrokes at two-fingers typing speed ;-) They prefer to save time and just ignore the errors. The problem, however, is letterhead crap added by A1, PROFS, OV, Macs, you name it. Eric ================================================================================ Archive-Date: Thu, 25 Mar 1993 19:04:40 CST Sender: list-mgr@WKUVX1.BITNET Subject: Re: MLF -Request function and .sig files Message-ID: <1993Mar25.202506.2397@news.weeg.uiowa.edu> From: meadows@cslvax.weeg.uiowa.edu Date: Thu, 25 Mar 1993 20:25:06 GMT Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET In article <1993Mar25.201504.16016@news.weeg.uiowa.edu>, meadows@cslvax.weeg.uiowa.edu writes: > > I'd like to see a "QUIT" command like the file server now has (in 3.2), >but until then, I've been using /nosig at the end of my mail to the >-Request server. > >-Howard > Actually, I just tried QUIT with the -Request server, using the REVIEW command, and it worked the same as the FILESERV, so I guess it's already there! :-) *************************************************************************** * Howard Meadows Sr. Systems Programmer Weeg Computing Center * * University Of Iowa Iowa City, Iowa 52242 Phone: 319-335-5519 * * email: howard-meadows@uiowa.edu * *************************************************************************** ================================================================================ Archive-Date: Thu, 25 Mar 1993 19:04:47 CST Sender: list-mgr@WKUVX1.BITNET Subject: Re: MLF -Request function and .sig files Message-ID: <1993Mar25.183515.8875@news.arc.nasa.gov> From: Date: Thu, 25 Mar 1993 18:35:15 GMT Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET In article <1993Mar24.152357.2614@vixvax.mgi.com>, lokhorst@vixvax.mgi.com writes: > I have a question about the -Request service provided by the MLF. >In older versions -Request used to handle single commands. With the newer >versions of MX (>= 3.0) MLF started answering multiple commands. At our >site many people have a signature file automatically included into their >mail messages. Therefore, when they send a message to a list's -Request >address they get the expected response as well as a message from the >PostMaster complaining that it can't interpret their .sig lines. > > Is their any way around this short of telling people "don't do that"? Maybe Hunter could add an "END" command, or something along those lines, which will tell MLF to stop processing any more of the message. Of course, you'd then have to get people to use the new command. -Matt -- Matthew Madison | madison@tgv.com | +1 408 427 4366 TGV, Inc. | 603 Mission Street | Santa Cruz, CA 95060 USA ================================================================================ Archive-Date: Thu, 25 Mar 1993 19:04:59 CST Sender: list-mgr@WKUVX1.BITNET Subject: Re: MLF -Request function and .sig files Message-ID: <1ot0bt$cj7@umd5.umd.edu> From: dmatthews@uap.umd.edu Date: 25 Mar 1993 19:15:09 GMT Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET In article <1993Mar24.152357.2614@vixvax.mgi.com>, lokhorst@vixvax.mgi.com writes: > > >Hello, > > I have a question about the -Request service provided by the MLF. >In older versions -Request used to handle single commands. With the newer >versions of MX (>= 3.0) MLF started answering multiple commands. At our >site many people have a signature file automatically included into their >mail messages. Therefore, when they send a message to a list's -Request >address they get the expected response as well as a message from the >PostMaster complaining that it can't interpret their .sig lines. > > Is their any way around this short of telling people "don't do that"? If MX is doing the auto signature, tell the people to put /NOSIG as the last line of the message. This also helps when sending mail to listservs, etc. The effect of this is that the sig file is not included in message, neither is the /nosig line. Dr. David L. Matthews, IPST, Univ. of Maryland, College Park MD 20742-2431 Telephone (301)405-4830 Internet dmatthews@uap.umd.edu FAX (301)314-9363 NSI/SPAN UMDUAP::DMATTHEWS ================================================================================ Archive-Date: Thu, 25 Mar 1993 19:05:19 CST Sender: list-mgr@WKUVX1.BITNET Subject: Re: MLF -Request function and .sig files Message-ID: <0096A081.AA225340@buckie.HSC.Colorado.EDU> From: Date: 25 Mar 1993 17:38:16 GMT Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET In article <1993Mar24.152357.2614@vixvax.mgi.com>, lokhorst@vixvax.mgi.com writes: > I have a question about the -Request service provided by the MLF. >In older versions -Request used to handle single commands. With the newer >versions of MX (>= 3.0) MLF started answering multiple commands. At our >site many people have a signature file automatically included into their >mail messages. Therefore, when they send a message to a list's -Request >address they get the expected response as well as a message from the >PostMaster complaining that it can't interpret their .sig lines. I think Eric's LISTSERV has the same behavour as MX's in this regard. Eric? What sortof change could be done? You need MX's MLF to tell the user when MLF encountered a command it couldn't parse -- MLF can't tell if it was an intended command or if it was the person's signature. Some people put "-- " above their signature, and MX could maybe look for that, but many people don't do this.... Besides, then you'd have to tell your users how to construct a "legal" signature. I think "If it hurts, don't do that" might be your best solution... -d -Dan Wing, Systems Administrator, University Hospital, Denver dwing@uh01.colorado.edu or wing_d@ucolmcc.bitnet ================================================================================ Archive-Date: Thu, 25 Mar 1993 19:54:00 CST Sender: list-mgr@WKUVX1.BITNET Date: Thu, 25 Mar 1993 17:48:26 -0800 (PST) From: Phil Rand Reply-To: MX-List@WKUVX1.BITNET Subject: Re: MLF -Request function and .sig files To: MX discussion Message-ID: Doesn't anybody read their manuals? MX v3.2 has the QUIT command, for just this situation! I've used it; it works. Tell your people to put a "quit" command as their last MLF command. Oh... I just looked in the manual, and couldn't find it again. Maybe it was only documented in the release notes? It's in there somewhere, or I wouldn't have noticed. By the way, thanks, Hunter. --Phil // Phil Rand prand@paul.spu.edu // Computer & Information Systems (206) 281-2428 // Seattle Pacific University, 3307 3rd Ave W, Seattle, WA 98119 ================================================================================ Archive-Date: Thu, 25 Mar 1993 21:54:51 CST Sender: list-mgr@WKUVX1.BITNET Subject: Re: MLF -Request function and .sig files Message-ID: <1993Mar25.201504.16016@news.weeg.uiowa.edu> From: meadows@cslvax.weeg.uiowa.edu Date: Thu, 25 Mar 1993 20:15:04 GMT Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET In article <1993Mar25.183515.8875@news.arc.nasa.gov>, madison@tgv.com (Matt Madison) writes: >In article <1993Mar24.152357.2614@vixvax.mgi.com>, lokhorst@vixvax.mgi.com writes: >> I have a question about the -Request service provided by the MLF. >>In older versions -Request used to handle single commands. With the newer >>versions of MX (>= 3.0) MLF started answering multiple commands. At our >>site many people have a signature file automatically included into their >>mail messages. Therefore, when they send a message to a list's -Request >>address they get the expected response as well as a message from the >>PostMaster complaining that it can't interpret their .sig lines. >> >> Is their any way around this short of telling people "don't do that"? > >Maybe Hunter could add an "END" command, or something along those lines, which >will tell MLF to stop processing any more of the message. Of course, you'd >then have to get people to use the new command. > I'd like to see a "QUIT" command like the file server now has (in 3.2), but until then, I've been using /nosig at the end of my mail to the -Request server. -Howard *************************************************************************** * Howard Meadows Sr. Systems Programmer Weeg Computing Center * * University Of Iowa Iowa City, Iowa 52242 Phone: 319-335-5519 * * email: howard-meadows@uiowa.edu * *************************************************************************** ================================================================================ Archive-Date: Thu, 25 Mar 1993 21:55:21 CST Sender: list-mgr@WKUVX1.BITNET From: Reply-To: MX-List@WKUVX1.BITNET Subject: Re: Rewriting, Decus UUCP, MX and ALL-In-1 Message-ID: <1993Mar25.153245.6147@gandalf.ca> Date: Thu, 25 Mar 1993 15:32:45 GMT To: MX-List@WKUVX1.BITNET In <1993Mar24.140619.684@hhcs.gov.au> Carl Makin writes: >> The problem that I have is that the headers on the Ultrix system from >> the All-In-One mail looks like: >> hanv02::hanv02::mrgate::"a1::user" I've been there... and fixed it. (Keep reading!) >> However, the problem that I have is that I can't seem to grab/rewrite >> the headers on the mail from the All-IN-1 to the Internet. As a result, >> the headers on the Internet host look like: >> "a1::user"%mrgate.dnet%hanv02.dnet.IP-Domain" Again, this is in the same vein... We can fix it, we have the technology! >This is the exact problem I'm also trying to solve, only I have a >further problem. Our All-In-1 usernames have a space in them so the >VMS mail address comes out like; >cbr::mrgate::"a1::lastname firstname" > ^ note the space. :-( Hmm, not sure on this one... >The best bet so far looks like using the host and domain rewriting >exits supported under MX 3.1c. (Thanks Mathew) Yes, the tools are available within the MX savesets with MX 3.1c and I guess with MX 3.2 also. What is needed is the NAME-CONVERSION routine provided in the MX_ROOT:[EXAMPLES] directory. (take the Bliss-32 and Macro version, not the C one). Read the 00README.NAME_CONVERSION file there. Matt Madison provided me with an enhanced version of this to allow for DECNET ALL-IN-1 nodes to also be able to send to the local ALL-IN-1 node that has the Internet access (ie. mx"internet_address"@MRGATE@MX_VAX). Also, the rewrite rules for inbound mail must be modified. Below I have included my re-write rules, which show entries to direct to my remote ALL-IN-1 VAX systems (VAX2 and VAX3). As you can see, ALL-IN-1 addresses go out to Internet world as username%A1.mrgate@local.internet.address. If the user is on a remote ALL-IN-1 system, his return address would be: username%A1.VAX2.mrgate@local.internet.address. This is all working fine for me. In ALL-IN-1, simply use MX%"user@internet"@MRGATE to send thr mail out. Here are my rewrite rules (I mailed them from my ALL-IN-1 account to this Sun Unix account): From DHUDDLESON%A1.mrgate@krypton.gandalf.ca Thu Mar 25 09:49:42 1993 Return-Path: Date: Thu, 25 Mar 1993 09:47:38 EST From: DHUDDLESON%A1.mrgate@krypton.gandalf.ca To: dhuddles@gandalf.ca X-Vmsmail-To: MX%"dhuddles@gandalf.ca" Subject: MCP rewrite rules for ALL-IN-1 From: NAME: David Huddleson FUNC: 10825 Systems & Communications TEL: 613-723-6500 #8807 To: MX%"dhuddles@gandalf.ca"@MRGATE Address-rewriting rules: Rewrite "<{user}@A1>" => "<""MRGATE::{user}""@krypton.gandalf.ca>" Rewrite "<{user}@VAX2>" => "<""VAX2::{user}""@krypton.gandalf.ca>" Rewrite "<{user}@VAX3>" => "<""VAX2::{user}""@krypton.gandalf.ca>" Rewrite "<{user}@{node}.dnet>" => "<""{node}::{user}""@vax1.gandalf.ca>" Rewrite "<{user}@{node}.{gw}.mrgate>" => "<""MRGATE::\""{gw}::{node}::{user}\""""@vax1.gandalf.ca>" Rewrite "<{user}@{node}.mrgate>" => "<""MRGATE::\""{node}::{user}\""""@vax1.gandalf.ca>" Rule #1 is a "short-cut", and assumes that I have ALL my ALL-IN-1 users defined within Message Router (MRMAN re-write rules). Rules #2 and #3 are used for VMS Mail routing. Rule #4 catches VMSMail also. Rule #5 and #6 are what happens for Remote and then local ALL-IN-1 inbound mail (from and Internet "REPLY" to ALL-IN-1 message). Hope this helps, David -- dhuddles@gandalf.ca David J. Huddleson Gandalf Data Ltd., Nepean, Ontario (613) 723-6500 Days (613) 822-1315 Otherwise ================================================================================ Archive-Date: Thu, 25 Mar 1993 22:46:09 CST Sender: list-mgr@WKUVX1.BITNET Subject: Re: MLF -Request function and .sig files Message-ID: <1993Mar25.231003.1@sejnet.sunet.se> From: Date: 25 Mar 93 23:10:03 GMT Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET In article <0096A081.AA225340@buckie.HSC.Colorado.EDU>, dwing@uh01.colorado.edu (Dan Wing) writes: > I think Eric's LISTSERV has the same behavour as MX's in this regard. Eric? Mail to 'listname-request' is an ageless Internet convention for reaching the *list administrator*. For a long time LISTSERV didn't support it, because LISTSERV isn't implemented as a component of the VM mail system but as a sort of end user with write access to the mailboxes of a number of lists. LISTSERV couldn't support these mailboxes unless the mail system were nice enough to pass them on, which it didn't, or unless the system administrator were to set up a mail forwarding entry (on VM, mail is a third-party layered product and there is no such thing as a standardized SET FORWARD command LISTSERV could issue itself - with the mailer we had at that time it was all in configuration files). So, the situation was that a handful of sites had set up these mailboxes but most hadn't, and you could say that LISTSERV didn't support listname-request at all. That's when the many 'listserv for eunuchs' started appearing. Seen from their perspective, listname-request, being the way to contact the human running the list for questions, was the place where all the 'pls add me to the info-bozo list' messages were sent. The first embryonic list managers were probably no more than a couple dozen lines of typical unix expectoration whose job was to pre-process the listname-request mailbox and add or delete people whose message seemed to look like a request to be added or deleted. Naturally, when they automated this process this is the mailbox they chose to be the recipient of subscription requests. This left them without any standard way for users to ask questions of the list administrator, but they hardly saw that as a drawback :-) I don't know if this budding convention was the reason Matt chose to use the listname-request mailbox as well, and I'm not saying it was. I just wanted to give you the background. Support for listname-request in LISTSERV has been available since Dec 91, with a patch to XMAILER R2.08, and it is a standard feature of XMAILER R2.10 and all versions of LMail. 50% of the servers run R2.10 or LMail, and I have no idea how many of the R2.08 sites have the patch. At any rate, LISTSERV never attempts to execute commands sent to this address: they are always passed to the list owner. Originally there wasn't any confusion at all: the users were happy to have a standard address to write to all the list owners at once, and they continued to send commands to the LISTSERV address as before. Sadly, with the advent of "eunuchs' listserv" (now renamed to "eunuchs' listserver" in order to be able to tell me that something has been done to ensure the users will never again confuse the two), users are starting to expect commands to the listname-request address to work. I have no plans to make them work, because I want to keep a compact and standard way of contacting the list owner. And I have no doubt that if I design a new convention, such as listname-admin, the eunuchs will be quick to adapt to the growing amount of unwanted messages and will alias it to listname-request, and even document it. At which time I'll have to make a listname-honcho, and so on. I don't think MX contributed to the confusion because VMS BITNET users tend to know about LISTSERV, and because MX was not developed by a brick-wall who thought it would be his constitutional right and duty to call it "VMS LISTSERV", and to have the following text in his helpfile: >This version is a bitnet-flavored UNIX implementation (not a port of the >original LISTSERV), written (and still developed) by Tasos Kotsikonas and >a group of current users. (apparently, in the eunuchs' closed little universe it is ok and even normal for implementations not to be compatible; an implementation that is actually compatible with what it claims to implement appears to be called a "port") Anyway, when commands are sent to the LISTSERV address and the syntax is incorrect, LISTSERV generates an error message and stops immediately (up to 1.7e) or after 10 commands (1.7f). The change was made to relieve me of a crowd of executive-type Mac users who are trying computers for the first time in their life and whose mail system generates a nice letterhead-looking banner in the local language, which cannot even be removed when editing the message or by clicking on any of the little icons (this according to the local Mac experts, I disclaim any responsibility). To prevent junk lines from generating junk messages and possibly flushing the remainder of your request, you can bracket your commands this way: M E D D E L A N D E Tid: blah blah blah Datum: zzzzzzzzzzzZZZZZZZZZZZZZZZZ [mne: // job subscribe xyz-l // eoj Both delimiters are optional. It was when trying to teach the Mac users to start with '// job' that I realized this was hopeless. On a VTxxx this looks like slash, slash, blank, job. On a Mac this looks like slash, blank, slashjob *sigh* Fine, so you spell it out: // job (slash, slash, blank, job) and people write either: / /job (slash, slash, blank, job) subscribe xyz-l or: slash, slash, blank, job subscribe xyz-l That's when you realize you can't fight them - it's a lost cause :-) Eric ================================================================================ Archive-Date: Fri, 26 Mar 1993 12:08:09 CST Sender: list-mgr@WKUVX1.BITNET Date: Fri, 26 Mar 1993 12:07:54 CST From: Hunter Goatley Reply-To: MX-List@WKUVX1.BITNET To: mx-list@WKUVX1.BITNET Message-ID: <0096A157.BEF125E0.16303@WKUVX1.BITNET> Subject: MX V3.3 ready for field test on AXP!!! MX V3.3 is ready for field testing under OpenVMS VAX *and* OpenVMS AXP. I've had MX running for more than two weeks on two different AXP systems. I'm looking for sites with AXP machines who are willing to test MX. If you're willing and able, please contact me privately at the address below and I'll tell you what's involved. Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@WKUVX1.BITNET (or goathunter%wkuvx1.bitnet@UKCC.UKY.EDU) ================================================================================ Archive-Date: Sat, 27 Mar 1993 19:26:28 CST Sender: list-mgr@WKUVX1.BITNET From: scott@ais.com Reply-To: MX-List@WKUVX1.BITNET Subject: Help on MX Installation? Message-ID: <1993Mar27.145654.6086@ais.com> Date: 27 Mar 93 14:56:54 GMT To: MX-List@WKUVX1.BITNET Could someone please point me in the right direction. I am trying to configure MX3.2 on a MicroVaxII with CMUTEK6.6. I configured it the was that I interpreted the installation manual, however no mail is being sent locally with MX or by way of MX-SMTP. I looked in the queue directory and found my undelivered messages that said something about not being able to find a route to the machines. I have the configuration route stuff set like: define path aisvax LOCAL define path aisvax.ais.com LOCAL define * SMTP If anyone can think of something that I should have done. I would really appricate some info. BTW: I do have all of the MX processes running like: SMTP server MX local, etc. Thanks in advance. --Scott Gregory scott@ais.com ================================================================================ Archive-Date: Sun, 28 Mar 1993 10:54:33 CST Sender: list-mgr@WKUVX1.BITNET Date: 28 Mar 1993 11:46:14 -0500 (EST) From: "Jonathan E. Hardis" Reply-To: MX-List@WKUVX1.BITNET Subject: RE: Help on MX Installation? To: MX-List@WKUVX1.BITNET CC: scott@ais.com, hardis@garnet.nist.gov Message-ID: <0096A2E7.0D086F00.11334@garnet.nist.gov> > Could someone please point me in the right direction. I am trying to > configure MX3.2 on a MicroVaxII with CMUTEK6.6. I configured it the > was that I interpreted the installation manual, however no mail is > being sent locally with MX or by way of MX-SMTP. I just went through hell on a similar set of symptoms, though I don't remember being told that no route could be found. In my case, the messages just sat in the queue "IN PROGRESS", because the MX_SMTP process had always died unceremoniously as soon as it was started. (To verify that this is part of your problem, type $ MCP STATUS. You should see both MX_SMTP and MX_SMTP_SERVER if all is well.) The root cause was my stupidity. In the INTERNET.CONFIG template, notice that in the line: $! Define/System/Exec/NoLog INTERNET_HOST_NAME "host.your.domain" you not only have to edit the right of the line, you also have to remove the "!" at the left of the line. (Similarly, the CMUTEK_ROOT and CMUTEK_SRC logicals must be uncommented, though this I had found, earlier.) Henry Miller, please take note: a comment line instruction on removing the "!" in these lines may save others similar grief. - Jonathan ================================================================================ Archive-Date: Mon, 29 Mar 1993 13:39:09 CST Sender: list-mgr@WKUVX1.BITNET Subject: File server woes Message-ID: <1993Mar29.120824.387@kenyon.edu> From: oursler@kenyon.edu Reply-To: MX-List@WKUVX1.BITNET Date: 29 Mar 93 12:08:24 -0500 To: MX-List@WKUVX1.BITNET Hullo, I am having some trouble setting up a fileserver. Here are the specifics: I am using MX 3.2. I have a list defined as follows: Mailing lists: Name: chinese Owner: "bai@KENYON.EDU" Reply-to: NOList, Sender Archive: MX_ROOT:[MLF.ARCHIVES.CHINESE] Add message: MX_MLIST_DIR:CHINESE_ADD_MESSAGE.TXT Description: This list is established to promote communication among teachers, researchers and students of the Chinese language Errors-to: bai@KENYON.EDU Strip header: NOReceived Protection: (SYSTEM:RWED,OWNER:RWED,GROUP:RWED,WORLD:E) I "HAD" a file server defined as follows: File servers: Name: chinese-archives, Manager: <> Description: Archives for mailing list chinese@kenyon.edu Root: MX_ROOT:[MLF.ARCHIVES.CHINESE.] Linked to mailing list: CHINESE Delay threshold: 0 Send period: 17:00 - 09:00 Daily limits: Server: 0 Host: 0 User: 0 I have defined this file server three times now. When I attempt to access it, I received the following error: From: MX%"Postmaster@kenyon.edu" 29-MAR-1993 11:56:21.04 To: OURSLER CC: Subj: LOCAL delivery error Return-Path: <> Date: Mon, 29 Mar 1993 11:55:33 EST From: Local delivery agent To: Subject: LOCAL delivery error X-Report-Type: Nondelivery; boundary="> Error description:" Note: this message was generated automatically. An error was detected while processing the enclosed message. A list of the affected recipients follows. This list is in a special format that allows software like LISTSERV to automatically take action on incorrect addresses; you can safely ignore the numeric codes. --> Error description: Error-For: chinese-archives@kenyon.edu Error-Code: 2 Error-Text: Error in auto-forward from username CHINESE-ARCHIVES to: forwarding loop detected Error-End: 1 error detected ------------------------------ Rejected message ------------------------------ Resent-Date: Mon, 29 Mar 1993 11:55:20 EST Resent-From: Resent-To: Received: by kenyon.edu (MX V3.2) id 23330; Mon, 29 Mar 1993 11:55:41 EST Date: Mon, 29 Mar 1993 11:54:33 EST From: Miles To: chinese-archives@kenyon.edu Message-ID: <0096A3B1.60EBBF80.23330@kenyon.edu> HELP When I check MCP again, I no longer have a file server defined. Doubtless, I messed up somewhere, but I'd appreciate it if someone could explain the specifics. - Miles - ------------------------------- Miles Oursler Manager of Networks and Systems Kenyon College oursler@kenyon.edu ------------------------------- ================================================================================ Archive-Date: Mon, 29 Mar 1993 14:03:57 CST Sender: list-mgr@WKUVX1.BITNET Date: Mon, 29 Mar 1993 14:03:34 CST From: Hunter Goatley Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET CC: oursler@kenyon.edu Message-ID: <0096A3C3.66EA9C00.17318@WKUVX1.BITNET> Subject: RE: File server woes oursler@kenyon.edu writes: > >Hullo, > > I am having some trouble setting up a fileserver. Here are > the specifics: > > I am using MX 3.2. > I have a list defined as follows: > [...] >--> Error description: >Error-For: chinese-archives@kenyon.edu >Error-Code: 2 >Error-Text: Error in auto-forward from username CHINESE-ARCHIVES to: > > forwarding loop detected Do you have a VMS Mail forwarding address set for CHINESE-ARCHIVES? Try: MAIL> SHOW FORWARD/USE=CHINESE-ARCHIVES If so, use SET NOFORWARD to cancel it. Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@WKUVX1.BITNET (or goathunter%wkuvx1.bitnet@UKCC.UKY.EDU) ================================================================================ Archive-Date: Mon, 29 Mar 1993 16:13:07 CST Sender: list-mgr@WKUVX1.BITNET Date: Mon, 29 Mar 1993 14:07:15 PST From: Virtual Bill Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <0096A3C3.EA553000.30802@gtewd> Subject: UNZIP Problem I have tried unsuccessfully to UNZIP both the XSHARE.ZIP and FTS.ZIP files but I keep getting the same error: Error: zipfile is in variable-length record format. Please run "bilf l xshare.zip" to convert the zipfile to stream-LF record format. (Bilf.exe, bilf.c and make_bilf.com are included in the VMS UnZip source distribution.) The last time I tried it with a new copy of the UNZIP.EXE that I obtained from Hunter's [MACRO32] directory. I also searched through the whole ANONYMOUS tree on Hunter's system for the cited files in the error above but could not find them. Can anyone tell me where I can obtain the three files, Bilf.exe, bilf.c and make_bilf.com? ------------------------------------------------------------------------------- Bill Powers GTE Government Systems (415) 966-2757 internet: powers@gtewd.mtv.gsc.gte.com fax: (415) 966-3401 ================================================================================ Archive-Date: Mon, 29 Mar 1993 16:17:20 CST Sender: list-mgr@WKUVX1.BITNET Date: Mon, 29 Mar 1993 16:16:48 CST From: Hunter Goatley Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET CC: powers@gtewd.mtv.gsc.gte.com Message-ID: <0096A3D6.03AD0D40.17366@WKUVX1.BITNET> Subject: RE: UNZIP Problem Virtual Bill writes: > > I have tried unsuccessfully to UNZIP both the XSHARE.ZIP and FTS.ZIP > files but I keep getting the same error: > > > Error: zipfile is in variable-length record format. Please > run "bilf l xshare.zip" to convert the zipfile to stream-LF > record format. (Bilf.exe, bilf.c and make_bilf.com are included > in the VMS UnZip source distribution.) > This is undoubtedly a result of not ftp'ing the .ZIP files as IMAGE files. If you're running MultiNet, you can use STRU VMS with ftp.spc.edu. Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@WKUVX1.BITNET (or goathunter%wkuvx1.bitnet@UKCC.UKY.EDU) ================================================================================ Archive-Date: Mon, 29 Mar 1993 16:49:33 CST Sender: list-mgr@WKUVX1.BITNET Date: Mon, 29 Mar 1993 14:21:56 PST From: Virtual Bill Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <0096A3C5.F7DC67A0.30816@gtewd> Subject: RE: UNZIP Problem Sorry folks my initial request has the wrong internet address. This e-mail has the correct internet address. ------------------------------------------------------------------------------- Bill Powers GTE Government Systems (415) 966-2757 internet: powers@gtewd.mtv.gtegsc.com fax: (415) 966-3401 ================================================================================ Archive-Date: Mon, 29 Mar 1993 19:07:12 CST Sender: list-mgr@WKUVX1.BITNET Date: Mon, 29 Mar 1993 17:03:00 PST From: Virtual Bill Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <0096A3DC.77AA9900.31005@gtewd> Subject: RE: UNZIP Problem My UNZIP problem has been solved. I want to thank the various people for there assistance, especially Hunter, George Greenwade and Bob Marshall. Thanks much for the quick response. ================================================================================ Archive-Date: Mon, 29 Mar 1993 19:07:57 CST Sender: list-mgr@WKUVX1.BITNET Date: Mon, 29 Mar 1993 16:52:19 CST From: "George D. Greenwade" Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET CC: powers@gtewd.mtv.gtegsc.com Message-ID: <0096A3DA.F9A904C0.21788@SHSU.edu> Subject: RE: UNZIP Problem On Mon, 29 Mar 1993 14:07:15 PST, Virtual Bill posted: > I have tried unsuccessfully to UNZIP both the XSHARE.ZIP and FTS.ZIP files > but I keep getting the same error: > > > Error: zipfile is in variable-length record format. Please > run "bilf l xshare.zip" to convert the zipfile to stream-LF > record format. (Bilf.exe, bilf.c and make_bilf.com are included > in the VMS UnZip source distribution.) > > The last time I tried it with a new copy of the UNZIP.EXE that I obtained > from Hunter's [MACRO32] directory. I also searched through the whole > ANONYMOUS tree on Hunter's system for the cited files in the error above > but could not find them. Can anyone tell me where I can obtain the three > files, Bilf.exe, bilf.c and make_bilf.com? Hmmmmm. Should be in the UNZIP distribution, but I can't say for sure since Hunter's distributions are wholly ZIPped now. If you have access to ftp, come to Niord.SHSU.edu (192.92.115.8) and look in the directory [FILESERV.UNZIP.UNZIP50P1.VMS.BILF], where I retain an exploded version of the distribution. Everything associated with BILF is here. If you only have e-mail access, include: SENDME UNZIP_VMS.*BILF* in the body of a mail message to FILESERV@SHSU.BITNET (FILESERV@SHSU.edu) and the sources required (as individual files), as well as a UUENCODEd executable will be mailed to you. Regards, George %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% George D. Greenwade, Ph.D. Bitnet: BED_GDG@SHSU Department of Economics and Business Analysis THEnet: SHSU::BED_GDG College of Business Administration Voice: (409) 294-1266 P. O. Box 2118 FAX: (409) 294-3612 Sam Houston State University Internet: bed_gdg@SHSU.edu Huntsville, TX 77341 bed_gdg%SHSU.decnet@relay.the.net %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% ================================================================================ Archive-Date: Tue, 30 Mar 1993 03:16:54 CST Sender: list-mgr@WKUVX1.BITNET Date: 30 Mar 93 10:58:57+0200 From: Fabien Marathee Reply-To: MX-List@WKUVX1.BITNET Message-ID: <9303300858.AA26454(a)eliot.cnes.fr> To: MX-List@WKUVX1.BITNET Subject: Rewriting From: field Hello everybody (it's my first message on the list...), MX is working really fine on Multinet, still I have some address rewriting problem (most important for me); Is there some kind of way I could redefine the 'From:' output format when sending a message through MX to a SMTP host. That is to say convert this from : vmsnode::user@mymxhost.mydomain ^^^^^^^^^^^^^^^^^^^^^^ to that from : user@vmsnode.span.mydomain ^^^^^^^^^^^^^^^^^ (mcp rewriting rules can convert back this last syntax easily ...) I've had my share of sendmail hacking and I would like MX to do the job ... Thank you, ======================================== Fabien Marathee (marathee@eliot.cnes.fr) Centre Spatial de Toulouse France ======================================== ================================================================================ Archive-Date: Tue, 30 Mar 1993 03:28:16 CST Sender: list-mgr@WKUVX1.BITNET Date: 30 Mar 93 11:18:21+0200 From: Fabien Marathee Reply-To: MX-List@WKUVX1.BITNET Message-ID: <9303300918.AA26528(a)eliot.cnes.fr> To: MX-list@WKUVX1.BITNET REVIEW ================================================================================ Archive-Date: Tue, 30 Mar 1993 05:51:44 CST Sender: list-mgr@WKUVX1.BITNET Date: Tue, 30 Mar 1993 05:51:23 CST From: Hunter Goatley Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <0096A447.CF5CD800.17473@WKUVX1.BITNET> Subject: RE: Rewriting From: field Fabien Marathee writes: > > Hello everybody (it's my first message on the list...), > > MX is working really fine on Multinet, still I have some address > rewriting problem (most important for me); > > Is there some kind of way I could redefine the 'From:' output format > when sending a message through MX to a SMTP host. That is to say convert > this from : > > vmsnode::user@mymxhost.mydomain > ^^^^^^^^^^^^^^^^^^^^^^ > > to that from : > > user@vmsnode.span.mydomain > ^^^^^^^^^^^^^^^^^ > Assuming you installed the CONTRIB files when you installed MX, take a look at the files in MX_ROOT:[CONTRIB]DECNET_NAME_CONVERSION.VMS_SHARE. That does almost exactly what you to do. The _Message Exchange Programmer's Guide_ documents a name conversion program. Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@WKUVX1.BITNET (or goathunter%wkuvx1.bitnet@UKCC.UKY.EDU) ================================================================================ Archive-Date: Tue, 30 Mar 1993 08:58:54 CST Sender: list-mgr@WKUVX1.BITNET Date: Tue, 30 Mar 1993 08:57:49 CST From: Hunter Goatley Reply-To: MX-List@WKUVX1.BITNET To: mx-list@WKUVX1.BITNET Message-ID: <0096A461.DA8C2900.17560@WKUVX1.BITNET> Subject: New: MX-List-Digest If you'd prefer to receive MX-List posts as a daily (depending on posts) digest instead of individual mail messages, you can now subscribe to MX-List-Digest here at WKUVX1.BITNET. MX-List-Digest will be mailed out daily at 5PM CT, assuming there are posts to MX-List. To subscribe, send the following command in the body of a mail message to LISTSERV@WKUVX1.BITNET: SUBSCRIBE MX-List-Digest "Your real name here" To remove yourself from the non-digest MX-List, add the following line to the same message: SIGNOFF MX-List Naturally, the digesting (!) is performed by the MX-DIGEST software included in MX_ROOT:[CONTRIB]. Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@WKUVX1.BITNET (or goathunter%wkuvx1.bitnet@UKCC.UKY.EDU) ================================================================================ Archive-Date: Tue, 30 Mar 1993 10:38:36 CST Sender: list-mgr@WKUVX1.BITNET Date: 30 Mar 1993 11:33:50 -0400 (AST) From: Greg Bishop Subject: help needed with DECnet-SMTP To: MX-LIST@WKUVX1.BITNET Reply-To: MX-List@WKUVX1.BITNET Message-ID: <0096A477.A6713960.25696@ac.nsac.ns.ca> I'm having problems getting DECnet-SMTP to work on my system. I've been using MX 3.1C & Multinet for awhile with no problems, but have never been able to get DECnet-SMTP to work. I want to have Gus, who is not running TCP/IP, send and receive mail from AC using DECnet. I setup mailer and server accounts (Mailer & DNSMTP_SRV) on both Gus and AC. I decided to use proxies as recommended. The proxy I used on AC was ADD/PROXY gus::mailer dnsmtp_srv/def and the proxy on Gus was ADD/PROXY ac::mailer dnsmtp_srv/def One of the MX_DNSMTP_LOG.LOG files on AC. 29-MAR-1993 15:33:10.39 Processing queue entry number 25430 on node AC 29-MAR-1993 15:33:10.67 Recipient: , route=gus.nsac.ns.ca 29-MAR-1993 15:33:10.68 SMTP_SEND: connecting to gus::"DECSMTP=" 29-MAR-1993 15:33:11.21 SMTP send failed, sts=0C27804A, sts2=0000209C 29-MAR-1993 15:33:11.21 Recipient status=0C27804A for 29-MAR-1993 15:33:11.71 1 rcpts need retry, next try 29-MAR-1993 16:03:11.71 29-MAR-1993 15:33:11.75 *** End of processing pass *** One of the error messages that I received back on Gus: From: MX%"Postmaster@gus.nsac.ns.ca" 30-MAR-1993 02:52:16.77 To: GB CC: Subj: DECnet/SMTP delivery error Return-Path: <> Date: Tue, 30 Mar 1993 02:52:12 EST From: DECNET_SMTP delivery agent To: Subject: DECnet/SMTP delivery error Note: this message was generated automatically. A problem occurred during DECnet/SMTP delivery of your message. Error occurred sending to the following user(s): (via AC.NSAC.NS.CA): %MX-F-RETRYEXCD, retry count exceeded -SYSTEM-F-INVLOGIN, login information invalid at remote node ======================================================================== Message follows. Received: by gus.nsac.ns.ca (MX V3.1C) id 13; Mon, 29 Mar 1993 14:46:57 EST Sender: gb@gus.nsac.ns.ca Date: Mon, 29 Mar 1993 14:46:56 EST From: gb@gus.nsac.ns.ca Reply-To: gb@gus.nsac.ns.ca To: gbishop@ac.nsac.ns.ca Message-ID: <0096A3C9.75FA72A0.13@gus.nsac.ns.ca> Subject: new test another test CAN ANYONE SUGGEST WHAT I'M DOING WRONG. THANKS IN ADVANCE. Greg Bishop Internet: GBISHOP@AC.NSAC.NS.CA System Manager Voice: (902) 893-6693 Nova Scotia Agricultural College Fax: (902) 895-4547 Truro, Nova Scotia CANADA B2N 5E3 ================================================================================ Archive-Date: Tue, 30 Mar 1993 11:53:22 CST Sender: list-mgr@WKUVX1.BITNET Date: Tue, 30 Mar 1993 09:44:55 PST From: "Bob Johns, (604)363-6520" Reply-To: MX-List@WKUVX1.BITNET To: MX-List%wkuvx1.BITNET@cunyvm.cuny.edu Message-ID: <0096A468.70124D00.8888@ccs.ios.bc.ca> Subject: MIME support within MX? Is it time to re-visit the "MIME support within MX" debate? The March 15th issue of "Open Systems Today" discusses the current state-of-the-art in an article titled "E-mail standard products appear", on page 26. I recall some discussion of MIME quite a while ago on this list, but I think Hunter implied at that time he didn't see any demand for it. This present article seems to suggest MIME is gaining ground, and perhaps it should be reconsidered for inclusion within MX. Something more for the wishlist...? Bob Johns (bob@ios.bc.ca) Manager, Central Systems & Networks Scientific Computing Institute of Ocean Sciences Sidney, B.C. Canada ================================================================================ Archive-Date: Tue, 30 Mar 1993 15:05:39 CST Sender: list-mgr@WKUVX1.BITNET From: Subject: Re: help needed with DECnet-SMTP Date: 30 Mar 1993 20:06:01 GMT Message-ID: <0096A484.1DD16960@buckie.HSC.Colorado.EDU> Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET In article <0096A477.A6713960.25696@ac.nsac.ns.ca>, Greg Bishop writes: >I'm having problems getting DECnet-SMTP to work on my system. I've been >using MX 3.1C & Multinet for awhile with no problems, but have never been >able to get DECnet-SMTP to work. > >I want to have Gus, who is not running TCP/IP, send and receive mail >from AC using DECnet. > >I setup mailer and server accounts (Mailer & DNSMTP_SRV) on both Gus and AC. >I decided to use proxies as recommended. The proxy I used on AC was > > ADD/PROXY gus::mailer dnsmtp_srv/def > >and the proxy on Gus was > > ADD/PROXY ac::mailer dnsmtp_srv/def > >One of the MX_DNSMTP_LOG.LOG files on AC. > >29-MAR-1993 15:33:10.39 Processing queue entry number 25430 on node AC >29-MAR-1993 15:33:10.67 Recipient: , route=gus.nsac.ns.ca >29-MAR-1993 15:33:10.68 SMTP_SEND: connecting to gus::"DECSMTP=" >29-MAR-1993 15:33:11.21 SMTP send failed, sts=0C27804A, sts2=0000209C >29-MAR-1993 15:33:11.21 Recipient status=0C27804A for >29-MAR-1993 15:33:11.71 1 rcpts need retry, next try 29-MAR-1993 16:03:11.71 >29-MAR-1993 15:33:11.75 *** End of processing pass *** On the remote node (GUS), enable an operator terminal for receiving security messages (REPLY/ENABLE=SECURITY), and make sure you are auditing login failures for NETWORK. Then get the local node (that is running TCP/IP) to send a message on SMTP-over-DECnet -- this will make it attempt a login at the remote node. You will get a login failure on GUS. The message in this login failure message will help you determine where the problem is located. Things that might be causing the problem: DNSMTP_SRV is DisUsered, has invalid login directory (can't create NETSERVER.LOG), doesn't have NETWORK access enabled, don't have NETMBX, no disk quotas, ... If you need additional assistance, please contact me - I've set this up before, although I didn't use proxies (they have a security risk which DECnet objects don't have. If you manage both machines, it doesn't really matter, but if you only manage one, you've opened yourself up a bit...) -d -Dan Wing, Systems Administrator, University Hospital, Denver dwing@uh01.colorado.edu or wing_d@ucolmcc.bitnet ================================================================================ Archive-Date: Tue, 30 Mar 1993 17:41:50 CST Sender: list-mgr@WKUVX1.BITNET From: Subject: Re: MIME support within MX? Message-ID: <1993Mar31.011000.1@sejnet.sunet.se> Reply-To: MX-List@WKUVX1.BITNET Date: Wed, 31 Mar 1993 01:10:00 GMT To: MX-List@WKUVX1.BITNET In article <0096A468.70124D00.8888@ccs.ios.bc.ca>, "Bob Johns, (604)363-6520" writes: > I recall some discussion of MIME quite a while ago on this list, but > I think Hunter implied at that time he didn't see any demand for it. > This present article seems to suggest MIME is gaining ground, and > perhaps it should be reconsidered for inclusion within MX. Concretely, what are you asking for? MIME is a bilateral agreement between user-interfaces. MX doesn't get into the picture except when it generates a delivery error, and even so I don't see the problem: the default options in MIME are, of course, set up so that text without MIME labels is treated as vanilla ASCII. Some mailers have code to insert MIME labels with all the default values on messages which were not in MIME format. I find this particularly irritating since it adds no information but increases the amount of rubbish headers. Eric ================================================================================ Archive-Date: Tue, 30 Mar 1993 21:05:58 CST Sender: list-mgr@WKUVX1.BITNET Date: 30 Mar 1993 22:56:56 -0400 (AST) From: Greg Bishop Subject: solution to DECnet-SMTP problem To: mx-list@WKUVX1.BITNET Reply-To: MX-List@WKUVX1.BITNET Message-ID: <0096A4D7.13CE27C0.25934@ac.nsac.ns.ca> In article <0096A477.A6713960@ac.nsac.ns.ca>, Greg Bishop stated a problem that Dan Wing replied to: After several messages, Dan put me on the right track and I now have DECnet-SMTP working here at my site. (I'm not sure if they all made it to the list, but I'll point out the solution now). Basically, after enabling some logging on the remote system, I was able to see that MAILER on GUS was trying to log into DECNET on AC, not DNSMTP as I had expected. So I went back into NCP, deleted the DNSMTP object and DEFINEd it again but with a USER MAILER at the end. I don't have the documentation here in front of me but it looked something like: NCP> defi obj dnsmtp num 254 prox incom file mx_exe:dnsmtp_srv.exe user mailer NCP> set obj dnsmtp all After doing that on both nodes, the messages starting flowing. Is this an error in the documentation (3.1C) or do I have a weird setup? Thanks to all those who replied. Greg Greg Bishop Internet: GBISHOP@AC.NSAC.NS.CA System Manager Voice: (902) 893-6693 Nova Scotia Agricultural College Fax: (902) 895-4547 Truro, Nova Scotia CANADA B2N 5E3 ================================================================================ Archive-Date: Wed, 31 Mar 1993 14:47:15 CST Sender: list-mgr@WKUVX1.BITNET Date: Wed, 31 Mar 1993 09:08:03 PST From: "Bob Johns, (604)363-6520" <"iosccs::bob"@ccs.ios.bc.ca> Reply-To: MX-List@WKUVX1.BITNET To: MX-List%wkuvx1.BITNET@cunyvm.cuny.edu Message-ID: <0096A52C.737B4180.9422@ccs.ios.bc.ca> Subject: Re: MIME support within MX? I may be displaying my ignorance of what MIME is, but what my users need is the capability to send various types of binary attachments to Internet mail messages. I had understood MIME was an evolving Internet standard that specifies how such attachments are encoded. Presumably the MIME standard says nothing about the user interface (sorry, I haven't read the RFC), but of course a protocol without a user interface is somewhat academic. Since we use VMSmail as the user interface to MX, and since VMSmail doesn't "officially" know anything about binary attachments (other than the "unsupported" send/foreign command), perhaps what I am looking for is really a new user interface that provides this functionality. However it needs to be implemented, the basic problem that needs to be solved is how to send binary attachments over SMTP. Simple ASCII (or ASCII-encoded binary) is no longer satisfactory, since users have come to expect this functionality from experience with other mail systems (e.g. DEC's Mailworks and Pathworks Mail, QuickMail, and even VMSmail's "unsupported" send/foreign command). Bob Johns (bob@ios.bc.ca) Manager, Central Systems & Networks Scientific Computing Institute of Ocean Sciences Sidney, B.C. Canada ================================================================================ Archive-Date: Wed, 31 Mar 1993 14:54:12 CST Sender: list-mgr@WKUVX1.BITNET Date: Wed, 31 Mar 1993 14:53:43 CST From: Hunter Goatley Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <0096A55C.BCE69240.18094@WKUVX1.BITNET> Subject: Re: MIME support within MX? "Bob Johns, (604)363-6520" <"iosccs::bob"@ccs.ios.bc.ca> writes: > >I may be displaying my ignorance of what MIME is, but what my users >need is the capability to send various types of binary attachments to >Internet mail messages. I had understood MIME was an evolving Internet >standard that specifies how such attachments are encoded. Presumably >the MIME standard says nothing about the user interface (sorry, I haven't >read the RFC), but of course a protocol without a user interface is >somewhat academic. > >Since we use VMSmail as the user interface to MX, and since VMSmail >doesn't "officially" know anything about binary attachments (other than >the "unsupported" send/foreign command), perhaps what I am looking for >is really a new user interface that provides this functionality. > For 98% (a figure I just made up to mean: to get the most out) of what MIME offers, a new user agent is needed. I looked at Pine---it sure would be nice if somebody ported that to VMS. I glanced at it, but I just don't have the time to try to do it. There are a lot of UNIXisms in it, so it looks like it would be tedious to port it (though not necessarily *that* hard). >However it needs to be implemented, the basic problem that needs to >be solved is how to send binary attachments over SMTP. Simple ASCII >(or ASCII-encoded binary) is no longer satisfactory, since users have >come to expect this functionality from experience with other mail >systems (e.g. DEC's Mailworks and Pathworks Mail, QuickMail, and even >VMSmail's "unsupported" send/foreign command). > I hesitate to mention this now, but.... 8-) I'm working on supporting at *least* the ability to use SEND/FOREIGN to send VMS files to other VMS sites (as MultiNet and PMDF do). That's about the only thing you can do with VMS Mail as the interface. To answer the question that started the thread, I'd like to mention again that the majority of the MIME stuff falls on the user interface and *not* the transport. However, I'll see what I can do. This *may* get in to MX v3.3. It depends on how my time goes the next few days. Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@WKUVX1.BITNET (or goathunter%wkuvx1.bitnet@UKCC.UKY.EDU)