1 INFO-VAX	Wed, 19 May 2004	Volume 2004 : Issue 276       Contents: Re: Copying tapes  Re: Copying tapes  Re: Copying tapes  Re: Copying tapes  Re: Copying tapes P Re: DCLER (DCL Enhancement Request) for DIRECTORY	 /SORT=[CREATED,MODIFIED,...]	 Re: DISMOUNT/POLICY=MINICOPY) Re: Eastern Washington University project % Re: I know I'm being picky but ...... E Loading sharable images with different file versions i.e. PRINT.EXE;* & Re: POSIX time functions and SYS$TZDIR+ Re: Printcap file with ip address and port? ! Re: Reboot forces Shadowset Merge ! Re: Reboot forces Shadowset Merge ! RE: Reboot forces Shadowset Merge ! Re: Reboot forces Shadowset Merge ! RE: Reboot forces Shadowset Merge ! Re: Reboot forces Shadowset Merge ! Re: Reboot forces Shadowset Merge ! RE: Reboot forces Shadowset Merge  Re: Request for new SMTP Re: Request for new SMTP Re: Request for new SMTP RE: Request for new SMTP Re: Request for new SMTP Re: Request for new SMTP RE: Request for new SMTP Re: Request for new SMTP Re: SSL in AST-driven programm? ! Re: SUN fails to advertise VMS... ! Re: SUN fails to advertise VMS... = Re: Switching from Process Software TCPware to TCPIP Services = Re: Switching from Process Software TCPware to TCPIP Services = Re: Switching from Process Software TCPware to TCPIP Services = Re: Switching from Process Software TCPware to TCPIP Services " Re: The next port for OpenVMS? ;-)" Re: The next port for OpenVMS? ;-)( Re: Timestamp format stored in RMS file?( Re: Timestamp format stored in RMS file?% [OT]:  Maybe SCO is (partially) right ) Re: [OT]:  Maybe SCO is (partially) right ) Re: [OT]:  Maybe SCO is (partially) right ) Re: [OT]:  Maybe SCO is (partially) right   F ----------------------------------------------------------------------  % Date: Tue, 18 May 2004 12:51:01 -0500 / From: Chris Scheers <chris@applied-synergy.com>  Subject: Re: Copying tapes3 Message-ID: <40AA4D05.E1537D8B@applied-synergy.com>    "David J. Dachtera" wrote: > J > Well, the only way to tell EOV is when COPY returns a zero record count.  	 Not true.   F On an ANSI labeled tape, you can legally have a zero record data file.  F A zero record count only means EOV when it occurs at a point where you are expecting a label file.   G ----------------------------------------------------------------------- $ Chris Scheers, Applied Synergy, Inc.  C Voice: 817-237-3360            Internet: chris@applied-synergy.com     Fax: 817-237-3074    ------------------------------  % Date: Tue, 18 May 2004 20:30:45 -0500 @ From: "David J. Dachtera" <djesys.nospam@NeOaSrPtAhMlNiOnWk.net> Subject: Re: Copying tapes5 Message-ID: <40AAB8C5.AD9D17A@NeOaSrPtAhMlNiOnWk.net>    Chris Scheers wrote: >  > "David J. Dachtera" wrote: > > L > > Well, the only way to tell EOV is when COPY returns a zero record count. >  > Not true.  > H > On an ANSI labeled tape, you can legally have a zero record data file.  D In that case, you would not be MOUNTing the tape /FOREIGN, more thanG likely. Remember: /FOREIGN means RMS is not intervening - label dataset $ processing is *YOUR* responsibility.  H > A zero record count only means EOV when it occurs at a point where you > are expecting a label file.   : ...except on a volume where label records are not present.  G True, EOV is signified by two successive tape marks with no intervening E dataset. The only way to detect that is if COPY from a volume MOUNTed C /FOREIGN returns a zero record count when you are expecting a label  dataset.  H So, in as much as your observation is correct, the answer "yes, and no".  ' MOUNTed Files-11: RMS traps it for you. D MOUNTed /FOREIGN: You must be sensitive to what you get vs. what you expect.   E In this case, zero records when header labels are expected means EOV.    So, my statement was correct.    --   David J. Dachtera  dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------  % Date: Tue, 18 May 2004 20:34:42 -0500 @ From: "David J. Dachtera" <djesys.nospam@NeOaSrPtAhMlNiOnWk.net> Subject: Re: Copying tapes6 Message-ID: <40AAB9B2.C325905B@NeOaSrPtAhMlNiOnWk.net>   Roy Omond wrote: >  > David J. Dachtera wrote: > > Denny Rich wrote:  > > G > >>I seem to remember (dimly) that in the olden days, with tu78/ta79s, C > >>connected through HSCs, it was possible to mount  a source tape D > >>Files11 (backup tape full of save sets), and a target tape  alsoG > >>Files11, and then "$ copy source:*.* target:"  (or was I doing this  > >>with HSC backup?)  > >>B > >>Anyway, the obvious would happen.  (IIRC...and thats a big if) > >>F > >>When I try this with a couple of backup tapes on TK89s, they won't > >>copy a single byte.  > >>F > >>Short of laying out each saveset and then putting it back onto theA > >>target tape, is there an easy way to duplicate a backup tape?  > >  > > < > > If you have the option, re-write your backup tapes using; > > /BLOCKSIZE=32256 to stay within RMS's 32767-byte limit.  > > F > > Then, you can MOUNT the source and target tapes /FOREIGN using theI > > appropriate /BLOCKSIZE parameter, and copy the datasets one at a time  > > for each saveset:  > >  > > 1. Header labels > > 2. Saveset data  > > 3. Trailer labels. > > L > > Use SET MAGTAPE/END after the last trailer labels after the last saveset/ > > to properly mark the logical end of volume.  >  > No, no, no !   Yes! Yes! Yes!  I > If your backups have been written to stay within the 32,767-byte limit,    There's the rub.  G > then you don't need to futz around with foreign tapes as above.  Your I > tape is an ANSI-standard labelled tape, so you can do as you originally  > did, namely: >  >         $ alloc MKx source >         $ alloc MKy target% >         $ mount/nowrite source xxxx % >         $ mount         target yyyy ' >         $ copy/log source:*.* target:   H ...except that conventional wisdom is to use the biggest /BLOCKSIZE thatF BACKUP supports (usually in reference to DLT) to minimize inter-record; gaps and maximize tape storage capacity. That's why I said:    > David J. Dachtera wrote:
 > > [snip]< > > If you have the option, re-write your backup tapes using; > > /BLOCKSIZE=32256 to stay within RMS's 32767-byte limit.    --   David J. Dachtera  dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------  % Date: Tue, 18 May 2004 20:38:01 -0500 @ From: "David J. Dachtera" <djesys.nospam@NeOaSrPtAhMlNiOnWk.net> Subject: Re: Copying tapes6 Message-ID: <40AABA78.CD42814F@NeOaSrPtAhMlNiOnWk.net>   Roy Omond wrote: > [snip]F > I have never seen BACKUP (or any other method in *base* VMS) recoverG > from parity errors on *any* helical-scan tape media (that's why these H > specialised data recovery companies can charge lots of money for these	 > cases).   / DLT is "Linear" (serpentine), not helical-scan.    --   David J. Dachtera  dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------  % Date: Wed, 19 May 2004 07:34:34 +0200 * From: Paul Sture <nospam@sture.homeip.net> Subject: Re: Copying tapes* Message-ID: <2h09vbF7jk3oU1@uni-berlin.de>   briggs@encompasserve.org wrote: Y > In article <2gu5joF6u1sdU1@uni-berlin.de>, Paul Sture <nospam@sture.homeip.net> writes:  > @ >>I've adopted a 32,556 blocksize as standard practice, as when  >  > L > 32256 surely.  Though I think that 32556 is functionally identical (rounds9 > down to the next lower multiple of 512 which is 32256).  >   ? Corrct, that was a typo. Specifying 32000 also rounds to 32556.    ------------------------------  # Date: Tue, 18 May 2004 18:21:59 GMT 4 From: "Roert G. Schaffrath" <rschaffrath@yahoo.com>Y Subject: Re: DCLER (DCL Enhancement Request) for DIRECTORY	 /SORT=[CREATED,MODIFIED,...]	 % Message-ID: <40AA5455.7530@yahoo.com>    Michael Austin wrote:  > (snip)G > there are a ton of things I will be able to do with it... :)    While J > Unix has it's weeknesses, contrary to popular belief (especially in this: > newsgroup) there are a lot of really good tools in Unix. >  > Michael Austin > Consultant - Available > 816-373-8572 > 816-728-3080 (Mobile)   A I have to agree.  Prior to starting work with Unix in 1992 and my F subsequent migration from VMS to Unix, I really hated it.  The cryptic@ commands (awk, grep, vi, cat, mv to name a few) and the patheticB security model annoyed me.  VMS has better security with installed= images instead of SUID functionality and granular privileges.   > However, despite the fact that I have written very complex DCLF procedures in the past, shell scripting IMHO is alot more powerful and7 in some cases easier especially with the help of pipes.   C As for the security, well you learn to live with it.  Unix security A reminds me alot of pre-9.0 RSTS/E; [1,*] accounts were "root" and > setting the privileged bit on a RSTS/E file protection was the equivalent of set-uid-root.    ------------------------------  % Date: Tue, 18 May 2004 20:00:51 +0200  From:  neale.hunt@hispeed.ch% Subject: Re: DISMOUNT/POLICY=MINICOPY ) Message-ID: <c8dj08$pn5$1@newshispeed.ch>   G You need to reboot the node that is not serving the disks. As a result  F of the reboot the shadow set will be remounted make suer you have the E /policy=minicopy option in the mount command  (if the disks were not  H dismounted minicopy then the /policy makes no difference). Note you use F sysman to dismount the disks you serve from tehe otehr node. Thia can H all be scripted in syshutdwn.com or do it manually (I use sysman). This C works fine on Alpah VMS V7.3 and upwards (have no vax available ti  ( verify but can't see that as a problem).  H If you shut down both nodes in the cluster, dismounting one half of the H shadow sets wil ensure a copy rather than a merge - which is about half $ the time so shadow after the reboot.  I If both members of the shadow set are served ny one node, then make sure  F reconncetion interval and any shadow timeouts are set long enough for E teh node to reboot, this way the disk go into mount verify until the  2 node is serving again (again can prevent a merge).   -- Neale  / Phillip Helbig---remove CLOTHES to reply wrote: H > I've read the help, read the release notes, read the volume-shadowing F > manual and am still confused about DISMOUNT/POLICY=MINICOPY and its # > support (or lack thereof) on VAX.  > I > Imagine a VAX/ALPHA cluster, VMS 7.3 VAX and 7.3-1 ALPHA.  Some shadow  F > sets are on just a VAX node, some on just an ALPHA node, some split I > across two VAX nodes, some split across a VAX node and an ALPHA node.   + > All shadow sets are mounted by all nodes.  > I > Obviously, MINICOPY is only of interest for the split shadow sets when  J > one node reboots and one stays up.  So we are down to two cases.  (Note J > that I don't (yet) have any shadow sets split across two ALPHA nodes.)  K > Presumably, I issue the DISMOUNT command for a member of the shadow set,  I > perhaps with the /CLUSTER qualifer.  All nodes which stay up will keep  4 > the shadow set mounted (now with only one member). > G > So, for the two cases above, can I reboot a VAX node (or in case one  J > member is on an ALPHA, the ALPHA node)?  Does it matter from which node I > (VAX or ALPHA, direct connection to the member to be lost or not, node  8 > to be rebooted or not) the DISMOUNT command is issued? >    ------------------------------  # Date: Tue, 18 May 2004 19:34:06 GMT , From: "Dave Gudewicz" <k9jdk@NOSPAMarrl.net>2 Subject: Re: Eastern Washington University project/ Message-ID: <Oytqc.31170$6f5.2954270@attbi_s54>   > Minor nit.  A VMS mainframe is about as common as hen's teeth.  6 "SANFACE Software" <mail@sanface.com> wrote in message7 news:8c682947.0405180752.3768e918@posting.google.com... G > As budget restrictions and resources grow tighter, Eastern Washington 7 > http://www.ewu.edu/ University has chosen Txt2pdf-PRO = > http://www.sanface.com/txt2pdfPRO.html as a tool to enhance # > productivity and reduce expenses.  > H > Each of our student, financial, and loan management enterprise systemsD > generates nightly reports that are distributed across campus. WithC > these paper reports comes a number of costs that we are trying to 	 > reduce:   > Cost of paper and its handling > Cost of report distribution  > Cost of additional copies  > Cost of report handling " > Printer and hardware maintenance > Physical storage > Usability costs  > ? > With Txt2pdf-PRO, we are able to reduce expenses and increase B > productivity in each of the above areas. Txt2pdf-PRO runs on ourE > mainframe OpenVMS system. However, as Txt2pdf-PRO is cross-platform G > and can run on any of our servers, we are guaranteed that it will run G > on future servers and operating systems and that we can scale its use E > to an enterprise level as its functionality is leveraged to benefit   > Eastern Washington University.   ------------------------------  # Date: Tue, 18 May 2004 17:39:09 GMT , From: "Dave Gudewicz" <k9jdk@NOSPAMarrl.net>. Subject: Re: I know I'm being picky but ....../ Message-ID: <1Trqc.74518$iF6.6266959@attbi_s02>   K I sent this note to Mr. Stallard of HP BCS fame.  He agreed the message was % confusing and said he'd look into it.   I I have sent Mr. Stallard several VMS IOIs and kept them worded correctly.  He's always responded.   Dave...   . "John Smith" <a@nonymous.com> wrote in message& news:laWdnUyUNvtTuzfdRVn-jg@igs.net...9 > At http://h71000.www7.hp.com/openvms/products/clusters/  > D > OpenVMS clusters are headlined as "World's Best Cluster Software". > 
 > while at > < > http://welcome.hp.com/country/us/en/prodserv/software.html > L > only HP-UX and Linux are touted as 'High Availability & Disaster Tolerant' > (under the Clusters heading).  > L > The 'High Availability & Disaster Tolerant Solutions' link (under the High, > Availability heading) leads only to HP-UX. >  > K > Truth in advertising (which HP seldom seems to deal with...you figure out H > which I'm refering to) would seem to dictate that disaster tolerance & high: > availability ought to be promoted thusly on the HP site: > I > Best Choice - OpenVMS or NSK depending on your needs, recovery times in J > seconds, geographic distribution requirements, and a desire to keep your > data 'clean' and consistent. > E > Better Choice - Tru64, if you are looking for a unix solution today  > ? > Good Choice - HP-UX today, perhaps eventually a Better Choice  > 5 > You Need Your Head Examined Choice - Linux, Windows  >  >    ------------------------------    Date: 18 May 2004 21:00:03 -0700# From: int_80h@hotmail.com (int_80h) N Subject: Loading sharable images with different file versions i.e. PRINT.EXE;*= Message-ID: <7df8ebf7.0405182000.58a5f705@posting.google.com>   @ I think my last posting was misleading. I thought I'd try again.E Notice the default_name0 and the default_name1 in the snippet below.  ; I would like to load different MYPRINT.EXE;* versions using F lib$find_image_symbol(). Possible? If not, how have other teams worked around this?   #include <stdio.h> #include <lib$routines.h>  #include <descrip.h>  
 void main() {       void (*pf)(char*) = 0;       unsigned int status = 0;   '       $DESCRIPTOR(filename, "MYPRINT"); *       $DESCRIPTOR(symbol_name, "MYPRINT");2       $DESCRIPTOR(default_name0, "MY_EXE:.EXE;0");  B       status = lib$find_image_symbol(&filename, &symbol_name, &pf, &default_name0);     3       $DESCRIPTOR(default_name1, "MY_EXE:.EXE;-1"); B       status = lib$find_image_symbol(&filename, &symbol_name, &pf, &default_name1); }    ------------------------------    Date: 18 May 2004 11:32:52 -0700* From: RaoulGough@yahoo.co.uk (Raoul Gough)/ Subject: Re: POSIX time functions and SYS$TZDIR = Message-ID: <a3390f41.0405181032.346092e9@posting.google.com>   _ Roy Omond <Roy.Omond@BlueBubble.UK.Com> wrote in message news:<2gug8fF6rb7qU1@uni-berlin.de>...  > Raoul Gough wrote: >  [snip]= > > This seems very weird to me. I don't think we've modified I > > SYS$STARTUP:VMS$INITIAL-050_LIB.COM, so we're using the default value : > > of SYS$TZDIR, which points to [.USER] and [.SYSTEM] inH > > SYS$SYSROOT:[SYS$ZONEINFO]. On the other hand, the US timezones mustI > > be very heavily used, so I would certainly expect them to work out of 0 > > the box. Can anyone explain what's going on? [snip] > / > Hi Raoul (yes, I am aware of this problem ;-)  > G > The SYS$TZDIR logical name changed at VMS 7.3 - as far as I can tell, D > there's no mention of this change in the Release Notes.  The C-RTLB > documentation still assumes the logical name to be equivalent to@ > SYS$COMMON:[SYS$ZONEINFO.SYSTEM], which, as your tests confirmF > makes "tzset" function as documented when the logical name SYS$TZDIR, > is set to that value (even in /USER-mode).  F So you fix it by doing a define/user on SYS$TZDIR before starting yourD executable? I've been kind of averse to doing this, because it wouldC be confusing to anyone examining the system logical in ignorance of @ the per-process setting. On the other hand, I doubt that I carry= enough weight here to get the system logical altered from the  "official" value.    > B > I consider this a bug introduced with VMS 7.3, and not addressed& > by any fix or workaround since then.  C Amazing to think that they could break the POSIX timezone functions % for the entire USA and not notice it!    --   Raoul Gough.   ------------------------------  % Date: Tue, 18 May 2004 22:10:46 +0400 : From: "Ruslan R. Laishev" <Laishev{at}DeltaTelecom{dot}RU>4 Subject: Re: Printcap file with ip address and port?3 Message-ID: <AE6693B0FD4B781DD82941EC6609699E@nntp>    Hello ! ) 	You should use TELNET Printing Symbiont.    Hal Kuff wrote:  > LTA908|lta908:\ 1 >         :lf=/TCPIP$LPD_ROOT/000000/LTA908.LOG:\  >         :lp=LTA908:\ >         :rm=10.30.6.19,9102:\  >         :rp=text:\% >         :sd=/TCPIP$LPD_ROOT/LTA908:  > #  >  >  > M > How do I get a port number in here... I need 9102 as oposed to the standard  > 9100 ? >  >  >    --   Cheers, Ruslan. D +---------------------pure personal opinion------------------------+C   RADIUS Server for OpenVMS project - www.starlet.spb.ru/radiusvms/ @   TKD (WTF) in Russia, St.-Petersburg - www.TaeKwonDo-WTF.SPb.RU   ------------------------------  % Date: Tue, 18 May 2004 20:10:21 -0500 @ From: "David J. Dachtera" <djesys.nospam@NeOaSrPtAhMlNiOnWk.net>* Subject: Re: Reboot forces Shadowset Merge6 Message-ID: <40AAB3FD.CAEB7BA7@NeOaSrPtAhMlNiOnWk.net>   Larry Kilgallen wrote: > { > In article <40A97204.6F5171EB@NeOaSrPtAhMlNiOnWk.net>, "David J. Dachtera" <djesys.nospam@NeOaSrPtAhMlNiOnWk.net> writes:  > > John Santos wrote: > K > >> You only need to dismount on the node that is rebooting.  If the queue J > >> manager is running on the node that is rebooting, you need to fail itG > >> over to the other node.  (I always thought this was automatic????) J > >> If the queue manager is running on the other node, then it can't have* > >> any open files on the rebooting node. > > L > > True. If the queue manager is enabled to run on any node of the cluster,I > > the shutdown procedure should make it fail over to the surviving node L > > (queue processing continues uninterrupted). In that case, the local nodeL > > would no longer see the queue database as an open file, and the DISMOUNT > > should go cleanly. > A > Actually, the Job Controller process holds QMAN$MASTER.DAT open 7 > even on nodes where the Queue Manager is not running.   A The question is, of course, on what disk does QMAN$MASTER reside?    --   David J. Dachtera  dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------  % Date: Tue, 18 May 2004 20:11:21 -0500 @ From: "David J. Dachtera" <djesys.nospam@NeOaSrPtAhMlNiOnWk.net>* Subject: Re: Reboot forces Shadowset Merge6 Message-ID: <40AAB439.B13A0704@NeOaSrPtAhMlNiOnWk.net>   Bart Zorn wrote: > V > The next question is thus: can I safely stop the Job Controller from SYSHUTDWN.COM ?  D Um, you *DO* understand what the Job Controller is and what it does, right?  , (Not to be confused with the Queue Manager.)   --   David J. Dachtera  dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------  % Date: Tue, 18 May 2004 18:15:52 -0700 # From: "Tom Linden" <tom@kednos.com> * Subject: RE: Reboot forces Shadowset Merge9 Message-ID: <NDEMLKKEBOIFBMJLCECIOEEODEAA.tom@kednos.com>      -----Original Message-----G   From: David J. Dachtera [mailto:djesys.nospam@NeOaSrPtAhMlNiOnWk.net] %   Sent: Tuesday, May 18, 2004 6:10 PM    To: Info-VAX@Mvb.Saic.Com ,   Subject: Re: Reboot forces Shadowset Merge       Larry Kilgallen wrote:   > A   > In article <40A97204.6F5171EB@NeOaSrPtAhMlNiOnWk.net>, "David =   J. Dachtera" <djesys.nospam@NeOaSrPtAhMlNiOnWk.net> writes:    > > John Santos wrote:   > C   > >> You only need to dismount on the node that is rebooting.  If    the queue L   > >> manager is running on the node that is rebooting, you need to fail itI   > >> over to the other node.  (I always thought this was automatic????) L   > >> If the queue manager is running on the other node, then it can't have,   > >> any open files on the rebooting node.   > > A   > > True. If the queue manager is enabled to run on any node of    the cluster,K   > > the shutdown procedure should make it fail over to the surviving node C   > > (queue processing continues uninterrupted). In that case, the    local nodeA   > > would no longer see the queue database as an open file, and    the DISMOUNT   > > should go cleanly.   > C   > Actually, the Job Controller process holds QMAN$MASTER.DAT open 9   > even on nodes where the Queue Manager is not running.   C   The question is, of course, on what disk does QMAN$MASTER reside?   D I don't think it is germane as to WHICH disk it resides on.  SupposeL it resides on some shadow set which may or may not be attached to the systemH where the queue manager runs.  As Larry pointed it it is held open.  NowF rebooting any other node in the cluster will cause a merge unless as IG understand it from the various posts the /policy=minicopy is applied to J both the dismount and the startup mount.  In other words, if it is germane; as to which disk it resides on then there is a design flaw.      --   David J. Dachtera    dba DJE Systems    http://www.djesys.com/  *   Unofficial Affordable OpenVMS Home Page:!   http://www.djesys.com/vms/soho/      --- (   Incoming mail is certified Virus Free.<   Checked by AVG anti-virus system (http://www.grisoft.com).A   Version: 6.0.680 / Virus Database: 442 - Release Date: 5/9/2004    --- & Outgoing mail is certified Virus Free.: Checked by AVG anti-virus system (http://www.grisoft.com).? Version: 6.0.680 / Virus Database: 442 - Release Date: 5/9/2004    ------------------------------  % Date: Tue, 18 May 2004 20:46:37 -0500 @ From: "David J. Dachtera" <djesys.nospam@NeOaSrPtAhMlNiOnWk.net>* Subject: Re: Reboot forces Shadowset Merge6 Message-ID: <40AABC7D.47EA0E19@NeOaSrPtAhMlNiOnWk.net>   Tom Linden wrote:  >  >   -----Original Message-----I >   From: David J. Dachtera [mailto:djesys.nospam@NeOaSrPtAhMlNiOnWk.net] ' >   Sent: Tuesday, May 18, 2004 6:10 PM  >   To: Info-VAX@Mvb.Saic.Com . >   Subject: Re: Reboot forces Shadowset Merge >  >   Larry Kilgallen wrote: >   > C >   > In article <40A97204.6F5171EB@NeOaSrPtAhMlNiOnWk.net>, "David ? >   J. Dachtera" <djesys.nospam@NeOaSrPtAhMlNiOnWk.net> writes:  >   > > John Santos wrote: >   > E >   > >> You only need to dismount on the node that is rebooting.  If 
 >   the queue N >   > >> manager is running on the node that is rebooting, you need to fail itK >   > >> over to the other node.  (I always thought this was automatic????) N >   > >> If the queue manager is running on the other node, then it can't have. >   > >> any open files on the rebooting node. >   > > C >   > > True. If the queue manager is enabled to run on any node of  >   the cluster,M >   > > the shutdown procedure should make it fail over to the surviving node E >   > > (queue processing continues uninterrupted). In that case, the  >   local nodeC >   > > would no longer see the queue database as an open file, and  >   the DISMOUNT >   > > should go cleanly. >   > E >   > Actually, the Job Controller process holds QMAN$MASTER.DAT open ; >   > even on nodes where the Queue Manager is not running.  > E >   The question is, of course, on what disk does QMAN$MASTER reside?  > F > I don't think it is germane as to WHICH disk it resides on.  SupposeN > it resides on some shadow set which may or may not be attached to the systemJ > where the queue manager runs.  As Larry pointed it it is held open.  NowH > rebooting any other node in the cluster will cause a merge unless as II > understand it from the various posts the /policy=minicopy is applied to L > both the dismount and the startup mount.  In other words, if it is germane= > as to which disk it resides on then there is a design flaw.   G Then, I guess there is a design flaw somehwere because when QMAN$MASTER H resides on a shadowed system disk, the system disk shadow-set doesn't goA merge on a reboot of any cluster member sharing that system disk.    --   David J. Dachtera  dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------  % Date: Tue, 18 May 2004 18:55:36 -0700 # From: "Tom Linden" <tom@kednos.com> * Subject: RE: Reboot forces Shadowset Merge9 Message-ID: <NDEMLKKEBOIFBMJLCECIMEFADEAA.tom@kednos.com>      -----Original Message-----G   From: David J. Dachtera [mailto:djesys.nospam@NeOaSrPtAhMlNiOnWk.net] %   Sent: Tuesday, May 18, 2004 6:47 PM    To: Info-VAX@Mvb.Saic.Com ,   Subject: Re: Reboot forces Shadowset Merge       Tom Linden wrote:    >     >   -----Original Message-----K   >   From: David J. Dachtera [mailto:djesys.nospam@NeOaSrPtAhMlNiOnWk.net] )   >   Sent: Tuesday, May 18, 2004 6:10 PM    >   To: Info-VAX@Mvb.Saic.Com 0   >   Subject: Re: Reboot forces Shadowset Merge   >    >   Larry Kilgallen wrote:   >   > E   >   > In article <40A97204.6F5171EB@NeOaSrPtAhMlNiOnWk.net>, "David A   >   J. Dachtera" <djesys.nospam@NeOaSrPtAhMlNiOnWk.net> writes:    >   > > John Santos wrote:   >   > G   >   > >> You only need to dismount on the node that is rebooting.  If    >   the queue @   >   > >> manager is running on the node that is rebooting, you   need to fail it >   >   > >> over to the other node.  (I always thought this was   automatic????)B   >   > >> If the queue manager is running on the other node, then   it can't have 0   >   > >> any open files on the rebooting node.	   >   > > E   >   > > True. If the queue manager is enabled to run on any node of    >   the cluster,@   >   > > the shutdown procedure should make it fail over to the   surviving nodeG   >   > > (queue processing continues uninterrupted). In that case, the    >   local nodeE   >   > > would no longer see the queue database as an open file, and    >   the DISMOUNT   >   > > should go cleanly.   >   > G   >   > Actually, the Job Controller process holds QMAN$MASTER.DAT open =   >   > even on nodes where the Queue Manager is not running.    > G   >   The question is, of course, on what disk does QMAN$MASTER reside?    > H   > I don't think it is germane as to WHICH disk it resides on.  SupposeB   > it resides on some shadow set which may or may not be attached   to the system L   > where the queue manager runs.  As Larry pointed it it is held open.  NowJ   > rebooting any other node in the cluster will cause a merge unless as IK   > understand it from the various posts the /policy=minicopy is applied to C   > both the dismount and the startup mount.  In other words, if it    is germane?   > as to which disk it resides on then there is a design flaw.   I   Then, I guess there is a design flaw somehwere because when QMAN$MASTER J   resides on a shadowed system disk, the system disk shadow-set doesn't goC   merge on a reboot of any cluster member sharing that system disk.   : But it doesn't have to be a system disk, suppose it isn't.     --   David J. Dachtera    dba DJE Systems    http://www.djesys.com/  *   Unofficial Affordable OpenVMS Home Page:!   http://www.djesys.com/vms/soho/      --- (   Incoming mail is certified Virus Free.<   Checked by AVG anti-virus system (http://www.grisoft.com).A   Version: 6.0.680 / Virus Database: 442 - Release Date: 5/9/2004    --- & Outgoing mail is certified Virus Free.: Checked by AVG anti-virus system (http://www.grisoft.com).? Version: 6.0.680 / Virus Database: 442 - Release Date: 5/9/2004    ------------------------------  % Date: Tue, 18 May 2004 21:25:31 -0500 @ From: "David J. Dachtera" <djesys.nospam@NeOaSrPtAhMlNiOnWk.net>* Subject: Re: Reboot forces Shadowset Merge6 Message-ID: <40AAC59B.E736BACB@NeOaSrPtAhMlNiOnWk.net>   Tom Linden wrote:  >  >   -----Original Message-----I >   From: David J. Dachtera [mailto:djesys.nospam@NeOaSrPtAhMlNiOnWk.net] ' >   Sent: Tuesday, May 18, 2004 6:47 PM  >   To: Info-VAX@Mvb.Saic.Com . >   Subject: Re: Reboot forces Shadowset Merge >  >   Tom Linden wrote:  >   > " >   >   -----Original Message-----M >   >   From: David J. Dachtera [mailto:djesys.nospam@NeOaSrPtAhMlNiOnWk.net] + >   >   Sent: Tuesday, May 18, 2004 6:10 PM ! >   >   To: Info-VAX@Mvb.Saic.Com 2 >   >   Subject: Re: Reboot forces Shadowset Merge >   >  >   >   Larry Kilgallen wrote:	 >   >   > G >   >   > In article <40A97204.6F5171EB@NeOaSrPtAhMlNiOnWk.net>, "David C >   >   J. Dachtera" <djesys.nospam@NeOaSrPtAhMlNiOnWk.net> writes:  >   >   > > John Santos wrote:	 >   >   > I >   >   > >> You only need to dismount on the node that is rebooting.  If  >   >   the queue B >   >   > >> manager is running on the node that is rebooting, you >   need to fail it @ >   >   > >> over to the other node.  (I always thought this was >   automatic????)D >   >   > >> If the queue manager is running on the other node, then >   it can't have 2 >   >   > >> any open files on the rebooting node. >   >   > > G >   >   > > True. If the queue manager is enabled to run on any node of  >   >   the cluster,B >   >   > > the shutdown procedure should make it fail over to the >   surviving nodeI >   >   > > (queue processing continues uninterrupted). In that case, the  >   >   local nodeG >   >   > > would no longer see the queue database as an open file, and  >   >   the DISMOUNT >   >   > > should go cleanly.	 >   >   > I >   >   > Actually, the Job Controller process holds QMAN$MASTER.DAT open ? >   >   > even on nodes where the Queue Manager is not running.  >   > I >   >   The question is, of course, on what disk does QMAN$MASTER reside?  >   > J >   > I don't think it is germane as to WHICH disk it resides on.  SupposeD >   > it resides on some shadow set which may or may not be attached >   to the system N >   > where the queue manager runs.  As Larry pointed it it is held open.  NowL >   > rebooting any other node in the cluster will cause a merge unless as IM >   > understand it from the various posts the /policy=minicopy is applied to E >   > both the dismount and the startup mount.  In other words, if it  >   is germaneA >   > as to which disk it resides on then there is a design flaw.  > K >   Then, I guess there is a design flaw somehwere because when QMAN$MASTER L >   resides on a shadowed system disk, the system disk shadow-set doesn't goE >   merge on a reboot of any cluster member sharing that system disk.  > < > But it doesn't have to be a system disk, suppose it isn't.   I thought I did:   "David J. Dachtera" wrote: > C > The question is, of course, on what disk does QMAN$MASTER reside?    --   David J. Dachtera  dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------  # Date: Wed, 19 May 2004 02:21:13 GMT 1 From: Michael Austin <maustin@firstdbasource.com> * Subject: Re: Reboot forces Shadowset Merge2 Message-ID: <40AAC495.4681659E@firstdbasource.com>   <bunch of stuff snipped>  I I actually like idea of a controller-based "business copy", async or sync P depending on distance, rather than what you get with HBVS.  Especially given theO issues when a system or site goes down and cannot be updated and the Merge/CopyeJ etc... problems.  The EVA and XP series have methods for guaranteeing dataL integrity.   I will also have to say, I need to see it in action before I am completely convinced.I  N In one shop, there was no HBVS, but (on HSG) we mirrored smaller single drivesO and larger database drives were raid5.  On EVA, everything was RAID5.  SnapshothA feature for backups etc... pretty cool stuff.  -- and only 240TB.O   Michael Austin.a   ------------------------------  % Date: Tue, 18 May 2004 19:33:39 -0700e# From: "Tom Linden" <tom@kednos.com> * Subject: RE: Reboot forces Shadowset Merge9 Message-ID: <NDEMLKKEBOIFBMJLCECIOEFBDEAA.tom@kednos.com>r     -----Original Message-----G   From: David J. Dachtera [mailto:djesys.nospam@NeOaSrPtAhMlNiOnWk.net]f%   Sent: Tuesday, May 18, 2004 7:26 PM    To: Info-VAX@Mvb.Saic.Com ,   Subject: Re: Reboot forces Shadowset Merge       Tom Linden wrote:o   >     >   -----Original Message-----K   >   From: David J. Dachtera [mailto:djesys.nospam@NeOaSrPtAhMlNiOnWk.net]a)   >   Sent: Tuesday, May 18, 2004 6:47 PMe   >   To: Info-VAX@Mvb.Saic.Com 0   >   Subject: Re: Reboot forces Shadowset Merge   >r   >   Tom Linden wrote:m   >   >S$   >   >   -----Original Message-----!   >   >   From: David J. DachteraC/   [mailto:djesys.nospam@NeOaSrPtAhMlNiOnWk.net]e-   >   >   Sent: Tuesday, May 18, 2004 6:10 PM #   >   >   To: Info-VAX@Mvb.Saic.Come4   >   >   Subject: Re: Reboot forces Shadowset Merge   >   >l    >   >   Larry Kilgallen wrote:   >   >   >OI   >   >   > In article <40A97204.6F5171EB@NeOaSrPtAhMlNiOnWk.net>, "DavidiE   >   >   J. Dachtera" <djesys.nospam@NeOaSrPtAhMlNiOnWk.net> writes:i    >   >   > > John Santos wrote:   >   >   >-K   >   >   > >> You only need to dismount on the node that is rebooting.  If1   >   >   the queueiD   >   >   > >> manager is running on the node that is rebooting, you   >   need to fail it3B   >   >   > >> over to the other node.  (I always thought this was   >   automatic????)F   >   >   > >> If the queue manager is running on the other node, then   >   it can't havec4   >   >   > >> any open files on the rebooting node.
   >   >   > >mI   >   >   > > True. If the queue manager is enabled to run on any node of    >   >   the cluster,D   >   >   > > the shutdown procedure should make it fail over to the   >   surviving nodeK   >   >   > > (queue processing continues uninterrupted). In that case, the8   >   >   local nodeI   >   >   > > would no longer see the queue database as an open file, andD   >   >   the DISMOUNT    >   >   > > should go cleanly.   >   >   >CK   >   >   > Actually, the Job Controller process holds QMAN$MASTER.DAT open A   >   >   > even on nodes where the Queue Manager is not running.h   >   >yK   >   >   The question is, of course, on what disk does QMAN$MASTER reside?    >   >NL   >   > I don't think it is germane as to WHICH disk it resides on.  SupposeF   >   > it resides on some shadow set which may or may not be attached   >   to the systemS@   >   > where the queue manager runs.  As Larry pointed it it is   held open.  NowoB   >   > rebooting any other node in the cluster will cause a merge
   unless as I A   >   > understand it from the various posts the /policy=minicopyr   is applied toOG   >   > both the dismount and the startup mount.  In other words, if it.   >   is germaneC   >   > as to which disk it resides on then there is a design flaw.    >dA   >   Then, I guess there is a design flaw somehwere because whena
   QMAN$MASTERiC   >   resides on a shadowed system disk, the system disk shadow-setp   doesn't goG   >   merge on a reboot of any cluster member sharing that system disk.x   > >   > But it doesn't have to be a system disk, suppose it isn't.     I thought I did:     "David J. Dachtera" wrote:   > E   > The question is, of course, on what disk does QMAN$MASTER reside?f    4 So you did.  Of course, you meant which, not what:-)     --   David J. Dachtera-   dba DJE Systems,   http://www.djesys.com/  *   Unofficial Affordable OpenVMS Home Page:!   http://www.djesys.com/vms/soho/:     ---t(   Incoming mail is certified Virus Free.<   Checked by AVG anti-virus system (http://www.grisoft.com).A   Version: 6.0.680 / Virus Database: 442 - Release Date: 5/9/2004l   --- & Outgoing mail is certified Virus Free.: Checked by AVG anti-virus system (http://www.grisoft.com).? Version: 6.0.680 / Virus Database: 442 - Release Date: 5/9/2004    ------------------------------  # Date: Tue, 18 May 2004 20:26:57 GMTd1 From: Michael Austin <maustin@firstdbasource.com>y! Subject: Re: Request for new SMTP.2 Message-ID: <40AA718E.B17E34B1@firstdbasource.com>   Larry Kilgallen wrote:  h > In article <409FCEAC.6FD5E5E3@firstdbasource.com>, Michael Austin <maustin@firstdbasource.com> writes:B > > It would be real nice to have a way to not bounce any message.K > > Especially since most of the spam uses forged headers etc...the serverspL > > then get into a bounce the bounced message loop.  the only way out is toB > > stop mail and delete all of the bounced messages in the queue. > >e7 > > either a parameter in the .CONFIG file or a logicals) > > TCPIP$BOUNCE_MESSAGES  {TRUE | FALSE}  > ; > The proper technique is to reject during the SMTP dialog.l  e I have been thinking about this... and I somewhat disagree.. it is impossible to reject on an unknownle quantity. If I recall correctly, SMTP does not determine if the user exists or not until after it has i received and processed the entire message.  IE, you do not know that some made-up username does not existwi on your system.. So, the post-processing of the message will "bounce" the message to the person listed inlj the "MAIL FROM:" command.  But, if this too is bogus it gets "bounced" back to me..  thereby causing us/me- to have to handle the same bogus email twice.t  j What ever method (reject email or prohibit bounced messages) is used,  it would still be nice to have this. functionality -- and the sooner the better....  
 receive emailm, discovers user does not exist on this system$ do not bounce it.. just delete it...   Michael Austin   ------------------------------  % Date: Tue, 18 May 2004 14:56:52 -0700p0 From: Mark Berryman <Mark.Berryman@Mvb.Saic.Com>! Subject: Re: Request for new SMTP ' Message-ID: <40aa2434$1@cpns1.saic.com>w   Michael Austin wrote:l > Larry Kilgallen wrote: >  > h >>In article <409FCEAC.6FD5E5E3@firstdbasource.com>, Michael Austin <maustin@firstdbasource.com> writes: >>A >>>It would be real nice to have a way to not bounce any message.jJ >>>Especially since most of the spam uses forged headers etc...the serversK >>>then get into a bounce the bounced message loop.  the only way out is totA >>>stop mail and delete all of the bounced messages in the queue.c >>>p6 >>>either a parameter in the .CONFIG file or a logical( >>>TCPIP$BOUNCE_MESSAGES  {TRUE | FALSE} >>; >>The proper technique is to reject during the SMTP dialog.  >  > g > I have been thinking about this... and I somewhat disagree.. it is impossible to reject on an unknown:g > quantity. If I recall correctly, SMTP does not determine if the user exists or not until after it has0k > received and processed the entire message.  IE, you do not know that some made-up username does not exist-k > on your system.. So, the post-processing of the message will "bounce" the message to the person listed inal > the "MAIL FROM:" command.  But, if this too is bogus it gets "bounced" back to me..  thereby causing us/me/ > to have to handle the same bogus email twice.i > l > What ever method (reject email or prohibit bounced messages) is used,  it would still be nice to have this0 > functionality -- and the sooner the better.... >  > receive email-. > discovers user does not exist on this system& > do not bounce it.. just delete it...  F Please do not confuse SMTP with implementations of mail that use SMTP.  H Any SMTP implementation may, if it chooses to do so, validate all local I recipients during the RCPT TO: exchange.  The SMTP specification clearly  C states this.  The mail systems I have used on VMS will do this (of oI couse, except for MX - which does have this functionality - I wrote them oD myself).  As far as I know, the MTAs that come with TCPIP services, @ TCPware, and Multinet do not do this.  I do not know about PMDF.  I So, if you want local users validated during the SMTP protocol exchange, iG then simply choose an MTA that supports it.  It is not a limitation of a5 SMTP that the one you currently use does not do this.   E As far as bounced bounces go, a properly functioning MTA will not do iI this.  When your system sends a bounce message the value of the envelope eH  From should be null (i.e. MAIL FROM: <>) and, since it is the value of G the envelope From that specifies where bounce messages are to be sent,  G the remote end has no address to send to and simply drops the message.  I This is how it is defined to work.  In practice, many mailers fail to do  H this correctly.  If your mailer is not sending a null envelope From for F bounce messages then it is broken.  If the remote mailer is not using @ the envelope From as the "bounce-to" address then it is broken. I However, I should point out that my mailer does use a null envelope From t9 for bounces and I never get bounce replies to my bounces.t  
 Mark Berryman    ------------------------------  # Date: Tue, 18 May 2004 23:20:21 GMTy1 From: Michael Austin <maustin@firstdbasource.com>t! Subject: Re: Request for new SMTPo2 Message-ID: <40AA9A31.D656DDF9@firstdbasource.com>   Mark Berryman wrote:   > Michael Austin wrote:T > > Larry Kilgallen wrote: > >u > >cj > >>In article <409FCEAC.6FD5E5E3@firstdbasource.com>, Michael Austin <maustin@firstdbasource.com> writes: > >>C > >>>It would be real nice to have a way to not bounce any message.eL > >>>Especially since most of the spam uses forged headers etc...the serversM > >>>then get into a bounce the bounced message loop.  the only way out is to.C > >>>stop mail and delete all of the bounced messages in the queue.k > >>> 8 > >>>either a parameter in the .CONFIG file or a logical* > >>>TCPIP$BOUNCE_MESSAGES  {TRUE | FALSE} > >>= > >>The proper technique is to reject during the SMTP dialog.a > >n > >ei > > I have been thinking about this... and I somewhat disagree.. it is impossible to reject on an unknownei > > quantity. If I recall correctly, SMTP does not determine if the user exists or not until after it hasnm > > received and processed the entire message.  IE, you do not know that some made-up username does not existSm > > on your system.. So, the post-processing of the message will "bounce" the message to the person listed inon > > the "MAIL FROM:" command.  But, if this too is bogus it gets "bounced" back to me..  thereby causing us/me1 > > to have to handle the same bogus email twice.s > >hn > > What ever method (reject email or prohibit bounced messages) is used,  it would still be nice to have this2 > > functionality -- and the sooner the better.... > >y > > receive emailU0 > > discovers user does not exist on this system( > > do not bounce it.. just delete it... >wH > Please do not confuse SMTP with implementations of mail that use SMTP. >.I > Any SMTP implementation may, if it chooses to do so, validate all localeJ > recipients during the RCPT TO: exchange.  The SMTP specification clearlyD > states this.  The mail systems I have used on VMS will do this (ofJ > couse, except for MX - which does have this functionality - I wrote themE > myself).  As far as I know, the MTAs that come with TCPIP services,rB > TCPware, and Multinet do not do this.  I do not know about PMDF. >gJ > So, if you want local users validated during the SMTP protocol exchange,H > then simply choose an MTA that supports it.  It is not a limitation of7 > SMTP that the one you currently use does not do this.2 >.F > As far as bounced bounces go, a properly functioning MTA will not doJ > this.  When your system sends a bounce message the value of the envelopeI >  From should be null (i.e. MAIL FROM: <>) and, since it is the value ofoH > the envelope From that specifies where bounce messages are to be sent,H > the remote end has no address to send to and simply drops the message.J > This is how it is defined to work.  In practice, many mailers fail to doI > this correctly.  If your mailer is not sending a null envelope From for G > bounce messages then it is broken.  If the remote mailer is not usingpA > the envelope From as the "bounce-to" address then it is broken.eJ > However, I should point out that my mailer does use a null envelope From; > for bounces and I never get bounce replies to my bounces.  >  > Mark Berrymanp   Mark,n Assume:     TCPIP Services SMTP servere    VMS MAILd  R I think you misunderstood the bounced - bounced messages part of my description...  i not understanding completely the interaction between SMTP server and the MTA, I am guessing the MTA in myv configuration is VMS MAIL?  i As stated earlier, my server receives a message to <unknown>@mydomain.com (this user does not exist on my e system) and bounces the message to the sender in the  "MAIL FROM:"   Because this address is **also**uo bogus/forged, the receiving system bounces the message back to "postmaster" or equivelent, in my case, the usereo TCPIP$SMTP gets the message.  creating a great anoynance by having to clean out the email box for TCPIP$SMTP (I % don't want the stuff in my inbox...).y  p Again, either way, I would like to be able to not bounce the message in the first place, there are some securityH concerns... I do have VRFY and ETRN turned off for everything but local.  n I will investigate MX and see if it will do what I want...  BTW, is there a "freeware" version of MX available2 somewhere (I guess I could do a google search....)   Thanks Michael Austin   ------------------------------  % Date: Tue, 18 May 2004 17:12:13 -0700 # From: "Tom Linden" <tom@kednos.com>t! Subject: RE: Request for new SMTP 9 Message-ID: <NDEMLKKEBOIFBMJLCECIKEEMDEAA.tom@kednos.com>      -----Original Message-----:   From: Michael Austin [mailto:maustin@firstdbasource.com]%   Sent: Tuesday, May 18, 2004 4:20 PMt   To: Info-VAX@Mvb.Saic.Comi#   Subject: Re: Request for new SMTP        Mark Berryman wrote:     > Michael Austin wrote:    > > Larry Kilgallen wrote:   > >o   > >o@   > >>In article <409FCEAC.6FD5E5E3@firstdbasource.com>, Michael-   Austin <maustin@firstdbasource.com> writes:    > >>E   > >>>It would be real nice to have a way to not bounce any message.U<   > >>>Especially since most of the spam uses forged headers   etc...the serversiA   > >>>then get into a bounce the bounced message loop.  the onlya   way out is to1E   > >>>stop mail and delete all of the bounced messages in the queue.a   > >>>g:   > >>>either a parameter in the .CONFIG file or a logical,   > >>>TCPIP$BOUNCE_MESSAGES  {TRUE | FALSE}   > >>?   > >>The proper technique is to reject during the SMTP dialog..   > >e   > >fB   > > I have been thinking about this... and I somewhat disagree..*   it is impossible to reject on an unknownA   > > quantity. If I recall correctly, SMTP does not determine ife+   the user exists or not until after it has>@   > > received and processed the entire message.  IE, you do not0   know that some made-up username does not existB   > > on your system.. So, the post-processing of the message will.   "bounce" the message to the person listed inB   > > the "MAIL FROM:" command.  But, if this too is bogus it gets/   "bounced" back to me..  thereby causing us/met3   > > to have to handle the same bogus email twice.E   > >;B   > > What ever method (reject email or prohibit bounced messages)/   is used,  it would still be nice to have this-4   > > functionality -- and the sooner the better....   > >G   > > receive emailu2   > > discovers user does not exist on this system*   > > do not bounce it.. just delete it...   >@J   > Please do not confuse SMTP with implementations of mail that use SMTP.   >nK   > Any SMTP implementation may, if it chooses to do so, validate all local L   > recipients during the RCPT TO: exchange.  The SMTP specification clearlyF   > states this.  The mail systems I have used on VMS will do this (ofL   > couse, except for MX - which does have this functionality - I wrote themG   > myself).  As far as I know, the MTAs that come with TCPIP services,wD   > TCPware, and Multinet do not do this.  I do not know about PMDF.   > L   > So, if you want local users validated during the SMTP protocol exchange,J   > then simply choose an MTA that supports it.  It is not a limitation of9   > SMTP that the one you currently use does not do this.s   >eH   > As far as bounced bounces go, a properly functioning MTA will not doL   > this.  When your system sends a bounce message the value of the envelopeK   >  From should be null (i.e. MAIL FROM: <>) and, since it is the value oftJ   > the envelope From that specifies where bounce messages are to be sent,J   > the remote end has no address to send to and simply drops the message.L   > This is how it is defined to work.  In practice, many mailers fail to doK   > this correctly.  If your mailer is not sending a null envelope From foryI   > bounce messages then it is broken.  If the remote mailer is not using"C   > the envelope From as the "bounce-to" address then it is broken.nL   > However, I should point out that my mailer does use a null envelope From=   > for bounces and I never get bounce replies to my bounces.U   >d   > Mark Berryman      Mark, 	   Assume:-      TCPIP Services SMTP servera
      VMS MAIL   B   I think you misunderstood the bounced - bounced messages part of   my description...R  B   not understanding completely the interaction between SMTP server*   and the MTA, I am guessing the MTA in my   configuration is VMS MAIL?  4   As stated earlier, my server receives a message to8   <unknown>@mydomain.com (this user does not exist on my=   system) and bounces the message to the sender in the  "MAILt+   FROM:"   Because this address is **also** @   bogus/forged, the receiving system bounces the message back to2   "postmaster" or equivelent, in my case, the user=   TCPIP$SMTP gets the message.  creating a great anoynance byp5   having to clean out the email box for TCPIP$SMTP (In'   don't want the stuff in my inbox...).s  >   Again, either way, I would like to be able to not bounce the5   message in the first place, there are some securityaJ   concerns... I do have VRFY and ETRN turned off for everything but local.  B   I will investigate MX and see if it will do what I want...  BTW,/   is there a "freeware" version of MX availabler4   somewhere (I guess I could do a google search....)  H I think it is worth the $500, which also gives you access to the mailing8 list.  When I switched my spam dropped by more than 90%.     Thanks   Michael Austin             ---i(   Incoming mail is certified Virus Free.<   Checked by AVG anti-virus system (http://www.grisoft.com).A   Version: 6.0.680 / Virus Database: 442 - Release Date: 5/9/2004    ---h& Outgoing mail is certified Virus Free.: Checked by AVG anti-virus system (http://www.grisoft.com).? Version: 6.0.680 / Virus Database: 442 - Release Date: 5/9/2004o   ------------------------------  + Date: Wed, 19 May 2004 00:28:37 +0000 (UTC)o From: david20@alpha2.mdx.ac.uk! Subject: Re: Request for new SMTP)) Message-ID: <c8e9nl$m1i$1@news.mdx.ac.uk>o  f In article <40AA718E.B17E34B1@firstdbasource.com>, Michael Austin <maustin@firstdbasource.com> writes: >Larry Kilgallen wrote:s >li >> In article <409FCEAC.6FD5E5E3@firstdbasource.com>, Michael Austin <maustin@firstdbasource.com> writes:oC >> > It would be real nice to have a way to not bounce any message.rL >> > Especially since most of the spam uses forged headers etc...the serversM >> > then get into a bounce the bounced message loop.  the only way out is to C >> > stop mail and delete all of the bounced messages in the queue.d >> >8 >> > either a parameter in the .CONFIG file or a logical* >> > TCPIP$BOUNCE_MESSAGES  {TRUE | FALSE} >>< >> The proper technique is to reject during the SMTP dialog. >tf >I have been thinking about this... and I somewhat disagree.. it is impossible to reject on an unknownf >quantity. If I recall correctly, SMTP does not determine if the user exists or not until after it hasj >received and processed the entire message.  IE, you do not know that some made-up username does not existj >on your system.. So, the post-processing of the message will "bounce" the message to the person listed ink >the "MAIL FROM:" command.  But, if this too is bogus it gets "bounced" back to me..  thereby causing us/meJ. >to have to handle the same bogus email twice. >ek >What ever method (reject email or prohibit bounced messages) is used,  it would still be nice to have this,/ >functionality -- and the sooner the better....u >c >receive email- >discovers user does not exist on this systemt% >do not bounce it.. just delete it...7 >@  $ This would not comply with the RFCs.; The system must inform the sender that the delivery failed.   K Note. Even if the rejection is made during the SMTP dialogue a message mustsO still be sent back to the sender. If the mail was sent directly to your machineoL then the rejection message is sent directly back to the sender's mail client2 in the form of the 550 rejection code and message.  I If the mail was sent via an intermediary system then rejecting during thetN SMTP dialogue forces the intermediate system to generate a bounce message back to the sender.  L Indeed for modern MTAs which support the notary extension RFC 3461 specifiesN that if the sender requests it a failure notification should include the whole message in the bounce.   "     The third component of theeD    multipart/report consists of the original message or some portionB    thereof.  When the value of the RET parameter is FULL, the fullG    message SHOULD be returned for any DSN which conveys notification ofuG    delivery failure.  (However, if the length of the message is greaterhE    than some implementation-specified length, the MTA MAY return onlyo9    the headers even if the RET parameter specified FULL.)y "m  ) The "RET" parameter is set by the sender.n        
 David Webb VMS and Unix team leader CCSS Middlesex University     >Michael Austin  >I >n   ------------------------------  # Date: Wed, 19 May 2004 00:42:24 GMTo1 From: Michael Austin <maustin@firstdbasource.com>r! Subject: Re: Request for new SMTPi2 Message-ID: <40AAAD6D.66E74A77@firstdbasource.com>   Tom Linden wrote:r   > <snip>J > I think it is worth the $500, which also gives you access to the mailing: > list.  When I switched my spam dropped by more than 90%. >g  P It is pretty difficult to justify anything when looking for a job/contract...let alone $500....   >6
 >   Thanks >   Michael Austin   ------------------------------  % Date: Tue, 18 May 2004 18:07:46 -0700c# From: "Tom Linden" <tom@kednos.com>w! Subject: RE: Request for new SMTP/9 Message-ID: <NDEMLKKEBOIFBMJLCECICEEODEAA.tom@kednos.com>-     -----Original Message-----:   From: Michael Austin [mailto:maustin@firstdbasource.com]%   Sent: Tuesday, May 18, 2004 5:42 PMu   To: Info-VAX@Mvb.Saic.Como#   Subject: Re: Request for new SMTPA           Tom Linden wrote:   
   > <snip>L   > I think it is worth the $500, which also gives you access to the mailing<   > list.  When I switched my spam dropped by more than 90%.   >,  ?   It is pretty difficult to justify anything when looking for ab   job/contract...let   alone $500..  > Ah, well that is a different issue.  Look on Hunter's site for something similar.     >a   >   Thanks   >   Michael Austin     ---t(   Incoming mail is certified Virus Free.<   Checked by AVG anti-virus system (http://www.grisoft.com).A   Version: 6.0.680 / Virus Database: 442 - Release Date: 5/9/2004u   ---n& Outgoing mail is certified Virus Free.: Checked by AVG anti-virus system (http://www.grisoft.com).? Version: 6.0.680 / Virus Database: 442 - Release Date: 5/9/2004i   ------------------------------  # Date: Wed, 19 May 2004 02:07:26 GMTr1 From: Michael Austin <maustin@firstdbasource.com>e! Subject: Re: Request for new SMTPo2 Message-ID: <40AAC15A.9AC2FCB1@firstdbasource.com>   david20@alpha2.mdx.ac.uk wrote:e  h > In article <40AA718E.B17E34B1@firstdbasource.com>, Michael Austin <maustin@firstdbasource.com> writes: > >Larry Kilgallen wrote:h > >uk > >> In article <409FCEAC.6FD5E5E3@firstdbasource.com>, Michael Austin <maustin@firstdbasource.com> writes:oE > >> > It would be real nice to have a way to not bounce any message.hN > >> > Especially since most of the spam uses forged headers etc...the serversO > >> > then get into a bounce the bounced message loop.  the only way out is to E > >> > stop mail and delete all of the bounced messages in the queue.  > >> >: > >> > either a parameter in the .CONFIG file or a logical, > >> > TCPIP$BOUNCE_MESSAGES  {TRUE | FALSE} > >>> > >> The proper technique is to reject during the SMTP dialog. > > h > >I have been thinking about this... and I somewhat disagree.. it is impossible to reject on an unknownh > >quantity. If I recall correctly, SMTP does not determine if the user exists or not until after it hasl > >received and processed the entire message.  IE, you do not know that some made-up username does not existl > >on your system.. So, the post-processing of the message will "bounce" the message to the person listed inm > >the "MAIL FROM:" command.  But, if this too is bogus it gets "bounced" back to me..  thereby causing us/meg0 > >to have to handle the same bogus email twice. > >-m > >What ever method (reject email or prohibit bounced messages) is used,  it would still be nice to have thisb1 > >functionality -- and the sooner the better....I > >C > >receive email/ > >discovers user does not exist on this systemm' > >do not bounce it.. just delete it...@ > >r >h& > This would not comply with the RFCs.= > The system must inform the sender that the delivery failed.b > M > Note. Even if the rejection is made during the SMTP dialogue a message mustsQ > still be sent back to the sender. If the mail was sent directly to your machinetN > then the rejection message is sent directly back to the sender's mail client4 > in the form of the 550 rejection code and message. > K > If the mail was sent via an intermediary system then rejecting during the@P > SMTP dialogue forces the intermediate system to generate a bounce message back > to the sender. > N > Indeed for modern MTAs which support the notary extension RFC 3461 specifiesP > that if the sender requests it a failure notification should include the whole > message in the bounce. >y > "  >    The third component of the F >    multipart/report consists of the original message or some portionD >    thereof.  When the value of the RET parameter is FULL, the fullI >    message SHOULD be returned for any DSN which conveys notification of I >    delivery failure.  (However, if the length of the message is greaterhG >    than some implementation-specified length, the MTA MAY return onlyt; >    the headers even if the RET parameter specified FULL.)n > "r >e+ > The "RET" parameter is set by the sender.   k I am not disagreeing with the intention of the RFC. I am however wondering -- as are the thousands of otheral mail/SMTP server owners/managers, if the RFC needs a bit of updating... because the fact is, the internet ism clogged  with bogus email bouncing from one system to another because of spam and certain viruses / worms etcEj -- some of them containing worms and virii...  As I said, the "mail from" and the "Return-Path" fields arel generally forged therefore the RFC is causing more problems than it was meant to solve.   Until the spammerso and virus authors are shot and hung by various parts of their anatomy, there needs to be a way for the owner of d the system to control how he/she handles these sorts of things -- not to mention bandwidth issues...  > I have added *@yahoo.{it|fr|ca} to my 'reject-mail-from' list.  _ Example from my mail today... my system bounced this message, and it was bounced back to me....w  + Date: Tue, 18 May 2004 20:13:52 -0500 (CDT) / Message-Id: <04051820135245@firstdbasource.com>-# From: TCPIP$SMTP@FIRSTDBASOURCE.COMf To: TCPIP$SMTP Subject: Returned mail  ' ---- Transcript of session follows ----m> 554  %TCPIP-E-SMTP_XFAIL, remote transaction failure, yahoo.ca  ---- Unsent message follows ----  + Date: Tue, 18 May 2004 20:13:47 -0500 (CDT):/ Message-Id: <04051820134760@firstdbasource.com> # From: TCPIP$SMTP@FIRSTDBASOURCE.COM. To: irqwwwqjckwmgx@yahoo.ca  Subject: Returned mail  ' ---- Transcript of session follows ----sD %%%%%%%%%%%%                   18-MAY-2004 20:13:43.14  %%%%%%%%%%%%1 %MAIL-E-NOSUCHUSR, no such user 3CA09A38.EDD42A5B/D %%%%%%%%%%%%                   18-MAY-2004 20:13:44.33  %%%%%%%%%%%%1 %MAIL-E-NOSUCHUSR, no such user 3CA09ACD.E65931BE D %%%%%%%%%%%%                   18-MAY-2004 20:13:45.56  %%%%%%%%%%%%0 %MAIL-E-NOSUCHUSR, no such user 3CA0EF32.F9EA4BFD %%%%%%%%%%%%                   18-MAY-2004 20:13:46.35  %%%%%%%%%%%%1 %MAIL-E-NOSUCHUSR, no such user 3CA14144.80B41CBDOD %%%%%%%%%%%%                   18-MAY-2004 20:13:47.05  %%%%%%%%%%%%1 %MAIL-E-NOSUCHUSR, no such user 3CA2865D.AE018E651% ---- Recipients of this delivery ----S  0 <3ca09a38.edd42a5b@firstdbasource.com> (bounced)0 <3ca09acd.e65931be@firstdbasource.com> (bounced)/ <3ca0ef32.f9ea4bf@firstdbasource.com> (bounced).0 <3ca14144.80b41cbd@firstdbasource.com> (bounced)0 <3ca2865d.ae018e65@firstdbasource.com> (bounced)    ---- Unsent message follows ----  $ Return-Path: irqwwwqjckwmgx@yahoo.ca- Received: from mx2.dnsvr.com (216.93.166.122) G          by alpha1.firstdbasource.com (V5.3-18E, OpenVMS V7.3-1 Alpha);i-         Tue, 18 May 2004 20:13:40 -0500 (CDT)sP Received: from h00e0188b9f74.ne.client2.attbi.com (h00e0188b9f74.ne.client2.attb i.com [24.128.15.63])l,         by mx2.dnsvr.com (Postfix) with SMTP=         id 9A57A1CB74B; Tue, 18 May 2004 21:10:15 -0400 (EDT)nP Received: from 52.92.144.137 by web764.mail.yahoo.com; Wed, 19 May 2004 12:00:25  -0600+ Message-ID: <PKHCHRLTOARSOFXDRELLY@msn.com>?+ From: "Enrique Kimble" <owrpvlhbr@yahoo.fr>n) To: 3ca09a38.edd42a5b@firstdbasource.com,h-         3ca09acd.e65931be@firstdbasource.com,i,         3ca0ef32.f9ea4bf@firstdbasource.com,-         3ca14144.80b41cbd@firstdbasource.com,o,         3ca2865d.ae018e65@firstdbasource.com1 Subject: Balance Due, account         ineluctable % Date: Wed, 19 May 2004 23:01:25 +0500e MIME-Version: 1.0n+ Content-Type: text/html; charset=iso-8859-1 + Content-Transfer-Encoding: quoted-printableu   ----875350313654304952    [HTML CODE REMOVED for brevity.] ----875350313654304952--     >  > David Webb > VMS and Unix team leader > CCSS > Middlesex University >  > >Michael Austin  > >  > >    ------------------------------  % Date: Wed, 19 May 2004 08:46:27 +0500r& From: Valentin Likoum <me@privacy.net>( Subject: Re: SSL in AST-driven programm?* Message-ID: <2h03kkF5o5rvU1@uni-berlin.de>   Dan Moore wrote:@ > Have a look at STUNNEL. It can wrap SSL around standard TCPIP & > applications. http://www.stunnel.org > E > It's on the OpenVMS Open Source CD. I've been really happy with it.eJ > You will also need SSL installed and configured properly (Also included  > on OpenVMS distributions).  <    Thank you, Dan. We are aware of STUNNEL and use it where 9 it's possible. But in one application we need to know IP h= address of the peer but STUNNEL hides it and connections are h: going from the local address. So we need to integrate SSL  into the application directly.   -- y
 Best regards,s
   Valentin)   valentin.likoum at ncc dot volga dot ru    ------------------------------    Date: 18 May 2004 16:19:47 -0700( From: bob@instantwhip.com (Bob Ceculski)* Subject: Re: SUN fails to advertise VMS...< Message-ID: <d7791aa1.0405181519.1cf087d@posting.google.com>   Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com> wrote in message news:<c8dfbl$p5u$3@new-usenet.uk.sun.com>...p > >  > > Having a bad day?  > 6 > Why would pointing out Bobs very obvious failings be$ > a symptom of me having a bad day ? > 	 > regardso > Andrew Harrison:  : the only thing you are pointing out is your desperation to> trash the only os that can't get viruses and has 13 irrelevant< certs in 13 years (i.e. decwindows) because your company and: every other one out there is selling patch of the day club1 memberships in the form of unix/linux/windoze ...    ------------------------------  % Date: Tue, 18 May 2004 20:53:00 -0400 # From: "John Smith" <a@nonymous.com>r* Subject: Re: SUN fails to advertise VMS..., Message-ID: <GuSdnbaB54ZlMjfdRVn-ig@igs.net>  5 "Bob Ceculski" <bob@instantwhip.com> wrote in messagen6 news:d7791aa1.0405181519.1cf087d@posting.google.com...K > Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com>o= wrote in message news:<c8dfbl$p5u$3@new-usenet.uk.sun.com>...2 > > >  > > > Having a bad day?- > >-8 > > Why would pointing out Bobs very obvious failings be& > > a symptom of me having a bad day ? > >u > > regardsb > > Andrew HarrisonM >e< > the only thing you are pointing out is your desperation to@ > trash the only os that can't get viruses and has 13 irrelevant> > certs in 13 years (i.e. decwindows) because your company and< > every other one out there is selling patch of the day club3 > memberships in the form of unix/linux/windoze ...o     Bob,  J Somehow I don't think that going on about this time after time with AndrewJ will convince him any time soon that he should run out and buy VMS for useJ in his company, even though Andrew knows in his heart that you are correct ;-)e  G You'd be of greater service to OpenVMS by convincing all your company's-H suppliers and customers to come over to VMS. Statistically you'll have aC better chance of doing that than getting Andrew to change his view.    John   ------------------------------  % Date: Tue, 18 May 2004 14:43:09 -0500r( From: brandon@dalsemi.com (John Brandon)F Subject: Re: Switching from Process Software TCPware to TCPIP Services1 Message-ID: <04051814430914@dscis6-0.dalsemi.com>s   David J. Dachtera writes:nE > Well, I've never hacked a TCPware distro., but I can tell you this: E > Multinet provides 13 more DCL verbs than UCX or TCP/IP Services for G > OpenVMS. The names "TCPware" and "Multinet" are a lot shorter, also.)e > G > In general (in my experience and analysis), the economics of bundling I > (TCPIP is now included in the VMS license bundle) don't offset the lossuA > of features or the expense of conversion from either TCPware or  > Multinet.>  J My experience differs.  I use NTP, NFS, FTP, TELNET, SNMP, and a few otherK features.  I have found that the bundled product more cost effective in our / environment.  And again that is my environment.i  N That is NOT to say that TCPWARE is better or worse.  Just that TCPIP is betterA for my environment.  I do not require all the bells and whistles.      J*o*h*n B*r*a*n*d*o*nh VMS Systems Administrator * firstname.lastname.spam.me.not@dalsemi.com   ------------------------------  % Date: Tue, 18 May 2004 20:12:35 -0500o@ From: "David J. Dachtera" <djesys.nospam@NeOaSrPtAhMlNiOnWk.net>F Subject: Re: Switching from Process Software TCPware to TCPIP Services5 Message-ID: <40AAB483.9D9FC36@NeOaSrPtAhMlNiOnWk.net>e   John Vottero wrote:  > M > "David J. Dachtera" <djesys.nospam@NeOaSrPtAhMlNiOnWk.net> wrote in messaged2 > news:40A9742E.E03754D7@NeOaSrPtAhMlNiOnWk.net... >  > [snip] >  > >SL > > Frankly, IMO, since Tru64 is toast anyway, someone should buy up VMS (hpJ > > can't be trusted with it, this much is obvious to even the most casualK > > observer) and Process Software's TCP/IP stacks for it, combine the bestnD > > features of all three stacks into one and bundle the result with > > OpenVMS. > D > I would guess that there are very good reasons for not doing this.K > Otherwise, TCPware and Multinet would have been combined a long time ago.w  D At the moment, they almost are combined. Their intrinsic differences remain, however. -- i David J. Dachterao dba DJE Systemse http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------  % Date: Tue, 18 May 2004 20:21:07 -0500e@ From: "David J. Dachtera" <djesys.nospam@NeOaSrPtAhMlNiOnWk.net>F Subject: Re: Switching from Process Software TCPware to TCPIP Services6 Message-ID: <40AAB683.866FF284@NeOaSrPtAhMlNiOnWk.net>   Bob Ceculski wrote:. >  > "David J. Dachtera" <djesys.nospam@NeOaSrPtAhMlNiOnWk.net> wrote in message news:<40A979D9.622D78C0@NeOaSrPtAhMlNiOnWk.net>... > > Bob Ceculski wrote:t > > > f > > > "Pip" <pip@ti.nl0.com> wrote in message news:<40a93a4f$0$31675$afc38c87@news.optusnet.com.au>...S > > > > Because it appears that TCPware is not currently available for OpenVMS v8.1/ > > > > on Itanium.e > > >6> > > > TCPware is being ported to itanium ... will be there for> > > > 8.2 ... plus it is the ONLY IP stack that can run decnet > > > phase IV over IP ... > >iE > > Not true. Multinet also provides DnIV/IP as Point-to-Point links.A > = > but not TRUE phase IV over IP ... it uses a pwip driver ...n   Try again...  * Have you actually SEEN Multinet's DnIV/IP?  2 Hint: See the on-line Multinet doc.'s, especially:C http://www.multinet.process.com/ftp/docs/html/admin_guide/httoc.htmsI http://www.multinet.process.com/ftp/docs/html/admin_guide/Ch26.htm#E47E27i   No mention is made of PWIP.e   --   David J. Dachtera  dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/e   ------------------------------  % Date: Tue, 18 May 2004 20:22:39 -0500r@ From: "David J. Dachtera" <djesys.nospam@NeOaSrPtAhMlNiOnWk.net>F Subject: Re: Switching from Process Software TCPware to TCPIP Services6 Message-ID: <40AAB6DF.E992C39B@NeOaSrPtAhMlNiOnWk.net>   John Brandon wrote:h >  > David J. Dachtera writes:iG > > Well, I've never hacked a TCPware distro., but I can tell you this:hG > > Multinet provides 13 more DCL verbs than UCX or TCP/IP Services forrI > > OpenVMS. The names "TCPware" and "Multinet" are a lot shorter, also.)  > >MI > > In general (in my experience and analysis), the economics of bundling.K > > (TCPIP is now included in the VMS license bundle) don't offset the losshC > > of features or the expense of conversion from either TCPware ori
 > > Multinet.e > L > My experience differs.  I use NTP, NFS, FTP, TELNET, SNMP, and a few otherM > features.  I have found that the bundled product more cost effective in oure1 > environment.  And again that is my environment.- > P > That is NOT to say that TCPWARE is better or worse.  Just that TCPIP is betterC > for my environment.  I do not require all the bells and whistles.3  G Bells and whistles are all fine and dandy, but I'm talking about actual  usable functionality.F   -- D David J. Dachterae dba DJE Systemss http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/y   ------------------------------  % Date: Wed, 19 May 2004 02:10:09 +0800t, From: Paul Repacholi <prep@prep.synonet.com>+ Subject: Re: The next port for OpenVMS? ;-)>- Message-ID: <87n045ip32.fsf@prep.synonet.com>e  Q Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com> writes:P  C > Its interesting, the only people who still seem to think that thejF > laws of physics which apply to everyone else don't apply to them are > the Itanium folks.  H And the rest of intel marketing it seems. They stated recently that the D upcoming dual core itanic will be smaller than x86 cores! Or perhaps they meant 486s or PPros...e   -- e< Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda.s@                                              West Australia 6076* comp.os.vms,- The Older, Grumpier Slashdot. Raw, Cooked or Well-done, it's all half baked.F EPIC, The Architecture of the future, always has been, always will be.   ------------------------------    Date: 18 May 2004 22:43:02 -0700' From: icerq4a@spray.se (David Svensson)h+ Subject: Re: The next port for OpenVMS? ;-)t= Message-ID: <734da31c.0405182143.50852385@posting.google.com>n   Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com> wrote in message news:<c8df1c$p5u$1@new-usenet.uk.sun.com>...i > John Smith wrote: O > > "Andrew Harrison SUNUK Consultancy" <Andrew_No.Harrison_No@nospamn.sun.com>.? > > wrote in message news:c8d6s3$gq9$1@new-usenet.uk.sun.com...s > >  > >>John Smith wrote:h > >>P > > http://story.news.yahoo.com/news?tmpl=story&ncid=1211&e=7&u=/pcworld/2004051 > > % > >>>7/tc_pcworld/116150&sid=95612664w > >>>I > >>>c > >>>VMS on a PDA anyone? ;-)n > >>>hJ > >>>Lay a bunch of them on a tabletop within 1 meter of each other and do > >  > > IrDA > >  > >>>clusters. > >>>  > >>A > >>Its interesting, the only people who still seem to think thathC > >>the laws of physics which apply to everyone else don't apply toe > >>them are the Itanium folks.w > >  > >  > > J > > Not meaning to stand-up for the Itanic folks, but in fairness, today'sH > > physics of chip engineering is a long way from that of 10 years ago. > > M > > Perhaps in a further 10 years time, Itanic IV with a healthy dose of "EV8hO > > Inside" will prove to be state-of-the-art....if the product line lives thate	 > > long.  > >  > D > One of the major issues seems to be heat output and there are someD > potentially promising new processes coming on stream in the second< > half of the decade that may mitigate against this problem. > H > However its clear from Intels recent cancellation of Tejas and JayhawkH > that they don't expect these new processes to be available soon enough6 > to allow the next generation x86 units to be viable.  $ Potomac and Tulsa are not cancelled,9 and they are also part of the "next generaton x86" units.o  B > To give you some idea of the problem Prescott which is currentlyB > being built in a 90 nanometer process, puts out 103 watts at 3.2A > GHz roughly 20 watts more than a 3.2 GHz Xeon built in an oldere@ > and apparently higher power 130 nanometer process. The 3.2 GHzA > Prescott chip is slightly slower than Xeon for most benchmarks.e > C > Apparently Intel intend to use the die space that would have beenm? > used to build Tejas to house 2 simpler cores that they expectc? > will deliver slightly better throughput than the single Tejasa/ > core but with better thermal characteristics.q > G > Which leaves us with Itanium. Intels reasons for cancelling Tejas and>@ > Jayhawk were mostly around their heat output, Itanium which isA > considerably larger than Tejas and which will be even larger inbB > 2005/2006 suffers from exactly the same problem except of course > its worse.  @ Montecito is apparently in silicon and running, it is said to beE released in 2005, that will most likely be second half of 2005. Goingp? from 130nm to 90nm looks like a problem for P4, but not for PM.uB Whether Itanium will have the same problems as P4 in 2005 is not a@ given. Large caches does not consume as much power as the cores,D actually they differences can be huge, and Itanium cores are smaller than P4 cores.  J > So if you apply the Tejas/Jayhawk logic to Itanium you end up cancelling5 > it in favour of doing a simpler multi-core Itanium.b  > Simpler multicore is, according to some reports, in the works, Tukwila.  I > However there is no simple Itanium core available nor is one likely to cH > surface. The Itanium core could have been a candidate but its too slowJ > and not nearly compact enough, the Pentium M core for example is 2x the E > performance of the Itanium, uses less transistors and puts out lessv > heat.l  4 Pentium M core is not 2x the performance of Itanium.  I > Sun cancelled Millenium Aka USV for exactly the same reasons that Intel I > cancelled Tejas. This could imply that Intel is in the same boat as SunnA > except for one very salient difference, Sun had already startedoF > developing an alternative (Rock) and had been doing so for sometime,D > Intel does not seem to have got very far if anywhere down the same > route.  D Many have predicted that Pentium M is the future, and in that regardD they already have an advantage. What Intel will have in x86 space in" 2007 when Rock appears is unknown.   ------------------------------    Date: 18 May 2004 14:17:23 -0700, From: JimStrehlow@data911.com (Jim Strehlow)1 Subject: Re: Timestamp format stored in RMS file? = Message-ID: <4b6ec350.0405181317.4c6f8a9d@posting.google.com>e  b Jaan Kronberg <jaan.kronberg@mail.ee> wrote in message news:<opr7x0i8q6xckwek@diablo.uninet.ee>... > Hi there,g > 
 > 8 bytes: > 0000 36BD 04FB A200. > M > Could anybody "translate" it to "readable" date without using any built-in n > OpenVMS function?F  D We converted OpenVMS RMS date/time values for many data conversions.F We simply used DATATRIEVE to select all rows from a table/file/domain,F if the date column was named  TRANS_DATE  (transaction date), we did a  F DECLARE  TRANS_DATE_CONV  COMPUTED FORMAT  TRANS_DATE  USING YYYYNNDD.   anda PRINT  TRANS_DATE_CONV along with the other columns.P  T We then used SQL*LOAD to load the "Datatrieve exported flat ASCII" file into Oracle.   Do you have or know Datatrieve?aK There are different solutions based upon the tools that you have available.n  / Jim, Systems Manager, Data911, Alameda, CA, USAs   ------------------------------  % Date: Tue, 18 May 2004 22:33:03 -0500 6 From: "Craig A. Berry" <craigberry@mac.com.spamfooler>1 Subject: Re: Timestamp format stored in RMS file?iE Message-ID: <craigberry-6B01F6.22330318052004@chi.news.speakeasy.net>m  1 In article <ZiPoc.1423$Oi3.172@news.cpqcorp.net>,,%  hoff@hp.nospam (Hoff Hoffman) wrote:.  @ > In article <opr7x0i8q6xckwek@diablo.uninet.ee>, Jaan Kronberg ! > <jaan.kronberg@mail.ee> writes:u >  > :8 bytes:) > :0000 36BD 04FB A200 > :uN > :Could anybody "translate" it to "readable" date without using any built-in  > :OpenVMS function? > G >   See the FAQ for an explanation of the OpenVMS quadword time format.i > J > :Or, alternatively, using Perl standard functions (let's assume I don't < > :have any modules and I don't know C - and I really don't)  8 Nothing standard, but there is a pure-Perl example here:  F http://www.xray.mpe.mpg.de/mailing-lists/vmsperl/1998-11/msg00063.html  E >   I would tend to expect that there is some Perl module for OpenVMSII >   somewhere that handles this conversion.  Or you can call through into C >   C code, such as something derived from the code attached below.M  C Reasonable expectation.  There are some functions in the VMS::Misc eF extension, but these call OpenVMS system services and thus don't meet = the cross-platform requirements sated by the original poster.c  G One thing to be aware of is that VMS dates are typically local and not dE normalized to GMT.  So if you convert the value to seconds since the wE unix epoch (as the Perl function cited above does), you will want to mE pass the results to gmtime() rather than localtime() to make sure no c@ offset is added, thus preserving the original local time of the ? original VMS quadword time.  This is the reverse of the normal  > expectations (and intended usage) of gmtime() and localtime().   ------------------------------  % Date: Tue, 18 May 2004 18:47:13 -0400t# From: "John Smith" <a@nonymous.com> . Subject: [OT]:  Maybe SCO is (partially) right, Message-ID: <kpCdnQV3HrHmDzfdRVn-gw@igs.net>  L http://story.news.yahoo.com/news?tmpl=story&cid=75&ncid=738&e=9&u=/nf/200405 18/tc_nf/24083     New Book Slams Linux, Torvalds   Tue May 18, 1:54 PM ET
 Jay Wrolstad,a www.enterprise-linux-it.comg  D A study challenging the origins of Linux states that the open-sourceD software frequently is taken or adapted from material owned by otherK companies and individuals. It also directly questions Linus Torvalds' claimB to be the inventor of Linux.  F The information is contained in a book by Kenneth Brown, president theH Alexis de Tocqueville Institution. Portions of the book will be released later this week.  H Brown conducted a comprehensive study on the source of open-source code,K tracing the free-software movement over three decades, including interviews G with some two-dozen principal developers of Linux, according to Gregory.& Fossedal, a Tocqueville senior fellow.     'Derivative Technology'nJ "Among the conclusions is that there is a high probability that Linux is aJ derivative work, based on previous operating systems -- including, but not6 limited to, Unix and Minux," Fossedal told NewsFactor.  I While many open-source programmers respect intellectual property, Brown'soL study shows that others refer to intellectual-property rights with contempt,
 ADTI reports.      Unix: Most Stolen?C The invention of Unix is an integral part of the Linux story, BrownwJ suggests. "People's exceptional interest in the Unix operating system madeK Unix one of the most licensed, imitated, and stolen products in the historyn  of computer science," he states.  L "For almost thirty years, programmers have tried to build a Unix-like systemF and couldn't," Brown says. "To this day, we have a serious attributionL problem in software development, because some programmers may have chosen to' unscrupulously borrow or imitate Unix."v  I Excerpts from Brown's book will be published at www.adti.net beginning one	 Thursday.    ------------------------------  + Date: Tue, 18 May 2004 23:30:34 +0000 (UTC)i% From: Dan Foster <usenet@evilphb.org>c2 Subject: Re: [OT]:  Maybe SCO is (partially) right6 Message-ID: <slrncal74c.u6a.usenet@gaia.roc2.gblx.net>  H In article <kpCdnQV3HrHmDzfdRVn-gw@igs.net>, John Smith <a@nonymous.com> wrote:N > http://story.news.yahoo.com/news?tmpl=story&cid=75&ncid=738&e=9&u=/nf/200405 > 18/tc_nf/24083   ...and here's the counterpoint:r  7 http://www.theregister.co.uk/2004/05/17/adti_linux_fud/u  F Personally, I would find it hard to believe that Linus Torvalds didn't; act as the major force behind Linux's original development.o  H I have seen the first source code I could find (around 0.9 or so) and itG is certainly small enough and sufficiently simplistic (such as not veryIE granular kernel locking structures) for one person with a few helping  hands to do it.r  C Even Mr. Torvalds himself has (from recollection of USENET posts oriE email from years ago) admitted that it was an extremely primitive andt simplistic original effort.r  B One of the flame wars he had early on was with none other than Dr.? Tanenbaum (creator of Minix, an OS used for computer science OS C programming courses and also an author of numerous CS instructionaliF texts) was due to how primitive and unorthodox Dr. Tanenbaum found Mr. Torvalds' early work to be.,  H It's a very well documented (and interesting) discussion still archived:  = http://groups.google.com/groups?threadm=12595%40star.cs.vu.nla  F Point being is that the early work was really immature and it did showF to all involved, but was still sufficiently small enough that a singleC motivated person could very well do the sheer majority of it. Linux.G exploded when people started contributing device drivers which also lediH to improvements in the underlying architecture and compiler tools, which, contributed to 'critical mass' and so forth.  E Frankly, from what I've read on Groklaw et al., this just sounds likepF typical sour grapes from the SCO camp. Especially interesting is whereG some of the funding for the study came from -- Microsoft, whom has much E vested interest in getting rid of the troublesome phenomenon known asVF Linux. Reference: the Halloween memos (from Microsoft) amongst others.   -Dan   ------------------------------  # Date: Tue, 18 May 2004 23:32:55 GMTa1 From: Michael Austin <maustin@firstdbasource.com>D2 Subject: Re: [OT]:  Maybe SCO is (partially) right2 Message-ID: <40AA9D23.E144E168@firstdbasource.com>  N And this is "new" news???  So I guess the programmers motto of  "why re-inventP the wheel when you can copy and paste" really is very much applicable to Unix asO a whole... I would almost bet that where the source code for any application or>4 OS is available, it too has been copied and used....   Michael Austin..         John Smith wrote:c New Book Slams Linux, Torvalds   >  > Tue May 18, 1:54 PM ET > Jay Wrolstad,l > www.enterprise-linux-it.come >eF > A study challenging the origins of Linux states that the open-sourceF > software frequently is taken or adapted from material owned by otherM > companies and individuals. It also directly questions Linus Torvalds' claim  > to be the inventor of Linux. >bH > The information is contained in a book by Kenneth Brown, president theJ > Alexis de Tocqueville Institution. Portions of the book will be released > later this week. >eJ > Brown conducted a comprehensive study on the source of open-source code,M > tracing the free-software movement over three decades, including interviews I > with some two-dozen principal developers of Linux, according to Gregoryg( > Fossedal, a Tocqueville senior fellow. >s > 'Derivative Technology'eL > "Among the conclusions is that there is a high probability that Linux is aL > derivative work, based on previous operating systems -- including, but not8 > limited to, Unix and Minux," Fossedal told NewsFactor. >eK > While many open-source programmers respect intellectual property, Brown's7N > study shows that others refer to intellectual-property rights with contempt, > ADTI reports.  >l > Unix: Most Stolen?E > The invention of Unix is an integral part of the Linux story, BrowneL > suggests. "People's exceptional interest in the Unix operating system madeM > Unix one of the most licensed, imitated, and stolen products in the historye" > of computer science," he states. >sN > "For almost thirty years, programmers have tried to build a Unix-like systemH > and couldn't," Brown says. "To this day, we have a serious attributionN > problem in software development, because some programmers may have chosen to) > unscrupulously borrow or imitate Unix."r >qK > Excerpts from Brown's book will be published at www.adti.net beginning onc > Thursday.T   ------------------------------  % Date: Tue, 18 May 2004 20:21:03 -0600s" From: GreyCloud <mist@cumulus.com>2 Subject: Re: [OT]:  Maybe SCO is (partially) right0 Message-ID: <U7-dnY9V4vjKWTfdRVn-hQ@bresnan.com>   Dan Foster wrote:o  J > In article <kpCdnQV3HrHmDzfdRVn-gw@igs.net>, John Smith <a@nonymous.com> > wrote: > N >>http://story.news.yahoo.com/news?tmpl=story&cid=75&ncid=738&e=9&u=/nf/200405 >>18/tc_nf/24083 >  > ! > ...and here's the counterpoint:e > 9 > http://www.theregister.co.uk/2004/05/17/adti_linux_fud/  > H > Personally, I would find it hard to believe that Linus Torvalds didn't= > act as the major force behind Linux's original development.r > J > I have seen the first source code I could find (around 0.9 or so) and itI > is certainly small enough and sufficiently simplistic (such as not veryeG > granular kernel locking structures) for one person with a few helpings > hands to do it.  > E > Even Mr. Torvalds himself has (from recollection of USENET posts oryG > email from years ago) admitted that it was an extremely primitive andn > simplistic original effort.  > D > One of the flame wars he had early on was with none other than Dr.A > Tanenbaum (creator of Minix, an OS used for computer science OSRE > programming courses and also an author of numerous CS instructional@H > texts) was due to how primitive and unorthodox Dr. Tanenbaum found Mr. > Torvalds' early work to be.  > J > It's a very well documented (and interesting) discussion still archived: > ? > http://groups.google.com/groups?threadm=12595%40star.cs.vu.nl> > H > Point being is that the early work was really immature and it did showH > to all involved, but was still sufficiently small enough that a singleE > motivated person could very well do the sheer majority of it. LinuxoI > exploded when people started contributing device drivers which also lednJ > to improvements in the underlying architecture and compiler tools, which. > contributed to 'critical mass' and so forth. > G > Frankly, from what I've read on Groklaw et al., this just sounds likeeH > typical sour grapes from the SCO camp. Especially interesting is whereI > some of the funding for the study came from -- Microsoft, whom has muchpG > vested interest in getting rid of the troublesome phenomenon known astH > Linux. Reference: the Halloween memos (from Microsoft) amongst others. > I Pretty much my sentiments as well regarding M$ funding this book and its RF research.  Seeing that longhorn has been delayed, M$ will continue to I FUD linux as much as they can.  Seems that M$ is getting a bit desperate.s   ------------------------------   End of INFO-VAX 2004.276 ************************