0 INFO-VAX	Mon, 16 Feb 2004	Volume 2004 : Issue 92      Contents:G An Open Letter to the French IT Press (was: VAXUS: Symposium cancelled) I Re: BACKUP/COPY change file's allocated size. WHY? How do I prevent this? I Re: BACKUP/COPY change file's allocated size. WHY? How do I prevent this? I Re: BACKUP/COPY change file's allocated size. WHY? How do I prevent this?  Re: CPU benchmarks5 Re: DCL procedure to find and delete unused accounts? 5 Re: DCL procedure to find and delete unused accounts? 5 RE: DCL procedure to find and delete unused accounts? 8 HP Launches Largest-ever Enterprise Advertising Campaign< Re: HP Launches Largest-ever Enterprise Advertising Campaign< Re: HP Launches Largest-ever Enterprise Advertising Campaign< Re: HP Launches Largest-ever Enterprise Advertising Campaign Re: Microvax vs Vaxstation 3100  Re: Microvax vs Vaxstation 3100  Re: Microvax vs Vaxstation 3100 > Re: Open Source developers are not to be thrusted says article> RE: Open Source developers are not to be thrusted says article PL/I for VAX/VMS Re: Renaissance of VAX-VMS ?( Re: Reversed links for joining Encompass; SBB POWER SUPPLY 150 OR 180 WATT - HOW MANY DISKS SUPPORTS? ? Re: SBB POWER SUPPLY 150 OR 180 WATT - HOW MANY DISKS SUPPORTS? , Re: Split CI farm MSCP=1 TMSCP=1 ALLOCLASS=1, Re: Split CI farm MSCP=1 TMSCP=1 ALLOCLASS=1 Re: VAXUS: Symposium cancelled Re: Why was VAX abandonned ?1 Re: [OT] Solaris crashes itself when /tmp is full   F ----------------------------------------------------------------------  % Date: Sun, 15 Feb 2004 09:53:50 +0100 " From: Didier Morandi <no@spam.com>P Subject: An Open Letter to the French IT Press (was: VAXUS: Symposium cancelled)' Message-ID: <402F339E.9000407@spam.com>    Alex Daniels wrote:   A > Here is an "English" translation that I got Google to produce..  (couic)    Here is my version.   I [start of free translation from French text available from www.vaxus.org]   ,                                 SHAME ON YOUF           An Open Letter from VAXUS to the French IT specialized Press.                               12 february 2004  ' Dear so-called specialized journalists,   O The first national Symposium of our Users association, recently founded, which  L was scheduled for June the 25th 2004 in the Paris Palais des Congres, Porte 6 Maillot, has been cancelled by a VAXUS Board decision.  M The Board of VAXUS, an association of Users of the VAX/VMS operating system,  L operating system created by Digital, today HP, decided to cancel the option Q taken from the Palais des Congres to rent a conference room and related services   for three reasons:  N First. HP France did not condescend to give us an answer to our request for a Q speaker to talk about the HP vision of the future of VAX/VMS. We believe that HP  Q France did not take us seriously because you, so-called specialized journalists,  Q   did not announce in your columns the creation of VAXUS nor the organization of  P our first symposium. To relay information is your job. You did not do your job. 
 Shame on you.   P The second reason. All solution providers we found for the VAX/VMS obsolescence P issue - which *is* an issue even if you don't care about it - did not give us a O definitive answer (that we understood as a deny) to talk about their vision of  N the problem and its solutions. We believe that they did not take us seriously K for the very same reasons previously quoted. So, you so-called specialized  C journalists, are responsible for that second failure. Shame on you.   K Then the third reason, which is probably the main reason for our symposium  N cancellation. As of today, despite heavy Internet communication, we collected M only two subscriptions to the symposium. A few merged information state that  O there are about 1800 DIGITAL Customers in France, a fourth of them still using  M VAX systems. These users are some of the French biggest companies: Michelin,  P SNECMA, France Telecom Mobiles, RATP, Shell Berre, Creusot Loire, EDF, Peugeot, G Airbus and many others. Do you really think, you so-called specialized  K journalists, that there are only two people interested in the future of an  P operating system which runs in their computer rooms since fifteen years without N any disfunction on computers which are obsolete since ten years and which run I off the shelf products, some of them abandoned on this platform by their  J respective editors since five years? [NDE: I'm thinking of Rockwell Allen L Bradley Interchange as an example]. For these reasons, these Customers have N questions that HP today answers with a relaxed "we will take you to Itanium". H You know that the migration of a process control application to another J architecture is a huge work. You also heard that, according to you, HP is Q considering to stop focusing on Itanium development, a processor which has been,  I as you said, a "marketing failure" (sic), to go AMD Athlon-64. I ask the  P question: Where is the future of these VAX/VMS Users, you so-called specialized P journalists? You just don't care about it, this is why you did not announce our < symposium to come on that very subject. Again, shame on you.  M Next year, or in two years time, when you hear about the increasing worry of  P these Users who see year 2010 coming close very fast, a date when HP officially R stops the VAX product line support, please do not show up saying "we told you so".   Didier Morandi VAXUS Chairman of the Board  (info at vaxus dot org)   O The Press communiques which announced on the 11-dec-2003 the creation of VAXUS  O and the one which announced on the 22-jan-2004 the symposium have been sent to  O the following French newspapers: 01 Informatique Hebdo, Le Monde Informatique,  & Les Echos, L'Usine Nouvelle et ZD-Net.   D. --  2 VAXUS - Your new helpful friend in the DEC Family!2 EHQ: 19 chemin de la Butte, 31400 Toulouse, France/       Phone: +336 7983 6418 Fax: +335 6154 1928 $                 http://www.vaxus.org   ------------------------------  % Date: Sun, 15 Feb 2004 09:13:57 +0000 - From: John Laird <nospam@laird-towers.org.uk> R Subject: Re: BACKUP/COPY change file's allocated size. WHY? How do I prevent this?8 Message-ID: <e5du20h3r1e67802pjlj56s316n4kusidu@4ax.com>  F On Sun, 15 Feb 2004 00:55:42 -0000, Z  <zarlenga@conan.ids.net> wrote:  / >John Laird <nospam@laird-towers.org.uk> wrote: K >: If you really must preserve the random contents of the disk that are not  >: part of your file > ? >The contents beyond EOF are not random and if they're not part ; >of the file, why does SET FILE/END give me access to them?   L Same way that the O/S will let you allocate an entire disk to a new file andJ let you read whatever was there already without you having to write 1 byteL (if you know the right programming tricks and have not enabled higher levels! of high-water security checking).   : >: (and sorry, but your application is broken if it thinksH >: copy and $ SET FILE/ATTR=(ORG:SEQ) both original and copy afterwards. > A >The application may indeed be broken.  But that doesn't help me. A >The application is no longer supported on VMS.  So there will be 9 >no fix for this.  And we cannot change database vendors.   I So you need to work with the (o/s) tools that are available.  Perhaps you I should be grateful that they will, with some caveats, let you do what you H need, rather than moaning that the VMS file designers didn't implement aL broken file design in the first place.  Look at this another way - most fileK systems have the concept of disk clusters, and there is always wasted space K at the end of a file (which must always be logically marked).  Do you think K it reasonable that network and tape copies should routinely waste bandwidth D and/or oxide preserving random data bytes ?  I doubt there is an FTPH implementation out there that wouldn't stop at the eof, on any platform.  @ >Is there or is there not a way for me to write ALL of the file,B >even the area between EOF and ALQ onto a tape and then back onto 8 >disk (using BACKUP) without first mucking with EOF with2 >SET FILE/END or the file attributes with CONVERT? >  >Yes or no?   K No, and rightly so.  But you can achieve what you want.  What is wrong with K correcting the eof position anyway (investigate set file/attr to see how to J set it to a fixed point rather than the end of the allocated blocks) ?  ItK is the best way you have of actually fixing this database problem, and if I K were you I would correct it even before getting into backup/restore issues, J because there is data in that file beyond eof and if you don't correct theL eof, you run the risk of losing that data during normal VMS file operations.   --  3 Today is the tomorrow you worried about yesterday.     Mail john rather than nospam...    ------------------------------    Date: 15 Feb 2004 06:38:56 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen) R Subject: Re: BACKUP/COPY change file's allocated size. WHY? How do I prevent this?3 Message-ID: <i1SyasKroPEI@eisner.encompasserve.org>   T In article <102tq6nl01a35f2@corp.supernews.com>, Z  <zarlenga@conan.ids.net> writes:0 > Larry Kilgallen <Kilgallen@spamcop.net> wrote: > : BACKUP/PHYSICAL. > 
 > No good. > < > BACKUP tells me I can only backup a device with /PHYSICAL.  H Of course.  I presumed that was obvious or that you were well acquaintedJ with it by reading the Backup documentation (not that everybody would haveC done that much reading, but in your situation I figured you would).   ) > $ backup/physical/log db1.db db.sav/sav I > %BACKUP-F-PHYFILSPE, /PHYSICAL specification must have only device name    The parameters should be:   + 	'F$PARSE("db1.db",,,"DEVICE")' DISK$SPARE:   C That answers the question you asked which prompted my answer above.    ------------------------------    Date: 15 Feb 2004 06:42:18 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen) R Subject: Re: BACKUP/COPY change file's allocated size. WHY? How do I prevent this?3 Message-ID: <JevCA7WhHw9T@eisner.encompasserve.org>   T In article <102u0q95noq3lbe@corp.supernews.com>, Z  <zarlenga@conan.ids.net> writes:4 > Richard B. Gilbert <rgilbert88@comcast.net> wrote:6 > : Would you, by any chance, be talking about Sybase? >  > No.  > C > The database in question does support DUMP/LOAD but it would take + > days to reload a 100GB database that way.   ? But you only need to do it once, while you switch to a database . engine that follows the VMS programming rules.  @ Note that it is rather difficult to write beyond the EOF pointer> without changing that pointer.  Somebody went to a lot of work to avoid playing by the rules.   ------------------------------  % Date: Sun, 15 Feb 2004 19:04:59 -0600 ( From: brandon@dalsemi.com (John Brandon) Subject: Re: CPU benchmarks 1 Message-ID: <04021519045929@dscis6-0.dalsemi.com>   ; > I am looking into getting some GS1280's for my production H > environments, currently running on racks of ES40's.    I am looking toH > find out what the relative horsepower is between the 6/667MHz cpu's inD > ES40's, and the 7/1.15GHz cpu's in GS1280.  (so I can estimate the > value of n in n-way). H >      I know there is a website out there that has this info, however I3 > can't remember the link (I would like that also.)  > F >      I am currently running OVMS V7.3-1 and my main applications are0 > Cerner's Millennium, and Oracle 8.1.something. > 
 > thanks \ >  > Dave.   M Also keep in mind that even though a CPU is faster it is not necessarily more N efficient.  I experienced that with a GS160 running 733-MHz against an AS 4100J running 667-MHz.  It depends on the workload requirements of the workload.  M Also keep in mind the performance of your sub-system.  For example using a CI J based in the lower-end Alpha's may suffice however get into the higher-endN Alpha's and the CI is not efficient for the large I/O bandwidth of the server.  O And speaking of disks - fragmentation, data distribution, I/O workload can also . have positive/negative impacts on performance.  P Then there is VCC and XFC caching - for block transfers this may have a positive impact on performance.    H The performance chart is a good rule-of-thumb for projecting performanceF impacts - in general.  However there are underlying currents involved.     J*o*h*n B*r*a*n*d*o*n  VMS Systems Administrator * firstname.lastname.spam.me.not@dalsemi.com   ------------------------------  # Date: Sun, 15 Feb 2004 11:41:36 GMT 4 From: Mike Rechtman <michael.rechtman.nospam@hp.com>> Subject: Re: DCL procedure to find and delete unused accounts?& Message-ID: <402F770F.59170267@hp.com>   Stephen Eickhoff wrote:  > F > Just so I don't have to reinvent the wheel, has anyone written a DCLM > procedure to find users that haven't logged in for a certain amount of time  > and disable or delete them?   G Look for a utility called UAF (try either the freeware or Hunter's site  -  sorry, memory cell failure.) quote from the README:  B         UAF is a general purpose utility for searching through the= authorization file based on any information stored within the A authorization file, including privileges (specific privileges, or ) privilege classes), last login time, etc.    Mike   --  E --------------------------------------------------------------------- E Usual disclaimer: All opinions are mine alone, perhaps not even that. ? Mike Rechtman                            *rechtman@tzora.co.il* F Kibbutz Tzor'a.                          Voice (home): 972-2-9908337  B   "20% of a job takes 80% of the time, the rest takes another 80%"E ---------------------------------------------------------------------  -----BEGIN GEEK CODE BLOCK-----  Version: 3.1: GCM/CS d(-)pu s:+>:- a++ C++ U-- L-- W++ N++ K? w--- V+++$6 PS+ PE-- t 5? X- tv-- b+ DI+ D-- G e++ h--- r+++ y+++@ ------END GEEK CODE BLOCK------    ------------------------------  # Date: Sun, 15 Feb 2004 11:35:08 GMT + From: Ken Robinson <sendspamhere@rbnsn.com> > Subject: Re: DCL procedure to find and delete unused accounts?@ Message-ID: <9e7e2e4d7991f2162900a24659a487c6@news.teranews.com>  3 "Stephen Eickhoff" <operagost@example.com> wrote in 1 news:PdEXb.13784$5W3.10413@nwrddc02.gnilink.net:     > E > I've found some helpful stuff there, but nothing like this. I don't C > even know how to access system services from DCL- some help there D > would be appreciated. It seems DECUS has a tool to do this. I justG > downloaded it, but as I don't have DECC installed, I imagine it won't 2 > do me any good. Only Alpha objects are included.  K Have you looked at the online doc set or done a "HELP" from the DCL prompt?   J Type "Help lexical". There isn't a way to access the UAF from DCL through G the lexical functions. I believe there is an old freeware program call  K SCANUAF that would help you.  I don't remember where I got the copy I used   in my last job.    Ken Robinson kenrbnsn (at) rbnsn (dot) com    ------------------------------  % Date: Sun, 15 Feb 2004 20:32:47 -0500 ' From: "Main, Kerry" <kerry.main@hp.com> > Subject: RE: DCL procedure to find and delete unused accounts?R Message-ID: <FD827B33AB0D9C4E92EACEEFEE2BA2FB278C25@tayexc19.americas.cpqcorp.net>  7 > From: Ken Robinson [mailto:sendspamhere@rbnsn.com]=20 ! > Sent: February 15, 2004 6:35 AM  > To: Info-VAX@Mvb.Saic.Com @ > Subject: Re: DCL procedure to find and delete unused accounts? >=205 > "Stephen Eickhoff" <operagost@example.com> wrote in 5 > news:PdEXb.13784$5W3.10413@nwrddc02.gnilink.net:=20  >=20 > >=20J > > I've found some helpful stuff there, but nothing like this. I don't=20H > > even know how to access system services from DCL- some help there=20I > > would be appreciated. It seems DECUS has a tool to do this. I just=20 ; > > downloaded it, but as I don't have DECC installed, I=20  > imagine it won't=20 4 > > do me any good. Only Alpha objects are included. >=20@ > Have you looked at the online doc set or done a "HELP" from=20 > the DCL prompt?  >=20B > Type "Help lexical". There isn't a way to access the UAF from=20A > DCL through the lexical functions. I believe there is an old=20 @ > freeware program call SCANUAF that would help you.  I don't=206 > remember where I got the copy I used in my last job. >=20 > Ken Robinson > kenrbnsn (at) rbnsn (dot) com  >=20  . SCANUAF can be found on Hunters freeware site:< http://vms.process.com/scripts/fileserv/fileserv.com?SCANUAF  2 The main pointer for Hunters site can be found at:- http://vms.process.com/fileserv-software.html    Regards   
 Kerry Main Senior Consultant  HP Services Canada Voice: 613-592-4660  Fax: 613-591-4477  Email: kerryDOTmainAThpDOTcom . (remove the DOT's and AT for email address)=20   ------------------------------  % Date: Sun, 15 Feb 2004 08:34:33 +0100 " From: Didier Morandi <no@spam.com>A Subject: HP Launches Largest-ever Enterprise Advertising Campaign 4 Message-ID: <402f2113$0$28138$626a14ce@news.free.fr>  @ (from http://www.hp.com/hpinfo/newsroom/press/2004/040209a.html)   [start of quote]8 HP Launches Largest-ever Enterprise Advertising Campaign  # HP tells companies to "love change"  PALO ALTO, Calif., Feb. 9, 2004   L HP today launched its most ambitious advertising campaign to date targeting 6 enterprise customers under the banner of "change +hp."  O The latest extension to the company's award-winning brand campaign tackles the  Q thorny subject of change by showcasing HP customers who use technology to master   change.   O The 16-page insert appearing in today's Wall Street Journal and New York Times  P includes HP customers Kimberly-Clark, Advance Transformer, United States Postal M Service and the Screen Actors Guild. Each company is showcased in a two-page  N spread that works like a mini-case study detailing how HP products, solutions * and services helped them deal with change.  K "The adage 'the only constant is change' couldn't be more relevant than in  L today's business world," said Nora Denzel, senior vice president at HP, who L leads the company's Adaptive Enterprise initiative. "At HP, we know what it O means to use technology to manage large-scale change. We speak from experience  B on the subject of what it takes to become an adaptive enterprise."  Q "We asked hundreds of CIOs and IT executives what keeps them awake at night. The  O universal response was 'change,'" said Allison Johnson, senior vice president,  J Global Brand and Communications, HP. "With this campaign, we hope to help 0 companies see the benefits of embracing change."  L The television, online and outdoor components of the campaign are slated to N debut in the United States in March and 17 additional countries in April. The K launch of the campaign coincides with today's announcements of HP's latest  M offerings designed to deliver the benefits of standardized IT architectures,  ) solutions and processes to its customers.   N HP worked with San Francisco-based advertising agency Goodby, Silverstein and ! Partners to develop the campaign.   > More information on the "change +hp" campaign is available at ! www.hp.com/hpinfo/newsroom/hpads.  [end of quote]     Anything on VMS ?    D. --  2 VAXUS - Your new helpful friend in the DEC Family!2 EHQ: 19 chemin de la Butte, 31400 Toulouse, France/       Phone: +336 7983 6418 Fax: +335 6154 1928 $                 http://www.vaxus.org   ------------------------------  % Date: Sun, 15 Feb 2004 04:35:23 -0500 * From: JF Mezei <jfmezei.spamnot@istop.com>E Subject: Re: HP Launches Largest-ever Enterprise Advertising Campaign ) Message-ID: <402F3D56.544A0065@istop.com>    Didier Morandi wrote: ? > More information on the "change +hp" campaign is available at # > www.hp.com/hpinfo/newsroom/hpads.  > [end of quote] >  > Anything on VMS ?   N No. But in fairness. the campaign is devoid of any information on any product.H There is a self congratulatory ad about Carly's folly, which resulted inM reducing IT costs by 25% and reducing the time it takes to add a new supplier * to their database from 5 weeks to 2 hours.  G HP also claims to have released over 600 new products last year (2003).     J The US post office figures fairly prominently. No mention of VMS. However,N what this means is that HP is reasonably sure that the post office will remainM an HP customer for some time to come. It would be a lot of egg on face if the M USPS were to announce next week that due to HP's mishandling of VMS, that the  USPS was going to IBM or SUN.   B Beware: the PDF documents were not compressed for on-line display.   ------------------------------    Date: 15 Feb 2004 19:02:15 -0800. From: alexdaniels@themail.co.uk (Alex Daniels)E Subject: Re: HP Launches Largest-ever Enterprise Advertising Campaign = Message-ID: <9f7f13a8.0402151902.7ef0935a@posting.google.com>   [ JF Mezei <jfmezei.spamnot@istop.com> wrote in message news:<402F3D56.544A0065@istop.com>...  > Didier Morandi wrote: A > > More information on the "change +hp" campaign is available at % > > www.hp.com/hpinfo/newsroom/hpads.  > > [end of quote] > >  > > Anything on VMS ?  > P > No. But in fairness. the campaign is devoid of any information on any product.  @ Have a look at the flash site for the campaign it is referencingD www.hp.com/adapt , seems to me there is explict mentions, for EVA's,D non-stop, linux, proliant, openview and integrity(without mentioningF VMS). This is all mentioned within the ad campaigns flash, VMS is not.   L > The US post office figures fairly prominently. No mention of VMS. However,P > what this means is that HP is reasonably sure that the post office will remain' > an HP customer for some time to come.   C Thought this was meant an ad in part to get new customers, not just B retain USPS. USPS, Screen Actors Guild, Reuters and HP(as they useC themselves as a case study) are all mentioned (they are VMS sites), D but no VMS mention within the flash or print that I can see. Only onB one obsucure link outside of the flash to USPS page, which in then
 links to VMS.    ------------------------------  # Date: Mon, 16 Feb 2004 04:26:19 GMT # From: "John Smith" <a@nonymous.com> E Subject: Re: HP Launches Largest-ever Enterprise Advertising Campaign L Message-ID: <LDXXb.28552$iVf1.12018@twister01.bloor.is.net.cable.rogers.com>   Alex Daniels wrote: 7 > JF Mezei <jfmezei.spamnot@istop.com> wrote in message ' > news:<402F3D56.544A0065@istop.com>...  >> Didier Morandi wrote:A >>> More information on the "change +hp" campaign is available at % >>> www.hp.com/hpinfo/newsroom/hpads.  >>> [end of quote] >>>  >>> Anything on VMS ?  >>D >> No. But in fairness. the campaign is devoid of any information on >> any product.  > B > Have a look at the flash site for the campaign it is referencingF > www.hp.com/adapt , seems to me there is explict mentions, for EVA's,F > non-stop, linux, proliant, openview and integrity(without mentioningH > VMS). This is all mentioned within the ad campaigns flash, VMS is not. > D >> The US post office figures fairly prominently. No mention of VMS.G >> However, what this means is that HP is reasonably sure that the post ; >> office will remain an HP customer for some time to come.  > E > Thought this was meant an ad in part to get new customers, not just D > retain USPS. USPS, Screen Actors Guild, Reuters and HP(as they useE > themselves as a case study) are all mentioned (they are VMS sites), F > but no VMS mention within the flash or print that I can see. Only onD > one obsucure link outside of the flash to USPS page, which in then > links to VMS.     8 Your observations would be characterized as belonging inL alt.grassy.knoll.conspiracy, as some HP folks who frequent c.o.v. would say.  F On the other hand, as that keen observer of the human condition, CaseyG Stengle, would say about the absence of VMS yet again from HP's pitiful 9 advertising attempts, "It's like deja vu all over again".    ------------------------------    Date: 15 Feb 2004 12:23:48 -08007 From: jones.computer.srv@worldnet.att.net (Daryl Jones) ( Subject: Re: Microvax vs Vaxstation 3100= Message-ID: <8a646952.0402151223.7c370459@posting.google.com>    Dear Lord Isildur:  E Once upon a time there was a VMS laptop! I was told for only $30,000.  It could be yours.   Regards, Daryl Jones   { Lord Isildur <isildur@andrew.cmu.edu> wrote in message news:<Pine.LNX.4.58-035.0402141147150.1941@unix44.andrew.cmu.edu>... ? > he might be thinking of the BA42A/B, which housed most of the H > vaxstation and microvax 3100's. the BA42A was the lower one, the B wasD > identical but about 1.5" taller. The vs3100 [34][08] came in thoseD > enclosures, for example, and the 3* version came in the ba42a, theI > 4* version in the ba42b. the microvax 3100/40 also came in a ba42b, and / > i think the later 3100's were all in ba42b's.  >  > > Richard B. Gilbert wrote: F > > > It has been about six years since I saw either one.  I thought IM > > > recalled that the Model 90 case was an inch or so taller than the Model  > > > 60 case. > > I > > The case are identical. Even the Storage Expansion case is identical. G > > Obviously the bits inside are different (although I think all 3 use  > > the same PSU). > > D > > The VAXstation 4000 VLC is the odd one out - it has the very low > > "pizza box" style case.  > # > yes, the Very Little Computer :-) F > the motherboard on those is small enough that  i keep thinking about  > making a vax laptop out of it. > 	 > isildur    ------------------------------  % Date: Sun, 15 Feb 2004 16:29:06 -0500 + From: Lord Isildur <isildur@andrew.cmu.edu> ( Subject: Re: Microvax vs Vaxstation 3100H Message-ID: <Pine.LNX.4.58-035.0402151615440.9374@unix44.andrew.cmu.edu>  G the fabled alphabook, you mean? ive heard of them, even heard of people J owning them, but ive never seen one. it's a shame that more of them werentG made, or that the line was continued a bit longer.. the 21164 gave much K better performance per watt-hour than the '064 (which is what the alphabook K ran, afaik).. but i'd take an '064 laptop , too! otherwise, i think a VLC's G motherboard could be stuffed into a largeer, older laptop enclosure and F something done to make the keyboard and display be driven by somethingJ emulating a vt220.. perhaps if i ever get the other tenscore things higher' up on the list of projects to finish...    isildur     ' On Sun, 15 Feb 2004, Daryl Jones wrote:    > Dear Lord Isildur: > G > Once upon a time there was a VMS laptop! I was told for only $30,000.  > It could be yours. > 
 > Regards,
 > Daryl Jones  > } > Lord Isildur <isildur@andrew.cmu.edu> wrote in message news:<Pine.LNX.4.58-035.0402141147150.1941@unix44.andrew.cmu.edu>... A > > he might be thinking of the BA42A/B, which housed most of the J > > vaxstation and microvax 3100's. the BA42A was the lower one, the B wasF > > identical but about 1.5" taller. The vs3100 [34][08] came in thoseF > > enclosures, for example, and the 3* version came in the ba42a, theK > > 4* version in the ba42b. the microvax 3100/40 also came in a ba42b, and 1 > > i think the later 3100's were all in ba42b's.  > >  > > > Richard B. Gilbert wrote: H > > > > It has been about six years since I saw either one.  I thought IO > > > > recalled that the Model 90 case was an inch or so taller than the Model  > > > > 60 case. > > > K > > > The case are identical. Even the Storage Expansion case is identical. I > > > Obviously the bits inside are different (although I think all 3 use  > > > the same PSU). > > > F > > > The VAXstation 4000 VLC is the odd one out - it has the very low > > > "pizza box" style case.  > > % > > yes, the Very Little Computer :-) H > > the motherboard on those is small enough that  i keep thinking about" > > making a vax laptop out of it. > >  > > isildur  >    ------------------------------  % Date: Sun, 15 Feb 2004 16:51:29 -0500 2 From: "Stanley F. Quayle" <squayle@insight.rr.com>( Subject: Re: Microvax vs Vaxstation 3100. Message-ID: <402FA391.31588.377E1DA@localhost>  + On 15 Feb 2004 at 12:23, Daryl Jones wrote: G > Once upon a time there was a VMS laptop! I was told for only $30,000.  > It could be yours.  C You can get a VMS laptop much cheaper -- just get a garden-variety  " Windows laptop and add CHARON-VAX.  C [Another Shameless Plug (tm) from Quayle Consulting Inc., a CHARON-  VAX reseller.]  
 --Stan Quayle  Quayle Consulting Inc.  
 ----------C Stanley F. Quayle, P.E. N8SQ  +1 614-868-1363  Fax: +1 614 868-1671 1 8572 North Spring Ct. NW, Pickerington, OH  43147 = Preferred address:  stan@stanq.com       http://www.stanq.com    ------------------------------  % Date: Sun, 15 Feb 2004 01:09:38 -0500 * From: JF Mezei <jfmezei.spamnot@istop.com>G Subject: Re: Open Source developers are not to be thrusted says article ) Message-ID: <402F0CFF.E4245E6C@istop.com>   N From an auditing point of view, isn't open-source better since auditors at theB user site can in fact look at the source code whereas when you buyH pre-compiled software you have no way to verify that there are no hidden7 treasures that could be nefarous to your organisation ?    ------------------------------  % Date: Sun, 15 Feb 2004 20:23:45 -0500 ' From: "Main, Kerry" <kerry.main@hp.com> G Subject: RE: Open Source developers are not to be thrusted says article R Message-ID: <FD827B33AB0D9C4E92EACEEFEE2BA2FB278C24@tayexc19.americas.cpqcorp.net>   > -----Original Message-----6 > From: JF Mezei [mailto:jfmezei.spamnot@istop.com]=20! > Sent: February 15, 2004 1:10 AM  > To: Info-VAX@Mvb.Saic.Com ? > Subject: Re: Open Source developers are not to be thrusted=20  > says article >=20= > From an auditing point of view, isn't open-source better=20 < > since auditors at the user site can in fact look at the=20? > source code whereas when you buy pre-compiled software you=20 B > have no way to verify that there are no hidden treasures that=20* > could be nefarous to your organisation ? >=20   JF,   F Both approaches have pro's and con's .. It really boils down to who do you trust ..  2 However, here are a few questions to consider -=20  H 1. How many Customers and even open source promoters actually understand@ in depth security from an OS kernels and drivers perspective?=20  D 2. Of those open source promoters that do understand security to theB right level, how many have the time and patience to review all theF hundreds of OS and driver code changes associated with updates, fixes,H enhancements and at the same time carry out the duties of their day job?    F On the other hand, the bad guys have much more incentive as it is whatD they do and their status is based on how well they do in the hacking
 community.  D 3. When the bad guys discover a hole in the code they are reviewing,D they do not notify the vendor - they circulate it among a very small" select group of other bad guys.=20  H Anyway, this is one of those arguments that will go on for a long time -G therefore, I expect that both approaches will be around for a long time  as well.   Regards   
 Kerry Main Senior Consultant  HP Services Canada Voice: 613-592-4660  Fax: 613-591-4477  Email: kerryDOTmainAThpDOTcom . (remove the DOT's and AT for email address)=20   ------------------------------  # Date: Mon, 16 Feb 2004 04:18:00 GMT 0 From: glen herrmannsfeldt <gah@ugcs.caltech.edu> Subject: PL/I for VAX/VMS - Message-ID: <YvXXb.41660$jk2.98999@attbi_s53>   ; Is VAX PL/I available through the hobbyist license program?    Even an old version is fine.   -- glen    ------------------------------  % Date: Sun, 15 Feb 2004 08:43:25 +0100 " From: Didier Morandi <no@spam.com>% Subject: Re: Renaissance of VAX-VMS ? 4 Message-ID: <402f2327$0$28106$626a14ce@news.free.fr>   Dieter Montanez wrote:  ? > I didn't know that VAXes actually "control" nuclear reactors, ? > at least not here in the USA. Most Nuclear Plants here in the A > USA do also run VAXes, mostly using an application called SAIC- > > PMS but these are Information Systems only and do not really? > execute any control on the actual plant I&C. They do actually > > interface I/O systems (like RTP G2) but they do not send any > control information to them. > B > Just out of curiosity, is this different in France's EDF NPP's ?  Q You understand that I will never disclose sensitive information in any way. What  Q I may only say is that I know that EDF is still using VAXen in their NPP control   rooms.  @ > FRAMATOME the most likely builder of most french NPP does alsoD > not provide any solutions for migrating VAX (SAIC-PMS or whatever)B > to any new DEC based system. They provide new solutions based onB > SIEMENS TXS and TXP which perform IC based controls with SIEMENSD > S5 based PLC and Information Systems (OM690) based on SUN Hardware > and Solaris OS.e  L I did not talk yet to Framatome. There are 1800 Customers in my base and it M takes a fairly long amount of time to call them all, mainly when those phone   numbers are no more valid.   D. -- e2 VAXUS - Your new helpful friend in the DEC Family!2 EHQ: 19 chemin de la Butte, 31400 Toulouse, France/       Phone: +336 7983 6418 Fax: +335 6154 1928 $                 http://www.vaxus.org   ------------------------------  # Date: Mon, 16 Feb 2004 04:22:03 GMT 0 From: glen herrmannsfeldt <gah@ugcs.caltech.edu>1 Subject: Re: Reversed links for joining Encompasse. Message-ID: <LzXXb.41026$yE5.163214@attbi_s54>   Tux Wonder-Dog wrote:v   > glen herrmannsfeldt wrote:  * (snip regarding encompass membership form)  8 >>I put in 123456 and hoped someone would figure it out.  @ >>Maybe that is why mine hasn't gone through yet, though I don't >>think the 10 days are up yet.e  I > I put in a quick sideways sequence from the Qwerty keyboard plus simplesH > number sequence and it seemed to be accepted.  E.g., alphanumeric like
 > qwer456.  E > I took a snapshot of the page, though, _just_ _in_ _case_.  It pays F > sometimes to take such precautions - but it seemed to be acceptable.  B Mine came through about the time I posted that.  It seems that you can put anything in that box.m   -- glene   ------------------------------  % Date: Sun, 15 Feb 2004 21:32:01 -0600m( From: brandon@dalsemi.com (John Brandon)D Subject: SBB POWER SUPPLY 150 OR 180 WATT - HOW MANY DISKS SUPPORTS?1 Message-ID: <04021521320121@dscis6-0.dalsemi.com>   E How many 9-GB disk drives (blue SBB) can a 150W power supply support?c   TIA        J*o*h*n B*r*a*n*d*o*n@ VMS Systems Administratorw* firstname.lastname.spam.me.not@dalsemi.com   ------------------------------  % Date: Sun, 15 Feb 2004 23:10:29 -0500t3 From: "Richard B. Gilbert" <rgilbert88@comcast.net>wH Subject: Re: SBB POWER SUPPLY 150 OR 180 WATT - HOW MANY DISKS SUPPORTS?0 Message-ID: <QeidnV3YZ8w6363dRVn-tA@comcast.com>  G If you are using the disks in a Wide shelf, I think you can have six.  dD It may make a difference if you have 7200RPM disks or 10k RPM disks.  < The Ultra Shelf I/O module needs more current than the wide.  F I wouldn't mess around with a 150W power supply if I had any choice!  J The 180W supplies can frequently be found on  e-Bay at reasonable prices.    John Brandon wrote:o  F >How many 9-GB disk drives (blue SBB) can a 150W power supply support? >  >TIA >e >t >  >J*o*h*n B*r*a*n*d*o*n >VMS Systems Administrator+ >firstname.lastname.spam.me.not@dalsemi.come >  : >    ------------------------------    Date: 15 Feb 2004 12:16:15 -08007 From: jones.computer.srv@worldnet.att.net (Daryl Jones)r5 Subject: Re: Split CI farm MSCP=1 TMSCP=1 ALLOCLASS=1 < Message-ID: <8a646952.0402151216.f53c129@posting.google.com>   Dear John Brandon:  E The naming convention for shared and non-shared disks in a cluster is  found at the following URL:o  X         http://h71000.www7.hp.com/doc/72final/4477/4477pro_008.html#manage_cluster_disks    C This includes the changed to the Allocation class made in VMS 7.1. s   Regards, Daryl Jonese      a brandon@dalsemi.com (John Brandon) wrote in message news:<04021413104256@dscis6-0.dalsemi.com>...o' > I have a three node Alpha CI cluster.  > ' > Two of the nodes have one CI SC (#1): - > controllers with MSCP allocation class    1,- >                  TMSCP allocation class   1r  > SYSGEN with      ALLOCLASS = 1 >  > $ > The other node has one CI SC (#2):- > controllers with MSCP allocation class    1m- >                  TMSCP allocation class   1t  > SYSGEN with      ALLOCLASS = 1 >  > = > I believe this to be a "less than desirable" configuration.t > Q > 1) The ALLOCLASS = 1 allows locally served disks (as there is) to have possibleg( > conflicts (i.e., DKA500 as $1$DKA500:) > O > 2) The MSCP/TMSCP allocation class 1 on all the controllers in both CI arrays K > to also have possible conflicts.  I already have duplicated disks on bothh	 > arrays.- > L > The problem is mounting disks /SYSTEM or /CLUSTER - in either case it will7 > cause device conflicts and therefore can not be done.m >  > My thoughts are to:e' >  Set the ALLOCLASS = 0 on all serverss4 >  Leave CI SC (#1) MSCP/TMSCP allocation class at 12 >  Set CI SC (#2) MSCP/TMSCP allocation class to 2 > 0 > Anyone care to contribute their 2-cents worth? >  >  >  > J*o*h*n B*r*a*n*d*o*nl > VMS Systems Administratora, > firstname.lastname.spam.me.not@dalsemi.com   ------------------------------  % Date: Sun, 15 Feb 2004 21:25:44 -0500 . From: Glenn Everhart <Everhart-nospam@gce.com>5 Subject: Re: Split CI farm MSCP=1 TMSCP=1 ALLOCLASS=1 3 Message-ID: <40302a39$1$3068$61fed72c@news.rcn.com>i  > I will add that some SCSI disks can be shared on a shared SCSI> bus and some cannot. It depends mainly on how the disk handles< bad sectors and certain other error conditions, but the diskB also has to know and understand multiple initiators (>1 controllerA sending commands to the disk) and has to be able to handle tagged D queueing right (so cluster state transitions work right). Disks that; lack a lot of this are allowed as local devices, but not as > shared scsi bus devices, because they cannot be trusted not to2 corrupt data at least under some error conditions.  = Not understanding all this stuff is very common in tape or CDi: devices...or at least was when scsi CDs were still common.     Daryl Jones wrote:   > Dear John Brandon: > G > The naming convention for shared and non-shared disks in a cluster ist > found at the following URL:v > Z >         http://h71000.www7.hp.com/doc/72final/4477/4477pro_008.html#manage_cluster_disks >  > E > This includes the changed to the Allocation class made in VMS 7.1. l > 
 > Regards,
 > Daryl Jones: >  >  > c > brandon@dalsemi.com (John Brandon) wrote in message news:<04021413104256@dscis6-0.dalsemi.com>...  > ' >>I have a three node Alpha CI cluster.- >>' >>Two of the nodes have one CI SC (#1):0- >>controllers with MSCP allocation class    1.- >>                 TMSCP allocation class   1l  >>SYSGEN with      ALLOCLASS = 1 >> >>$ >>The other node has one CI SC (#2):- >>controllers with MSCP allocation class    1:- >>                 TMSCP allocation class   1   >>SYSGEN with      ALLOCLASS = 1 >> >>= >>I believe this to be a "less than desirable" configuration.h >>Q >>1) The ALLOCLASS = 1 allows locally served disks (as there is) to have possible ( >>conflicts (i.e., DKA500 as $1$DKA500:) >>O >>2) The MSCP/TMSCP allocation class 1 on all the controllers in both CI arrayslK >>to also have possible conflicts.  I already have duplicated disks on bothd	 >>arrays.o >>L >>The problem is mounting disks /SYSTEM or /CLUSTER - in either case it will7 >>cause device conflicts and therefore can not be done.  >> >>My thoughts are to:p' >> Set the ALLOCLASS = 0 on all servers 4 >> Leave CI SC (#1) MSCP/TMSCP allocation class at 12 >> Set CI SC (#2) MSCP/TMSCP allocation class to 2 >>0 >>Anyone care to contribute their 2-cents worth? >> >> >> >>J*o*h*n B*r*a*n*d*o*ni >>VMS Systems Administratord, >>firstname.lastname.spam.me.not@dalsemi.com   ------------------------------  % Date: Sun, 15 Feb 2004 08:44:22 +0100d" From: Didier Morandi <no@spam.com>' Subject: Re: VAXUS: Symposium cancelleda4 Message-ID: <402f2360$0$28106$626a14ce@news.free.fr>   Barry Treahy, Jr. wrote:   > Didier Morandi wrote:k > H >> The VAXUS Symposium, which was scheduled for June the 25th, 2004, in B >> Paris has been cancelled due to the lack of publicity from the  >> so-called specialized Press.o >>E >> Read our open letter to the French so-called specialized Press at   >> www.waxus.org (French only) >> > www.WAXUS.org? >I$                 http://www.vaxus.org Sorry.   D.   ------------------------------  # Date: Mon, 16 Feb 2004 04:17:10 GMT 0 From: glen herrmannsfeldt <gah@ugcs.caltech.edu>% Subject: Re: Why was VAX abandonned ?d- Message-ID: <9vXXb.43690$_44.41746@attbi_s52>f   Richard B. Gilbert wrote:S  H > I first met the issue of boundary alignment ca. 1970 with the IBM 360 H > Model 91.  It is just part of the way processors work.  The designers J > can make varying amounts of effort to "fix up" misaligned variables and I > can charge greater or lesser penalties for them.  I would imagine that  J > there are substantial costs involved both in engineering and in silicon , > to get maximum fixup with minimum penalty.  B The 91 was special.  For most S/360 there was an SPIE routine thatC would copy misaligned data to a properly aligned temporary, performn@ the desired operation, and copy the result back.  Of course that> was slow, but because of the imprecise interrupts on the 91 it( wasn't possible to find the instruction.  > Also, Fortran COMMON was responsible for most of the unaligned8 variables.  It required packing with no padding allowed.   -- glenc   ------------------------------  % Date: Mon, 16 Feb 2004 02:07:59 +0800c, From: Paul Repacholi <prep@prep.synonet.com>: Subject: Re: [OT] Solaris crashes itself when /tmp is full- Message-ID: <87bro0nrls.fsf@prep.synonet.com>:  ! Roy Omond <Roy@Omond.net> writes:.  B > b) I've never seen VMS crash because any disk (even system disk): > filled up (and that's in 22 years managing VMS systems).  < The audit server can be configured to call the fat owl if it- can't write the audit log due to a full disk.g  = The clasic one was OPCOM not being able to write it's log andi? growing bigger and bigger and.... Till something broke. Or wentiH into a error message spiral of death! Runnig out of paper on the console# LAxx was good for that one as well.E   -- h< Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda.0@                                              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.   ------------------------------   End of INFO-VAX 2004.092 ************************