1 INFO-VAX	Mon, 10 Apr 2006	Volume 2006 : Issue 198       Contents: Advanced Server 6.1  Re: Advanced Server 6.1  Re: Advanced Server 6.1 - Re: Anybody got the kit for BASIC and COBOL ?   Re: Auto Negotiate with Gigabit? EVA vs. ESA/EMA response time + Re: logging mail sent to non-existent users + Re: logging mail sent to non-existent users + Re: logging mail sent to non-existent users  Re: OpenVMS on zx2000 or zx6000 % Re: possible to avoid a shadow merge? % Re: possible to avoid a shadow merge? % Re: possible to avoid a shadow merge? % Re: possible to avoid a shadow merge? % Re: possible to avoid a shadow merge? % Re: possible to avoid a shadow merge? * Re: Quorum, locks and application question. Re: SMTP: stop sending "no such user" messages  F ----------------------------------------------------------------------   Date: 9 Apr 2006 20:24:14 -0700  From: tomarsin2015@comcast.net Subject: Advanced Server 6.1C Message-ID: <1144639454.096127.166110@t31g2000cwb.googlegroups.com>   D Is there anyway of getting info on what files are access? I can do a show dev/files device, butG I would like to know how many times the file has been access and really ? who is accessing the file since share permissions is granted to  everyone with full control.  thanks phillip    ------------------------------   Date: 9 Apr 2006 22:00:27 -0700 , From: "Cluster-Karl" <karl.rohwedder@gmx.de>  Subject: Re: Advanced Server 6.1C Message-ID: <1144645227.473329.107310@u72g2000cwu.googlegroups.com>    Phillip,  D the currently open files can be viewed with the SHOW OPEN command inG the ADMIN utility. To log all file accesses, you may try with SET AUDIT G POLICY, but I fear, this will collect much data, so you should increase  your event logs.   regards Kalle.   ------------------------------   Date: 9 Apr 2006 22:00:16 -0700 , From: "Cluster-Karl" <karl.rohwedder@gmx.de>  Subject: Re: Advanced Server 6.1B Message-ID: <1144645216.520054.41080@v46g2000cwv.googlegroups.com>   Phillip,  D the currently open files can be viewed with the SHOW OPEN command inG the ADMIN utility. To log all file accesses, you may try with SET AUDIT G POLICY, but I fear, this will collect much data, so you should increase  your event logs.   regards Kalle.   ------------------------------   Date: 9 Apr 2006 12:49:08 -0700 ( From: "Chuck" <chuckmoore55@hotmail.com>6 Subject: Re: Anybody got the kit for BASIC and COBOL ?C Message-ID: <1144612148.772937.234310@e56g2000cwe.googlegroups.com>    Hello Peter, Dave, and Ian,   C I just updated my Google profile with information about my location  within Washington State.   My mailing/living address is 1008 Central, S.E. Olympia, Washington 98501   F I tried the http://vmsone.com link, but the connection timed out the 3$ separate times I tried to access it.  = I very much to appreciate y'all taking the time to assist me,  Chuck    ------------------------------  # Date: Sun, 09 Apr 2006 19:40:28 GMT # From: Beach Runner <bob@nospam.com> ) Subject: Re: Auto Negotiate with Gigabit? < Message-ID: <Mqd_f.140093$g47.72127@tornado.tampabay.rr.com>   Dan Foster wrote: C > In article <06040819092997@dscis6-0.dalsemi.com>, BRANDON, JOHN M  > <brandon@dalsemi.com> wrote: > H >>In the past I have experienced problems with auto-negotiate and 100 MbD >>ethernet adapters - which setting setting both the adapter and the= >>network port to forced 100 Full Duplex resolved any issues.  >  > G >>Though I have not (seemingly) experienced any of the same issues with F >>Gigabit ethernet as I have with 100 Mb - has anyone else expereinced= >>problems with auto-negotiate and Gigabit ethernet adapters?  >  > E > Can't say I have... but would have to be a severely broken setup if G > anyone ever has any issues with gig-e autoneg because it's explicitly : > required by the gig-e standards and properly done there. > H > My recollection says that autonegotiation was a fair bit of a hack, asF > it was overlaid onto the ethernet/fast ethernet standards... but was> > integrated (properly) into the gig-e standards from day one. > H > There are multiple means of autonegotiation with 10baseT and 100baseT;J > it is not a passive thing, but active... and made worse by the fact thatF > there is more than one way to do it. (See the problem? Not everybodyG > does it in the same way; and as such, will not always autoneg on both  > ends properly.)  > E > But with 1000baseX/1000baseT, there is one very well-defined way of 6 > doing it that is (more or less) universally honored. >  > -DanF The problem is with 100mb there were several standard. YOu won't have  this problem with gb.    ------------------------------  % Date: Sun, 09 Apr 2006 20:02:04 -0500 + From: brandon@dalsemi.com (BRANDON, JOHN M) & Subject: EVA vs. ESA/EMA response time1 Message-ID: <06040920020437@dscis6-0.dalsemi.com>   O I just wanted to know what type of results I can expect with the migration from K an ESA/EMA (HSG80) storage environment to the newer EVA storage environment  will have on my processing.   E Yeah I know - as in any environment my mileage will vary depending on , configuration, processing requirements, etc.  = Just looking for some brief comments on what was encountered.    Thanks!      John "REBOOT" Brandon  VMS Systems Administrator * firstname.lastname.spam.me.not@dalsemi.com   ------------------------------  * Date: Sun, 9 Apr 2006 12:55:44 -0500 (CDT)* From: sms@antinode.org (Steven M. Schweda)4 Subject: Re: logging mail sent to non-existent users2 Message-ID: <06040912554463_202002C3@antinode.org>  P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)  4 > I would like to log this for future reference.  In  > TCPIP$SMTP_RECV_RUN.LOG I get  > P >    check_user: User NOBODYNO is apparently a username but has no account: FAIL > F > but these logs are purged.  (When, and why, did these start getting / > created on every run of the receiver?)  [...]       SHOW LOGICAL *SMTP*  F Then consider the possible effect of TCPIP$SMTP_RECV_TRACE.  I'd guessE that they started getting created about when you defined that logical  name.   E    The purging is done by TCPIP$SYSTEM:TCPIP$SMTP_RECV_RUN.COM (TCPIP F SHOW SERVICE /FULL SMTP).  I've changed mine to save a variable number- of log files, determined by the logical name, $ TCPIP$SMTP_RECV_RUN_LOG_PURGE_LIMIT.  :    Note that it's a good idea to keep a copy of a modifiedE TCPIP$SMTP_RECV_RUN.COM in a safe place, as upgrades and ECOs tend to + replace your old one without saving a copy.   H ------------------------------------------------------------------------  3    Steven M. Schweda               sms@antinode-org 4    382 South Warwick Street        (+1) 651-699-9818    Saint Paul  MN  55105-2547    ------------------------------   Date: 9 Apr 2006 11:20:00 -0700  From: davidc@montagar.com 4 Subject: Re: logging mail sent to non-existent usersB Message-ID: <1144606800.813545.88240@z34g2000cwc.googlegroups.com>  A You might consider MX from Mad Goat software.  It's a pretty well F featured Mail Transport Agent, includes routing, rewrite rules, alias,A external program processing of incoming mail (SITE), and managing E mailing lists.  The commercial version ($$) includes support for RBL, D programmed rejections based upon IP, MAIl FROM/RCPT TO combinations,A and more.  I've used it since before there was much in the way of ? OpenVMS TCP/IP products (using UUCP!), and it provides a lot of  flexibility.   ------------------------------  * Date: Sun, 9 Apr 2006 18:27:08 +0000 (UTC)P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)4 Subject: Re: logging mail sent to non-existent users$ Message-ID: <e1bjls$f56$2@online.de>  C In article <06040912554463_202002C3@antinode.org>, sms@antinode.org  (Steven M. Schweda) writes:   R > From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) > 6 > > I would like to log this for future reference.  In" > > TCPIP$SMTP_RECV_RUN.LOG I get  > > R > >    check_user: User NOBODYNO is apparently a username but has no account: FAIL > > H > > but these logs are purged.  (When, and why, did these start getting 1 > > created on every run of the receiver?)  [...]  >  >    SHOW LOGICAL *SMTP* > H > Then consider the possible effect of TCPIP$SMTP_RECV_TRACE.  I'd guessG > that they started getting created about when you defined that logical  > name.   6 The logical name TCPIP$SMTP_RECV_TRACE isn't defined. H TCPIP$SMTP_RECV_RUN.LOG gets created regularly.  (I seem to recall that 9 this wasn't the case with 5.3, or am I imagining things?)    ------------------------------   Date: 9 Apr 2006 19:52:01 -0700 ( From: "Rich Jordan" <jordan@ccs4vms.com>( Subject: Re: OpenVMS on zx2000 or zx6000C Message-ID: <1144637521.533825.142550@i40g2000cwc.googlegroups.com>   G Probably because itanium workstations went the way of itanium desktops, E itanium laptops, and dodo-birds... servers don't need fancy graphics.    ------------------------------  % Date: Sun, 09 Apr 2006 19:37:44 +0200 / From: Paul Sture <paul.sture.nospam@hispeed.ch> . Subject: Re: possible to avoid a shadow merge?8 Message-ID: <1cbd$44394669$50db5015$742@news.hispeed.ch>  / Phillip Helbig---remove CLOTHES to reply wrote: K > I have a new ALPHA as a satellite in my cluster.  The idea is to boot it  G > up only when CSWB is being used, as the other systems don't have the  I > resources.  (The machine is too power-hungry to leave on all the time.) I > I have SYSUAF etc on a non--system-disk shadow set.  As a result, this  H > disk can't be dismounted before shutting down the satellite (at least ! > not easily), due to open files.  > G > Under what conditions will shutting down and rebooting the satellite  J > cause a merge on this disk (or any other disks it can't dismount due to J > open files (assuming the applications with the open files can't be shut + > down prior to shutting down the system)).  >   I Go for Dump Off System Disk (DOSD), and that should avoid a merge of the  ) system disk. Other disks won't be merged.    ------------------------------  * Date: Sun, 9 Apr 2006 18:24:55 +0000 (UTC)P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply). Subject: Re: possible to avoid a shadow merge?$ Message-ID: <e1bjhn$f56$1@online.de>  C In article <1cbd$44394669$50db5015$742@news.hispeed.ch>, Paul Sture ' <paul.sture.nospam@hispeed.ch> writes:    I > > Under what conditions will shutting down and rebooting the satellite  L > > cause a merge on this disk (or any other disks it can't dismount due to L > > open files (assuming the applications with the open files can't be shut - > > down prior to shutting down the system)).  > >  > K > Go for Dump Off System Disk (DOSD), and that should avoid a merge of the  + > system disk. Other disks won't be merged.   I I'm not getting a merge of the system disk, but rather of the disk where   SYSUAF etc are.    ------------------------------  # Date: Sun, 09 Apr 2006 19:37:20 GMT # From: Beach Runner <bob@nospam.com> . Subject: Re: possible to avoid a shadow merge?< Message-ID: <Qnd_f.140091$g47.28575@tornado.tampabay.rr.com>  / Phillip Helbig---remove CLOTHES to reply wrote: E > In article <1cbd$44394669$50db5015$742@news.hispeed.ch>, Paul Sture ) > <paul.sture.nospam@hispeed.ch> writes:   >  > H >>>Under what conditions will shutting down and rebooting the satellite K >>>cause a merge on this disk (or any other disks it can't dismount due to  K >>>open files (assuming the applications with the open files can't be shut  , >>>down prior to shutting down the system)). >>>  >>K >>Go for Dump Off System Disk (DOSD), and that should avoid a merge of the  + >>system disk. Other disks won't be merged.  >  > K > I'm not getting a merge of the system disk, but rather of the disk where   > SYSUAF etc are.  >  Think about mini merge.    ------------------------------  * Date: Sun, 9 Apr 2006 20:13:12 +0000 (UTC)P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply). Subject: Re: possible to avoid a shadow merge?$ Message-ID: <e1bpso$pns$1@online.de>  B In article <Qnd_f.140091$g47.28575@tornado.tampabay.rr.com>, Beach  Runner <bob@nospam.com> writes:    > Think about mini merge.   C I shall.  However, the shadowset which gets merged consists of two  H members each of which has direct connections only to one VAX.  (In each I case, it is a different VAX.)  I'll have to see if MINIMERGE can be used   here (MINICOPY can be).    ------------------------------  % Date: Sun, 09 Apr 2006 22:39:17 +0200 / From: Paul Sture <paul.sture.nospam@hispeed.ch> . Subject: Re: possible to avoid a shadow merge?; Message-ID: <ae332$443970f5$50db5015$10457@news.hispeed.ch>   / Phillip Helbig---remove CLOTHES to reply wrote: E > In article <1cbd$44394669$50db5015$742@news.hispeed.ch>, Paul Sture ) > <paul.sture.nospam@hispeed.ch> writes:   >  > H >>>Under what conditions will shutting down and rebooting the satellite K >>>cause a merge on this disk (or any other disks it can't dismount due to  K >>>open files (assuming the applications with the open files can't be shut  , >>>down prior to shutting down the system)). >>>  >>K >>Go for Dump Off System Disk (DOSD), and that should avoid a merge of the  + >>system disk. Other disks won't be merged.  >  > K > I'm not getting a merge of the system disk, but rather of the disk where   > SYSUAF etc are.  >   9 Can you be more spcific about what "SYSUAF etc" includes?    ------------------------------  + Date: Mon, 10 Apr 2006 02:41:14 +0000 (UTC) 7 From: moroney@world.std.spaamtrap.com (Michael Moroney) . Subject: Re: possible to avoid a shadow merge?( Message-ID: <e1cgka$19e$1@pcls4.std.com>  R helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) writes:  F >Under what conditions will shutting down and rebooting the satellite I >cause a merge on this disk (or any other disks it can't dismount due to  I >open files (assuming the applications with the open files can't be shut  * >down prior to shutting down the system)).  G If I remember, it was a bug that when a certain file (either SYSUAF or  J RIGHTSLIST) resided on a disk other than the system disk, that disk wasn'tI dismounted properly on shutdown, and you'd get shadow merges if it was a  
 shadowset.  @ I don't remember when it was fixed or even if it was ever fixed.   ------------------------------  # Date: Sun, 09 Apr 2006 19:39:18 GMT # From: Beach Runner <bob@nospam.com> 3 Subject: Re: Quorum, locks and application question = Message-ID: <Gpd_f.140092$g47.103222@tornado.tampabay.rr.com>    JF Mezei wrote:   G > Say I have an application which runs on every node of the cluster and H > each instance uses locks to assert itself and tell the other instances( > about its ability to service requests. > B > Does the application need to worry about quorum issues at all ?  > F > If node A is disconnected, is it correct to assume that applicationsF > running on the other nodes will immediatly see the loss of the locks$ > help by their peer that ran on A ?G If it's a cluster, of course.  You can easily corrupt your system disk. G Heck, if a node not seen as member of the cluster mounts the disk, the  0 disk will never get out of a mount verification.   quorum is your friend.   ------------------------------  % Date: Sun, 09 Apr 2006 17:47:16 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 7 Subject: Re: SMTP: stop sending "no such user" messages , Message-ID: <443980D7.662D8A65@teksavvy.com>  C > > Since many names can point to one address, but one address only L > > translates back to one name, could it be legitimate that the translation% > > of an address doesn't match HELO?    Yes.  6 All you, as a receiver, can do is just make sure that:   (1)  HELO smtp.chocolate.com  can translate to *an* IP   and that (2) F the IP address from which the call is coming can be reverse translated to an IP address.       G For (1), you canot even "validate" the IP address. Consider a large ISP E with 10 SMTP servers. They may all use "HELO SMTP.CHOCOLATE.COM"  and H you can translatre SMTP.CHOCOLATE.COM to *an* IP but it doesn't garanteeH that it will translate to the same IP that is being used. (for instance,H it may tranmslate to the first server, but currently, you call is coming from the 3rd server).    For (2)   G All this check does is ensure that the call is coming from an IP adress G that is serious enough to have a reverse translation. You cannot really F validate it. You are simply eliminating calls coming from IP addresses: that aren't serious enough to have a reverse translation.   D Consider a canadian bank that has outsourced its corporate email toaB telco. You'd be getting an email from a user@bank.ca coming from aK server smtp.telus.ca. But this is perfectly valid so you have to accept it.    ------------------------------   End of INFO-VAX 2006.198 ************************