1 INFO-VAX	Fri, 17 Dec 2004	Volume 2004 : Issue 699       Contents:* Free: PATHWORKS for DOS DECnet users Guide Re: How to get a free iPod?  Re: HP exodus to Intel Re: HP exodus to Intel Re: HP exodus to Intel Re: HP exodus to Intel Re: HP exodus to Intel Re: HP exodus to Intel Re: HP exodus to Intel) Re: HP pulls out of IA64 chip development ) Re: HP pulls out of IA64 chip development ) Re: HP pulls out of IA64 chip development  Re: Interesting coding tidbit  Re: Interesting coding tidbit  Re: Interesting coding tidbit  Re: Interesting coding tidbit ! more LPD problems with TCPIP V5.4  Re: More on Tru64  Re: More on Tru64 3 More PHP vulnerabilities; is the VMS port affected?  Re: NYSE and HP servers + Re: OT: Display technology at euro stadiums  Robison dumps HP stock soon to be gone  Re: soon to be gone  Re: soon to be gone  Re: soon to be gone  Re: Time to revive Emerald?  Re: Time to revive Emerald?  Re: Time to revive Emerald?  RE: Time to revive Emerald?  Re: Time to revive Emerald?  Re: Time to revive Emerald?  Re: Time to revive Emerald?  Re: Time to revive Emerald?  Re: Time to revive Emerald?  Re: Time to revive Emerald? @ Re: [Nomex on]: Security research suggests Linux has fewer flaws> [OpenVMS Alpha V7.3-2] GETDVI Item for Volume Size and Limit ?B Re: [OpenVMS Alpha V7.3-2] GETDVI Item for Volume Size and Limit ?B Re: [OpenVMS Alpha V7.3-2] GETDVI Item for Volume Size and Limit ?B Re: [OpenVMS Alpha V7.3-2] GETDVI Item for Volume Size and Limit ?B Re: [OpenVMS Alpha V7.3-2] GETDVI Item for Volume Size and Limit ?  F ----------------------------------------------------------------------  % Date: Fri, 17 Dec 2004 11:59:02 -0500 $ From: Mike Duffy <Duffy@process.com>3 Subject: Free: PATHWORKS for DOS DECnet users Guide J Message-ID: <63D30D6E10CFD11190A90000F805FE8605AED28C@lespaul.process.com>  6 I need to get rid of stuff I'm finding in my basement,9 and have some pieces of DEC history I must unfortunately  
 part with.  6 If anyone's interested in the PATHWORKS for DOS DECnet7 User's Guide (September 1991, part number AA-PAFGC-TK), ; it's free.  Just pay for mailing (from Baltimore, MD, USA.)   8 It talks about using DECnet under MS-DOS and Windows to 3 connect to VMS and ULTRIX, and using NFT and stuff.   < To contact me, just answer this mail; I use my real address.  7 If nobody claims it by 24-DEC-2004, I'll dispose of it. 8 I'll probably be posting other miscellaneous DEC-related) free stuff here over the next few months.    -Mike Duffy    ------------------------------    Date: 17 Dec 2004 08:11:16 -0800* From: "FreeIpodInfo" <free2ipod@yahoo.com>$ Subject: Re: How to get a free iPod?C Message-ID: <1103299876.392156.318780@f14g2000cwb.googlegroups.com>    Hey,  D I created a great website for people looking for referrals. Come and0 visit my website at www.freeipodmp3.blogspot.com  F Please click on the first person in line and let me know when you have4 completed an offer. I will list you onto my website.   Good Luck!!!!!!!!    ------------------------------  % Date: Fri, 17 Dec 2004 08:14:19 -0800 # From: "Tom Linden" <tom@kednos.com>  Subject: Re: HP exodus to Intel ( Message-ID: <opsi5t15mvzgicya@hyrrokkin>  0 On Fri, 17 Dec 2004 16:13:21 GMT, Keith Parris  % <keithparris_NOSPAM@yahoo.com> wrote:    > Tom Linden wrote: J >> Introducing incompatible architecture when you have a large installed   >> base J >> is reckless at best, and is a good way to shed customers.  You make theL >> assumption that Alpha based customers will willy-nilly jump to Itanium.   >> IJ >> think that is an unproven assertion and is likely false considering theH >> lack of success (we may have different measures for this quantity) in >> migrating from VAX to Alpha.  > I > The bulk of the VAX base has successfully migrated to Alpha by now. I   I > rarely see a VAX system in serious use at customer sites I visit now.   J > Some VAX systems do remain in the field (mostly in "if it ain't broke,  K > don't fix it" scenarios, where they continue to work just fine), and HP   E > has continued to provide support for their software and for their   J > hardware (as spare levels allow). The fact they remain in use is not a  G > failure on HP's part -- it represents investment protection for the   H > customers, a crucial priciple in the system of values of the OpenVMS   > ecosystem.  J Actually we recently got an order for PL/I for a new large VAX for a gov'tI agency.  The other issue you raise, begs the question as to the direction J those ain't broke customers will move in the future, and I think it likely you will lose some > J > A major attraction of Itanium to current OpenVMS users is they benefit  L > from the economies of scale of a box which also runs Windows, Linux, and  J > HP-UX, making Itanium system prices very attractive compared to Alpha,  H > at equivalent performance levels. This is a benefit we all had hoped  L > Alpha would provide, but with the loss of Windows support, it didn't pan   > out. > , >> The IBM model for how this is done is theK >> only sound way to execute, z-series can execute code compiled 40 years    >> ago!  > H > Ever heard of VEST? It allows VAX code to execute on Alpha, unchanged.K > We also have Charon-VAX, which runs entire OpenVMS VAX operating system   6 > environments on OpenVMS Alpha (or Wintel) platforms.   VEST is not the same thing.    > I > AEST similarly allows Alpha code to execute on Itanium (even VAX code    > previously VESTed to Alpha). > - > So tell me again how IBM does a better job?        --  C Using Opera's revolutionary e-mail client: http://www.opera.com/m2/    ------------------------------  # Date: Fri, 17 Dec 2004 16:13:21 GMT 1 From: Keith Parris <keithparris_NOSPAM@yahoo.com>  Subject: Re: HP exodus to Intel 2 Message-ID: <BADwd.4718$Q85.2007@news.cpqcorp.net>   Tom Linden wrote: L > Introducing incompatible architecture when you have a large installed baseI > is reckless at best, and is a good way to shed customers.  You make the K > assumption that Alpha based customers will willy-nilly jump to Itanium. I I > think that is an unproven assertion and is likely false considering the G > lack of success (we may have different measures for this quantity) in  > migrating from VAX to Alpha.    F The bulk of the VAX base has successfully migrated to Alpha by now. I F rarely see a VAX system in serious use at customer sites I visit now. G Some VAX systems do remain in the field (mostly in "if it ain't broke,  H don't fix it" scenarios, where they continue to work just fine), and HP B has continued to provide support for their software and for their G hardware (as spare levels allow). The fact they remain in use is not a  D failure on HP's part -- it represents investment protection for the E customers, a crucial priciple in the system of values of the OpenVMS  
 ecosystem.  G A major attraction of Itanium to current OpenVMS users is they benefit  I from the economies of scale of a box which also runs Windows, Linux, and  G HP-UX, making Itanium system prices very attractive compared to Alpha,  E at equivalent performance levels. This is a benefit we all had hoped  I Alpha would provide, but with the loss of Windows support, it didn't pan   out.  + > The IBM model for how this is done is the M > only sound way to execute, z-series can execute code compiled 40 years ago!   F Ever heard of VEST? It allows VAX code to execute on Alpha, unchanged.H We also have Charon-VAX, which runs entire OpenVMS VAX operating system 4 environments on OpenVMS Alpha (or Wintel) platforms.  F AEST similarly allows Alpha code to execute on Itanium (even VAX code  previously VESTed to Alpha).  + So tell me again how IBM does a better job?    ------------------------------  # Date: Fri, 17 Dec 2004 16:26:03 GMT 1 From: Keith Parris <keithparris_NOSPAM@yahoo.com>  Subject: Re: HP exodus to Intel 1 Message-ID: <vMDwd.4719$o45.264@news.cpqcorp.net>    Neil Rieck wrote: I > It's deja-vu all over again. HP sends it's Itanium developers to Intel.   F I think this is a sign that Itanium has attained a level of maturity. A When the project started, Intel didn't know beans about high-end  D processors, so HP had to help. Now Intel is ready to take the reins.  H It also helps make competitors like IBM and Dell more comfortable using E Itanium. Remember when AT&T, owner of UNIX, took a 15% stake in Sun?  D Other UNIX vendors were very worried that AT&T would favor Sun. You G can't blame them. This move fixes the similar problem for Itanium, and  - is aimed at making its widespread use easier.   E Note that HP retained its own chipsets for use with Itanium (and the  G associated chip design engineers). HP's chipsets perform very well and  B HP sees this as a competitive advantage to help differentiate its @ products from other Itanium system vendors using the same Intel  microprocessor chips.    ------------------------------  % Date: Fri, 17 Dec 2004 08:48:42 -0800 * From: "Jack Peacock" <peacock@simconv.com> Subject: Re: HP exodus to Intel 2 Message-ID: <LpSdnWE5Zp92kF7cRVn-rA@mpowercom.net>  9 "Rob Young" <young_r@encompasserve.org> wrote in message  - news:cJ3TlpJupT04@eisner.encompasserve.org... G > Please spare us - Jack.  You've been trying to bury VMS for years and D > you make it sound as if "recent events" made you decide something. > , > Sorry Jack, but Google is not your friend! > L Like any psychic^W consultant I just make the same prediction over and over E until it finally comes true.  And I'm a lot cheaper than Gartner.  :)   G I've been using VMS since the early days of V3 on 11/750s, and TOPS-20  K before that.  Were there still a way I'd glady spec VMS on servers, but  I  F have parameters that say the design has to work (as in maintained and M extended, with readily available skills pool) for ten years or more.  I have  G no great desire to switch to Windows, Solaris or Linux, but poor track  K record in predictions aside, no one can deny the trend for VMS is not to a  K happy future filled with Itaniums.  HP has made a poor choice going to IPF  K but spent too much money to change now.  I do present VMS as an option for  D clients, but I tell them why I am reluctant to recommend it as well.  D The subject of buying an Itanium VMS system came up for next year's I planning.  Will VMS still be around at the end of 2005, 2006?  Sure, but  G will it be commercially viable for new installations?  Reluctantly our  M answer, for our customers, was no.  Instead we're recommending that existing  K Alpha users buy a spare machine as a hedge against cutbacks in HP service.  M Meanwhile the software they use is being migrated to Windows, albeit slowly,  L and what has been moved so far is working even though it takes more support H time to keep it running.  Not more expensive though, personnel costs on  Windows are cheaper than VMS.   K What is burying VMS is the lack of new installs.  HP isn't advertising any  M statistics, telling in itself.  The customer dollar amount I steer away from  M HP is not significant in itself, but I doubt I'm the only one doing it.  Can  E anyone seriously recommend a client to invest several million in new  M development on a mission critical system, starting from scratch, with VMS as  A the centerpiece?  A legacy shop maybe, but not if there's no VMS  J infrastructure already in place.  No argument VMS has better reliability, L but that's not the only issue.  There has to be a perception that VMS has a K future, and that's nowhere in evidence, no matter how much we'd like it to  H be different (and yes, I'm one who would like to see VMS return to it's  glory days).  I Old TOPS veterans know this is deja vu all over again (tip of the hat to  K Yogi Berra).  The same economics are at work now.  Nothing saved TOPS, and  / there's no white knight on the horizon for VMS.    Jack Peacock     ------------------------------  # Date: Fri, 17 Dec 2004 17:08:57 GMT 1 From: Keith Parris <keithparris_NOSPAM@yahoo.com>  Subject: Re: HP exodus to Intel 2 Message-ID: <JoEwd.4723$Bb5.4010@news.cpqcorp.net>   JF mezei wrote: M > Well, the number is a spin to help control the speed of the downward spiral  > that IA64 was put in.   F IA64 isn't in a "downward spiral". It's just beginning to really take J off. Revenue growth was 60% quarter-over-quarter, and 225% year-over-year.  H IA64 is doing very well on benchmarks. In the latest TOP500 list, there F are 84 Itanium2 entries compared with 54 for POWER and 30 for Opteron.  D HP saw more than 180 SAP customers move to Itanium in 180 days (see ; http://www.hp.com/hpinfo/newsroom/press/2004/041118a.html).   E I visited some VMS customers in NYC a couple of months ago, and they  I were eagerly starting to get VMS running on rx2600 and rx4640 systems to  I start their porting efforts. There's a lot of excitement in the VMS base   right now about VMS on Itanium.   H While a lot of low-end systems are selling for porting purposes, that's @ not all that's selling: HW split by revenue is 45% low-end; 29% L mid-range; 20% high-end; 6% other (not sure what "other" is: maybe Blades?).  D There are 2,880 applications available on Itanium now, up from just E 1,000 only one year ago. (For VMS, the count is now 250 applications  A ready for 8.2, with over 780 applications from over 360 partners  G committed.) So the momentum is really building. It's not surprising to  G see the FUD building as well. But, for example, even IBM has shipped a  H lot more Linux systems running Itanium than Linux systems running POWER.   ------------------------------  % Date: Fri, 17 Dec 2004 10:22:04 -0800 * From: "Jack Peacock" <peacock@simconv.com> Subject: Re: HP exodus to Intel 2 Message-ID: <IamdnVqQ2ZJRvl7cRVn-iQ@mpowercom.net>  ? "Keith Parris" <keithparris_NOSPAM@yahoo.com> wrote in message  , news:JoEwd.4723$Bb5.4010@news.cpqcorp.net...F > HP saw more than 180 SAP customers move to Itanium in 180 days (see = > http://www.hp.com/hpinfo/newsroom/press/2004/041118a.html).  > + The article is about SAP on HP-UX, not VMS.  > L > I visited some VMS customers in NYC a couple of months ago, and they were L > eagerly starting to get VMS running on rx2600 and rx4640 systems to start  > their porting efforts.K And therein lies the problem.  Everything you quote is existing customers,  M not new ones.  Where are the articles of users converting a large Sun or IBM   site to Itanium?  K Were I working in a large VMS shop I'd be eager to convert to Itanium too.  J Like most of the people in this forum I have a lot invested in VMS skills K and am not looking forward to writing off those years.  Are numbers of new  G VMS licenses on the increase?  I don't know, and HP doesn't seem to be  L telling.  Quotes of total licenses are misleading; they can include 15 year G old VAXes sitting in someone's closet (I have some of those).  Are the  I numbers going off support greater than new sign ups?  If so I'd say that  5 pretty well defines a spiral, in the wrong direction.    Jack Peacock     ------------------------------    Date: 17 Dec 2004 12:24:00 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen)  Subject: Re: HP exodus to Intel 3 Message-ID: <NB70jXD3DaJD@eisner.encompasserve.org>   f In article <BADwd.4718$Q85.2007@news.cpqcorp.net>, Keith Parris <keithparris_NOSPAM@yahoo.com> writes: > Tom Linden wrote:   , >> The IBM model for how this is done is theN >> only sound way to execute, z-series can execute code compiled 40 years ago! > H > Ever heard of VEST? It allows VAX code to execute on Alpha, unchanged.J > We also have Charon-VAX, which runs entire OpenVMS VAX operating system 6 > environments on OpenVMS Alpha (or Wintel) platforms. > H > AEST similarly allows Alpha code to execute on Itanium (even VAX code  > previously VESTed to Alpha). > - > So tell me again how IBM does a better job?   > I don't know about IBM, but Apple certainly does a better job.> PowerPC Macintoshes just _run_ 680x0 code from former versions	 of MacOS.    ------------------------------    Date: 17 Dec 2004 04:05:37 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen) 2 Subject: Re: HP pulls out of IA64 chip development3 Message-ID: <H+pMDXm5PB3z@eisner.encompasserve.org>   V In article <41C23F7B.2060108@tsoft-inc.com>, Dave Froble <davef@tsoft-inc.com> writes:  H > Wonder how easily they could build NVAX chips?  Cheaper than Pentiums?  A The noteworthy patent on the VAX architecture has expired by now.    ------------------------------    Date: 17 Dec 2004 09:13:02 -0800 From: icerq4a@spray.se2 Subject: Re: HP pulls out of IA64 chip developmentC Message-ID: <1103303582.290982.142220@z14g2000cwz.googlegroups.com>    JF Mezei wrote:  > bob@instantwhip.com wrote: > > > > > I think you are dismissing the alpha team way to early .../ > > I predict they will make itanium viable ...  > G > Unless they can produce a 10ghz chip (or equivalent), there is little  the IA64D > team can do from an enegineering point of view to make that chip a market success.   D The things that the Alpha team really can contribute with is the newE system architecture. The current Itanium cores are doing just fine in F performance, and Montecito will have the best power saving features inF the industry next year. The problem current IA64 has in competing with> say POWER5 is the system architecture and that is what the EV8 designers are doing (CSI).   ------------------------------  % Date: Sat, 18 Dec 2004 01:22:56 +0800  From: prep@prep.synonet.com 2 Subject: Re: HP pulls out of IA64 chip development- Message-ID: <87r7lo7sb3.fsf@prep.synonet.com>   / Kilgallen@SpamCop.net (Larry Kilgallen) writes:   X > In article <41C23F7B.2060108@tsoft-inc.com>, Dave Froble <davef@tsoft-inc.com> writes: > I >> Wonder how easily they could build NVAX chips?  Cheaper than Pentiums?  > C > The noteworthy patent on the VAX architecture has expired by now.    The AST Level Register?    --  < Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda. @                                              West Australia 6076* comp.os.vms,- The Older, Grumpier Slashdot. Raw, Cooked or Well-done, it's all half baked.F EPIC, The Architecture of the future, always has been, always will be.   ------------------------------  % Date: Fri, 17 Dec 2004 08:57:40 +0000 0 From: Chris Sharman <chris.sharman@sorry.nospam>& Subject: Re: Interesting coding tidbit3 Message-ID: <cpu724$7r$1$8300dec7@news.demon.co.uk>    Keith Cayemberg wrote:   > John Smith wrote: 9 >> http://www.research.ibm.com/trl/projects/security/ssp/  > E > Of course this does nothing for you if the Hacker/Cracker used GCC  I > without this extension, another language's compiler, assembler or even     Am I missing something ?F I thought this was a feature to protect your own trusted code against E buffer overrun attacks, rather than to stop hackers compiling virii ? F Although I agree there's no substitute for correct code, if it offers @ buffer protection it probably makes writing correct code easier.   Chris    ------------------------------    Date: 17 Dec 2004 04:12:39 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen) & Subject: Re: Interesting coding tidbit3 Message-ID: <qip6m7z9sWXD@eisner.encompasserve.org>   f In article <cpu724$7r$1$8300dec7@news.demon.co.uk>, Chris Sharman <chris.sharman@sorry.nospam> writes: > Keith Cayemberg wrote: >  >> John Smith wrote:: >>> http://www.research.ibm.com/trl/projects/security/ssp/ >>  F >> Of course this does nothing for you if the Hacker/Cracker used GCC J >> without this extension, another language's compiler, assembler or even  >  > Am I missing something ?H > I thought this was a feature to protect your own trusted code against G > buffer overrun attacks, rather than to stop hackers compiling virii ?   A Certainly you are correct.  There is no protection if you give an > attacker permission to execute their own code on your machine.  H > Although I agree there's no substitute for correct code, if it offers B > buffer protection it probably makes writing correct code easier.  A It is important to note that this is _not_ a general GCC feature. @ The cited page notes that it is _specifically_ for programs that are written in C.   A For general programming purposes, buffer overflows were conquered B years ago -- only lower level languages like C* have this problem.   ------------------------------  % Date: Fri, 17 Dec 2004 15:27:20 +0100 0 From: Keith Cayemberg <keith.cayemberg@arcor.de>& Subject: Re: Interesting coding tidbitB Message-ID: <41c2ecc9$0$29836$9b4e6d93@newsread2.arcor-online.net>   Chris Sharman wrote: > Keith Cayemberg wrote: >  >> John Smith wrote: >>: >>> http://www.research.ibm.com/trl/projects/security/ssp/ >> >>F >> Of course this does nothing for you if the Hacker/Cracker used GCC J >> without this extension, another language's compiler, assembler or even  >  >  > Am I missing something ?H > I thought this was a feature to protect your own trusted code against G > buffer overrun attacks, rather than to stop hackers compiling virii ? H > Although I agree there's no substitute for correct code, if it offers B > buffer protection it probably makes writing correct code easier. >  > Chris   I No, I don't think you're missing anything. You are quite right that such  H a tool would increase the security and correctness of homegrown code. I I wanted only to make an 'additional' point that the usefulness of this is  I limited in the larger context of having a secure system. Even if all the  C   operating system code were compiled using this tool it would not  C change the architecture of the Operating System to prevent foreign  H programs compiled with unknown tools and methods from creating security F   holes (including those buffer-overflow errors believed to have been > eliminated by this tool) in your system. The operating system D architecture needs to be defined to prevent buffer-overflows, stack H crashing and other problems by it's design of separate protection modes H for native system code (kernel), third-party code (layered-products) and@ user code and actions. Which is why 3 protection modes (Kernel, D Supervisor, and User) are regarded to be the *minimum* for a secure E operating system (not available in Unix or Windows OS Designs). This  E separation of modes (along with the coupling of important actions to  E required designated privileges and rights) must result in ALL kernel  F code, rights and privileges being only accessible through a carefully H designed, secure Calling Standard. This is what can prevent third-party I products from attaining higher privileges even when you don't intimately  - know who, how or what exactly was programmed.   H It might be possible to realize such a secure design with a microkernel B OS using a minimum of 3 security domains to adequately secure the F various primary services moved out of the kernel, but this forces the I design to be greatly more complex and error prone, and requires multiple  I secure calling standards. To my knowledge no operating system design has  E been correctly designed or implemented in this way yet. However, the  G traditional multi-protection mode ring architecture as used in OpenVMS  9 has been successfully implemented and proved in practice.    Cheers!    Keith Cayemberg    ------------------------------  % Date: Fri, 17 Dec 2004 15:44:51 +0100 0 From: Keith Cayemberg <keith.cayemberg@arcor.de>& Subject: Re: Interesting coding tidbitB Message-ID: <41c2f0e4$0$29845$9b4e6d93@newsread2.arcor-online.net>   Larry Kilgallen wrote:  h > In article <cpu724$7r$1$8300dec7@news.demon.co.uk>, Chris Sharman <chris.sharman@sorry.nospam> writes: >  >>Keith Cayemberg wrote: >> >> >>>John Smith wrote: >>> : >>>>http://www.research.ibm.com/trl/projects/security/ssp/ >>> F >>>Of course this does nothing for you if the Hacker/Cracker used GCC J >>>without this extension, another language's compiler, assembler or even  >> >>Am I missing something ?H >>I thought this was a feature to protect your own trusted code against G >>buffer overrun attacks, rather than to stop hackers compiling virii ?  >  > C > Certainly you are correct.  There is no protection if you give an @ > attacker permission to execute their own code on your machine. > I I'm also referring to the larger case that one normally doesn't know the  G language methods or intent of the coders of any software product which  H has not been designed and built in-house. Open Source Software improves D the possibility of controlling this, but the reality is that a real C understanding and control of all external code is not practical or  G affordable for most concerns (if you have ever had to maintain someone  I else's code in a complex package you know what I mean, even if it's well  F documented, you may need weeks to read the documentation), especially B for those organizations requiring the highest levels of security. @ Automatic methods integrated in the operating system design are H necessary. This concern was behind the design of Multics already in the H 60's. The Unix and Windows designers didn't learn from history, and are  now paying the price.    > H >>Although I agree there's no substitute for correct code, if it offers B >>buffer protection it probably makes writing correct code easier. >  > C > It is important to note that this is _not_ a general GCC feature. B > The cited page notes that it is _specifically_ for programs that > are written in C.  > C > For general programming purposes, buffer overflows were conquered D > years ago -- only lower level languages like C* have this problem.   ------------------------------  # Date: Fri, 17 Dec 2004 16:12:26 GMT " From:   VAXman-  @SendSpamHere.ORG* Subject: more LPD problems with TCPIP V5.40 Message-ID: <00A3C7B1.C0FF2787@SendSpamHere.ORG>  ' Proxy or no proxy, LPD under TCPIP V5.4 ' (with DEC-AXPVMS-TCPIP_ECO-V0504-154-4)  does not work.  B The remote host is always listed with a RNF error in the log file.   I wish WIS still functioned. :(    --  < http://www.ProvN.com  for the *best* OpenVMS system security=                       solutions that others only claim to be.  --  , Cyber-Terrorism (si'-ber tayr'-or-iz-em) n.:M   The release of, the sale of, or the use of any Micro$oft software product!   --  K VAXman- A Bored Certified VMS Kernel Mode Hacker   VAXman(at)TMESIS(dot)COM    ------------------------------  % Date: Fri, 17 Dec 2004 10:28:12 -0500 # From: "John Smith" <a@nonymous.com>  Subject: Re: More on Tru64, Message-ID: <I8adnZh54fWRZl_cRVn-2A@igs.net>   Robert Deininger wrote: C > In article <ifjwd.24219$%p1.1513797@news20.bellglobal.com>, "Neil & > Rieck" <n.rieck@sympatico.ca> wrote: > F >> HP said existing Tru64 customers should move over to HP-UX and just? >> licence third party software from Veritas to make up for the  >> differences.  >>D >> Well, it looks like Symatec just bought Veritas and you know whatE >> usually happens during mergers. (hint: stuff that's not a real big % >> money maker usually gets the chop)  > G > HP-UX has shipped with the Veritas file system for a number of years. F > As I understand it, the file system is well integrated with the rest > of the OS. > ( > So I guess HP-UX is doomed too, right?   Nah..   L What's really amazing though is the sh*t will sell when it has advertising &G marketing behind it. Too bad Tru64 and VMS never had the marketing push . behind them to the same extent that PH-UX had.  H So what's the number of installed OpenVMS systems today...still 411,000?   ------------------------------    Date: 17 Dec 2004 09:47:07 -06004 From: kaplow_r@encompasserve.org.TRABoD (Bob Kaplow) Subject: Re: More on Tru643 Message-ID: <3wilxLcV5Jtr@eisner.encompasserve.org>   R In article <I8adnZh54fWRZl_cRVn-2A@igs.net>, "John Smith" <a@nonymous.com> writes:N > What's really amazing though is the sh*t will sell when it has advertising &I > marketing behind it. Too bad Tru64 and VMS never had the marketing push 0 > behind them to the same extent that PH-UX had.  I I don't know if that's a typo or intentional, but it's the funniest thing  I've seen all week!   1 	Bob Kaplow	NAR # 18L	TRA # "Impeach the TRA BoD" & 		>>> To reply, remove the TRABoD! <<<K Kaplow Klips & Baffle:	http://nira-rocketry.org/LeadingEdge/Phantom4000.pdf L     www.encompasserve.org/~kaplow_r/    www.nira-rocketry.org    www.nar.org  N ... One nation under survielence, divisive, with liberty and justice for none.   ------------------------------    Date: 17 Dec 2004 10:09:15 -0800 From: jordan@ccs4vms.com< Subject: More PHP vulnerabilities; is the VMS port affected?C Message-ID: <1103306955.111557.252380@f14g2000cwb.googlegroups.com>   1 http://www.hardened-php.net/advisories/012004.txt   G As usual I'm buried in other stuff and don't have time to experiment to D verify if the VMS port of PHP is impacted, but I don't think PHP forG VMS has been updated since before the last round of PHP vulnerabilities G was disclosed earlier in the year.  Any word from the maintainers would  be appreciated.    ------------------------------  % Date: Fri, 17 Dec 2004 11:27:48 -0500  From: "Ray" <no@spam.me>  Subject: Re: NYSE and HP servers, Message-ID: <xVDwd.14041$wR6.12145@fe06.lga>  H Here's another article about this, this one a press release on IBM's web site:    (Mind the wrapping) r http://www-1.ibm.com/press/PressServletForm.wss?TemplateName=ShowPressReleaseTemplate&SelectString=t1.docunid=7459  J Another traditional DEC/Tandem  market showing early signs of defecting to IBM.   ------------------------------  % Date: Fri, 17 Dec 2004 09:21:09 +0100  From: Dirk Munk <munk@home.nl>4 Subject: Re: OT: Display technology at euro stadiums2 Message-ID: <cpu4tq$d12$1@news5.zwoll1.ov.home.nl>   JF Mezei wrote: P > Does anyone know what sort of technology is used for the advertising displays,M > such as the one used at Madrid'd football statium which cover almost all of  > the periphery of the field ? > M > How do they prevent it from breaking when somone kicks a ball into it, or a ( > bunch of players run/collide into it ? > O > I find it interesting that they can scale the displays to such an extent that O > they can horizontally scroll contents across the whole length of the display.   Q I haven't seen these actual pictures, but I do know that these displays may only  L be television tricks. I'm sure you know the 'blue wall' they use with TV to Q trick scenes. The same principle is applied with these displays for games on TV.  ' In the stadium itself you can's see it.    ------------------------------  % Date: Fri, 17 Dec 2004 10:21:06 -0500 # From: "John Smith" <a@nonymous.com>  Subject: Robison dumps HP stock , Message-ID: <6O-dncOEvdD_ZF_cRVn-hA@igs.net>  J Interesting that Shane Robison sold nearly 1/2 his holdings of HP stock on	 Dec. 7th.   J carly(tm) sold about 11,000 shares - guess that's for a few new pant suits   ------------------------------    Date: 17 Dec 2004 07:55:24 -0600; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler)  Subject: soon to be gone3 Message-ID: <yMdNQsepc3bp@eisner.encompasserve.org>   ?    Those of you who were at the 1995 Spring DECUS Symposium in  ?    Washington, DC (I think it was still called symposium then), E    might be interested to know that plans are to implode the building &    tomorrow (Dec 18) at 7:30 am local.      You can't go back.    ------------------------------  % Date: Fri, 17 Dec 2004 06:05:14 -0800 # From: "Tom Linden" <tom@kednos.com>  Subject: Re: soon to be gone( Message-ID: <opsi5n20kpzgicya@hyrrokkin>  , On 17 Dec 2004 07:55:24 -0600, Bob Koehler  0 <koehler@eisner.nospam.encompasserve.org> wrote:   > @ >    Those of you who were at the 1995 Spring DECUS Symposium inA >    Washington, DC (I think it was still called symposium then), G >    might be interested to know that plans are to implode the building ( >    tomorrow (Dec 18) at 7:30 am local. >  >    You can't go back.  > J We were demo'ng PL/I on Tru64 and I remember carrying in a CRT, and askedJ one of the many teamsters standing about if I could use his dolly... the   look,  I ended up carrying it.      --  C Using Opera's revolutionary e-mail client: http://www.opera.com/m2/    ------------------------------  % Date: Fri, 17 Dec 2004 10:11:59 -0500 # From: "John Smith" <a@nonymous.com>  Subject: Re: soon to be gone, Message-ID: <evWdnehgPK-ial_cRVn-2w@igs.net>   Bob Koehler wrote:@ >    Those of you who were at the 1995 Spring DECUS Symposium inA >    Washington, DC (I think it was still called symposium then), G >    might be interested to know that plans are to implode the building ( >    tomorrow (Dec 18) at 7:30 am local. >  >    You can't go back.I    , Here's another building they should implode:" 3000 HANOVER STREET, PALO ALTO, CA   ------------------------------    Date: 17 Dec 2004 09:32:40 -0800 From: jordan@ccs4vms.com Subject: Re: soon to be goneB Message-ID: <1103304760.905039.76290@f14g2000cwb.googlegroups.com>  E Could be worse; in chicago (aka the pit) the unionista would probablyeD have called up the thugs and had you 'accidentally' injured, or have6 your display/booth experience unexplained misfortunes.   ------------------------------  + Date: Fri, 17 Dec 2004 10:56:23 +0000 (UTC)r From: david20@alpha2.mdx.ac.uk$ Subject: Re: Time to revive Emerald?) Message-ID: <cpue0n$im2$1@news.mdx.ac.uk>   V In article <41C243F9.9010305@tsoft-inc.com>, Dave Froble <davef@tsoft-inc.com> writes: >David J Dachtera wrote: >i >> DAVID TURNER wrote: >> i >>>Hang on a minute... >>>i >>>www.softresint.comt >>>i- >>>I wonder if they are on any stock exchange ) >>>My bet would be to buy a load of that.e >>>Openvms DOES run on PC'se5 >>>(as long as you give billy your $100.00 as well !)L >>>h >> wK >> ...and therein lies the rub. So long as the x86-based systems need a VAX A >> emulation layer, they will remain limited as VAX replacements.  >eM The current products emulate a VAX processor hence they are VAX replacements.VN Future products running on x86-64 might emulate an Alpha processor and thus be an Alpha replacement.aO The real problem with these emulators though is not the VAX emulation layer but-J the fact that they are running on top of another OS (ie Windows or Linux) B which imposes it's own overheads (and possible security worries ).    
 David Webb Security team leader CCSS Middlesex University       >eP >Why?  What rule makes this so?  What do you care how you get to an environment R >that will run VMS?  For that matter, VMS doesn't run on Alpha, or NVAX.  It runs Q >on the environment made up of those products plus firmware, microcode, PALcode, .J >whatever.  VAX emulation code is just another example of what I've named. >e >> WhenSJ >> OpenVMS-IA32 runs natively on IA32, and OpenVMS-x86/64 runs natively onE >> x86/64, *THEN* we'll see an opportunity for the market to take offb	 >> again.i >y >-P >Well, there is no more IA32 hardware available.  Intel and AMD have gotten the M >speed from hardware that is no longer x86, and provided an x86 environment, -2 >again, using firmware/microcode/PALcode/whatever. >0O >To the people building CPUs today, 'NATIVE' no longer has the same meaning as ?R >when CPUS were a collection of boards, and a MOVL truly was a hardware operation. >a   ------------------------------  % Date: Fri, 17 Dec 2004 08:47:24 -0500b) From: "Neil Rieck" <n.rieck@sympatico.ca>a$ Subject: Re: Time to revive Emerald?; Message-ID: <IrBwd.27361$%p1.1781632@news20.bellglobal.com>   @ "David J Dachtera" <djesys.nospam@comcast.net> wrote in message % news:41C2370A.6FD67628@comcast.net...4 > DAVID TURNER wrote:L [...snip...] >sJ > ...and therein lies the rub. So long as the x86-based systems need a VAXE > emulation layer, they will remain limited as VAX replacements. WhensI > OpenVMS-IA32 runs natively on IA32, and OpenVMS-x86/64 runs natively oniD > x86/64, *THEN* we'll see an opportunity for the market to take off > again. >t
 Well said.  J "OpenVMS-IA32" and "OpenVMS-x86/64" should be the next mantras chanted by M the folks at HP OpenVMS engineering. Five years ago I would have be a year's sF pay that Tru64 would have squeezed out other pay-to-use forms of UNIX M because Tru64 was the best UNIX I'd ever laid my hands on. Now Tru64 is dead  L in the water and its most important features (AfvFs and TruCluster) are not  going to be moved into HP-UX.s  M Let's not let our collective admiration of OpenVMS blind us to the fact that  L the same thing could happen to this OS. (especially since OpenVMS will only 8 be a one-trick-pony after HP stops manufacturing Alpha).  G p.s. Am I foolish to believe that Tru64 might be moved into the public l domain?o  
 Neil Rieck Kitchener/Waterloo/Cambridge,  Ontario, Canada.8 http://www3.sympatico.ca/n.rieck/links/cool_openvms.html   ------------------------------  % Date: Fri, 17 Dec 2004 14:12:36 +0000s- From: Roy Omond <Roy.Omond@BlueBubble.UK.Com> $ Subject: Re: Time to revive Emerald?, Message-ID: <32g7uqF3kkr9sU1@individual.net>   Neil Rieck wrote:e > [...snip...] > O > Let's not let our collective admiration of OpenVMS blind us to the fact that eN > the same thing could happen to this OS. (especially since OpenVMS will only : > be a one-trick-pony after HP stops manufacturing Alpha).   Y'know, all this talk...  @ I'm going out on a limb here, but my bet is that VMS EngineeringA is smart enough to have taken advantage of the whole IA64 portingp2 effort to have done work on "other platforms" too.  7 My guesstimate is to look out in the "near" future for:l   	OPENVMS-AMD64 and	OPENVMS-POWER5  2 (definition of "near" intentionally left blank ;-)   ------------------------------  % Date: Fri, 17 Dec 2004 09:22:26 -0500x# From: "Dan Allen" <dallen@nist.gov> $ Subject: RE: Time to revive Emerald?: Message-ID: <JFEPKAPBPMDFDBOIANGDKEAIFOAA.dallen@nist.gov>   > -----Original Message-----6 > From: Roy Omond [mailto:Roy.Omond@BlueBubble.UK.Com]) > Sent: Friday, December 17, 2004 9:13 AMc > To: Info-VAX@Mvb.Saic.Como& > Subject: Re: Time to revive Emerald? >e >  > Neil Rieck wrote:- > > [...snip...] > >uF > > Let's not let our collective admiration of OpenVMS blind us to the > fact that O > > the same thing could happen to this OS. (especially since OpenVMS will onlyo< > > be a one-trick-pony after HP stops manufacturing Alpha). >$ > Y'know, all this talk... >oB > I'm going out on a limb here, but my bet is that VMS EngineeringC > is smart enough to have taken advantage of the whole IA64 portingt4 > effort to have done work on "other platforms" too.  ) 	Gee, isn't that what Fred said early on?I   >m9 > My guesstimate is to look out in the "near" future for:a >  > 	OPENVMS-AMD64 > and	OPENVMS-POWER5 > 4 > (definition of "near" intentionally left blank ;-)  G 	Gutsy move - hope it's not as wishfull as my picks in the BCS bowls (4r
 "upsets") ;-)y   	Dan >a >y   ------------------------------  % Date: Fri, 17 Dec 2004 06:50:25 -0800s# From: "Tom Linden" <tom@kednos.com> $ Subject: Re: Time to revive Emerald?( Message-ID: <opsi5p6bh3zgicya@hyrrokkin>  / On Fri, 17 Dec 2004 14:12:36 +0000, Roy Omond  t$ <Roy.Omond@BlueBubble.UK.Com> wrote:   >eB > I'm going out on a limb here, but my bet is that VMS EngineeringC > is smart enough to have taken advantage of the whole IA64 portingu4 > effort to have done work on "other platforms" too.: >  My guesstimate is to look out in the "near" future for: >  OPENVMS-AMD64 > andOPENVMS-POWER5t1 >  (definition of "near" intentionally left blank   B It could be argued that not having done it would be a dereliction.   -- vC Using Opera's revolutionary e-mail client: http://www.opera.com/m2/e   ------------------------------  % Date: Fri, 17 Dec 2004 08:10:06 -0800 # From: "Tom Linden" <tom@kednos.com>h$ Subject: Re: Time to revive Emerald?( Message-ID: <opsi5tu4jtzgicya@hyrrokkin>  G On Fri, 17 Dec 2004 10:43:21 -0500, Neil Rieck <n.rieck@sympatico.ca>  A wrote:  H > First off, I don't think the new-HP (still with a Compaq core) cares   > aboutXK > religious discussions involving "which CPU is the best". They only want  E > toG > sell boxes and replace red ink with black. On top of that, if their  y	 > OpenVMSAK > software group adds profits to HP's bottom line, then so much the better.-H > (If their OpenVMS group doesn't pull their weight then that group is   > toast)I > Secondly, the higher-ups at Intel won't care if their business partners1I > design port Itanium software to Pentium or 64-bit Pentium. Intel is a    > chipK > manufacturing company and can only see this effort as an opportunity to  n > sellL > more chips. On top of that, they know that AMD makes up no more than 10%   > ofG > the 32-bit CPU business and probably don't see AMD as a threat. (In   
 > reality,K > they would never want to see AMD go out of business because this would bet1 > the beginning of non-competition woes for them)%  K In news story from datamonitor.com this morning, Jenkins reveals that IntelnK is contractually bound, the writer speculates to 2008.  Thus, it made sensedJ to transfer the  engineers to Intel.  A large portion of $3B appears to be going to chip sets.u  J Of course, to drive the cost of the chips down (which isn't so important   formI Servers, you need volume, and that would only happen if MSFT embraced theiJ product.  They have their own server ambitions, and I don't see why they   wouldo want to help a competitor-   -- -C Using Opera's revolutionary e-mail client: http://www.opera.com/m2/e   ------------------------------  % Date: Fri, 17 Dec 2004 10:43:21 -0500 ) From: "Neil Rieck" <n.rieck@sympatico.ca>R$ Subject: Re: Time to revive Emerald?: Message-ID: <p8Dwd.17934$pb.1210436@news20.bellglobal.com>  5 "Neil Rieck" <n.rieck@sympatico.ca> wrote in message b5 news:IrBwd.27361$%p1.1781632@news20.bellglobal.com...n >v [...snip...] >cL > "OpenVMS-IA32" and "OpenVMS-x86/64" should be the next mantras chanted by H > the folks at HP OpenVMS engineering. Five years ago I would have be a J > year's pay that Tru64 would have squeezed out other pay-to-use forms of L > UNIX because Tru64 was the best UNIX I'd ever laid my hands on. Now Tru64 B > is dead in the water and its most important features (AfvFs and 3 > TruCluster) are not going to be moved into HP-UX.n >iJ > Let's not let our collective admiration of OpenVMS blind us to the fact I > that the same thing could happen to this OS. (especially since OpenVMS uD > will only be a one-trick-pony after HP stops manufacturing Alpha). >r [...snip...] > I This message is a rebuttal to several personal replies I received to the FL above posting. The major theme of those replies was "HP wouldn't allow work K on a non-Itanium version of OpenVMS because it could hurt sales of Itanium h based systems".n  K First off, I don't think the new-HP (still with a Compaq core) cares about aK religious discussions involving "which CPU is the best". They only want to fL sell boxes and replace red ink with black. On top of that, if their OpenVMS J software group adds profits to HP's bottom line, then so much the better. K (If their OpenVMS group doesn't pull their weight then that group is toast)   H Secondly, the higher-ups at Intel won't care if their business partners K design port Itanium software to Pentium or 64-bit Pentium. Intel is a chip oM manufacturing company and can only see this effort as an opportunity to sell  L more chips. On top of that, they know that AMD makes up no more than 10% of M the 32-bit CPU business and probably don't see AMD as a threat. (In reality,  J they would never want to see AMD go out of business because this would be / the beginning of non-competition woes for them)   
 Neil Rieck Kitchener/Waterloo/Cambridge,s Ontario, Canada.8 http://www3.sympatico.ca/n.rieck/links/cool_openvms.html   ------------------------------  % Date: Fri, 17 Dec 2004 17:13:30 +0100i+ From: Karsten Nyblad <nospam@nospam.nospam>i$ Subject: Re: Time to revive Emerald?- Message-ID: <cpv0lb$2r8d$1@news.cybercity.dk>u   Roy Omond wrote: > Neil Rieck wrote:m >  >> [...snip...]i >>F >> Let's not let our collective admiration of OpenVMS blind us to the G >> fact that the same thing could happen to this OS. (especially since  F >> OpenVMS will only be a one-trick-pony after HP stops manufacturing 
 >> Alpha). >  >  > Y'know, all this talk... > B > I'm going out on a limb here, but my bet is that VMS EngineeringC > is smart enough to have taken advantage of the whole IA64 portinga4 > effort to have done work on "other platforms" too. > 9 > My guesstimate is to look out in the "near" future for:. >  >     OPENVMS-AMD64  > and    OPENVMS-POWER5p > 4 > (definition of "near" intentionally left blank ;-)  I They would still need to create new compilers for Macro32 and Bliss.  In gF the latter case they will need to do that even if they already have a H compiler for Bliss from the Emerald project, because they need a 64-bit F Bliss compiler.  Further, they will have to somehow get compilers for F all the other languages supported on Alpha VMS.  (Perhaps they can do . with those promissed to be supported on IA64.)  G I would only port VMS to AMD64 if I was to decide.  Power 5 is a great  I chip, but I think people will prefer to buy it as part of AIX boxes from gH IBM.  It should be possible to get reliable AMD64 boxes if HP choses to # build them from high quality parts.    ------------------------------  % Date: Fri, 17 Dec 2004 12:19:15 -0500i) From: "Neil Rieck" <n.rieck@sympatico.ca>h$ Subject: Re: Time to revive Emerald?; Message-ID: <kyEwd.28334$%p1.1847029@news20.bellglobal.com>   9 "Karsten Nyblad" <nospam@nospam.nospam> wrote in message o' news:cpv0lb$2r8d$1@news.cybercity.dk...  > Roy Omond wrote: >gK > They would still need to create new compilers for Macro32 and Bliss.  In 0H > the latter case they will need to do that even if they already have a J > compiler for Bliss from the Emerald project, because they need a 64-bit L > Bliss compiler.  Further, they will have to somehow get compilers for all I > the other languages supported on Alpha VMS.  (Perhaps they can do with  + > those promissed to be supported on IA64.)  >cI > I would only port VMS to AMD64 if I was to decide.  Power 5 is a great IK > chip, but I think people will prefer to buy it as part of AIX boxes from hJ > IBM.  It should be possible to get reliable AMD64 boxes if HP choses to % > build them from high quality parts.   J We've seen this group perform miracles before. The peanut gallery said it K would be impossible to move the OS from VAX to Alpha and they did that. At iM an "OpenVMS Technical Update" in 2003 the audience was told that moving from  I Alpha to Itanium was even easier. Maybe now is the time to replace BLISS  	 with "C".o  J As for languages, I was under the impression that all GEM-based languages > were easy to port (however, I stand corrected if they are not)  
 Neil Rieck Kitchener/Waterloo/Cambridge,e Ontario, Canada.9 http://www3.sympatico.ca/n.rieck/links/cool_openvms.html e   ------------------------------    Date: 17 Dec 2004 12:31:34 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen)s$ Subject: Re: Time to revive Emerald?3 Message-ID: <q3QD+5m3p0vg@eisner.encompasserve.org>   g In article <kyEwd.28334$%p1.1847029@news20.bellglobal.com>, "Neil Rieck" <n.rieck@sympatico.ca> writes:n  L > We've seen this group perform miracles before. The peanut gallery said it M > would be impossible to move the OS from VAX to Alpha and they did that. At rO > an "OpenVMS Technical Update" in 2003 the audience was told that moving from  K > Alpha to Itanium was even easier. Maybe now is the time to replace BLISS l > with "C".:  @ One of the worst things you can do to software reliability is to> gratuitously port to a different language.  That would even be= true if C were better than Bliss.  I have ported Bliss to Adad@ and engaged in Formal Inspection to make sure the result was ok.A The client is still finding bugs 4 years later.  But in that case @ a rewrite was required since the Bliss had assumptions about the4 underlying software architecture that had to change.  L > As for languages, I was under the impression that all GEM-based languages @ > were easy to port (however, I stand corrected if they are not)  ? Keeping the interface to the back end the same and changing theoA back end is an easier way to port a compiler, but it is not free.M? You also have to change the back ends, and HP has turned over at lot of the GEM people to Intel.s   ------------------------------    Date: 17 Dec 2004 07:50:39 -0600; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler)nI Subject: Re: [Nomex on]: Security research suggests Linux has fewer flawsm3 Message-ID: <S5f9gH4x+lZB@eisner.encompasserve.org>F  b In article <gvjwd.900$1o1.366@newssvr19.news.prodigy.com>, "John Vottero" <John@mvpsi.com> writes: >> > N > Yeah, the tools can be useful but, it makes no sense to compare the results L > from the Linux kernel to the results from "commercial" software.  Compare 2 > Linux kernel to HP-UX kernel or Windows kernel.   H    The last time I looked, HP-UX and Windows were "commercial software".H    I'm willing to go along with the notion that they weren't able to getC    the Windows source code to scan, but what evidence is there thatoH    OS kernels have different error rates than other commercial software?   ------------------------------  + Date: Fri, 17 Dec 2004 15:25:08 +0000 (UTC)m6 From: peter@langstoeger.at (Peter 'EPLAN' LANGSTOEGER)G Subject: [OpenVMS Alpha V7.3-2] GETDVI Item for Volume Size and Limit ?t1 Message-ID: <newscache$rrgv8i$6641$1@news.sil.at>r  I Now that Dynamic Volume Expansion (DVE) is part of VMS, I was looking fora, GETDVI items to get these numbers of my disk   $ SHOW DEVICE DSA1/FULL  ....O     Logical Volume Size     71132960    Expansion Size Limit         1073725440h ....  E but I was so far unsuccessful. Am I blind or aren't there any (yet) ?e   TIA1   -- 0 Peter "EPLAN" LANGSTOEGERr% Network and OpenVMS system specialistu E-mail  peter@langstoeger.atF A-1030 VIENNA  AUSTRIA              I'm not a pessimist, I'm a realist   ------------------------------    Date: 17 Dec 2004 11:09:19 -0500/ From: brooks@cuebid.zko.dec.nospam (Rob Brooks)eK Subject: Re: [OpenVMS Alpha V7.3-2] GETDVI Item for Volume Size and Limit ?u- Message-ID: <N3GQDe0Pof3V@cuebid.zko.dec.com>c  8 peter@langstoeger.at (Peter 'EPLAN' LANGSTOEGER) writes:K > Now that Dynamic Volume Expansion (DVE) is part of VMS, I was looking for). > GETDVI items to get these numbers of my disk >  > $ SHOW DEVICE DSA1/FULL  > ....Q >     Logical Volume Size     71132960    Expansion Size Limit         1073725440  > .... > G > but I was so far unsuccessful. Am I blind or aren't there any (yet) ?b   $ sho sys/noprocK OpenVMS V7.3-2  on node CUEBID  17-DEC-2004 11:07:51.08  Uptime  8 18:30:21 : $ write sys$output f$getdvi( "sys$sysdevice:", "expsize" ) 2080768s: $ write sys$output f$getdvi( "sys$sysdevice:", "volsize" ) 2050860k     -- t  M Rob Brooks    VMS Engineering -- I/O Exec Group     brooks!cuebid.zko.dec.como   ------------------------------  % Date: Fri, 17 Dec 2004 16:16:01 -0000e& From: "Craig Cooke" <cs@beta.dabs.com>K Subject: Re: [OpenVMS Alpha V7.3-2] GETDVI Item for Volume Size and Limit ?t5 Message-ID: <FBSO0OF5EHA.4264@juno.intranet.dabs.com>n  C "Peter 'EPLAN' LANGSTOEGER" <peter@langstoeger.at> wrote in messagek+ news:newscache$rrgv8i$6641$1@news.sil.at...eK > Now that Dynamic Volume Expansion (DVE) is part of VMS, I was looking forl. > GETDVI items to get these numbers of my disk >- > $ SHOW DEVICE DSA1/FULL- > ....> >     Logical Volume Size     71132960    Expansion Size Limit
 1073725440 > .... >RG > but I was so far unsuccessful. Am I blind or aren't there any (yet) ?r >o > TIA  >a > -- < > Peter "EPLAN" LANGSTOEGERo' > Network and OpenVMS system specialistr > E-mail  peter@langstoeger.atH > A-1030 VIENNA  AUSTRIA              I'm not a pessimist, I'm a realist   Is its  >       EXPSIZE  Integer  Current expansion limit on the volume.     Regardsk   Craig Cooke>   ------------------------------  + Date: Fri, 17 Dec 2004 16:51:27 +0000 (UTC)m6 From: peter@langstoeger.at (Peter 'EPLAN' LANGSTOEGER)K Subject: Re: [OpenVMS Alpha V7.3-2] GETDVI Item for Volume Size and Limit ?a1 Message-ID: <newscache$lrkv8i$4p61$1@news.sil.at>o  j In article <newscache$rrgv8i$6641$1@news.sil.at>, peter@langstoeger.at (Peter 'EPLAN' LANGSTOEGER) writes:J >Now that Dynamic Volume Expansion (DVE) is part of VMS, I was looking for- >GETDVI items to get these numbers of my disk  >t >$ SHOW DEVICE DSA1/FULL >.....P >    Logical Volume Size     71132960    Expansion Size Limit         1073725440 >..... > F >but I was so far unsuccessful. Am I blind or aren't there any (yet) ?  C Gotcha. I found them besides some other un- or bad documented ones.o7 And it also seems I have to regenerate my FORSYSDEF ;-)-  ' It is VOLSIZE and EXPSIZE respectively.    -Peter  N PS: I also found the following items missing in HELP. Could someone check 8.2?
 CLIENT_DEVICEb	 DAPDEVNAM-
 DEVDEPEND3
 DEVDEPEND4 DISPLAY_DEVNAM DRIVER_IMAGE_NAME  SHDW_FAILED_MEMBER
 TT_ANSI_COLORe
 TT_ASIAN_MODE 
 TT_DECCRT5 TT_MULTISESSION>
 TT_PASSALL	 TT_SCRIPTb -- / Peter "EPLAN" LANGSTOEGER % Network and OpenVMS system specialistf E-mail  peter@langstoeger.atF A-1030 VIENNA  AUSTRIA              I'm not a pessimist, I'm a realist   ------------------------------    Date: 17 Dec 2004 12:22:09 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen)iK Subject: Re: [OpenVMS Alpha V7.3-2] GETDVI Item for Volume Size and Limit ? 3 Message-ID: <h55tvmPDpwsp@eisner.encompasserve.org>t  j In article <newscache$lrkv8i$4p61$1@news.sil.at>, peter@langstoeger.at (Peter 'EPLAN' LANGSTOEGER) writes:  P > PS: I also found the following items missing in HELP. Could someone check 8.2?  ( What do you mean you "found" the items ?  A If you found them in the documentation, then the HELP text shouldu be updated.t  A If you merely found them in STARLET.REQ, then the items very welleB may not work, produce the wrong answers, or (worst of all) produce( the wrong answers just some of the time.  E Remember that bits and data structures often get designed well beforeo the code to use them.o  D But perhaps some of those you listed will now be documented with theG vast expansion of DVI$_ codes mentioned by someone from VMS DevelopmentiD here.  As I recall, that is due to arrive in Alpha VMS V8.2 (and was _not_ in the Field Test).h   ------------------------------   End of INFO-VAX 2004.699 ************************