1 INFO-VAX	Sun, 30 May 2004	Volume 2004 : Issue 298       Contents:  Re: Announcing WHOIS version 1.6  Re: Announcing WHOIS version 1.6  Re: Announcing WHOIS version 1.6  Re: Announcing WHOIS version 1.6  Re: Announcing WHOIS version 1.6  Re: Announcing WHOIS version 1.6% AUTOGEN is confused about file names!  BOOT, HALT, RESTART---again : Contrast with HP and OpenVMS customers who just drift away
 datatrieve% Re: HP and Intel Developer Forum 2004 ; long, boring explanation of minicopy (and HBVS, in general) ? Re: long, boring explanation of minicopy (and HBVS, in general) 5 Re: More on Processors from May issues of "PROCESSOR" , shutdown of a node, shadow copies and merges. Re: VMS721_UPDATE-V0300, 10.5" 6250bpi Magtape  F ----------------------------------------------------------------------  # Date: Sat, 29 May 2004 18:14:37 GMT 1 From: Michael Austin <maustin@firstdbasource.com> ) Subject: Re: Announcing WHOIS version 1.6 ; Message-ID: <hq4uc.1310$Db4.825@newssvr23.news.prodigy.com>    JF Mezei wrote:   O > WHOIS version 1.6 has been released. This is a freeware utility to fill a gap 9 > in the TCPIP Services product which lacks this utility.  > 
 > 1.6 sports:  > 4 > - an updated list of whois servers for most .TLDs.Z > - support for AS number requests through table of AS number ranges and their authorities > - improved parsing of query 2 > - added /HOST qualifier (equivalent to /SERVER)  >  >  > It is available through: > ) > http://www.vaxination.ca/vms/whois.html  > ' > Comments/problem reports appreciated.   F Good Job!!  I did not recompile but just linked with shipped objs.... 
 works great!!    Michael Austin.    ------------------------------  % Date: Sat, 29 May 2004 21:03:14 +0200 , From: "Hans Vlems" <hvlems.dotweg@zonnet.nl>) Subject: Re: Announcing WHOIS version 1.6 * Message-ID: <2hs58lFgdoqsU1@uni-berlin.de>  < "JF Mezei" <jfmezei.spamnot@teksavvy.com> schreef in bericht: news:41246313628ad29ccd5b81045e2b083a@news.teranews.com... > Hans Vlems wrote: 
 > > Compiling 3 > >         $DESCRIPTOR(command_desc,command_line); 
 > >         ^ J > > %CC-W-ADDRCONSTEXT, In the initializer for command_desc.dsc$a_pointer,E > >  "command_line" does not have a constant address, but occurs in a  context  > > thatI > >  requires an address constant.  This is an extension of the language. F > >                 At line number 588 in DISK$APPL3:[WHOIS]WHOIS.C;1. >  > Damned descriptors :-) > E > Have you defined the CC command to add qualifiers to make the DEC C  compiler > more pedantic than default ? > G > I'll look to see why the other descriptor definitions don't cause big  complaints.    JF,   L I did not redefine the CC command as far as I can remember. I'll check that.I But the C compiler on the VAX is not the most current version I'm afraid. K The compiler issues a warning (beyond my understanding of C) and the linker @ is able to build a functioning executable. So far nothing wrong.< On what platform (VMS and DEC C) did you build your version?   Hans   ------------------------------  % Date: Sat, 29 May 2004 21:15:45 +0200 , From: "Hans Vlems" <hvlems.dotweg@zonnet.nl>) Subject: Re: Announcing WHOIS version 1.6 * Message-ID: <2hs605FgbkpeU1@uni-berlin.de>  < "JF Mezei" <jfmezei.spamnot@teksavvy.com> schreef in bericht: news:41246313628ad29ccd5b81045e2b083a@news.teranews.com... > Hans Vlems wrote: 
 > > Compiling 3 > >         $DESCRIPTOR(command_desc,command_line); 
 > >         ^ J > > %CC-W-ADDRCONSTEXT, In the initializer for command_desc.dsc$a_pointer,E > >  "command_line" does not have a constant address, but occurs in a  context  > > thatI > >  requires an address constant.  This is an extension of the language. F > >                 At line number 588 in DISK$APPL3:[WHOIS]WHOIS.C;1. >  > Damned descriptors :-) > E > Have you defined the CC command to add qualifiers to make the DEC C  compiler > more pedantic than default ? > G > I'll look to see why the other descriptor definitions don't cause big  complaints.    JF,   H The fix is to change the declarations on lines 585 and 586 as follows in procedure get_params():    static char command_line[264]; static char temp_str[24];    Hans   ------------------------------  # Date: Sat, 29 May 2004 20:37:35 GMT - From: JF Mezei <jfmezei.spamnot@teksavvy.com> ) Subject: Re: Announcing WHOIS version 1.6 @ Message-ID: <bdb796d9c05dd30d329232d0a25b9d6e@news.teranews.com>   Hans Vlems wrote: J > The fix is to change the declarations on lines 585 and 586 as follows in > procedure get_params():  >   > static char command_line[264]; > static char temp_str[24];   M Thanks for pointing it out. The problem is that the command_line buffer being L dynamically allocated when the subroutine is called, the compiler warns thatN the descriptor sctructure that points to it won't be completre until run-time.M By splitting the structure value assignements, it does the same thing without  the compiler complaining.   F Using your suggestion of "static" would work too (and perhaps be nicerM looking), but it also means that 288 bytes are wasted throughout the run time . of the image (when they are needed only once).    + The compiler I have on VAX is DEC C 6.0-001    ------------------------------  % Date: Sat, 29 May 2004 23:18:19 +0200 , From: "Hans Vlems" <hvlems.dotweg@zonnet.nl>) Subject: Re: Announcing WHOIS version 1.6 * Message-ID: <2hsd60Fgq7stU1@uni-berlin.de>  < "JF Mezei" <jfmezei.spamnot@teksavvy.com> schreef in bericht: news:bdb796d9c05dd30d329232d0a25b9d6e@news.teranews.com... > Hans Vlems wrote: L > > The fix is to change the declarations on lines 585 and 586 as follows in > > procedure get_params():  > > " > > static char command_line[264]; > > static char temp_str[24];  > I > Thanks for pointing it out. The problem is that the command_line buffer  being I > dynamically allocated when the subroutine is called, the compiler warns  thatF > the descriptor sctructure that points to it won't be completre until	 run-time. G > By splitting the structure value assignements, it does the same thing  without  > the compiler complaining.  > H > Using your suggestion of "static" would work too (and perhaps be nicerJ > looking), but it also means that 288 bytes are wasted throughout the run time0 > of the image (when they are needed only once). >  > - > The compiler I have on VAX is DEC C 6.0-001   7 That's what I thought, you have a more recent compiler. H I'm not sure JF that I understand why 288 bytes are wasted. I'm not that familiarK with C to be honest and I'd appreciate it if you could elaborate that point  for me.    ------------------------------  # Date: Sat, 29 May 2004 23:07:08 GMT   From: nobody <nobody@nobody.org>) Subject: Re: Announcing WHOIS version 1.6 @ Message-ID: <2e3bc98e2ed945bcf91280f377a2bcb1@news.teranews.com>   Hans Vlems wrote: = > I'm not sure JF that I understand why 288 bytes are wasted.   I static char name[288] l means that the 288 bytes remain allocated for the I duration of the image, so that all activations of the routine re-use that C storage. )eg: storage is persistant across subroutine invocations).   L char name[288] means that the space is allocated only when the subroutine isT caklled and the space is released once the subroutine returns control to the caller.   ------------------------------  + Date: Sat, 29 May 2004 19:52:05 +0000 (UTC) P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply). Subject: AUTOGEN is confused about file names!$ Message-ID: <c9apl4$c15$1@online.de>  0 $  SEARCH SYS$SYSTEM:*.DAT/SIN PAGEFILE,SWAPFILE   ******************************( SYS$SYSROOT:[SYSEXE]AGEN$FEEDBACK.DAT;52  * SWAPFILE1_NAME = "SYS$SYSTEM:SWAPFILE.SYS" SWAPFILE1_PEAK = 1920 : SWAPFILE2_NAME = "DISK$SWAPPAGE_3:[GLADIA]SWAPFILE2.SYS;1" SWAPFILE2_PEAK = 0: PAGEFILE1_NAME = "DISK$SWAPPAGE_3:[GLADIA]PAGEFILE2.SYS;1" PAGEFILE1_PEAK = 2843 * PAGEFILE2_NAME = "SYS$SYSTEM:PAGEFILE.SYS" PAGEFILE2_PEAK = 2909    ******************************! SYS$SYSROOT:[SYSEXE]PARAMS.DAT;83   * SWAPFILE1_NAME = "SYS$SYSTEM:SWAPFILE.SYS" SWAPFILE1_PEAK = 1920 : SWAPFILE2_NAME = "DISK$SWAPPAGE_3:[GLADIA]SWAPFILE2.SYS;1" SWAPFILE2_PEAK = 0: PAGEFILE1_NAME = "DISK$SWAPPAGE_3:[GLADIA]PAGEFILE2.SYS;1" PAGEFILE1_PEAK = 2843 * PAGEFILE2_NAME = "SYS$SYSTEM:PAGEFILE.SYS" PAGEFILE2_PEAK = 2909 > PAGEFILE1_NAME="SYS$SYSTEM:PAGEFILE.SYS" ! WHY DO I NEED THIS? MIN_PAGEFILE1_SIZE=200000 6 PAGEFILE2_NAME="DISK$SWAPPAGE_3:[GLADIA]PAGEFILE2.SYS" PAGEFILE2_SIZE=400000 F SWAPFILE1_NAME="SYS$SYSTEM:SWAPFILE.SYS" ! MAYBE NOT NEEDED; SEE ABOVE MIN_SWAPFILE1_SIZE=500006 SWAPFILE2_NAME="DISK$SWAPPAGE_3:[GLADIA]SWAPFILE2.SYS" SWAPFILE2_SIZE=100000    From AGEN$PARAMS.REPORT:  4 AUTOGEN Parameter Calculation Report on node: GLADIA;   This information was generated at 29-MAY-2004 14:22:09.62 K   AUTOGEN was run from SAVPARAMS to SETPARAMS - default execution specified      Processing Parameter Data files  -------------------------------   3 Including parameters from: SYS$SYSTEM:MODPARAMS.DAT   9 The following problems were detected within MODPARAMS.DAT 1    These problems should be reviewed immediately.   9 ** WARNING ** - Duplicate value for PAGEFILE1_NAME found. G 	This overrides preceding requirements for this parameter in PARAMS.DAT J 	Please review the parameter setting and if possible use MIN, MAX, or ADD.  9 ** WARNING ** - Duplicate value for PAGEFILE2_NAME found. G 	This overrides preceding requirements for this parameter in PARAMS.DAT J 	Please review the parameter setting and if possible use MIN, MAX, or ADD.  9 ** WARNING ** - Duplicate value for SWAPFILE2_NAME found. G 	This overrides preceding requirements for this parameter in PARAMS.DAT J 	Please review the parameter setting and if possible use MIN, MAX, or ADD.  = Feedback information was collected on 29-MAY-2004 14:22:08.63 F   Old values below are the parameter values at the time of collection.5   The feedback data is based on 463 hours of up time. B   Feedback information will be used in the subsequent calculations  -  Calculations for page, swap, and dump files. -  --------------------------------------------   #     Errorlog dumpfile calculations:   4 	No errorlog dump file modifications should be made., 	Errorlog dumpfile will remain at 34 blocks.       Dump file calculations: + 	No dump file modifications should be made. 8 	Dumpfile on device DSA133: will remain at 98348 blocks.       Page file calculations:   Q         PAGEFILE1_SIZE information (for DISK$SWAPPAGE_3:[GLADIA]PAGEFILE2.SYS;1):  	Feedback information.- 	   Old value was 400000, New value is 200000 * 	   Maximum observed usage (blocks): 45488B 	Override Information - parameter calculation has been overridden.= 	   The calculated value was 68200.  The new value is 200000. 9 	   PAGEFILE1_SIZE is not allowed to be less than 200000. 9 	   PAGEFILE1_SIZE will be modified to hold 200000 blocks   A         PAGEFILE2_SIZE information (for SYS$SYSTEM:PAGEFILE.SYS):  	Feedback information.- 	   Old value was 400000, New value is 400000 * 	   Maximum observed usage (blocks): 46544B 	Override Information - parameter calculation has been overridden.= 	   The calculated value was 69800.  The new value is 400000. B 	   PAGEFILE2_SIZE has been set to the hard-coded value of 400000.? 	   PAGEFILE2 will not be modified. The file size is within 10%   @ 	** NOTE ** Unable to change the size of PAGEFILE1 since current< 	   disk block utilization is 95%.  However, if enough spaceK 	   were available, DISK$SWAPPAGE_3:[GLADIA]PAGEFILE2.SYS;1, would contain  D 	   200000 blocks.  Instead, PAGEFILE1 will remain at 400000 blocks.       Swap file calculations:   A         SWAPFILE1_SIZE information (for SYS$SYSTEM:SWAPFILE.SYS):  	Feedback information.+ 	   Old value was 50000, New value is 50000 * 	   Maximum observed usage (blocks): 30720B 	Override Information - parameter calculation has been overridden.< 	   The calculated value was 46100.  The new value is 50000.8 	   SWAPFILE1_SIZE is not allowed to be less than 50000.? 	   SWAPFILE1 will not be modified. The file size is within 10%   Q         SWAPFILE2_SIZE information (for DISK$SWAPPAGE_3:[GLADIA]SWAPFILE2.SYS;1):  	Feedback information.- 	   Old value was 100000, New value is 100000 & 	   Maximum observed usage (blocks): 0B 	Override Information - parameter calculation has been overridden.< 	   The calculated value was 6400.  The new value is 100000.B 	   SWAPFILE2_SIZE has been set to the hard-coded value of 100000.? 	   SWAPFILE2 will not be modified. The file size is within 10%    From MODPARAMS.DAT:   > PAGEFILE1_NAME="SYS$SYSTEM:PAGEFILE.SYS" ! why do I need this? MIN_PAGEFILE1_SIZE=200000 6 PAGEFILE2_NAME="DISK$SWAPPAGE_3:[GLADIA]PAGEFILE2.SYS" PAGEFILE2_SIZE=400000 F SWAPFILE1_NAME="SYS$SYSTEM:SWAPFILE.SYS" ! maybe not needed; see above MIN_SWAPFILE1_SIZE=500006 SWAPFILE2_NAME="DISK$SWAPPAGE_3:[GLADIA]SWAPFILE2.SYS" SWAPFILE2_SIZE=100000   H What I don't understand is why the system can't set up the pagefile and I swapfile names like I have them in MODPARAMS.DAT.  I've had these values  . in MODPARAMS.DAT for several AUTOGEN runs now.   $  SHOW MEM/FILE  @               System Memory Resources on 29-MAY-2004 21:48:45.19  L Swap File Usage (8KB pages):                   Index        Free        SizeP   DISK$ALPHASYS_3:[SYS0.SYSEXE]SWAPFILE.SYS                                     L                                                    1        2544        3120P   DISK$SWAPPAGE_3:[GLADIA]SWAPFILE2.SYS;1                                       L                                                    2        6248        6248  L   Total size of all swap files:                                         9368  L Paging File Usage (8KB pages):                 Index        Free        SizeP   DISK$SWAPPAGE_3:[GLADIA]PAGEFILE2.SYS;1                                       L                                                  253       22693       24992P   DISK$ALPHASYS_3:[SYS0.SYSEXE]PAGEFILE.SYS                                     L                                                  254       22613       24992  L   Total size of all paging files:                                      49984L   Total committed paging file usage:                                    6432  F As things are set up, AUTOGEN will never actually change the sizes of H the files: either they are hard-coded, or there is a minimum value much H larger than the actual usage (at the present time).  Thus, I could take I the stuff out of MODPARAMS.DAT, but a) the wrong information is still in  G the other files in SYS$SYSTEM:*.DAT, b) I want to understand where the  G problem lies and c) I need to make sure that the system knows what the  F page and swap files are supposed to be!  (DISK$SWAPPAGE_3 is a shadow I set of solid-state disks.  I would like the page and swap files there to  I be used preferentially, with the ones on the system disk only as reserve  E in case those are the only ones the system has access to, but that's   another question.)   ------------------------------  + Date: Sat, 29 May 2004 17:59:46 +0000 (UTC) P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)$ Subject: BOOT, HALT, RESTART---again# Message-ID: <c9aj2h$cu$4@online.de>   G There have been many threads on this, many initiated by me.  There are  F the values 1, 2 and 3 corresponding to RESTART, BOOT and HALT for the ( BOOT and AUTO_ACTION console parameters.  E I have a VAXstation 4000/60 in my cluster which has been leaving the  I cluster recently---about every three weeks on average.  BOOT is set to 1  E (RESTART).  However, it doesn't restart or reboot after such a crash.   E What I want to do is this: make sure it ALWAYS reboots after a power  H cycle, and reboots (or restarts) if at all possible after an unexpected G crash.  Am I wrong in assuming that setting BOOT to 1 (RESTART) is the   best way to do this?     It doesn't leave a crash dump.  E For about a year now, I have been switching off the console (a VT320  G connected via MMJ).  (Strangely, this used to produce a BREAK and thus  I halt the system, but doesn't anymore.)  Could this somehow be preventing  E the machine from restarting/rebooting after such an unexpected crash?   H Power-cycling the machine allows it to come up again normally, so there B doesn't seem to be any serious problem, at least no permanent one.   ------------------------------  % Date: Sat, 29 May 2004 17:47:21 -0400 # From: "John Smith" <a@nonymous.com> C Subject: Contrast with HP and OpenVMS customers who just drift away , Message-ID: <YtidnXXqM9F1mSTd4p2dnA@igs.net>  L http://story.news.yahoo.com/news?tmpl=story&cid=1738&ncid=1208&e=10&u=/zd/20 040527/tc_zd/128287   B ...and no advertising by HP to convince customers to stay with VMS  C ....but that gets harder each day as more ISV's drift away too.....    -------------------     / IBM's Ad Attacking Oracle Omits Migration Costs    Thu May 27, 2:31 PM ET Lisa Vaas - eWEEK   J I loved the "May Day! May Day!" ad IBM took out in The Wall Street Journal9 and The New York Times last Friday and earlier this week.   E In the ad, here in PDF form, IBM offers to "rescue" Oracle users from K voracious Oracle sales reps as Oracle nears the end of its fiscal year. The G season "usually brings constant calls from your Oracle sales team," IBM  reminds us in the ad.   L "Come next year, Oracle's current levels of support of 8i vanish, and you'reI relegated to second-tier support," the ad continues, "which means limited I support at a higher cost. As we speak, they've already eliminated patches J for this installed database. Any way you look at it, you're stuck. This isB fallout from eagerness to shift you to Oracle's new 10g database."  L The ad continues on in a delightfully snotty way, suggesting that now is theC time to re-evaluate IBM DB2 Universal Database and IBM DB2 support.   G It's so snotty, it's like something that only a huge, arrogant database J behemoth would think up-say, a few years back, before such a company mightL have launched, say, a campaign to swallow a rival and therefore attempted toL clean up its bratty image and gain the affection of stockholders and judges.  J Sound familiar? Sound like Oracle? Bingo! IBM has learned from the masters* how to spread fear, uncertainty and doubt.  I In this particular FUD campaign, IBM is trying to get at Oracle customers F who are "in the throes of renegotiating software, software support, or/ thinking of augmenting" their current database.   F It's a nice try, but the bottom line is that it's easier to go from anL Oracle database to an Oracle database than it is to go to IBM, regardless of< what good tools IBM has in place to help with the migration.  G As noted to me recently by analysts including Colleen Graham at Gartner F Dataquest and Mike Schiff, vice president of business intelligence and? e-business at Current Analysis, it's tough to change databases.   L Customers look at issues of cost and support before they buy, not at a pointF when support gets taken away for an aging database that's already been! superceded by two major releases.   J True, lots of customers still run successful Oracle8i implementations, butL the fact that Oracle will desupport 8i next year hardly comes as a surprise.H We've seen Oracle9i, Oracle9i Release 2 and Oracle 10g in past years. AsJ Schiff pointed out to me, "You can't expect a company to support something	 forever."   K Not surprisingly, IBM is relying on internal and/or commissioned studies to D back up its assertions that Oracle's support is poorer than its own,  according to an IBM spokeswoman.  G As for independent input, Gartner's Graham noted that she's not hearing I customers complain about spectacularly poor customer support from Oracle. F She's not hearing that the support is stellar, either, but her clients) aren't bellyaching excessively, she said.   K As far as IBM's assertions that Oracle is more expensive, that assertion is G true when you're looking just at the list price. But when you bundle in H Oracle's tools and options and take into consideration costs such as theL training and rebuilding of staff skills that would be required by a database2 migration, the price picture gets decidedly murky.  I Where Oracle gets really interesting with regards to price is, of course, C with what Graham calls Oracle's "Linux story." That's the one where K enterprises run Oracle databases on a cluster of Linux boxes and experience  huge hardware savings.  K Of course, if you do run a cluster, you need Oracle9i RAC (Real Application H Clusters), an option that comes at about a 50 percent premium. "So, it'sG kind of like, yeah, you'll save money on the hardware, but you'll spend $ extra on the software," Graham said.  J The long and short of it is that you have to be leery about both IBM's andL Oracle's claims about their respective rival's support, price and everything- else under the sun. That goes without saying.   K What really needs to be pointed out is that June 28 is the last day you can K lean on Oracle's very hungry sales reps to get major discounts as they wrap  up their fiscal year.   2 Read more here about Oracle's price breaks on 10g.  F If you haven't already, for God's sake, drop everything and twist someK Oracle arm on the last day before the holiday. Don't miss the boat-Graham's 9 clients are reporting discounts of as much as 80 percent.   K That's right, 80 percent. As Graham so eloquently put it, "Up to 80 percent  discounts. That's, like, whoa!"   L Or, as we might rewrite IBM's ad to read, "May Day! May Day! Rescuing Oracle users-from paying high prices!"    ------------------------------  + Date: Sat, 29 May 2004 23:34:44 +0000 (UTC) P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) Subject: datatrieve $ Message-ID: <c9b6mk$s9f$1@online.de>  G I'm updating the layered products on my hobbyist system.  Since I have  G enough disk space, I figure I might as well install stuff I don't need  F now but which might come in handy in the future.  One such product is H DATATRIEVE.  Can someone explain in a nutshell what it does and whether H it is worth learning for someone like myself who has no experience with  it?    ------------------------------  % Date: Sat, 29 May 2004 17:33:14 -0400 # From: "John Smith" <a@nonymous.com> . Subject: Re: HP and Intel Developer Forum 2004, Message-ID: <QO6dnckBbs0EnCTd4p2dnA@igs.net>  J Thanks for the clear explanation Warren. So the easiest solution is for HPI to simply advertise OpenVMS thereby driving traffic to the site and hence 4 'promoting' VMS to the upper level on the DSPP page.  * See...it ALWAYS comes back to advertising.    7 "warren sander" <warren.sander@hp.com> wrote in message $ news:40b79eb0@usenet01.boi.hp.com...L > the links on the dspp home page are based on the number of clicks they get > on the lowerdown pages.  > J > if you click the 'more...' under technologies or the 'technologies' link you  > will see OpenVMS listed. > L > if that link starts getting hits it will migrate to the home page. (please5 > don't just click it for that.. there's more too it) H > but they do move things around. I don't know the exact time frames but this) > is one reason we do collect metrics. So 4 > these movements can be justified based on traffic. > L > And OpenVMS is listed on the Itanium based solutions page also. I do think7 > that in some places on hp.com OpenVMS is slighted but K > DSPP isn't one of them. They are trying but EVERYONE wants their stuff on  as; > close to the top as possible and there is a lot of stuff.  > L > If you find places that OpenVMS should be listed let me know. I can try toL > get with the site owners and get some OpenVMS content in. but then you allH > have to use that content also. Some of the areas of hp.com are old andK > crufty (hey some parts of the OpenVMS web site are old and crufty) but we 6 > all try to get things fixed and promoted correctly.. >  >  > 0 > "John Smith" <a@nonymous.com> wrote in message( > news:mc2dnWES_KM8qyrdRVn-tA@igs.net... > > A > > "Stanley F. Quayle" <squayle@insight.rr.com> wrote in message + > > news:40B67A35.2512.6EE6750@localhost... H > > > Anyone going to this?  Looks like a way to get an Itanium box with > > > VMS cheap: > > > K > > > "As a special offer to a select set of HP and Intel developers, HP is K > > > making the HP Integrity rx2600 server available at an exclusive price  > > > of $2000 USD." > > > E > > > You have to join DSPP (free) and the Intel Early Access Program I > > > (free), but it's not clear what the session costs -- other than the  > > > $2000 for the box. > > > * > > > More info at (sorry about the wrap): > > > L > > > http://h21007.www2.hp.com/dspp/bus/bus_BusDetailPage_IDX/1,1252,6045,0 > > > 0.html > >  > > J > > Also note that when you go to that link and then click on  AdditionalL > > Details on DSPP link (redirects to http://h21007.www2.hp.com/ ), OpenVMS > isJ > > not mentioned on that page but ALL the other operating systems that HP > sells  > > are. > >  > > How bloody typical.  > >  > >  > >  >  >    ------------------------------  # Date: Sat, 29 May 2004 19:53:25 GMT / From: brooks@cuebid.zko.dec.nospam (Rob Brooks) D Subject: long, boring explanation of minicopy (and HBVS, in general)- Message-ID: <AqZWoVHs7m63@cuebid.zko.dec.com>   2 (Phillip Helbig---remove CLOTHES to reply) writes:K > There have been various threads on this topic, but there doesn't seem to  I > be a general consensus about what works, what is the proper behaviour,  # > what is the actual behaviour etc.   H I have been following a bit of these discussions, but not with any greatE detail.  Independent of whether or not there has been any comp.os.vms C consensus about what is the proper behaviour, if you ask a specific C question about perceived behaviour, I'll tell you what the expected 3 behaviour is, assuming a modern version of OpenVMS.   K > I'm still confused about VAX support.  Which of the following situations  F > would benefit from DISMOUNT/POLICY-MINICOPY (assume two VAX and one  > ALPHA node in the cluster):   B A VAX cannot have a minicopy bitmap on it.  A VAX **can** have itsK writes registered on a minicopy bitmap that exists on an Alpha (or Itanium, J for V8.2 and beyond.  The implementation of Host-Based Volume Shadowing onM Itanium **IS IDENTICAL** to that on the Alpha hardware.  The only differences N in the code exist to deal with the differences in the calling standards of the two architectures.)   A In all the examples you give, the only one that could not benefit G from minicopy is the one where the Alpha is shut down.  For the others, H as long as the shadow set is mounted on an Alpha (even if its connectionD is MSCP through a surviving VAX), you can use minicopy.  If a shadowC set is mounted on an Alpha, but its only connection is MSCP through 6 the VAX being shut down, then you cannot use minicopy.  J If this is not clear, please let me know and I'll take another stab at it.  H Also, have you read the manual?  If you have and it is not clear, let meM know that, also.  We think that the manual does a very good job at explaining : this. If we're wrong, we'll clarify whatever is confusing.  ? Note that for V8.2, the shadowing manual has been substantially J modified to account for Host-Based Minimerge (HBMM) and the new copy/mergeF priority scheme that gives a system manager complete control over whatF systems perform merges/copies on each shadow set and in what order theA merges/copies are done.  This merge/copy priority stuff is pretty E useful, we think.  The merge/copy priority scheme will also be in the D HBMM kit for V7.3-2 that will be in field test in about a month, and2 available for production near the end of the year.              --    M Rob Brooks    VMS Engineering -- I/O Exec Group     brooks!cuebid.zko.dec.com    ------------------------------  + Date: Sat, 29 May 2004 19:41:53 +0000 (UTC) P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)H Subject: Re: long, boring explanation of minicopy (and HBVS, in general)$ Message-ID: <c9ap21$bg8$1@online.de>  - In article <AqZWoVHs7m63@cuebid.zko.dec.com>, 2 brooks@cuebid.zko.dec.nospam (Rob Brooks) writes:   4 > (Phillip Helbig---remove CLOTHES to reply) writes:M > > There have been various threads on this topic, but there doesn't seem to  K > > be a general consensus about what works, what is the proper behaviour,  % > > what is the actual behaviour etc.  > J > I have been following a bit of these discussions, but not with any greatG > detail.  Independent of whether or not there has been any comp.os.vms E > consensus about what is the proper behaviour, if you ask a specific E > question about perceived behaviour, I'll tell you what the expected 5 > behaviour is, assuming a modern version of OpenVMS.   H Here, I was referring to something which some people deemed to be a bug F regarding shutting down the job controller during a planned shutdown, 6 which can lead to problems since it keeps a file open.  C > In all the examples you give, the only one that could not benefit I > from minicopy is the one where the Alpha is shut down.  For the others, J > as long as the shadow set is mounted on an Alpha (even if its connection; > is MSCP through a surviving VAX), you can use minicopy.     C Thanks, that clears things up.  So the deciding factor is that the  F shadow set has to be mounted on an ALPHA, regardless of what node the . individual members have direct connections to.  
 > If a shadow E > set is mounted on an Alpha, but its only connection is MSCP through 8 > the VAX being shut down, then you cannot use minicopy.  G In my case, this would only apply to a shadow set with both members on  H the node to be shut down.  This is only the case for my VAX system-disk I shadow sets.  Presumably, the normal shutdown should handle these OK (at  5 least if I dismount them from the other nodes first).   L > If this is not clear, please let me know and I'll take another stab at it.  G I think I've got it now.  I can benefit from MINICOPY if the shadow set > is mounted from an ALPHA.  Do I have to do the dismount of theH shadow-set member from the ALPHA, or could I do it from a VAX?  Say the F shadow set has members on both VAXes, and is mounted on all nodes.  I I want to take down one of the VAXes.  The shadow set will stay mounted on  F the other nodes (and will be dismounted by the VAX being shut down).  E Before starting the shutdown, I have to DISMOUNT/POLICY=MINICOPY the  H member of the shadow set connected to the VAX going down.  Do I have to I do this from the ALPHA, or is it enough that the ALPHA mounts the shadow   set.  J > Also, have you read the manual?  If you have and it is not clear, let meO > know that, also.  We think that the manual does a very good job at explaining < > this. If we're wrong, we'll clarify whatever is confusing.  E I've read the online manual 2 or 3 times actually.  I guess what was  B confusing me was the term "on VAX": does it mean physical members I of the shadow set connected to a VAX, the shadow set mounted on a VAX or  B the DISMOUNT/POLICY=MINICOPY command being issued from a VAX.  :-|  B In my case, it looks like I can benefit a lot, since I can always E benefit when shutting down a VAX.  When the ALPHA goes down, I can't  F benefit from minicopy for the shadow sets for which it hosts a member.H (I will probably add a second ALPHA to the cluster soon, so that should G improve things.)  (I reboot the ALPHA more often, since there are more  H patches for ALPHA.  For this reason, I recently moved my biggest shadow F set (9 GB) to the two VAX nodes, so that I can avoid shadow copies on I rebooting the ALPHA.  This will still make sense with MINICOPY, at least  E as long as there is just one ALPHA in the cluster.  (Reads are a bit  I slower since the SCSI speed on my VAXen is half that on the ALPHa, but I   can live with that.))    ------------------------------  % Date: Sat, 29 May 2004 17:34:58 -0400 # From: "John Smith" <a@nonymous.com> > Subject: Re: More on Processors from May issues of "PROCESSOR", Message-ID: <AZednT2phNKcnyTdRVn-sw@igs.net>  F "Andrew Harrison" <andrew_._remove_harrison@su_n.com> wrote in message* news:c989pj$d2b$1@new-usenet.uk.sun.com... > Barry Treahy, Jr. wrote: > >  > >  > > Rob Young wrote: > > > > >> In article <uMCdnZnxnNOX9CvdRVn-ig@igs.net>, "John Smith" > >> <a@nonymous.com> writes:  > >> > >> > >>H > >>> Doesn't this sound like Intel 'tripping?' Not only is this bad forG > >>> Intel's 32-bit processors, but I cannot see this being 'good' for  > >>> Itanic.. > >>>e > >>>n > >> > >>L > >>     Yeah.  And then financial reality sets in.  AMD cleared $60 millionH > >>     last quarter, Intel cleared $2.5 billion last quarter.  Profits equaliD > >>     to twice AMD's revenues.  Maybe Intel shovels an extra $1002 > >>     million to Itanium just for good measure? > >> > >>L > > Not one for David and Goliath stories?  The same arguments could be saidL > > about pitting Dell against IBM years past, but if you find the right mixC > > at the right time and run with it, well anything is possible...  > >s >sD > The huge irony of Robs post is that Rob was confidently predictingA > that AMD would be hemoraging money now because of a discounting- > onslaught by Intel.- >-B > In fact not only is AMD making money out of processors but their > average cost is increasing.o >eB > Another prediction that Rob got totally and completely wrong but@ > then hey its a long long list and one more isn't going to make > much of an impact is it. >rB > So instead the new spin is that AMD is so tiny that Intel cannot@ > lose all they need to do is pump a bit more into Itanium and a5 > bit more and a bit more and just a little bit more.     I And it seems that a certain small company, HP, is purchasing more than ita ever used to from AMD.  & I wonder how Intel reads that message?   ------------------------------  + Date: Sat, 29 May 2004 18:14:23 +0000 (UTC)wP From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)5 Subject: shutdown of a node, shadow copies and mergesp$ Message-ID: <c9ajtv$6lb$1@online.de>  I There have been various threads on this topic, but there doesn't seem to 1G be a general consensus about what works, what is the proper behaviour, u! what is the actual behaviour etc.D  1 So I just want to contribute an observation.  :-)e  G In my hobbyist cluster, all disks (with one exception not important to 2E the present discussion) are shadow sets.  System disks and swap/page  I disks have both members on one node, otherwise there is a member on each DI of two nodes.  (All have 2 members.)  All shadow sets are mounted by all nI nodes.  All disks are simple SCSI disks, one controller on each machine, h' all MSCP served.  No dual-ported disks.h  A After an unexpected VAX crash, since I had installed some layeredbB products on another VAX and installed some patches on the ALPHA, IF figured a cluster reboot was the best thing to do, taking advantage ofF the opportunity to run AUTOGEN and the two nodes which were still up. H Note that the one VAX had left the cluster abnormally.  I then specifiedE CLUSTER_SHUTDOWN as an option.  The site-specific shutdown doesn't doe any dismounting etc now. r  G As expected, I got a shadow copy on the shadow set with a member on theeD abnormally crashed VAX.  Otherwise, no shadow copies.  (All pairs ofB nodes have a shadow set, except the abnormally crashed VAX and theF ALPHA.)  I got a merge on both VAX system-disk shadow sets, but not onD the ALPHA system-disk shadow set.  I don't really understand this atA all, since the ALPHA and the VAX which stayed in the cluster are  G completely on equal footing.  (None of the nodes has files open on the fC other system disks; I just mount all disks on all nodes, including c3 system disks, to make things easier in SYSMAN etc.)o  H I plan to look seriously into the MINICOPY stuff soon, though of course H this would only help during a clean shutdown.  As I gather, the idea is H to do the DISMOUNT of a shadow-set member with a direct connection to a G node about to be shut down FROM a node which is to stay in the cluster.hI I'm still confused about VAX support.  Which of the following situations 8D would benefit from DISMOUNT/POLICY-MINICOPY (assume two VAX and one  ALPHA node in the cluster):n  &    shadow set members on two VAX nodes         vax node being shut down  )          dismount from the other VAX  (1)s  %          dismount from the ALPHA  (2)p  6    shadow set members split across VAX and ALPHA nodes         vax node being shut down  )          dismount from the other VAX  (3)m  %          dismount from the ALPHA  (4)   .    shadow set split across VAX and ALPHA nodes          alpha node being shut down  8          dismount from VAX hosting the other member  (5)  @          dismount from the other VAX (not hosting a member)  (6)   ------------------------------  % Date: Sun, 30 May 2004 01:09:15 -0400e3 From: "Richard B. Gilbert" <rgilbert88@comcast.net>r7 Subject: Re: VMS721_UPDATE-V0300, 10.5" 6250bpi Magtape40 Message-ID: <qaqdnXnP8pvh8STdRVn-ug@comcast.com>   VAXman- wrote:  N >I arrived home from Nashua, NH after close to a three week stay to a mountian1 >of USnail mail and UPS/FedEx package deliveries.c >tO >Amongst the UPS/FedEx packages was a box from HP sent to me Priority OvernighttO >FedEx.  Its contents:  V721_UPDATE_V0300 (this is almost 2 yrs old is it not?)m" >on a 10.5" 6250 bpi 9 track tape. >"% >There are a couple of problems here:n >r >1. I didn't request this kit.E >2. Priority overnight on the 20th when I was still in NH until 25th.e  >3. I no longer a 9 track drive. >4. I've upgraded to V7.3-2  >.N >I hope that this is no indication that future updates will arrive on magtape. >  r >   C I got one on TK50.  The difference is that I actually ordered one, e@ ALMOST A YEAR AGO, when I couldn't download it from DSNLink.  I I subsequently found an FTP site where I could download it and got on with 3 patching my systems!   ------------------------------   End of INFO-VAX 2004.298 ************************