1 INFO-VAX	Sat, 25 Aug 2001	Volume 2001 : Issue 472       Contents: Re: Comp.os.VMS session at CETS * completely off the VMS topics: 25-aug-1944* completely off the VMS topics: Bear&Dragon) 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: DCL challenge  Re: DCL challenge   Re: Feeling Better about Itanium  Re: Feeling Better about Itanium- Re: Modifying User Accounts - newbie question - Re: Modifying User Accounts - newbie question 7 Re: RWMBX - What to do, What to do! Help me if you can. H SHOCK HORROR! $persona_reserverve requires Detach/Impersonate privilege!P Re: SHOCK HORROR! $persona_reserverve requires Detach/Impersonate privilege! pri Re: V5.5-2 Password Recovery Re: V5.5-2 Password Recovery: Re: [Q]: How to get BACKUP to relabel tapes automatically?  F ----------------------------------------------------------------------  % Date: Sat, 25 Aug 2001 18:07:53 +0200 , From: Didier Morandi <Didier.Morandi@gmx.ch>( Subject: Re: Comp.os.VMS session at CETS& Message-ID: <3B87CD59.B27D6A33@gmx.ch>  & "Brian Schenkenberger, VAXman-" wrote:   > See you all there.  E You send me my plane ticket by (air) mail or should I pick it up from  the TWA desk at Zrich-Kloten?   D.   ------------------------------  % Date: Sat, 25 Aug 2001 15:43:07 +0200 , From: Didier Morandi <Didier.Morandi@gmx.ch>3 Subject: completely off the VMS topics: 25-aug-1944 & Message-ID: <3B87AB6B.D8C58312@gmx.ch>  D Where can I post a message to say "thank you" to the families of allG these military folks who entered Paris with General Leclerc 4th Armored  divison 57 years ago?    :-)    D.   ------------------------------  % Date: Sat, 25 Aug 2001 08:34:17 +0200 , From: Didier Morandi <Didier.Morandi@gmx.ch>3 Subject: completely off the VMS topics: Bear&Dragon & Message-ID: <3B8746EA.80FE6ABB@gmx.ch>  0 In which forum can I ask the following question:  = [start of question to be posted elsewhere. Do not reply here] H I am currently reading Clancy's The Bear and the Dragon and I would likeC to know why a diplomat has to be released after being arrested in a A foreign country where s/he is officially diplomating. Is there an K international treaty or such on diplomacy and police? Where can it be read? ( [end of question to be posted elsewhere]  2 [end of off the VMS topics question. Reply below]    Thanks,    D.   ------------------------------  % Date: Sat, 25 Aug 2001 02:14:42 -0400 ' From: "Bill Todd" <billtodd@foo.mv.com> 2 Subject: Re: Conference: CETS-2001 Detailed Update( Message-ID: <9m7fnu$i6o$1@pyrite.mv.net>  1 "Jeff Killeen" <Jeff@IDM-IO.com> wrote in message 0 news:vvAh7.253$A83.90944@typhoon1.gnilink.net...   ...   : >     1673 You Can Bet Your Business on Compaq and Itanium > J >     Abstract: This session addresses fundamental business issues related toK >     Compaq's AlphaT to Itanium strategy. These issues include: Preserving  > yourD >     already existing investment in your Tru64T UNIX or OpenVMST ITG >     infrastructure; Why the investment you make today in new projects 
 > deployedJ >     on Tru64 UNIX  or OpenVMS, both in terms of hardware and application9 >     development costs, will be preserved in the future;   J At this point, the answer to this question is measured purely in immediateL development and marketing funding dollars:  words and promises are less than useless.    What Compaq is doing  > toG >      insure the long term  viability of OpenVMS and Tru64 UNIX in the 
 > marketplace F >     as technology leading enterprise class servers. These issues and others > are J >     covered, and this session provides the answers to why Compaq's Alpha to	 > Itanium / >     strategy is a safe bet for your business.   D At this point, the answer to this last question necessarily involvesJ performance contracts with penalty clauses:  again, words and promises areJ less than useless - though one would hope that at some time in the future,H after Compaq has taken visible actions (involving significant *monetary*G commitments) that help restore some level of credibility, this might no  longer be the case.    > H > ...we requested session because as we learned more about the technicalJ > aspects of porting from Alpha to VMS many of us realized that it was NOTE > going to be mission impossible.  Anyone with open mind who has been  reading L > 'Hoff' Hoffman's postings in comp.os.vms knows that there has already been a F > lot of thought put into this and this not some wild ass dream of theH > beancounters Houston - there is significant engineering insight behind this.   J I suspect that most people haven't really doubted that porting VMS to IA64J was possible:  I've just never considered it particularly desirable, givenJ that it was a step backward in performance (and actively UNdesirable given/ that the price was the loss of Alpha's future).   F > However, even if you are a believer that the technical issues can beH > addressed we kept hearing back over and over again that folks were notH > believers about the all the business issue aspects.  We asked for thisF > session up front and we were very clear that a ra ra "gloss over the issues4 > with a thin coating of happy dust" would NOT work.  C I for one will be *extremely* surprised if Compaq has anything more J substantive to offer here.  But I'd welcome such a surprise as long as itsK content was real rather than the kind of 'information' that has so far been 2 run up the flagpole to see if anyone would salute.     Frankly I thought CompaqH > was going to duck the session, especially given the expectation that aJ > superficial session wouldn't work, and we were pleasantly surprised thatL > they took the session right away even after we explained our perception ofK > the situation.  You have to give them credit for being willing to lead to " > what may be the hardest session.  I Given the attitude of the Encompass leadership to date, I suspect they'll J have plenty of sympathetic supporters there.  And given the attitude of atK least a significant portion of the customer base, failure to step up to the : plate for such a session could have been pretty expensive.  K Wish I could be there, so I'll look forward to hearing how it turns out.  I H somewhat pity Rich, since I suspect he's going to have to stand up thereL without anything more substantial than what we've already heard.  But he canH perhaps deflect the awkward issues of the lies about Alpha's performanceH potential and cost-effectiveness by pretending that they were 'judgementK calls' rather than outright fabrications, and do the same in support of the K 'value' of the IA64 platform's 'industry-standardness' (without confronting J the issue of its current non-existence).  It'll still be kind of difficultI to justify the impact on VMS and Tru64 sales during the period when these J systems are available only on a lame-duck hardware platform, but since theL Q3 figures won't yet be available he may be able to skate around this one as well.   K (I'm not being snide at Rich here:  he's got responsibilities to get Compaq J through a tight spot here and will simply try to acquit himself as best he? can - likely without deriving much enjoyment from the process.)   B Rich is a personable guy and likely has the advantage of not beingJ personally responsible for the most dubious aspects of this debacle, so heI may well escape relatively unscathed.  The real test will be how well the H actual content of the session stands up to later scrutiny after the goodG feelings are factored out (very much as in the discussion of Don's post  earlier today).    ...   C >     1674  Compaq Directions for Integrating Alpha Chip Technology H >               with the Intel Itanium Processor Family: Executive Panel > J >     Abstract:  Join us for this panel discussion with Compaq engineering > executivesL >     as we discuss the plans for integrating Alpha chip technology into the > Intel Itanium G >     Processor Family (IPF). We'll address your interests and concerns  about  > future >     server and OS roadmaps.  > F > ...this will be the Q&A session with the architectural heavy weights  H This'll be an interesting one too.  Of course, Compaq would seem to haveJ absolutely zero say in how Intel chooses to integrate Alpha technology (orJ not), so one would hope to see a liberal sprinkling of Intel architects on( the panel speaking officially for Intel.  K I'm still betting that the gist will be that at most only minor tweaks will J get to market in IA64 before 2005 (i.e., nothing major by the time the VMSK port is scheduled to ship), then the peripheral EV7 stuff (on-chip glue for G RAMBUS and SMP) in 2005, and maybe some OOO and/or SMT in 2006 or 2007. L Aside from details about future IA64 features (information on which has beenI conspicuously sparse by comparison with Alpha's road maps), dates are the I important thing:  people can promise *anything* if they don't have to say G when it will appear, and the on-time delivery history of IA64 makes any D schedule that appears at all aggressive subject to serious question.   - bill   ------------------------------  # Date: Sat, 25 Aug 2001 14:57:04 GMT & From: "Jeff Killeen" <Jeff@IDM-IO.com>2 Subject: Re: Conference: CETS-2001 Detailed Update8 Message-ID: <41Ph7.1114$A83.489040@typhoon1.gnilink.net>  2 "Bill Todd" <billtodd@foo.mv.com> wrote in message" news:9m7fnu$i6o$1@pyrite.mv.net...L > I suspect that most people haven't really doubted that porting VMS to IA64L > was possible:  I've just never considered it particularly desirable, given, > that it was a step backward in performance  L Lets assume you are correct that the _chip_ is slower.  If it turns out thatH Compaq can deliver the _system_ with equal to or greater performance forI equal to or less costs who cares?  Isn't total system performance at cost G 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.   L Our segment of the industry has a long history of "cheaper" being bundled upK to take on "faster", at the same price point, going all the way back to the L VAX 11/780 cluster.  With InfiniBand and Blade servers (effectively clusters' in a small rack) the world is changing.   H Just so everyone knows my feelings on the subject long pre-date the JuneL 25th announcement.  I used to go to User Group meetings with Compaq and hearE the great and wonderful things they were going to do to create market J identity for Alpha.  I was often the lone voice saying pushing Alpha won'tI work.  Companies buy solutions and not chips.  They could care less if it E runs on the foobar chip or whatever.  If they were going to lead with I technology they should have lead with OpenVMS.  By themselves Alpha chips K only provide a solution to heating a small room.  Understand in many ways I H 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.  K In the end I want to know that Compaq will deliver systems with the same or I better performance for the same of less cost.  I don't care if they do it  with 1, 2, or 4 chips...   ------------------------------  # Date: Sat, 25 Aug 2001 15:04:45 GMT & From: "Jeff Killeen" <Jeff@IDM-IO.com>2 Subject: Re: Conference: CETS-2001 Detailed Update8 Message-ID: <h8Ph7.1117$A83.492323@typhoon1.gnilink.net>  2 "Bill Todd" <billtodd@foo.mv.com> wrote in message" news:9m7fnu$i6o$1@pyrite.mv.net... > 3 > "Jeff Killeen" <Jeff@IDM-IO.com> wrote in message 2 > news:vvAh7.253$A83.90944@typhoon1.gnilink.net... >  > ...  > < > >     1673 You Can Bet Your Business on Compaq and Itanium > > L > >     Abstract: This session addresses fundamental business issues relatedF > >      to Compaq's AlphaT to Itanium strategy. These issues include:G > >      Preserving your already existing investment in your Tru64 UNIX B > >      or OpenVMS IT infrastructure; Why the investment you makeB > >      today in new projects deployed on Tru64 UNIX  or OpenVMS,J > >      both in terms of hardware and application development costs, will$ > >      be preserved in the future; > L > At this point, the answer to this question is measured purely in immediateI > development and marketing funding dollars:  words and promises are less  than
 > useless.  K While I agree that the dollars backing it up are important I would disagree * words are less than useless.  If I hear...  :     "You should be able to compile any source code on IPF"  * ...I will have one reaction.  If I hear...  ;     "You will be able to compile any source code on IPF and %     here is how we will guarantee it"   L ...I will have a much different reaction.  If any Compaq folks are listening. trust me they don't want the first reaction...   ------------------------------  % Date: Sat, 25 Aug 2001 11:47:18 -0500 1 From: "David J. Dachtera" <djesys.nospam@fsi.net> 2 Subject: Re: Conference: CETS-2001 Detailed Update' Message-ID: <3B87D696.BA80224E@fsi.net>    Jeff Killeen wrote:  >  > [SNIP] > M > > > Then after we break for lunch Encompass requested the following session  > (we  > > > wrote the abstract)... > > > > > > >     1673 You Can Bet Your Business on Compaq and Itanium >  > [SNIP] > F > > Indeed. I wrote to Richard suggesting that he may want to consider% > > changing the name of the session.  > G > When Encompass submitted the session we submitted it with that title. F > Compaq took the session and title from us and did not modified it...  G Needles to say (intentional misspelling), I'd have had to disagree with  that.   @ Digital said, "bet your business on Alpha/NT". They even startedC advertising Alpha/NT in the UK and Europe (post merger). Then, they  killed Alpha/NT.   Fool me once, shame on you.   A Then, Compaq said, "bet your business on Alpha and OpenVMS". Sure E 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.   H Now, you're asking Compaq to say, "bet your business on IPF and Tru64 orH OpenVMS". I don't see IPF going away, so when the next set of ads startsG to appear in the UK and Europe, I guess we'll know what to expect, huh?   H How could you even consider that? The next time Compaq says, "bet you'reH business", the prospect/customer is going to slam the door in their faceB after saying, "No, *YOU* bet *YOUR* business. I've heard that lineE before and got screwed! I *LEARNED* _MY_ lesson, I suggest you do the  same!"  D I think you should seriously consider helping someone like myself orC Bill Todd get onto the Encompass board. Why on *EARTH* would you do D anything like that? As Lenny Bruce allegedly said, "you need to haveF (someone like that) around to tell you when you're blowing it". (I sayC "allegedly" because Dustin Hoffman delivered that line in the movie H "Lenny", I have no proof that he ever actually said anything like that.)  H Again, and as always, IMHO - YMMV considerably, possibly to the point of diametric opposition.    --   David J. Dachtera  dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------  % Date: Sat, 25 Aug 2001 11:54:34 -0500 1 From: "David J. Dachtera" <djesys.nospam@fsi.net> 2 Subject: Re: Conference: CETS-2001 Detailed Update' Message-ID: <3B87D84A.90354787@fsi.net>    Jeff Killeen wrote:  > 4 > "Bill Todd" <billtodd@foo.mv.com> wrote in message$ > news:9m7fnu$i6o$1@pyrite.mv.net... > > 5 > > "Jeff Killeen" <Jeff@IDM-IO.com> wrote in message 4 > > news:vvAh7.253$A83.90944@typhoon1.gnilink.net... > >  > > ...  > > > > > >     1673 You Can Bet Your Business on Compaq and Itanium > > > N > > >     Abstract: This session addresses fundamental business issues relatedH > > >      to Compaq's AlphaT to Itanium strategy. These issues include:I > > >      Preserving your already existing investment in your Tru64 UNIX D > > >      or OpenVMS IT infrastructure; Why the investment you makeD > > >      today in new projects deployed on Tru64 UNIX  or OpenVMS,L > > >      both in terms of hardware and application development costs, will& > > >      be preserved in the future; > >nN > > At this point, the answer to this question is measured purely in immediateK > > development and marketing funding dollars:  words and promises are lessd > than > > useless. > M > While I agree that the dollars backing it up are important I would disagreen, > words are less than useless.  If I hear... > < >     "You should be able to compile any source code on IPF" > , > ...I will have one reaction.  If I hear... > = >     "You will be able to compile any source code on IPF and ' >     here is how we will guarantee it"e > N > ...I will have a much different reaction.  If any Compaq folks are listening0 > trust me they don't want the first reaction...  B A this point, in my case, the "how" of any guarantee would have toH include failure-to-perform penalties that are both extremely serious and@ severe, and of sufficient substance to withstand a Supreme Court
 challenge.  1 As the old song says, "We won't be fooled again!"-   --   David J. Dachtera0 dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------  % Date: Sat, 25 Aug 2001 13:04:37 -0400e- From: JF Mezei <jfmezei.spamnot@videotron.ca> 2 Subject: Re: Conference: CETS-2001 Detailed Update, Message-ID: <3B87DAA5.8ABA57B2@videotron.ca>   "David J. Dachtera" wrote:C > Then, Compaq said, "bet your business on Alpha and OpenVMS". SurexG > enough, the ads began to appear in the UK and Europe for Alpha, Tru643( > and OpenVMS. Guess what "got it" next?  J Actually, it is funny that Compaq would use the word "bet". When you thinkK about it, bet implies high risk with some chance of a return. So Compaq was E telling customers that any investment in VMS/ALPHA was in fact a bet.0  N The questions is how do the odds of VMS surviving/winning compared to the odds+ of winning Poweball or some other littery ?    ------------------------------  % Date: Sat, 25 Aug 2001 12:20:57 -0500o1 From: "David J. Dachtera" <djesys.nospam@fsi.net> 2 Subject: Re: Conference: CETS-2001 Detailed Update' Message-ID: <3B87DE79.DF70B7AC@fsi.net>o   JF Mezei wrote:t >  > "David J. Dachtera" wrote:E > > Then, Compaq said, "bet your business on Alpha and OpenVMS". SuretI > > enough, the ads began to appear in the UK and Europe for Alpha, Tru64t* > > and OpenVMS. Guess what "got it" next? > L > Actually, it is funny that Compaq would use the word "bet". When you thinkM > about it, bet implies high risk with some chance of a return. So Compaq wasmG > telling customers that any investment in VMS/ALPHA was in fact a bet.D > P > The questions is how do the odds of VMS surviving/winning compared to the odds- > of winning Poweball or some other littery ?9  D "littery" - I realize that's a typo., but the humor of it exquisite!  C Much is made of the odds of winning if you do buy a lottery ticket.n  > ...but what are the odds of winning if you don't buy a ticket?  E ...and how does that compare to the odds of "winning" from a businessx% perspective if you don't buy OpenVMS?r  G ...and might *THAT* be an interesting premise for a global ad campaign?w  H "You have a better chance of winning the lottery than you have of losing  your data when you run OpenVMS!"   --   David J. Dachterae dba DJE Systemse http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/k   ------------------------------  # Date: Sat, 25 Aug 2001 17:53:32 GMTa& From: "Jeff Killeen" <Jeff@IDM-IO.com>2 Subject: Re: Conference: CETS-2001 Detailed Update8 Message-ID: <wCRh7.1013$tS5.875379@typhoon2.gnilink.net>  < "David J. Dachtera" <djesys.nospam@fsi.net> wrote in message! news:3B87D696.BA80224E@fsi.net...aC > Then, Compaq said, "bet your business on Alpha and OpenVMS". SureeG > enough, the ads began to appear in the UK and Europe for Alpha, Tru64o( > and OpenVMS. Guess what "got it" next?  J Of course my POV is that Compaq should have always promoted just VMS (noteL the lack of open) and Unix (note the lack of Tru) and not the hardware. ThatG POV goes all the way back to the early 90's.  Just think where would bepF today if they had done that?  Chips and hardware will always change...   ------------------------------  % Date: Sat, 25 Aug 2001 19:51:13 +0010n% From: paddy.o'brien@zzz.tg.nsw.gov.auo Subject: Re: DCL challenge5 Message-ID: <01K7K9WVM1GI004B48@tgmail.tg.nsw.gov.au>    JF Marchal wrote:s  F >"Didier Morandi" <Didier.Morandi@gmx.ch> a =E9crit dans le message n= ews: >3B869396.FD905B31@gmx.ch... >> Jean-Francois Marchal wrote:  >> >> ../..F >> > could any DCL guru rewrite the code to get z in one line without=  a pipee ?d >>% >> You should make a choice here, JF:n >>F >> Either you please yourself with the most ununderstandable line(s) = of=20e code,r >u4 >=E7a me plairait particuli=E8rement dans ce cas ...F >juste pour le fun ... je suis de toute fa=E7on le seul =E0 maintenir=	  ce code,sC >qui aurait plut=F4t du =EAtre =E9crit en cobol, en fortran ou en Cl >(c'est une appli de "gestion")p  F Well, why not?  Cryptic (or in Didier's lovely word "ununderstandable= ") is=20F sometimes in the eye of the beholder.  Jf's original request, IIRC, w= as to=20F avoid pipe; use of pipe may be cryptic to some and clear to others.  = It's=20wF also a deterrent to people who like to fiddle with code that they do = not=20F understand.  There was an esoteric use of f$fao in a .COM by Wolfgang= =20s7 Mueller a couple of years ago to access system symbols.o  F Really efficient "black-box" mathematical routines are often difficul= t to=20rF read at a first glance.  Extensive comments have been my personal sav= iour =20@ -- be they algorithms for fun or serious use in my applications.   >> or F >> you consider that one day someone else than you will have to maint= ainr
 >> this code.  >>F >> I have definitely choosen the second option and each time I arrive=  on atF >> Customer's site, I split complicated DCL code to different lines t= oh, >> improve readability and ease maintenance. >>: >> Think about the poor consultants who come behind... :-)#                    ^^^^^^^^^^^^^^^^o  F Are there such?  My organisation believes in outsourcing; it keeps th= eir=20F salary bills down, and these are reducible costs.  Because the two re=
 maining=20F of us are flat out, they employ consultants at n times our salaries. =  We=203 still have to hold their hands, and waste our time.v  F There is a time and place for consultants versus regular employees, b=
 ut many=20F companies are spending exorbitant money on them to make the books loo= k good.j  & BTW, I do not know the word "gestion".   Regards, Paddy   ------------------------------  % Date: Sat, 25 Aug 2001 12:03:15 +0100r. From: Graham Burley <100625.30@compuserve.com> Subject: Re: DCL challenge. Message-ID: <3B879403.2B99C17F@compuserve.com>   Jean-Francois Marchal wrote:K > could any DCL guru rewrite the code to get z in one line without a pipe ?p > $ > Yes of course, I could just use  :" > $ Z = S_'SYSNUM'_'REFNUM'_REFINIF > $ if S_'SYSNUM'_'REFNUM'_REF.nes."" then Z = S_'SYSNUM'_'REFNUM'_REF >    With f$fao:t  2 $ Z = f$fao("!AS!#(AS)", S_'SYSNUM'_'REFNUM'_REF -G         , S_'SYSNUM'_'REFNUM'_REF .eqs. "", S_'SYSNUM'_'REFNUM'_REFINI)u  H Or plain string manipulation (assuming "#" doesn't appear in your data):  H $ Z = S_'SYSNUM'_'REFNUM'_REFINI + "#" + S_'SYSNUM'_'REFNUM'_REF + "#" -9         - "##" - (S_'SYSNUM'_'REFNUM'_REFINI + "#") - "#"a     GT   ------------------------------  % Date: Sat, 25 Aug 2001 18:56:10 +0200 & From: John McLean <mcleanj@dplanet.ch>) Subject: Re: Feeling Better about Itaniums* Message-ID: <3B87D8AA.84ADABBB@dplanet.ch>   Hi Sue,    A couple of comments ...  E Personally I have no problem with people expressing positive opinionsiE provided that those opinions are reasonably grounded in fact.  On thet? other hand, if their opinions are wildly optimistic or based on D half-truths or falsehoods, I think they should be told.  It is clearH that Compaq is still in the process of making decisions about a range ofH matters about the migration to IPF so I believe that it is quite fair toF tell Don to take the comments from Compaq with a grain of salt at this point in time.  C This brings up the second point:  Are you speaking personally or onzH behalf of Compaq in this posting?  If you are speaking for Compaq then IB must say that I find it very ironic that Compaq defends a customerE making positive statements about VMS given Compaq's own silence abouts VMS issues.t  F One would assume that as the manufacturer of VMS Compaq should be ableE to find positive things to say that Compaq would be constantly sayingeF them to the world at large.  I am at loss to recall the last CPQ PressE Release that contained any genuine positive statements about VMS; thetH June announcement had a small degree of fact surrounded by a large layerE of unsubstantiated hot air, maybe positive enough for those who stilleG believe in the easter bunny and the tooth fairy but that discounts mostaF of us.  Where, for goodness sake, is the Press Release to say "Hackers% admit VMS Security is unbreakable" ? o  G Doesn't Compaq realise that their silence about VMS is tantamount to anuA admission that there is no good news to be found ?  That there isc' nothing positive that is worth saying ?a  H Compaq's silence is probably more negative than almost anything that has@ been said in this newsgroup.  At least in this newsgroup one canG publicly disagree with a statement and give a positive interpretation. gB Trying to counterbalance Compaq's silence is like fighting against shadows.  G When Compaq start doing something constructive about VMS then maybe theo> postings in this newsgroup will become more constructive also.     John McLeanr      y   Sue Skonetski wrote: > G > You know folks the fact that Don feels better and Compaq is trying to I > communicate is a good thing.  People should be allowed to express theircJ > opinions even if they are good.  I think that the newsgroup has to allowH > folks to state their opinions with out being hammered.  If someone hasG > something to positive to say and they want to share it they should be 
 > allowed to.  > L > And from personal experience I can tell you,  if you get hammered as beingK > unaware, or swallowing Compaq Bull or you are blind or uneducated it sureoJ > does not make you want to communicate and we need more communication notL > less.  And then all we will be left with is negative baggage that everyone? > can complain about in the newsgroup and nothing constructive.n > L > And I know Cathy Stockwell and in the entire time I have known her she hasK > never said a lie and has communicated as openly and honestly as possible,fM > she is an OpenVMS Ambassador and has been with the company for more than 20  > years and is a good person.y > J > We don't do everything correct but you know we don't do everything wrongM > either.  And while I am on the soap box, you can only say you are sorry for 6 > selling products to different companies for so long. >  > suen   ------------------------------  % Date: Sat, 25 Aug 2001 12:00:00 -0500m1 From: "David J. Dachtera" <djesys.nospam@fsi.net>e) Subject: Re: Feeling Better about Itanium-' Message-ID: <3B87D990.E48EBBF5@fsi.net>    "Kenneth H. Fairfield" wrote:f >  > Sue Skonetski wrote: > I > > You know folks the fact that Don feels better and Compaq is trying to8K > > communicate is a good thing.  People should be allowed to express theirmL > > opinions even if they are good.  I think that the newsgroup has to allowJ > > folks to state their opinions with out being hammered.  If someone hasI > > something to positive to say and they want to share it they should bem > > allowed to.b > >tN > > And from personal experience I can tell you,  if you get hammered as beingM > > unaware, or swallowing Compaq Bull or you are blind or uneducated it sureaL > > does not make you want to communicate and we need more communication notN > > less.  And then all we will be left with is negative baggage that everyoneA > > can complain about in the newsgroup and nothing constructive.p > L > Indeed, there is precedent, in this very news group, for what happens whenM > one (or more) participants take on a role of criticizing nearly every post,oJ > or every post that doesn't take their particular point of few (RIP CJL).O > By my count, and IMHO, there are about 2 1/2 such in the current environment,sI > one particularly abrasive one, and a "few" others that, while not beinglB > abrasive or rude (two Brownie points for each! :-), are tiringly/ > repetitive and make threads run way too long.e > H > In the past case, it was patently clear that CJL's style and frequencyB > drove out other posters, including highly technical, experiencedH > professionals (e.g., Steve Lionel) and newbies and lurkers were simplyI > afraid to post.  When CJL passed, c.o.v became a much more civil place,eJ > many more people started participating, the level of discussion improvedJ > immensely, and and the long, tedious, abusive flame-wars dies out almostG > over night (even though many were very much saddened by his passing).  > K > Ladies and gentlemen, NONE of us benefit from the monopolization of ideasYK > expressed here when those with ideas different from the "majority" (i.e., L > Larry Kilgallen's "Jonny One Notes") posts, choose not to post them eitherH > out of a desire not to be abused publicly by Jonny One Note, or out ofG > disgust for the unprofessional level to which these "discussions", or ! > better, "arguments", have sunk.o > H > Even an old geezer like me who's not afraid to argue a point publicly,I > and be shown to be wrong(!), has a gut reaction when each sentence I'velB > typed in a post gets a snide, denigrating or sarcastic response.C > Pot shots, thinks I.  Not an honest exchange of ideas.  Closer tob > ad hominem attacks.e > H > So here's sympathy for anyone who feels put off by Jonny One Note, and@ > an invitation to please post your ideas, assessments, personalG > professional experience, and to ignore the "abuse" heaped on by thosePG > who want to dominate the discussion and drown out other voices.  JusttF > ignore them.  They won't go away, but don't feel you need to respond > to them either...o   Ken,  G I feel the need to make a public apology to you because I believe I maytB have been unkind to you recently in another thread. For that, I do
 apologize.  E I make no apologies for my opinions, and I would expect the same from 0 anyone else. Our convictions make us who we are.  H We all exceed our thresholds from time to time, but that's no excuse for$ being discourteous or disrespectful.  6 My apologies to you and group for being unkind to you.   -- u David J. Dachtera" dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/f   ------------------------------  % Date: Sat, 25 Aug 2001 14:57:56 +0200e" From: "Hans Vlems" <hvlems@iae.nl>6 Subject: Re: Modifying User Accounts - newbie question( Message-ID: <9m871g$fm5$1@news.IAEhv.nl>  2 Authorize has the MOFIFY command for that purpose.  5 Mat Riain <matei@no.spam.eircom.net> wrote in messageP* news:Aoyh7.4407$s5.55519@news.indigo.ie... > Hello! >-I > Today I was trying to create a new user account and I forgot to specifya someF > of the user's information.  Can someone tell me how I can modify theK > existing account?  I am fairly new to this, so excuse the newbie question 	 > please!d >b	 > Thanks!. >c >    ------------------------------  % Date: Sat, 25 Aug 2001 11:01:18 -0400l' From: Howard S Shubs <howard@shubs.net> 6 Subject: Re: Modifying User Accounts - newbie question< Message-ID: <howard-C0B5A6.11011425082001@enews.newsguy.com>  L In article <9m871g$fm5$1@news.IAEhv.nl>, "Hans Vlems" <hvlems@iae.nl> wrote:  4 > Authorize has the MOFIFY command for that purpose.  # Or, in English, the MODIFY command.n -- : Howard S ShubsD "Run in circles, scream and shout!"  "I hope you have good backups!"   ------------------------------  % Date: Sat, 25 Aug 2001 19:21:30 +0010d% From: paddy.o'brien@zzz.tg.nsw.gov.auI@ Subject: Re: RWMBX - What to do, What to do! Help me if you can.5 Message-ID: <01K7K8W13M020049BD@tgmail.tg.nsw.gov.au>t  H Regarding this topic, I have vague memories of Nick de Smith writing an M "essay" about all resource wait states and potential ways to overcome them.   K This was on all old DECUS tape, but I no longer have the details.  Whether sA his comments and code apply equally to VAX and Alpha, I know not.a  + Just a 5c (minimum .au coinage) suggestion.   
 Regards Paddye   ------------------------------  % Date: Sat, 25 Aug 2001 13:33:47 +0100 , From: "Richard Maher" <maher_rj@hotmail.c*m>Q Subject: SHOCK HORROR! $persona_reserverve requires Detach/Impersonate privilege!e0 Message-ID: <9m85v8$4q$1@uranium.btinternet.com>   Hi,e  J If you look under the "Privileges required" section in the System Services@ Reference manual for the $persona_reserve service it clearly andK unambiguosly states *"None"*.  But when you try and use it without privs iti1 tells you that IMPERSONATE privilege is required.g  H Please patch this immediately :-) Ok. The next series of patches will be fine.0  K It is my understanding that $persona_reserve and $persona_delegate allow useH to get around the problem of not being able to call out to secureshr.exeF from a UWSS. (Interestingly enough I see that now only $persona_createH resides in secureshr.exe and all the others have been made "real" system
 services.)  ? $persona_reserves requires *NO!* privileges. Please make it so!n   Regards Richard Maher.  L FYI. If you call $getjpi (with PID specified as that of the calling process)H after changing persona with $persona_assume, you will receive ss$_noprivK status if the new persona is in the same GROUP UIC and you don't have GROUP L priv or WORLD priv it is outside of the group. If you ommit the PID argumentH to $getjpi then everything is peachy. This cannot be right can it? WhereL does $getjpi get the process' UIC from if not from where $persona_assume has modified it?  0 BTW. VMS 7.3 OS and documentation CD fo VMS 7.2.   ------------------------------  % Date: Sat, 25 Aug 2001 15:37:25 +0200a, From: Didier Morandi <Didier.Morandi@gmx.ch>Y Subject: Re: SHOCK HORROR! $persona_reserverve requires Detach/Impersonate privilege! prii& Message-ID: <3B87AA14.2BF035EB@gmx.ch>   Richard Maher wrote: >  > Hi,r > L > If you look under the "Privileges required" section in the System ServicesC > Reference manual for the $persona_reserve service, it clearly and" > unambiguosly states *"None"*.n   From:mE www.openvms.compaq.com:8000/73final/4527/4527pro_075.html#index_x_892i   $PERSONA_RESERVE (Alpha Only)u   Descriptiona  B This service reserves a persona identifier slot within the currentF process for a specific client process to use in delegating its persona to thist@ process. A reserved persona slot can be deleted by a call to theF $PERSONA_DELETE service. When a return fails, no persona slot has been! reserved for the client process. y  E The delegation of persona is only supported for processes residing onu the same node of a cluster.    Required Access or Privileges    IMPERSONATEr   ------------------------------  % Date: Sat, 25 Aug 2001 11:21:35 -0400T) From: "Neil Rieck" <n.rieck@sympatico.ca> % Subject: Re: V5.5-2 Password Recovery ; Message-ID: <5kPh7.56502$wX5.4465432@news20.bellglobal.com>n  J Watching you people debate this got me thinking that I should at least try it. I wrote thisC http://www3.sympatico.ca/n.rieck/demo_vms/basic-password-search.zipkH DEC-BASIC program in a little more than an hour using two OpenVMS systemK calls (sys$getjpi and sys$hash_password) which are publicly documented hereD< http://www.openvms.compaq.com:8000/72final/4527/4527pro.html/ so I guess OpenVMS really is open after all :-)f  J I estimate that the runtime on an Alpha (EV5/300 MHz) is between 10 and 20G days for a 6 character password (it depends on whether the password waseK AAAAAA, ZZZZZZ, 111111  or 999999). You would need to multiply this time byaF 38 for each additional character in the password. Since better skilledG programmers could probably come up with a more efficient solution, I've K decided to change the minimum password length from 6 to 8 on all my OpenVMSt/ systems via the following command in authorize:a   uaf>mod * /PWDMINIMUM=8   H p.s. ten years out, Compaq may wish to allow case sensitive passwords in OpenVMS   
 Neil Rieck Kitchener/Waterloo/Cambridge,o Ontario, Canada.! http://www3.sympatico.ca/n.rieck/G   ------------------------------    Date: 25 Aug 2001 09:11:29 -07001 From: nothome@spammers.are.scum (Malcolm Dunnett)g% Subject: Re: V5.5-2 Password Recovery., Message-ID: <mXAFfH6TnITE@malvm6.mala.bc.ca>  < In article <5kPh7.56502$wX5.4465432@news20.bellglobal.com>, /     "Neil Rieck" <n.rieck@sympatico.ca> writes:a   > L > I estimate that the runtime on an Alpha (EV5/300 MHz) is between 10 and 20I > days for a 6 character password (it depends on whether the password waseM > AAAAAA, ZZZZZZ, 111111  or 999999). You would need to multiply this time by=3 > 38 for each additional character in the password.e       Not necessarily, see below.s   > Since better skilledI > programmers could probably come up with a more efficient solution, I've M > decided to change the minimum password length from 6 to 8 on all my OpenVMS=1 > systems via the following command in authorize:t > H    Keep in mind that before a bad guy can get ahold of a hashed passwordF to try his guessing program on you already have a security breach. TheG UAF is not intended to be readable by non-system users, so it should berC difficult for anyone to get the hashed password in the first place.e   > J > p.s. ten years out, Compaq may wish to allow case sensitive passwords in	 > OpenVMSa  G    I certainly hope not. Given how much Microsoft stole from VMS for NTsH it's disgusting they didn't steal the idea of case insensitive passwordsE but instead followed the Unix model. In typical MS inconsistancy theyeE did go with case insensitive usernames though. I bet helpdesks aroundCF the world cumulatively spend thousands of hours per year telling users9 to turn the caps lock key off and try their logins again.a  I    When you use a brute force guesser to crack a password hash you're not^H necessarily deriving the original password, you're just finding a randomH string that hashes to the same result. Using a quadword for the passwordG gives you 2^64 (approx 10^19) possible values. Given a maximum passwordtL length of 32 gives you (38^31)+(38^30)+(38^29)...+(38^0) possible passwords,G which is over 10^49. So there are already something like 10^30 possibleoD passwords for every possible hash value ( assuming the hash producesH an even distribution across the possible passwords ). Allowing lowercaseI letters would increase the possible passwords to around 10^56, but they'd0- still all have to hash into the same 64 bits..  C    All this is fairly academic. Passwords are far more likely to beBA compromised by social engineering techniques ( fooling users into F divulging their password ), user carelessness ( passwords written down? or users allowing others to "shoulder surf" their password ) orE: insecure network links ( ethernet sniffers and the like ).   ------------------------------  % Date: Sat, 25 Aug 2001 06:36:04 -0400_  From: John Santos <JOHN@egh.com>C Subject: Re: [Q]: How to get BACKUP to relabel tapes automatically?r5 Message-ID: <1010825061853.2563A-100000@Ives.egh.com>a  0 On Fri, 24 Aug 2001, Kenneth H. Fairfield wrote:   > John Santos wrote: > 4 > > On Thu, 23 Aug 2001, Kenneth H. Fairfield wrote: > >aJ > > >     I've been studying BACKUP's /LABEL=(<label-list>), /EXACT_ORDER,J > > > and /IGNORE=(LABEL_PROCESSING) qualifiers (yes, there is some mutualB > > > exclusion present), in order to solve the following problem. > > : > > [snip a lot of stuff I might regret snipping later...] > >e > > >     So...o > > >oL > > >     Does anyone have a suggestion of how to either (a) force BACKUP toH > > > use the labels I want it to without pre-labeling the tapes, or (b)
 > > > provideeM > > > a (robust, reliable?) method to determine how many tapes a given BACKUPrI > > > job as used (without scanning the log file, which will be held openI > > > during > > > this processing)?o > > >D > > >     Thanks, Ken  > >C5 > > A couple of things you might want to investigate.h > >iI > > 1) The MRU (Media Robot Utility, but Compaq may have changed the namepI > > recently) allows you direct control of the loader.  You could write a I > > command procedure to load each tape in turn and label it (with INIT),nK > > then unload it.  When done, reload the 1st tape and run backup with theu! > > label=() [*] and exact_order.C > G > I'd love to do that.  In fact the init/unload/repeat would be trivialsG > to do from the backup command procedure.  The problem is the TZ877 isaE > NOT a library, it is strictly a stacker.  MRU can't access it.  AndoE > the operational problem is that the stacker ejects the whole 7-tapeyB > cartridge after the last tape is unloaded, which requires manualE > intervention to reload the cartridge.  I can't ask the operators to C > do that: it would burden them with _waiting_ for some message andRG > responding to it, while they're busy getting a dozens of other backup I > procedures running on other clusters/systems.  They don't have the time E > stand around and wait for the 7 tapes to be initialized, and they'diG > likely miss one or more of these messages telling them to go back andt > reload the cartridge.h  C What's the host connection for the TZ877?  The only place I've useduC them is via an HSJ50 to an Alpha 4100, and MRU works fine for this.g  C At my customer's site (where the TZ877 lives), I can load, use, andh? unload any of the 7 tapes using MRU.  I'm not sure what happensSB after you run off the end of the 7th tape (i.e. in BACKUP); it mayA eject the cartridge, but you can certainly load, init, and unload C the 7th tape, then reposition to the 1st tape and load that one andt? start the backup.  I don't know for sure that this works with ax@ TZ877 connected directly to a host SCSI adapter or via an HSZxx,@ etc.  MRU version V1.4-1, the stacker shows up on the HSJ and inB MRU as a "DEC TZ Media Changer9823", and the tape drive as a TZ87.B The HSJ50 is running firmware V51J-0.  (I think this is pretty oldE and the current version is V54; I hope they haven't broken anything!)n   > E > > 2) TAPESYS (I think that's the name, the tape management & backupoH > > product from Software Partners) may do all this.  If you have enoughG > > systems and tapes, this may prove very worthwhile, just for keepinge > > track of things. > F > I'd love to try this out, or SLS, but I'd guess our current stackersF > have insufficient functionality to support either product.  Although? > they might do a better job of trcking the tapes themselves...s >  >     Thanks, Kena > --8 > I don't speak for Intel, Intel doesn't speak for me...   -- e John Santos  Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------   End of INFO-VAX 2001.472 ************************