1 INFO-VAX	Sun, 26 Aug 2001	Volume 2001 : Issue 473       Contents: Re: Alpha - Complete for USD599 7 Are consultants "poor" consultants (was: DCL challenge) F Cheaper systems with IA64 (was: Conference: CETS-2001 Detailed Update)) Re: Conference: CETS-2001 Detailed Update ) Re: Conference: CETS-2001 Detailed Update ) Re: Conference: CETS-2001 Detailed Update ) Re: Conference: CETS-2001 Detailed Update ) Re: Conference: CETS-2001 Detailed Update ) Re: Conference: CETS-2001 Detailed Update ) Re: Conference: CETS-2001 Detailed Update ) Re: Conference: CETS-2001 Detailed Update ) Re: Conference: CETS-2001 Detailed Update ) Re: Conference: CETS-2001 Detailed Update ) Re: Conference: CETS-2001 Detailed Update ) Re: Conference: CETS-2001 Detailed Update ) Re: Conference: CETS-2001 Detailed Update ) Re: Conference: CETS-2001 Detailed Update ) Re: Conference: CETS-2001 Detailed Update ) Re: Conference: CETS-2001 Detailed Update ) Re: Conference: CETS-2001 Detailed Update ) Re: Conference: CETS-2001 Detailed Update ) Re: Conference: CETS-2001 Detailed Update   Re: Feeling Better about Itanium  Re: Feeling Better about Itanium  Re: Feeling Better about Itanium  Re: Feeling Better about Itanium  Re: Feeling Better about Itanium GNU screen for AXP/VMSA Re: Incautious Privileged Users (was: Re: Queue/Entry management) A Re: Incautious Privileged Users (was: Re: Queue/Entry management)  Re: Intersystems and Alpha+ Re: Is there a why to set verify in sysgen? + Re: Is there a why to set verify in sysgen? + Re: Is there a why to set verify in sysgen? 7 Looking for Digital Serial Number Identication Resource ; Re: Looking for Digital Serial Number Identication Resource ; Re: Looking for Digital Serial Number Identication Resource - Re: Modifying User Accounts - newbie question - Re: Modifying User Accounts - newbie question " Re: ODS-5 and parse_style question Re: Queue/Entry management Re: Queue/Entry management Re: Queue/Entry management	 Re: RWMBX 	 Re: RWMBX 7 Re: RWMBX - What to do, What to do! Help me if you can. 7 Re: RWMBX - What to do, What to do! Help me if you can. L Re: SHOCK HORROR! $persona_reserverve requires Detach/Impersonate privilege!G System Managers (was: Wailing at Eunuchs (was: Wailing and Moaning...))  Re: V5.5-2 Password Recovery Re: V5.5-2 Password Recovery Re: V5.5-2 Password Recovery Re: V5.5-2 Password Recovery Re: V5.5-2 Password Recovery Re: V5.5-2 Password Recovery Re: V5.5-2 Password Recovery: Re: [Q]: How to get BACKUP to relabel tapes automatically?: Re: [Q]: How to get BACKUP to relabel tapes automatically?: Re: [Q]: How to get BACKUP to relabel tapes automatically?: Re: [Q]: How to get BACKUP to relabel tapes automatically?: Re: [Q]: How to get BACKUP to relabel tapes automatically?: Re: [Q]: How to get BACKUP to relabel tapes automatically?  F ----------------------------------------------------------------------  + Date: Sat, 25 Aug 2001 15:33:06 -0700 (PDT) . From: Fabio Cardoso <fabiopenvms@yahoo.com.br>( Subject: Re: Alpha - Complete for USD599> Message-ID: <20010825223306.210.qmail@web20206.mail.yahoo.com>  1 May Islandco put this Alpha in an Amiga 1200 case & US$200,00 ? Taxes problems here :-))))   Regards    FC=20 6 --- "David J. Dachtera" <djesys.nospam@fsi.net> wrote: > "www.islandco.com" wrote:  > >=205 > > Yep - September is here and we are shipping these  > little puppies.  > >=20 > > Configured as follows: > >=20# > > 433Mhz CPU 21164 EV56 at 433Mhz * > > 128MB Memory 10/100 Ethernet On Board, > > S3Trio64 2MB > > 1.44Mb Floppy +  > > 4x SCSI CDROM 2 > > Unix/Linux SCSI Ctr PCI 2GB  7200rpm Disk SCSI > Wide# > > Keyboard Generic 3 Button Mouse  > >=205 > > VMS compatible system requires different (QLogic)  > controller add $51 > >=20! > > 23 in stock and ready to go !  >=20) > I HAD to congratulate you on this price  > breakthrough. That's the best & > deal on a "new" Alpha I've seen yet. >=205 > Keep up the good work. Hope you sell 'em all before 
 > 15-Sep-2001 ' > (arbitrary day - no special meaning).  >=20 > --=20  > David J. Dachtera  > dba DJE Systems  > http://www.djesys.com/ >=20* > Unofficial Affordable OpenVMS Home Page:! > http://www.djesys.com/vms/soho/      =3D=3D=3D=3D=3D L =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D  F=E1bio dos Santos Cardoso OpenVMS System Manager Rio de Janeiro - Brazil  fabiopenvms@yahoo.com.brL =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D   2 __________________________________________________ Do You Yahoo!?H Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/    ------------------------------  % Date: Sat, 25 Aug 2001 20:44:24 +0200 , From: Didier Morandi <Didier.Morandi@gmx.ch>@ Subject: Are consultants "poor" consultants (was: DCL challenge)& Message-ID: <3B87F208.2726AC6A@gmx.ch>  & paddy.o'brien@zzz.tg.nsw.gov.au wrote: > L > Well, why not?  Cryptic (or in Didier's lovely word "ununderstandable") is' > sometimes in the eye of the beholder.    Thank you, Paddy.   < > >> Think about the poor consultants who come behind... :-)% >                    ^^^^^^^^^^^^^^^^ J > Are there such?  My organisation believes in outsourcing; it keeps theirN > salary bills down, and these are reducible costs.  Because the two remainingJ > of us are flat out, they employ consultants at n times our salaries.  We5 > still have to hold their hands, and waste our time.    Hmmm...  Er.. Heu?  D Well, you are right. If I spend four months, as I did for Peugeot inB Paris in 1988, to (more or less) rewrite more than two hundred DCLB procs, yes, I did make money, but the Customer had his applicationF working again when I left (the folks who installed the VAX came from aH worldwide famous tier-company which name I will not tell, with BULL GCOSH background. I do not know how they decided to handle executable versionsH in their procs, but the fact is that they also didn't hear about purgingF disks, and the prod. VAX happened to crash because its system disk wasE full. I did a purge (without /keep=2, it has been the very Day when I B learned about this magic) and all .EXE;98 disappeard, leaving onlyH .EXE;99 which were hard coded numbers for test versions. As the ;98 wereG "production" versions, the application went straight to the wastebasket  in one shoot :-(H I do not add that there were NO error messages nowhere giving some cluesC about what was happening, until I discovered that all and every DCL / proc. started with set mess/nof/noi/nos/not...)   L Do not say "so, it was your consultant fault", I followed the STANDARDS! :-)  N > There is a time and place for consultants versus regular employees, but manyN > companies are spending exorbitant money on them to make the books look good.  D When some companies decide to decomission VMS applications, they seeH their VMS expertise leave, which is normal. Then they discover that theyH cannot "decomission" VMS that fast and easy because VMS does just betterF than any other OS, even with the whole stuff rewritten (good luck, you> Cobol/OS 390 programmers), then - I was saying - they need us,D consultants, and they are very happy to find people accepting to flyH from Toulouse to Zurich every Sunday evening, leaving behind a brand newG house, a wife and two kids. Sorry, I mean "a wife, two kids and a brand  new house" :-)  ( > BTW, I do not know the word "gestion".   Accounting or General Ledger (you're welcome :-)    D.   ------------------------------    Date: 25 Aug 2001 18:39:43 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen) O Subject: Cheaper systems with IA64 (was: Conference: CETS-2001 Detailed Update) 3 Message-ID: <8qEZ5P3vRHvf@eisner.encompasserve.org>   a In article <41Ph7.1114$A83.489040@typhoon1.gnilink.net>, "Jeff Killeen" <Jeff@IDM-IO.com> writes:  > 4 > "Bill Todd" <billtodd@foo.mv.com> wrote in message$ > news:9m7fnu$i6o$1@pyrite.mv.net...M >> I suspect that most people haven't really doubted that porting VMS to IA64 M >> was possible:  I've just never considered it particularly desirable, given - >> that it was a step backward in performance  > N > Lets assume you are correct that the _chip_ is slower.  If it turns out thatJ > Compaq can deliver the _system_ with equal to or greater performance forK > equal to or less costs who cares?  Isn't total system performance at cost I > that matters?  If they can deliver the same performance with a 2-way or ? > 4-way IPF for the same cost as a single chip Alpha who cares.  > N > Our segment of the industry has a long history of "cheaper" being bundled upM > to take on "faster", at the same price point, going all the way back to the N > VAX 11/780 cluster.  With InfiniBand and Blade servers (effectively clusters) > in a small rack) the world is changing.  > J > Just so everyone knows my feelings on the subject long pre-date the JuneN > 25th announcement.  I used to go to User Group meetings with Compaq and hearG > the great and wonderful things they were going to do to create market L > identity for Alpha.  I was often the lone voice saying pushing Alpha won'tK > work.  Companies buy solutions and not chips.  They could care less if it G > runs on the foobar chip or whatever.  If they were going to lead with K > technology they should have lead with OpenVMS.  By themselves Alpha chips M > only provide a solution to heating a small room.  Understand in many ways I J > am chuckling today at the mess that Compaq now finds itself in by having> > created its image based on the chip rather than the systems. > M > In the end I want to know that Compaq will deliver systems with the same or K > better performance for the same of less cost.  I don't care if they do it  > with 1, 2, or 4 chips...  3 I have long wanted a cheaper multiprocessor system. M For me, faster is not important -- debugging multiprocessor code is the goal.    ------------------------------  % Date: Sat, 25 Aug 2001 14:09:30 -0400 ' From: "Bill Todd" <billtodd@foo.mv.com> 2 Subject: Re: Conference: CETS-2001 Detailed Update( Message-ID: <9m8pk7$nst$1@pyrite.mv.net>  < "David J. Dachtera" <djesys.nospam@fsi.net> wrote in message! news:3B87DE79.DF70B7AC@fsi.net...  > JF Mezei wrote:  > >  > > "David J. Dachtera" wrote:G > > > Then, Compaq said, "bet your business on Alpha and OpenVMS". Sure K > > > enough, the ads began to appear in the UK and Europe for Alpha, Tru64 , > > > and OpenVMS. Guess what "got it" next? > > H > > Actually, it is funny that Compaq would use the word "bet". When you think K > > about it, bet implies high risk with some chance of a return. So Compaq  was I > > telling customers that any investment in VMS/ALPHA was in fact a bet.  > > I > > The questions is how do the odds of VMS surviving/winning compared to  the odds/ > > of winning Poweball or some other littery ?  > F > "littery" - I realize that's a typo., but the humor of it exquisite! > E > Much is made of the odds of winning if you do buy a lottery ticket.  > @ > ...but what are the odds of winning if you don't buy a ticket?  K Better:  you're guaranteed to break even (which statistically you of course J won't if you buy a ticket), and even get a smidgeon of interest during theH interval between when you would have purchased the ticket and the moment5 when you would have discovered that it was worthless.   G Aside from the pleasure one may get from the gamble, the only reason to H purchase a lottery ticket is if you need a large amount of cash soon butJ won't (even infinitesimally) miss the purchase price (in which case you'veJ nothing to lose).  Or in the extremely unlikely event that the probabilityL of a return enters positive territory *and* seems likely to stay there until the purchase deadline expires.   > G > ...and how does that compare to the odds of "winning" from a business ' > perspective if you don't buy OpenVMS?   K The parallels to the above are obvious.  If you don't risk your business on H VMS's continued viability, there's no way Compaq can screw you (which ofJ course assumes that you believe that some other vendor is more dependable,D but that's not too much of a stretch at this point for several otherH choices).  So to compensate, your need for VMS must be fairly intense orG very short-term, or your faith in Compaq must rise to religious levels.    - bill   ------------------------------  # Date: Sat, 25 Aug 2001 18:10:41 GMT & From: "Jeff Killeen" <Jeff@IDM-IO.com>2 Subject: Re: Conference: CETS-2001 Detailed Update6 Message-ID: <BSRh7.149$Ia1.25294@typhoon1.gnilink.net>  : "JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in message& news:3B87DAA5.8ABA57B2@videotron.ca...  L > Actually, it is funny that Compaq would use the word "bet". When you thinkI > about it, bet implies high risk with some chance of a return. So Compaq  was G > telling customers that any investment in VMS/ALPHA was in fact a bet.   K No more or less than betting your companies future on Windows XP, hp-ux, or G others.  Which do you think is a safer bet for a solid enterprise class L server?  Windows XP Data Center Edition versus OpenVMS or Tru64 running on aE IPF based system?  I know which one I would bet on.  The IT market is J experiencing major technology waves every 18-24 months these days.  Almost; all major base technology decisions these days are a bet...    ------------------------------  % Date: Sat, 25 Aug 2001 14:19:51 -0400 ' From: "Bill Todd" <billtodd@foo.mv.com> 2 Subject: Re: Conference: CETS-2001 Detailed Update( Message-ID: <9m8q7m$o56$1@pyrite.mv.net>  1 "Jeff Killeen" <Jeff@IDM-IO.com> wrote in message 0 news:BSRh7.149$Ia1.25294@typhoon1.gnilink.net... > < > "JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in message( > news:3B87DAA5.8ABA57B2@videotron.ca... > H > > Actually, it is funny that Compaq would use the word "bet". When you think K > > about it, bet implies high risk with some chance of a return. So Compaq  > was I > > telling customers that any investment in VMS/ALPHA was in fact a bet.  > J > No more or less than betting your companies future on Windows XP, hp-ux, orI > others.  Which do you think is a safer bet for a solid enterprise class L > server?  Windows XP Data Center Edition versus OpenVMS or Tru64 running on a G > IPF based system?  I know which one I would bet on.  The IT market is L > experiencing major technology waves every 18-24 months these days.  Almost= > all major base technology decisions these days are a bet...   J Of course, if you instead choose one of the mature and reliable non-CompaqH Unix platforms out there, or something similarly mature and reliable butH non-Unixy from IBM, this straw-man argument collapses:  there really areL dependability differences among vendors, just as there are differences amongF OSs, and the safety of your 'bet' heavily depends on such differences.   - bill   ------------------------------  # Date: Sat, 25 Aug 2001 18:46:54 GMT & From: "Jeff Killeen" <Jeff@IDM-IO.com>2 Subject: Re: Conference: CETS-2001 Detailed Update8 Message-ID: <yoSh7.1028$tS5.909512@typhoon2.gnilink.net>  2 "Bill Todd" <billtodd@foo.mv.com> wrote in message" news:9m8q7m$o56$1@pyrite.mv.net...L > Of course, if you instead choose one of the mature and reliable non-CompaqJ > Unix platforms out there, or something similarly mature and reliable butJ > non-Unixy from IBM, this straw-man argument collapses:  there really areH > dependability differences among vendors, just as there are differences among H > OSs, and the safety of your 'bet' heavily depends on such differences.  J Are you suggesting AIX or Linux is as robust and as mature as OpenVMS when2 it comes to being a solid enterprise class server?   ------------------------------   Date: 25 Aug 2001 19:10:48 GMT3 From: mooney@dogbert.cc.ndsu.NoDak.edu (Tim Mooney) 2 Subject: Re: Conference: CETS-2001 Detailed Update. Message-ID: <9m8t7o$tfe$1@news.ndsu.nodak.edu>  8 In article <41Ph7.1114$A83.489040@typhoon1.gnilink.net>,% Jeff Killeen <Jeff@IDM-IO.com> wrote:    M > In the end I want to know that Compaq will deliver systems with the same or K > better performance for the same of less cost.  I don't care if they do it  > with 1, 2, or 4 chips...   Jeff-   F You made some interesting points, and although I'm a fan of the Alpha,N overall I agree with your statement that it's the total solution that matters.  E The problem is that Compaq has now changed directions enough times insK the last few years that people are really questioning whether *any* currentwJ enterprise product (or solution) from Compaq has long-term viability.  WhyF deploy a solution that involves OpenVMS or Tru64 on any chip, when theG company delivering the solution may end the long-term viability of thate solution in a couple years?l  I We both know that superior technology is rarely the deciding factor (i.e.2D inferior technology often outlasts and eventually kills off superiorI technology for various reasons), so when companies like IBM and Sun offerUI a competing solution, why would any enterprise IT Manager choose Compaq's0G solution, these days?  You can say what you want about IBM and Sun (I'mrG no fan of Sun, the SPARC, or Solaris) or IBM (I'm ok with them), but ITtH Managers can at least really believe that neither of those two companiesI is going to abruptly change course or suddenly ditch a critical componente+ of the solutions they provide to customers.t  N I've been a fan of Digital products for a few years, and I liked the directionI I saw Tru64 UNIX going in the last year -- additional market penetration, J which improves app availability.  It was hard for me to write the previousM two paragraphs, but even fans of Digital's and now Compaq's product offerings - have to be asking themselves, "What's next?".t  G As a side note, one of the trade rags that I read recently rumored that I a precipitous drop in sales of Alpha systems after the omega announcement I was likely the final nail in the coffin for Midwest Systems, which closedRK its doors recently. The current economy certainly was the major factor, butoH the uncertainty with Compaq is a big one too.  Customers, even customersD that look, are having a hard time finding a reason to buy enterpriseH solutions from Compaq, when the solution-provider's committment to those solutions is questionable.   Tim  -- hH Tim Mooney                              mooney@dogbert.cc.ndsu.NoDak.edu> Information Technology Services         (701) 231-1076 (Voice)< Room 242-J6, IACC Building              (701) 231-8541 (Fax)3 North Dakota State University, Fargo, ND 58105-5164P   ------------------------------  # Date: Sat, 25 Aug 2001 19:44:26 GMTe& From: "Jeff Killeen" <Jeff@IDM-IO.com>2 Subject: Re: Conference: CETS-2001 Detailed Update8 Message-ID: <ueTh7.1044$tS5.948324@typhoon2.gnilink.net>  @ "Tim Mooney" <mooney@dogbert.cc.ndsu.NoDak.edu> wrote in message( news:9m8t7o$tfe$1@news.ndsu.nodak.edu...  * > It was hard for me to write the previousE > two paragraphs, but even fans of Digital's and now Compaq's productt	 offeringsP/ > have to be asking themselves, "What's next?".   I I do not disagree this is the heart of the issue.  Compaq needs present a-H convincing case that someone can, with reasonable assurance, place theirJ future in the hands of Compaq and IPF.  IMHO debates about esoteric issuesI around the fine points of chip architectures miss the point.  TechnicallymK this is a doable transition.  The questions really are related to Compaq as0G partner.  IMO the test to see how firm a public commitment Compaq makese( about certain aspects of the conversion.  K For example are Alpha and VAX licenses going to receive full credit towards J IPF licenses?  Are they going to guarantee source will compile.  Are mixedJ IPF and Alpha/VAX clusters going to be supported.  Will heterogeneous SANsJ be supported.  Will key 3rd party software convert?  Will all this be done at a reasonable cost?r  F I do get frustrated when I see the discussion focusing on the esotericG aspects of the chips - one way or another those will be solved - either I though elegant engineering or brute force (n-way processor systems).  The J real issues IMO are the non-technical issues that relate to doing business with Compaq.  6 They have some penance to do on the business issues...   ------------------------------  # Date: Sat, 25 Aug 2001 19:48:58 GMT2& From: "Jeff Killeen" <Jeff@IDM-IO.com>2 Subject: Re: Conference: CETS-2001 Detailed Update6 Message-ID: <KiTh7.295$Ia1.66096@typhoon1.gnilink.net>  @ "Tim Mooney" <mooney@dogbert.cc.ndsu.NoDak.edu> wrote in message( news:9m8t7o$tfe$1@news.ndsu.nodak.edu...K > We both know that superior technology is rarely the deciding factor (i.e.aF > inferior technology often outlasts and eventually kills off superiorK > technology for various reasons), so when companies like IBM and Sun offer_K > a competing solution, why would any enterprise IT Manager choose Compaq's0I > solution, these days?  You can say what you want about IBM and Sun (I'm-I > no fan of Sun, the SPARC, or Solaris) or IBM (I'm ok with them), but ITMJ > Managers can at least really believe that neither of those two companiesK > is going to abruptly change course or suddenly ditch a critical component@- > of the solutions they provide to customers.   I I am firm believer that Compaq's (Digital's) most painful wounds are selfeI inflicted.  I do not claim to be expert on other platforms an but haven'toH both IBM and SUN put their customers through major hardware and softwareL changes that forced source level recompiles?  If so technically how are theyJ any less reliable as a business partner? I think the answer is technicallyH they aren't any less reliable but the did it with a lot more finesse and didn't self-inflict wounds...h   ------------------------------  % Date: Sat, 25 Aug 2001 16:11:31 -0400I- From: JF Mezei <jfmezei.spamnot@videotron.ca> 2 Subject: Re: Conference: CETS-2001 Detailed Update, Message-ID: <3B880668.10CA71A7@videotron.ca>   Jeff Killeen wrote:sK > I do not disagree this is the heart of the issue.  Compaq needs present a J > convincing case that someone can, with reasonable assurance, place their( > future in the hands of Compaq and IPF.  J IA64 is not the issue. It is outside of Compaq's jurisdiction and is beingL built by a company (Intel) with a fairly good track record for supporting anN architecture once it has been launched. And IA64 is close enough to being realE at this point in time that it is a safe bet that it won't be aborted.d  J And whether IA64 acheives impressive, acceptable or pitiful performance isJ also not at issue. IA64 will acheive whatever performance it will acheive.L Compaq is captive to that architecture and won't have a choice. And Compaq'sN main competitors are also captive to that architecture so everyone (except IBMI and Sun) will be at an equal footing, not matter the performance of IA64.y  M In the end, box makers will succeed based on marketing, cabinet colour/designaK and price because they will all offer similar performance. VMS will be at aeI disadvantage because for the same hardware, its added security results inn slower performance.e  I In the past, VMS's slower performance was compensated by VMS running on aiD faster chip compared to competitors. That won't be the case anymore.  I > partner.  IMO the test to see how firm a public commitment Compaq makesw* > about certain aspects of the conversion.  N You are assuming that Compaq will make public commitments. Have you consideredJ the possibility that Compaq will deal with each of its remaining customers0 individually as seems to be the case right now ?  
 <speculation>iM Lets say that 300 VMS customers worldwide generate 90% of the profits. Of the N few thousands that remain, Compaq probably figures some attrition rate to lose that 10% over the next 5 years.-  H This means that for Compaq, it can maintain the vast majority of its VMSM profits with a skeletton crew that supports only 300 customers in perhaps 1001 cities around the world. </speculation>  F So, if Compaq decides to focus on the few customers which yield it theL majority of VMS profits, it would also explain Compaq's public silence sinceG from now on, they would deal individually with each of those customers..  N And Compaq need only worry about the limited set of applications used by thoseJ few customers, so a dwindling customer base, shedding thousands of smallerE customers wouldn't really matter to those few focused large remaining I customers since they don't care about application availability (for now).c  N Perhaps Compaq intends to turn VMS into an NSK with a very limited, small, butM highly ofcused customer base. The smaller the customer base, the more focusedIK your developpemnt of the OS can be because you will need to suppport a much , narrower set of configurations/applications.   ------------------------------  % Date: Sat, 25 Aug 2001 16:25:55 -0400d- From: JF Mezei <jfmezei.spamnot@videotron.ca>e2 Subject: Re: Conference: CETS-2001 Detailed Update, Message-ID: <3B8809C8.C174FE14@videotron.ca>   Jeff Killeen wrote: J > both IBM and SUN put their customers through major hardware and software. > changes that forced source level recompiles?  M In the case of IBM, going from 24 to 32 bit adressing (or was it 31 bit ?) onhI its mainframes meant that customers could configure system with much morenJ memory. So there was a significant gain for the pain. And IBM went throughK hoops to make it work and there was no discussion on what IBM's true hiddenuN intentions were with regards to MVS. IBM has no problems telling the world andD wall street casino analysts that its mainframes are very profitable.  M The move from VMS to Alpha not only gave the advantage of increased adressingmN space, but also the promise of a leading edge performance due to its high tech! quality-design risc architecture.r  L The move from Alpha to IA64 gives customers absolutely no new functionality,L and one could argue that it gives less functionality for many reasons (for 4F years, engineers focused on porting instead of moving VMS forwards forK instance). And this assumes that VMS is "fully" ported and that bits aren'ti( left out due to limitations on the chip.  L There is nothing on IA64 boxes that Compaq couldn't have done with Alpha *if Compaq had wanted to*.N If Compaq had wanted to, it could have made Alpha mainstream. It chose not to.  I This current move is clearly a case of customers having to go through thenJ expense/trouble of a port that gives no functional advantage just to allowU Compaq executives to execute their own pet projects (move closer to Intel/Microsoft).e  J In other words, Winkler's religion will force VMS customers to spend extraK money because Winkler's religion doesn't consider Alpha to be kosher, so ityM had to be destroyed. In the end, VMS customers will spend extra money to help 5 Winkler acheive his goal of NT ruling the enterprise.    ------------------------------  # Date: Sat, 25 Aug 2001 20:26:47 GMTw& From: "Jeff Killeen" <Jeff@IDM-IO.com>2 Subject: Re: Conference: CETS-2001 Detailed Update6 Message-ID: <bSTh7.363$Ia1.78657@typhoon1.gnilink.net>  : "JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in message& news:3B880668.10CA71A7@videotron.ca...A > In the end, box makers will succeed based on marketing, cabinet 
 colour/designrK > and price because they will all offer similar performance. VMS will be atd a K > disadvantage because for the same hardware, its added security results inn > slower performance.f >tK > In the past, VMS's slower performance was compensated by VMS running on anF > faster chip compared to competitors. That won't be the case anymore.  J Sorry your argument doesn't hold water because people have been willing toL pay a premium price for that VMS right along. Compaq can continue to deliverK that performance - it won't cost them any more to deliver that premium withoH 2 or 3 IPF chips than 1 Alpha chip. Once fully in production the cost toL Compaq of a IPF chip should be about $700-800 versus about $1700-1800 for anI Alpha (overhead included).   Do the math Compaq can build a system with 2 G IPF processors for the cost one Alpha processor once the IPF processorsh reach volume pricing.e  J Besides in a 20-30K enterprise class server do you really think 1 versus 2< or 3 $500 processor chips will make or break a buy decision?   > VMS will be at aK > disadvantage because for the same hardware, its added security results ina > slower performance.l  L Oh call me foolish but me thinks for enterprise class servers added securityK and reliability are an advantage - not a disadvantage - foolish me thinking  this...    ------------------------------  % Date: Sat, 25 Aug 2001 17:06:20 -0400m- From: JF Mezei <jfmezei.spamnot@videotron.ca>:2 Subject: Re: Conference: CETS-2001 Detailed Update, Message-ID: <3B88133E.1A3945B2@videotron.ca>   Jeff Killeen wrote:mL > Sorry your argument doesn't hold water because people have been willing to/ > pay a premium price for that VMS right along.   L They were willing because at that time, the only serious competition was IBME mainframes which were even more expensive. But now, the up and comingnN el-cheapo systems are rapidly gaining acceptance as being secure enough to betK your business on (yeah, on NT, you really do bet your business), and so ther sames go to NT instead of VMS.  E For the average application, the difference between NT and VMS is not B significant enough to warrant paying the high difference in price.    > Compaq can continue to deliverM > that performance - it won't cost them any more to deliver that premium with % > 2 or 3 IPF chips than 1 Alpha chip.-  N Will VMS be priced the same to run on 3 IA64 CPUs compared to a single Alpha ?    & > Once fully in production the cost toN > Compaq of a IPF chip should be about $700-800 versus about $1700-1800 for an > Alpha (overhead included). e  J Had Compaq wanted to, it could have made Alpha mainstream, at which point,I Alpha per-unit costs would have been way lower then now. The high cost of2J Alpha is self-inflicted since the days of Digital. Compaq had the clout toL make Alpha mainstream if it had wanted to (back in the days of NT running onE Alpha). And it would have most probably killed IA64 before it startedsL seriously. And then, Compaq could have sold Alpha to Intel for far more than> the tidbits it got from giving away the engineers and patents.    N > Oh call me foolish but me thinks for enterprise class servers added securityM > and reliability are an advantage - not a disadvantage - foolish me thinkingk	 > this...n  M Not when it is windows weenies that make purchaing decision for servers. They M think that NT has way too much security as it is (since it prevents them froma playing directly with devices)   ------------------------------  # Date: Sat, 25 Aug 2001 21:37:55 GMTf& From: "Jeff Killeen" <Jeff@IDM-IO.com>2 Subject: Re: Conference: CETS-2001 Detailed Update9 Message-ID: <TUUh7.1066$tS5.1016426@typhoon2.gnilink.net>   : "JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in message& news:3B88133E.1A3945B2@videotron.ca...  H > Will VMS be priced the same to run on 3 IA64 CPUs compared to a single Alpha ?   I These are the types of issues IMO customers should be pressing  Compaq oncD now.  If it requires more than one IPF processor to deliver the sameH performance as an Alpha than VMS and Tru64 license pricing ought to takeH that into account - that includes rounding up when compensating.(i.e. noK playing games with hidden prices increases because you can't buy fractionale IPF chips).i  I These are the types of business issues Compaq has a lot of control over -gL and the types of issues they clearly can do penance over by making decisions that favor the customer...   ------------------------------  % Date: Sat, 25 Aug 2001 18:23:24 -0400f- From: JF Mezei <jfmezei.spamnot@videotron.ca>a2 Subject: Re: Conference: CETS-2001 Detailed Update, Message-ID: <3B88255D.ABB2360A@videotron.ca>   Jeff Killeen wrote:-K > These are the types of issues IMO customers should be pressing  Compaq on(F > now.  If it requires more than one IPF processor to deliver the sameJ > performance as an Alpha than VMS and Tru64 license pricing ought to take > that into account   L The problem is that the IA64 that Compaq intends to commercialise for VMS isJ still very much vaporware since we don't yet know what will trigger CompaqN making VMS available on IA64. We know it is in a 3-4 year timeframe, but we doN not know what will be the state of Alpha then nor what the state/speed of IA64 will be.  I So I doubt very much you will see Compaq making any sorts of commitments.   M Compaq has set a direction. And when enough information will become availableiL to Compaq, it might be able to draw a roadmap. But as far as I am concerned,M Compaq is blindly going where no other box maker has gone before. And that ise; not a quality enterprise customers want to see in a vendor.o   ------------------------------  % Date: Sat, 25 Aug 2001 19:34:12 -050021 From: "David J. Dachtera" <djesys.nospam@fsi.net>.2 Subject: Re: Conference: CETS-2001 Detailed Update' Message-ID: <3B884404.F6B64926@fsi.net>0   Jeff Killeen wrote:c > > > "David J. Dachtera" <djesys.nospam@fsi.net> wrote in message# > news:3B87D696.BA80224E@fsi.net... E > > Then, Compaq said, "bet your business on Alpha and OpenVMS". SurenI > > enough, the ads began to appear in the UK and Europe for Alpha, Tru64t* > > and OpenVMS. Guess what "got it" next? > L > Of course my POV is that Compaq should have always promoted just VMS (noteN > the lack of open) and Unix (note the lack of Tru) and not the hardware. ThatI > POV goes all the way back to the early 90's.  Just think where would berH > today if they had done that?  Chips and hardware will always change...   Indeed just think...  H If Micro$haft had been convinced that Alpha was the 64-bit future, where4 would Itanic be today? (Hint: Is Bismark a herring?)  E ...and had VMS/x86 (aka /IA32) been a reality for going on nine yearsID now, IA64 -> IA32 would be a more logical progression than Alpha - > nothing -> IPF.   G Y'know, I just told someone this a.m. how disenchanted I've become withtB EDP as a whole. Alpha? IPF? IA32? I don't think I even give a damnD anymore. Let Bill Gates HAVE that part of the world. Just leave me aG sunset, a rainbow, a flower, trees, grass, a child's laughter, a loving'A spouse ... and I could give a spit whether Intel becomes the solea% supplier of CPUs in the world or not.t   -- t David J. Dachterah dba DJE Systemss http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/i   ------------------------------    Date: 25 Aug 2001 21:57:59 -05009 From: kaplow_r@eisner.encompasserve.org.mars (Bob Kaplow)w2 Subject: Re: Conference: CETS-2001 Detailed Update3 Message-ID: <EdNHw0aJZJ1l@eisner.encompasserve.org>t  [ In article <3B87D696.BA80224E@fsi.net>, "David J. Dachtera" <djesys.nospam@fsi.net> writes: B > Digital said, "bet your business on Alpha/NT". They even startedE > advertising Alpha/NT in the UK and Europe (post merger). Then, they: > killed Alpha/NT. >  > Fool me once, shame on you.j > C > Then, Compaq said, "bet your business on Alpha and OpenVMS". Sure1G > enough, the ads began to appear in the UK and Europe for Alpha, Tru64 ( > and OpenVMS. Guess what "got it" next? >  > Fool me twice, shame on me.a > J > Now, you're asking Compaq to say, "bet your business on IPF and Tru64 orJ > OpenVMS". I don't see IPF going away, so when the next set of ads startsI > to appear in the UK and Europe, I guess we'll know what to expect, huh?r  L One question I've had from the beginning is what it will cost us, the users,J to convert? Particularly with software licenses, which these days can costM more than the hardware. Will my license transfer from Alpha to IPF ***WITHOUT L COST***? I already spent lots of money to convert VAX licences to Alpha. NFWL will customers pay again, especially when this conversion doesn't buy us the* huge performance increases that Alpha did.  J > How could you even consider that? The next time Compaq says, "bet you'reJ > business", the prospect/customer is going to slam the door in their faceD > after saying, "No, *YOU* bet *YOUR* business. I've heard that lineG > before and got screwed! I *LEARNED* _MY_ lesson, I suggest you do thee > same!"  K True. Compaq has bet its business on IPF. They don't get to bet MY businesss on it.   ------------------------------    Date: 25 Aug 2001 22:01:31 -05009 From: kaplow_r@eisner.encompasserve.org.mars (Bob Kaplow)l2 Subject: Re: Conference: CETS-2001 Detailed Update3 Message-ID: <grIONUbTwKZO@eisner.encompasserve.org>u  _ In article <BSRh7.149$Ia1.25294@typhoon1.gnilink.net>, "Jeff Killeen" <Jeff@IDM-IO.com> writes:-< > "JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in message( > news:3B87DAA5.8ABA57B2@videotron.ca... > M >> Actually, it is funny that Compaq would use the word "bet". When you think1J >> about it, bet implies high risk with some chance of a return. So Compaq > wasoH >> telling customers that any investment in VMS/ALPHA was in fact a bet. > M > No more or less than betting your companies future on Windows XP, hp-ux, ormI > others.  Which do you think is a safer bet for a solid enterprise classpN > server?  Windows XP Data Center Edition versus OpenVMS or Tru64 running on aG > IPF based system?  I know which one I would bet on.  The IT market iseL > experiencing major technology waves every 18-24 months these days.  Almost= > all major base technology decisions these days are a bet...h  I I'd bet on a solution not married to Intel... I've heard lots of rumblingd5 about IBM since the bombshell was dropped on Alpha...e   ------------------------------  % Date: Sat, 25 Aug 2001 23:59:39 -0400i- From: JF Mezei <jfmezei.spamnot@videotron.ca> 2 Subject: Re: Conference: CETS-2001 Detailed Update, Message-ID: <3B88741F.60177E4B@videotron.ca>   Bob Kaplow wrote:0N > One question I've had from the beginning is what it will cost us, the users,L > to convert? Particularly with software licenses, which these days can costO > more than the hardware. Will my license transfer from Alpha to IPF ***WITHOUTc
 > COST***?  J This goes beyond Compaq though. Consider a big company such as CA. BecauseM Compaq isn't marketing VMS, CA has to view the market for its VMS software asa) a closed one for existing customers only.l  J But if CA spends money to port a piece of software, it will expect returnsM within a certain number of years as dictated by Wall Street Casino. And sincehM CA is currently under close scrutiny of shareholders, it would not be seen asrM very good for CA to start spending on a VMS port to IA64 now if the remaininghJ customer base won't start converting for another 4 years and especially if? customers will resist migration from Alpha as long as possible.   M And now, you would want that port to be free to customers ? How would CA costaM justify the costs of porting the software to its shareholders if it can't seej( short term revenus to pay for the port ?  I And it is a vicious circle: the more software vendors will charge for the"I switch of licences, the more customers will delay the port. The more theyd8 delay, the harder it is for CA to cost justify the port.   ------------------------------  # Date: Sun, 26 Aug 2001 04:36:06 GMT & From: "Jeff Killeen" <Jeff@IDM-IO.com>2 Subject: Re: Conference: CETS-2001 Detailed Update9 Message-ID: <W0%h7.1583$tS5.1271055@typhoon2.gnilink.net>d  F "Bob Kaplow" <kaplow_r@eisner.encompasserve.org.mars> wrote in message- news:EdNHw0aJZJ1l@eisner.encompasserve.org...a  G > One question I've had from the beginning is what it will cost us, thep users,L > to convert? Particularly with software licenses, which these days can costD > more than the hardware. Will my license transfer from Alpha to IPF
 ***WITHOUTJ > COST***? I already spent lots of money to convert VAX licences to Alpha. NFW1J > will customers pay again, especially when this conversion doesn't buy us thee, > huge performance increases that Alpha did.  H This is one of the way Compaq can do penance - and they also can make it+ right licensewise with the VAX customers...g   ------------------------------  # Date: Sun, 26 Aug 2001 04:31:44 GMTe& From: "Jeff Killeen" <Jeff@IDM-IO.com>2 Subject: Re: Conference: CETS-2001 Detailed Update8 Message-ID: <QY_h7.1453$Ia1.234979@typhoon1.gnilink.net>  : "JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in message& news:3B88741F.60177E4B@videotron.ca...  $ > Because Compaq isn't marketing VMS  H Not true - they are marketing it.  They just disagree you as to what theL target market is and their definition includes new customers.  Of course itsG pointless to have this discussion unless there is agreement on what the A target market is because by definition they won't be marketing tot non-targeted markets.a  K Now I won't disagree with what Compaq should have done in 1987, 1988, 1989,fG 1990, and 1991 - but last time I checked Mr. Peabody's  WayBack machine 1 isn't available and that bell can't be un-rung...i   ------------------------------  % Date: Sat, 25 Aug 2001 15:39:08 -0400 - From: JF Mezei <jfmezei.spamnot@videotron.ca>c) Subject: Re: Feeling Better about Itanium2, Message-ID: <3B87FED3.A2C4D1DD@videotron.ca>   John McLean wrote:E > This brings up the second point:  Are you speaking personally or on $ > behalf of Compaq in this posting?    Actually the choices would be:   -personally (likely)  -on behalf of VMS group (likely)" -on behalf of Compaq (not likely).  J I make a big differentiation between the VMS group which is trying hard toL survive inside an organisation that is either hostile or doesn't give a shit for VMS.  M When Marcello was given a token marketing budget last year, he had no problemoN using it to promote VMS. One can argue whether the money was spent in the mostM efficient way, but he was happy to spend it. Flahsing balls and umbrellas andn= posters, and actual real advertising in 13 smaller countries.e  M And I feel for the VMS group because I can see that they are trying hard, and'H that it is very hard to score any good points with customers when you doN something good that is then immediatly countered by the big boss that destroys what you have just done.  E Last year, the VMS group moved forwards with that token marketing andeM supposedly turned VMS from a shrinking sales to growing sales. But instead ofnI congratulating them, customers are now back in attack mode because CompaqbM destroyed all the gains made by the VMS grouop last year in one big swoosh onn June 25.  L So now, the VMS group has to find ways to spin the bad news from Compaq intoT something that will look less damaging to VMS to reduce the damage caused by Compaq.    G There was an interesting episode in Babylon 5 some time ago. Sinclair's L girlfriend goes to some new world and is amost killed by some huge mega shipL appearing out of nowhere. At the end, J'Kar explains to her the situation byN pointing to an ant on a flower: Sometimes, when you are so big, you don't even' see the ants that you kill as you walk.e  M Perhaps VMS is so small on Compaq's radar screen that Compaq doesn't even seelR the damage it causes to VMS whenever Compaq opens its mouth. (especially Winkler).  I > Doesn't Compaq realise that their silence about VMS is tantamount to anoC > admission that there is no good news to be found ?  That there isd) > nothing positive that is worth saying ?e  N If you beleive that Compaq does not view VMS as a long term product, but wantsM to do just enough to keep existing key customers on VMS until migration to NT,G becomes viable, then Compaq's silence on VMS is quite clear and easy toeK explain. Remember that Compaq visited the key customers it wants to keep on @ June 25th but doesn't bother informing other customers directly.  L There is no point trying to find alternative explanations until Compaq takes/ hard real actions that prove that theory wrong.c  N For a project/change that is so important, I personally find it insulting thatI we are being told to wait until that USA CETS thing, because not only theAM wait, but also the expectation that all VMS customers will be going there and D that if you don't/can't go, tough luck, you will remain in the dark.  E Prior to the internet, DECUS conferences were in fact the best way todK disseminate information toc customers, especially since DECUS had an active L presence in so many countries. But this time has passed and now the best wayC to disseminate information in through the internet. Waiting for thes4 DECUS-wannabe CETS thing is ludicrous in my opinion.   ------------------------------    Date: 25 Aug 2001 14:57:33 -0700+ From: mend0070@tc.umn.edu (Phil Mendelsohn):) Subject: Re: Feeling Better about ItaniumI= Message-ID: <9fffd0d8.0108251357.61c0dd48@posting.google.com>s  l "Sue Skonetski" <susan.skonetski@compaq.com> wrote in message news:<%Azh7.768$bB1.32693@news.cpqcorp.net>...  J > We don't do everything correct but you know we don't do everything wrong > either.  s  > I'm merely a VMS hobbyist and a child of DEC, so this isn't anC important post.  I have heard only good things about Ms. Skonetski,a and am in no way attacking her.   ? That said, the irony of the above sentence nearly killed me.  I C believe you meant "We don't do everything correctly, but, you know,o& not everything we do is wrong either."  @ Whether it was due to a mildly stressful topic, the same lack ofF proofreading to which we all fall prey on usenet, or just because theyD were right when the Dept. of Tourism said "Texas:  it's like a whole$ 'nother country," it was a funny. :)   ------------------------------   Date: 25 Aug 2001 23:17:36 GMT' From: dashw459@aol.comeatspam (Doug W.).) Subject: Re: Feeling Better about Itaniumf9 Message-ID: <20010825191736.24220.00001748@mb-fc.aol.com>t   Don Sykes wrote:J << B) The EV6 & EV7 teams are still at Compaq and will continue to deliverB improvements for the next few (~3) years. So even if the new IntelH design doesn't deliver, they could extend the Alpha line until the Intel does deliver. >>  J Will Compaq also continue to improve the compilers or are these people now working for Intel?   ------------------------------  + Date: Sat, 25 Aug 2001 16:12:59 -0700 (PDT)n. From: Fabio Cardoso <fabiopenvms@yahoo.com.br>) Subject: Re: Feeling Better about Itaniuml@ Message-ID: <20010825231259.16356.qmail@web20209.mail.yahoo.com>   Sue   % Dont worry about the people here !=20s5 We are a group of VMS nuts and geeks, only this ! :-)u- Some frustrated, some happy, some angry, some 4 distracted.... but it is normal in the IT market.=201 Like Indiana Jones, people here like antiquies=20r. like PDPs and VAXes,and fight for them ! :-)))    3 So, dont fell bothered about them ! At the end, thet4 Roman Empire was over, the Napoleon Empire was over,6 the Soviet Union was over .... the OpenV@#$#$@DQW@#$@$
 NO CARRIER   Regardsb   FC=20i+ --- John McLean <mcleanj@dplanet.ch> wrote:i	 > Hi Sue,w >=20 > A couple of comments ... >=205 > Personally I have no problem with people expressingh > positive opinionsa6 > provided that those opinions are reasonably grounded > in fact.  On the5 > other hand, if their opinions are wildly optimisticp
 > or based onA3 > half-truths or falsehoods, I think they should bem > told.  It is clear/ > that Compaq is still in the process of making  > decisions about a range of6 > matters about the migration to IPF so I believe that > it is quite fair tos2 > tell Don to take the comments from Compaq with a > grain of salt at thisn > point in time. >=204 > This brings up the second point:  Are you speaking > personally or on/ > behalf of Compaq in this posting?  If you arei > speaking for Compaq then I1 > must say that I find it very ironic that Compaq  > defends a customer5 > making positive statements about VMS given Compaq'so > own silence about 
 > VMS issues.e >=202 > One would assume that as the manufacturer of VMS > Compaq should be able 5 > to find positive things to say that Compaq would bed > constantly saying 5 > them to the world at large.  I am at loss to recallb > the last CPQ Press- > Release that contained any genuine positivea > statements about VMS; theo. > June announcement had a small degree of fact > surrounded by a large layere3 > of unsubstantiated hot air, maybe positive enoughi > for those who still 5 > believe in the easter bunny and the tooth fairy but  > that discounts mostl0 > of us.  Where, for goodness sake, is the Press > Release to say "Hackersn) > admit VMS Security is unbreakable" ?=20v >=205 > Doesn't Compaq realise that their silence about VMSy > is tantamount to and7 > admission that there is no good news to be found ?=20w > That there isb) > nothing positive that is worth saying ?r >=201 > Compaq's silence is probably more negative thano > almost anything that has0 > been said in this newsgroup.  At least in this > newsgroup one cani/ > publicly disagree with a statement and give a  > positive interpretation.=20s3 > Trying to counterbalance Compaq's silence is likeh > fighting against
 > shadows. >=206 > When Compaq start doing something constructive about > VMS then maybe the- > postings in this newsgroup will become more1 > constructive also. >=20 >=20
 > John McLeany >=20 >=20 > =20  >=20 > Sue Skonetski wrote: > >=205 > > You know folks the fact that Don feels better and  > Compaq is trying to 2 > > communicate is a good thing.  People should be > allowed to express their5 > > opinions even if they are good.  I think that theo > newsgroup has to allow0 > > folks to state their opinions with out being > hammered.  If someone hasp1 > > something to positive to say and they want tox > share it they should bei > > allowed to.u > >=204 > > And from personal experience I can tell you,  if > you get hammered as being 1 > > unaware, or swallowing Compaq Bull or you areb > blind or uneducated it surei5 > > does not make you want to communicate and we needp > more communication not/ > > less.  And then all we will be left with isf  > negative baggage that everyone3 > > can complain about in the newsgroup and nothingi > constructive.h > >=205 > > And I know Cathy Stockwell and in the entire timeo > I have known her she has3 > > never said a lie and has communicated as openlyp > and honestly as possible,'6 > > she is an OpenVMS Ambassador and has been with the > company for more than 20 > > years and is a good person.n > >=202 > > We don't do everything correct but you know we > don't do everything wronga4 > > either.  And while I am on the soap box, you can > only say you are sorry for2 > > selling products to different companies for so > long.u > >=20 > > sue      =3D=3D=3D=3D=3D L =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3Df F=E1bio dos Santos Cardoso OpenVMS System Manager Rio de Janeiro - Brazil- fabiopenvms@yahoo.com.brL =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3Dw  2 __________________________________________________ Do You Yahoo!?H Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/d   ------------------------------  % Date: Sun, 26 Aug 2001 07:49:29 +0200/, From: Didier Morandi <Didier.Morandi@gmx.ch>) Subject: Re: Feeling Better about Itaniumt& Message-ID: <3B888DE8.2E5E39FC@gmx.ch>   "Doug W." wrote: >  > Don Sykes wrote:L > << B) The EV6 & EV7 teams are still at Compaq and will continue to deliverD > improvements for the next few (~3) years. So even if the new IntelJ > design doesn't deliver, they could extend the Alpha line until the Intel > does deliver. >> > L > Will Compaq also continue to improve the compilers or are these people now > working for Intel?  A Th announcement stated that the Alpha Engineering Group *and* the 6 Compilers Group went to Intel. Which is what happened.   D.B ================================================================== Poor Consultancy (un)limited   ------------------------------  % Date: Sat, 25 Aug 2001 21:00:43 -0400o, From: James Metcalf <sdn6@pantheon.yale.edu> Subject: GNU screen for AXP/VMSsH Message-ID: <Pine.GSO.4.32.0108252059400.18980-100000@mars.its.yale.edu>  F Does anyone if it's possible to port GNU screen to VMS? Has it already' been done? If so where I can I find it?    Thanks   sdn6   ------------------------------  + Date: Sat, 25 Aug 2001 15:14:30 -0700 (PDT)e. From: Fabio Cardoso <fabiopenvms@yahoo.com.br>J Subject: Re: Incautious Privileged Users (was: Re: Queue/Entry management)@ Message-ID: <20010825221430.72738.qmail@web20207.mail.yahoo.com>  6 I know there are "security" problems here, like the=202 development team using th same priviliged account, even  each one have their own account.3 Ir the 4.000 users in the machine in the same groupe [100,*].  . But this is a cultural problem of a lazy state company.* I am new, I would like to change - but now6 Schlumberger is developing a Security Consoultin here.1 I hope they can change. Not only in OVM, but MVS,t. unix, WNT, etc .... this is the problem of the3 companies which IT systems grow fast just buying=20  machines....     Regardsb   FC=20 0 --- Hoff Hoffman <hoffman@xdelta.zko.dec.nospam> wrote: > In article5 > <OFF456B08A.483CA20E-ON85256AB2.0060C38A@acml.com>,n" > William_Bochnik@acml.com writes:3 > :Do you know a way to avoid deleting entries in ae > queueo2 > :using a "way" to protect the entries from being% > :deleted  by a priviliged account ?s > :The problem is: > :o2 > :The development people have privilges to delete4 > :entries and sometimes, a "sleepy" cobol developer, > :deletes an important entry in the queues. >=203 >   Um, no, you are wrong.  The problem here is theo > sleepy developer withn- >   privileges.  The privilege and protection  > mechanisms are designed to=20I5 >   prevent exactly this situation from happening.=20h > Sleepy or incautious/ >   privileged users are extremely hazardous to  > correct system operation.3 >=203 > :We would like to create a way to protect entriesu > from > :being deleted, just this. >=20+ >   You will want to remove the privileges.n >=206 >   If the privileges exist solely to permit access to > the queues -- this5 >   is extremely unlikely -- you will want to use the  > protection masks2 >   and potentially associate access control lists > (ACLs) with the queues.o >=206 >   Since you will undoubtedly be unable to remove the > privileges (or you6 >   would have done so before asking) you will want to > enable auditing fore3 >   use-of-privileges and such.  While a privilegedi > user can disable the=20u0 >   audits, a truely sleepy privileged user will > probably leave enough=204 >   evidence around for you to find the (privileged) > culprit.   You willA3 >   also want to encourage the users to leave theirt > privileges disabled 3 >   whenever possible, and you will want to provideA > alternative mechanisms4 >   and configurations and procedures that can avoid > the need to assign >   privileges.s >=20 >  =202 >  ---------------------------- #include <rtfaq.h> > -----------------------------u5 >       For additional, please see the OpenVMS FAQ --i > www.openvms.compaq.com   =204 >  --------------------------- pure personal opinion > --------------------------- 5 >    Hoff (Stephen) Hoffman   OpenVMS Engineering =20  > hoffman#xdelta.zko.dec.com >=20     =3D=3D=3D=3D=3DtL =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D- F=E1bio dos Santos Cardoso OpenVMS System Manager Rio de Janeiro - Brazil  fabiopenvms@yahoo.com.brL =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D2  2 __________________________________________________ Do You Yahoo!?H Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/    ------------------------------  % Date: Sun, 26 Aug 2001 07:53:20 +0200 , From: Didier Morandi <Didier.Morandi@gmx.ch>J Subject: Re: Incautious Privileged Users (was: Re: Queue/Entry management)& Message-ID: <3B888ED0.EB16987F@gmx.ch>   Fabio Cardoso wrote: > 5 > I know there are "security" problems here, like thep4 > development team using th same priviliged account, > even" > each one have their own account.5 > Ir the 4.000 users in the machine in the same groupn
 > [100,*]. > 0 > But this is a cultural problem of a lazy state
 > company., > I am new, I would like to change - but now8 > Schlumberger is developing a Security Consoultin here.3 > I hope they can change. Not only in OVM, but MVS, 0 > unix, WNT, etc .... this is the problem of the2 > companies which IT systems grow fast just buying > machines....  E Fabio, I have some experience on introducing a VMS "no privs policy",tG that I did twice for very big companies in France and Switzerland. Sendo! me mail if you wish to know more.a   D.B ================================================================== Poor Consultancy (un)limited   ------------------------------  + Date: Sat, 25 Aug 2001 15:39:09 -0700 (PDT)e. From: Fabio Cardoso <fabiopenvms@yahoo.com.br># Subject: Re: Intersystems and Alphad@ Message-ID: <20010825223909.39084.qmail@web20202.mail.yahoo.com>   I am just informing you ! ! :-)h  1 I hope they will port, their  OpenVMS market will.+ grouw, they will have support for GSs ( > 4  processors). I really hope about it !=20M  . They are arriving here in BR, with a strong=200 marketing campaign...if we could chain Cache and) VMS in South America, should be good !=20r   Regardss   FC=20p      ) --- Scott Vieth <svieth@wi.rr.com> wrote:r6 > Yeah?  What's your point?  I heard the same thing in > person from some > Intersystems repsl2 > at the IDX National Users Conference a few weeks > ago. >=206 > Did you think that they *weren't* going to support a > move to IPF? >=20
 > -Scott ????  >=20 > Fabio Cardoso wrote: >=20	 > > Clickr > >n0 > > http://www.intersystems.com/cache/alpha.html > >o > > It is dated from Aug/8 > >e > > Regardse > >s > > F=E1bio C. > >.6 > > __________________________________________________ > > Do You Yahoo!?6 > > Make international calls for as low as $.04/minute > with Yahoo! Messengere > > http://phonecard.yahoo.com/t >=20     =3D=3D=3D=3D=3DeL =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3Dt F=E1bio dos Santos Cardoso OpenVMS System Manager Rio de Janeiro - Brazile fabiopenvms@yahoo.com.brL =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3Dv  2 __________________________________________________ Do You Yahoo!?H Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/t   ------------------------------  % Date: Sat, 25 Aug 2001 20:21:40 +0200s, From: Didier Morandi <Didier.Morandi@gmx.ch>4 Subject: Re: Is there a why to set verify in sysgen?& Message-ID: <3B87ECB4.29DA0115@gmx.ch>   Howard S Shubs wrote:  > O > In article <3B83EEF4.C37422CA@gmx.ch>, Didier Morandi <Didier.Morandi@gmx.ch>o > wrote: >  > > $ mc sysman : > > sysman> startup set options/output=file/verify=partial > > sysman> ^Z > = > Bizzareness.  What does this do?  STARTUP_Pn modifications?i  D No. Well, I do not think so. Afaik, it sets up some global symbol orP logical name (dunno, never cared about) which are used by sys$system:startup.com  ; > > $ search/number sys$system:startup.log "-W-","-E-","-F"hE > > We (well, most of us) do this since more that 20 years, don't we?W > 4 > Not using SYSMAN.  It hasn't existed for 20 years.  , I was talking about the SEARCH command line.   D.   ------------------------------  % Date: Sat, 25 Aug 2001 16:56:03 -0400r' From: Howard S Shubs <howard@shubs.net>q4 Subject: Re: Is there a why to set verify in sysgen?< Message-ID: <howard-A08778.16560325082001@enews.newsguy.com>  N In article <3B87ECB4.29DA0115@gmx.ch>, Didier Morandi <Didier.Morandi@gmx.ch>  wrote:  . > I was talking about the SEARCH command line.  K You could only do that if there's always been a way to log that stuff to a oI file, which is what I got the impression that SYSMAN command did.  Since  I SYSMAN hasn't been around more than about 8 to 10 years, how was it done   before that utility existed? -- n Howard S ShubsD "Run in circles, scream and shout!"  "I hope you have good backups!"   ------------------------------  % Date: Sat, 25 Aug 2001 17:43:18 -0400u  From: John Santos <JOHN@egh.com>4 Subject: Re: Is there a why to set verify in sysgen?5 Message-ID: <1010825172354.2563A-100000@Ives.egh.com>c  * On Sat, 25 Aug 2001, Howard S Shubs wrote:  P > In article <3B87ECB4.29DA0115@gmx.ch>, Didier Morandi <Didier.Morandi@gmx.ch>  > wrote: > 0 > > I was talking about the SEARCH command line. > M > You could only do that if there's always been a way to log that stuff to a SK > file, which is what I got the impression that SYSMAN command did.  Since  K > SYSMAN hasn't been around more than about 8 to 10 years, how was it done j > before that utility existed? > --   > Howard S ShubsF > "Run in circles, scream and shout!"  "I hope you have good backups!"  I The STARTUP_Px parameters have been around for a very long time, possiblynG since V1.0 (VAX, not Alpha).  I think SYSMAN just gives you a "new" waytE of setting them, but it might be an entirely different mechanism.  (ICH say "new" because I think SYSMAN has been around for at least 10 years.)  E Shortly before I discovered the built-in logging, someone at our siteoG changed systartup_xxx.com to log everything with a @/output=startup.logoF (Originally, I think it called a separate command file, just leaving aD stub for systartup_xxx.com.  I think this was in VMS V3 or so - whenE DCL subroutines came along, someone else changed it to get rid of the % original extra command file and used:i  6 $ call logged_startup/output=sys$manager:systartup.log $ exit $ !) $ logged_startup: subroutine# $ set noon      ! ignore any errorsT $ set verify [...]c $ set noverify $ endsubroutine:  / The guts of systartup_vms.com are in the [...].2  @ This was more useful to us than the built-in logging mechanisms,@ because it only logged our code, which is usually the stuff that= might break!  We got a much smaller, more manageable log fileIA this way.  Most of the sys$system:startup.com stuff logs to OPCOMl= if there are any problems, and we can always turn on the fullp@ logging if we suspect there were problems in the DEC/Compaq part of the startup.-  @ BTW, the "set noon" prevents the command file from blowing up ifB there are errors, but it makes it much more important to check the? log files if you've made any changes to systartup_vms.com.  You9? can't check the log files (and correct things) if you can't logs? in, and it's much harder if disks aren't mounted, logical namesu@ aren't defined, etc. etc.  Way back in the old days, logins wereB enabled in the predecessor of systartup_v5.com (which was replaced> by systartup_vms.com in VAX VMS V6.0 and Alpha VMS V1.0?).  If= you got an error in the startup command file, and didn't havei> "set noon" enabled, you couldn't log in except at the console,> which made remote support virtually impossible.  I don't think@ this is an issue anymore since "$ set logins/interactive" is nowB in sys$system:startup.com.  Still, it is useful to have "set noon"B since it prevents having to reboot because of a minor, correctableE typo in systartup_vms.com, especially when down-time is at a premium.f   -- o John Santosi Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------  # Date: Sat, 25 Aug 2001 22:26:49 GMTs2 From: "John Fredrickson" <jafred@bellatlantic.net>@ Subject: Looking for Digital Serial Number Identication Resource7 Message-ID: <JCVh7.477$Ia1.113227@typhoon1.gnilink.net>   / Dear Digital Equipment Corporation Aficionados,n  J Does anyone know of a resource on the web where you supply a serial numberJ for a Digital product and get the model number, date of manufacture, etc.?  J I've found an old Digital Alphastation and I'd like to know more about it.J It seems to be in the Alphastation 600 series box, but the front label hasJ been removed. It has two numbers on the back: the serial number NI63800016J and another number 041-56514. It also has a label on it that identifies it7 as a prototype that is not for sale outside of Digital.o   Thanks in advance.   -- John Fredrickson Washington, DC   ------------------------------  + Date: Sat, 25 Aug 2001 15:57:28 -0700 (PDT)u. From: Fabio Cardoso <fabiopenvms@yahoo.com.br>D Subject: Re: Looking for Digital Serial Number Identication Resource@ Message-ID: <20010825225728.41696.qmail@web20202.mail.yahoo.com>   Dell have this system online.d' May be Compaq should buy from them !=20n   :-)))   , In 100 days Compaq will become Unisys !!!=20     Regardsy   FC=20a5 --- John Fredrickson <jafred@bellatlantic.net> wrote: 1 > Dear Digital Equipment Corporation Aficionados,s >=205 > Does anyone know of a resource on the web where youe > supply a serial number6 > for a Digital product and get the model number, date > of manufacture, etc.?  >=205 > I've found an old Digital Alphastation and I'd liket > to know more about it.4 > It seems to be in the Alphastation 600 series box, > but the front label hast3 > been removed. It has two numbers on the back: thec > serial number NI638000166 > and another number 041-56514. It also has a label on > it that identifies itM0 > as a prototype that is not for sale outside of
 > Digital. >=20 > Thanks in advance. >=20 > -- > John Fredrickson > Washington, DC >=20 >=20 >=20 >=20     =3D=3D=3D=3D=3DwL =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D  F=E1bio dos Santos Cardoso OpenVMS System Manager Rio de Janeiro - Brazile fabiopenvms@yahoo.com.brL =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3Dt  2 __________________________________________________ Do You Yahoo!?H Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/n   ------------------------------  # Date: Sun, 26 Aug 2001 01:06:15 GMTl' From: "Peter Barone" <barone1@HOME.COM>rD Subject: Re: Looking for Digital Serial Number Identication Resource; Message-ID: <bYXh7.24234$qc.2808941@news1.rdc1.az.home.com>w  
 NI63900016  K The leading 6 stands for 1996 and the 39 is the 39th work week.  Thats whenuI it was manufactured.  This is a valid serial number.  It's to old to givedK you any more info.  I think the NI means it was manufactured in Nashua, News
 Hampshire.   Regardsp Peter Barone Compaq Services   = "John Fredrickson" <jafred@bellatlantic.net> wrote in message 1 news:JCVh7.477$Ia1.113227@typhoon1.gnilink.net... 1 > Dear Digital Equipment Corporation Aficionados,k > L > Does anyone know of a resource on the web where you supply a serial numberL > for a Digital product and get the model number, date of manufacture, etc.? >eL > I've found an old Digital Alphastation and I'd like to know more about it.L > It seems to be in the Alphastation 600 series box, but the front label hasL > been removed. It has two numbers on the back: the serial number NI63800016L > and another number 041-56514. It also has a label on it that identifies it9 > as a prototype that is not for sale outside of Digital._ >_ > Thanks in advance. >  > -- > John Fredrickson > Washington, DC >u >w >  >o   ------------------------------  % Date: Sat, 25 Aug 2001 20:03:41 +0200-, From: Didier Morandi <Didier.Morandi@gmx.ch>6 Subject: Re: Modifying User Accounts - newbie question& Message-ID: <3B87E87C.C038C320@gmx.ch>   Howard S Shubs wrote:x > N > In article <9m871g$fm5$1@news.IAEhv.nl>, "Hans Vlems" <hvlems@iae.nl> wrote: > 6 > > Authorize has the MOFIFY command for that purpose. > % > Or, in English, the MODIFY command.n  / Be good! He broke one teeth this morning... :-)n   D.   ------------------------------  % Date: Sat, 25 Aug 2001 14:29:34 -0400i' From: Howard S Shubs <howard@shubs.net> 6 Subject: Re: Modifying User Accounts - newbie question< Message-ID: <howard-36FCBC.14293425082001@enews.newsguy.com>  N In article <3B87E87C.C038C320@gmx.ch>, Didier Morandi <Didier.Morandi@gmx.ch>  wrote:   > Howard S Shubs wrote:o > > P > > In article <9m871g$fm5$1@news.IAEhv.nl>, "Hans Vlems" <hvlems@iae.nl> wrote: > > 8 > > > Authorize has the MOFIFY command for that purpose. > > ' > > Or, in English, the MODIFY command.n > 1 > Be good! He broke one teeth this morning... :-)>  L Am!  For all I know, foreign version of VMS use foreign language commands.   And I don't know Dutch.I --   Howard S ShubsD "Run in circles, scream and shout!"  "I hope you have good backups!"   ------------------------------  % Date: Sat, 25 Aug 2001 18:57:49 -0500:C From: "Craig A. Berry" <craig.berry@nospam.SignalTreeSolutions.com>e+ Subject: Re: ODS-5 and parse_style question7I Message-ID: <craig.berry-60496A.18574925082001@newsrump.sjc.telocity.net>   = In article <2af2b3d8.0108241315.643b7eae@posting.google.com>,e,  polato@igi.pd.cnr.it (Sandro Polato) wrote:    E > I try to explain better my problem . In my organization there are amF > lot of programmers (students and researchers) that use indifferentlyF > lowercase and uppercase in the file name to create it. To read theirF > output files they use some application (ghostview for examples) thatC > can't show file names in lower or mix case and I would dislike tohG > obligate the users to edit all their programs and change in uppercasec > the file names. G > But it seems there are not alternatives to uppercasing the file nameslE > because we can't upgrade all that limited applications and the "SETt: > PROC/PARSE=TRADITIONAL" command works only at DCL level.  F If the programs are written in C or use the C RTL to create or report F file names, you may find it helpful to read the documentation section E entitled "The Compaq C RTL supports case preservation in file names" n and located here:   @ <http://www.openvms.compaq.com/commercial/c/5763p.htm#index_x_3>  F At first glance, it sounds like the behavior you want is actually the 1 default, though I haven't studied this carefully.i   ------------------------------  + Date: Sat, 25 Aug 2001 15:04:44 -0700 (PDT)y. From: Fabio Cardoso <fabiopenvms@yahoo.com.br># Subject: Re: Queue/Entry managementt@ Message-ID: <20010825220444.64155.qmail@web20208.mail.yahoo.com>  # Probably this will not work fine=20s here at the Company.  0 When I arrived here the systems were running for more than 10 years.e  6 The main developers are "green badge" (employees)and I6 am "brown badge" (subcontracted) ... do you understand this ?   :-)w   Fabiou    , --- Howard S Shubs <howard@shubs.net> wrote:. > In article <3B869EAB.C23C1F91@videotron.ca>,1 >  JF Mezei <jfmezei.spamnot@videotron.ca> wrote:  >=204 > > This way, you don't need to give the programmers > any privileges.s >=206 > The fun part comes if the programmers have privs for > other tasks, as is=20a0 > usually the case, so you can't take them away. >=201 > To fix that situation, I suspect that making ito > known publically why the=20h/ > important job disappeared would suffice.  Letl# > management take care of the rest.l > --=20  > Howard S Shubs2 > "Run in circles, scream and shout!"  "I hope you > have good backups!"r     =3D=3D=3D=3D=3D=L =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D- F=E1bio dos Santos Cardoso OpenVMS System Manager Rio de Janeiro - Brazilo fabiopenvms@yahoo.com.brL =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3Df  2 __________________________________________________ Do You Yahoo!?H Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/3   ------------------------------  % Date: Sat, 25 Aug 2001 19:02:09 -0400J' From: Howard S Shubs <howard@shubs.net>r# Subject: Re: Queue/Entry managementD< Message-ID: <howard-FF1E1D.19020925082001@enews.newsguy.com>  @ In article <20010825220444.64155.qmail@web20208.mail.yahoo.com>,0  Fabio Cardoso <fabiopenvms@yahoo.com.br> wrote:  # > Probably this will not work fine   > here at the Company. > 2 > When I arrived here the systems were running for > more than 10 years.i > 8 > The main developers are "green badge" (employees)and I8 > am "brown badge" (subcontracted) ... do you understand > this ?  L Depends on the corporate culture.  If they're causing trouble, and it won't O reflect badly on you, screw 'em and don't bother.  If it will reflect badly on eI you, document what you try, making your supervisor well aware of it, and r? you'll be covered.  Some things can't be fixed with technology.s --   Howard S ShubsD "Run in circles, scream and shout!"  "I hope you have good backups!"   ------------------------------  % Date: Sat, 25 Aug 2001 21:24:41 -0400t- From: JF Mezei <jfmezei.spamnot@videotron.ca>e# Subject: Re: Queue/Entry managements, Message-ID: <3B884FD8.FB5B8FB5@videotron.ca>   Fabio Cardoso wrote:8 > The main developers are "green badge" (employees)and I8 > am "brown badge" (subcontracted) ... do you understand > this ?  N Yep, understand. Your job is to prepare in your head/paper a plan to provide aI test/delelopment environment on the same system. Not just queues, but the-K whole kit and caboodle. And then present it to the managers and explain howfB easy it would be to implement and what the added security would beL (programmers not interfering with production). Also important is to devise aN plan that will not cause the programmers to hate it or constantly hit hurdles.   ------------------------------   Date: 25 Aug 2001 23:35:37 GMT' From: dashw459@aol.comeatspam (Doug W.)i Subject: Re: RWMBX9 Message-ID: <20010825193537.24220.00001755@mb-fc.aol.com>n   Bill Ames wrote:" << SOUTHEAST>RUN SYS$SYSTEM:SYSGEN SYSGEN>  SHOW DEFMBXBUFQUOH Parameter                 Name     Current    Default     Min.      Max. Unit    DynamicfL --------------           -------    -------    -------    -------    ----     -------G DEFMBXBUFQUO                 1056       1056       256      64000 Bytest DP SYSGEN>   B Are these really low numbers and can I increase them to get betterH performance.  The business system has way to many programs for me to getI into the source and fix it all. I seem to only have these problems on one_ AXP server. >>  K Without knowing your application its impossible to determine if the defaultoH MBXBUFQUO is adequate or ridiculously undervalued.  Any chance you couldL determine msg lengths, msg writer rates, number of processes writing and how/ many msgs a second your mbx reader can process?   J If not, waste the memory by boosting the MBX to 64K.  Before I messed withO Sysgen, I'd go through the code.  Its likely you will be able to locate the mbx3M creator by doing a SEARCH of the source code.  If you can do this easily, youh# can bump mbx size with a one liner.   
 Good Luck    ------------------------------  % Date: Sat, 25 Aug 2001 21:29:42 -0400-- From: JF Mezei <jfmezei.spamnot@videotron.ca>4 Subject: Re: RWMBX, Message-ID: <3B885105.6ACD14EA@videotron.ca>   "Doug W." wrote:L > If not, waste the memory by boosting the MBX to 64K.  Before I messed with# > Sysgen, I'd go through the code. 4    N There are logical names that can be defined prior to the creation of a mailboxN to define if the mailbox will be temporary, permanent etc. Would there be someL logical name that can be created prior to image activation that would define3 the default mailbox buffer quota for that process ?l   ------------------------------   Date: 25 Aug 2001 23:45:50 GMT' From: dashw459@aol.comeatspam (Doug W.)n@ Subject: Re: RWMBX - What to do, What to do! Help me if you can.9 Message-ID: <20010825194550.24220.00001757@mb-fc.aol.com>    JF Mezei wrote:I  M << If the problem is simply a question of throughput where the client submits N transactions faster than the server can read them, hence putting the client inM RWMBX *temporarily* while the server catches up, is there anything inherentlyr wrong with a process in RWMBX ?r  >>7  N It may not matter if it only happens occasionally.  But on a busy machine withM many writers its a performance diaster that occurs a precisely the wrong timeHL (when you are busy).  MBX fills putting N writers into RWMBX, server reads aM msg, take N processes out of RWMBX.  Oh no, one of the writers qued a msg andd8 filled the mbx again, put N-1 processes back into RWMBX.  B Which I suppose is why MBXs aren't recommended for heavy traffic. - Unfortunately, most people use them this way.!   ------------------------------  % Date: Sat, 25 Aug 2001 21:44:45 -0400e- From: JF Mezei <jfmezei.spamnot@videotron.ca>S@ Subject: Re: RWMBX - What to do, What to do! Help me if you can., Message-ID: <3B88548A.5442A1FF@videotron.ca>   "Doug W." wrote:O > msg, take N processes out of RWMBX.  Oh no, one of the writers qued a msg andm: > filled the mbx again, put N-1 processes back into RWMBX.  I Consider a process that sends data to a terminal running at 110 baud. ThehH process would be able to send data at way faster rates than the port canM handle, so the process is throttled back (doesn't it go in LEF while it waitse for QIOs to complete ?  N Seems to me that RWMBX is just a thorttling mechanism for processes that writeL to mailboxes. Does RWMBX cause process context drawbacks that are much worse than a process going to LEF ?r   ------------------------------    Date: 25 Aug 2001 18:55:01 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen)wU Subject: Re: SHOCK HORROR! $persona_reserverve requires Detach/Impersonate privilege!w3 Message-ID: <A7mu7l3nxdRO@eisner.encompasserve.org>   _ In article <9m85v8$4q$1@uranium.btinternet.com>, "Richard Maher" <maher_rj@hotmail.c*m> writes:r > Hi,. > L > If you look under the "Privileges required" section in the System ServicesB > Reference manual for the $persona_reserve service it clearly andM > unambiguosly states *"None"*.  But when you try and use it without privs it 3 > tells you that IMPERSONATE privilege is required.m > J > Please patch this immediately :-) Ok. The next series of patches will be > fine.  > M > It is my understanding that $persona_reserve and $persona_delegate allow usyJ > to get around the problem of not being able to call out to secureshr.exeH > from a UWSS. (Interestingly enough I see that now only $persona_createJ > resides in secureshr.exe and all the others have been made "real" system > services.) > A > $persona_reserves requires *NO!* privileges. Please make it so!f  F Regardless of what the documentation says, the behavior should be thatF which is consistent with the VMS security model.  Sometimes that meansG correcting the documentation rather than the code.  (And another poster  indicates they have done so.)b   ------------------------------  + Date: Sat, 25 Aug 2001 15:31:20 -0700 (PDT) . From: Fabio Cardoso <fabiopenvms@yahoo.com.br>P Subject: System Managers (was: Wailing at Eunuchs (was: Wailing and Moaning...))@ Message-ID: <20010825223120.10839.qmail@web20209.mail.yahoo.com>  1 I work with VMS for a long time and I allways had,4 other roles in my job. I used to manage heterogeneus4 systems: VAX/Alpha/Sparc/WNT...and buy supplies, cut0 cables, give support to end-users, nowadays I am, strictly with OVMS because of some "politics
 problems".  2 I am graduated in Telecommunications Technology (a4 kind of 3 years course here) but I never worked with3 telecomm itself. I still have hope to jump to Ciscoo- stuff in the next year. I allways worked with.3 LAN/WAN/OSs/Users.... I would like to have a strongt/ background in OSes internals. But here in Southr0 America, the universities dont have good "kernel eating" courses.4 The computing schools "dont teach" C++ and Assembler2 (I had it in the University but just to "printf")./ This is why our SAP (4GL) marketing is growing. 1 The stundents learn VB and Delphi for development.4 (rarely C/C++). A few Java.... The market is full of, Web developers, but without knowledge of OS.6 I am thinking sometimes to jump to the developm market1 but I am feeling without patience in the last fewe0 months. I believe is the 30s crisis arriving....   :-)))i   REgardsc   FC=20 - --- Hamlyn Mootoo <univms@bigfoot.com> wrote:  >=20 >=20 > Fred Kleinsorge wrote: > >=20" > > Hamlyn Mootoo wrote in message$ > <3B856D15.155D5F60@bigfoot.com>... > >=204 > > >> Remind me not to work on any of your systems.4 > > >After I get done inheriting the crap that other > people leave, the 2 > > >systems are secure.  But it's possible you've > never been outside5 > > >DEC/Compaq ( don't worry, a lot of ex DEC people- > have the same problemn4 > > >when they get out into the real world).  In the > real world, a large / > > >percentage of systems run with huge holes.h > > >b > >=205 > > While I have been at DEC/Compaq for 22 years now,  > I didn't go theD4 > > college-to-VMS-engineering route.  I worked as a > IBM 360 operator, and as a0 > > programmer writing store-and-forward message > switching for a specializedl4 > > custom OS.  The first 5 years or so of my career > at DEC was as a Software5 > > Specialist, working at customer sites doing PL90,i > remedial support,06 > > installation, etc.  Nor have I retired to a closet > since joininga > > engineering. > >=206 > > Of course, the shops I worked with and for back in > NY, generally were% > > insanely paranoid about security.I > >=20 > > >Except for the standalone1 > > >> systems that I self manage, I neither have  > privledges, or have them
 > > turned/ > > >> on if I do, unless I need them.  I wouldn" > venture to say that outside of a3 > > >> development environment, most production VMSi > shops give the minimal set > > of2 > > >> required privledges to users other than the > system managers. > > >>1 > > >> Installing random images written by sloppy= > programmers sounds dangerous > > on > > >> any OS.6 > > >I don't know what kind of coding you've done, but > this is a standard. > > >tactic to allow users to perform specific > privilege tasks - maybe you 6 > > >should read your own manuals.  For instance let's > say a user needs to32 > > >only delte some lta ports.  A program written > only to do this installedt/ > > >with appropriate privs would do just fine.a > > >s > >=20/ > > Yes, but *you* implied that people blithely- > install "bad" software withu- > > privs, or worse - allow end users to haveo# > excessive privs because they needf4 > > to use poorly written software that needs privs. >=20, > I indicated the latter not the former. =20 >=20 >    Why on earth would you do. > > that?  Are people to lazy or too ignorant? > >=20+ > I believe it's a lack of education. It isi  > understandable from people who7 > have recently moved or coded from other platforms.=20r
 > Actually, ae3 > programmer has to know a little bit about systemsi > management in order to5 > avail himself (gender neutral himself here) of this7 > method.  Quite a few, > system managers on the other hand, are not > programmers.  In the "early"5 > days, a lot of VMS system managers came "up throughy > the ranks" and were 3 > little more than glorified tape jockeys.  I stilla > remember in some shops2 > that their was this notrious "glass wall" behind > which the programmerst1 > could not go, even to get their printouts.  Thet > operators and system5 > managers had full access, but generally didn't knowl > much about5 > programming.  This created a bit of rivalry betweene > the "systems" people3 > and the application programmers which didn't helpD > the finger pointingi5 > when something didn't work.  I remember doing a VMS  > upgrade (circa 5.0)-5 > after which an in-house application developer swore2 > up and down that iti6 > broke his code somehow.  Knowing that what I did had > very little if5 > anything to do with what he was coding, I asked himc > to show me the codeo3 > ( it was COBOL, ugh).  After his initial confused" > look, he let me take a0 > look.  I compiled and linked it with Debug and > nonchalantly stepped5 > through his code and in about 4 minutes pointed outr > the problem.  He had0 > made his changes around the same time that the > upgrade had been done, so:1 > naturally he thought it was that.  I could tellt > though, that he was notU5 > familiar with the symbolic debugger so I gave him aC > few pointers3 > afterwards.  This went a long way in establishing@ > and keeping thea& > credibility of the operations staff. >=200 > > Is this just some admission that in the real > world, bad practices are just 6 > > too appealing?  And good ones just too hard?  It's > not like we've made thes$ > > hoops that hard to jump through.     =3D=3D=3D=3D=3DeL =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3Di F=E1bio dos Santos Cardoso OpenVMS System Manager Rio de Janeiro - Brazilo fabiopenvms@yahoo.com.brL =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D-  2 __________________________________________________ Do You Yahoo!?H Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/-   ------------------------------  % Date: Sat, 25 Aug 2001 20:17:17 +0200t, From: Didier Morandi <Didier.Morandi@gmx.ch>% Subject: Re: V5.5-2 Password Recoveryr% Message-ID: <3B87EBAC.5D7E310@gmx.ch>n   Malcolm Dunnett wrote: >  ../..oI >    I certainly hope not. Given how much Microsoft stole from VMS for NTd ../..t  H This sentence does not make sense. The principal engineer for NT is DaveK Cutler, who used to be one of the creators of VMS (remember: VMS + 1 = WNT)'   Choose your words carefully.  , (this forum is really becoming a soapbox :-)   D.   ------------------------------  % Date: Sat, 25 Aug 2001 14:38:30 -0400u) From: "Neil Rieck" <n.rieck@sympatico.ca>p% Subject: Re: V5.5-2 Password Recoveryc; Message-ID: <%gSh7.67742$wZ3.5135477@news20.bellglobal.com>R  > "Malcolm Dunnett" <nothome@spammers.are.scum> wrote in message& news:mXAFfH6TnITE@malvm6.mala.bc.ca... >oG > Keep in mind that before a bad guy can get ahold of a hashed passwordeH > to try his guessing program on you already have a security breach. TheI > UAF is not intended to be readable by non-system users, so it should becE > difficult for anyone to get the hashed password in the first place.i >y  - You are obviously not an X-files watcher. :-)'  G I'm not worried about someone breaking into my OpenVMS system, but I am2I worried about someone with privs doing something illegal. For example, ifmL wished to do something criminal I may want to log on as someone else, commitK my fraud, then put everything back in order to cover my tracks. As a systemaL manager I already have privs to change someone's password, but I didn't have% the tools to put it back (until now).g  I Now let me stress that I wouldn't ever do this. However, in a big companyeI many more people end up doing system support (and getting priv passwords) 1 and I can't vouch for the honesty of any of them.a  K On a related topic you are correct. System routine "sys$hash_password" is a I one-way function which means there is no 100% guarantee that you have thetI actual password, only that you will have an appropriate key which you canl% use to access someone else's account..  L Current documentation states that a password must be comprised of charactersI selected from a set of 38 ("A" to "Z", "0" to "9", "_","$"). The passwordtL length is anything from 1 to 32 (changing a password from within "authorize"J allows you to enter a password shorter than the current minimum). The hashK function combines the USERNAME with the PASSWORD (and SALT) to generate the-K stored 64 bit number. The easiest way to protect your user's accounts is tooE increase the minimum password length. For example, moving from 6 to 83F characters changes the maximum number of password candidates from 6^38J (3.71e+29) to 8^38 (2.07e+62). Note that this last number is very close toJ 2^64 which is the maximum number of unique symbols that can be representedL with 64 bits (ignoring the data contribution of USERNAME to the algorithm of course).  J I accept your argument about lower case, but as machines get faster CompaqA will need to do something (go to a 128 or 256 bit hash perhaps?).4  
 Neil Rieck Kitchener/Waterloo/Cambridge,b Ontario, Canada.! http://www3.sympatico.ca/n.rieck/b   ------------------------------  % Date: Sat, 25 Aug 2001 21:09:23 +0200d, From: Didier Morandi <Didier.Morandi@gmx.ch>% Subject: Re: V5.5-2 Password Recovery & Message-ID: <3B87F7E3.BF57FAD4@gmx.ch>   Neil Rieck wrote:n >  ../...
 > As a systemaN > manager I already have privs to change someone's password, but I didn't have' > the tools to put it back (until now).    $ set def sys$system $ cop sysuaf.dat *) $ mc authorize mod foo/passw=bar/nopwdexpg
 $ set ho 0
 username: foo 
 password: baro $ blablablae $ logout $ delete sysuaf.dat.   D.  B ================================================================== Poor Consultancy (un)limited   ------------------------------    Date: 25 Aug 2001 12:21:12 -07001 From: nothome@spammers.are.scum (Malcolm Dunnett).% Subject: Re: V5.5-2 Password Recoveryn, Message-ID: <RjMp$E95XjDZ@malvm6.mala.bc.ca>  & In article <3B87EBAC.5D7E310@gmx.ch>, 2     Didier Morandi <Didier.Morandi@gmx.ch> writes:   > Malcolm Dunnett wrote: >>   > ../..sJ >>    I certainly hope not. Given how much Microsoft stole from VMS for NT > ../..o > J > This sentence does not make sense. The principal engineer for NT is DaveM > Cutler, who used to be one of the creators of VMS (remember: VMS + 1 = WNT)  > D     What doesn't make sense about it? Cutler knew how VMS worked andJ used many of those same techniques in NT. Reading the NT internals book isJ surprisingly similar to reading the VMS internals manual. You'd think thatH having worked on VMS Cutler would know better than to use case sensitive* passwords ( which was my original point ).   > Choose your words carefully. >   M     Would you prefer I use the word "copied" rather than "stole"? I certainlySO didn't mean to imply any criminal action on Microsofts part ( I believe DigitaleN and MS long ago settled their legal disputes in this area ) but I used "stole"J to suggest that there was no public acknowledgement of how much NT owes toJ VMS in terms of "heritage". I suspect from your email address that EnglishK may not be your first language, so perhaps you're not familiar with the use.: of "stole" in this context, but it's quite a common usage.   ------------------------------    Date: 25 Aug 2001 13:20:22 -07001 From: nothome@spammers.are.scum (Malcolm Dunnett)i% Subject: Re: V5.5-2 Password Recoveryh, Message-ID: <78ewRlvoTJA1@malvm5.mala.bc.ca>  ; In article <%gSh7.67742$wZ3.5135477@news20.bellglobal.com>,m.    "Neil Rieck" <n.rieck@sympatico.ca> writes: > @ > "Malcolm Dunnett" <nothome@spammers.are.scum> wrote in message( > news:mXAFfH6TnITE@malvm6.mala.bc.ca... >>H >> Keep in mind that before a bad guy can get ahold of a hashed passwordI >> to try his guessing program on you already have a security breach. The J >> UAF is not intended to be readable by non-system users, so it should beF >> difficult for anyone to get the hashed password in the first place. >> > / > You are obviously not an X-files watcher. :-)  > I > I'm not worried about someone breaking into my OpenVMS system, but I amrK > worried about someone with privs doing something illegal. For example, if N > wished to do something criminal I may want to log on as someone else, commitM > my fraud, then put everything back in order to cover my tracks. As a systemeN > manager I already have privs to change someone's password, but I didn't have' > the tools to put it back (until now).i >   L     Sure you did. Open the SYSUAF file for write access ( it's just a normalJ RMS indexed file ). Find the relevant record ( you can search by key basedF on username ). Read the record into your program. In BASIC I think the9 module to get the record definition is UAF070DEF so you'd   F   %include "$UAF070DEF" %from %library "SYS$LIBRARY:BASIC$STARLET.TLB"  H   ( this assumes you built the optional system definition files when you installed BASIC ).  ?    Change the quadword at offset UAF070$Q_PWD to your new valueh? ( as determined by encoding it with SYS$HASH_PASSWORD ), saving M the old value somwhere else ( outside the SYSUAF ). Write UAF the record. YouhF can now log into that user with the new password. When your evil deedsH are done reverse the process, writing the saved quadword value back intoI the UAF record. Voila, instant password change - no audit trail, no "lastsF password change" information. Of course the victims old password won'tJ work during the time you have your new password enabled, so make sure he's0 not likely to try logging in during that window.  K     I don't think any of the above counts as giving secrets away - it's allFK pretty clearly documented ( the basic data structures, not the technique ).    > M > On a related topic you are correct. System routine "sys$hash_password" is a K > one-way function which means there is no 100% guarantee that you have the K > actual password, only that you will have an appropriate key which you cans' > use to access someone else's account.n > G    But for all practical purposes the two are identical. There's no wayr= to tell what original string was used to create a hash value.a  N > Current documentation states that a password must be comprised of charactersK > selected from a set of 38 ("A" to "Z", "0" to "9", "_","$"). The passwordsN > length is anything from 1 to 32 (changing a password from within "authorize"D > allows you to enter a password shorter than the current minimum).   E      Right. Those are the figures I based my earlier calculations on.:  
 > The hashM > function combines the USERNAME with the PASSWORD (and SALT) to generate theAM > stored 64 bit number. The easiest way to protect your user's accounts is toeG > increase the minimum password length. For example, moving from 6 to 8 H > characters changes the maximum number of password candidates from 6^38  > (3.71e+29) to 8^38 (2.07e+62).  J    The number of valid 8 character passwords is actually 38^8 (4.34e+12)?.  J    I think you mean changes the minimum number of password candidates. TheJ maximum is always the same because you aren't enforcing a maximum passwordG length, which always remains at 32 ( though I'll grant many users wouldsF never dream of using a password longer than they absolutely have to ).  G   I haven't examined the internals of the hash algorithm, but I imagineuH that for a given 8 character password there could be a 5 or 6 character F string that hashes to the same value. In fact you'd expect this if theC algorithm evenly distributes hash values ( if it doesn't the cleveroD bad guy could probably derive useful information about the original F string length based on hashed value ). This clearly has to be true forL much longer passwords. As we saw earlier there are huge numbers of candidateI strings that all hash to the same value for a given user ( there are more1F possible 13 character passwords than there are possible hash values soG at that level and beyond there have to be multiple strings that hash tonJ the same value ). So forcing 8 character passwords may not be of much help in the "brute force" scenario.   > L > I accept your argument about lower case, but as machines get faster CompaqC > will need to do something (go to a 128 or 256 bit hash perhaps?).n >   J    That would make sense to me, the time required to produce a larger hashH value should not be significant, but the time required to guess a randomD string which encoded to that value would be longer on average. A 256H bit hash would allow 10^77 possible values, which could comfortably holdH unique values for every possible password ( given the current limits and character set ).   ------------------------------  % Date: Sat, 25 Aug 2001 23:05:26 +0200 , From: Didier Morandi <Didier.Morandi@gmx.ch>% Subject: Re: V5.5-2 Password Recoveryt& Message-ID: <3B881315.4CF69B25@gmx.ch>   Malcolm Dunnett wrote: ../..n > Write UAF the record. You H > can now log into that user with the new password. When your evil deedsJ > are done reverse the process, writing the saved quadword value back intoK > the UAF record. Voila, instant password change - no audit trail, no "lasts > password change" information.i  F A system mangler concerned by security would of course have a securityF acl on the sysuaf.dat file and would wonder the day after why s/he hadH "something" write into this file without having an AUDIT alarm triggered (assuming it is enabled)   D.B ================================================================== Poor Consultancy (un)limited   ------------------------------    Date: 25 Aug 2001 14:38:30 -07001 From: nothome@spammers.are.scum (Malcolm Dunnett)o% Subject: Re: V5.5-2 Password Recoverye, Message-ID: <hz5FWuprFW4d@malvm5.mala.bc.ca>  ' In article <3B881315.4CF69B25@gmx.ch>, s1    Didier Morandi <Didier.Morandi@gmx.ch> writes:h   >> Write UAF the record. YouI >> can now log into that user with the new password. When your evil deeds K >> are done reverse the process, writing the saved quadword value back intodL >> the UAF record. Voila, instant password change - no audit trail, no "last  >> password change" information. > H > A system mangler concerned by security would of course have a securityH > acl on the sysuaf.dat file and would wonder the day after why s/he hadJ > "something" write into this file without having an AUDIT alarm triggered > (assuming it is enabled)  E    I suppose, assuming such an ACL exists, but that's not part of theED "out of the box" VMS setup - whereas recording the date the passwordH was last changed by authorize ( or $setuai ) is. Wouldn't all the normalE things that write the UAF (such as every login) trigger the ACL also?lF With all that noise you'd have to be pretty sure what you were lookingE for ( or have a good analysis tool ) to spot the suspicious activity.n  E   Your earlier suggestion about just copying the UAF would also work,gI but there could be traces of that in other users records ( eg other usersnG log in while your copied UAF is active, their last login dates won't beuK recorded when you restore the original file, any password change they mightu have made would be lost, etc ).s   ------------------------------    Date: 25 Aug 2001 18:49:44 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen) C Subject: Re: [Q]: How to get BACKUP to relabel tapes automatically?*3 Message-ID: <Wii4aOVLMMk6@eisner.encompasserve.org>o  U In article <3B87351F.60BEAC3A@gmx.ch>, Didier Morandi <Didier.Morandi@gmx.ch> writes:h > Larry Kilgallen wrote: >> tK >> While that is a good feature, I don't understand why that implementation.> >> is any better than the journal files made by Backup itself. > P > Maybe because all the history is in only one file instead of thousand of .LOG?  < The default file extension for Backup Journal Files is .BJL.; While you can name it anything you want, it would be in then< interest of communications to use the default extension name in discussions here.  9 I don't understand why there would be thousands of files.m7 The format is specifically designed to be extended, andt, to be readable either in forward or reverse.   ------------------------------  # Date: Sat, 25 Aug 2001 11:40:03 GMTd3 From: sy18889@COYOTE.FMR.COM (Bradford J. Hamilton) C Subject: Re: [Q]: How to get BACKUP to relabel tapes automatically?m0 Message-ID: <n8Mh7.67$4W2.128@news-srv1.fmr.com>   Folks,  X I can answer the question regarding the behavior of the seventh tape, since I've tested Z for that condition.  You have to manually reposition to the first tape.  The 7th cart willO just unload; it does not "automagically" reposition to the first tape and load.g   --Brad  Y >In article <1010825061853.2563A-100000@Ives.egh.com>, John Santos <JOHN@egh.com> writes:e1 >On Fri, 24 Aug 2001, Kenneth H. Fairfield wrote:  >e >> John Santos wrote:  >> I5 >> > On Thu, 23 Aug 2001, Kenneth H. Fairfield wrote:h4 <snip of MRU background and problem statement...>> >  D >At my customer's site (where the TZ877 lives), I can load, use, and@ >unload any of the 7 tapes using MRU.  I'm not sure what happensC >after you run off the end of the 7th tape (i.e. in BACKUP); it may B >eject the cartridge, but you can certainly load, init, and unloadD >the 7th tape, then reposition to the 1st tape and load that one and@ >start the backup.  I don't know for sure that this works with aA >TZ877 connected directly to a host SCSI adapter or via an HSZxx,TA >etc.  MRU version V1.4-1, the stacker shows up on the HSJ and inlC >MRU as a "DEC TZ Media Changer9823", and the tape drive as a TZ87.hC >The HSJ50 is running firmware V51J-0.  (I think this is pretty old F >and the current version is V54; I hope they haven't broken anything!) >h <another snip...>> g   Bradford J. Hamilton  bradhamilton@mediaone.net	(home) brad.hamilton@fmr.com		(work)=  ; "All opinions that I express are my own, not my employer's"M   ------------------------------  # Date: Sun, 26 Aug 2001 00:39:16 GMT3/ From: StevenU@POBoxes.com (Steven P. Underwood)=C Subject: Re: [Q]: How to get BACKUP to relabel tapes automatically?_3 Message-ID: <3b884483.1047809124@news.telocity.com>o  B It has been quite a while since I worked on these units, but if myE memory serves me, I believe there was a key switch on the front.  One0E position was a service switch and the other two controlled the actiona# described here, either loop or not.A   Steve@  E On Sat, 25 Aug 2001 11:40:03 GMT, sy18889@COYOTE.FMR.COM (Bradford J.. Hamilton) wrote:   >Folks,l >rY >I can answer the question regarding the behavior of the seventh tape, since I've tested i[ >for that condition.  You have to manually reposition to the first tape.  The 7th cart willeP >just unload; it does not "automagically" reposition to the first tape and load. >- >--Brad- >-Z >>In article <1010825061853.2563A-100000@Ives.egh.com>, John Santos <JOHN@egh.com> writes:2 >>On Fri, 24 Aug 2001, Kenneth H. Fairfield wrote: >> >>> John Santos wrote: >>> 6 >>> > On Thu, 23 Aug 2001, Kenneth H. Fairfield wrote:5 ><snip of MRU background and problem statement...>> >6 >lE >>At my customer's site (where the TZ877 lives), I can load, use, and A >>unload any of the 7 tapes using MRU.  I'm not sure what happens D >>after you run off the end of the 7th tape (i.e. in BACKUP); it mayC >>eject the cartridge, but you can certainly load, init, and unloaddE >>the 7th tape, then reposition to the 1st tape and load that one andwA >>start the backup.  I don't know for sure that this works with aVB >>TZ877 connected directly to a host SCSI adapter or via an HSZxx,B >>etc.  MRU version V1.4-1, the stacker shows up on the HSJ and inD >>MRU as a "DEC TZ Media Changer9823", and the tape drive as a TZ87.D >>The HSJ50 is running firmware V51J-0.  (I think this is pretty oldG >>and the current version is V54; I hope they haven't broken anything!)i >> ><another snip...>>  >e >Bradford J. Hamiltond! >bradhamilton@mediaone.net	(home)  >brad.hamilton@fmr.com		(work) >o< >"All opinions that I express are my own, not my employer's"   Steven P. Underwood,DNRC Whitinsville,MAa StevenU@POBoxes.come   ------------------------------  % Date: Sat, 25 Aug 2001 19:43:53 -0500m1 From: "David J. Dachtera" <djesys.nospam@fsi.net> C Subject: Re: [Q]: How to get BACKUP to relabel tapes automatically? ' Message-ID: <3B884649.4807EA18@fsi.net>t   "Bradford J. Hamilton" wrote:s >  > Folks, > Y > I can answer the question regarding the behavior of the seventh tape, since I've tested.\ > for that condition.  You have to manually reposition to the first tape.  The 7th cart willQ > just unload; it does not "automagically" reposition to the first tape and load.n  H That's where MLU came in handy. I was able to reload the cart. from slot. 0 after examining the cart.'s in the magazine.   -- a David J. Dachterar dba DJE Systemsp http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/a   ------------------------------  # Date: Sun, 26 Aug 2001 04:07:32 GMTm- From: "Richard L. Dyson" <rickdyson@home.com> C Subject: Re: [Q]: How to get BACKUP to relabel tapes automatically?i' Message-ID: <3B8875FF.5BCC695@home.com>h  B > etc.  MRU version V1.4-1, the stacker shows up on the HSJ and inD > MRU as a "DEC TZ Media Changer9823", and the tape drive as a TZ87.D > The HSJ50 is running firmware V51J-0.  (I think this is pretty oldG > and the current version is V54; I hope they haven't broken anything!)-  K What is the current release version of MRU?  Does anyone know how to obtainrG updates?  Is it a royalty product?  Does Compaq charge for it, or is its
 considered part of the drive purchase?l   Rick   ------------------------------  % Date: Sun, 26 Aug 2001 07:45:01 +0200e, From: Didier Morandi <Didier.Morandi@gmx.ch>C Subject: Re: [Q]: How to get BACKUP to relabel tapes automatically?u& Message-ID: <3B888CDD.C95A6AD7@gmx.ch>   Larry Kilgallen wrote: > > > The default file extension for Backup Journal Files is .BJL.= > While you can name it anything you want, it would be in the=> > interest of communications to use the default extension name > in discussions here. > ; > I don't understand why there would be thousands of files. 9 > The format is specifically designed to be extended, and . > to be readable either in forward or reverse.  E Shame on me. I was talking of the .LOG of the batch processes runningiD backups, which of course generate a .LOG (for each disk every day ifE this is how it was designed). As I never used this feature (this is a.H looong time since I *created* VMS operation environments), I thought theB /journal qualifier would create a .BJL for each command, and not a" single file with records appended.   D.B ================================================================== Poor Consultancy (un)limited   ------------------------------   End of INFO-VAX 2001.473 ************************