1 INFO-VAX	Sat, 25 Nov 2006	Volume 2006 : Issue 649       Contents:@ (slightly OT) the commercial invoice and international hobbyistsP Re: Annoying screen noise when scrolling on a DECterm (XP1000, Radeon7500, VMS 7 Re: DECW$SERVER crashes (8.3) , Re: increase in spam and what to do about it, Re: increase in spam and what to do about it, Re: increase in spam and what to do about it, Re: increase in spam and what to do about it, Re: increase in spam and what to do about it, Re: increase in spam and what to do about it Re: OpenVMS Clustering Question  Re: OpenVMS Clustering Question  Re: OpenVMS Clustering Question  Re: OpenVMS Support Issues Re: OpenVMS Support Issues Re: OpenVMS Support Issues optimal drives for HSG80  F ----------------------------------------------------------------------  % Date: Sat, 25 Nov 2006 11:38:47 -0000 5 From: "Tom Garcia" <tgarcia-REMOVE-THIS@hivemind.org> I Subject: (slightly OT) the commercial invoice and international hobbyists 7 Message-ID: <45682b49$0$627$5a6aecb4@news.aaisp.net.uk>    Morning,  L I'm likely not the only hobbyist outside the United States who occasionally L gets items shipped across the pond.  Now our socialist utopia imposes 17.5% H tax on the declared value of goods _and_ shipping costs, payable by all K individuals and any business which is not "VAT registered" (ie the smaller   ones).  F The last two places I obtained VMS-related bits from were helpful and L efficient, with the exception that they both did not fill in the commercial G invoice correctly: the shipping/freight line of the commercial invoice  J should contain the amount I was charged for shipping, not "0.00", and the I amount should certainly not be included in another line.  Otherwise, the  M clearance guys make an overestimate of the amount it would cost to ship, and  M then calculate tax based on that figure (in the latter case, then, one would  M be charged tax twice on shipping).  Trying to claw back this extra amount is  ' an exercise in nonproductive masochism.   M I guess the best advice is to ensure that whoever you are obtaining hardware  I from, individual or organisation, is aware of how to fill in the invoice   correctly before you order.    --  ! Tom Garcia | tgarcia@hivemind.org    ------------------------------  % Date: Sat, 25 Nov 2006 10:55:19 +0100 # From: "H Vlems" <hvlems@freenet.de> Y Subject: Re: Annoying screen noise when scrolling on a DECterm (XP1000, Radeon7500, VMS 7 4 Message-ID: <4568125a$0$4669$bf4948fe@news.tele2.nl>  / <petros.dafniotis@gmail.com> schreef in bericht < news:1164406225.723457.155220@m7g2000cwm.googlegroups.com.../ > I would appreciate your help or tips on this.  > @ > Basically when scrolling (either within the TPU editor or justI > executing a DCL command that produces lots of output) I get an annoying I > screen noise to the right of the DECterm. This is totally reproducible. H > I am running VMS 7.3-2 with Graphics V4.00 installed; should I upgrade > to 8.2 or 8.3? > 
 > Details:A > XP1000 (667 MHz), 1.5GB RAM, VMS 7.3-2, Club3D Radeon 7500 card 7 > running on a Compaq P1100 monitor at 1600x1200 @85Hz.  > + > Thank you for reading this. Kind regards,  > Petros >  Petros, J what happens if you scale down to 1280x1024 at 85 Hz, or stay at 1600x1200J but reduce the refresh rate to 75 or 72 Hz? (or go higher if the equipment can handle that)   Hans   ------------------------------  % Date: Sat, 25 Nov 2006 12:07:17 -0500 ) From: "Neil Rieck" <n.rieck@sympatico.ca> & Subject: Re: DECW$SERVER crashes (8.3)< Message-ID: <45687777$0$26896$9a6e19ea@news.newshosting.com>  : "JF Mezei" <jfmezei.spamnot@teksavvy.com> wrote in message1 news:65f1e$45662aea$cef8887a$4606@TEKSAVVY.COM... I >This is just an FYI. If others are also experienceing this perhaps there ( >might be something worth investigating.   [...snip...]  : >23-NOV-2006 15:37:35.3 Access granted to: LOCAL 0 JFMEZEI#      matched entry: LOCAL 0 JFMEZEI  >23-NOV-2006 17:56:06.8 + >23-NOV-2006 17:56:06.9 Fatal server error:  >23-NOV-2006 17:56:07.0 . >23-NOV-2006 17:56:07.2 %SYSTEM-F-ABORT, abort > I >Unrecoverable server internal error (error code = 44) found, terminating  >all connections.    ####  I I see the you are getting error 44 but sometimes it there may be related  I things going on. I suggest you turn on either partial or full accounting   like so:   $set acc/ena=image ! (partial)" $set acc/ena              ! (full)  L This way, if there are other things exiting at the same time as DECW$SERVER F you'll get their times and exit codes as well. Some other people have K suggested tuning. Have you done an autogen with feedback? Be sure to check  A file "SYS$SYSROOT:[SYSEXE]AGEN$PARAMS.REPORT" after you try this.   
 Neil Rieck Kitchener/Waterloo/Cambridge,  Ontario, Canada." http://www3.sympatico.ca/n.rieck/    ------------------------------  % Date: Sat, 25 Nov 2006 04:21:20 -0500 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 5 Subject: Re: increase in spam and what to do about it 8 Message-ID: <7480d$45680af1$cef8887a$15031@TEKSAVVY.COM>  9 Another interesting article about a current wave of spam.   3 http://www.eweek.com/article2/0,1759,2062649,00.asp     C Thanks to OPCOM, I have found that most of it comes in waves. (eg:  J contantly attempting delivery for maybe a minute so lots of bells on OPA0.  K I noticed a problem with the receiver: If you have the service defined has  I having a maximum of 10 connections, but there is a version limit of 5 in  J the directory, then many connection attempts will fail when they all come ) at the same time (such as in spam waves).   . I have reduced the concurrent connections to 2 TCPIP SET SERVICE SMTP/LIMIT=2  I This means that during a wave of incoming messages, only the first 2 are  L connected, then new ones are rejected until the initial ones complete. This ) ends up reducing the load on the machine.   D This works for small business/hobbyist, but obviously not corporate C networks where getting multiple connections at the same time would   legitimately happen often.   ------------------------------  + Date: Sat, 25 Nov 2006 14:57:15 +0000 (UTC)  From: david20@alpha2.mdx.ac.uk5 Subject: Re: increase in spam and what to do about it , Message-ID: <ek9lkb$cc0$1@south.jnrs.ja.net>  M In article <ek9l9r$c7q$1@south.jnrs.ja.net>, david20@alpha2.mdx.ac.uk writes: _ >In article <1164427612.373176.124490@m7g2000cwm.googlegroups.com>, davidc@montagar.com writes:  >>Bill Gunshannon wrote:K >>> > Which is the same set of "potential customers" - I'm just testing the  >>> > RBL at a different place.  >>> L >>> But, if you just change RBL's you open yourself up to all the places theK >>> other RBL had that the new one doesn't and your back where you started.  >>G >>You still don't understand.  An MTA typically checks for an MX record G >>to determine which host to send mail to.  Rather than accept and drop E >>an SMTP connection based on the IP address being in a RBL, it would @ >>save some traffic to not send respond to the DNS lookup if theF >>requesters IP address is on an RBL.  It's the same RBL, just testing: >>the IP address at a different point of the SMTP process. >>I >The DNS lookup of MX (or A records) is not part of the mail transaction. N >The DNS lookup is done to the senders local DNS servers which either have theD >information already cached or have to ask other DNS servers for the
 >information. F >That makes it pretty much impossible to provide incorrect informationJ >eg a 127.0.0.1 response or  no response at all just to systems on an RBL.N >(Also the DNS lookup is used for other types of connectivity not just email.) > P >A better way of doing this was actually devised and used. The original MAPS RBLK >(realtime blacklist)  provided routing information and allowed sites which N >made use of it to basically cut the sites on the list off the internet as far >as they were concerned.  D Sorry that should be Realtime Blackhole list not realtime blacklist.  
 David Webb Security team leader CCSS Middlesex University  P >Since Trend Micro took over MAPS I'm not sure whether the RBL BGP feed is still >available. I >This was at one point quite widely used. One of the UK Education Network L >(JANET) transatalantic links was provided by Teleglobe who implemented this@ >blocking. Hence any US sites which managed to get themselves onN >the RBL list were totally cut off from UK universities - no mail, no web , noQ >contact whatsoever. As far as they were concerned UK universities were no longer  >on the same internet. > I >The disadvantages of this approach (especially when it was controlled by H >someone outside your own organisation ie Teleglobe) are pretty obvious. >  >  >David Webb  >Security team leader  >CCSS  >Middlesex University  >    ------------------------------    Date: 25 Nov 2006 09:08:09 -0800 From: davidc@montagar.com 5 Subject: Re: increase in spam and what to do about it B Message-ID: <1164474489.503942.51480@j72g2000cwa.googlegroups.com>   david20@alpha2.mdx.ac.uk wrote: O > In article <ek9l9r$c7q$1@south.jnrs.ja.net>, david20@alpha2.mdx.ac.uk writes: I > >>You still don't understand.  An MTA typically checks for an MX record I > >>to determine which host to send mail to.  Rather than accept and drop G > >>an SMTP connection based on the IP address being in a RBL, it would B > >>save some traffic to not send respond to the DNS lookup if theH > >>requesters IP address is on an RBL.  It's the same RBL, just testing< > >>the IP address at a different point of the SMTP process. > >>K > >The DNS lookup of MX (or A records) is not part of the mail transaction.   G It is not part of the SMTP protocol, but it is a pre-requisite in order 6 to determine the mail server which you are sending to.  P > >The DNS lookup is done to the senders local DNS servers which either have theF > >information already cached or have to ask other DNS servers for the > >information.   = True, but lots of places run their own name servers, not just G higher-tier ISP's.  Even if all you do it send a short TTL, but invalid D to new and unknown name servers, you can cause the mail to initiallyE fail.  This will cause a re-send, of course, EXCEPT for spam engines. C They do not retry on failures.  This would insure you only get mail D from well-designed mail servers and knock off a chunk of spam.  SomeD anti-spam mail server respond with a 5xx on first connect, and avoid# traffic from spam engines this way.   H > >That makes it pretty much impossible to provide incorrect informationL > >eg a 127.0.0.1 response or  no response at all just to systems on an RBL.P > >(Also the DNS lookup is used for other types of connectivity not just email.) > > R > >A better way of doing this was actually devised and used. The original MAPS RBLM > >(realtime blacklist)  provided routing information and allowed sites which P > >made use of it to basically cut the sites on the list off the internet as far > >as they were concerned. > F > Sorry that should be Realtime Blackhole list not realtime blacklist.  E Which is good, too.  However, was wanting to disrupt traffic a little F higher in the chain before initiating an SMTP connection to avoid someE of the traffic.  It's not a either-or, but an in-addition-to.  And of B course, I'm only talking about MX lookups, no A/CNAME/etc records.   ------------------------------    Date: 25 Nov 2006 09:12:43 -0800 From: davidc@montagar.com 5 Subject: Re: increase in spam and what to do about it C Message-ID: <1164474763.707051.210540@j44g2000cwa.googlegroups.com>    JF Mezei wrote: M > Also, with the way the receiver is setup as an auxiliary service (a process K > is created by the TCPIP Kernel for every incoming call), I am not sure if F > it is possible  for such a process to obtain IP information prior to > accepting the TCPIP call.   C True, even if you write your own MTA, I think you have accept() the - connection in order to get the sockaddr data.    ------------------------------    Date: 25 Nov 2006 09:15:44 -0800 From: davidc@montagar.com 5 Subject: Re: increase in spam and what to do about it A Message-ID: <1164474944.600237.36360@m7g2000cwm.googlegroups.com>    Larry Kilgallen wrote:C > Some of the solutions described in this discussion are listed at:  > 6 > 	http://www.rhyolite.com/anti-spam/you-might-be.html  
 I like it!   ------------------------------  + Date: Sat, 25 Nov 2006 18:27:52 +0000 (UTC)  From: david20@alpha2.mdx.ac.uk5 Subject: Re: increase in spam and what to do about it , Message-ID: <eka1v8$g1o$1@south.jnrs.ja.net>  ^ In article <1164474489.503942.51480@j72g2000cwa.googlegroups.com>, davidc@montagar.com writes:  >david20@alpha2.mdx.ac.uk wrote:P >> In article <ek9l9r$c7q$1@south.jnrs.ja.net>, david20@alpha2.mdx.ac.uk writes:J >> >>You still don't understand.  An MTA typically checks for an MX recordJ >> >>to determine which host to send mail to.  Rather than accept and dropH >> >>an SMTP connection based on the IP address being in a RBL, it wouldC >> >>save some traffic to not send respond to the DNS lookup if the I >> >>requesters IP address is on an RBL.  It's the same RBL, just testing = >> >>the IP address at a different point of the SMTP process.  >> >> L >> >The DNS lookup of MX (or A records) is not part of the mail transaction. > H >It is not part of the SMTP protocol, but it is a pre-requisite in order7 >to determine the mail server which you are sending to.  > L Yes but because of caching the lookup may have been done for an earlier mail message or some other purpose.    Q >> >The DNS lookup is done to the senders local DNS servers which either have the G >> >information already cached or have to ask other DNS servers for the  >> >information. > > >True, but lots of places run their own name servers, not justH >higher-tier ISP's.  Even if all you do it send a short TTL, but invalidE >to new and unknown name servers, you can cause the mail to initially  >fail.    N If only all DNS's and applications would honor short TTLs. Unfortunately lots L don't. Your invalid entries would end up being cached by lots of DNS serversH for long periods as the (non-authorative ie cached) entry for your mail N system - ie lots of legitimate servers would no longer be able to contact you.  7 According to what you returned you might also end up on   @ badconf.rhsbl.sorbs.net - List of domain names where the A or MX( 			  records point to bad address space.      6 For a discussion on DNS servers not honoring TTLs  see  ? http://ask.slashdot.org/article.pl?sid=05/04/18/198259&from=rss     ? >This will cause a re-send, of course, EXCEPT for spam engines. ! >They do not retry on failures.     N Greylisting returns 4xx replies to all mail first time (indicating a temporaryM error) and then accepts it if it is retried but this is accomplished without  / any use of DNS's returning invalid information.   $ >This would insure you only get mailE >from well-designed mail servers and knock off a chunk of spam.  Some E >anti-spam mail server respond with a 5xx on first connect, and avoid $ >traffic from spam engines this way. > J Returning 5xx means that this is a permanent error - sending mail systems E shouldn't retry but should bounce messages when receiving that reply. G This code is returned when mail systems use DNSBL lists to reject mail.     I >> >That makes it pretty much impossible to provide incorrect information M >> >eg a 127.0.0.1 response or  no response at all just to systems on an RBL. Q >> >(Also the DNS lookup is used for other types of connectivity not just email.)  >> >S >> >A better way of doing this was actually devised and used. The original MAPS RBL N >> >(realtime blacklist)  provided routing information and allowed sites whichQ >> >made use of it to basically cut the sites on the list off the internet as far  >> >as they were concerned.  >>G >> Sorry that should be Realtime Blackhole list not realtime blacklist.  > F >Which is good, too.  However, was wanting to disrupt traffic a littleG >higher in the chain before initiating an SMTP connection to avoid some F >of the traffic.  It's not a either-or, but an in-addition-to.  And ofC >course, I'm only talking about MX lookups, no A/CNAME/etc records.  > L Mail servers using DSNBL's to reject mail can generally do it at a number ofL points during the SMTP dialogue. For the PMDF systems I run I have it set toM reject after they have provided the MAIL FROM and MAIL recipients. I could do N it earlier but this allows me to log this information which makes dealing with8 complaints about possible false positives a lot easier.   N The thing you want to avoid is receiving the whole message ie DATA part which  ties up your resources. M In comparison accepting the connection and a few bytes saying who the message 0 purports to be from and who it's for is trivial.      
 David Webb Security team leader CCSS Middlesex University   ------------------------------  % Date: Sat, 25 Nov 2006 10:23:16 -0500 3 From: "Richard B. Gilbert" <rgilbert88@comcast.net> ( Subject: Re: OpenVMS Clustering Question: Message-ID: <0YidnS5iJr55wvXYnZ2dnUVZ_tadnZ2d@comcast.com>   Larry Kilgallen wrote:  h > In article <4567B021.E2DEEFC7@spam.comcast.net>, David J Dachtera <djesys.no@spam.comcast.net> writes: >  >>M White wrote: >>L >>>It's been awhile since I worked with OpenVMS clustering.  Do they have itM >>>now so if one node goes down the processes on the downed node get switched M >>>to the remaining node(s) without manually logging into the remaining node?  >>D >>If you can develop that technology, you'll be the next Bill Gates. >  > 4 > But who would _want_ to be a marketing charlatan ?  C If that's all it takes to have a net worth of $98,000,000,000 I'll   volunteer!!!   ------------------------------  % Date: Sat, 25 Nov 2006 11:12:24 -0500 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> ( Subject: Re: OpenVMS Clustering Question8 Message-ID: <9359d$45686b4a$cef8887a$23178@TEKSAVVY.COM>  	 Question:   F With Wildfire class machines, there is shared memory between the CPUs.  L Some time ago, VMS had some sort of snapshot service where you could take a J snapshot of VMS , and you could then reboot immediatly into that snapshot D (where the snapshot services would create all process contexts , io  channels etc).  I With those two technologies, how hard would it be to provide the ability  ! for a process to truly failover ?   J Process would call SYS$SNAPSHOT(backup_node) at regular intervals, and if H that node failed (and that process was not the guilty party causing the H crash), the backup_node would recreate the process context based on the E snapshot information and the memory belonging to that process on the  
 failing node.   G I realise this is moot now because wildfire class machines don't exist  K beyond Alpha (at least until VMS is ported beyond that IA64 thing), but in  K principle, could this have been implemented ? Or are there too many little  ( things that would make this impossible ?   ------------------------------  + Date: Sat, 25 Nov 2006 17:24:54 +0000 (UTC)  From: david20@alpha2.mdx.ac.uk( Subject: Re: OpenVMS Clustering Question, Message-ID: <ek9u96$euo$1@south.jnrs.ja.net>  h In article <9359d$45686b4a$cef8887a$23178@TEKSAVVY.COM>, JF Mezei <jfmezei.spamnot@teksavvy.com> writes:
 >Question: > G >With Wildfire class machines, there is shared memory between the CPUs.  > M >Some time ago, VMS had some sort of snapshot service where you could take a  K >snapshot of VMS , and you could then reboot immediatly into that snapshot  E >(where the snapshot services would create all process contexts , io   >channels etc).  >   O The snapshot service was just meant to get an image of a newly booted system it G had a large number of restrictions such as not being able to cope with  H a cluster environment, not being able to cope with "uncertified images",C not being able to cope with processes with open writeable files etc M The workaround being that after the snapshot startup various things were then $ run in a post snapshot cleanup file.   See   Q http://www-pi.physics.uiowa.edu/webbook/DISK$RED:%5BDECW$BOOK.VAX%5Ddy4yaa58.p71.   
 David Webb Security team leader CCSS Middlesex University      J >With those two technologies, how hard would it be to provide the ability " >for a process to truly failover ? > K >Process would call SYS$SNAPSHOT(backup_node) at regular intervals, and if  I >that node failed (and that process was not the guilty party causing the  I >crash), the backup_node would recreate the process context based on the  F >snapshot information and the memory belonging to that process on the  >failing node. > H >I realise this is moot now because wildfire class machines don't exist L >beyond Alpha (at least until VMS is ported beyond that IA64 thing), but in L >principle, could this have been implemented ? Or are there too many little ) >things that would make this impossible ?  >  >    ------------------------------  % Date: Sat, 25 Nov 2006 10:20:33 -0500 3 From: "Richard B. Gilbert" <rgilbert88@comcast.net> # Subject: Re: OpenVMS Support Issues : Message-ID: <0YidnS9iJr7fwvXYnZ2dnUVZ_tadnZ2d@comcast.com>   David J Dachtera wrote:  > Sue wrote: > E >>I have requested information that I can take to management to prove C >>that there is an issue and as of yet I have not received one mail I >>message detaling the issues at hand.  Granted it is much easier to talk 8 >>about how bad the problem is but fixing it takes work. >  > O > We tend to focus on addressing the issue which caused the support call first. M > We've tended not to document the progress of support calls. It is generally R > assumed that the call tracking system does this on its own, without the customerP > needing to take specific action (who received the call, at what time, the timeN > at which the called was transferred to the next person, if/when the customerQ > called back, who received the call, how long did that conversation last, etc.). O > This impression comes from the message one hears when placing the call: "This : > call may be monitored or recorded for quality purposes." > 8 > Perhaps more recording/monitoring needs to take place. >   E Then perhaps people should be reporting the log number of calls that  * were not handled in a satisfactory manner.  = There is nothing that Sue or anyone else can do without some  D documentation; if you want something done, you need to provide that I documentation!  In the absence of documentation one is inclined to think  H that some people would rather have something to complain about than get  something fixed.   ------------------------------  % Date: Sat, 25 Nov 2006 10:51:43 -0500  From: norm.raphael@metso.com# Subject: Re: OpenVMS Support Issues Q Message-ID: <OF708717C6.B71DC898-ON85257231.0056184F-85257231.00572C68@metso.com>   + This is a multipart message in MIME format. " --=_alternative 00572C6185257231_=, Content-Type: text/plain; charset="US-ASCII"  K "Richard B. Gilbert" <rgilbert88@comcast.net> wrote on 11/25/2006 10:20:33   AM:    > David J Dachtera wrote:  > > Sue wrote: > > G > >>I have requested information that I can take to management to prove E > >>that there is an issue and as of yet I have not received one mail G > >>message detaling the issues at hand.  Granted it is much easier to   talk: > >>about how bad the problem is but fixing it takes work. > >  > > F > > We tend to focus on addressing the issue which caused the support 
 > call first. F > > We've tended not to document the progress of support calls. It is 	 generally @ > > assumed that the call tracking system does this on its own,  > without the customerD > > needing to take specific action (who received the call, at what  > time, the timeH > > at which the called was transferred to the next person, if/when the  customerF > > called back, who received the call, how long did that conversation > last, etc.).F > > This impression comes from the message one hears when placing the 
 > call: "This < > > call may be monitored or recorded for quality purposes." > > : > > Perhaps more recording/monitoring needs to take place. > >  > G > Then perhaps people should be reporting the log number of calls that  , > were not handled in a satisfactory manner. > ? > There is nothing that Sue or anyone else can do without some  F > documentation; if you want something done, you need to provide that K > documentation!  In the absence of documentation one is inclined to think    J > that some people would rather have something to complain about than get  > something fixed.  ( I have been staying out of this, but....  G I have a support agreement.  I do not often have to invoke it.  When I  J do, I want to be confident that I will get the excellent level of support E to which I have become accustomed.  So I do have a dog in this hunt.  J I want any weaknesses cleared up before I need the support.  I absolutely I agree with Sue and those who want specific cases with difficulties to be  D documented and reported to the website (and properly escalated - if  contact G can be made).  Expressing concern is not, however, "just complaining."    F As an aside:  It is nigh onto December, and I have not been contacted H about 2007 renewal, yet.  One recent year, it took until mid-May to get K the annual support agreement to where it could be signed.  Some situations    7 around support are not new, and the trend is worrisome.   C Be assured that if I cannot get the level of support needed I will  	 document  F and report the situation, after exhausting supplied channels.  Heroic H customer service should be the goal, not the exception (and magnificent  recoveries don't count).  " --=_alternative 00572C6185257231_=+ Content-Type: text/html; charset="US-ASCII"      <br>R <br><font size=2><tt>&quot;Richard B. Gilbert&quot; &lt;rgilbert88@comcast.net&gt;$ wrote on 11/25/2006 10:20:33 AM:<br> <br>  &gt; David J Dachtera wrote:<br> &gt; &gt; Sue wrote:<br> &gt; &gt; <br>G &gt; &gt;&gt;I have requested information that I can take to management  to prove<br>I &gt; &gt;&gt;that there is an issue and as of yet I have not received one  mail<br>J &gt; &gt;&gt;message detaling the issues at hand. &nbsp;Granted it is much easier to talk<br>G &gt; &gt;&gt;about how bad the problem is but fixing it takes work.<br>  &gt; &gt; <br> &gt; &gt; <br>K &gt; &gt; We tend to focus on addressing the issue which caused the support  <br> &gt; call first.<br>H &gt; &gt; We've tended not to document the progress of support calls. It is generally<br>J &gt; &gt; assumed that the call tracking system does this on its own, <br> &gt; without the customer<br> I &gt; &gt; needing to take specific action (who received the call, at what  <br> &gt; time, the time<br> I &gt; &gt; at which the called was transferred to the next person, if/when  the customer<br>P &gt; &gt; called back, who received the call, how long did that conversation<br> &gt; last, etc.).<br> G &gt; &gt; This impression comes from the message one hears when placing  the <br> &gt; call: &quot;This<br> K &gt; &gt; call may be monitored or recorded for quality purposes.&quot;<br>  &gt; &gt; <br>D &gt; &gt; Perhaps more recording/monitoring needs to take place.<br> &gt; &gt; <br>	 &gt; <br> I &gt; Then perhaps people should be reporting the log number of calls that  <br>3 &gt; were not handled in a satisfactory manner.<br> 	 &gt; <br> F &gt; There is nothing that Sue or anyone else can do without some <br>H &gt; documentation; if you want something done, you need to provide that <br>I &gt; documentation! &nbsp;In the absence of documentation one is inclined 
 to think <br> H &gt; that some people would rather have something to complain about than get <br> &gt; something fixed.<br>  </tt></font>I <br><font size=2><tt>I have been staying out of this, but....</tt></font>  <br>J <br><font size=2><tt>I have a support agreement. &nbsp;I do not often have' to invoke it. &nbsp;When I </tt></font> M <br><font size=2><tt>do, I want to be confident that I will get the excellent  level of support </tt></font> J <br><font size=2><tt>to which I have become accustomed. &nbsp;So I do have& a dog in this hunt. &nbsp;</tt></font>G <br><font size=2><tt>I want any weaknesses cleared up before I need the ( support. &nbsp;I absolutely </tt></font>J <br><font size=2><tt>agree with Sue and those who want specific cases with difficulties to be </tt></font> I <br><font size=2><tt>documented and reported to the website (and properly # escalated - if contact </tt></font> L <br><font size=2><tt>can be made). &nbsp;Expressing concern is not, however,0 &quot;just complaining.&quot; &nbsp;</tt></font> <br>G <br><font size=2><tt>As an aside: &nbsp;It is nigh onto December, and I $ have not been contacted </tt></font>G <br><font size=2><tt>about 2007 renewal, yet. &nbsp;One recent year, it & took until mid-May to get </tt></font>F <br><font size=2><tt>the annual support agreement to where it could be* signed. &nbsp;Some situations </tt></font>X <br><font size=2><tt>around support are not new, and the trend is worrisome.</tt></font> <br>I <br><font size=2><tt>Be assured that if I cannot get the level of support # needed I will document </tt></font> H <br><font size=2><tt>and report the situation, after exhausting supplied# channels. &nbsp;Heroic </tt></font> K <br><font size=2><tt>customer service should be the goal, not the exception  (and magnificent </tt></font> 9 <br><font size=2><tt>recoveries don't count).</tt></font>  <br>$ --=_alternative 00572C6185257231_=--   ------------------------------  % Date: Sat, 25 Nov 2006 11:06:44 -0500 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> # Subject: Re: OpenVMS Support Issues 8 Message-ID: <5283c$456869f6$cef8887a$22681@TEKSAVVY.COM>   Richard B. Gilbert wrote: G > Then perhaps people should be reporting the log number of calls that  , > were not handled in a satisfactory manner.  J And Sue should be thanked for offering to champion the cause of those not @ getting good support in exchange for "hard" data on those calls.  J However, when you must tell everyone within your company "because of call G quality issues, whenever you call HP, you must write down all relevant  G details, and insist on call log number and write down the names of the  L people you have spoken with and time on hold etc"  it makes the vendor look H pretty bad in a very public (internally) way. So when the time comes to J justify staying on VMS, you can't use the "VMS has good support" argument ) anymore because of all the bad publicity.     L When you have a vendor whom you trust so little that you need to write down A all this information, then is it worth staying with that vendor ?      As a suggestion to Sue: G Work internally so that whenever a customer calls in, the main contact  K person at that customer site gets an email with all the call details. This  L way, the customer doesn't have to write down all the info.  And if there is O a problem call, it is then easier for the customer to brin the issue to you/HP.    ------------------------------  % Date: Sat, 25 Nov 2006 07:53:17 -0800 * From: "Tom Linden" <tom@kednos-remove.com>! Subject: optimal drives for HSG80 ) Message-ID: <op.tjkw23a5tte90l@hyrrokkin>   B I am considering replacing the 18GB drives in my HSG80 with larger@ capacity.  Newer drives vary greatly in performance, e.g., speed. transfer rate and cache size and therefor cost  D There are 4 shelves each with 6 drives and mirrored controllers withD 256MByte caches, organized as 3 raid arrays.  There are 5 bad drivesC in the system, so rather than replacing with same, why not upgrade. A The controllers are cross-strapped to two 1Gb FC switches  and in % their turn to dual HBAs in each node.   E So the question arises what the optimum drive looks like.  Does cache F on the drive do any good?  Too fast a transfer rate would be masked byF that of the HSG80.  What about spin rate?  Slower drive I would assumeG is likely more reliable.  The difference in latency between 10K and 15K + probably wouldn't noticeable in this system    Appreciate your thoughts.  Tom    ------------------------------   End of INFO-VAX 2006.649 ************************                                                                                                                                                                                                                                                                                                                                                                                              