1 INFO-VAX	Tue, 13 May 2003	Volume 2003 : Issue 263       Contents:9 AS255 models (was: AlphaStation 255/500 power up problem) = Re: AS255 models (was: AlphaStation 255/500 power up problem)  Best practices for VMS Re: Best practices for VMS Re: Best practices for VMS Re: Best practices for VMS Re: Best practices for VMS Re: Best practices for VMS Re: Best practices for VMS Re: can call lib$get_symbol < Re: How Alpha will save Itanium - must reading for Bill Todd3 Re: HP's 'Adaptive Enterprise' advertising campaign 3 Re: HP's 'Adaptive Enterprise' advertising campaign 3 Re: HP's 'Adaptive Enterprise' advertising campaign " Re: INDEX.SYS size and performance; Re: MicroVAX and VAX models EOSL list (end of service life)  Re: next VMS versions  Re: next VMS versions P OpenVMS Pearl - Partner Press release MVP Systems announced usage-based pricing " OSU server questions ( byterange ) Re: simh emulator and cluster  Re: simh emulator and cluster  Re: Spamfilter for OpenVMS?  RE: Spamfilter for OpenVMS?  Re: Spamfilter for OpenVMS?  Re: Spamfilter for OpenVMS? / Sparky is losing the race Andrew ... and badly! 3 Re: Sparky is losing the race Andrew ... and badly! 3 Re: Sparky is losing the race Andrew ... and badly! 3 Re: Sparky is losing the race Andrew ... and badly! 3 Re: Sparky is losing the race Andrew ... and badly! 3 Re: Sparky is losing the race Andrew ... and badly! 3 Re: Sparky is losing the race Andrew ... and badly! 3 Re: Sparky is losing the race Andrew ... and badly! 3 Re: Sparky is losing the race Andrew ... and badly!  Re: Splitting cluster  Status of Commserver product% Stopping a que other then a print que ) Re: Stopping a que other then a print que ) Re: Stopping a que other then a print que ) Re: Stopping a que other then a print que ) Re: Stopping a que other then a print que ) Re: Stopping a que other then a print que 7 Re: What is the schedule for the DII COE certification? 7 Re: What is the schedule for the DII COE certification? 7 Re: What is the schedule for the DII COE certification? 7 Re: What is the schedule for the DII COE certification? 7 Re: What is the schedule for the DII COE certification? 7 Re: What is the schedule for the DII COE certification?   F ----------------------------------------------------------------------  % Date: Mon, 12 May 2003 15:48:02 -0500 / From: Chris Scheers <chris@applied-synergy.com> B Subject: AS255 models (was: AlphaStation 255/500 power up problem)3 Message-ID: <3EC00882.B9735D00@applied-synergy.com>    Alan Boyles wrote: >  > Group: > N > I have just received 2 AlphaStations (a 255/400 and a 255/500) and am havingJ > some problems.  When I try to turn either of the boxes on they will veryI > briefly run, maybe half a second to a second and then shut down.  I was I > thinking power supply but I find it strange that both boxes do the same  > thing.  Any ideas ?  >  > Thanks >  > Alan  G What is an AlphaStation 255/400?  I thought the AlphaStation 255 family  maxed out at 300MHz.  G ----------------------------------------------------------------------- $ Chris Scheers, Applied Synergy, Inc.  C Voice: 817-237-3360            Internet: chris@applied-synergy.com     Fax: 817-237-3074    ------------------------------  % Date: Mon, 12 May 2003 19:08:04 -0400 0 From: "Alan Boyles" <alan.boyles@mindspring.com>F Subject: Re: AS255 models (was: AlphaStation 255/500 power up problem)/ Message-ID: <vc0a8vt0qrub9d@corp.supernews.com>   I Nope, this is a Alphastation 500/500 and it maxes out at 320.  I actually ' have found the part number 30-45491-03.    Alan< "Chris Scheers" <chris@applied-synergy.com> wrote in message- news:3EC00882.B9735D00@applied-synergy.com...  > Alan Boyles wrote: > > 
 > > Group: > > I > > I have just received 2 AlphaStations (a 255/400 and a 255/500) and am  havingL > > some problems.  When I try to turn either of the boxes on they will veryK > > briefly run, maybe half a second to a second and then shut down.  I was K > > thinking power supply but I find it strange that both boxes do the same  > > thing.  Any ideas ?  > > 
 > > Thanks > >  > > Alan > I > What is an AlphaStation 255/400?  I thought the AlphaStation 255 family  > maxed out at 300MHz. > I > ----------------------------------------------------------------------- & > Chris Scheers, Applied Synergy, Inc. > D > Voice: 817-237-3360            Internet: chris@applied-synergy.com >   Fax: 817-237-3074    ------------------------------    Date: 12 May 2003 11:50:28 -0700+ From: c00per11242001@yahoo.ca (Vic Mendham)  Subject: Best practices for VMS = Message-ID: <f7a73cb1.0305121050.22a7812a@posting.google.com>   8 Just wondering if anyone has any best practices for VMS?F Things like reset the operator.log once a day or once a week or month.- Reset account.dat once a day, week, or Month. 2 Reset the security logs once a day, week or month.* Disk space not to be allowed over 80% usedB Create a backup copy of the sysuaf file, incase the production one gets corrupted. F always (if budgets allow) carry a spare system disk (offline), and use	 backup to  copy once a week.   E Specifically, I'm looking for which files to be reset, and how often. E I realize this my depend on the adminsitrator or on the system usage.  But does anyone have anything?  C Also does anyone have a script which would create a new copy of the D security audit file once a day or week and rename it to -1 or old or with the date?   Regards    ------------------------------  % Date: Mon, 12 May 2003 16:11:06 -0400 ! From: Jim Agnew <jpagnew@vcu.edu> # Subject: Re: Best practices for VMS ' Message-ID: <3EBFFFDA.595E1B54@vcu.edu>   D Monthly is what we aim for...  most of our stuff has monthly jobs to rotage the logfiles...     Vic Mendham wrote: > : > Just wondering if anyone has any best practices for VMS?H > Things like reset the operator.log once a day or once a week or month./ > Reset account.dat once a day, week, or Month. 4 > Reset the security logs once a day, week or month., > Disk space not to be allowed over 80% usedD > Create a backup copy of the sysuaf file, incase the production one > gets corrupted. H > always (if budgets allow) carry a spare system disk (offline), and use > backup to  > copy once a week.  > G > Specifically, I'm looking for which files to be reset, and how often. G > I realize this my depend on the adminsitrator or on the system usage.   > But does anyone have anything? > E > Also does anyone have a script which would create a new copy of the F > security audit file once a day or week and rename it to -1 or old or > with the date? > 	 > Regards    --  F "4,000 years ago I made a mistake."  Elrond Half-Elven, in "Fellowship of the Ring"   ------------------------------  % Date: Mon, 12 May 2003 17:54:43 -0500 ( From: brandon@dalsemi.com (John Brandon)# Subject: Re: Best practices for VMS 1 Message-ID: <03051217544365@dscis6-0.dalsemi.com>   : > Just wondering if anyone has any best practices for VMS?  4 I have monitor utilities that perform the following:  , 1) monitor disks for low space (page, opcom)+ 2) monitor queues for errors  (page, opcom)  3) monitor errors (page, opcom) ' 4) monitor SET /INT for 0 (page, opcom)   . I rename & ZIP system files (after reporting):  ! 5) ERRLOG & OPCOM weekly (e-mail) % 6) AUDIT & ACCOUNTNG monthly (e-mail)   * Other reporting mechanisms (daily, weekly)  / 7) Search null printers for 0 block print jobs, 6 print jobs that have errors for one reason or another,& and report findings to users. (e-mail): 8) Search disk roots for SYSLOST and make sure they exist,2 also report files in SYSLOST directories. (e-mail)* 9) ANALYZE /DISK /REPAIR nightly. (e-mail)E 10) Search disks for files exceeding version limit of 20,000 (e-mail) H 11) Duplicate directories search (not that this is a bad thing) (e-mail). 12) DUMP /HEADER report for all disks (e-mail)I 13) DIRECTORY /GRAND of files of all disks looking for top users/abusers.   G All of these items are automated and report to the admin team by OPCOM, I e-mail, or page - dependent on the severity of the problem.  DECevent and N Compaq Analyze can also be used for this - with a valid license (for reporting
 purposes).  H > Things like reset the operator.log once a day or once a week or month./ > Reset account.dat once a day, week, or Month. 4 > Reset the security logs once a day, week or month., > Disk space not to be allowed over 80% used  N For Storage Arrays with cache - the 80% rule (under certain circumstances) can be tossed - sometimes.  D > Create a backup copy of the sysuaf file, incase the production one > gets corrupted.   L Good idea.  May include other system files like PCSI database, DECnet, TCPIP files, etc.   H > always (if budgets allow) carry a spare system disk (offline), and use > backup to  > copy once a week.   1 Offsite backup save-set of system disks and data.   G > Specifically, I'm looking for which files to be reset, and how often. G > I realize this my depend on the adminsitrator or on the system usage.   > But does anyone have anything?   OPCOM, AUDIT, ACCOUTNG, ERRLOG.   E > Also does anyone have a script which would create a new copy of the F > security audit file once a day or week and rename it to -1 or old or > with the date?   Yes./ Also look at WIS (DSN) and do a Tech Search for , Methods Used To Recover Space On System Disk       John Brandon VMS Systems Administrator  Dallas Semiconductor first.last@dalsemi.com 972.371.4172 wk    ------------------------------  % Date: Mon, 12 May 2003 19:03:33 -0500 1 From: "David J. Dachtera" <djesys.nospam@fsi.net> # Subject: Re: Best practices for VMS ' Message-ID: <3EC03655.786FE31F@fsi.net>    John Brandon wrote:  > [snip]) > 4) monitor SET /INT for 0 (page, opcom)   2 F$GETSYI( "IJOBLIM" ) returns the current setting.  0 > I rename & ZIP system files (after reporting): > # > 5) ERRLOG & OPCOM weekly (e-mail) ' > 6) AUDIT & ACCOUNTNG monthly (e-mail)  > , > Other reporting mechanisms (daily, weekly) > 1 > 7) Search null printers for 0 block print jobs,   # What's a "null printer"? (NULSYMB?)   8 > print jobs that have errors for one reason or another,( > and report findings to users. (e-mail)< > 8) Search disk roots for SYSLOST and make sure they exist,   Should never need them.   4 > also report files in SYSLOST directories. (e-mail)  3 Should never exist. If they do, fix the program(s).   , > 9) ANALYZE /DISK /REPAIR nightly. (e-mail)  D I *REALLY* don't like that one. Unless there's an app.'s misbehaving@ seriously that can't be fixed, I'd think *REAL* hard about that!  F You do know that VERIFY can do things you don't necessarily want it to do when run automated, right?   D This also keeps each volume locked for the duration. Can cause other processes to fail (timeout).  G > 10) Search disks for files exceeding version limit of 20,000 (e-mail) J > 11) Duplicate directories search (not that this is a bad thing) (e-mail)    What is a "duplicate directory"?  0 > 12) DUMP /HEADER report for all disks (e-mail)   What does that do?  D All together, what's the machine consumption in terms of I/O and CPU# cycles as compared to the benefits?    --   David J. Dachtera  dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------  % Date: Mon, 12 May 2003 19:36:41 -0500 ( From: brandon@dalsemi.com (John Brandon)# Subject: Re: Best practices for VMS 1 Message-ID: <03051219364177@dscis6-0.dalsemi.com>   3 > > 7) Search null printers for 0 block print jobs,  > % > What's a "null printer"? (NULSYMB?)   O We have users that print to sys$print - which is sometimes not defined.  Rather L than spit it out to a physical printer, we leave it in the queue and the jobM forwards the print job back to the user with a message stating the reason for 	 doing so.   / > >  9) ANALYZE /DISK /REPAIR nightly. (e-mail)  > F > I *REALLY* don't like that one. Unless there's an app.'s misbehavingB > seriously that can't be fixed, I'd think *REAL* hard about that!   (I figured you would not) F I have had not problems with this.  I started this out of a problem weK encountered with VAX VMS 5.5 (?) that caused our boot device to show out of N space.  Colorado stated I needed to ANA/DIS/REP to fix the problem.  They also5 suggested that I should do this on a scheduled basis.   H > You do know that VERIFY can do things you don't necessarily want it to > do when run automated, right?   % Yes I do and I have thought about it.   F > This also keeps each volume locked for the duration. Can cause other > processes to fail (timeout).  I My disks are relatively small in size (8-GB to 20-GB) and on a GS160 with G 12-CPU this really is not a problem.  Typicall files that are found are 	 mail.mai.   " > What is a "duplicate directory"?  L Different disks sometimes would have the same directory.  Not that this is aJ problem, however if we moved a user from one disk to another and forget toN cleanup - or development created multiple directories for testing, we could go back and clean them up.     2 > > 12) DUMP /HEADER report for all disks (e-mail) >  > What does that do?  9 Determine the severity of extents of the disk header file   6 $ dump /header /block=count:0 device: /output=file.txt* $ search file.txt "Map area words in use:"  F > All together, what's the machine consumption in terms of I/O and CPU% > cycles as compared to the benefits?   W Impact is very minimal.  Heavy hitters are run once a week.  The machine I have is more L than capable to perform this.  In addition, I do not mind paying a little upL front to avoid late night gotchas.  And since it is an automated (reporting)/ mechanism, I do not need to run these manually.    John Brandon VMS Systems Administrator  Dallas Semiconductor first.last@dalsemi.com 972.371.4172 wk    ------------------------------  % Date: Mon, 12 May 2003 20:38:16 -0500 1 From: "David J. Dachtera" <djesys.nospam@fsi.net> # Subject: Re: Best practices for VMS ' Message-ID: <3EC04C88.18352388@fsi.net>    John Brandon wrote:  > [snip] > $ > > What is a "duplicate directory"? > N > Different disks sometimes would have the same directory.  Not that this is aL > problem, however if we moved a user from one disk to another and forget toP > cleanup - or development created multiple directories for testing, we could go > back and clean them up.   @ Active development environments can have the same directory treeG repeated many times under different upper-level directories on the same F spindle or volume-set. Sometimes they need to compare results based on% multiple variations of the same code.   4 > > > 12) DUMP /HEADER report for all disks (e-mail) > >  > > What does that do? > ; > Determine the severity of extents of the disk header file  > 8 > $ dump /header /block=count:0 device: /output=file.txt, > $ search file.txt "Map area words in use:"   DFU does this, also.   DJAS01::DDACHTERA$ sh def    DKA0:[DDACHTERA]# DJAS01::DDACHTERA$ dfu report dka0:   1      Disk and File Utilities for OpenVMS DFU V2.7       Freeware version 1      Copyright  2000 COMPAQ Computer Corporation   0 %DFU-I-REPORT, Reporting on DKA0: (DJAS01$DKA0:)  E       ***** Volume info for ODS2 volume DKA0: (from HOME block) ***** 1  Volume name                      :  DRIVE000     1  Volume owner                     :               1  Volume set name                  :               -  Highwater mark. / Erase on del.  :  Yes / No &  Cluster size                     :  4+  Maximum # files                  :  411048 *  Header count                     :  16390(  First header VBN                 :  118)  Free headers                     :  7212   3       ***** File Statistics (from INDEXF.SYS) ***** ;  INDEXF.SYS fragments/ map_in_use :  4 /10 words ( 6% used) -  Total files (ODS2 / ODS5)        :  9158 / 0 '  Empty files                      :  45 )  Files with allocation            :  9113 &  Files with extension headers     :  0&  Files marked for delete          :  0(  Directory files                  :  314)  Contiguous files                 :  8914 5  Total used/ allocated size       :  3393577 /3481060 )  Total fragments                  :  9606 *  Average fragments per file       :  1.0548  File fragmentation index         :  0.118  (excellent) (  Average size per fragment        :  362$  Most fragmented file             : G     DJAS01$DKA0:[DDACHTERA]SEMINAR1024-2002.ZIP;1 ( 14872/14872 blocks;  43 fragm ents)   9       ***** Free space statistics (from BITMAP.SYS) ***** ,  Total blocks on disk             :  4110480+  Total free blocks                :  629420 '  Percentage free (rounded)        :  15 (  Total free extents               :  155B  Largest free extent              :  53048  blocks at LBN: 2719552)  Average extent size (rounded)    :  4060 8  Free space fragmentation index   :  0.098  (excellent)   " %DFU-I-READY, REPORT command ready   --   David J. Dachtera  dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------  % Date: Mon, 12 May 2003 23:50:26 -0400   From: John Santos <JOHN@egh.com># Subject: Re: Best practices for VMS 5 Message-ID: <1030512234729.2916H-100000@Ives.egh.com>   " On 12 May 2003, Vic Mendham wrote:  : > Just wondering if anyone has any best practices for VMS?H > Things like reset the operator.log once a day or once a week or month./ > Reset account.dat once a day, week, or Month. 4 > Reset the security logs once a day, week or month., > Disk space not to be allowed over 80% usedD > Create a backup copy of the sysuaf file, incase the production one > gets corrupted. H > always (if budgets allow) carry a spare system disk (offline), and use > backup to  > copy once a week.  > G > Specifically, I'm looking for which files to be reset, and how often. G > I realize this my depend on the adminsitrator or on the system usage.   > But does anyone have anything? > E > Also does anyone have a script which would create a new copy of the F > security audit file once a day or week and rename it to -1 or old or > with the date? > 	 > Regards   B I wonder if Dave Miller's rev of Hoff's update of the Baldwin book will cover this?   --   John Santos  Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------  % Date: Mon, 12 May 2003 15:02:40 -0400 * From: JF Mezei <jfmezei.spamnot@istop.com>$ Subject: Re: can call lib$get_symbol) Message-ID: <3EBFEFCE.6BF90B46@istop.com>    Kesav Tadimeti wrote:  >  > Hello all,2 > I have a small C program to call lib$get_symbol.N > The program while compiling can't find where lib$get_symbol is defined. What > header file am I missing?   M You are not missing any header file. On VAX, they didn't deem it necessary to ) define the uppercase versions of the rtl.    so you need:   #include <lib$routines.h>  #ifdef _VAX $ #define LIB$GET_SYMBOL lib$getsymbol #endif  ; and for the SYS$ routines, you need to #include <starlet.h>   L On Alpha, those modules define both the uppsercase and lowercase versions of4 the routines, but on vax only the lowercase version.   ------------------------------  % Date: Mon, 12 May 2003 22:30:39 -0400 * From: "Bill Todd" <billtodd@metrocast.net>E Subject: Re: How Alpha will save Itanium - must reading for Bill Todd 2 Message-ID: <Ce6cnTny1LlPxV2jXTWcoQ@metrocast.net>  4 "David Svensson" <icerq4a@spray.se> wrote in message7 news:734da31c.0305120650.5e184985@posting.google.com... 9 > "Bill Todd" <billtodd@metrocast.net> wrote in message > K > > The new Madison TPC-C result *is* on the next-gen box, Rob:  it's using  the L > > new Pinnacles chipset, and you'll be able to buy one this summer (though why ? > > you'd want to is not clear, given this first glimpse of its 
 performance).  > >  > = > The Superdome is a nice machine with very good performance,   L Unless you're simply saying that you're happy with your own SuperDome (whichJ is nice for you, but not particularly useful information for others), thatE statement doesn't exist in a vacuum but implies comparison with other K options.  The only information I've seen on the new SuperDome suggests that C its performance (and particularly its per-processor performance) is H decidedly inferior to the large new p-Series IBM boxes (my guess is thatH it's also inferior to Marvel boxes in large configurations, but we don'tL have any data on that front), but if you have other data to put forward that' tend to suggest otherwise please do so.     and I know # > many who would like to buy these.   K Many people would like to buy lots of things.  But what counts is what they , actually end up laying out cash to purchase.  "  You don't have to be number 1 all > the time!   J But it helps if you're trying to convince people to migrate away from what/ has been the #1 platform, as Alpha's vendor is.   :  Companies which replace a 4 year old high-end server will8 > get a good increase in performance with the Superdome.  I Unless they're completely ignorant of the competition or locked into that K platform, the more relevant question is whether they can get an even better , increase in performance from something else.   - bill   ------------------------------    Date: 12 May 2003 15:55:56 -0500; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) < Subject: Re: HP's 'Adaptive Enterprise' advertising campaign3 Message-ID: <lR5qpOOzmBzz@eisner.encompasserve.org>   k In article <vbvjfijloh5o94@corp.supernews.com>, "gregc at gregcagle.com" <"gregc at gregcagle.com"> writes: A > Lots of people have products not based on their own technology. % > Even Sun. Is that such a bad thing?   A    You mean Sun didn't invent UNIX, TCP/IP, and 68000 processors?    ------------------------------  % Date: Mon, 12 May 2003 17:55:16 -0400 $ From: anonymous <anonymous@null.dev>< Subject: Re: HP's 'Adaptive Enterprise' advertising campaign( Message-ID: <3EC01840.DD085753@null.dev>   Bob Koehler wrote:C >    You mean Sun didn't invent UNIX, TCP/IP, and 68000 processors?   M No, it was IBM that invented Unix. (this is what a brainwashed bank senior VP  had told me :-)    ------------------------------  % Date: Mon, 12 May 2003 18:47:03 -0500 1 From: "David J. Dachtera" <djesys.nospam@fsi.net> < Subject: Re: HP's 'Adaptive Enterprise' advertising campaign& Message-ID: <3EC03277.5FF4C57@fsi.net>   Bob Koehler wrote: > m > In article <vbvjfijloh5o94@corp.supernews.com>, "gregc at gregcagle.com" <"gregc at gregcagle.com"> writes: C > > Lots of people have products not based on their own technology. ' > > Even Sun. Is that such a bad thing?  > C >    You mean Sun didn't invent UNIX, TCP/IP, and 68000 processors?   ' Those are Gore-isms, don't ya know? ;-)    --   David J. Dachtera  dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------  % Date: Mon, 12 May 2003 18:44:33 -0500 1 From: "David J. Dachtera" <djesys.nospam@fsi.net> + Subject: Re: INDEX.SYS size and performance ' Message-ID: <3EC031E1.C91BC4BB@fsi.net>    "Alan E. Feldman" wrote: > b > "David J. Dachtera" <djesys.nospam@fsi.net> wrote in message news:<3EBC527E.3083807B@fsi.net>... > > "Alan E. Feldman" wrote: > > > g > > > brandon@dalsemi.com (John Brandon) wrote in message news:<03050908582736@dscis6-0.dalsemi.com>...  > [...] O > > > > > Now, while it may still be a good idea to estimate the largest number N > > > > > of file extents you ever expect to have on the disk and set /HEADERSI > > > > > to that number, there is much less need to worry about actually O > > > > > running out of space in the file header for INDEXF.SYS because of the 2 > > > > > new extension algorithm mentioned above. > > > > R > > > > True.  However taking a little time to determine the needs for the disk isT > > > > always a good idea.  And the initial creation of the disk is a lot less time > > > I > > > Agreed, as I already said above. I guess I should have said that at H > > > least it's not like the VMS .LE. v5 days in which this problem wasH > > > much more likely to happen. I found that with the old algorithm ofK > > > extending INDEXF.SYS in chunks of 1000 blocks that you'd be likely to L > > > get the HEADERFULL problem when you reached about 50000 blocks on yourD >                                                       ^^^^^^^^^^^^ > 9 > Uh, make that approx. 50000 *files*, not blocks. Sorry.  >  > > > disk.  > > H > > ...depending upon the values of /MAXFILES and /HEADERS at INITIALIZEI > > time, and depending on how fragmented INDEXF.SYS has become (i.e., is , > > the extent map in the header full yet?). > G > I should have mentioned that for the 50000-file header-fillup rule of D > thumb I was talking about disks that were INIT-ed with the defaultH > value for /HEADERS, which IIRC is, or at least back then was, 16 (withE > the default value for /MAXIMUM_FILES). I would think that since the F > new algorithm extends INDEXF.SYS in bigger, and hence fewer, chunks,> > the file header for INDEXF.SYS would not fill up as quickly.  D ...unless the disk gets very full and/or freespace becomes extremelyG fragmented. Then, even INDEXF.SYS can only be given whatever small free H space fragments are available. Better to pre-extend it (where possible).   --   David J. Dachtera  dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------  # Date: Tue, 13 May 2003 03:16:35 GMT ! From: rob.buxton@wcc.spam.govt.nz D Subject: Re: MicroVAX and VAX models EOSL list (end of service life)% Message-ID: <3ec06334.112685803@news>   , On 10 May 2003 03:28:22 GMT, "Zane H. Healy"# <healyzh@shell1.aracnet.com> wrote: E What is also quite interesting is that the 4000-705A has gone EOL but  the 4000-700A has not.5 Your comment about parts availability may be spot on.     ( >Rich Jordan <jordan@ccs4vms.com> wrote:H >> We have some very unhappy customers as a result of this; they've beenH >> paying good money for support on top of hefty dollars on the originalC >> purchases, and do not like the direction HP is taking with these B >> really not _that_ old systems, given the history of longer term >> support in the past...  > K >While I agree that this stinks, I'm wondering, how much of this is becuase D >they no longer have the parts to provide service on these systems?  > K >Of course if that is the case, then the question would be, how much of the L >reason for that is Compaq dumping the contents of numerous DEC warehouses a >few years ago?  >  >			Zane   ------------------------------  % Date: Mon, 12 May 2003 15:06:05 -0400 * From: JF Mezei <jfmezei.spamnot@istop.com> Subject: Re: next VMS versions) Message-ID: <3EBFF09B.26C0883F@istop.com>    Maarten van Tilburg wrote:G > Yes, there is VAX 7.3 , and no, there will not be VAX7.3-x AFAIK, not  > many ECO's to install either.   G Does VAX 7.3 actually add any new features, or is is just a maintenance 0 release to ensure interoperatbility with Alpha ?  H I get the feeling that 7.2 is the last version of VAX-VMS to incorporateU usable new features. The gap between VAX and alpha is widening with ever new version.    ------------------------------    Date: 12 May 2003 15:59:15 -0500; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler)  Subject: Re: next VMS versions3 Message-ID: <3y1z35fV0Ysv@eisner.encompasserve.org>   V In article <3EBFF09B.26C0883F@istop.com>, JF Mezei <jfmezei.spamnot@istop.com> writes: > Maarten van Tilburg wrote:H >> Yes, there is VAX 7.3 , and no, there will not be VAX7.3-x AFAIK, not  >> many ECO's to install either. > I > Does VAX 7.3 actually add any new features, or is is just a maintenance 2 > release to ensure interoperatbility with Alpha ? > J > I get the feeling that 7.2 is the last version of VAX-VMS to incorporateW > usable new features. The gap between VAX and alpha is widening with ever new version.   F    I don't have the release notes handy, but I don't recall being ableF    to mount ODS-5 disks (served by an Alpha) or see the files on a VAX    prior to 7.3.   ------------------------------    Date: 12 May 2003 11:10:32 -07001 From: susan_skonetski@hotmail.com (Sue Skonetski) Y Subject: OpenVMS Pearl - Partner Press release MVP Systems announced usage-based pricing  < Message-ID: <857e9e41.0305121010.6478a61@posting.google.com>  F ______________________________________________________________________G Columbus, Ohio - May 12, 2003 - Today MVP Systems announced usage-based A pricing starting with a FREE upgradeable license for its JAMS job ' scheduling software running on OpenVMS.   C "We are committed to providing software that takes advantage of the F strength of OpenVMS at a price point that is affordable for everyone,"H said John Vottero, Vice President of Development for MVP Systems. "We'veG also made it easier to get started with JAMS by providing full download " from our website - www.mvpsi.com."  D Flexible usage-based pricing gives customers the ability to react toF change and acquire the right functionality to support mission criticalH execution of hundreds or thousands of jobs. Vottero explained, "IndustryE trends show that customers are moving towards just-in-time-buying and ? our pricing has been adjusted to meet this demand. It gives our E customers the ability to purchase the right product at the right time 6 and to grow with the product as their needs increase."  F The Job Access and Management System (JAMS) provides enterprise class,H cross platform, job-scheduling capabilities. It gives those in charge ofC operations as well as the general end-user, the ability to request, E monitor and control the processing of batch jobs. JAMS can completely E automate and integrate data center processing leading to a completely  lights-out operation.   E "JAMS is the first product to be offered under this pricing strategy. ? Based on the success of the JAMS offering we hope to have other 9 usage-based software released by year end," said Vottero.     F With thirteen years of research and development behind it, JAMS is theC most reliable and feature-rich job scheduling product on the market H today. JAMS automates the entire life cycle of batch job processing, and< combines the batch processes of various sources - end users,A applications and operating systems - into one manageable business  process.F The complexities associated with running a professionally managed dataC center are significantly reduced by using JAMS to schedule jobs and H integrate applications. Through its robust job scheduling features, JAMSF integrates complex business processes across multiple applications andE platforms and provides an easy way for different applications to work E together. By scheduling specific tasks to be run in a specific order, H JAMS allows IT organizations to implement business processes that depend> on multiple tasks across different applications while managingF dependencies between platforms so that business processes flow without
 interruption. H Traditional job scheduling systems help manage regularly scheduled batchF jobs. One of the strengths of JAMS is that it also helps manage ad hoc@ jobs, jobs which are run only when needed. While the end-user is? responsible for requesting the job and providing values for the F parameters, JAMS still schedules the job based upon the job and system6 definitions which are maintained by the IT department.  ? JAMS is scalable, tightly integrated with the operating system, H customizable, and yet is ready to provide benefits right-out-of the box.G It is easy to implement because implementation can be done in phases, a < job at a time. JAMS can be used as is, or customized to meetE organizational needs without the worry that future JAMS upgrades will D displace the work already completed. Properly implemented, JAMS willA both enhance and simplify batch scheduling which increases system 0 reliability and lowers total cost of operations.  C MVP Systems was founded in 1988 to develop, JAMS, a world-class job F scheduling system, for the OpenVMS operating system.  For more than 13E years MVP and its partners have successfully marketed JAMS throughout 0 the United States, Canada, Australia and Europe.  D Further Information on JAMS, and Usage-based Pricing is available at http://www.mvpsi.com.    ------------------------------  % Date: Mon, 12 May 2003 16:34:07 -0400 * From: JF Mezei <jfmezei.spamnot@istop.com>+ Subject: OSU server questions ( byterange ) ) Message-ID: <3EC0053D.4DCB08BF@istop.com>M  H (sorry to post here, but the subscription process for the OSU web serverJ mailing list seems broken/unmanned, so I can't send to it, having recently changed email).m  C I experienced a problem serving certain PDF documents.  The defaultcN HTTP_PREFIXES.CONF file contains a presentation line for PDF which make use of  the "byterange.exe" CGI program.  U It sometimes generates a RMS-F-WER file write error towards the end of its execution.r  H Before I investigate this further, is this still needed ? has OSU (3.10)M gotten built-in byterange handling or does it still require an external "plugr in" to handle this ?  K Also, while I am at it. That same file contains a definition for XBM bitmape images (image/x-xbm)J This seems to work (to my susprise) on netscape on a mac with an xbm imageN actually displayed. However, going to www.iana.org, the official list of media# types does not include image/x-xbm.   F Does anyone know if the IANA list is complete ? Just curious as to whyM image/x-xbm would have been used by netscape on mac and by dave jones when heyO setup the OSU server if this format is not on the official lists of mime types..   ------------------------------  % Date: Mon, 12 May 2003 14:56:47 -0400p* From: "Stanley F. Quayle" <stan@stanq.com>& Subject: Re: simh emulator and cluster. Message-ID: <3EBFB62F.13572.B43FD81@localhost>  1 On 11 May 2003 at 22:12, David J. Dachtera wrote: J > Please approach this with great caution until you have made very certain5 > that there is no danger to your production systems.   F I concur.  Once your SIMH machine enters the cluster, it must respond C promptly to all cluster messages.  You might hack SYSGEN parameter tE RECNXINTERVAL bigger on all cluster members, but that would make any r cluster transition longer.  D One downside of how SIMH works is that it puts the Ethernet adapter F into promiscious mode.  This means the adapter will "hear" absolutely D everything on the network, and the host system will have to process A each message.  If that process "falls behind", you will have big CE problems.  The inevitable cluster failure might be the worst of your iD problems.  [Shameless commercial plug:  CHARON-VAX doesn't do this.]  D A work-around would be to install a second Ethernet adapter on your D system and configure SIMH to use that adapter.  Make sure your host F doesn't start any other services on that adapter, and put it behind a @ switch or router that filters all the non-SCS traffic.  This is F easier said than done, however, since most switches and routers don't  know anything about SCS.  F As for having the cluster members use the host's disk space, you will C have to serve a bunch of disk images from SIMH.  Only those images o@ you share will be visible to the cluster members, and cannot be  combined into a single volume.  > Might I suggest a better idea?  I assume that you have TCP/IP  installed on these VMS systems.h  A Instead of emulating a VAX, why not use NFS to serve your host's -A entire disk to the VMS systems?  I do this myself, using a Linux iF system to serve a 130 GB disk for my VMS cluster (both VAX and Alpha)  to use for backups, etc.  F If you mount the disk correctly, using the /ADF=CREATE parameter, you E can have the VMS systems use the NFS share and they'll create hidden rD files which preserve the VMS file characteristics.  All you need to A do is to configure in the NFS client on the VMS systems, and you e should be good to go.n  
 --Stan Quaylea Quayle Consulting Inc.  
 ----------C Stanley F. Quayle, P.E. N8SQ  +1 614-868-1363  Fax: +1 614 868-1671i1 8572 North Spring Ct. NW, Pickerington, OH  431473= Preferred address:  stan@stanq.com       http://www.stanq.comr   ------------------------------  % Date: Mon, 12 May 2003 21:57:28 +02000+ From: "Hans Vlems" <hvlems.nieuw@zonnet.nl>I& Subject: Re: simh emulator and cluster5 Message-ID: <b9ouba$lekmn$1@ID-143435.news.dfncis.de>e  2 "bayden cline" <bayden@isys.ca> schreef in berichtD news:%Vxva.179219$kYH.136688@news01.bloor.is.net.cable.rogers.com...J > I am wondering if i can add a vax running in a simh emulator on my pc to the/I > vax cluster that we have working in the office and have the vax cluster  abelL > to use it the emulators disk space.  all machines involved are running VMS& > 6.2.  Thanks in advance for any help >8 > bayden >  >  > G That will work with the simh versions that support ethernet. I booted a-K microVAX 3100-10e from a simh boothost that ran VMS 7.2. DECnet was used as1+ the cluster communication protocol carrier.i But it is not fast.-   ------------------------------  % Date: Mon, 12 May 2003 17:52:17 -0500 - From: Hunter Goatley <goathunter@goatley.com>l$ Subject: Re: Spamfilter for OpenVMS?7 Message-ID: <9qVva.8482$gI5.40@fe02.atl2.webusenet.com>e   Larry Kilgallen wrote: > I > Will what you are developing allow a Reject in cases where the username L > does not exist ?  I understand the RFCs allow for Bounces to be generated,F > but those are counterproductive in this age of generally forged spam
 > origins.  3 That's one of the things we're planning to do, yes.o  A > Will what you are developing provide for a Teergrubing defense, B > or provide callouts for customers to mount their own Teergrubing > defense ?n  ? As I understand it, that's a function of the SMTP server, whicho? V1 of our product won't have.  I also don't quite see the point1= of these things, other than to have some fun at the spammer's-= expense---but unless I'm missing something (which is entirelyg< possible, since I'd never heard of this before), I don't see: how it's going to make much difference in the overall spam issue.   Hunter ------9 Hunter Goatley, Process Software, http://www.process.com/  goathunter@goatley.com   ------------------------------  % Date: Mon, 12 May 2003 16:29:11 -0700 # From: "Tom Linden" <tom@kednos.com> $ Subject: RE: Spamfilter for OpenVMS?9 Message-ID: <CIEJLCMNHNNDLLOOGNJIIENJHCAA.tom@kednos.com>a   >-----Original Message-----a5 >From: Hunter Goatley [mailto:goathunter@goatley.com]o# >Sent: Monday, May 12, 2003 3:52 PMd >To: Info-VAX@Mvb.Saic.Com% >Subject: Re: Spamfilter for OpenVMS?  >r >y >Larry Kilgallen wrote:u >>  J >> Will what you are developing allow a Reject in cases where the usernameC >> does not exist ?  I understand the RFCs allow for Bounces to be   >generated, G >> but those are counterproductive in this age of generally forged spame >> origins.  >c4 >That's one of the things we're planning to do, yes. >dB >> Will what you are developing provide for a Teergrubing defense,C >> or provide callouts for customers to mount their own TeergrubingE >> defense ? > @ >As I understand it, that's a function of the SMTP server, which@ >V1 of our product won't have.  I also don't quite see the point> >of these things, other than to have some fun at the spammer's> >expense---but unless I'm missing something (which is entirely= >possible, since I'd never heard of this before), I don't seei; >how it's going to make much difference in the overall spama >issue.   @ See  http://www.iks-jena.de/mitarb/lutz/usenet/teergrube.en.html   >p >Hunterm >------n: >Hunter Goatley, Process Software, http://www.process.com/ >goathunter@goatley.com  >) >R >---' >Incoming mail is certified Virus Free.T; >Checked by AVG anti-virus system (http://www.grisoft.com).eA >Version: 6.0.476 / Virus Database: 273 - Release Date: 4/24/2003s >a ---e& Outgoing mail is certified Virus Free.: Checked by AVG anti-virus system (http://www.grisoft.com).@ Version: 6.0.476 / Virus Database: 273 - Release Date: 4/24/2003   ------------------------------    Date: 12 May 2003 19:42:22 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen)o$ Subject: Re: Spamfilter for OpenVMS?3 Message-ID: <RKU3UpH+yxZj@eisner.encompasserve.org>)  g In article <9qVva.8482$gI5.40@fe02.atl2.webusenet.com>, Hunter Goatley <goathunter@goatley.com> writes:p > Larry Kilgallen wrote: >> eJ >> Will what you are developing allow a Reject in cases where the usernameM >> does not exist ?  I understand the RFCs allow for Bounces to be generated,nG >> but those are counterproductive in this age of generally forged spam  >> origins.k > 5 > That's one of the things we're planning to do, yes.. > B >> Will what you are developing provide for a Teergrubing defense,C >> or provide callouts for customers to mount their own Teergrubing  >> defense ? > A > As I understand it, that's a function of the SMTP server, which)  C Hmmm, if you are not in a position to do Teergrubing (regardless oflA whether or not you choose to do it) it seems to me you are not in D a position (in handling incoming SMTP) to Reject rather than Bounce.  A > V1 of our product won't have.  I also don't quite see the pointe? > of these things, other than to have some fun at the spammer'ss? > expense---but unless I'm missing something (which is entirely > > possible, since I'd never heard of this before), I don't see< > how it's going to make much difference in the overall spam > issue.  ? My question quite honestly was to learn the intentions of those ? designing the product, not to lobby for a different focus.  Butu> since you raise the issue of the effectiveness of Teergrubing, let me say:d  6 	Teergrubing consumes resources of the sending system,6 	be it a machine owned by the spammer or an open relay6 	complicit in delivering the spam.  To the extent that6 	spam victims can spare the (lower) resources to delay8 	their attackers, I think that is a good idea.  It keeps8 	the spammer from proceeding quickly to the next victim.  = That said, Teergrubing has no potential as a commercial sales5< feature.  The number of people with purchasing authority who; would make a purchase decision on the basis of that feature  is vanishingly small.t  < When you get to providing an SMTP server however (or in your< existing products' SMTP servers) it would be nice to have an= appropriate set of callouts to site-specific code (_not_ DCL,) due to efficiency concerns).   ------------------------------  % Date: Mon, 12 May 2003 22:40:12 -0400n* From: JF Mezei <jfmezei.spamnot@istop.com>$ Subject: Re: Spamfilter for OpenVMS?) Message-ID: <3EC05B0B.E64E41C6@istop.com>O   someone wrote:? >         Teergrubing consumes resources of the sending system,S? >         be it a machine owned by the spammer or an open relayi, >         complicit in delivering the spam.    Not necessarily.  J If the offending system is behind a NAT router, your revenge process couldG connect to machine 2 while machine 1 happily continues to send spam. SooM machine 2 would handle the teergrubing from people mad at you while machine 1a3 would busily make many many more people mad at you.r   ------------------------------    Date: 12 May 2003 12:16:52 -0700( From: bob@instantwhip.com (Bob Ceculski)8 Subject: Sparky is losing the race Andrew ... and badly!= Message-ID: <d7791aa1.0305121116.5a682f00@posting.google.com>a  6 Sun might as well forget it Andrew ... you should have2 bought alpha/vms/tru64 when you had the chance ...7 NIH (not invented here) syndrome will hurt the company!s  ( http://www.theinquirer.net/?article=9437   ------------------------------  % Date: Mon, 12 May 2003 17:02:18 -0400r# From: "rob kas" <rob@paychoice.com>d< Subject: Re: Sparky is losing the race Andrew ... and badly!8 Message-ID: <TmTva.131$oA2.65073272@news.netcarrier.net>      Bob  3   Do you get paid to regurgitate Inquirer Articles?-  "                                Rob      5 "Bob Ceculski" <bob@instantwhip.com> wrote in message 7 news:d7791aa1.0305121116.5a682f00@posting.google.com...r8 > Sun might as well forget it Andrew ... you should have4 > bought alpha/vms/tru64 when you had the chance ...9 > NIH (not invented here) syndrome will hurt the company!b > * > http://www.theinquirer.net/?article=9437   ------------------------------  % Date: Mon, 12 May 2003 16:15:46 -0400 * From: JF Mezei <jfmezei.spamnot@istop.com>< Subject: Re: Sparky is losing the race Andrew ... and badly!) Message-ID: <3EC000F2.FDD5FC68@istop.com>r   Bob Ceculski wrote:a* > http://www.theinquirer.net/?article=9437   Something I do not understand:  M There is a table in this article. It lists EV7 as being MUCH MUCH slower thanaL all its competitors in 2003. (with a 1.15ghz rate versus the others who have faster clocks).i  J But in 2004, the 1.6ghz EV7 still ranks slower in some metrics to the 2003 chips that are at 1.5ghz.o  L Considering that HP has supposedly not released official benchmarks for EV7,# can this table really be believed ?e   ------------------------------  # Date: Mon, 12 May 2003 20:50:08 GMTe4 From: brad@.gateway.2wire.net (Bradford J. Hamilton)< Subject: Re: Sparky is losing the race Andrew ... and badly!. Message-ID: <4OTva.564464$OV.536306@rwcrnsc54>  V In article <3EC000F2.FDD5FC68@istop.com>, JF Mezei <jfmezei.spamnot@istop.com> writes: >Bob Ceculski wrote:+ >> http://www.theinquirer.net/?article=9437a >h >Something I do not understand:v >pN >There is a table in this article. It lists EV7 as being MUCH MUCH slower thanM >all its competitors in 2003. (with a 1.15ghz rate versus the others who haveh >faster clocks). >hK >But in 2004, the 1.6ghz EV7 still ranks slower in some metrics to the 2003: >chips that are at 1.5ghz.  H The copy in the article implies that the Alpha is being "throttled back"L (deliberately, so as not to outshine IA-64).  The tone of the whole article,N however, indicates that all "facts", including the table, are guesses.  Since I I'm not a speed-maven, I can't really judge how accurate the guesses are a4 (I'll leave that exercise to Bill Todd, et. al.)	:-)     >cM >Considering that HP has supposedly not released official benchmarks for EV7,y$ >can this table really be believed ?  A _________________________________________________________________w0 Bradford J. Hamilton			"All opinions are my own"/ bMradAhamiPltSon@atMtAbi.cPoSm		"Lose the MAPS"h   ------------------------------  % Date: Mon, 12 May 2003 23:46:01 -0400g* From: "Bill Todd" <billtodd@metrocast.net>< Subject: Re: Sparky is losing the race Andrew ... and badly!2 Message-ID: <oKidnWhnVM_j912jXTWcrg@metrocast.net>  A "Bradford J. Hamilton" <brad@.gateway.2wire.net> wrote in messagea( news:4OTva.564464$OV.536306@rwcrnsc54...4 > In article <3EC000F2.FDD5FC68@istop.com>, JF Mezei# <jfmezei.spamnot@istop.com> writes:k > >Bob Ceculski wrote:- > >> http://www.theinquirer.net/?article=9437m > >e! > >Something I do not understand:e > >fK > >There is a table in this article. It lists EV7 as being MUCH MUCH slowert thanJ > >all its competitors in 2003. (with a 1.15ghz rate versus the others who have > >faster clocks). > > H > >But in 2004, the 1.6ghz EV7 still ranks slower in some metrics to the 2003 > >chips that are at 1.5ghz. > J > The copy in the article implies that the Alpha is being "throttled back"E > (deliberately, so as not to outshine IA-64).  The tone of the wholeC article,H > however, indicates that all "facts", including the table, are guesses.  K Well, maybe just a *bit* more than guesses - see this RWT contribution fromg	 February:O  L http://www.realworldtech.com/forums/index.cfm?action=detail&PostNum=1233&Thr ead=1&roomID=11&entryID=14653D  ( EV79 crushed under Carly's spiked heel ?  + Name: Paul DeMone (pdemone@igs.net) 2/14/03   3 According to a report of an ISSCC 2003 attendee theV3 EV79 paper revealed a much different beast than wasg on Compaq's roadmap: Here's the link:L http://groups.google.com/groups?selm=45022fc8.0302112326.2a1d1d72%40posting.
 google.com  B "- Alpha in 0.13um SOI. Is this EV-7? It had the 1.75MB secondary,C    the 8 RDRAM interfaces, etc. I think this might be a second port*B    of EV-7 or some such thing. The "Source design" ran at 1.25 GHz2    in 0.18um bulk CMOS, this one runs at 1.45 GHz.D    That doesn't seem like quite the right amount of speedup. I wouldE    expect about that much speedup just from the bulk->SOI transition.o;    0.18um -> 0.13um should have gotten another 15-20%, no?"D  7 The EV79 was originally spec'd out with a 3.0 MB L3 and 7 a clock rate of 1.6 to 1.7 GHz. Considering the process 5 move from 0.18 um bulk to 0.13 um SOI even that seems , like a rather conservative frequency target.  5 Considering that the EV79 was the only EV7 descendantl4 planned it is hard to escape the conclusion that the3 ISSCC 2003 paper does describe the last Alpha. ThatA5 implies HP greatly emasculated the EV79 from what was35 planned for by Compaq. The most likely explanation iso5 that Carly & Co wants to encourage customers to leave 6 Alpha as quickly as possible but was under contractual5 obligation to produce the EV79. They will produce the 9 EV79 but it will be a caricature of its former target and 2 barely an improvement on the existing 0.18 um EV7.  3 This can hardly have gone down well with members of 6 the shrink team. I would like to hear from any current5 or former ADTers who know the inside story on the sadm4 and likely treacherous finish to a great engineering9 tradition. I will keep the details private if so desired.-   ------------------------------  % Date: Mon, 12 May 2003 23:59:10 -0400o* From: "Bill Todd" <billtodd@metrocast.net>< Subject: Re: Sparky is losing the race Andrew ... and badly!2 Message-ID: <Mc6dnVMJzcsO8F2jXTWcrg@metrocast.net>  5 "Bill Todd" <billtodd@metrocast.net> wrote in messageM, news:oKidnWhnVM_j912jXTWcrg@metrocast.net... >aC > "Bradford J. Hamilton" <brad@.gateway.2wire.net> wrote in messageM* > news:4OTva.564464$OV.536306@rwcrnsc54...6 > > In article <3EC000F2.FDD5FC68@istop.com>, JF Mezei% > <jfmezei.spamnot@istop.com> writes:y > > >Bob Ceculski wrote:/ > > >> http://www.theinquirer.net/?article=9437e > > >w# > > >Something I do not understand:, > > >eF > > >There is a table in this article. It lists EV7 as being MUCH MUCH slower > thanL > > >all its competitors in 2003. (with a 1.15ghz rate versus the others who > have > > >faster clocks). > > >yJ > > >But in 2004, the 1.6ghz EV7 still ranks slower in some metrics to the > 2003 > > >chips that are at 1.5ghz. > >eL > > The copy in the article implies that the Alpha is being "throttled back"G > > (deliberately, so as not to outshine IA-64).  The tone of the wholei
 > article,J > > however, indicates that all "facts", including the table, are guesses. > , > Well, maybe just a *bit* more than guesses   And another reference:  * http://212.100.234.54/content/3/28947.html  I "Bennett [group marketing manager at HP's Business Critical Systems unit]mK said the EV7[9] chip is expected to provide about 30% more performance than + the EV7, and will run at 1.3GHz to 1.5GHz."p  J Again, much slower than the 1.6 - 1.7 GHz one would expect from the shrinkJ plus the move to SOI.  The above article also noted that HP expected majorK OLTP performance improvements from Marvel but did not plan to release TPC-Ci benchmarks for it.   - bill   ------------------------------  % Date: Tue, 13 May 2003 00:06:00 -0400r* From: "Bill Todd" <billtodd@metrocast.net>< Subject: Re: Sparky is losing the race Andrew ... and badly!2 Message-ID: <-BWdnVoobrHU8l2jXTWcpg@metrocast.net>  5 "Bill Todd" <billtodd@metrocast.net> wrote in messagea, news:Mc6dnVMJzcsO8F2jXTWcrg@metrocast.net...   ...d   > And another reference: >j, > http://212.100.234.54/content/3/28947.html >nK > "Bennett [group marketing manager at HP's Business Critical Systems unit]dH > said the EV7[9] chip is expected to provide about 30% more performance than- > the EV7, and will run at 1.3GHz to 1.5GHz."d >eL > Again, much slower than the 1.6 - 1.7 GHz one would expect from the shrinkL > plus the move to SOI.  The above article also noted that HP expected majorG > OLTP performance improvements from Marvel but did not plan to releasee TPC-Ce > benchmarks for it.  F Damn - forgot to note that the above article also said that EV79 wouldK appear in 'late 2004', about a 9-month slip from the early 2004 predictionsyF that HP had been making just weeks earlier.  In sum:  cache-size boostG cancelled, clock-rate scaled back, introduction delayed - three strikeslK against an already declared-dead product, just to make *sure* that it won'te upstage the floundering Itanic.e   - bill   ------------------------------  % Date: Tue, 13 May 2003 00:13:56 -0400 * From: JF Mezei <jfmezei.spamnot@istop.com>< Subject: Re: Sparky is losing the race Andrew ... and badly!) Message-ID: <3EC070FD.672B27A8@istop.com>r   Bill Todd wrote:H > Damn - forgot to note that the above article also said that EV79 wouldM > appear in 'late 2004', about a 9-month slip from the early 2004 predictionse    N On the other hand, since they have succesfully released EV7 without making anyJ waves/noises and kept it secret, it would be to their advantage to releaseK EV79 next week, keep it just as secret and be done with Alpha one full yeare0 earlier, reducing their commitment by one yeart.  J Remember that HP is stuck with Alpha support well past the time when carlyQ will be ousted/retired or asked  to move to MCI to fix the mess left by Capellas.p   ------------------------------  % Date: Tue, 13 May 2003 00:46:00 -0400e* From: "Bill Todd" <billtodd@metrocast.net>< Subject: Re: Sparky is losing the race Andrew ... and badly!2 Message-ID: <rtqdnbvr46QW5V2jXTWcow@metrocast.net>  7 "JF Mezei" <jfmezei.spamnot@istop.com> wrote in message # news:3EC000F2.FDD5FC68@istop.com...i > Bob Ceculski wrote:n, > > http://www.theinquirer.net/?article=9437 >o  > Something I do not understand: >rJ > There is a table in this article. It lists EV7 as being MUCH MUCH slower thanI > all its competitors in 2003. (with a 1.15ghz rate versus the others whon have > faster clocks).g  L Because all the others are a full process generation ahead of EV7.  And theyI have cores that are 3 - 4 years newer than the EV7 core, and 3.4x as much J on-chip cache in the case of Madison or a 32 MB off-chip cache in the case of POWER4+.i   >eL > But in 2004, the 1.6ghz EV7 still ranks slower in some metrics to the 2003 > chips that are at 1.5ghz.   J Not the SPECint/fp metrics (though since HP has gutted EV79 its figures inE the chart are probably optimistic now).  And the GFLOPs figures are a-I function not only of the clock rate but also of the issue width:  EV8 (in L 2004) would have increased EV7's issue width and kept it very competitive in8 that area while completely dominating the others in more- commercially-significant performance metrics.c   >uI > Considering that HP has supposedly not released official benchmarks for  EV7,% > can this table really be believed ?   K SPECint/fp benchmarks exist for EV7, and the GFLOPs figures are (I believe)m simply-calculated values.    - bill   ------------------------------  % Date: Mon, 12 May 2003 15:50:02 -0500a/ From: Chris Scheers <chris@applied-synergy.com>e Subject: Re: Splitting cluster3 Message-ID: <3EC008FA.43E92AD2@applied-synergy.com>    Paddy O'Brien wrote: > A > I'm afraid that I currently have no access to any fine manuals.a > G > I have the remains of a heterogeneous cluster: one VAX (was four) and  > one Alpha. > I > In order to get them to boot separately and not as a cluster, do I onlyeN > need to change VAXCLUSTER to 0 in each of the MODPARAMS.DAT and run Autogen? > G > Do I need to worry about other system parameters, e.g. quorum values?o >  > Regards, Paddy    @ Setting VAXCLUSTER=0 is enough to force a node to be standalone.  F If you want a node to be a cluster member in a different cluster, thenG other things need to be done.  Mainly, the cluster group/password needs  to be reset.  G -----------------------------------------------------------------------n$ Chris Scheers, Applied Synergy, Inc.  C Voice: 817-237-3360            Internet: chris@applied-synergy.com e   Fax: 817-237-3074    ------------------------------  % Date: Tue, 13 May 2003 12:07:23 +1000s$ From: David Bodey <dbodey@yahoo.com>% Subject: Status of Commserver productl( Message-ID: <3EC0535B.3000901@yahoo.com>  F Does anyone know what happen to the old DEC Commserver software which I allows a VMS systems to communicate with a Commserver gateway (e.g. to a eL PLC network). Did HP (or a previous incarnation) sell it to another company?  H We have Commserver V2.0 running on VMS/VAX V7.1 using X25 HDLC LAPB and % we want to upgrade to VMS/Alpha V7.3.    ------------------------------  % Date: Mon, 12 May 2003 13:31:42 -0600^' From: DigiDemon <digidemon@hotmail.com>0. Subject: Stopping a que other then a print que8 Message-ID: <pan.2003.05.12.19.31.41.736349@hotmail.com>  
 Hello all!  C Real quick....we have PerfectDisk running here..and there have beenmI sometimes when I wan't to stop the scheduled que that it starts...and forhF the life of me I just haven't been able to shut it down.  Anyway I can nuke this que?  Thanks!h   JamesN   ------------------------------  % Date: Mon, 12 May 2003 19:07:55 -0500c1 From: "David J. Dachtera" <djesys.nospam@fsi.net>M2 Subject: Re: Stopping a que other then a print que' Message-ID: <3EC0375B.F569FC97@fsi.net>e   DigiDemon wrote: >  > Hello all! > E > Real quick....we have PerfectDisk running here..and there have beenyK > sometimes when I wan't to stop the scheduled que that it starts...and foraH > the life of me I just haven't been able to shut it down.  Anyway I can > nuke this que?  Thanks!o   Huh?  F $ STOP/RESET will do a "catastrophic" stop of queue. DELETE/QUEUE will$ delete the queue once it is stopped.  C $ DELETE/ENTRY will kill an existing job (or try to; subject to the + usual LEF, MWAIT, MUTEX, etc. limitations).   ; If it uses it's own scheduler, you may have other problems.e   --   David J. Dachterae dba DJE SystemsD http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/.   ------------------------------    Date: 12 May 2003 17:39:33 -0700# From: dooleys@snowy.net.au (dooley).2 Subject: Re: Stopping a que other then a print que= Message-ID: <1ca82fc6.0305121639.513e3fa9@posting.google.com>s  g DigiDemon <digidemon@hotmail.com> wrote in message news:<pan.2003.05.12.19.31.41.736349@hotmail.com>...f > Hello all! > E > Real quick....we have PerfectDisk running here..and there have been K > sometimes when I wan't to stop the scheduled que that it starts...and for>H > the life of me I just haven't been able to shut it down.  Anyway I can > nuke this que?  Thanks!u >  > Jameso  9 The PerfectDisk queue should be called PD_BATCH_ON_<node> . You can safely stop this queue, why delete it?5 The batch job only starts detached processes that do o8 the real work, if you use the procedure PDA.COM you can  stop these detached processes  Phil   ------------------------------  % Date: Mon, 12 May 2003 21:41:25 -0400F( From: David Froble <davef@tsoft-inc.com>2 Subject: Re: Stopping a que other then a print que, Message-ID: <3EC04D45.5010804@tsoft-inc.com>   David J. Dachtera wrote:   > DigiDemon wrote: >  >>Hello all! >>E >>Real quick....we have PerfectDisk running here..and there have beeneK >>sometimes when I wan't to stop the scheduled que that it starts...and for H >>the life of me I just haven't been able to shut it down.  Anyway I can >>nuke this que?  Thanks!f >> >  > Huh? > H > $ STOP/RESET will do a "catastrophic" stop of queue. DELETE/QUEUE will& > delete the queue once it is stopped. > E > $ DELETE/ENTRY will kill an existing job (or try to; subject to theu- > usual LEF, MWAIT, MUTEX, etc. limitations).3 > = > If it uses it's own scheduler, you may have other problems.@ >  >     L Don't know if it's always required, but long ago I learned to use the /NEXT J switch on any STOP/QUEUE commands.  Wouldn't work without it.  Similar to I STOP/QUEUE/MANAGER/CLUSTER is required, even if you don't have a cluster.r     Dave   --  4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596> DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com6 T-Soft, Inc.  170 Grimplin Road  Vanderbilt, PA  15486   ------------------------------  % Date: Mon, 12 May 2003 21:55:13 -0500n1 From: "David J. Dachtera" <djesys.nospam@fsi.net>)2 Subject: Re: Stopping a que other then a print que& Message-ID: <3EC05E91.4F99D55@fsi.net>   David Froble wrote:  >  > David J. Dachtera wrote: >  > > DigiDemon wrote: > >e > >>Hello all! > >>G > >>Real quick....we have PerfectDisk running here..and there have been7M > >>sometimes when I wan't to stop the scheduled que that it starts...and for_J > >>the life of me I just haven't been able to shut it down.  Anyway I can > >>nuke this que?  Thanks!- > >> > >c > > Huh? > >tJ > > $ STOP/RESET will do a "catastrophic" stop of queue. DELETE/QUEUE will( > > delete the queue once it is stopped. > >sG > > $ DELETE/ENTRY will kill an existing job (or try to; subject to thet/ > > usual LEF, MWAIT, MUTEX, etc. limitations).t > >V? > > If it uses it's own scheduler, you may have other problems.t > >e > >g > M > Don't know if it's always required, but long ago I learned to use the /NEXT"@ > switch on any STOP/QUEUE commands.  Wouldn't work without it.   G When did you encounter that? AFAIK, /QUEUE has never been required whenc using /NEXT or /RESET.   > Similar toK > STOP/QUEUE/MANAGER/CLUSTER is required, even if you don't have a cluster.o  2 That's a new one on me, too. Never had to do that.   --   David J. Dachtera. dba DJE Systemsu http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------  % Date: Mon, 12 May 2003 22:51:05 -0400d* From: JF Mezei <jfmezei.spamnot@istop.com>2 Subject: Re: Stopping a que other then a print que) Message-ID: <3EC05D98.1DA2DB89@istop.com>    David Froble wrote: M > Don't know if it's always required, but long ago I learned to use the /NEXTa$ > switch on any STOP/QUEUE commands.  + yep. STOP/QUEUE only works on iddle queues.n  ( And if you REALLY want to stop the queue   STOP/QUEUE chocolate_queue  STOP/QUEUE/ABORT chocolate_queue  STOP/QUEUE/RESET chocolate_queue  4 the first one prevents any more jobs from starting. 2 The second one stops the currently executing jobs.: The 3rd one makes sure the queue is really really stopped.    9 What is really neeeded is STOP/QUEUE/NOW=I_REALLY_MEAN_ITh   ------------------------------  % Date: Mon, 12 May 2003 14:48:52 -0400s* From: JF Mezei <jfmezei.spamnot@istop.com>@ Subject: Re: What is the schedule for the DII COE certification?) Message-ID: <3EBFEC94.F138D423@istop.com>g   Paddy O'Brien wrote:I > David, why "preferably unsigned"?  A 64 bit integer is already a damned , > big number, beyond the use of most of us.   G You could stick 8 characters in an unsigned register. If you use signedmL operations, then the highest order character can't use the full ISO standard. and is restricted to the first 127 characters.  X Also, consder when you do bit shift operations. Signed or usigned makes a big diference.   ------------------------------  # Date: Mon, 12 May 2003 21:10:30 GMT 0 From: John Santos <john.santos@post.harvard.edu>@ Subject: Re: What is the schedule for the DII COE certification?= Message-ID: <MPG.1929d7d0b1eb4dc9896d3@news.bellatlantic.net>o  I In article <3EBF4C92.5060106@tg.nsw.gov.au>, paddy.o'brien@tg.nsw.gov.au o says...a >  >  > David J. Dachtera wrote: > > John Santos wrote: > > * > >>On 10 May 2003, Larry Kilgallen wrote: > >> > >>Z > >>>In article <m1$m61PpHU1C@elias.decus.ch>, p_sture@elias.decus.ch (Paul Sture) writes: > >>> r > >>>>In article <E9uua.528$Ct2.295@news.cpqcorp.net>, "Fred Kleinsorge" <my-last-name@stardotzko.dec.com> writes: > >>>rO > >>>>>The Kernel sits on top of a standard VMS release.  But changes that wereiR > >>>>>needed to support the Kernel were done in a seperate release stream for theO > >>>>>first release to manage schedule and risk.  Those changes will be in thei. > >>>>>next general V7.3-* release of OpenVMS. > >>>>N > >>>>So... I was looking forward to the idea that we non US govt. folks would< > >>>>get to see the benefits of the work put into VMS here. > >>>>K > >>>>Can you please tell us what advantages we, the normal users will see?e > >>>SO > >>>For C programmers, there will be better compatibility with the environmenty< > >>>on Unix operating systems, which is useful for porting. > >>>EK > >>>For those using higher level languages like Ada, it should not matter.t > >>K > >>Well, even if you use a higher level language (I'm partial to Macro-32,3L > >>VAX/DEC Basic and TECO), you will benefit if other people (HP and nonHP) > I > John, I would not class any of these as high level.  Macro is low; not rF > sure about Basic, I have only used it as an interpreted language -- I > middle; and TECO is an editor not a language (perhaps you can do eigen h > analysis with TECO :-) >   F There was an implied smiley in the list...  A joke that compared to C,G even MACRO-32 is high-level.   BTW, VAX/DEC BASIC is much more advancedrG than most BASIC dialects.  Fully block structured: if/then/else/endif, rE for/next, while/until, select/case, etc.  It lets you define complex tD data types (RECORDs) consisting of collections of simple data types H (integer, floating, string, decimal, RFAs) and other complex data types G (analogous to structures in C), optional strong typing, etc.  Function bI prototyping with compile-time checking.  Named instead of numeric labels pE (line numbers) as goto targets, etc.  (But I almost never need GOTOs .I anymore, due to block structuring and loop control (ITERATE statement.)   D On Alpha, it uses the GEM backend, so it has access to the compiler   optimizing of other languages.    E TECO, of course, is not so much a high level language as an operating 
 system :-)   [...]    > Regards, Paddy     -- p John   ------------------------------  % Date: Mon, 12 May 2003 18:39:08 -0500 1 From: "David J. Dachtera" <djesys.nospam@fsi.net>:@ Subject: Re: What is the schedule for the DII COE certification?' Message-ID: <3EC0309C.1983CED4@fsi.net>D   Paddy O'Brien wrote: >  > David J. Dachtera wrote: > > John Santos wrote: > >d* > >>On 10 May 2003, Larry Kilgallen wrote: > >> > >>Z > >>>In article <m1$m61PpHU1C@elias.decus.ch>, p_sture@elias.decus.ch (Paul Sture) writes: > >>>tr > >>>>In article <E9uua.528$Ct2.295@news.cpqcorp.net>, "Fred Kleinsorge" <my-last-name@stardotzko.dec.com> writes: > >>>eO > >>>>>The Kernel sits on top of a standard VMS release.  But changes that wereuR > >>>>>needed to support the Kernel were done in a seperate release stream for theO > >>>>>first release to manage schedule and risk.  Those changes will be in the . > >>>>>next general V7.3-* release of OpenVMS. > >>>>N > >>>>So... I was looking forward to the idea that we non US govt. folks would< > >>>>get to see the benefits of the work put into VMS here. > >>>>K > >>>>Can you please tell us what advantages we, the normal users will see?  > >>>aO > >>>For C programmers, there will be better compatibility with the environmentt< > >>>on Unix operating systems, which is useful for porting. > >>>tK > >>>For those using higher level languages like Ada, it should not matter.r > >>K > >>Well, even if you use a higher level language (I'm partial to Macro-32, L > >>VAX/DEC Basic and TECO), you will benefit if other people (HP and nonHP) > H > John, I would not class any of these as high level.  Macro is low; notE > sure about Basic, I have only used it as an interpreted language -- H > middle; and TECO is an editor not a language (perhaps you can do eigen > analysis with TECO :-) > G > >>find it easier to port and maintain various programs.  For example,sC > >>there is a recent thread about 4GB file size limits in ZIP.  IfeL > >>this has been or is soon fixed in the generic/Linux/GNU/Solaris/whateverG > >>version of ZIP and that version can be compiled with minimal hassler0 > >>on VMS, then we'll get the fix much quicker. > >>: > >>So it doesn't just apply to low-level C programmers... > >e > >cH > > I should think it's a matter of acquiring the ability to use integerL > > fields 64 bits in length, preferably unsigned. Other software would needK > > to be modified: ZIP, UNZIP (remember backward compatibility with 32-bit8; > > versions), the associated RTLs and math libraries, etc.  > >r- > > Just a guess, but it seems to make sense.t > >oI > David, why "preferably unsigned"?  A 64 bit integer is already a damned02 > big number, beyond the use of most of us. [snip]  E Didn't someone once say that no one would ever need more than 640K of3 RAM?  H Wasn't there once a problem with PC disks bigger than about 504MB or so?  B Doesn't VMS prior to V6 have a problem with disks bigger than 8GB?  F Doesn't ODS-5 exist partly to accomodate smaller cluster sizes on huge	 RAIDsets?e  F Eventually, a 64-bit integer will become too small for some uses. Just trying to plan ahead.i   -- e David J. Dachterao dba DJE SystemsV http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/r   ------------------------------    Date: 12 May 2003 19:44:03 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen)1@ Subject: Re: What is the schedule for the DII COE certification?3 Message-ID: <OuiEzMVNfXZs@eisner.encompasserve.org>   [ In article <3EC0309C.1983CED4@fsi.net>, "David J. Dachtera" <djesys.nospam@fsi.net> writes:e > Paddy O'Brien wrote:  J >> David, why "preferably unsigned"?  A 64 bit integer is already a damned3 >> big number, beyond the use of most of us. [snip]s > G > Didn't someone once say that no one would ever need more than 640K ofo > RAM? > J > Wasn't there once a problem with PC disks bigger than about 504MB or so? > D > Doesn't VMS prior to V6 have a problem with disks bigger than 8GB? > H > Doesn't ODS-5 exist partly to accomodate smaller cluster sizes on huge > RAIDsets?t > H > Eventually, a 64-bit integer will become too small for some uses. Just > trying to plan ahead.f  @ I don't think 1280K of RAM would have made that much difference.2 Planning ahead requires more than a factor of two.   ------------------------------  + Date: Tue, 13 May 2003 02:06:56 +0000 (UTC)h) From: Dan Foster <dsf@globalcrossing.net> @ Subject: Re: What is the schedule for the DII COE certification?3 Message-ID: <slrnbc0kq7.n6s.dsf@gaia.roc2.gblx.net>-  b In article <OuiEzMVNfXZs@eisner.encompasserve.org>, Larry Kilgallen <Kilgallen@SpamCop.net> wrote:] > In article <3EC0309C.1983CED4@fsi.net>, "David J. Dachtera" <djesys.nospam@fsi.net> writes:  >> Paddy O'Brien wrote:  > K >>> David, why "preferably unsigned"?  A 64 bit integer is already a damned-4 >>> big number, beyond the use of most of us. [snip] >> uH >> Didn't someone once say that no one would ever need more than 640K of >> RAM?m >> bK >> Wasn't there once a problem with PC disks bigger than about 504MB or so?> >>  E >> Doesn't VMS prior to V6 have a problem with disks bigger than 8GB?d >> oI >> Doesn't ODS-5 exist partly to accomodate smaller cluster sizes on huge> >> RAIDsets? >> tI >> Eventually, a 64-bit integer will become too small for some uses. Just' >> trying to plan ahead. > B > I don't think 1280K of RAM would have made that much difference.4 > Planning ahead requires more than a factor of two.   Indeed. To add on to that:   2^32
 4294967296 2^64 18446744073709551616  I Unsigned 64 bit address space is about 16.77 million terabytes, or 16,384 
 petabytes.  K In about 20 years, we've gone from 640K to 1 GB on desktops, an increase ofrJ about 1640 times... so if that holds linearlly, can expect 2 TB systems inK another 20 years. 20, 100, 200 TB servers eventually? Still a long way fromkI 16.77 million TB. Even if desktop RAM sizes grows by 1640^2 times, that'saE about 2600 TB. You could have servers 100x bigger than that and stilln weight in at 260000 TB.w  E However, I haven't underestimated the ability of certain applicationscA (read: Microsoft Word) to expand and occupy all available RAM :-)s   -Dan   ------------------------------  % Date: Mon, 12 May 2003 20:29:42 -0500a1 From: "David J. Dachtera" <djesys.nospam@fsi.net>d@ Subject: Re: What is the schedule for the DII COE certification?' Message-ID: <3EC04A86.C237555E@fsi.net>:   Larry Kilgallen wrote: > ] > In article <3EC0309C.1983CED4@fsi.net>, "David J. Dachtera" <djesys.nospam@fsi.net> writes:. > > Paddy O'Brien wrote: > L > >> David, why "preferably unsigned"?  A 64 bit integer is already a damned5 > >> big number, beyond the use of most of us. [snip]e > >oI > > Didn't someone once say that no one would ever need more than 640K oft > > RAM? > >lL > > Wasn't there once a problem with PC disks bigger than about 504MB or so? > >xF > > Doesn't VMS prior to V6 have a problem with disks bigger than 8GB? > >eJ > > Doesn't ODS-5 exist partly to accomodate smaller cluster sizes on huge
 > > RAIDsets?e > >hJ > > Eventually, a 64-bit integer will become too small for some uses. Just > > trying to plan ahead.e > B > I don't think 1280K of RAM would have made that much difference.4 > Planning ahead requires more than a factor of two.  @ Not too hard to envision 1280T of RAM at the rate we're going...   --   David J. Dachteraa dba DJE Systemse http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/t   ------------------------------   End of INFO-VAX 2003.263 ************************