1 INFO-VAX	Sun, 14 May 2006	Volume 2006 : Issue 267       Contents: Re: Compressing backup file  Re: Compressing backup file  Re: Compressing backup file  FREE Work At Home Job Finder3 Itanium tukwila uses alpha team, EV7 4 core design!  Re: SGI files for chapter 11  Re: The EDU Program (once again)* Re: VMS indexed files - how did they work?* Re: VMS indexed files - how did they work?  F ----------------------------------------------------------------------  % Date: Sun, 14 May 2006 05:59:02 -0400 + From: Steve Matzura <number6@speakeasy.net> $ Subject: Re: Compressing backup file8 Message-ID: <flvd62hc658bk0maq25kdn85v1h3lmf4hn@4ax.com>  F I was just thinking about a product I used for compressing not backupsC but other data for writing to magneto-opticals and thought, data is D data, why should it not compress a BACKUP saveset, too?  The productF is Disk Miser from Symark. If it can write to magneto-opticals, it canA surely write to CD's and maybe even now to DVD's. What's the diff @ between a CD and a DVD but about 4gb? A disk is a disk is a disk2 mostly, isn't it? Or am I over-simplifying things?   ------------------------------    Date: 14 May 2006 06:55:30 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen) $ Subject: Re: Compressing backup file3 Message-ID: <dRO1OkWLlGMV@eisner.encompasserve.org>   f In article <flvd62hc658bk0maq25kdn85v1h3lmf4hn@4ax.com>, Steve Matzura <number6@speakeasy.net> writes:  H > I was just thinking about a product I used for compressing not backupsE > but other data for writing to magneto-opticals and thought, data is F > data, why should it not compress a BACKUP saveset, too?  The productH > is Disk Miser from Symark. If it can write to magneto-opticals, it canC > surely write to CD's and maybe even now to DVD's. What's the diff B > between a CD and a DVD but about 4gb? A disk is a disk is a disk4 > mostly, isn't it? Or am I over-simplifying things?  ? In response to recent incidents, the proposal for Revision 1 of > NIST Special Publication 800-53 includes a suggested rule that backups must be encrypted.  @ As has been discussed here, compression of encrypted data is not
 effective.   ------------------------------  % Date: Sun, 14 May 2006 05:42:55 -0700 # From: "Tom Linden" <tom@kednos.com> $ Subject: Re: Compressing backup file) Message-ID: <op.s9jj9te1zgicya@hyrrokkin>   5 On Sun, 14 May 2006 04:55:30 -0700, Larry Kilgallen    <Kilgallen@SpamCop.net> wrote:  J > In article <flvd62hc658bk0maq25kdn85v1h3lmf4hn@4ax.com>, Steve Matzura  ! > <number6@speakeasy.net> writes:  > I >> I was just thinking about a product I used for compressing not backups F >> but other data for writing to magneto-opticals and thought, data isG >> data, why should it not compress a BACKUP saveset, too?  The product I >> is Disk Miser from Symark. If it can write to magneto-opticals, it can D >> surely write to CD's and maybe even now to DVD's. What's the diffC >> between a CD and a DVD but about 4gb? A disk is a disk is a disk 5 >> mostly, isn't it? Or am I over-simplifying things?  > A > In response to recent incidents, the proposal for Revision 1 of @ > NIST Special Publication 800-53 includes a suggested rule that > backups must be encrypted. > B > As has been discussed here, compression of encrypted data is not > effective.I Sems to suggest that /COMPRESS qualifier might be useful or alternatively 
 /NOENCRYPT   ------------------------------    Date: 14 May 2006 07:20:00 -0700% From: "bivek1" <jha.bivek1@gmail.com> % Subject: FREE Work At Home Job Finder C Message-ID: <1147616400.880133.138740@i39g2000cwa.googlegroups.com>   E Find the perfect work at home job for you using our FREE Work at home  Job Finder! B Get matched with a Home Based Job or Business Plan that suits your needs and skills. G Simply visit our website and fill in the short form to receive your Job  Match Details for FREE Today!   P http://www.typeinternational.com/idevaffiliate/idevaffiliate.php?id=1319_65_3_99   ------------------------------    Date: 14 May 2006 10:11:56 -0700 From: bob@instantwhip.com < Subject: Itanium tukwila uses alpha team, EV7 4 core design!C Message-ID: <1147626716.668996.132380@u72g2000cwu.googlegroups.com>   D there is hope after all ... the superior team and design won out ...  D http://www.realworldtech.com/page.cfm?NewsID=361&date=05-05-2006#361   ------------------------------   Date: 14 May 2006 15:30:40 GMT( From: bill@cs.uofs.edu (Bill Gunshannon)% Subject: Re: SGI files for chapter 11 , Message-ID: <4cp0p0F16mtkmU1@individual.net>  G In article <J6KdnboUwPVVFfvZnZ2dnUVZ_sidnZ2d@metrocastcablevision.com>, + 	Bill Todd <billtodd@metrocast.net> writes:  > Tom Linden wrote: J >> On Sat, 13 May 2006 18:04:32 -0700, Bill Todd <billtodd@metrocast.net> 	 >> wrote:  >>  K >>> Nobody likes hardware migrations, but they're a necessary fact of life  I >>> if a vendor is to survive - at least when they're done well.  I'm in  I >>> no position to evaluate how well the transition to Alpha was managed  K >>> (my suspicion is that it could have been done better but was done well  D >>> enough that other problems were what killed DEC), but I am in a K >>> position to recognize that it was necessary and that VAX had to wither  J >>> as a result (even if DEC had been healthy as a horse, it likely could 3 >>> not have justified continuing VAX development).  >>  J >> They are not at all necessary, consider 370 architecture, for example,  >> is now 40 >> years old, and it is 64 bit!  > I > When you've developed a monopoly on the market segment, you don't have  F > the competitive pressures that DEC had with VAX and can afford such F > luxuries (in fact, may find them to be required, and performance be J > damned).  Perhaps that was a large part of DEC's problem:  it *thought* F > for a while that VAX *did* have a monopoly on its segment, but that K > turned out not be be the case - and by the time that had become obvious,  0 > it was too late to respond in a timely manner. > A > Vendors don't put their customers through the pain of hardware  H > migrations just for the hell of it:  they do it to remain competitive H > (and anyone who suggests that DEC - unlike S/360/370/390 - could have H > remained competitive without moving to RISC simply doesn't understand E > what DEC's market was).  Well, perhaps in a few cases (such as the  K > migration to Itanic) just because they're idiots, but that's a different   > issue.  J Wel, let me play devil's advocate here.  Asssuming that it was pretty muchJ a give that VAX, as it existed, could not be architecturally sped up.  WhyH did DEC not consider emulating the VAX (at a very low level, not like weJ do with SIMH today) so that they could keep VAX customers who did not wantG to (or were not able to easily) migrate and they would get a speed bump G every time the alpha did?  Heck, they wouldn't even have to tell people H what was under the hood, just sell them "The New VAX" and guarantee that VMS was supported on it.    I And before you call me an idiot, I am just shooting from the hip and have H no idea how possible this might have been that many years ago, but givenJ the caliber of the engineering staff I know, I don't think that would have+ been the stumbling block if there were one.    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: Sun, 14 May 2006 07:58:51 -0400  From: Pete <None@nospam..com> ) Subject: Re: The EDU Program (once again) 8 Message-ID: <cn6e62tlqkgsbh04fnkhbp7bsmsbi0l5oc@4ax.com>  , On Sat, 13 May 2006 14:25:40 -0400, JF Mezei% <jfmezei.spamnot@teksavvy.com> wrote:    >Bill Gunshannon wrote: P >> The EDU PAKs seem to be end of August, so I suspect this might not work well. > I >Not sure if this is common, but until recently, I didn't know about SHOW 0 >LICENSE. I only knew about the LICENSE utility. > ) >SHOW LICENSE/SINCE=date/TERMINATION_DATE   B FWIW The "show license" command works on the in memory copy of the? license database. The "license list" works on the on disk copy.  Pete     ------------------------------  % Date: Sun, 14 May 2006 05:54:41 -0400 + From: Steve Matzura <number6@speakeasy.net> 3 Subject: Re: VMS indexed files - how did they work? 8 Message-ID: <eevd621mrm0fct90glbsdha050oh8jkhco@4ax.com>  E I gotta say, what I wouldn't give for that li'l jewel of a feature to D be available on other operating systems. BTrieve and everything elseA is fine but requires too much work on the part of the programmer. C With indexed files, you open them, you map them, you read them, you = write them, you're done.  A nice black-box DLL for Windows or = something similar for Unix would/could be a real money-maker.    ------------------------------  % Date: Sun, 14 May 2006 05:47:46 -0700 # From: "Tom Linden" <tom@kednos.com> 3 Subject: Re: VMS indexed files - how did they work? ) Message-ID: <op.s9jkhwiyzgicya@hyrrokkin>   K On Sun, 14 May 2006 02:54:41 -0700, Steve Matzura <number6@speakeasy.net>    wrote:  G > I gotta say, what I wouldn't give for that li'l jewel of a feature to F > be available on other operating systems. BTrieve and everything elseC > is fine but requires too much work on the part of the programmer. E > With indexed files, you open them, you map them, you read them, you ? > write them, you're done.  A nice black-box DLL for Windows or ? > something similar for Unix would/could be a real money-maker.  > @ As you may know PL/I IO presumes an idexed file system.  We haveC partnered with another company to provide our ISAM package as a DLL  on Windows, stay tuned.    ------------------------------   End of INFO-VAX 2006.267 ************************