1 INFO-VAX	Fri, 05 Aug 2005	Volume 2005 : Issue 434       Contents:" Re: "the normal ordering process"? Re: ANNOUNCE: XPdf v3.00pl3  Re: ANNOUNCE: XPdf v3.00pl3  Re: comp.os.vms archives ?/ Data File Search Order in Some VMS Applications 3 Re: Data File Search Order in Some VMS Applications 3 Re: Data File Search Order in Some VMS Applications % Re: Help to find X25 Layered Packages  Re: HP cuts announced  Re: HP cuts announced  Re: HP cuts announced  Re: HP cuts announced / Re: Intel hammer another nail in Itanium coffin / Re: Intel hammer another nail in Itanium coffin / Re: Intel hammer another nail in Itanium coffin / Re: Intel hammer another nail in Itanium coffin / Re: Intel hammer another nail in Itanium coffin 9 Re: minicopy, VAX, ALPHA, SHADOW_MAX_COPY, SYSMAN, SYSGEN 5 minicopy, VAX, ALPHA, SHADOW_MAX_COPY, SYSMAN, SYSGEN   F ----------------------------------------------------------------------   Date: 5 Aug 2005 09:31:00 -0500 - From: Kilgallen@SpamCop.net (Larry Kilgallen) + Subject: Re: "the normal ordering process"? 3 Message-ID: <QQsQJkynjjAg@eisner.encompasserve.org>   [ In article <BF1681F1.11C2A%roktsci@comcast.net>, Jeff Cameron <roktsci@comcast.net> writes: L > On 8/2/05 1:57 PM, in article 00A47B0B.AE905A81@SendSpamHere.ORG, "VAXman-8 > @SendSpamHere.ORG" <VAXman-  @SendSpamHere.ORG> wrote: > J >> OK... I need to break down and get myself a copy of the OpenVMS Itanium7 >> source listings.  On one of the /DSPP pages it says:  >>  H >> DSPP does not provide listings kits.  Partners may order them from HPI >> through the normal ordering process.  Part numbers are provided below.  >>   >>  H >> OK, what *is* a normal ordering process with HP.  My experiences haveG >> not left me to believe that there is such a beast.  Anybody that has A >> obtained the Itanium source listings, please help me out here.  >>  H >> I'm sincerely hoping this doesn't turn into the rack mounting kit de- >> bacle of several months ago.  > I > When you are a registered OpenVMS partner with HP your "normal ordering J > process" is spelled out in the contract, and is different in details for > each partner.    Nice theory.  H > Are you a registered partner? If so your agreement should specify your1 > process. If you are not then you must register.   E Presumably that includes DSPP, for which no such solution is provided ! (which is what Brian was saying).    ------------------------------   Date: 5 Aug 2005 01:15:29 -0700 ' From: "Bart Zorn" <Bart.Zorn@xs4all.nl> $ Subject: Re: ANNOUNCE: XPdf v3.00pl3B Message-ID: <1123229729.447624.88580@g47g2000cwa.googlegroups.com>   Hello Chip,    Thanks for the good work!   G However, using xpdf to view the pdf version of the Unix Haters Handbook F is still not a pleasure. Apparently, one or more of the fonts used are( substituted by others with poor results.  G There are lots of font directories on my system. With probably a lot of B redundancy. But xpdf cannot find what it needs. Sometimes the fullG fontname is in the filename, sometimes it is some cryptic name like the  ones in your post.  & here is the output of pdffonts ugh.pdf  G name                                 type         emb sub uni object ID G ------------------------------------ ------------ --- --- --- --------- G TimesNewRomanPS-BoldMT               TrueType     no  no  no    8785  0 G Futura-CondensedExtraBold            Type 1       no  no  no    1117  0 G Bodoni-Bold                          Type 1       no  no  no    1118  0 G TimesNewRomanPS-ItalicMT             TrueType     no  no  no    1119  0 G Symbol                               Type 1       no  no  yes   1122  0 G TimesNewRomanPSMT                    TrueType     no  no  no    1123  0 G Courier-Bold                         Type 1       no  no  no    1124  0 G Courier                              Type 1       no  no  no    1125  0 G Arial-BoldMT                         TrueType     no  no  no    1126  0 G TimesNewRomanPS-BoldItalicMT         TrueType     no  no  no    1127  0 G Arial-BoldItalicMT                   TrueType     no  no  no    1128  0 G Courier-Oblique                      Type 1       no  no  no    1129  0   9 Could you point me to some documentation regarding fonts?   
 Thanks again,   	 Bart Zorn    ------------------------------  $ Date: Fri, 5 Aug 2005 13:07:05 -0400+ From: Chip Coldwell <coldwell@gmail.nospam> $ Subject: Re: ANNOUNCE: XPdf v3.00pl3R Message-ID: <Pine.OSX.4.63.0508051305330.474@physics-departments-computer-2.local>  $ On Fri, 5 Aug 2005, Bart Zorn wrote:  
 > Hello Chip,  >  > Thanks for the good work!  > I > However, using xpdf to view the pdf version of the Unix Haters Handbook H > is still not a pleasure. Apparently, one or more of the fonts used are* > substituted by others with poor results. > I > There are lots of font directories on my system. With probably a lot of D > redundancy. But xpdf cannot find what it needs. Sometimes the fullI > fontname is in the filename, sometimes it is some cryptic name like the  > ones in your post. > ( > here is the output of pdffonts ugh.pdf > I > name                                 type         emb sub uni object ID I > ------------------------------------ ------------ --- --- --- --------- I > TimesNewRomanPS-BoldMT               TrueType     no  no  no    8785  0 I > Futura-CondensedExtraBold            Type 1       no  no  no    1117  0 I > Bodoni-Bold                          Type 1       no  no  no    1118  0 I > TimesNewRomanPS-ItalicMT             TrueType     no  no  no    1119  0 I > Symbol                               Type 1       no  no  yes   1122  0 I > TimesNewRomanPSMT                    TrueType     no  no  no    1123  0 I > Courier-Bold                         Type 1       no  no  no    1124  0 I > Courier                              Type 1       no  no  no    1125  0 I > Arial-BoldMT                         TrueType     no  no  no    1126  0 I > TimesNewRomanPS-BoldItalicMT         TrueType     no  no  no    1127  0 I > Arial-BoldItalicMT                   TrueType     no  no  no    1128  0 I > Courier-Oblique                      Type 1       no  no  no    1129  0  > ; > Could you point me to some documentation regarding fonts?   D It looks like you found a PDF that has no embedded fonts at all, andD that uses a bunch of TrueType fonts to boot.  I've downloaded a copyD for myself, and I'll take a look at it when I get home.  I installedB the MS core TrueType fonts for my Xpdf, and I'll let you know what happens.   Chip   --   Charles M. "Chip" Coldwell Turn on, log in, tune out    ------------------------------  % Date: Fri, 05 Aug 2005 15:54:48 +0200 0 From: Keith Cayemberg <keith.cayemberg@arcor.de># Subject: Re: comp.os.vms archives ? B Message-ID: <42f37005$0$11758$9b4e6d93@newsread4.arcor-online.net>   JF Mezei wrote: N > Google has killed even Elmer now. All of its interfaces have been massacred, > censored, killed.  > G > Does anyone know if comp.os.vms is being archived elsewhere ? Could a  > searchable archive be setup ?      Hi JF,  ( here are the alternatives known to me...   Deja Power Search - Google3 http://www.geocities.com/tsca.geo/various/deja.html   - Der Keiler - Comp.Os.VMS Clickable Collection 1 http://unix.derkeiler.com/Newsgroups/comp.os.vms/    Gopher: FA.info-vax < http://gopher.quux.org:70/Archives/usenet-a-news/FA.info-vax   Info-Vax Digest Archive - SAIC& http://mvb.saic.com/freeware/info-vax/  $ Info-VAX Mailing List Archive - SAIC ftp://mvb.saic.com/info-vax/  % Info-VAX Archives for 1990-1998 - SRI $ http://www-mpl.sri.com/info-vax.html  > news2mail - Comp.Os.Vms -- DEC's VAX* line of computers & VMS.) http://www.news2mail.com/comp/os/vms.html   % news2mail - Messages from comp.os.vms 2 http://www.news2mail.com/comp/os/vms_messages.html   Web2news.com - COV  http://web2news.com/?comp.os.vms   Cheers!    Keith Cayemberg    ------------------------------  % Date: Fri, 05 Aug 2005 10:04:20 -0000  From: John <ozman@ozbus.net.au> 8 Subject: Data File Search Order in Some VMS Applications: Message-ID: <Xns96A9CC47ED57Aozmanozbusnetau@216.168.3.30>  
 'lo all...  J I've been away from VMS system management for a while (I last managed VMS C v5.x systems) now but I'm looking to implement something I vaguely   remember...   G If a program in VMS wants to use a data file, there would be a 'search  I order' that's generally used... but I can't remember the way it worked.     I *think* it was something like:  > if exists SYS$SYSTEM:SYSUAF.DAT         ! The default location!    sysuaf = SYS$SYSTEM:SYSUAF.DAT   ? else if exists SYS$DEFAULT:SYSUAF.DAT   ! The current directory "    sysuaf = SYS$DEFAULT:SYSUAF.DAT  C else if exists $trnlnm(SYSUAF)          ! The logical name location     sysuaf = $trnlnm(SYSUAF)    else     flag error: can't find SYSUAF   endif   I Would someone please point me to the correct sequence of checking and/or  I the relevant system guide or manual that explains the order.  I remember  E it somewhere in dealing with SYSUAF, queue manager files, LGICMD and   LOGIN.COM execution, etc  ' Thanks for any forthcoming suggestions.      John   ------------------------------   Date: 5 Aug 2005 03:41:48 -0700  From: dooleys@snowy.net.au< Subject: Re: Data File Search Order in Some VMS ApplicationsC Message-ID: <1123238508.211805.200730@g43g2000cwa.googlegroups.com>    John wrote:  > 'lo all... > K > I've been away from VMS system management for a while (I last managed VMS D > v5.x systems) now but I'm looking to implement something I vaguely
 > remember...  > H > If a program in VMS wants to use a data file, there would be a 'searchI > order' that's generally used... but I can't remember the way it worked. " > I *think* it was something like: > @ > if exists SYS$SYSTEM:SYSUAF.DAT         ! The default location# >    sysuaf = SYS$SYSTEM:SYSUAF.DAT  > A > else if exists SYS$DEFAULT:SYSUAF.DAT   ! The current directory $ >    sysuaf = SYS$DEFAULT:SYSUAF.DAT > E > else if exists $trnlnm(SYSUAF)          ! The logical name location  >    sysuaf = $trnlnm(SYSUAF)  >  > else" >    flag error: can't find SYSUAF >  > endif  > J > Would someone please point me to the correct sequence of checking and/orJ > the relevant system guide or manual that explains the order.  I rememberF > it somewhere in dealing with SYSUAF, queue manager files, LGICMD and > LOGIN.COM execution, etc > ) > Thanks for any forthcoming suggestions.  >  >  > John? well the index is http://h71000.www7.hp.com/doc/os72_index.html . if you're dealing with a cluster you will need7 http://h71000.www7.hp.com/doc/72final/4477/4477pro.html " (chapter on cluster-wide logicals) most system manager stuff is in 7 http://h71000.www7.hp.com/doc/72final/6017/6017pro.html ) (chapter on startup using sylogicals.com)  and the security guide is 7 http://h71000.www7.hp.com/doc/72final/6346/6346pro.html 7 (again has a chapter on cluster-wide files like sysuaf)  Have a good weekend! Phil   ------------------------------   Date: 5 Aug 2005 05:12:47 -0700  From: dooleys@snowy.net.au< Subject: Re: Data File Search Order in Some VMS ApplicationsC Message-ID: <1123243967.022005.230810@g44g2000cwa.googlegroups.com>    ps8 for "user" files, look for the bit about lnm$file_dev inN http://h71000.www7.hp.com/doc/72final/6489/6489pro_030.html#mod_log_name_trans   ------------------------------  % Date: Tue, 26 Jul 2005 21:54:28 +0800  From: prep@prep.synonet.com . Subject: Re: Help to find X25 Layered Packages- Message-ID: <871x5l3c6j.fsf@prep.synonet.com>   ! Hkz <nightshade@email.it> writes:   F > I am searching for the X25 network Layered Packages for OpenVMS (VAX > and Alpha versions) 7.2.  F > I need them because me and a group of friends are trying to recreateA > a small X25 network, but the OpenVMS 7.2 CD seems to be lacking D > these packages. Of course we have subscribed the Hobbyist Program,& > so we have the licenses to use them.  A You do know that VMS X.25 does not include a X.25 *network*, only  the DTE stuff...   --  < Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda. @                                              West Australia 6076* comp.os.vms,- The Older, Grumpier Slashdot. Raw, Cooked or Well-done, it's all half baked.F EPIC, The Architecture of the future, always has been, always will be.   ------------------------------  # Date: Fri, 05 Aug 2005 14:20:44 GMT " From:   VAXman-  @SendSpamHere.ORG Subject: Re: HP cuts announced0 Message-ID: <00A47D2F.CD33B803@SendSpamHere.ORG>  f In article <7fKIe.7418$ia4.5070@fe1.news.blueyonder.co.uk>, Alan Greig <greigaln@netscape.net> writes:* >http://www.theinquirer.net/?article=25182 > J >"Back to the story at hand though. Colorado Springs has until October 31 > >to live, but they know this already. They are training their J >replacements now. HP-UX and some OpenVMS are training their replacements J >at Sitel in Canada, and the rest of OpenVMS along with all of Storage is D >going to Bangalore. One word to Hurd, rhyming intended, ENTERPRISE J >CUSTOMERS WILL NOT STAND FOR THIS, THEY ARE PICKY ABOUT SERVICE. Look to I >your storage SLA payouts for a hint on what I mean here, when you spend  I >more money than you bring in on kickbacks to placate customers, it does  J >not make business sense. When that money does not cover their losses, it > >makes even less sense for them to not jump ship and sue you."  G Couple this with the bad news of late for those of us doing development G (no SDK, new source licensing fee structure, etc.), the self-fulfilling ( prophecy of the demise of VMS is nigh.     --  K VAXman- A Bored Certified VMS Kernel Mode Hacker   VAXman(at)TMESIS(dot)COM              5   "Well my son, life is like a beanstalk, isn't it?"     ------------------------------  # Date: Fri, 05 Aug 2005 14:37:35 GMT ( From: Alan Greig <greigaln@netscape.net> Subject: Re: HP cuts announced: Message-ID: <PQKIe.7642$ia4.191@fe1.news.blueyonder.co.uk>   VAXman- wrote:   > I > Couple this with the bad news of late for those of us doing development I > (no SDK, new source licensing fee structure, etc.), the self-fulfilling * > prophecy of the demise of VMS is nigh.    I And you may have noticed Rob is practising his Windows sales pitch. I'll  H   bet the day VMS is cancelled he jumps in to tell us just how mistaken G we were all along (just like we were about the inherent superiority of  B the Alpha over Itanium) and that we should immediately upgrade to 5 Windows on HP's wonderful (err...) Opteron Proliants.    --  
 Alan Greig   ------------------------------  # Date: Fri, 05 Aug 2005 15:40:17 GMT " From:   VAXman-  @SendSpamHere.ORG Subject: Re: HP cuts announced0 Message-ID: <00A47D3A.EA3B127D@SendSpamHere.ORG>  e In article <PQKIe.7642$ia4.191@fe1.news.blueyonder.co.uk>, Alan Greig <greigaln@netscape.net> writes:  >  >  >VAXman- wrote:  >  >>J >> Couple this with the bad news of late for those of us doing developmentJ >> (no SDK, new source licensing fee structure, etc.), the self-fulfilling+ >> prophecy of the demise of VMS is nigh.    > J >And you may have noticed Rob is practising his Windows sales pitch. I'll I >  bet the day VMS is cancelled he jumps in to tell us just how mistaken  H >we were all along (just like we were about the inherent superiority of C >the Alpha over Itanium) and that we should immediately upgrade to  6 >Windows on HP's wonderful (err...) Opteron Proliants.  G Oh Jersey shore boardwalk hot-dog vending cart here I come.  I'd rather F stuff my gonads in the food processor and select the puree button thanF ever put a single cent of mine into the coffers of the Redmond Academy@ of Teenage Software Neophytes Emitting Substandard Technologies.    E Little Danny Torrance seen riding around the Overlook Hotel growling: E Redmund! Redmund!  Will no one heed the foreshadowing of his shining?    --  K VAXman- A Bored Certified VMS Kernel Mode Hacker   VAXman(at)TMESIS(dot)COM              5   "Well my son, life is like a beanstalk, isn't it?"     ------------------------------  $ Date: Fri, 5 Aug 2005 19:13:54 +02003 From: "Dr. Dweeb" <NOSPAM_5msg0h202@sneakemail.com>  Subject: Re: HP cuts announced= Message-ID: <42f39e52$0$78287$157c6196@dreader1.cybercity.dk>   - <VAXman- @SendSpamHere.ORG> wrote in message  * news:00A47D3A.EA3B127D@SendSpamHere.ORG...H > In article <PQKIe.7642$ia4.191@fe1.news.blueyonder.co.uk>, Alan Greig ! > <greigaln@netscape.net> writes:  >> >> >>VAXman- wrote: >> >>> K >>> Couple this with the bad news of late for those of us doing development K >>> (no SDK, new source licensing fee structure, etc.), the self-fulfilling * >>> prophecy of the demise of VMS is nigh. >>J >>And you may have noticed Rob is practising his Windows sales pitch. I'llI >>  bet the day VMS is cancelled he jumps in to tell us just how mistaken H >>we were all along (just like we were about the inherent superiority ofC >>the Alpha over Itanium) and that we should immediately upgrade to 7 >>Windows on HP's wonderful (err...) Opteron Proliants.  > I > Oh Jersey shore boardwalk hot-dog vending cart here I come.  I'd rather H > stuff my gonads in the food processor and select the puree button thanH > ever put a single cent of mine into the coffers of the Redmond AcademyB > of Teenage Software Neophytes Emitting Substandard Technologies. >  >   5 Well, I was working happily as a chef until recently. K I have now been headhunted to oversee the removal of all things VMS from a  
 F500 company. = It will take time, and when it's done, I am retiring from IT.   F Sort of fitting to bury VMS and 25 years of career at the last client.   Dweeb.  G > Little Danny Torrance seen riding around the Overlook Hotel growling: G > Redmund! Redmund!  Will no one heed the foreshadowing of his shining?  >  > --  3 > VAXman- A Bored Certified VMS Kernel Mode Hacker   > VAXman(at)TMESIS(dot)COM > 6 >  "Well my son, life is like a beanstalk, isn't it?"    ------------------------------   Date: 4 Aug 2005 22:47:25 -0700  From: icerq4a@spray.se8 Subject: Re: Intel hammer another nail in Itanium coffinB Message-ID: <1123220845.350393.95810@g43g2000cwa.googlegroups.com>   Alan Greig skrev:   E > According to the Intel slides published on the The Inquirer website C > Intel are now targetting the Itanium only at market segment "RISC I > replacement (2/4/8+sockets)". The market segment "Enterprise and volume B > (4/8+ sockets)" is now targetted by the 64 bit Intel Xeon MP andE > successors. The roadmap shows that Intel have no remaining residual 8 > plans to force Itanic into the wider Enterprise space. > A > See the slides at http://www.theinquirer.net/?article=25073. In 9 > particular the Intel Enterprise Server Platform Roadmap  > -- > Alan Greig  B Hardly any news... Intel has been saying RISC replacement for many years.C Xeon MP has been Enterprise on Intels websites and Intel executives - have also said this in public for some years.    ------------------------------  % Date: Fri, 05 Aug 2005 03:00:29 -0400 ( From: Bill Todd <billtodd@metrocast.net>8 Subject: Re: Intel hammer another nail in Itanium coffin= Message-ID: <X5idnXpmMN8Tk27fRVn-uA@metrocastcablevision.com>    Rob Young wrote:g > In article <eMtIe.1601$ia4.256@fe1.news.blueyonder.co.uk>, Alan Greig <greigaln@netscape.net> writes:  > H >>Mica/Prism project at DEC), in favour of Itanic, that he really drove F >>hard the collaboration between Microsoft and ex DEC folks at AMD on E >>X86-64. If the Itanic killed Alpha he would sink Itanic - which he  , >>hated. Looks to me as if he did just that. >> >  >  > 	I don't think so. > 4 > http://www.itjungle.com/two/two040605-story02.html > K > The new Itanium machines are called PrimeQuest, and Fujitsu thinks it can M > generate $2 billion in sales over the next few years from these Windows and N > Linux boxes, mainly because some companies don't want big Unix iron and they  > have outgrown 32-bit X86 iron.  F Well, after having sunk all that development time and money into what D they were told would be The Next Great Thing they *would* say that, E wouldn't they?  Better to bluster and hope for the best than just to  5 throw in the towel when there's any hope at all left.    >  > 	Shipped in June.   F Funny, though:  despite its sporting that faster FSB support that you H tend to run on about (and now having comparable Madison II chips to use I it), there don't seem to be much in the way of benchmarks to crow about.  C   Perhaps they contracted a case of DEC-style stealth marketing or  H something - or perhaps the only 'crow' is of the eating variety because # there's really just not much there.   G Speaking of not much there, while you seem to have had time to blather  E on in other areas, you've been conspicuously silent about correcting  E your recent erroneous statements about Montecito's purported LINPACK  I superiority.  Rather like Intel itself has responded to being confronted  D about its mendacious press release about it, in fact:  try to avoid H embarrassment and hope that some people will remember only the original ! lie and never see its refutation.    - bill   ------------------------------  # Date: Fri, 05 Aug 2005 09:31:02 GMT ( From: Alan Greig <greigaln@netscape.net>8 Subject: Re: Intel hammer another nail in Itanium coffin; Message-ID: <qlGIe.6034$ia4.2179@fe1.news.blueyonder.co.uk>    Bill Gunshannon wrote:  * > In article <42F29DC3.6D9D94F8@mist.com>,' > 	GreyCloud <cumulus@mist.com> writes:  > = >>I don't know what would be standing in the way of M$ buying % >>the complete OpenVMS line from HP,   >  > F > How about the idea that they have no interest in it at all as it hasI > much less marketability than their current OS.  The only other possible H > reason for MS buying VMS would be to kill it. But then they would haveC > to see it as offering some kind of competition, which it doesn't.   G Other than to "sunset" the product the only major company that I think  G it might just make sense for to buy VMS at this point in time would be  @ Intel. If Intel bought VMS and announced an X86-64 port and the H intention to take it back into the mainstream then the cat would really G be among the pigeons. Unlikely but not totally impossible I would have  & thought given Intel's reliance on VMS.   > bill >    --  
 Alan Greig   ------------------------------  % Date: Fri, 05 Aug 2005 11:14:17 -0400 ' From: Dave Froble <davef@tsoft-inc.com> 8 Subject: Re: Intel hammer another nail in Itanium coffin0 Message-ID: <11f70ccqdedvp59@corp.supernews.com>   Alan Greig wrote:  >  >  > Bill Gunshannon wrote: > + >> In article <42F29DC3.6D9D94F8@mist.com>, + >>     GreyCloud <cumulus@mist.com> writes:  >>? >>> I don't know what would be standing in the way of M$ buying ' >>> the complete OpenVMS line from HP,   >> >> >>G >> How about the idea that they have no interest in it at all as it has J >> much less marketability than their current OS.  The only other possibleI >> reason for MS buying VMS would be to kill it. But then they would have D >> to see it as offering some kind of competition, which it doesn't. >  > I > Other than to "sunset" the product the only major company that I think  I > it might just make sense for to buy VMS at this point in time would be  B > Intel. If Intel bought VMS and announced an X86-64 port and the J > intention to take it back into the mainstream then the cat would really I > be among the pigeons. Unlikely but not totally impossible I would have  ( > thought given Intel's reliance on VMS.  A Not sure if I have any valid reason to feel this way, but I just  H wouldn't trust Intel.  Not sure what part they played in killing Alpha,  but they sure had motive.   H If they had VMS, possibly the largest effort they would make is to find I some way to insure that it didn't run on Opteron, if they did port it to   64 bit x86.      --  4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596> DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com 170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------  $ Date: Fri, 5 Aug 2005 19:15:27 +02003 From: "Dr. Dweeb" <NOSPAM_5msg0h202@sneakemail.com> 8 Subject: Re: Intel hammer another nail in Itanium coffin= Message-ID: <42f39eaf$0$78287$157c6196@dreader1.cybercity.dk>   5 "Dave Froble" <davef@tsoft-inc.com> wrote in message  * news:11f70ccqdedvp59@corp.supernews.com... > Alan Greig wrote:  >> >> >> Bill Gunshannon wrote:  >>, >>> In article <42F29DC3.6D9D94F8@mist.com>,, >>>     GreyCloud <cumulus@mist.com> writes: >>> @ >>>> I don't know what would be standing in the way of M$ buying' >>>> the complete OpenVMS line from HP,  >>>  >>>  >>> H >>> How about the idea that they have no interest in it at all as it hasK >>> much less marketability than their current OS.  The only other possible J >>> reason for MS buying VMS would be to kill it. But then they would haveE >>> to see it as offering some kind of competition, which it doesn't.  >> >>M >> Other than to "sunset" the product the only major company that I think it  G >> might just make sense for to buy VMS at this point in time would be  M >> Intel. If Intel bought VMS and announced an X86-64 port and the intention  J >> to take it back into the mainstream then the cat would really be among I >> the pigeons. Unlikely but not totally impossible I would have thought  ! >> given Intel's reliance on VMS.  > L > Not sure if I have any valid reason to feel this way, but I just wouldn't J > trust Intel.  Not sure what part they played in killing Alpha, but they  > sure had motive. >   F HP has entrusted Intel its future - at least from a computer producer 
 viewpoint.7 Someone there thinks that Intel is to be trusted - lol.   	 Dr. Dweeb   J > If they had VMS, possibly the largest effort they would make is to find K > some way to insure that it didn't run on Opteron, if they did port it to  
 > 64 bit x86.  >  >  > --  6 > David Froble                       Tel: 724-529-04506 > Dave Froble Enterprises, Inc.      Fax: 724-529-0596@ > DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com > 170 Grimplin Road  > Vanderbilt, PA  15486    ------------------------------   Date: 5 Aug 2005 00:45:29 -0700 ' From: "Bart Zorn" <Bart.Zorn@xs4all.nl> B Subject: Re: minicopy, VAX, ALPHA, SHADOW_MAX_COPY, SYSMAN, SYSGENB Message-ID: <1123227929.244217.11130@o13g2000cwo.googlegroups.com>  G SYSGEN has no dependency on logical names, so you should be able to use D it early during system startup. Remember that you can use MCR SYSGEN CONNECT ... in SYCONFIG.COM.  @ Generally cluster wide logical names are available at the momentC SYLOGICALS.COM runs. However, according to the documentation in the @ System Management Guide, you should check F$GETSYI("CWLOGICALS"); to see if they really are. Reason for this is that CSP (the 5 CLUSTER_SERVER process) has to do its initialization.    HTH   	 Bart Zorn    ------------------------------  * Date: Fri, 5 Aug 2005 07:25:31 +0000 (UTC)P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)> Subject: minicopy, VAX, ALPHA, SHADOW_MAX_COPY, SYSMAN, SYSGEN$ Message-ID: <dcv49b$ae6$1@online.de>  H To my delight, I find that DISMOUNT/POLICY=MINICOPY followed by a MOUNT H command allows a minicopy as opposed to a full copy even if none of the I members on the shadow set has a direct connection to an ALPHA.  However,  # BOTH of the following must be true:   4    o  the MOUNT command must be issued from an ALPHA  6    o  the actual (mini)copy must be done from an ALPHA  G Here's my problem.  As long as an ALPHA remains in the cluster, I want  G to enable MINICOPY on shadow-set members which become unavailable when  H the node to which they have a direct connection is gone and then become A available again when their host node returns to the cluster.  In  H particular, I want to do this for a disk which has members connected to I two VAXes and which is normally mounted during SYLOGICALS.COM (it has to  C be mounted that early, since it contains SYSUAF etc; the reason no  H member is on ALPHA is that, due to patches etc, I normally reboot ALPHA ? more often than VAX).  Before the MOUNT command is issued from  I SYLOGICALS, I wait a bit to make sure all disks are available (important  I during a cluster reboot) and write a message to the console.  So, I know  G when to perform the MOUNT command interactively from ALPHA to enable a  I minicopy.  The problem is, a VAX usually handles the copy, which results   in a full copy.   H I could set SHADOW_MAX_COPY to 0 on VAX and the problem would be solved.E However, I like to have it set to 1 by default so that if a merge is  H required each node will merge its own system-disk shadow set.  My first I idea was to use SYSMAN from the ALPHA to temporarily set SHADOW_MAX_COPY  F to 0 on VAX before issuing the command, and setting it back after the  minicopy commences.   G However, at this point in the startup, SYSMAN isn't yet running on the   node which just booted.   @ I don't think I can delay the mount until SYSMAN starts since itE contains SYSUAF etc.  I also don't want to somehow artificially start D SYSMAN sooner (even if that were possible).  Also, of course, SYSMANG will need SYSUAF, so obviously the disk with SYSUAF needs to be mounted F before I use SYSMAN.  (Presumably, I could have a local copy of SYSUAF< for use until the real one is available, but this means moreF maintenance.  However, my main problem is that SYSMAN is not running,   not that SYSUAF is unavailable.)   What are the recommendations?   E What about using SYSGEN?  Will it be running before SYLOGICALS.COM is E executed?  If so, then I could use SYSGEN to set SHADOW_MAX_COPY to 0 C sometime after the system-disk shadow set has had a chance to start G merging, but before I interactively issue a MOUNT command from an ALPHA C to enable a minicopy.  Presumably, the beginning of SYSLOGICALS.COM G would be the right point to set SHADOW_MAX_COPY to 0.  Since a MINICOPY D is relatively fast, I could do the two minicopies I need after a VAX= reboots before continuing with the startup.  (It appears that H cluster-wide logicals ARE available when SYLOGICALS.COM is executed, so F presumably I could put a WAIT loop before any MOUNT commands and test B the value of this logical, which I would assign before starting a 0 minicopy from ALPHA and deassign when finished.)   Any other ideas?   ------------------------------   End of INFO-VAX 2005.434 ************************                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            