1 INFO-VAX	Sun, 12 Jun 2005	Volume 2005 : Issue 326       Contents: BA35x, SWXCC-22  Re: BA35x, SWXCC-22  Encrypting backups Re: Encrypting backups Re: Encrypting backups Re: Encrypting backups3 Re: Intel neuters Montvale, Itanic screams in alarm 3 Re: Intel neuters Montvale, Itanic screams in alarm 3 Re: Intel neuters Montvale, Itanic screams in alarm 3 Re: Intel neuters Montvale, Itanic screams in alarm 3 Re: Intel neuters Montvale, Itanic screams in alarm 3 Re: Intel neuters Montvale, Itanic screams in alarm   F ----------------------------------------------------------------------  + Date: Sun, 12 Jun 2005 13:00:45 +0000 (UTC) P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) Subject: BA35x, SWXCC-22$ Message-ID: <d8hblt$vdv$1@online.de>  H I'm trying to figure out if a BA35x (i.e. BA350 or BA356) is a BA350 or G a BA356, i.e. will it support wide (BA356) drives or not (BA350).  One  F label says BA35x and the other says SWXCC-22.  Does anyone know  what > this is?  (I don't have it yet, so I can't test out anything.)   ------------------------------  % Date: Sun, 12 Jun 2005 13:39:14 -0400 - From: William Webb <william.w.webb@gmail.com>  Subject: Re: BA35x, SWXCC-227 Message-ID: <8660a3a105061210392bb9910a@mail.gmail.com>   4 On 6/12/05, Phillip Helbig---remove CLOTHES to reply( <helbig@astro.multiclothesvax.de> wrote:I > I'm trying to figure out if a BA35x (i.e. BA350 or BA356) is a BA350 or H > a BA356, i.e. will it support wide (BA356) drives or not (BA350).  OneG > label says BA35x and the other says SWXCC-22.  Does anyone know  what @ > this is?  (I don't have it yet, so I can't test out anything.) >=20 >=20  I I can't find anything about SWXCC-22, but the SWXSS-22 is a 16-bit shelf.    WWWebb   --=20 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: Sun, 12 Jun 2005 07:22:16 -0700 (PDT) 2 From: "James J. O'Shea" <seamas_ose@ameritech.net> Subject: Encrypting backups ? Message-ID: <20050612142216.2360.qmail@web81106.mail.yahoo.com>   5 We are backing up our VAX VMS v6.2 environment on DLT 3 tapes using TAPESYS.  Does TAPESYS provide a way to 5 encrypt backups?  If not, is there some other tool or ' utility that we could use to do that?        Thanks, 
 Jim O'Shea   ------------------------------  % Date: Sun, 12 Jun 2005 11:58:23 -0400 ' From: Glenn Everhart <Everhart@gce.com>  Subject: Re: Encrypting backups , Message-ID: <FN-dnaUmerdbxjHfRVn-gw@rcn.net>   James J. O'Shea wrote:  7 > We are backing up our VAX VMS v6.2 environment on DLT 5 > tapes using TAPESYS.  Does TAPESYS provide a way to 7 > encrypt backups?  If not, is there some other tool or ) > utility that we could use to do that?    >  > 	 > Thanks,  > Jim O'Shea >  > C There are at least two suppliers of boxes that sit in front of SCSI B tape drives and allow encryption of anything written. They seem toB be able to keep up with even pretty fast drives and are 2 terminalE devices that pretty much hide the real drive. The rest of your system ; sees the tape drive as normal, but the data gets encrypted.   C It is possible some of these beasts might do a better job with SCSI C than most drives themselves also. It is very common for tape drives 9 not to decode SCSI LUN (or was not that long ago anyhow).   B Failing that there are remote virtual tape drivers on the sigtapes@ that could be cobbled together with some crypto to encrypt data,B and that would work ok, but programming it is not totally trivial.E One item you will have to consider is whether to encrypt headers too, = and that bunch of code is not the fastest stuff in the world.   F If you are doing this for production and not for fun I suggest gettingD a Paranoia box or similar. Then it will continue to work even if you add different tapes later. Glenn Everhart   ------------------------------    Date: 12 Jun 2005 11:13:18 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen)  Subject: Re: Encrypting backups 3 Message-ID: <$OPAQ2hT0+o3@eisner.encompasserve.org>   t In article <20050612142216.2360.qmail@web81106.mail.yahoo.com>, "James J. O'Shea" <seamas_ose@ameritech.net> writes:  7 > We are backing up our VAX VMS v6.2 environment on DLT 5 > tapes using TAPESYS.  Does TAPESYS provide a way to 7 > encrypt backups?  If not, is there some other tool or ) > utility that we could use to do that?     G VMS Backup will use the VMS Encryption product from HP if it is present  on the system.  C TAPESYS uses VMS Backup, so Software Partners could easily add some * qualifiers if they don't already have one.  F Depending on your security goals, however, safeguarding the encryptionA key may be a tough proposition.  That is a feature of the typical 9 problem statement in this area, independent of the tools.    ------------------------------  % Date: Sun, 12 Jun 2005 12:48:13 -0500 ( From: Wayne Sewell <wayne@tachysoft.com> Subject: Re: Encrypting backups / Message-ID: <00A452D5.75D0585D.1@tachysoft.com>   . >From: Kilgallen@SpamCop.net (Larry Kilgallen) >X-Newsgroups: comp.os.vms  >Subject: Re: Encrypting backups! >Date: 12 Jun 2005 11:13:18 -0500     u >In article <20050612142216.2360.qmail@web81106.mail.yahoo.com>, "James J. O'Shea" <seamas_ose@ameritech.net> writes:  > 8 >> We are backing up our VAX VMS v6.2 environment on DLT6 >> tapes using TAPESYS.  Does TAPESYS provide a way to8 >> encrypt backups?  If not, is there some other tool or* >> utility that we could use to do that?   > H >VMS Backup will use the VMS Encryption product from HP if it is present >on the system.  > D >TAPESYS uses VMS Backup, so Software Partners could easily add some+ >qualifiers if they don't already have one.  >     H No modifications to tapesys are required.  All vms backup parameters andK qualifiers are passed straight through to the backup command line, with the F exception of those tapesys controls directly, such as /[no]rewind.  InL particular, the /encrypt qualifier is used to activate the product mentionedN above, and this qualifier is handed off to vms backup with all its parameters.  J All you have to do is add the appropriate /encrypt=(...) to the QUALIFIERSM parameter in your .sbk file.  After buying the encryption product from hp, of  course.  :-)  M We don't do our own encryption at the present time, but we would look into it  if there was demand.   Wayne O =============================================================================== N Wayne Sewell, Tachyon Software Consulting  (281)812-0738   wayne@tachysoft.com; http://www.tachysoft.com/www/tachyon.html and wayne.html    O =============================================================================== P Jake Blues:"You traded the Caddy for a microphone? ...... Okay, I can buy that."   ------------------------------  % Date: Sun, 12 Jun 2005 06:55:21 -0400 ( From: Bill Todd <billtodd@metrocast.net>< Subject: Re: Intel neuters Montvale, Itanic screams in alarm= Message-ID: <LsidnYa8CN4EiTHfRVn-3g@metrocastcablevision.com>    Rob Young wrote:i > In article <z2Eqe.20071$_n2.1398651@news20.bellglobal.com>, "Neil Rieck" <n.rieck@sympatico.ca> writes:  > J >>On a related note, when Compaq decided to kill Alpha, I don't think theyN >>gave any thought to how this action would affect Cray (who depended on AlphaJ >>as their primary CPU technology). Like wise, if Intel decides that IntelK >>shareholders would like to see Itanium die, they won't give any though to  >>how this will affect HP. >> >  > @ > 	Or SGI, or NEC, or Fujitsu or Hitachi or Bull or Unisys, etc.  D True enough.  Because if Intel decides to pull the plug, it will be D *because* it won't have much affect on its OEMs because they aren't H selling enough product to keep Intel happy (and therefore won't be very H happy themselves, or all that sad to see Itanic sink beneath the waves).  C HP and SGI possibly excepted, because they're the only ones stupid  @ enough to have put all their eggs in the Itanic basket and will ; therefore likely feel that anything is better than nothing.   F Tough tooties.  If they can't keep Intel happy, they'll get precisely  what such stupidity deserves.    ...   L > Still, Fujitsu remains comfortable with its decision to invest in Itanium, > Rodriguez said.   F And in the immortal words of Mandy Rice Davies, "Well, they would say  that, wouldn't they?"   D I mean, now that they've thrown most of their money into the pot up G front, folding their hand without seeing how it will be received would  H be kind of silly - as would announcing that they really didn't like the  look of it very much.   I When you're committed anyway, best to try to make the best of it even if  ) the probability of success is pretty low.    ...   ? > Though Itanium has failed to live up to initial expectations,   G A pronouncement certainly in the running for understatement of the new  H century.  The initial expectations were that it would offer 2x - 3x the E performance of its RISC competition, ship in 1997 - 1998, completely  I obliterate that competition ("If you think you have a future, you don't"  F - Albert Yu, Intel VP & GM), and replace x86 and get rid of the pesky  competition in that market.   H Yes, you could say that it has failed to live up to those by just a bit.  
   it has been  > gaining momentum of late.   H When you start at zero, momentum is easy to gain.  Thus the only time a F gain is impressive is if you're already moving at a really good clip, 5 which I fear even you cannot claim is true of Itanic.    ...   
   sales ofO > Itanium servers totaled $1.4 billion in 2004, according to research firm IDC.   F Most of which came from HP's semi-captive audience of PA-RISC orphans  with nowhere else to go.   ...   P > Regarding servers, Fujitsu hopes to sell 10,000 units in the next three years,6 > which would generate an income of 2 billion dollars.  C And I hope to win the lottery, which would generate an income of 7  > figures - but not enough to go out and actually buy a ticket. G Unfortunately for Fujitsu, it bought its Itanic tickets when Intel was  H touting them as a sure bet, and now it's stuck with 'hopes' rather than  anything more substantial.   ...      Itanium is a good thing come# > 	Montecito (RAS and performance).   D Now, now, Rob.  You assured us that McKinley was a good thing.  You I assured us that Madison was a good thing.  Exactly why should anyone pay  7 any more attention to your predictions about Montecito?   2 Ever heard the story of the boy who cried "Wolf!"?   > C > 	Think of the repercussions of Intel suddenly souring on Itanium. ? > 	You have a major OEM/partner in Fujitsu that is just getting G > 	set to roll-out a whole line of servers based on Itanium - mainframe B > 	class (RAS, etc.) and now suddenly Intel pulls the plug on them2 > 	and 6-12 other major OEMs depending on Itanium?  @ When Compaq pulled the plug on Alpha it didn't cut off supplies I immediately, or even development (though of course it did lie about *how  G much* additional development would occur).  Another rather significant  D product release took place, with product available for sale 5 years # after the end-of-life announcement.   E Intel is in a considerably better position, since in only 2 years it  E will be offering x86 product usable in precisely the same boxes that  + will have to be developed to house Itanics.   H So if it tells OEMs that they'd better start making plans to transition E to x86, they'll be able to continue on about the same course for the  F next two years that they would have even if Itanic were thriving, and H have a couple of years after that point to adjust to a different ISA in  the same boxes.   H Pretty much like HP moved its PA-RISC base to Itanic, in fact.  Kind of E looks like Intel may have not had its head as deep in the sand as it  B seemed, and developed CSI with precisely this possibility in mind.   - bill   ------------------------------  % Date: Sun, 12 Jun 2005 07:23:11 -0400 ) From: "Neil Rieck" <n.rieck@sympatico.ca> < Subject: Re: Intel neuters Montvale, Itanic screams in alarm6 Message-ID: <uWUqe.2662$yU.6539@news20.bellglobal.com>  8 "Rob Young" <young_r@encompasserve.org> wrote in message- news:LBIdqJWlTfjw@eisner.encompasserve.org... J > In article <z2Eqe.20071$_n2.1398651@news20.bellglobal.com>, "Neil Rieck"  > <n.rieck@sympatico.ca> writes: [...snip...] > n > http://news.softpedia.com/news/Fujitsu-hopes-to-get-2-billion-dollars-from-the-Primequest-servers-1067.shtml > I > Regarding servers, Fujitsu hopes to sell 10,000 units in the next three  > years,6 > which would generate an income of 2 billion dollars. > > > So you see Fujitsu expects to sell a mainframe based ItaniumC > server to the tune of $2 billion over the next 3 years.  No doubt A > these early units are seed units - Itanium is a good thing come " > Montecito (RAS and performance). > B > Think of the repercussions of Intel suddenly souring on Itanium.> > You have a major OEM/partner in Fujitsu that is just gettingF > set to roll-out a whole line of servers based on Itanium - mainframeA > class (RAS, etc.) and now suddenly Intel pulls the plug on them ? > and 6-12 other major OEMs depending on Itanium?  Yeah, right.  > ? > Do you realize how comical that is to even suggest it happens D > (murder of Itanium - hi JF!)?  It is a roarer!  I mean how absurd! >  > Rob  >   ? Yes, almost as absurd as killing off Alpha and yet it happened.   J Look, I do not want to see Intel kill off Itanium. That train has gone tooL far down the track. But if Intel has a few bad years, someone there is goingH to start worrying "more" about Intel shareholders and "less" about IntelL business partners.  When this happens, one of the justifications for killingH Itanium (besides saving a huge amount of money) will be the huge base ofK existing x86 software that won't run on Itanium. It doesn't matter that the K new chip was meant for server applications because 99% of the people on the H street (including the media) don't understand the difference anyway. TheL preservation of existing software will be seen as an advertising opportunityG by the marketing folks at Intel. Meanwhile, killing Itanium could place G OpenVMS engineering in the same position as Cray was when Compaq killed  Alpha: "a one trick pony".  J There were many compelling reasons for switching from VAX to Alpha and yetI many balked  at that idea (and still do; my employer probably has one VAX K for every Alpha). In 2005, I don't see any compelling reasons for switching K from x86 with 64 bit extensions to Itanium. This may change in future years L but somehow I doubt it. x86 technology will continue to improve in order forK Intel to compete with other desktop CPU companies like AMD. This also means J their x86 business will be competing with their Itanium business, with the6 Itanium unit always being smaller and less profitable.  K When Intel started Itanium, extended x86 did not yet exist and the need for G an Itanium solution was more apparent. But times changed and x86 became I extended x86 and the need for Itanium went away. Now more than ever,  x86 L technology is better thought of as Intel's "goose that lays the golden eggs"F and yet Intel continues to focus on Itanium. In the book "In Search ofK Stupidity: Over 20 Years of High-Tech Marketing Disasters" the author talks E about a number of companies that went under (or almost went under) by G marketing new products that compete with their own existing products. I A wonder if he will have an "Intel chapter" in a future reprinting.   
 Neil Rieck Kitchener/Waterloo/Cambridge,  Ontario, Canada.! http://www3.sympatico.ca/n.rieck/    ------------------------------    Date: 12 Jun 2005 08:33:53 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen) < Subject: Re: Intel neuters Montvale, Itanic screams in alarm3 Message-ID: <UJAFRCfHWYnN@eisner.encompasserve.org>   b In article <uWUqe.2662$yU.6539@news20.bellglobal.com>, "Neil Rieck" <n.rieck@sympatico.ca> writes:  L > There were many compelling reasons for switching from VAX to Alpha and yetK > many balked  at that idea (and still do; my employer probably has one VAX  > for every Alpha).   G I don't see that as balking.  The fact that a vendor switches to making > a different machine is no reason to discard existing machines.  ? 23 years ago I was consulting at a shop with several 780s.  The @ beancounters came around and said it was time to sell the oldestA one, since it had reached the end of its depreciation.  They were B paying no attention at all to whether the machine was doing useful9 work for the company.  Thankfully, they lost that battle.    ------------------------------  % Date: Sun, 12 Jun 2005 10:36:35 -0400 ' From: Dave Froble <davef@tsoft-inc.com> < Subject: Re: Intel neuters Montvale, Itanic screams in alarm0 Message-ID: <11aoi0l4a2ulv2e@corp.supernews.com>   Larry Kilgallen wrote:d > In article <uWUqe.2662$yU.6539@news20.bellglobal.com>, "Neil Rieck" <n.rieck@sympatico.ca> writes: >  > L >>There were many compelling reasons for switching from VAX to Alpha and yetK >>many balked  at that idea (and still do; my employer probably has one VAX  >>for every Alpha).  >  > I > I don't see that as balking.  The fact that a vendor switches to making @ > a different machine is no reason to discard existing machines. > A > 23 years ago I was consulting at a shop with several 780s.  The B > beancounters came around and said it was time to sell the oldestC > one, since it had reached the end of its depreciation.  They were D > paying no attention at all to whether the machine was doing useful; > work for the company.  Thankfully, they lost that battle.   F It would depend upon whether the beancounters were willing to come up H with the money to purchase a replacement.  That way the users could get G a faster replacement, and the beancounters would have another asset to  I depreciate.  In later years it was a very good thing to replace an aging  G VAX 6000 series machine with a faster and cheaper system.  The savings  H on maintenance alone, using the 3-year warranty, often paid for the new B system.  The increases in performance were basically a free bonus.   --  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: Sun, 12 Jun 2005 11:13:42 -0400 ) From: "Neil Rieck" <n.rieck@sympatico.ca> < Subject: Re: Intel neuters Montvale, Itanic screams in alarm7 Message-ID: <PiYqe.4726$yU.38597@news20.bellglobal.com>   : "Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message- news:UJAFRCfHWYnN@eisner.encompasserve.org... E > In article <uWUqe.2662$yU.6539@news20.bellglobal.com>, "Neil Rieck"   > <n.rieck@sympatico.ca> writes: > I >> There were many compelling reasons for switching from VAX to Alpha and  >> yetL >> many balked  at that idea (and still do; my employer probably has one VAX >> for every Alpha). > I > I don't see that as balking.  The fact that a vendor switches to making @ > a different machine is no reason to discard existing machines. > A > 23 years ago I was consulting at a shop with several 780s.  The B > beancounters came around and said it was time to sell the oldestC > one, since it had reached the end of its depreciation.  They were D > paying no attention at all to whether the machine was doing useful; > work for the company.  Thankfully, they lost that battle.  >   F At my employer's company it all depends on how the pitch was made and J whether the ultimate decision makers were technologically savvy. IMHO, as L long as you could get all the software to run on Alpha, there was no reason L to stay with VAX. Lower power requirements and lower air conditioning costs H alone justified the change over (provided these costs weren't hidden in K someone else's budget). In some cases we couldn't install any new computer  M systems in certain locations because the UPS was at full capacity. Switching  M from VAX to Alpha (or other vendor's older equipment to newer) freed up some  = UPS capacity which allowed the installation of newer systems.   I But back to my original point from the previous post, there were obvious  M reasons for industry to switch over from VAX to Alpha. Right now there are a  K lot of people using "x86" and/or "64-bit extended x86" technologies who do  L NOT have any obvious reasons to switch over to Itanium. I fear that Itanium J may never be anything more than a niche market which will make it an easy ) kill target if Intel falls on hard times.   
 Neil Rieck Kitchener/Waterloo/Cambridge,  Ontario, Canada.8 http://www3.sympatico.ca/n.rieck/links/cool_openvms.html   ------------------------------    Date: 12 Jun 2005 11:09:20 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen) < Subject: Re: Intel neuters Montvale, Itanic screams in alarm3 Message-ID: <DCkFiNJrnUhI@eisner.encompasserve.org>   Z In article <11aoi0l4a2ulv2e@corp.supernews.com>, Dave Froble <davef@tsoft-inc.com> writes: > Larry Kilgallen wrote:e >> In article <uWUqe.2662$yU.6539@news20.bellglobal.com>, "Neil Rieck" <n.rieck@sympatico.ca> writes:  >>   >>  M >>>There were many compelling reasons for switching from VAX to Alpha and yet L >>>many balked  at that idea (and still do; my employer probably has one VAX >>>for every Alpha). >>   >>  J >> I don't see that as balking.  The fact that a vendor switches to makingA >> a different machine is no reason to discard existing machines.  >>  B >> 23 years ago I was consulting at a shop with several 780s.  TheC >> beancounters came around and said it was time to sell the oldest D >> one, since it had reached the end of its depreciation.  They wereE >> paying no attention at all to whether the machine was doing useful < >> work for the company.  Thankfully, they lost that battle. > H > It would depend upon whether the beancounters were willing to come up J > with the money to purchase a replacement.  That way the users could get  > a faster replacement,   2 At the time of this incident, 780 was the fastest.   ------------------------------   End of INFO-VAX 2005.326 ************************