1 INFO-VAX	Fri, 24 Feb 2006	Volume 2006 : Issue 110       Contents: Re: AMD blew it big time!  Re: AMD blew it big time!  Re: AMD blew it big time!  Re: AMD blew it big time!  Re: AMD blew it big time!  Re: BACKUP$MANAGER Re: Boy, do I like VMS humor!  Re: Boy, do I like VMS humor!  Re: Boy, do I like VMS humor!  Re: Boy, do I like VMS humor!  Re: Boy, do I like VMS humor!  Re: Boy, do I like VMS humor!  Re: Boy, do I like VMS humor! ! Re: Can VMS make files immutable? ! Re: Can VMS make files immutable? % Re: CSWS 2.1 + Tomcat 5.5.9 + mod_jk2 K Re: Entry-level Integrity Servers? (was: Itanium still not on alpha level!) , Re: file list for ftp in a command procedure, Re: file list for ftp in a command procedure, Re: file list for ftp in a command procedure= Re: Gartner wakes up company executives to X86-64 scalability = Re: Gartner wakes up company executives to X86-64 scalability G Re: HP Campus program for Integrity Servers in Europe/ Integrity Server  HP hurting the itanium market!' IA64 VMS V8.2-1: SYSTEM-F-VA_NOTPAGALGN + Re: IA64 VMS V8.2-1: SYSTEM-F-VA_NOTPAGALGN + Re: IA64 VMS V8.2-1: SYSTEM-F-VA_NOTPAGALGN + Re: IA64 VMS V8.2-1: SYSTEM-F-VA_NOTPAGALGN + Re: IA64 VMS V8.2-1: SYSTEM-F-VA_NOTPAGALGN % Re: Itanium still not on alpha level! % Re: Itanium still not on alpha level! % Re: Itanium still not on alpha level! % Re: Itanium still not on alpha level! , Re: object names from executable image files, Re: OpenVMS proves superior to all other OSs, Re: OpenVMS proves superior to all other OSs, Re: OpenVMS proves superior to all other OSs, Re: OpenVMS proves superior to all other OSs1 Re: Plain truth is that unix/linux is NOT secure! 1 Re: Plain truth is that unix/linux is NOT secure! 1 Re: Plain truth is that unix/linux is NOT secure! 1 Re: Plain truth is that unix/linux is NOT secure! 1 Re: Plain truth is that unix/linux is NOT secure! 1 Re: Plain truth is that unix/linux is NOT secure! 1 Re: Plain truth is that unix/linux is NOT secure! 1 Re: Plain truth is that unix/linux is NOT secure! 1 Re: Plain truth is that unix/linux is NOT secure! 1 Re: Plain truth is that unix/linux is NOT secure! 1 Re: Plain truth is that unix/linux is NOT secure! 1 Re: Plain truth is that unix/linux is NOT secure!  question about VMS732_LMF-V0200  Re: Regarding SDA Extension., Re: Rich Marcello in VMS mention shocker :-), Re: Rich Marcello in VMS mention shocker :-). Rocky Mountain Local Users Group March Meeting Sales of Alpha Systems?  Re: Sales of Alpha Systems?  Re: save_set on DVD   F ----------------------------------------------------------------------  % Date: Fri, 24 Feb 2006 03:12:29 -0500 ( From: Bill Todd <billtodd@metrocast.net>" Subject: Re: AMD blew it big time!G Message-ID: <mPidnXtuTIptImPenZ2dnUVZ_tCdnZ2d@metrocastcablevision.com>   
 Andrew wrote:  > bob@instantwhip.com wrote:E >> they thought that buying a few bits and pieces of alpha technology J >> for their oopsterons would suffice, but eventually it will run into theC >> x86 boat anchor performance wall ... they should have bought all  >> of alpha and had the x86 64 on the one side, and alpha EV8 and 9 on the high end ... would have been a lot better long term strategy. >> > H > Exactly how much quicker do you think the EV8 would have been than the, > current Alpha processor ? 1.5x 2x perhaps.  E Welcome back, Andrew - it seems you're still inclined to pontificate  & about subjects you know nothing about.  G EV8 was planned to clock 1.5x as fast as EV7 at introduction, up to 2x  I as fast over its 130 nm. lifetime.  But by now (having been shipping for  I nearly 2 years) it would have been in a 90 nm. process (the process size  E always planned as its 'sweet spot'), so 2x as fast would likely be a   lower limit.  I But that's just as far as clock speed goes.  EV7's core first shipped in  F 1998, and thus EV8 had nearly 6 years' more technology development to I leverage.  I don't remember some of the details (8-way rather than 4-way  G issue and significantly improved branch-prediction were just two, plus  E of course a larger on-chip cache than EV7 has), but by now it should  D have offered noticeably more than 2x the performance of today's EV7.  ? And that's just for a single thread, of course.  EV8 was 4-way  I simultaneously-multi-threaded (with increased numbers of execution units  H to match, which were useful in supporting 8-way issue as well), and its I simulations indicated that for typical commercial workloads this doubled  D (actually, for TPC-C a bit more than doubled) its throughput over a A non-SMT EV8.  Hence it would have offered at least 5x the server   throughput of today's EV7.  G Perhaps you should stick to talking about Sun:  I always did think you  I had some credibility in that area, and had some interesting observations  	 to offer.    - bill   ------------------------------    Date: 24 Feb 2006 03:59:44 -0800- From: "Andrew" <andrew_harrison@symantec.com> " Subject: Re: AMD blew it big time!B Message-ID: <1140782384.613913.53800@v46g2000cwv.googlegroups.com>   Bill Todd wrote:    F > Welcome back, Andrew - it seems you're still inclined to pontificate( > about subjects you know nothing about. > H > EV8 was planned to clock 1.5x as fast as EV7 at introduction, up to 2xJ > as fast over its 130 nm. lifetime.  But by now (having been shipping forJ > nearly 2 years) it would have been in a 90 nm. process (the process sizeF > always planned as its 'sweet spot'), so 2x as fast would likely be a > lower limit. > J > But that's just as far as clock speed goes.  EV7's core first shipped inG > 1998, and thus EV8 had nearly 6 years' more technology development to J > leverage.  I don't remember some of the details (8-way rather than 4-wayH > issue and significantly improved branch-prediction were just two, plusF > of course a larger on-chip cache than EV7 has), but by now it shouldF > have offered noticeably more than 2x the performance of today's EV7. > @ > And that's just for a single thread, of course.  EV8 was 4-wayJ > simultaneously-multi-threaded (with increased numbers of execution unitsI > to match, which were useful in supporting 8-way issue as well), and its J > simulations indicated that for typical commercial workloads this doubledE > (actually, for TPC-C a bit more than doubled) its throughput over a B > non-SMT EV8.  Hence it would have offered at least 5x the server > throughput of today's EV7. > H > Perhaps you should stick to talking about Sun:  I always did think youJ > had some credibility in that area, and had some interesting observations > to offer.   B Thanks you have just reinforced my point wonderfully. AMD currentyD deliver a dual core Opteron in a 233 million transistor package that> delivers on a per core basis 2x the performance of the fastest? available Alpha CPU or 4x the throughput for the whole package.   E If your best case outcome for EV8 had played out then maybee sometime B in the future EV8 would have matched the throughput of the currentE shipping Opterons, with a bigger package and higher themal footprint.   F In the circumstances your opening salvo looks more and more like folly and bravado on your part.    Regards  Andrew Harrison    ------------------------------    Date: 24 Feb 2006 04:19:55 -0800- From: "Andrew" <andrew_harrison@symantec.com> " Subject: Re: AMD blew it big time!C Message-ID: <1140783595.641086.122750@i40g2000cwc.googlegroups.com>    bob@instantwhip.com wrote:G > no x86 emulated processor will ever run the high end as well as alpha  > does.  > D > I said AMD could still have their x86 64 bit emulator chip for the > massesB > who feel trapped on x86 but could have still beat IBM, Intel and
 > everyone* > else also in the high end with alpha ... >   F You seem to have a tiny missconception about AMD's market aspirations.C AMD wants to take laptop, desktop and commodity server market share  away from Intel.  E Something that their current microarchitecture and packaging is doing B rather well. AMD have few aspirations at the top end and you couldE argue that they are better of not overreaching themselves and falling " into the trap the Intel fell into.  E That said Cray have 10 XT3's in the top500 list 2 of which are in the B top 10 and the XT3 is Opteron based. The Cray SeaStar architectureD shows that is is quite feasable to build very large systems based on Opteron and Hypertransport.   D Sun are expected to deliver a 16 way Opteron based system this year,B roughly equivalent to a 32 way Alpha server in throughput, not the. ultra high end be definitely in the mid range.   Regards  Andrew Harrison  ..   ------------------------------  % Date: Fri, 24 Feb 2006 09:11:56 -0700 6 From: "Michael D. Ober" <obermd.@.alum.mit.edu.nospam>" Subject: Re: AMD blew it big time!/ Message-ID: <4gGLf.26$Mf3.1183@news.uswest.net>       I stand corrected.   Mike.   5 "Bill Todd" <billtodd@metrocast.net> wrote in message 7 news:Ko2dndSjMITBCWPeRVn-pA@metrocastcablevision.com...  > Michael D. Ober wrote: > > J > > Probably was.  VAX/VMS was a threat to the PDP-11/TOPS-20 OS and there wereL > > a lot of people inside DEC who were emotionally committed to the PDP-11. > J > You really should stop blowing smoke out of your ass:  it just makes you > look stupid. > I > There was indeed some less-than-friendly rivalry between the 36-bitters F > and VAX/VMS, but any rivalry between the PDP-11 and VMS was amicableG > (well, the RSTS people were frustrated that VMS wouldn't adopt a more H > RSTS-like upgrade path for their users, but that didn't mean that they( > failed to appreciate VMS's strengths). > > > Those of us working on the 11 were all too well aware of itsJ > address-space limitations:  while working within them was in some ways aF > pleasurable challenge, three was no question whatsoever that a widerJ > architecture would be required to remain competitive by the beginning ofH > the '80s if not before - and VAX/VMS was a far more compatible upgrade> > path for 11 users than the 36-bit platforms would have been. > G > So while one can argue (as I did at the time) that DEC may have wound C > down 16- (and perhaps even more so 36-) bit development a bit too H > quickly (DEC was arguably large and strong enough to have pursued themF > for a while longer along with VAX, and the fact was that VAX was notI > able to take up the slack in a cost-effective - with respect to the 11s F > - and a performance-effective - with respect to the 36-bit systems -I > manner as soon as the DEC transition would have had it do so), the idea D > that people in the 11 world were actively sabotaging it is absurd. >  > - bill >    ------------------------------    Date: 24 Feb 2006 08:36:55 -0800- From: "Andrew" <andrew_harrison@symantec.com> " Subject: Re: AMD blew it big time!C Message-ID: <1140799015.206498.243330@t39g2000cwt.googlegroups.com>    JF Mezei wrote:  > bob@instantwhip.com wrote:K > > for their oopsterons would suffice, but eventually it will run into the ( > > x86 boat anchor performance wall ... >  > Bob, Bob, Bob... > H > Never underestimate a competitor. Yeah, there is plenty to laugh aboutJ > the 8086's life. But in the end, the predictions that it had reached itsH > architectural limits were proven wrong because both Intel and AMD wereG > able to scale the 8086 into enterprise level systems with performance V > that is not to sneeze at and at a price you can't beat because there is competition. > H > And because the volumes are so high, Intel and AMD can afford to spendB > the big bucks to support 8086 instructions onto modern machines. > I > It isn't Alpha , Power or Sparc that will sign IA64's death warrant, it G > will be the 8086. And don't sneeze at the 8086 because in the end, it D > may be the very thing which saves VMS from oblivion and gives it a# > chance to expand its marketplace.   C Actually Power and SPARC are also likely contenders to sign IA-64's E death warrant.  In order to suceed IA-64 has to gain large amounts of E market share from somewhere other than PA-RISC and Alpha. If as seems F likely Power and SPARC hold onto their market positions then IA-64 has; to take share from x86-64/EMT-64 which also seems unlikely.   > IDC recently predicted that the total Itanium server market inD 2008-2009 would be $6.6 billion dollars this is very close to todaysE combined market for Itanium, Alpha and PA-RISC and so it would appear E that Itaniums market share growth will be at the expense of HP-PA and " Alpha and not Power, SPARC or x86.   Regards  Andrew   ------------------------------    Date: 24 Feb 2006 09:45:52 -0600; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler)  Subject: Re: BACKUP$MANAGER 3 Message-ID: <E0JxYbG48bxn@eisner.encompasserve.org>   ` In article <43FBD87A.895A44C8@comcast.net>, David J Dachtera <djesys.nospam@comcast.net> writes: > G > Does anyone remember what comes on a standard DECpizza (what would be * > the default qualifiers/keywords/values)?  E    Hm, no.  I do have a couple DECpizza boxes sitting around, but all '    they have in them is a couple TLZ04.        Somebody musta' ate the rest.   ------------------------------  + Date: Fri, 24 Feb 2006 14:23:04 +0000 (UTC)  From: david20@alpha2.mdx.ac.uk& Subject: Re: Boy, do I like VMS humor!) Message-ID: <dtn4s8$fac$1@news.mdx.ac.uk>   R In article <43FE6892.8090005@comcast.net>, BRAD <bradhamilton@comcast.net> writes: >JF Mezei wrote: >> BRAD wrote: >>   >>>On VMS V7.3-2: # >>>write sys$output f$message(3244) J >>>%SYSTEM-F-IA32_TRAP, IA-32 trap, reason_mask=!XW, vector=!XB, code=!XW, >>>PC=!XH,PS=!XL >>   >>    >> Doesn't work on VAX though... >>  L >> And on Alpha, HELP/MESSAGE doesn't find any text to explain this message. >>   > D >Perhaps an example of "latent support"	:-)	Any comment from hp?	:-) >   ; But it must be fairly recent. On an Alpha running VMS 7.3-1   ' Imhub1:write sys$output f$message(3244) ( %SYSTEM-F-NOMSG, Message number 00000CAC  
 David Webb Security team leader CCSS Middlesex University   ------------------------------  # Date: Fri, 24 Feb 2006 15:02:30 GMT F From: lederman@star.enet.dec.DISABLE-JUNK-EMAIL.com (Bart Z. Lederman)& Subject: Re: Boy, do I like VMS humor!- Message-ID: <aeFLf.31$BK.190@news.oracle.com>   R In article <43FE5BA9.8030405@comcast.net>, BRAD <bradhamilton@comcast.net> writes: >Michael Moroney wrote: I >> Hmmm, maybe there really is some truth to the rumors of the secret VMS ; >> porting project taking place in the dungeons of ZK03....  >>  % >> $ write sys$output f$message(3244)  >  >On VMS V7.3-2: ! >write sys$output f$message(3244) I >%SYSTEM-F-IA32_TRAP, IA-32 trap, reason_mask=!XW, vector=!XB, code=!XW,   >PC=!XH,PS=!XL >   9 >>>IF<<< I were going to speculate on the origins of this 9 message, I would first look at the old FX!32 product, and ' not any secret OpenVMS porting project.    ------------------------------  # Date: Fri, 24 Feb 2006 15:53:21 GMT & From: John Reagan <john.reagan@hp.com>& Subject: Re: Boy, do I like VMS humor!2 Message-ID: <RZFLf.3634$8B5.2067@news.cpqcorp.net>   BRAD wrote:    > K > Perhaps an example of "latent support"    :-)    Any comment from hp?      > :-)  >   I Sure.  A quick scan of the listings shows that this is the error that is  A signaled inside the operating system in the event that some user  I application tried to execute the 'br.ia' instruction which switches from  C the traditional IA-64 instruction set and into the Itanium's IA-32  H instruction set handling.  OpenVMS doesn't support those programs.  The G interrupt vector catches this case.  I think we shove the program back  $ into IA-64 mode and raise the error.   --   John Reagan / HP Pascal/{A|I}MACRO for OpenVMS Project Leader  Hewlett-Packard Company    ------------------------------   Date: 24 Feb 2006 15:07:13 GMT( From: bill@cs.uofs.edu (Bill Gunshannon)& Subject: Re: Boy, do I like VMS humor!+ Message-ID: <468lp1Fa07c3U1@individual.net>   - In article <aeFLf.31$BK.190@news.oracle.com>, I 	lederman@star.enet.dec.DISABLE-JUNK-EMAIL.com (Bart Z. Lederman) writes: T > In article <43FE5BA9.8030405@comcast.net>, BRAD <bradhamilton@comcast.net> writes: >>Michael Moroney wrote:J >>> Hmmm, maybe there really is some truth to the rumors of the secret VMS< >>> porting project taking place in the dungeons of ZK03.... >>> & >>> $ write sys$output f$message(3244) >> >>On VMS V7.3-2:" >>write sys$output f$message(3244)J >>%SYSTEM-F-IA32_TRAP, IA-32 trap, reason_mask=!XW, vector=!XB, code=!XW,  >>PC=!XH,PS=!XL  >> > : >>>>IF<<< I were going to speculate on the origins of this; > message, I would first look at the old FX!32 product, and ) > not any secret OpenVMS porting project.   ? Wasn't it originally thought that the Itanium would support the ? execution of x86 to some extent?  Possibly just anticipation of  this possibility.    bill   --  J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>       ------------------------------   Date: 24 Feb 2006 15:08:23 GMT( From: bill@cs.uofs.edu (Bill Gunshannon)& Subject: Re: Boy, do I like VMS humor!+ Message-ID: <468lr7Fa07c3U2@individual.net>   2 In article <RZFLf.3634$8B5.2067@news.cpqcorp.net>,) 	John Reagan <john.reagan@hp.com> writes: 
 > BRAD wrote:  >  >>  L >> Perhaps an example of "latent support"    :-)    Any comment from hp?     >> :-) >>   > K > Sure.  A quick scan of the listings shows that this is the error that is  C > signaled inside the operating system in the event that some user  K > application tried to execute the 'br.ia' instruction which switches from  E > the traditional IA-64 instruction set and into the Itanium's IA-32  J > instruction set handling.  OpenVMS doesn't support those programs.  The I > interrupt vector catches this case.  I think we shove the program back  & > into IA-64 mode and raise the error.  - Haha!!!!  For once I was actually right.  :-)    bill     --  J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>       ------------------------------    Date: 24 Feb 2006 10:10:17 -0600; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) & Subject: Re: Boy, do I like VMS humor!3 Message-ID: <hqSiwlkn6Y7$@eisner.encompasserve.org>   \ In article <43FD878D.CD5DDFB6@teksavvy.com>, JF Mezei <jfmezei.spamnot@teksavvy.com> writes: > Michael Unger wrote:I >> It had been posted to this NG by Charlie Hammond on 2-Apr-2004, thread D >> subject "DCL minute of the Day: integer to string, padded & right >> justified". >  > J > The procedure to identify the right and left hands is flawed. It assumesG > the clock you are using is an antique analog display and not a modern L > 21st century digital clock. Mr Hammond needs to update this documentation.  >    No, if you get a really antique clock it may turn in eitherF    direction.  But the document is correct where I work, where I live,!    where I shop, on my wrist, ...           ------------------------------  + Date: Fri, 24 Feb 2006 18:39:50 +0000 (UTC) P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)& Subject: Re: Boy, do I like VMS humor!$ Message-ID: <dtnjtm$cdu$1@online.de>  H In article <dtllbr$r1g$1@pcls4.std.com>, moroney@world.std.spaamtrap.com (Michael Moroney) writes:   H > Hmmm, maybe there really is some truth to the rumors of the secret VMS: > porting project taking place in the dungeons of ZK03.... > $ > $ write sys$output f$message(3244) >  > (probably only works on V8.2)    On 7.3-2 ALPHA:    News> spa wso f$message(3244) H %SYSTEM-F-IA32_TRAP, IA-32 trap, reason_mask=!XW, vector=!XB, code=!XW,  PC=!XH, PS=!XL   ------------------------------  % Date: Fri, 24 Feb 2006 09:57:27 +0100 + From: Karsten Nyblad <nospam@nospam.nospam> * Subject: Re: Can VMS make files immutable?= Message-ID: <43feca74$0$67257$157c6196@dreader2.cybercity.dk>    Glenn and Mary Everhart wrote:K > It is possible in VMS to do most anything you want without needing BYPASS L > and if you haven't got BYPASS priv enabled, file protections and/or deviceA > protections against system work and restrict what can be done.   > Extraordinary L > measures to control the superuser are not needed because adequate measures > are designed in. >  > Glenn Everhart >  >  > -----Original Message-----, > From: Hoff Hoffman [mailto:hoff@hp.nospam], > Sent: Wednesday, February 22, 2006 2:36 PM > To: Info-VAX@Mvb.Saic.Com < > Subject: Re: Plain truth is that unix/linux is NOT secure! >  > L > In article <dti5j1$o90$1@news.mdx.ac.uk>, david20@alpha2.mdx.ac.uk writes: >  > K > :Can you tell me how to make a file IMMUTABLE under VMS so that not even   > the G > :someone logged in as system can alter the file ? (Mounting the disk   > read-only  > :doesn't count).  G It should be fairly trivial to take out a kernel mode read lock on the  F file.  That would make VMS think that the file is open for read only, ) and even bypass cannot write such a file.   G As Larry Kilgallen points out, nobody can stop a user with change mode  E kernel privilege.  Further, if you have privileges for physical IOs,  C then you can bypass the file system and write directly to the disk.    ------------------------------  + Date: Fri, 24 Feb 2006 14:40:15 +0000 (UTC)  From: david20@alpha2.mdx.ac.uk* Subject: Re: Can VMS make files immutable?) Message-ID: <dtn5sf$fo6$1@news.mdx.ac.uk>   c In article <11vsu3l7bh0ep9f@corp.supernews.com>, Glenn and Mary Everhart <everhart@gce.com> writes: ' >Re making a file "immutable" in VMS...  > < >If he at least recompiles Safety (on VMS SIG tapes c. 2000)= >it will allow this. It can prevent access by anyone desired, = >or if desired can block access by processes with extra privs @ >while allowing it to the peons who have only netmbx and tmpmbx.@ >I replied to the guy via email already, will try to post later. > @ >(BTW I will check that all Safety sources are out there and getE >any stragglers out next time round. The *.bld files have compilation = >commands but kitinstal.com will need to have a few tweaks to B >understand VMS new versions...nothing very serious but some range >checks anyway.) > A >Unfortunately it has not been tested on recent VMS (or at all on < >IA64) but the source is there, and it doesn't intercept DDTE >entries as I recall, so it should not fall afoul of the new routines F >that want to be used for DDT interception. It can also fix matters soC >someone denied access to a file (e.g., by trying to open for write D >when disallowed) opens something else instead (done so you can findH >out what an evildoer intends without risking your real valuable files). > F >Apart from suchlike things I don't believe there's much that standardD >VMS can do about someone who runs with BYPASS turned on. Many of usA >don't leave BYPASS enabled by default even on SYSTEM, but SETPRV  >is still there. > I >I would argue that apart from that, however, VMS has less need for being G >able to make files immutable. Recall, you don't normally run as system M >for very much, and have no choice between a peon account and an all powerful G >superuser as in unix. VMS accounts can already pick and choose what is E >allowed, and running in a mode where your process is allowed to drop G >into kernel as needed BUT not allowed to scribble over anything except J >its own files in the filesystem, is pretty common. (long sentence but you >get the idea.)  > J >It is possible in VMS to do most anything you want without needing BYPASSK >and if you haven't got BYPASS priv enabled, file protections and/or device M >protections against system work and restrict what can be done. Extraordinary K >measures to control the superuser are not needed because adequate measures  >are designed in.  >  >Glenn Everhart  >    Glenn,  M Thanks for the information on Safety. I wasn't actually needing to make files H immutable just pointing out that Bob's critism of OpenBSD was misplaced.H The fact that Theo de Raadt isn't going to fix the optional securelevelsI functionality that protects immutable files in OpenBSD doesn't of itself  L make OpenVMS more secure than OpenBSD since such protection isn't available  in VMS out of the box.O I wasn't aware that your optional Safety product could provide such protection.        
 David Webb Security team leader CCSS Middlesex University     >  >-----Original Message----- + >From: Hoff Hoffman [mailto:hoff@hp.nospam] + >Sent: Wednesday, February 22, 2006 2:36 PM  >To: Info-VAX@Mvb.Saic.Com; >Subject: Re: Plain truth is that unix/linux is NOT secure!  >  > K >In article <dti5j1$o90$1@news.mdx.ac.uk>, david20@alpha2.mdx.ac.uk writes:  >  > M >:Can you tell me how to make a file IMMUTABLE under VMS so that not even the O >:someone logged in as system can alter the file ? (Mounting the disk read-only  >:doesn't count).    ------------------------------    Date: 24 Feb 2006 08:58:05 -0800 From: tim.beaudin@hp.com. Subject: Re: CSWS 2.1 + Tomcat 5.5.9 + mod_jk2C Message-ID: <1140800285.098917.313730@e56g2000cwe.googlegroups.com>    Hi,   F  Just a thought - have you restarted both csws and csws_java? from the release notes posted at:    M http://h71000.www7.hp.com/openvms/products/ips/apache/csws_java_relnotes.html   G                     Error during initial creation of shared memory file   D If the mod_jk2 (Apache 2.1) adapter is enabled for CSWS_JAVA Version
 3.0, an error   ? can occur during the initial creation of the shared memory file ; (shm.file).  The error_log will report the following error:     ? [Thu Jan 15 09:38:50 2004] [error] shm.create(): error creating 9 /apache$root/logs/shm.file 0 22 0x2e0c30 invalid argument   ? [Thu Jan 15 09:38:50 2004] [error] shm.create(): error mmapping  /apache$root/logs/shm.file    E If this error occurs, restart both CSWS and CSWS_JAVA using supported > command procedures. Creation of the shared memory file will beG completed during the first shutdown of CSWS. Do not delete the shm.file  between restarts.       Thanks.  Tim    ------------------------------  + Date: Fri, 24 Feb 2006 18:32:37 +0000 (UTC) P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)T Subject: Re: Entry-level Integrity Servers? (was: Itanium still not on alpha level!)$ Message-ID: <dtnjg5$81c$3@online.de>  
 In articleA <rdeininger-2302061823060001@user-uinj4ma.dialup.mindspring.com>, 8 rdeininger@mindspringdot.com (Robert Deininger) writes:   O > HP still makes and sells single-CPU Integrity systems, and VMS supports them. 5 > They are not particularly hard to find or purchase. > > They are a lot less expensive than single-CPU Alpha systems.= > They are significantly faster for almost every application.   F What is the list price, approximately, of the least expensive Itanium 6 system, including the following essential ingredients:  0    o  twice the supported-minimum-for-VMS memory  
    o  SCSI      o  ethernet    5    o  device to boot from (if non-SCSI-device needed)       o  bootable OS media   '    o  documentation media (CD, DVD etc)    ------------------------------    Date: 24 Feb 2006 08:27:01 -08001 From: "pcoviello@gmail.com" <pcoviello@gmail.com> 5 Subject: Re: file list for ftp in a command procedure C Message-ID: <1140798420.957735.161880@v46g2000cwv.googlegroups.com>   2 great help so far!  now is the following possible?  , $! P1 = start date in the dd-mmm-yyyy format* $! P2 = end date in the dd-mmm-yyyy format $! P3 = month to be processed  $!* $COPY/since='P1'/before='P2'  *.*  [.temp]A $ if P1 .eqs. "" then Inquire start date "Please Enter Start Date  dd-mmm-yyyy = $ if P2 .eqs. "" then Inquire end date "Please Enter End Date  dd-mmm-yyyy  $SET DEF [.temp] $FTP open ftp username passw  dir  mput *.* \DIR\HB\CLAIMS\'P3' $EXIT ) $IF $STATUS is good then DELETE *.*;*/log    ------------------------------    Date: 24 Feb 2006 11:53:18 -0600 From: briggs@encompasserve.org5 Subject: Re: file list for ftp in a command procedure 3 Message-ID: <gVcO1q4C0H1d@eisner.encompasserve.org>   w In article <1140798420.957735.161880@v46g2000cwv.googlegroups.com>, "pcoviello@gmail.com" <pcoviello@gmail.com> writes: 4 > great help so far!  now is the following possible?   [Snip attempted solution]    How about this  , $! P1 = start date in the dd-mmm-yyyy format* $! P2 = end date in the dd-mmm-yyyy formatI $! P3 = month to be processed (name of subdirectory on target FTP server)  $!N $ if P1 .eqs. "" then Inquire start date "Please Enter Start Date dd-mmm-yyyy"J $ if P2 .eqs. "" then Inquire end date "Please Enter End Date dd-mmm-yyyy"4 $ start_date = f$cvtime ( P1, "comparison", "date" )2 $ end_date = f$cvtime ( P2, "comparison", "date" ) $  $ any_files = "FALSE"  $ loop:  $	file = f$search ( "*.*" ) % $	if file .eqs. "" then goto end_loop / $	file_date = f$file_attributes ( file, "RDT" ) : $	file_date = f$cvtime ( file_date, "comparison", "date" )( $	if file_date .ges. start_date  .and. - 	   file_date .les. end_date $	then6 $	    name = f$parse ( file,,, "name", "syntax_only" ); $           ext = f$parse ( file,,, "type", "syntax_only" )  $	    simple_name = name + ext $	    any_files = "TRUE"H $	    copy /ftp 'file ftp"user password"::dir\hb\claims\'P3\'simple_name $	endif  $	goto loop  $  $ end_loop:  $ if .not. any_files $ then, $	write sys$Output "No matching files found" $	exit $ endif  $	 $ exit   ------------------------------    Date: 24 Feb 2006 10:09:53 -08001 From: "pcoviello@gmail.com" <pcoviello@gmail.com> 5 Subject: Re: file list for ftp in a command procedure C Message-ID: <1140804593.593574.242640@i40g2000cwc.googlegroups.com>   E thanks now to figure out why it won't run with date and leaving p1 p2 	 &p3 empty ) and if the date is supplied the following   ; %TCPIP-E-FTP_INPROCF, error processing input file  FILENAME    -RMS-F-UBF, invalid user buffer    thanks again Paul   ------------------------------    Date: 24 Feb 2006 10:23:10 -0600; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) F Subject: Re: Gartner wakes up company executives to X86-64 scalability3 Message-ID: <itlKkHLsiGMO@eisner.encompasserve.org>   s In article <1140613955.752322.149160@f14g2000cwb.googlegroups.com>, "Andrew" <andrew_harrison@symantec.com> writes:  >  > 6 > Being between 2x and 4x faster than the best 2-4 way7 > Itanium/Power5+/x86 systems on the market measured by I > SPECjbb/SPECjappserver, SPECweb, Lotus NotesBench, with a single module 1 > doesn't really support your implied suggestion.   F    Being better than Itanium isn't going to get you very far in c.o.v,%    how do they compare to a real CPU?   H > It also turns out that they arn't bad DBMS servers either as their SAP > numbers demonstrate. > = > http://www.sun.com/servers/coolthreads/t1000/benchmarks.jsp   D    You should know very well by now I wouldn't touch anything sappy.   ------------------------------    Date: 24 Feb 2006 09:06:24 -0800- From: "Andrew" <andrew_harrison@symantec.com> F Subject: Re: Gartner wakes up company executives to X86-64 scalabilityC Message-ID: <1140800784.652981.311070@i40g2000cwc.googlegroups.com>    Bob Koehler wrote:u > In article <1140613955.752322.149160@f14g2000cwb.googlegroups.com>, "Andrew" <andrew_harrison@symantec.com> writes:  > >  > > 8 > > Being between 2x and 4x faster than the best 2-4 way9 > > Itanium/Power5+/x86 systems on the market measured by K > > SPECjbb/SPECjappserver, SPECweb, Lotus NotesBench, with a single module 3 > > doesn't really support your implied suggestion.  > H >    Being better than Itanium isn't going to get you very far in c.o.v,' >    how do they compare to a real CPU?   C Depends what you class as a real CPU, Power5+ or x86-64 would be on B most peoples list and the 2-4x performance lead includes Power and x86-64.   G As and example a single module T2000 has roughly double the SPECweb2005 E throughput compared with a 2 module P550 (4 cores) with 1.9 GHz Power D 5+ and over 3 x the throughput of a 2 module x86 server with 3.8 Ghz P4.   0 http://www.spec.org/web2005/results/web2005.html  E As you can see the T2000 is delivering roughly 4 x the throughput per C module when compared with Power and 6x when compared with x86. This A kind of lead is fairely consistent across other benchmarks. 3.4 x D throughput per module compared with Power 5+ on SPECjappserver (5.3x0 the thoughput per module compared with Itanium).  A This is unprecedented in terms of a performance gap and even more F remarkable because the T1 didn't meet its origional 1.4-1.5 Ghz design: goals and instead these results are with the 1.2 Ghz part.   Regards  Andrew Harrison    ------------------------------  % Date: Fri, 24 Feb 2006 12:40:21 +0100 3 From: "Gorazd Kikelj" <gorazd.kikelj@nospam.hp.com> P Subject: Re: HP Campus program for Integrity Servers in Europe/ Integrity Server* Message-ID: <43fef0a7@usenet01.boi.hp.com>  ? "Malcolm Dunnett" <nothome@spammers.are.scum> wrote in message  & news:rySQCWXkf4jd@malvm9.mala.bc.ca...) > In article <43fc50c6$1@news.ll.iac.es>, + >    Frank Gribbin <fjg@ing.iac.es> writes:  >>I >> I'd also be interested to hear from anyone with experience of the move F >> from Alpha to Itanium/Integrity. My impression is that resellers we< >> contacted don't have much experience of the new machines. > E >  That would match my experience. I think I ordered 3 years worth of D > VMS upgrades but nobody has been able to tell me how I am supposedF > to go about actually getting the new versions when they're released.B > There was some talk of them being available for download but theE > download site only has patch kits, not full OS releases. My fear at F > this point is that when 8.3 comes out the only option HP is going toG > give me is to purchase another full operating environment kit at list  > price. >   
 Hi Malcom,  E you need to select a medium you want to receive your updates in ITRC.   J First step is to link yout sowtware update contract in your ITRC user and E then you can select on what medium (or download) you want to receive  3 updates. Here you can also change delivery address.   
 Best, Gorazd     ------------------------------    Date: 24 Feb 2006 08:28:59 -0800 From: bob@instantwhip.com ' Subject: HP hurting the itanium market! C Message-ID: <1140798538.988079.193950@e56g2000cwe.googlegroups.com>   ) http://www.theinquirer.net/?article=29893    ------------------------------  % Date: Fri, 24 Feb 2006 16:50:37 +0100 , From: Albrecht Schlosser <ajs567@tiscali.de>0 Subject: IA64 VMS V8.2-1: SYSTEM-F-VA_NOTPAGALGN, Message-ID: <f1antd.23b.ln@news.hus-soft.de>   To VMS development:   H There seems to be a bug introduced with OpenVMS V8.2-1 on IA64 that has 6 not been present on V8.2 (IA64) nor on V7.3-2 (Alpha).  @ Analysis: Linker options PSECT_ATTRIBUTES = PAGE, combined with H /DEMAND_ZERO=PER_PAGE _and_ a (FORTRAN) DATA Statement together lead to:  - %DCL-W-ACTIMAGE, error activating image TDATA 0 -CLI-E-IMGNAME, image file ...[TEST]TDATA.EXE;22G -SYSTEM-F-VA_NOTPAGALGN, specified virtual address is not CPU-specific   page aligned  F The following test program works on OpenVMS 7.3-2 (Alpha) and OpenVMS * 8.2 (Itanium), but not on 8.2-1 (Itanium).  
 $ t tdata.for  C           PROGRAM TDATA C &          INTEGER*2       VAR1    (256)(          INTEGER*2       VAR2    (10240) C           COMMON  /TEST1/ VAR1           COMMON  /TEST1/ VAR2  C + D       DATA    VAR1    /100,200,300,253*0/  C           TYPE    *,VAR1(1) C           END
 $ t tdata.com  $! $ tcpip show version $! $!      DATA:   NO $!      DZPP:   YES  $! $ FORT TDATA $!( $ LINK/EXE=TDATA /DEMAND_ZERO=PER_PAGE -$                  TDATA,SYS$INPUT/OPT ! ! PSECT_ATTRIBUTES = TEST1,SHR,PAGE  !  $! $ RUN TDATA  $! $!      DATA:   YES  $!      DZPP:   NO $! $ FORT/D_L TDATA $! $ LINK/EXE=TDATA -$                  TDATA,SYS$INPUT/OPT ! ! PSECT_ATTRIBUTES = TEST1,SHR,PAGE  !  $! $ RUN TDATA  $! $!      DATA:   YES  $!      DZPP:   YES  $! $ FORT/D_LINES TDATA $!( $ LINK/EXE=TDATA /DEMAND_ZERO=PER_PAGE -$                  TDATA,SYS$INPUT/OPT ! ! PSECT_ATTRIBUTES = TEST1,SHR,PAGE  !  $! $ RUN TDATA  $! $ @tdata  K    HP TCP/IP Services for OpenVMS Industry Standard 64 Version V5.5 - ECO 1 :    on an HP rx1620  (1.30GHz/3.0MB) running OpenVMS V8.2-1         0      100 - %DCL-W-ACTIMAGE, error activating image TDATA 0 -CLI-E-IMGNAME, image file ...[TEST]TDATA.EXE;22G -SYSTEM-F-VA_NOTPAGALGN, specified virtual address is not CPU-specific   page aligned $   E The first and second RUN commands work and output 0 and 100, but the  2 third RUN produces the mentioned error message :-(    . The same procedure on V8.2 and V7.3-2 (Alpha):   $ @tdata  C    HP TCP/IP Services for OpenVMS Industry Standard 64 Version V5.5 8    on an HP rx2620  (1.30GHz/3.0MB) running OpenVMS V8.2         0      100      100    $ @tdata  <    HP TCP/IP Services for OpenVMS Alpha Version V5.4 - ECO 2/    on a AlphaServer DS15 running OpenVMS V7.3-2          0      100      100     C I consider this to be a (linker) bug. IIRC, an image that has been  L linked on V8.2 runs okay on V8.2-1, but an image linked on V8.2-1 is faulty.  , I didn't find a related patch. Any comments?  @ (Please don't tell me a workaround, or ask why I need this. The F workaround is to omit /demand_zero=per_page, but it took some time to > track the problem down to this combination of three elements).  I BTW: Help/message doesn't really help, because the error message doesn't  F give any hints, _which_ virtual address ("specified virtual address")  might not be aligned :-(     Albrecht   ------------------------------  % Date: Fri, 24 Feb 2006 17:13:11 +0100 , From: Albrecht Schlosser <ajs567@tiscali.de>4 Subject: Re: IA64 VMS V8.2-1: SYSTEM-F-VA_NOTPAGALGN, Message-ID: <nbbntd.b8b.ln@news.hus-soft.de>   John Reagan wrote: > Albrecht Schlosser wrote:  >> To VMS development: >>G >> There seems to be a bug introduced with OpenVMS V8.2-1 on IA64 that  = >> has not been present on V8.2 (IA64) nor on V7.3-2 (Alpha).  >> > K > It looks somewhat familiar.  I've forwared it to the linker person for a   > more definitive answer.  >   % Wow, thanks for this _fast_ reply :-)    Albrecht   ------------------------------  # Date: Fri, 24 Feb 2006 16:59:21 GMT & From: John Reagan <john.reagan@hp.com>4 Subject: Re: IA64 VMS V8.2-1: SYSTEM-F-VA_NOTPAGALGN2 Message-ID: <JXGLf.3638$WF5.2371@news.cpqcorp.net>   Albrecht Schlosser wrote:  > To VMS development:  > J > There seems to be a bug introduced with OpenVMS V8.2-1 on IA64 that has 8 > not been present on V8.2 (IA64) nor on V7.3-2 (Alpha). >   I It looks somewhat familiar.  I've forwared it to the linker person for a   more definitive answer.    --   John Reagan / HP Pascal/{A|I}MACRO for OpenVMS Project Leader  Hewlett-Packard Company    ------------------------------  # Date: Fri, 24 Feb 2006 18:50:43 GMT & From: John Reagan <john.reagan@hp.com>4 Subject: Re: IA64 VMS V8.2-1: SYSTEM-F-VA_NOTPAGALGN2 Message-ID: <7AILf.3648$1K5.3635@news.cpqcorp.net>   > John Reagan wrote: >  >> Albrecht Schlosser wrote: >> >>> To VMS development:  >>> H >>> There seems to be a bug introduced with OpenVMS V8.2-1 on IA64 that > >>> has not been present on V8.2 (IA64) nor on V7.3-2 (Alpha). >>>  >>J >> It looks somewhat familiar.  I've forwared it to the linker person for  >> a more definitive answer. >> >   ! According to the linker engineer:      Yes, this is a known problem.   G It is the PER_PAGE keyword. In other words, the produced image can't be C activated. The image activator does not take into account that the  H reminder of the segment, the demand zero part, needs to be aligned on a F page boundary. That was implemented in 8.2, but didn't show before we  made the linker keyword public.   G I have this on my list, I know what to change to make it work. It will   be in V8.3.      --   John Reagan / HP Pascal/{A|I}MACRO for OpenVMS Project Leader  Hewlett-Packard Company    ------------------------------  % Date: Fri, 24 Feb 2006 19:26:30 +0100 , From: Albrecht Schlosser <ajs567@tiscali.de>4 Subject: Re: IA64 VMS V8.2-1: SYSTEM-F-VA_NOTPAGALGN, Message-ID: <n5jntd.vuc.ln@news.hus-soft.de>   John Reagan wrote: > !   > Yes, this is a known problem.  > I > It is the PER_PAGE keyword. In other words, the produced image can't be E > activated. The image activator does not take into account that the  J > reminder of the segment, the demand zero part, needs to be aligned on a H > page boundary. That was implemented in 8.2, but didn't show before we ! > made the linker keyword public.  > I > I have this on my list, I know what to change to make it work. It will  
 > be in V8.3.    Thanks, that sounds good :-)   Will there also be a patch?    Albrecht   ------------------------------  % Date: Fri, 24 Feb 2006 10:08:49 +0100 ( From: "Rudolf Wingert" <win@fom.fgan.de>. Subject: Re: Itanium still not on alpha level!3 Message-ID: <003301c63921$ed021b00$994614ac@wat153>    Hello, Andrew (SUN) Harrison wrotes:  >>> F This is plainly untrue. The 1.6GHz 9MB cache Itanium does 1580 SPECintB and 2700 SPECfp as oposed to the EV7z 1.3Ghz which does under 1000 SPECint and under 1700 SPECfp. <<< E Andrew, your mistake is, that you match only CPU spec's. If you would E have a look at the TOP500, you will see that an Alpha was a long time H under the top10. The spec's of the single CPU was less then other singleB CPUs. In the old day I made the same experience with the VAX11/780F (1VUP) vs. 3xxx/48 (4.8VUP). The single user performance of the latterF was much better (in most cases). But if you have more then one user onH it, the good old VAX11/780 did outperform the latter one. If you compareE apples with apples (in this case Alpha vs. Itanium under OpenVMS) you G will see, that the good old lady do outperform the newest Itanium (last A what I did hear 2:1). If you information about the performance of > OpenVMS on Itanium is newer, then be free to make them public. Best regards R. Wingert    ------------------------------  # Date: Fri, 24 Feb 2006 10:34:32 GMT 5 From: rdeininger@mindspringdot.com (Robert Deininger) . Subject: Re: Itanium still not on alpha level!L Message-ID: <rdeininger-2402060534310001@user-uinj44f.dialup.mindspring.com>  D In article <003301c63921$ed021b00$994614ac@wat153>, "Rudolf Wingert" <win@fom.fgan.de> wrote:   >Hello,  >Andrew (SUN) Harrison wrotes: >>>>G >This is plainly untrue. The 1.6GHz 9MB cache Itanium does 1580 SPECint C >and 2700 SPECfp as oposed to the EV7z 1.3Ghz which does under 1000  >SPECint and under 1700 SPECfp.  ><<<F >Andrew, your mistake is, that you match only CPU spec's. If you wouldF >have a look at the TOP500, you will see that an Alpha was a long timeI >under the top10. The spec's of the single CPU was less then other single C >CPUs. In the old day I made the same experience with the VAX11/780 G >(1VUP) vs. 3xxx/48 (4.8VUP). The single user performance of the latter G >was much better (in most cases). But if you have more then one user on I >it, the good old VAX11/780 did outperform the latter one. If you compare F >apples with apples (in this case Alpha vs. Itanium under OpenVMS) youH >will see, that the good old lady do outperform the newest Itanium (lastB >what I did hear 2:1). If you information about the performance of? >OpenVMS on Itanium is newer, then be free to make them public.  >Best regards R. Wingert  ) Rudolf, in this case you are out of date.   J On small systems, current Itaniums running VMS V8.2-1 (or V8.3) outperformH small Alpha systems like DS15 and DS25 for a wide variety of workloads. D It would be hard to find a real application that ran half as fast on Itanium as on Alpha.  G You are right to discount benchmarks; they are easily manipulated.  You " need to try a real-world workload.  H Why are the Itanium systems faster?  There are several factors that seem to contribute...N 1. The Itanium CPUs are faster than Alpha EV68 (or EV7) for most applications.J 2. The whole I/O subsystem is now a generation ahead of Alpha.  This isn't$ surprising, but is worth mentioning.= 3. The whole memory subsystem is faster.  Again, so surprise.   I The rx1620 and rx2620 really shine in I/O and memory utilization compared I to similar size Alpha systems.  The rx4640 is still good, but with 4 CPUs ? some workloads will see a Front-Side Bus and/or I/O bottleneck.   J In the bigger systems, the fast interconnect in EV7 AlphaServers shows itsF worth.  Current big Integrity servers just can't keep up for workloadsJ that move a lot of data between CPUs.  The next generation will narrow the' gap, but maybe not close it completely.    ------------------------------    Date: 24 Feb 2006 03:33:58 -0800- From: "Andrew" <andrew_harrison@symantec.com> . Subject: Re: Itanium still not on alpha level!C Message-ID: <1140780838.436180.282930@e56g2000cwe.googlegroups.com>    Rudolf Wingert wrote:  > Hello, > Andrew (SUN) Harrison wrotes:  > >>> H > This is plainly untrue. The 1.6GHz 9MB cache Itanium does 1580 SPECintD > and 2700 SPECfp as oposed to the EV7z 1.3Ghz which does under 1000  > SPECint and under 1700 SPECfp. > <<< G > Andrew, your mistake is, that you match only CPU spec's. If you would G > have a look at the TOP500, you will see that an Alpha was a long time J > under the top10. The spec's of the single CPU was less then other singleD > CPUs. In the old day I made the same experience with the VAX11/780H > (1VUP) vs. 3xxx/48 (4.8VUP). The single user performance of the latterH > was much better (in most cases). But if you have more then one user onJ > it, the good old VAX11/780 did outperform the latter one. If you compareG > apples with apples (in this case Alpha vs. Itanium under OpenVMS) you I > will see, that the good old lady do outperform the newest Itanium (last C > what I did hear 2:1). If you information about the performance of @ > OpenVMS on Itanium is newer, then be free to make them public. > Best regards R. Wingert   D However the current crop of Itanium servers also have better I/O andC with the exception  olf  the GS1280 better bisectional bandwidth as  well.   C Your top500 example is actually a good illustration of how far back C Alpha has slipped. ASCI-Q the highest placed Alpha system uses 8192 F processors to get a RMAX  score of 13880. The highest placed commodityD based Itanium system uses 4096 CPU's to get a RMAX score of 19940 or@ put another way the Itanium CPU's are delivering over double theC throughput compared with Alpha. Now you could argue that the Alphas D arn't the fastest available which would be true but then the ItaniumE processors used in Thunder are 1.4 Ghz 4MB cache units not the faster  1.6Ghz 9MB cache units.    Regards  Andrew Harrison    ------------------------------  % Date: Fri, 24 Feb 2006 07:07:38 -0500 ) From: "Neil Rieck" <n.rieck@sympatico.ca> . Subject: Re: Itanium still not on alpha level!: Message-ID: <aGCLf.24863$%14.607684@news20.bellglobal.com>  8 "rcyoung" <rcyoung@aliconsultants.com> wrote in message = news:1140705818.165819.325250@g43g2000cwa.googlegroups.com... G >I don't have a good set for cross comarisions, but we do have (2) 2100 C > Alpha dual processor systems,  a rx2600 I64, and (2) 4000/500 Vax F > systems, all being used as software development machines. The rx2600( > blows all the others out of the water. >   J I initially made the case to move from VAX to Alpha by using manufacturer 7 published product comparisons. Here is the current URL: 2 http://h18002.www1.hp.com/alphaserver/performance/M The comparison is not scientific (and is in units called PERFs) but at least  C it will provide a decent rule of thumb to take to upper management.   ( Occasionally I browse through this area:9 http://h71000.www7.hp.com/openvms/integrity/products.html J and have not yet seen something comparing Alpha to Itanium. So until I do H see a chart, I'm going to assume that Itanium/Integrity numbers are not  worth publishing.   
 Neil Rieck Kitchener/Waterloo/Cambridge,  Ontario, Canada.8 http://www3.sympatico.ca/n.rieck/links/cool_openvms.html   ------------------------------  # Date: Fri, 24 Feb 2006 15:46:11 GMT & From: John Reagan <john.reagan@hp.com>5 Subject: Re: object names from executable image files 2 Message-ID: <7TFLf.3633$YE5.1616@news.cpqcorp.net>   JF Mezei wrote:  > bdhobbs18@acm.org wrote: > F >>how would a COBOL call data-name work when the value in data-name is >>assembled at run time.   >  > G > Actually, at run time, the image doesn't need to know the name of the ; > subroutines. Only the offset from the start of the image.   D But for COBOL's call by name, there is a table of routine/paragraph I names to addresses.  However, that is COBOL-specific and doesn't need to   contain all paragraph names.     --   John Reagan / HP Pascal/{A|I}MACRO for OpenVMS Project Leader  Hewlett-Packard Company    ------------------------------    Date: 24 Feb 2006 06:02:01 -0800+ From: "Dr. Dweeb" <comp.os.vms@hotmail.com> 5 Subject: Re: OpenVMS proves superior to all other OSs C Message-ID: <1140789721.129231.251980@u72g2000cwu.googlegroups.com>   / I have an LK461-A2 connected to an Dell XP box.   G There is no driver for it, only an old LK411 driver for NT, which XP is  not too happy with. F I use Reflection, which has LK450 keyboard mapping support supposedly.  , Bottom line is that it simply does not work.  F Windows keeps reinstalling the default kbd at boot time, and dependingD which application is in focus, switches the keyboard.  F19, F20, Do,! F13 do not work under reflection.   D Given that HP and VMS have dictated that we use PCs to access VMS inD character mode, the very least you could have done is write a decentA kbd driver for the LK4xx keyboards to make our lives tolerable !!    ------------------------------    Date: 24 Feb 2006 07:50:36 -0800( From: "Rich Jordan" <jordan@ccs4vms.com>5 Subject: Re: OpenVMS proves superior to all other OSs B Message-ID: <1140796236.109530.13090@v46g2000cwv.googlegroups.com>  E A number of our customers, mainly in financial and financial services F business use and prefer VT420 and 510 terminals over PCs.  They take aE lot less room, generally less power, cost less (unless you buy crappy D peecees), run longer, have vanishingly small maintenance costs, _no_D upgrade costs, and are much faster for data entry within the limitedE requirements of the business. They can even do non-graphic email with  Pine.   D They also don't provide internet access, minefield, solitaire, and aC lot of other productivity killing time wasters that are totally not 1 necessary to the jobs of the folks that use them.   F Where customers have decided to switch to peecees, we put Powerterm onE them for emulation, but we've heard from a lot of folks how, although ? they like having the windows and the browser and the email with E pictures and the games, that they miss the ease of use, and the total D lack of required maintenance and upgrades of their terminals.  And a? _lot_ of them have really come to miss their LK401 keyboards...   F So I'm going to go with a different analogy; the terminal _is_ the oldB solid reliable low-optioned pickup truck, not a buggy.  It isn't aD futzed up techno-wiz convertible Avalanche SUV/truck/camper/portableF hotel room with jacuzzi, but it'll still do everything it was designedG to do without fuss or bother, and within that limit, do so a darn sight 2 more efficiently and cheaply than a wintel peecee.   ------------------------------    Date: 24 Feb 2006 09:42:00 -0600; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) 5 Subject: Re: OpenVMS proves superior to all other OSs 3 Message-ID: <VvStmQiYpJe1@eisner.encompasserve.org>   _ In article <1140545372.781679.281670@g14g2000cwa.googlegroups.com>, bob@instantwhip.com writes: . > when is security and uptime not practical??? >        When your name is Bill.    ------------------------------   Date: 24 Feb 2006 16:45:39 GMT( From: bill@cs.uofs.edu (Bill Gunshannon)5 Subject: Re: OpenVMS proves superior to all other OSs + Message-ID: <468rhjF9nok6U1@individual.net>   0 In article <00A51CB9.FDF9EF37@sendspamhere.org>,# 	VAXman-  @SendSpamHere.ORG writes:  > N >>Use a X11 emulator or a terminal emulator.  There are many remote management0 >>tools for managing and updating the PC itself. > N > Those are all "add-on" items like the screen-scraper server.  If the X11 en-N > vironment goes belly-up (like the screen-scraper server several times a day)N > where are we now?... back in the same boat bailing out the sinking ship with$ > the same old manual reboot teacup.  I I have been using VNC since the NASA days and have never had a VNC server F go "belly-up" when it wasn't the whole machine that went dead.  PrettyH much the same for X11 except I have been using it even longer (since theF MIT days, I think about V2).  And when the whole maschine goes down itA doesn't really matter which program you were using at the moment.    bill    --  J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>       ------------------------------    Date: 24 Feb 2006 09:50:55 -0600; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) : Subject: Re: Plain truth is that unix/linux is NOT secure!3 Message-ID: <mnHVptwRM6eY@eisner.encompasserve.org>   k In article <43fc37de$0$67256$157c6196@dreader2.cybercity.dk>, Karsten Nyblad <nospam@nospam.nospam> writes:  > bob@instantwhip.com wrote:? >> you don't just get bypass priviledge ... someone has to give  >> it to you ... >>  G > Getting the password for root on *NIX is just as easy as getting the  C > password for OpenVMS.  Besides, people are putting more and more  J > security into Linux.  I am far from certain that OpenVMS is more secure H > by design than newer Linux any Unix variants.  Please note that while F > OpenVMS is standing still, *NIX is moving forward with new security  > features being added.   F    *NIX is all the way up to early 1980's security technology.  PrettyG    good for something burdened with the flaws of an overall late 1960's 
    design.  E    Meanwhile OpenVMS moves on, whether you want to believe it or not.    ------------------------------    Date: 24 Feb 2006 09:53:40 -0600; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) : Subject: Re: Plain truth is that unix/linux is NOT secure!3 Message-ID: <MhKBefACzf0B@eisner.encompasserve.org>   J In article <dti5j1$o90$1@news.mdx.ac.uk>, david20@alpha2.mdx.ac.uk writes: >  > Bob, > N > Can you tell me how to make a file IMMUTABLE under VMS so that not even the P > someone logged in as system can alter the file ? (Mounting the disk read-only  > doesn't count).  >   H    I don't know about the other guy, but I'd copy it to CD-R, since that    isn't read-only.  	8-)    ------------------------------    Date: 24 Feb 2006 09:48:47 -0600; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) : Subject: Re: Plain truth is that unix/linux is NOT secure!3 Message-ID: <0OodBIaeVOXm@eisner.encompasserve.org>   Y In article <ReednZUH0fz0KmbeRVn-gQ@libcom.com>, Dave Froble <davef@tsoft-inc.com> writes: H > It's not that Unix has a 'root' user.  The issue is how easy it is to  > get 'root' login/privs.  > G > Are you going to tell me that BYPASS is any less of a security issue   > than the 'root' user on Unix?   E    No the problem is that the mail program on UNIX runs as root.  The 0    mail program on VMS does not run with BYPASS.   ------------------------------    Date: 24 Feb 2006 09:51:41 -0600; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) : Subject: Re: Plain truth is that unix/linux is NOT secure!3 Message-ID: <+gaKOvOZgMEC@eisner.encompasserve.org>   c In article <TPWtKC6$jOOC@eisner.encompasserve.org>, Kilgallen@SpamCop.net (Larry Kilgallen) writes: m > In article <43fc37de$0$67256$157c6196@dreader2.cybercity.dk>, Karsten Nyblad <nospam@nospam.nospam> writes:  > H >> Getting the password for root on *NIX is just as easy as getting the D >> password for OpenVMS.  Besides, people are putting more and more K >> security into Linux.  I am far from certain that OpenVMS is more secure  0 >> by design than newer Linux any Unix variants. > H > How does Unix handle users attempting to overflow the password history
 > buffer ?  G   As in all things UNIX, it depends on the UNIX.  What you can count on ?    is a very good chance of not even having a password history.    ------------------------------    Date: 24 Feb 2006 09:55:38 -0600; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) : Subject: Re: Plain truth is that unix/linux is NOT secure!3 Message-ID: <s5045hDxDwZo@eisner.encompasserve.org>   c In article <Gp7RYCja26if@eisner.encompasserve.org>, Kilgallen@SpamCop.net (Larry Kilgallen) writes:  > I > It also would not work, for the same reason.  Mounting a disk read-only J > is a software convention, honored by operating system software, and thus  > susceptible to being bypassed.  C    Not on an RA90, RA81, RA60, RP06, RP07, RM05, RM03, RX01, RX02,  ,    5 1/4 inch floppy, 3 1/2 inch floppy, ...  $    Lots of hardware has write locks.   ------------------------------    Date: 24 Feb 2006 09:56:27 -0600; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) : Subject: Re: Plain truth is that unix/linux is NOT secure!3 Message-ID: <x65oJiBAa5pG@eisner.encompasserve.org>   r In article <1140639290.504049.167060@g47g2000cwa.googlegroups.com>, "rcyoung" <rcyoung@aliconsultants.com> writes:I > In fact there is no "secure" OS. ALL of them have a weakness somewhere. C > The systems themselves are too complex not to have loop holes and E > glitches buried in them....if you know how and were to look. So the " > entire argument is largely moot. >   D     Bull.  I write good software for a living.  I know there doesn't    "have to be" weaknesses.    ------------------------------    Date: 24 Feb 2006 10:08:27 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen) : Subject: Re: Plain truth is that unix/linux is NOT secure!3 Message-ID: <U8qfPVN$TOfM@eisner.encompasserve.org>   q In article <+gaKOvOZgMEC@eisner.encompasserve.org>, koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: e > In article <TPWtKC6$jOOC@eisner.encompasserve.org>, Kilgallen@SpamCop.net (Larry Kilgallen) writes: n >> In article <43fc37de$0$67256$157c6196@dreader2.cybercity.dk>, Karsten Nyblad <nospam@nospam.nospam> writes: >>  I >>> Getting the password for root on *NIX is just as easy as getting the  E >>> password for OpenVMS.  Besides, people are putting more and more  L >>> security into Linux.  I am far from certain that OpenVMS is more secure 1 >>> by design than newer Linux any Unix variants.  >>  I >> How does Unix handle users attempting to overflow the password history  >> buffer ?  > I >   As in all things UNIX, it depends on the UNIX.  What you can count on A >    is a very good chance of not even having a password history.   I Oh I know there are lots of insecure Unix variants out there.  I was just G waiting for one of those people who claim (some) Unix is secure to step F up the the plate and explain how their best-in-class Unix handles this particular problem.   ( Bob, I guess you are not that person :-)   ------------------------------    Date: 24 Feb 2006 10:09:59 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen) : Subject: Re: Plain truth is that unix/linux is NOT secure!3 Message-ID: <EMw9jBhrEkeh@eisner.encompasserve.org>   q In article <s5045hDxDwZo@eisner.encompasserve.org>, koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: e > In article <Gp7RYCja26if@eisner.encompasserve.org>, Kilgallen@SpamCop.net (Larry Kilgallen) writes:  >>  J >> It also would not work, for the same reason.  Mounting a disk read-onlyK >> is a software convention, honored by operating system software, and thus ! >> susceptible to being bypassed.  > E >    Not on an RA90, RA81, RA60, RP06, RP07, RM05, RM03, RX01, RX02,  . >    5 1/4 inch floppy, 3 1/2 inch floppy, ... > & >    Lots of hardware has write locks.  D Hardware write-lock invoked at the request of software, since it canD be un-requested by software (through a dismount and remount at worstC case).  I believe hardware write-lock was excluded from the initial 
 challenge.   ------------------------------    Date: 24 Feb 2006 10:04:47 -0600; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) : Subject: Re: Plain truth is that unix/linux is NOT secure!3 Message-ID: <R7n2p07vkr5x@eisner.encompasserve.org>   k In article <43fd6970$0$67257$157c6196@dreader2.cybercity.dk>, Karsten Nyblad <nospam@nospam.nospam> writes: B > *NIX does not need supervisor mode because the command language I > interpreter does not run in the same process as the user applications.    D    That's UNIX's problem.  It means there are lot of things that youB    can't well do.  Like setting a shell variable that will be seen    by the parent shell.   J > *NIX protect the command language interpreter in a simpler way than VMS C > but the *NIX way is at least as efficient.  Thus VMS uses a more  I > complicated code to do something that could be done in a simpler.  Any  J > security expert will tell you to keep you security related code simple, F > so the *NIX design of running the command language interpreter is a = > better design as seen from a purely security point of view.   $    "Any" security expert?  Not mine.  D    If a "security expert" tells you so, then they're just don't knowG    better.  Of course, if they work for Billy they'll claim the Windows     way is more secure, instead.   @    Of all the "security experts" I've met, few have any idea VMSD    exists, or how it does things.  (Pick one:  DEC's fault, Compaq's@    fault, HP's fault).  Most are just reguritating the hype they-    learned from some other "security expert".    ------------------------------   Date: 24 Feb 2006 16:50:45 GMT( From: bill@cs.uofs.edu (Bill Gunshannon): Subject: Re: Plain truth is that unix/linux is NOT secure!+ Message-ID: <468rr4F9nok6U2@individual.net>   3 In article <R7n2p07vkr5x@eisner.encompasserve.org>, > 	koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:m > In article <43fd6970$0$67257$157c6196@dreader2.cybercity.dk>, Karsten Nyblad <nospam@nospam.nospam> writes: C >> *NIX does not need supervisor mode because the command language  J >> interpreter does not run in the same process as the user applications.  > F >    That's UNIX's problem.  It means there are lot of things that youD >    can't well do.  Like setting a shell variable that will be seen >    by the parent shell.   G That has nothing to do with wether or not Unix has a root or superviser E user it has to do with the design of the shell.  If it was desired by I Unix users the capabilty to define variables that can be seen system wide H could be implemented.  But the fact is, even after all these years, Unix) users don't see it as anything they need.    bill   --  J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>       ------------------------------   Date: 24 Feb 2006 16:54:14 GMT( From: bill@cs.uofs.edu (Bill Gunshannon): Subject: Re: Plain truth is that unix/linux is NOT secure!+ Message-ID: <468s1lF9nok6U3@individual.net>   3 In article <x65oJiBAa5pG@eisner.encompasserve.org>, > 	koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:t > In article <1140639290.504049.167060@g47g2000cwa.googlegroups.com>, "rcyoung" <rcyoung@aliconsultants.com> writes:J >> In fact there is no "secure" OS. ALL of them have a weakness somewhere.D >> The systems themselves are too complex not to have loop holes andF >> glitches buried in them....if you know how and were to look. So the# >> entire argument is largely moot.  >>   > F >     Bull.  I write good software for a living.  I know there doesn't >    "have to be" weaknesses.   F And while I don't do it exclusively for a living today I have and I doG still write software off and on and I agree competely.  And, yes, among E other languages, I write programs in C, too, that meet this paradigm.    bill   --  J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>       ------------------------------   Date: 24 Feb 2006 18:53:50 GMT( From: bill@cs.uofs.edu (Bill Gunshannon): Subject: Re: Plain truth is that unix/linux is NOT secure!+ Message-ID: <46931tFa1foeU1@individual.net>   3 In article <U8qfPVN$TOfM@eisner.encompasserve.org>, 0 	Kilgallen@SpamCop.net (Larry Kilgallen) writes:s > In article <+gaKOvOZgMEC@eisner.encompasserve.org>, koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: f >> In article <TPWtKC6$jOOC@eisner.encompasserve.org>, Kilgallen@SpamCop.net (Larry Kilgallen) writes:o >>> In article <43fc37de$0$67256$157c6196@dreader2.cybercity.dk>, Karsten Nyblad <nospam@nospam.nospam> writes:  >>> J >>>> Getting the password for root on *NIX is just as easy as getting the F >>>> password for OpenVMS.  Besides, people are putting more and more M >>>> security into Linux.  I am far from certain that OpenVMS is more secure  2 >>>> by design than newer Linux any Unix variants. >>> J >>> How does Unix handle users attempting to overflow the password history >>> buffer ? >>  J >>   As in all things UNIX, it depends on the UNIX.  What you can count onB >>    is a very good chance of not even having a password history. > K > Oh I know there are lots of insecure Unix variants out there.  I was just I > waiting for one of those people who claim (some) Unix is secure to step H > up the the plate and explain how their best-in-class Unix handles this > particular problem.   E I guess the big problem is that no unix users to date have thought it F was useful enough to ask for.  Considering that all the code to handleD password history would be within one program that doesn't run insideF the kernel at all, it would be fairly trivial to add any form of pass-C word history you wanted.  But, like most things, if no one wants it 8 no one is going to put forth the effort to implement it.  E Just out of curiosity, define for me what you consider a proper pass- B word history scheme.  Maybe I'll implement it in my spare time andD release it to the world.  Then we can watch and see if anyone really cares.  :-)    bill   --  J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>       ------------------------------  + Date: Fri, 24 Feb 2006 18:22:44 +0000 (UTC) P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)( Subject: question about VMS732_LMF-V0200$ Message-ID: <dtnitk$81c$2@online.de>  1 A new patch has been announced: VMS732_LMF-V0200.    In part, the announcement says:   H ---------8<-------------------------------------------------------------  ;      INSTALL_2 : To be installed by all customers using the &                  following feature(s):         -  PCL license management   A      2.3  Version(s) of OpenVMS to which this kit may be applied:         OpenVMS ALPHA V7.3-2   =      2.4  New functionality or new hardware support provided:         Yes  F 5  NEW FUNCTIONALITY AND/OR PROBLEMS ADDRESSED IN THE VMS732_LMF-V0200    KIT  1      5.1  New functionality addressed in this kit   #           5.1.1  Per-Core Licensing   2                5.1.1.1  Functionality Description:  C                The next version of the OpenVMS Industry standard 64 F                operating system will introduce support for new type ofD                licenses - Per-Core Licenses (PCL).  PCL licenses areC                intended to support the next generation of Integrity                 servers.   F                This change adds the ability to manage and generate PCLD                licenses from prior versions of the operating system.H                More details on PCL licenses will be available in the New2                Features manual of the new version.  H ---------8<-------------------------------------------------------------  ' Do PCL licenses exist already on ALPHA?   E I am certainly not using them.  I have not consciously installed any  H software to do so.  CAN I install the patch?  (I prefer keeping patches H up to date so that I don't have to remember to install them if I decide 9 to use a feature in the future which I am not using now.)   E It seems to be an Itanium-only feature; what's the point of an ALPHA   patch?  D Since there was no equivalent VAX announcement, I conclude that the G number of folks planning to migrate from VAX to Itanium, at least with   no ALPHA in-between, is small.  E By the way, has it been decided yet whether 7.3 will remain the last   version of VMS for VAX?    ------------------------------    Date: 24 Feb 2006 02:53:33 -0800' From: "Kaushal" <etheticgame@gmail.com> % Subject: Re: Regarding SDA Extension. C Message-ID: <1140778413.553385.159720@t39g2000cwt.googlegroups.com>   E hey i just cant get you. I just want to know, whether we can write an  sda extension using c++ or not.    ------------------------------    Date: 24 Feb 2006 08:19:20 -0800 From: bob@instantwhip.com 5 Subject: Re: Rich Marcello in VMS mention shocker :-) C Message-ID: <1140797960.488066.131390@v46g2000cwv.googlegroups.com>   G vms should be a huge growth market for them, but it is being mismanaged % either on purpose or by stupidity ...    ------------------------------    Date: 24 Feb 2006 08:58:53 -0800* From: "Brice Buchanan" <BriceBu@gmail.com>5 Subject: Re: Rich Marcello in VMS mention shocker :-) C Message-ID: <1140800332.943851.295460@i39g2000cwa.googlegroups.com>   A " '... the people who are on OpenVMS pretty much want to be there E forever.' ... The next five years look to be a lot better for Itanium 1 than the past five years. That much is for sure."   < Cool. For a peon like me, this reads as "job security."  ;-)   ------------------------------    Date: 24 Feb 2006 09:11:35 -0800 From: lmcgaughey@parsec.com 7 Subject: Rocky Mountain Local Users Group March Meeting B Message-ID: <1140801095.861203.57340@u72g2000cwu.googlegroups.com>  
 Greetings!  G PARSEC Group would like to invite you to the next meeting for the Rocky F Mountain Local Users Group (RMLUG) here at our NEW offices in downtown Denver.   D RMLUG exists for the VMS community to have a chance to come togetherE and discuss issues, as well as to advance the platform. Whatever your A level of experience, it is our hope that this group will help you ) learn, grow, and network with each other.    When: Thursday, March 9, 2006   F Where: PARSEC Group, 999 18th Street, Suite 1725 (in the North Tower), Denver, CO 80202   Time: 6:30 p.m. - 8:30 p.m.   D RSVP: Please let us know to expect you by calling Laura McGaughey atF 720-962-9583 or by emailing her at lmcgaughey@parsec.com no later than noon on Friday, March 3.  B Snacks will be served and we will be discussing the recent OpenVMSB Ambassadors meeting in Nashua, NH, as well as the Integrity Server# Users Conference in Richardson, TX.   # We look forward to seeing you here!    PARSEC Group 888-4-PARSEC 999 18th Street, Suite 1725  Denver, CO 80202 www.parsec.com www.openvmsplanet.org    ------------------------------  % Date: Fri, 24 Feb 2006 10:32:42 -0500 C From: "David Turner, Island Computers US Corp" <dbturner@icusc.com>   Subject: Sales of Alpha Systems?: Message-ID: <6yFLf.57163$697.23700@bignews3.bellsouth.net>  A Curious, how many of you are going the Itanium way any time soon? F And if you are, what is left in the way of Alpha systems/workstations?  L Reason for asking is that we are looking at inventory wondering what we need% to stock for the next couple of years J If anyone can enlighten us to what they will be sparing up on - and beforeL you ask - no we are not trying to generate sales from this post; just trying& to figure out our direction with stock  K We would be very curious also to see what kind of pricing the base RX1620-2 @ is going for as we can't seem to find anyone to send us a quote.) We need one here for training/examination    DT       --     David B Turner Island Computers US Corp 2700 Gregory St, Suite 180 Savannah GA 31404  Tel: 912 447 6622 X201 Cell: 912 447 6622 X252  Fax: 912 201 0402  Email: dbturner@icusc.com  Web: http://www.islandco.com% ===================================== < All orders are subject to the following terms and conditions. of sale. These should be read before ordering.% http://www.islandco.com/warranty.html    ------------------------------  % Date: Fri, 24 Feb 2006 12:24:56 -0500 2 From: "Stanley F. Quayle" <squayle@insight.rr.com>$ Subject: Re: Sales of Alpha Systems?. Message-ID: <43FEFB18.11608.DF93669@localhost>  = On 24 Feb 2006 at 10:32, David Turner, Island Computer wrote: D > We would be very curious also to see what kind of pricing the baseD > RX1620-2 is going for as we can't seem to find anyone to send us a2 > quote. We need one here for training/examination  E If you pay my travel expenses and the cost of the course ($2k), I'll  E go to the next Integrity porting camp and have the rx1620 shipped to  D you.  I think there are a few scheduled for this year, at least for  HP-UX.  E Failing that, you should be able to get a price for a system through   DSPP.   
 --Stan Quayle  Quayle Consulting Inc.  
 ----------8 Stanley F. Quayle, P.E. N8SQ  Toll free: 1-888-I-LUV-VAX3 8572 North Spring Ct., Pickerington, OH  43147  USA 0 stan-at-stanq-dot-com       http://www.stanq.com) "OpenVMS, when downtime is not an option"    ------------------------------  # Date: Fri, 24 Feb 2006 11:24:43 GMT " From:   VAXman-  @SendSpamHere.ORG Subject: Re: save_set on DVD0 Message-ID: <00A51C93.76C72A2D@SendSpamHere.ORG>  K In article <OSpLf.38$IY4.7@fe06.lga>, "Dan Moore" <dmoore@sosu.edu> writes:  >  >  >>> M >>>  Any suggestions on getting the PC out of the loop or at least preserving D >>>the save_set file characterisitic when burning the DVD on the PC? >>J >> Assuming you are creating the backup saveset with its normal block size* >> of 32,256, you can mount the DVD with : >>; >> $ MOUNT/OVER=ID/UNDEF=(FIXED:NONE:32256) dvd-device-name  >> >> -- 4 >> VAXman- A Bored Certified VMS Kernel Mode Hacker  >> VAXman(at)TMESIS(dot)COM  >  >  >That did the trick. Thanks!  F Welcome.  You did ask how to access the saveset directly from the DVD.   --  K VAXman- A Bored Certified VMS Kernel Mode Hacker   VAXman(at)TMESIS(dot)COM              5   "Well my son, life is like a beanstalk, isn't it?"     ------------------------------   End of INFO-VAX 2006.110 ************************