1 INFO-VAX	Tue, 28 Mar 2006	Volume 2006 : Issue 173       Contents:3 Customer Times HP Integrity Servers Special Edition 7 Re: Customer Times HP Integrity Servers Special Edition 7 Re: Customer Times HP Integrity Servers Special Edition  Re: F$FAO (!%D) & Week Number / Re: Is VMS Security being dumbed-down for Java? / Re: Is VMS Security being dumbed-down for Java? " Re: LWP::Simple crashes on VMSperl Re: old uVAX needs a home . Re: Opinion: I was just trying to sell OpenVMS. Re: Opinion: I was just trying to sell OpenVMS. Re: Opinion: I was just trying to sell OpenVMS. Re: Opinion: I was just trying to sell OpenVMS. Re: Opinion: I was just trying to sell OpenVMS. Re: Opinion: I was just trying to sell OpenVMS. Re: Opinion: I was just trying to sell OpenVMS OT:  Foundries Re: qman$master.dat - Re: strange behaviour: toasted network cards? - Re: strange behaviour: toasted network cards? - Re: strange behaviour: toasted network cards? - Re: strange behaviour: toasted network cards? - Re: strange behaviour: toasted network cards? - Re: strange behaviour: toasted network cards? F Re: This is sad...Paul Flaherty (creator of AltaVista at Digital) dies$ Re: Where do DSA devices come from ?$ Re: Where do DSA devices come from ?  F ----------------------------------------------------------------------    Date: 27 Mar 2006 11:45:50 -0800) From: "Sue" <susan_skonetski@hotmail.com> < Subject: Customer Times HP Integrity Servers Special EditionC Message-ID: <1143488750.130290.221570@j33g2000cwa.googlegroups.com>    To: Skonetski, Susan@ Subject: RE: Customer Times HP Integrity Servers Special Edition    > http://www.hp.com/products1/evolution/customertimes/index.html      R http://www.hp.com/products1/evolution/customertimes/pdfs/200603_Customer_Times.pdf   ------------------------------  % Date: Mon, 27 Mar 2006 15:43:42 -0500 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> @ Subject: Re: Customer Times HP Integrity Servers Special Edition+ Message-ID: <44284E75.DE6A043@teksavvy.com>   
 Sue wrote:T > http://www.hp.com/products1/evolution/customertimes/pdfs/200603_Customer_Times.pdf    G VMS and NSK are mentioned. Kudos to whoever in the VMS group managed to 7 convince the producers of that document to mention VMS.    ------------------------------    Date: 27 Mar 2006 16:58:08 -0800) From: "Sue" <susan_skonetski@hotmail.com> @ Subject: Re: Customer Times HP Integrity Servers Special EditionC Message-ID: <1143507488.807484.292800@v46g2000cwv.googlegroups.com>   E We have an excellent person (Marc) working with the team who puts all  arre stuff in this newsletter.   Sue    ------------------------------    Date: 27 Mar 2006 16:27:31 -0800" From: "Jose Baars" <peut@peut.org>& Subject: Re: F$FAO (!%D) & Week NumberC Message-ID: <1143505651.017272.126910@z34g2000cwc.googlegroups.com>   F > > In article <1143477105.494924.51760@e56g2000cwe.googlegroups.com>," > > "R Boyd" <bob@hax.com> writes:G > > >When I use the ISO rule about the week containing the 1st Thursday  > > >being week 1,B > > >I get that 31-Dec-2009 and 1-Jan-2010 are in Week 53 of 2009. > > > 9 > > >For 31-Dec-2010 and 1-Jan-2011 I get week 52 of 2010  > > > @ > > >1-Jan-2012 is on a Sunday, depending on how you define yourJ > > >week(starting on Monday or Sunday), this is either in week 52 of 2011L > > >or week 1 of 2012.    The incredibly short command procedure calculates > > >it to be week 52 of 2011. > > $ > > And in my eyes, this is correct. > > B > > Seeing the first day of the week as Sunday is the Jewish view,8 > > while Monday as the first day is the Christian view.F > > For the year 2011 you have to use the Christian view, because with; > > the Jewish view the year must be well above 5000 or so.  > B > Well the European calendars I've seen start with Monday, and the7 > North American Calendars I've seen start with Sunday.  > < > Our work week starts Sunday.  We get paid Sunday-Saturday. > $ > This is not a religious arguement. >   G Unless you take ISO as a religion. ISO believes Monday is the first day  of the week.> There are  interesting heretics around  though, see this page:  . http://www.pjh2.de/datetime/weeknumber/wnd.php     Jose   ------------------------------  # Date: Mon, 27 Mar 2006 20:31:23 GMT , From: Hoff Hoffman <hoff-remove-this@hp.com>8 Subject: Re: Is VMS Security being dumbed-down for Java?1 Message-ID: <vYXVf.5381$Nz.1708@news.cpqcorp.net>    Richard Maher wrote:  D > Can I just pin you down on your definition of an RTL? Is a call toM > SYS$GETUAI or SYS$PERSONA_CREATE in sys$library:secureshp.exe a "RTL call"? J > So as not to try and trick you, when previously (couple of years ago?) IK > asked "Is it safe to call sys$getuai from a UWSS?" your answer was "AFAIK M > No.". I am now of the opinion that what we're walking away with here is "It L > is safe to call other UWSS shareable images (including SECURESHRP) but not' > other user-mode RTLs." Is that right?   H    What I am referring to here as an RTL is anything not built into the G kernel.  If it's loaded and activated separately or otherwise not part  D of the kernel, it's not necessarily safe to call it from inner-mode H code.  And AFAIK, it is not safe to call sys$getuai, since this call is H implemented as a UWSS and not as part of the kernel -- the LOADSS calls I needed to use outer-mode APIs as part of their operations, so the LOADSS  * APIs are not directly part of the kernel.)  * >> But if problems do arise and the reportJ >>   gets to OpenVMS Engineering, my input is going to be "not supported". > N > You can't get much plainer than that, and I appreciate your candour. But theK > image I'm stuck with is that of the poor developer's face who, after just J > spending a big chunk of his life reinventing a new heap-managment wheel,C > stumbles across ACMS or Rdb (or PCA$COLLECTOR) code that's called E > LIB$GET_VM_PAGE from year dot and has had oodles of VMS engineering  > involvement. He's gutted!!!   F    I've extricated my share of locally-written memory management code L from existing applications.  Maintaining it was more work than replacing it.  H    And in any event, inner-mode code cannot call RTL calls.   There are D cases where it might work for some folks, but there are cases where B mixing the access modes and the memory heap page protections will A encounter failures -- or worse, you'll introduce a security hole.   G    If I'm coding in user-mode, I call the RTLs and set up what I need,  I and pass it along to inner-mode code (where I then verify the memory via  D probes).  If I'm coding in inner-mode code, I use the kernel memory E management routines, and the kernel debugging routines (tr_print and  H friends, for instance).  Or I expect the outer-mode code to have set up < the necessary memory, and I then probe it for access rights.  G    If working in this area, access to the source listings are required.   @ > But if the VMS documentation set did not consistently refer toN > LIB$GET_VM_PAGE being called from inner mode then I suspect that support andH > engineering would not be hounded about it for all eternity. Will these) > references be removed from the doc set?   H    I can't say I've seen any documentation to inner-mode code referring I to the RTLs.  If it is, we'll either have to fix the existing RTLs to be  D mode-sensitive or we'll have to fix the documentation, or both.  In H either case, the resolution doesn't immediately matter here as calls to # the RTL from inner mode don't work.   B   NOSHRIMG,  privileged shareable image cannot have outbound calls > F > When did it become legal to drop the /PROTECT qualifier on the $LINKM > command? Are we agreed that a re-visit of the relevant documentation should 3 > have taken place at that time and, sadly, didn't?   ,    You can't call RTLs from inner-mode code.  ; >>   obviously the kernel-mode C library, are safe to call.  > M > Once again, can you please tell me the file-spec for this library? (And are M > the routines as well documented as the EXE$ routines) Are there kernel mode + > equivalents of malloc, and realloc et al?   I    You can't call user-mode code and user-mode RTLs from inner-mode code.   D    The kernel C library is part of the kernel, and is callable from  inner-mode code.  I    Key here is the use of LINK/NOSYSLIB/SYSEXE.  If you have C calls and  I use this command, per the driver documentation, you will get a subset of  I the standard C library calls resolved via the kernel C library.  (If you  G have both the user-mode C library and the inner-mode C library, you'll   get duplicate symbols.)     * >> Inner-mode calls to anything other thanE >> exec-based system services are not generally considered supported.  > M > Anyone got just *one* example of a non exec-based system service call being  > specifically supported?   G    You can't call user-mode code from inner-mode code.  If you need to  G get out to user-mode to do something, you need to use an AST or an ACP  9 or a connection to a remote server process or other such.   C    I can choose to use a pseudo device driver, too, as there are a  I variety of constructs and APIs available that can make operations within  H a driver easier (and easier to secure) than those within a UWSS; within C a privileged shareable image.  And there is more documentation for  
 drivers, too.   E    Anyone writing inner-mode code really needs access to the OpenVMS  ; source listings kit, too.  The part numbers are in the FAQ.    ------------------------------  % Date: Tue, 28 Mar 2006 06:54:23 +0800 3 From: "Richard Maher" <maher_rj@hotspamnotmail.com> 8 Subject: Re: Is VMS Security being dumbed-down for Java?1 Message-ID: <e09qe1$jp3$1@news-02.connect.com.au>    Thanks.   9 "Hoff Hoffman" <hoff-remove-this@hp.com> wrote in message + news:vYXVf.5381$Nz.1708@news.cpqcorp.net...  > Richard Maher wrote: > F > > Can I just pin you down on your definition of an RTL? Is a call toH > > SYS$GETUAI or SYS$PERSONA_CREATE in sys$library:secureshp.exe a "RTL call"?L > > So as not to try and trick you, when previously (couple of years ago?) IF > > asked "Is it safe to call sys$getuai from a UWSS?" your answer was "AFAIKK > > No.". I am now of the opinion that what we're walking away with here is  "It J > > is safe to call other UWSS shareable images (including SECURESHRP) but not ) > > other user-mode RTLs." Is that right?  > I >    What I am referring to here as an RTL is anything not built into the H > kernel.  If it's loaded and activated separately or otherwise not partE > of the kernel, it's not necessarily safe to call it from inner-mode I > code.  And AFAIK, it is not safe to call sys$getuai, since this call is I > implemented as a UWSS and not as part of the kernel -- the LOADSS calls J > needed to use outer-mode APIs as part of their operations, so the LOADSS, > APIs are not directly part of the kernel.) > , > >> But if problems do arise and the reportL > >>   gets to OpenVMS Engineering, my input is going to be "not supported". > > L > > You can't get much plainer than that, and I appreciate your candour. But the H > > image I'm stuck with is that of the poor developer's face who, after justL > > spending a big chunk of his life reinventing a new heap-managment wheel,E > > stumbles across ACMS or Rdb (or PCA$COLLECTOR) code that's called G > > LIB$GET_VM_PAGE from year dot and has had oodles of VMS engineering  > > involvement. He's gutted!!!  > G >    I've extricated my share of locally-written memory management code J > from existing applications.  Maintaining it was more work than replacing it.  > I >    And in any event, inner-mode code cannot call RTL calls.   There are E > cases where it might work for some folks, but there are cases where C > mixing the access modes and the memory heap page protections will C > encounter failures -- or worse, you'll introduce a security hole.  > H >    If I'm coding in user-mode, I call the RTLs and set up what I need,J > and pass it along to inner-mode code (where I then verify the memory viaE > probes).  If I'm coding in inner-mode code, I use the kernel memory F > management routines, and the kernel debugging routines (tr_print andI > friends, for instance).  Or I expect the outer-mode code to have set up > > the necessary memory, and I then probe it for access rights. > I >    If working in this area, access to the source listings are required.  > B > > But if the VMS documentation set did not consistently refer toL > > LIB$GET_VM_PAGE being called from inner mode then I suspect that support and J > > engineering would not be hounded about it for all eternity. Will these+ > > references be removed from the doc set?  > I >    I can't say I've seen any documentation to inner-mode code referring J > to the RTLs.  If it is, we'll either have to fix the existing RTLs to beE > mode-sensitive or we'll have to fix the documentation, or both.  In I > either case, the resolution doesn't immediately matter here as calls to % > the RTL from inner mode don't work.  > D >   NOSHRIMG,  privileged shareable image cannot have outbound calls > > H > > When did it become legal to drop the /PROTECT qualifier on the $LINKH > > command? Are we agreed that a re-visit of the relevant documentation should5 > > have taken place at that time and, sadly, didn't?  > . >    You can't call RTLs from inner-mode code. > = > >>   obviously the kernel-mode C library, are safe to call.  > > K > > Once again, can you please tell me the file-spec for this library? (And  are J > > the routines as well documented as the EXE$ routines) Are there kernel mode- > > equivalents of malloc, and realloc et al?  > K >    You can't call user-mode code and user-mode RTLs from inner-mode code.  > E >    The kernel C library is part of the kernel, and is callable from  > inner-mode code. > J >    Key here is the use of LINK/NOSYSLIB/SYSEXE.  If you have C calls andJ > use this command, per the driver documentation, you will get a subset ofJ > the standard C library calls resolved via the kernel C library.  (If youH > have both the user-mode C library and the inner-mode C library, you'll > get duplicate symbols.)  >  > , > >> Inner-mode calls to anything other thanG > >> exec-based system services are not generally considered supported.  > > I > > Anyone got just *one* example of a non exec-based system service call  being  > > specifically supported?  > H >    You can't call user-mode code from inner-mode code.  If you need toH > get out to user-mode to do something, you need to use an AST or an ACP; > or a connection to a remote server process or other such.  > D >    I can choose to use a pseudo device driver, too, as there are aJ > variety of constructs and APIs available that can make operations withinI > a driver easier (and easier to secure) than those within a UWSS; within D > a privileged shareable image.  And there is more documentation for > drivers, too.  > F >    Anyone writing inner-mode code really needs access to the OpenVMS= > source listings kit, too.  The part numbers are in the FAQ.  >  >  >    ------------------------------    Date: 27 Mar 2006 13:35:39 -0800+ From: "juna" <ggl.20.jjpon@spamgourmet.com> + Subject: Re: LWP::Simple crashes on VMSperl B Message-ID: <1143495339.427991.99390@i40g2000cwc.googlegroups.com>   Craig,  F I tried your one-liner with all privs turned on and it gave me a fatal error:) $ perl -e "print join qq/\n/, keys %ENV;" F Fatal VMS error (status=100052) at P_ROOT:[000000]VMS.C;2, line 644 at
 -e line 1.+ %RMS-F-SYN, file specification syntax error   E I also ran the same thing under Perl 5.6.0 and it worked with minimum  privs.	 What now?    Juna   ------------------------------    Date: 27 Mar 2006 19:22:17 -0800) From: "William" <william.bader@gmail.com> " Subject: Re: old uVAX needs a homeB Message-ID: <1143516137.401733.10860@i40g2000cwc.googlegroups.com>  E This area of Pennsylvania was founded by Moravians in the mid 1700's. F I live in Bethlehem http://www.bethlehempaonline.com/ , and nearby, weG have Bath and Emmaus.  The Amish settled about 30 miles west and picked F city names like Intercourse, Blue Ball, Virginville, and Bird in Hand.  F VMS licensing changes lead us to port our applications from VAX/VMS toB Intel 386-based SCO Unix in the mid 1980's.  DEC increased the VMSG license fee so much that the VMS license component of the per-seat cost F of our application became higher than the total per-seat price chargedD by our competition.  Intel is still our preferred platform, althoughD now we have switched our primary development from SCO Unix to RedHatB Linux, and we support most of our applications on Linux, SCO Unix,E Solaris/SPARC, Mac OS X, and Windows. http://www.newspapersystems.com   B A few people have inquired about the uVAXen, but we don't have any1 takers so far.  It's sad.  Here's the photo again E http://williambader.com/museum/vax/vax.html They don't want to end up E in a scrap metal heap.  Unfortunately, the manuals in the photos were G composted several years ago, and my precious CIT-101 followed them last  year.    William    ------------------------------   Date: 27 Mar 2006 22:23:52 GMT( From: bill@cs.uofs.edu (Bill Gunshannon)7 Subject: Re: Opinion: I was just trying to sell OpenVMS + Message-ID: <48r6voFlftinU1@individual.net>   0 In article <FbmdncBUidFPtbXZ4p2dnA@bresnan.com>,% 	GreyCloud <mist@cumulus.com> writes:  > K > All you have to do is look at your latest Apple PC.  Underneath the hood  E > is unix.  Some say it isn't so, but it is true after much thorough  H > digging.  So why not do the same with OpenVMS?  After all, the o/s is K > quite compact as it is and would only require putting eye candy GUI over  J > it.  Make software installing simple.  If Apple can do it to Unix, then  > why not on OpenVMS?   C Well, let's start at the beginning.  What did the underlying OS for K Mac OSX cost?  Andswer $0.00.  What does VMS cost?  Any reason to continue?    bill   --  J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>       ------------------------------  % Date: Mon, 27 Mar 2006 17:44:07 -0500 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 7 Subject: Re: Opinion: I was just trying to sell OpenVMS , Message-ID: <44286AA8.529092F9@teksavvy.com>   Bill Gunshannon wrote:E > Well, let's start at the beginning.  What did the underlying OS for M > Mac OSX cost?  Andswer $0.00.  What does VMS cost?  Any reason to continue?   C Clustering. Support for larger systems. Integration into enterprise A systems. Complete documentation. And very competant engineers who F continue to work to improve VMS (and with Apple joining in, they would have greater budgets).   ------------------------------  % Date: Mon, 27 Mar 2006 19:41:13 -0500 ' From: Dave Froble <davef@tsoft-inc.com> 7 Subject: Re: Opinion: I was just trying to sell OpenVMS 9 Message-ID: <nKCdna-J9dMGGLXZnZ2dnUVZ_smdnZ2d@libcom.com>    Bill Gunshannon wrote:2 > In article <FbmdncBUidFPtbXZ4p2dnA@bresnan.com>,' > 	GreyCloud <mist@cumulus.com> writes:  > K >>All you have to do is look at your latest Apple PC.  Underneath the hood  E >>is unix.  Some say it isn't so, but it is true after much thorough  H >>digging.  So why not do the same with OpenVMS?  After all, the o/s is K >>quite compact as it is and would only require putting eye candy GUI over  J >>it.  Make software installing simple.  If Apple can do it to Unix, then  >>why not on OpenVMS?  >  > E > Well, let's start at the beginning.  What did the underlying OS for M > Mac OSX cost?  Andswer $0.00.  What does VMS cost?  Any reason to continue?  >  > bill >    No, that is not valid.  E If it's HP producing the appliance, they own VMS and can embed it in  0 anything they choose.  For any cost they choose.   --  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: Mon, 27 Mar 2006 17:42:08 -0700 " From: GreyCloud <mist@cumulus.com>7 Subject: Re: Opinion: I was just trying to sell OpenVMS 0 Message-ID: <nOudnZULLM3HGrXZRVn-pA@bresnan.com>   JF Mezei wrote:    > Bill Gunshannon wrote: > E >>Well, let's start at the beginning.  What did the underlying OS for M >>Mac OSX cost?  Andswer $0.00.  What does VMS cost?  Any reason to continue?  >  > E > Clustering. Support for larger systems. Integration into enterprise C > systems. Complete documentation. And very competant engineers who H > continue to work to improve VMS (and with Apple joining in, they would > have greater budgets).  G What I really see is a big gapping hole in the hardware lineup from HP. H Also consider that Sun had a hand in helping Apple with Java, obviously D to their interests, but nonetheless it helped Apple better position A their product.  Right now I'm seeing a lot of Apple minis on the  0 desktops of our local newspaper vendor on a LAN.? They can't afford to have a nasty virus disrupt their services. ( OpenVMS would be a very nice competitor.   --   Where are we going?   And why am I in this handbasket?   ------------------------------  % Date: Mon, 27 Mar 2006 17:38:56 -0700 " From: GreyCloud <mist@cumulus.com>7 Subject: Re: Opinion: I was just trying to sell OpenVMS 0 Message-ID: <nOudnZoLLM0HG7XZRVn-pA@bresnan.com>   Bill Gunshannon wrote:2 > In article <FbmdncBUidFPtbXZ4p2dnA@bresnan.com>,' > 	GreyCloud <mist@cumulus.com> writes:  > K >>All you have to do is look at your latest Apple PC.  Underneath the hood  E >>is unix.  Some say it isn't so, but it is true after much thorough  H >>digging.  So why not do the same with OpenVMS?  After all, the o/s is K >>quite compact as it is and would only require putting eye candy GUI over  J >>it.  Make software installing simple.  If Apple can do it to Unix, then  >>why not on OpenVMS?  >  > E > Well, let's start at the beginning.  What did the underlying OS for M > Mac OSX cost?  Andswer $0.00.  What does VMS cost?  Any reason to continue?  >   E I don't think that it cost $0.00.  After all, they did have to adapt  : everything to a new processor.  Then wrap a GUI around it.  B I don't know what VMS real cost to develop was, but now we have a ' problem with VMS visibility these days.   9 I'd much prefer VMS over any UNIX or any of its variants.   G Right now I don't see any small inexpensive desktop VMS units for sale. B My idea of low cost is under $2k.  Bulk sales will recoup any R&D.B The fact that DEC did produce a small desktop VMS computer before C managment went south was a good indicator of where DEC was heading.        --   Where are we going?   And why am I in this handbasket?   ------------------------------   Date: 28 Mar 2006 01:49:37 GMT( From: bill@cs.uofs.edu (Bill Gunshannon)7 Subject: Re: Opinion: I was just trying to sell OpenVMS + Message-ID: <48rj1hFllrgdU1@individual.net>   9 In article <nKCdna-J9dMGGLXZnZ2dnUVZ_smdnZ2d@libcom.com>, * 	Dave Froble <davef@tsoft-inc.com> writes: > Bill Gunshannon wrote:3 >> In article <FbmdncBUidFPtbXZ4p2dnA@bresnan.com>, ( >> 	GreyCloud <mist@cumulus.com> writes: >>  L >>>All you have to do is look at your latest Apple PC.  Underneath the hood F >>>is unix.  Some say it isn't so, but it is true after much thorough I >>>digging.  So why not do the same with OpenVMS?  After all, the o/s is  L >>>quite compact as it is and would only require putting eye candy GUI over K >>>it.  Make software installing simple.  If Apple can do it to Unix, then   >>>why not on OpenVMS? >>   >>  F >> Well, let's start at the beginning.  What did the underlying OS forN >> Mac OSX cost?  Andswer $0.00.  What does VMS cost?  Any reason to continue? >>   >> bill  >>   >  > No, that is not valid. > G > If it's HP producing the appliance, they own VMS and can embed it in  2 > anything they choose.  For any cost they choose. >   H Well, of course that is true.  But then, using the same logic they couldH have always sold VMS cheap on small machines for small businesses.  But.F did they?  If I want a single license to use VMS on the smallest Alpha0 available today, what will HP charge me for it?   E Sorry, while it is a nice idea that there might be a small system VMS D we have already been thru this dozens of times.  It just isn't goingF to happen.  At this stage of the game we will be lucky if VMS survivesI in the niche it currently occupies.  It isn't moving into any new niches.    bill   --  J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>       ------------------------------  % Date: Mon, 27 Mar 2006 22:54:42 -0500 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 7 Subject: Re: Opinion: I was just trying to sell OpenVMS , Message-ID: <4428B35F.540B60C1@teksavvy.com>   Bill Gunshannon wrote:G > Sorry, while it is a nice idea that there might be a small system VMS F > we have already been thru this dozens of times.  It just isn't goingH > to happen.  At this stage of the game we will be lucky if VMS survivesK > in the niche it currently occupies.  It isn't moving into any new niches.     D I think that IA64's upcoming demise holds promise for VMS. If VMS isG ported to he 8086, HP will not have any disincentives to hide VMS since G every VMS sale will contribute to HP's true bottom line: its ranking in  the 8086 marketplace.   H And Linux has already set the precedent for wintel assembly companies to% deliver boxes that don't run windows.    ------------------------------  % Date: Mon, 27 Mar 2006 17:03:59 -0800 # From: "Tom Linden" <tom@kednos.com>  Subject: OT:  Foundries ) Message-ID: <op.s63mkxqrzgicya@hyrrokkin>   L Normally try not to post OT, but saw this article, which should cause some   concern.     Mark LaPedus	 	  EE Times (03/25/2006 1:36 PM EST) 	   	 P SAN JOSE, Calif. — China’s Semiconductor Manufacturing International Corp.  M (SMIC) topped Singapore’s Chartered Semiconductor Manufacturing Pte. Ltd.   D for third place in the worldwide silicon foundry rankings in 2005,  5 according to the rankings from Gartner Dataquest Inc.   G Dongbu, Hua Hong NEC, Jazz and MagnaChip also moved up in the foundry   L rankings in 2005, according to Gartner Dataquest. Overall, however, it was  J a bad year for the foundry industry, as worldwide sales hit 18.4 billion  K in 2005, down 2.5 percent over 2004, according to the market research firm.   I For the first time, the foundry market fell while overall semiconductor   * sales grew in 2005, according to the firm.  N Taiwan Semiconductor Manufacturing Co. Ltd. (TSMC) remained as the world’s  L largest foundry with 44.8 percent market share in 2005. TSMC’s sales hit  0 $8.22 billion in 2005, up 7.2 percent over 2004.  J Taiwan’s United Microelectronics Corp. (UMC) remained as the world’s  N second largest foundry with 15.4 percent market share in 2005. UMC’s sales  7 hit $2.82 billion in 2005, down 19.3 percent over 2004.   E SMIC jumped from fourth place in 2004 to the third spot in the 2005   M rankings with 6.4 percent market share. SMIC’s sales hit $1.17 billion in     2005, up 20.1 percent over 2004.  H Chartered fell from third place in 2004 to the fourth spot in the 2005  G rankings with 6.2 percent market share. Chartered’s sales hit $1.13   * billion in 2005, up 2.6 percent over 2004.  L IBM Corp. remained as the world’s fifth largest foundry with 4.5 percent  L market share in 2005. IBM’s foundry sales hit $832 million in 2005, down   2.1 percent over 2004.  K South Korea’s MagnaChip Semiconductor Ltd. jumped from seventh place in   L 2004 to the sixth spot in the 2005 rankings with 2.2 percent market share.  J MagnaChip’s foundry sales hit $396 million in 2005, up 10 percent over   2004.   M Taiwan’s Vanguard International Semiconductor Corp. fell from sixth place   J in 2004 to the seventh spot in the 2005 rankings with 1.9 percent market  N share. Vanguard’s foundry sales hit $354 million in 2005, down 9.8 percent  
 over 2004.  N South Korea’s Dongbu Semiconductor Ltd. jumped from ninth place in 2004 to  K the number eight spot in the 2005 rankings with 1.9 percent market share.   D Dongbu’s sales hit $347 million in 2005, up 4.2 percent over 2004.  N China’s Shanghai Hua Hong NEC jumped from tenth place in 2004 to the ninth  J spot in the 2005 rankings with 1.7 percent market share. The company’s  C foundry sales hit $305 million in 2005, down 5.7 percent over 2004.   J U.S.-based Jazz Semiconductor Inc. jumped from 12th place in 2004 to the  D tenth spot in the 2005 rankings with 1.1 percent market share. The  G company’s sales hit $210 million in 2005, down 4.5 percent over 2004.    ------------------------------  % Date: Mon, 27 Mar 2006 14:23:49 -0500 - From: JF Mezei <jfmezei.spamnot@teksavvy.com>  Subject: Re: qman$master.dat, Message-ID: <44283BC3.69BF3A77@teksavvy.com>   Chuck Aaron wrote: >  > For instance,  > F > What would be the command to delete the queue excpt$batch out of the > que$master.dat file?    P $ HELP QUEUE is your friend. It lists all the major commands that affect queues.   ------------------------------  + Date: Mon, 27 Mar 2006 20:43:37 +0000 (UTC) P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)6 Subject: Re: strange behaviour: toasted network cards?$ Message-ID: <e09ipp$v7j$1@online.de>  : In article <4428161f$0$29721$636a55ce@news.free.fr>, rejoc <rejoc@FREEfree.fr> writes:   K > I suppose that the ethernet interface on the VAXes are not "native" 10bT  H > interfaces. So they must be connected to the DECrepeater through 10bT E > transceivers and there is nothing to do regarding half/full duplex.   0 Right, converting the thickwire to twisted pair.  G > On the Alpha, it would be interesting to know the "duplexing" of the  I > interface but lancp doesn't seem to give the value (too old version of  
 > VMS ?).   D 7.3-2, all patches (up until the batch which started coming about 2  weeks ago).   A > This can be checked at the console prompt (>>>) or during boot. B > As you are connected to a DECrepeater, your interface should be 6 > configured no-auto-negotiate, 10Mb/s, *half duplex*.  E I'm moving the hardware here on Thursday, so I can more easily check   things like this.   C ALL nodes are having trouble, but a) the ALPHA has the most and b)  E perhaps the troubles on the VAXes are a result of the ALPHA troubles.    ------------------------------  % Date: Mon, 27 Mar 2006 23:19:51 +0200  From: rejoc <rejoc@FREEfree.fr> 6 Subject: Re: strange behaviour: toasted network cards?3 Message-ID: <442856f9$0$7689$636a55ce@news.free.fr>   2 Phillip Helbig---remove CLOTHES to reply a crit :< > In article <4428161f$0$29721$636a55ce@news.free.fr>, rejoc > <rejoc@FREEfree.fr> writes:  > L >> I suppose that the ethernet interface on the VAXes are not "native" 10bT I >> interfaces. So they must be connected to the DECrepeater through 10bT  F >> transceivers and there is nothing to do regarding half/full duplex. > 2 > Right, converting the thickwire to twisted pair. > H >> On the Alpha, it would be interesting to know the "duplexing" of the J >> interface but lancp doesn't seem to give the value (too old version of  >> VMS ?).   > F > 7.3-2, all patches (up until the batch which started coming about 2 
 > weeks ago). I Sorry, I don't have any more Alpha 7.x systems to check. But perhaps the  : hardware cannot transmit the information to the system ???  E If the system keeps on crashing and if the command exists, you could  
 perhaps try a = $ mc lancp set device esa0 /noautonego/nofull_duplex/speed=10 D (don't really know if the command will do anything because of "show $ conf" doesn't give the duplexing...) > B >> This can be checked at the console prompt (>>>) or during boot.C >> As you are connected to a DECrepeater, your interface should be  7 >> configured no-auto-negotiate, 10Mb/s, *half duplex*.  > G > I'm moving the hardware here on Thursday, so I can more easily check   > things like this.  > E > ALL nodes are having trouble, but a) the ALPHA has the most and b)  G > perhaps the troubles on the VAXes are a result of the ALPHA troubles.  > H When a node has problem to "talk" to the others within a cluster it can D mess up all the cluster. Usually there are many messages about lost ; connections to a node, then the node is coming back, etc...    ------------------------------    Date: 27 Mar 2006 14:02:20 -0800 From: bob@instantwhip.com 6 Subject: Re: strange behaviour: toasted network cards?C Message-ID: <1143496940.440656.181050@v46g2000cwv.googlegroups.com>   / same thing happened to us with a DE500 card ... + our TCPware NIC failover dual cards keep us , up but we had sluggishness that after slowly1 increasing error counts turned to really slow ... + a card change fixed the problem so probably  some kind of line surge?   ------------------------------  % Date: Mon, 27 Mar 2006 17:16:54 -0500 ) From: "Neil Rieck" <n.rieck@sympatico.ca> 6 Subject: Re: strange behaviour: toasted network cards?8 Message-ID: <9vZVf.798$u15.184777@news20.bellglobal.com>  M "Phillip Helbig---remove CLOTHES to reply" <helbig@astro.multiCLOTHESvax.de>  / wrote in message news:e09ipp$v7j$1@online.de... < > In article <4428161f$0$29721$636a55ce@news.free.fr>, rejoc > <rejoc@FREEfree.fr> writes:  >  > G >> On the Alpha, it would be interesting to know the "duplexing" of the I >> interface but lancp doesn't seem to give the value (too old version of 
 >> VMS ?). >  [...snip...] > B >> This can be checked at the console prompt (>>>) or during boot.B >> As you are connected to a DECrepeater, your interface should be7 >> configured no-auto-negotiate, 10Mb/s, *half duplex*.  >  [...snip...] > K Rule of thumb: if you are using ?-BASE-T and are connecting directly to an  F Ethernet switch, then you can go full duplex. At all other times (eg. L "Ethernet hub" or "shared  transmit + receive paths") then you must go half  duplex.   
 Neil Rieck Kitchener/Waterloo/Cambridge,  Ontario, Canada.8 http://www3.sympatico.ca/n.rieck/links/cool_openvms.html   ------------------------------  % Date: Mon, 27 Mar 2006 18:20:16 -0500 / From: "William Webb" <william.w.webb@gmail.com> 6 Subject: Re: strange behaviour: toasted network cards?I Message-ID: <8660a3a10603271520y7dec83fcu79fc3021a4537ab0@mail.gmail.com>   , On 3/25/06, rejoc <rejoc@freefree.fr> wrote:6 > Phillip Helbig---remove CLOTHES to reply a =E9crit :F > > About a week ago, there was an unexpected power outage.  After theJ > > cluster came back up, some strange behaviour was noticed.  Maybe thereK > > is no relation, but I suspect there is, due to the coincidence in time.  >  > > C > > Could the power outage have damaged network cards or something, J > > resulting in this problem?  (There have been power outages before, and+ > > they never seemed to have bad effects.)  > > H > could be bad negotiation (half/full duplex) between the NIC and switch, > on one (or more) systems in the cluster...F > It can cause nodes disappearing/coming back in a cluster under heavy > network load.  >  >  >   A We used to run into this periodically when the network people did 6 things like upgrade IOS on the switches our SANS used.  E They'd deny like hell that anything in the configuration had changed, D but the fact that all our VAX systems and our DECservers disappeared= was a dead giveaway that their ports had gone from 10/half to  autonegotiate.   WWWebb --C NOTE: This email address is only used for noncommerical VMS-related  correspondence. C All unsolicited commercial email will be deemed to be a request for 8 services pursuant to the terms and conditions located at# http://bellsouthpwp.net/w/e/webbww/    ------------------------------  # Date: Tue, 28 Mar 2006 03:03:58 GMT   From: John Santos <john@egh.com>6 Subject: Re: strange behaviour: toasted network cards?* Message-ID: <yI1Wf.5012$f21.2426@trnddc01>   rejoc wrote:4 > Phillip Helbig---remove CLOTHES to reply a crit : > < >> In article <442546b6$0$7934$636a55ce@news.free.fr>, rejoc >> <rejoc@FREEfree.fr> writes: >> >>> $ mc lancp show confB >>> will show you the speed and duplex currently setup on the NIC. >> >>  " >> SYSMAN> do $ mc lancp show conf  - Try "SYSMAN> do $ mc lancp show dev/all/char"   ? On 7.3-2, this definitely shows full/half duplex status as well > as speed.  (On V8.2, "mcr lancp show conf" shows duplex state,? but on my one 8.2 node, it is *WRONG*.  It shows 10Mb Full, but > the DE435 adapter on my AlphaStation 200 4/100 (worlds slowestF Alpha?) isn't capable of full duplex and "mcr lancp show dev/all/char" says it's in Half-Duplex.)    5 >> %SYSMAN-I-OUTPUT, command execution on node DANEEL  >> LAN Configuration: 8 >>    Device   Medium      Default LAN Address   Version8 >>    ------   ------      -------------------   -------> >>     EZA0    CSMA/CD      08-00-2B-92-26-9D    Not available5 >> %SYSMAN-I-OUTPUT, command execution on node ELIJAH  >> LAN Configuration: 8 >>    Device   Medium      Default LAN Address   Version8 >>    ------   ------      -------------------   -------> >>     EZA0    CSMA/CD      08-00-2B-BF-A4-AB    Not available  = Unless you are using a 3rd-party ethernet adapter (Nemonix?), ; all VAX Ethernets are 10Mb HD.  If the switch isn't set the = to 10Mb, it won't work at all.  I've never seen a 10Mb FD, is  this even possible?   6  >> %SYSMAN-I-OUTPUT, command execution on node GLADIA >> LAN Configuration: G >>   Device  Parent  Medium/User        Version   Speed  Size      LAN  
 >> Address@ >>   ------  ------  -----------        -------   -----  ----    >> -----------------@ >>   ESA0               CSMA/CD         00000000    10   1500    >> 08-00-2B-96-22-35 >>= >> Note that GLADIA is an ALPHA; DANEEL and ELIJAH are VAXes.  >>  > The Alpha is running at 10Mb, but was this the most it can do,' or the result of bogus autonegotiation?   6 mcr lancp show dev/all/char should help clear this up.    H >>> For the switch, if it is manageable you should be able to check the  >>> configuration. >> >>K >> The VMS systems are connected via a DECrepeater.  A long cable goes from G >> that to a switch/router upstairs.  I'll have a look at that later.   J >> The DECrepeater is I believe manageable, but I don't have access to it  >> now. E >> (My cluster is 500 km away, but this week I'll be moving it to my  = >> place of residence, which will make hardware work easier.)  >>K > I suppose that the ethernet interface on the VAXes are not "native" 10bT  H > interfaces. So they must be connected to the DECrepeater through 10bT E > transceivers and there is nothing to do regarding half/full duplex.  > G > On the Alpha, it would be interesting to know the "duplexing" of the  I > interface but lancp doesn't seem to give the value (too old version of  I > VMS ?). This can be checked at the console prompt (>>>) or during boot. B > As you are connected to a DECrepeater, your interface should be 6 > configured no-auto-negotiate, 10Mb/s, *half duplex*.    ; Another give-away of duplex mismatch is lots of frame-check : and alignment errors under load.  These usually get logged, to OPCOM, at least when running DECnet-Plus.   --   John Santos  Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------    Date: 27 Mar 2006 21:52:35 -0600+ From: young_r@encompasserve.org (Rob Young) O Subject: Re: This is sad...Paul Flaherty (creator of AltaVista at Digital) dies 3 Message-ID: <7ozxv$fSMTtH@eisner.encompasserve.org>   o In article <1143408972.457093.111070@e56g2000cwe.googlegroups.com>, "Sue" <susan_skonetski@hotmail.com> writes:  >  > Mar 24, 6:15 PM EST  > ( > Paul Flaherty, AltaVista creator, dies >  > By JORDAN ROBERTSON  > Associated Press Writer  >  > More Technology Video  > E > SAN FRANCISCO     (AP) -- Paul A. Flaherty, a computer engineer who  > helpedH > create the pioneering AltaVista online search engine, has died. He was > 42.  > H > Flaherty died March 16 of a heart attack at his home in Belmont, about> > 20 miles south of San Francisco, family members said Friday. >   " 	Especially sad when I heard this.  ? 	I spoke with Paul Flaherty back in the day.  He told me how he ? 	essentially came up with the concept of indexing the Internet.   > 	His wife was working for Oracle, and they were in Italy.  SheF 	working, he vacationing.  He was accessing Digital networks remotely D 	(I can't recall for what reason) and he had one of those "what if" H 	moments.  "What if we indexed the Internet?"  (Or thoughts along those ! 	lines, a conversation long ago).   ? 	In the summer of 1996 I talked my wife into detouring 60 miles C 	so we could stop on the outskirts of the small town of AltaVista,  I 	Iowa.  We took several pictures of me holding my son standing alongside  C 	"Welcome to Altavista" - sent him one.  Asking about it later, he  F 	made mention it was on the wall in his cube.  I still have a picture 7 	of Josh and I next to that AltaVista sign, in my cube.   F 	God rest Paul Flaherty.  My heartfelt prayers of comfort for friends   	and family in this trying time.   				Rob    ------------------------------  % Date: Mon, 27 Mar 2006 14:20:40 -0500 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> - Subject: Re: Where do DSA devices come from ? , Message-ID: <44283B06.9CB011D2@teksavvy.com>  & > > /SHADOW is a positional qualifier.    7 HELP MOUNT /SHADOW examples shows why this is the case.   H MOUNT/BIND=CHOCOLATE  DSA1:/Shadow=(DUA0,DUA1), DSA2:/shadow=(dua2,dua3)( CHOCOLATE1 CHOCOLATE2  DELICIOUS$LOGICAL  H In this case, it is very clear why you need /SHADOW to be positional. ItC clearly qualifies the virtual device name, and if you have multiple B vistual device names, you need to be able to qualify each of them.   ------------------------------  + Date: Mon, 27 Mar 2006 23:52:07 +0000 (UTC) 7 From: moroney@world.std.spaamtrap.com (Michael Moroney) - Subject: Re: Where do DSA devices come from ? ( Message-ID: <e09tr6$qpo$1@pcls4.std.com>  " John Santos <john@egh.com> writes:   >Michael Moroney wrote: 5 >> John Santos <john.santos@post.harvard.edu> writes:  >>  G >>>Required for 2 reasons, and due to multi version cluster support, it H >>>will probably never change.  1) the name of the disk has to fit in a G >>>resource name; allocation-style names are 2 characters shorter than  7 >>>node-style names (maximum 5 vs. 7 character prefix.)  >>   >>  J >> The allocation class is internally stored as a binary longword, so this >> isn't a reason. >>    F >I don't understand this comment.  Maybe you didn't understand me? :-)  D I see what you meant.  It's that the alloclass is stored as a binaryD longword, so alloclasses larger than the byte size that is supportedK actually work, resulting in longer names that work.  I've seen $32767$ddcu: G units as shadowset members before (totally unsupported, of course) and  I larger probably work as well.  They theoretically could fit a 6 character I nodename into a longword using RAD50 (they already use RAD50 or something H similar to encode the ddc of the ddcu: into a word) but that isn't done.    B >I think what you are saying here is it isn't the text form of theE >device name that is stored in the resource name (or is it some other I >datastructure?), but a long-word containing the allocation class, which, E >if zero, doesn't completely specify the device.  If this is correct, @ >then it all makes sense, and I apologize for misleading people.  = That is correct.  A second longword encodes the member ddcu:.   F >I think I was mislead by a vague memory that the shadow lock resourceI >name contained the disk name, and would be too long if a node-style name F >were used.  Double-checking against the IDS book (V5.2, which is the E >latest version I have, but which I think is still valid), the volume E >shadowing lock resource name is "SHAD$"+allocation class device name D >of the virtual unit.  This is a little confusing... Is the "virtualC >unit" the member drive or the shadow set?  Shadow names don't have D >an allocation class... the unit name is DSAxxx:, not $ALOC$DSAxxx:.> >But in any case, the maximum length for a resource name is 31C >characters, so either "SHAD$NODEXX$DDCuuuu" or "SHAD$$255$DDCuuuu"  >would be short enough to fit.  I Shadow locks are of the form $DSAnnnnxxxxx (where nnnn is the unit number J in ASCII, with leading zeroes).   There are also mount locks of some sort I on the members to prevent them from being mounted separately.  Shadowing  , doesn't otherwise use member-specific locks.  H All this info is somewhat old, before things like HBMM and minicopy came into being.    ------------------------------   End of INFO-VAX 2006.173 ************************                                                                                                                                                                                                                                                                                                        ?ӑ6||t>$j0W=QWx1zEQO1}L ŸysZLqQxG)a7G
|C˒~U!xE@یM56ކXF}URGb#JO7~:;ME>Z{H}+RC)K/h=>L;x_@ːe2hp#Kýd<OX_8ǿL\O8H 15|&Ȗ4}٨tz߷N1bblѻ{ZF~ԫ,GWG1d?9ЪO>6@*#y4
A!eÿ h=>f9U5+~_G}wzGwո{jv&kfwnM._ߩn}jDj'gEDۧPcI^?
r\W\\{Crܚ0:b5q9rFr3ij,]@b]ɂ]&zǙ;J}[􁀬⨳Gصj '*]b
NqBwQ&<n%?M72HfͰ9n}<?_s\q(i@Z*kd^4	F,>5wPa:;f%=߫uY|&^>F_([_\pQa3D}`]T"-tm*h/v_8Fd?BxPl=\O9R!c =cw{fUoYf|3=HCl8G٭#~<y?$GLO8gwn
ǽȊa?$])
c`G)9cWM6>=,bgxaw_
3pQdL֖俹V_sٱo	3|?{gli'xƂ&z+<pG=~[ojg1|>QcҼr:,OݒLp 1e!rwsg>1|>~5 4g?όʫt~jyuN`7W_O9ivws-(}$C9QdԶRnzrPI5W"Ix|f~;/I
5xA,|QΚyDqΗY١<x^g8?>$VJ69P4ف+霏IC'|*`42yS FY(s,Rs
{F~	ߊTsGZ}S
aűjv'EDOw6̷t^jk㳿3NЈ9
/}~ѩUl&A}XVc
1)y.ҷ|LXQ>KW4ƚ??3gSdKT3FF>^5DL=&8V|B@A{ըF~F+7=(F{ڐlG]o6<b~⣂?ܠևU5|ᖱ>-eO~9z/'!4wgSi->W_kX~C ZXV^vHՌ崞
B1gGR"y
Vg~_ڶ}EKw\a?^S->?zyקz1g=Ng,',zwsySdl}f}&}Hx 
3;TFԔ&#ĭI^ |@҈BG4<D9&k^v_UKwvkڍ%y,GPZg#然G\·dvZ<涳)ήp&n
1wx*+V5Г}#E{W7三|/\ Ta\\OL[`TYOy(T"09IRݗm/ҸPoE.:J7>ŷR
F|Z`gI)a ?Lns.I5
Ӿؼ+?a8޼'=O{d0wvҴu<>㍖?ƛXx7WXчZg{>>"?*{^_aE/3ߦ+j+Wy|H0ZV貚~@9o?24u?qٞyxeWp<
<dOn<,GϿ>߄"z_鼊cS_Ay!SH7~/ҹŏh9^TTXï;t$:y{a3}&B?,|2RTZ,)ʢ|/Uk 1jyno$V0#)	ȗ%`~"p貨"Qq`=2r/93bFq롾yJPC47
gs͡;]O~͉_glWx֤ڎ<i?q2QI"lWk|)+3ό.e?_4kK~%<gC+G0p7/[TXvV  /%F?/W됆SPpN)Im1n'2!StbjE<V)H!d\ܘY,Af?ȃ)l۱ăyyPb<#:Ax`Ly#ff&|TA i&+37e<H} ?$?xΐN-I+d  E噣pB*L7ȃ#{o<(6 \($AcHdqIPJܩ:˹C)i)gЏ(O9"ʤ{FTfHO:\-ڕw>R$Ӧ]:)c+gWj]yv;KK'TJYmČ=R ڐ)&}L&sZ.Ly{;$҉>t$)K6MG0>C7	a\#cɘyNHW*(cUc9[+&p
(C~e,-o寖5/ϼNCrZ6`hOɘ{wmķ "|/+Rϛo]} ןUs*$ջUF)}V2$SLv_uf2du*e