1 INFO-VAX	Sun, 04 Aug 2002	Volume 2002 : Issue 426       Contents:C Re: Arithmetic Data Corruption - Compaq TCP/IP Services 5.3 and NFS C Re: Arithmetic Data Corruption - Compaq TCP/IP Services 5.3 and NFS C Re: Arithmetic Data Corruption - Compaq TCP/IP Services 5.3 and NFS 0 Re: Bad shadowing and SCSI bus error interaction0 Re: Bad shadowing and SCSI bus error interaction0 Re: Bad shadowing and SCSI bus error interaction2 Re: Can ANYONE explain HP's rationale on this one? Re: Carl's birthday -- Yea!  Re: Carl's birthday -- Yea! & Re: device full: wrong error messages?& Re: device full: wrong error messages?& Re: device full: wrong error messages?& Re: device full: wrong error messages?& Re: device full: wrong error messages?& Re: device full: wrong error messages?& Re: device full: wrong error messages? F&A?? Was VAX Hardware ID = Free  New High Res 19" Monitor with Xp1000 667 purchase !!!!! ' Re: OpenVMS comes to Itanium - Roadshow ' Re: OpenVMS comes to Itanium - Roadshow ' RE: OpenVMS comes to Itanium - Roadshow   Re: Second KLEZ from ATTBI Today* Re: Second KLEZ from ATTBI Today - TROLL !* Re: Second KLEZ from ATTBI Today - TROLL ! Re: Today's KLEZ Alert Re: Today's KLEZ Alert Re: Today's KLEZ Alert Re: Today's KLEZ Alert Re: Today's KLEZ Alert2 trying to install CPQ java131 on a alpha 250 4/2666 Re: trying to install CPQ java131 on a alpha 250 4/2666 Re: trying to install CPQ java131 on a alpha 250 4/2666 Re: trying to install CPQ java131 on a alpha 250 4/266 Re: VAX Hardware ID   F ----------------------------------------------------------------------  % Date: Sat, 03 Aug 2002 09:26:14 -0400 2 From: rdeininger@mindspring.com (Robert Deininger)L Subject: Re: Arithmetic Data Corruption - Compaq TCP/IP Services 5.3 and NFSJ Message-ID: <rdeininger-0308020926140001@1cust66.tnt2.nashua.nh.da.uu.net>  H In article <YYN29.67334$uV1.4495122@zwoll1.home.nl>, munk@home.nl wrote:    N >>>If you have this version of TCP/IP installed, are using the NFS server and J >>>have any application that does floating point arithmetic :^) apply the < >>>just-released AXPVMS-TCPIP_MUP-V0503-181-4 *immediately*. >>>  >>   >>  M >>    This doesn't seem to be available on ftp.service.digital.com ( at least  >> I can't find it ).  >>   > N >No, it is not there. Only a update for TCPIP 5.1 (I'm looking in the VMS 7.3 N >patch list). Thta is a bit odd, since this MUP update ! Perhaps full testing M >hasn't completed yet, and at the moment you will only get this patch if you   >experience problems ?  H I think the road to the public patch site is long and twisty.  HopefullyI the patch will appear on Monday.  Apparently the "expedite" mechanism for  MUPs is broken.   J If you have a software contract, and you use NFS server or the TCPIP proxyJ mechanism, you should log a call and ask for (demand?) the patch.  Even ifF you don't think you have any applications that use floating point, VMS; itself uses floating point and might experience corruption.    ------------------------------    Date: 03 Aug 2002 23:04:38 +0800, From: Paul Repacholi <prep@prep.synonet.com>L Subject: Re: Arithmetic Data Corruption - Compaq TCP/IP Services 5.3 and NFS- Message-ID: <87r8hg6l15.fsf@prep.synonet.com>   1 Mark Daniel <Mark.Daniel@wasd.vsm.com.au> writes:   B > We recently had a *real significant* problem after an upgrade toF > Compaq TCP/IP 5.3.  Not to labour the story too heavily, but as thisH > causes data corruption, a *warning* is in order and I couldn't find an > existing one on c.o.v.   H > If you have this version of TCP/IP installed, are using the NFS serverH > and have any application that does floating point arithmetic :^) apply? > the just-released AXPVMS-TCPIP_MUP-V0503-181-4 *immediately*.    7 > The ECO description seems to rather understate it ...    > > > Applications which use floating point find their registers) > > modified when the NFS server is used.    E > There is an interesting story behind this.  Perhaps someone who has 5 > first-hand knowlege might be in a position to post.   D This would be a dance with FP, the CRTL and interupt mode perchance?   --  < Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda. @                                              West Australia 6076. Raw, Cooked or Well-done, it's all half baked.F EPIC, The Architecture of the future, always has been, always will be.   ------------------------------  # Date: Sun, 04 Aug 2002 17:11:39 GMT & From: John Reagan <john.reagan@hp.com>L Subject: Re: Arithmetic Data Corruption - Compaq TCP/IP Services 5.3 and NFS% Message-ID: <3D4D5E89.3000700@hp.com>    Paul Repacholi wrote:    > F > This would be a dance with FP, the CRTL and interupt mode perchance? >    The CRTL isn't involved...  I By default, the compiler will sometimes use floating divide instructions  C to perform integer division.  It is sometimes faster to convert to  I float, do the floating divide, and convert back to integer than to use a  G pure integer-only subroutine that loops around generating the result a   few bits at a time.   H To do this optimization, the compiler needs to use a few floating point G scratch registers (ie, ones that are not normally saved by the calling  
 standard).  E However, certain places in OpenVMS (interrupt routines come to mind)  G only save certain user-context for better performance.  In paritcular,  I floating registers (even scratch ones) aren't saved since the assumption  G is that they are not used in those places.  In other words, the system  H can take an interrupt, process it, and return without saving any of the 7 user's floating point registers since nobody used them.   H To reconcile all of this, the C compiler (and BLISS and Pascal) provide F an /INSTRUCTION_SET=NOFLOATING_POINT qualifier.  This qualifier tells ? the optimizer not to use the "use floating for integer divide"  F optimization since the generated code will run in a context where the F floating registers aren't available (ie, nobody is going to save them I before the code would be called).  Instead, it calls the OTS$DIV routine  F which is an integer-only  routine that loops around and generates the  result a few bits at a time.  I At seems that components of TCP were built without using this qualifier.  G   Recent versions of GEM use the "use floating for integer" more often  I than previous versions.  The TCP folks upgraded to the latest C compiler  I which used a newer version of GEM.  This uncovered the bug where the ISR  I would use F0/F1 for integer division.  Since nobody saved/restore F0/F1,  I the interrupted code would see F0 and F1 become magically corrupted.  If  I you are lucky, F0 and F1 weren't being used by the code.  If you weren't  # lucky, you are calling for the MUP.   I I believe the MUP is simply a recompile of the affected modules with the  3 needed /INSTRUCTION_SET=NOFLOATING_POINT qualifier.    --   John Reagan ' Compaq Pascal/{A|I}MACRO Project Leader  Hewlett-Packard Company    ------------------------------    Date: 03 Aug 2002 22:58:35 +0800, From: Paul Repacholi <prep@prep.synonet.com>9 Subject: Re: Bad shadowing and SCSI bus error interaction - Message-ID: <87vg6s6lb8.fsf@prep.synonet.com>   , "Bill Todd" <billtodd@metrocast.net> writes:  ; > "Paul Repacholi" <prep@prep.synonet.com> wrote in message ) > news:87r8hh9olj.fsf@prep.synonet.com... & > > John Santos <JOHN@egh.com> writes:  B > > > *WE* need to know, but the application sure as hell doesn't!  > > > > Shadowing is supposed to hide hardware failures from the > > > application.  C > > No, shadowing is designed to enable your app to continue in the  > > face of disk errors.  A > If you meant that in any sense that materially differs from the C > sense of John's statement, then I believe that the extent of such E > difference represents an error on your part.  At the very most, the D > fact that a shadow set may have lost some of its redundancy is theF > kind of thing that should be reported as additional 'success' statusA > in something like the RMS STV field, not as some kind of error.   E I think we need to agree to disagree. I consider it essential for the E error to be reported. The app can throw it away, have a hisssy fit or E start WWIII. But without the error report, there is no option in what C you can do. Being able to intercept it and deal with it outside the 7 app would be really nice though, I will grant you that.    --  < Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda. @                                              West Australia 6076. Raw, Cooked or Well-done, it's all half baked.F EPIC, The Architecture of the future, always has been, always will be.   ------------------------------  # Date: Sat, 03 Aug 2002 20:36:49 GMT * From: "Bill Todd" <billtodd@metrocast.net>9 Subject: Re: Bad shadowing and SCSI bus error interaction @ Message-ID: <B9X29.76097$nm.2901610@bin5.nnrp.aus1.giganews.com>  9 "Paul Repacholi" <prep@prep.synonet.com> wrote in message ' news:87vg6s6lb8.fsf@prep.synonet.com... . > "Bill Todd" <billtodd@metrocast.net> writes: > = > > "Paul Repacholi" <prep@prep.synonet.com> wrote in message + > > news:87r8hh9olj.fsf@prep.synonet.com... ( > > > John Santos <JOHN@egh.com> writes: > D > > > > *WE* need to know, but the application sure as hell doesn't! > @ > > > > Shadowing is supposed to hide hardware failures from the > > > > application. > E > > > No, shadowing is designed to enable your app to continue in the  > > > face of disk errors. > C > > If you meant that in any sense that materially differs from the E > > sense of John's statement, then I believe that the extent of such G > > difference represents an error on your part.  At the very most, the F > > fact that a shadow set may have lost some of its redundancy is theH > > kind of thing that should be reported as additional 'success' statusC > > in something like the RMS STV field, not as some kind of error.  > G > I think we need to agree to disagree. I consider it essential for the  > error to be reported.   J No one is arguing about that, just about whom it should be reported to or,L if actually reported to the application, the manner in which the applicationC should be told (error status rather than qualified success status).   0  The app can throw it away, have a hisssy fit orG > start WWIII. But without the error report, there is no option in what E > you can do. Being able to intercept it and deal with it outside the 9 > app would be really nice though, I will grant you that.   G That logic would require that the application be informed about *every* G recoverable error (even read re-tries at the disk) - and informed by an K error status rather than something like a qualified success return which is I easily ignorable if the application is not interested (an RMS write-error L return - and for that matter *any* RMS error return - is *not* something you( should ignore under most circumstances).   Your logic is flawed.    - bill   ------------------------------  $ Date: Sat, 3 Aug 2002 18:12:48 -0400  From: John Santos <JOHN@egh.com>9 Subject: Re: Bad shadowing and SCSI bus error interaction 5 Message-ID: <1020803180244.3497A-100000@Ives.egh.com>   $ On 3 Aug 2002, Paul Repacholi wrote:  . > "Bill Todd" <billtodd@metrocast.net> writes: > = > > "Paul Repacholi" <prep@prep.synonet.com> wrote in message + > > news:87r8hh9olj.fsf@prep.synonet.com... ( > > > John Santos <JOHN@egh.com> writes: > D > > > > *WE* need to know, but the application sure as hell doesn't! > @ > > > > Shadowing is supposed to hide hardware failures from the > > > > application. > E > > > No, shadowing is designed to enable your app to continue in the  > > > face of disk errors. > C > > If you meant that in any sense that materially differs from the E > > sense of John's statement, then I believe that the extent of such G > > difference represents an error on your part.  At the very most, the F > > fact that a shadow set may have lost some of its redundancy is theH > > kind of thing that should be reported as additional 'success' statusC > > in something like the RMS STV field, not as some kind of error.  > G > I think we need to agree to disagree. I consider it essential for the G > error to be reported. The app can throw it away, have a hisssy fit or G > start WWIII. But without the error report, there is no option in what E > you can do. Being able to intercept it and deal with it outside the 9 > app would be really nice though, I will grant you that.   B The app being in this case RMS, since it is RMS that knows whetherE it was writing a data bucket or an index bucket, primary or secondary C index, etc.  Or should the user mode app just call SYS$PUT again if  it gets a (FATAL) RMS$_WER?   @ Note that even RMS has no idea which physical device experienced? the error.  All non-trivial software is a matter of appropriate B abstraction.  Someone writing in DCL shouldn't have to worry aboutD CPU register allocation or memory management.  Shadowing is supposedD to abstract disk failure management from the application level, justA like, e.g. automatic bad block replacement.  If course, there are C always catastrophic failures, where your only recourse is to crash, B reload your backup tapes, and reprocess from the application logs,A upstream feeds, RMS journals, or whatever.  But this should never > happen in an avoidable case, and losing one member of a shadow= set is completely avoidable.  Dropping the erroring disk, and B forcing a shadow copy from the other disk seems to me extreme, but0 infinitely preferable to what actually happened.  < Or are you saying any write error, including a transient bus) error, should be treated as catastrophic?    >  > --  > > Paul Repacholi                               1 Crescent Rd.,9 > +61 (08) 9257-1001                           Kalamunda. B >                                              West Australia 60760 > Raw, Cooked or Well-done, it's all half baked.H > EPIC, The Architecture of the future, always has been, always will be. >  >    --   John Santos  Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------  # Date: Sat, 03 Aug 2002 19:04:39 GMT 1 From: "David J. Dachtera" <djesys.nospam@fsi.net> ; Subject: Re: Can ANYONE explain HP's rationale on this one? ' Message-ID: <3D4C2E00.EB99E865@fsi.net>    "Terry C. Shannon" wrote:  > > > "David J. Dachtera" <djesys.nospam@fsi.net> wrote in message# > news:3D4B2767.54E38413@fsi.net...  > > John Smith wrote:  > > > [snip] > > B > > I seriously doubt if *ANY*one can explain HPQ's (ir)rationale, > > especially not HPQ!  > M > Well, back when I was a kid they had those magic 8-balls that would deliver M > 8 random answers to questions you posed. Maybe these are still available...   2 Yes, they are - and they're more predictable, too!   --   David J. Dachtera  dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------  # Date: Sat, 03 Aug 2002 14:34:28 GMT  From: sasadmin <jec@nospam.net> $ Subject: Re: Carl's birthday -- Yea!2 Message-ID: <87sn1wxaqn.fsf@Alethion.systasis.net>  - young_r@encompasserve.org (Rob Young) writes:   < > 	Well... I cheated.  But I don't feel too guilty as it was1 > 	a one-shot reference by Carl on Feb 17, 1992.     Here's the specific reference:K http://groups.google.com/groups?selm=25FEB91153804%40misvax.mis.arizona.edu      --   Microsoft Free By 2003   ------------------------------   Date: 3 Aug 2002 13:12:27 -0600 + From: young_r@encompasserve.org (Rob Young) $ Subject: Re: Carl's birthday -- Yea!3 Message-ID: <2ccd84dkgVZ1@eisner.encompasserve.org>   T In article <87sn1wxaqn.fsf@Alethion.systasis.net>, sasadmin <jec@nospam.net> writes:/ > young_r@encompasserve.org (Rob Young) writes:  > = >> 	Well... I cheated.  But I don't feel too guilty as it was 2 >> 	a one-shot reference by Carl on Feb 17, 1992.  >   > Here's the specific reference:M > http://groups.google.com/groups?selm=25FEB91153804%40misvax.mis.arizona.edu  >   ; 	Ah, my fault.  I searched for kilogavron as you said.  Not B 	kilo-gavron.  I had long forgotten about the post you referenced.! 	Ah, those were the bad old days.0   				Rob0   ------------------------------  # Date: Sat, 03 Aug 2002 14:35:12 GMTC. From: "Tom Simpson" <simpsont@attbi.com.fubar>/ Subject: Re: device full: wrong error messages? > Message-ID: <ASR29.269011$uw.152768@rwcrnsc51.ops.asp.att.net>  L We had a similar experience last weekend during our weekly file conversions. No explanation so far from CSC.    The process went like this:t7 1. convert large RMS file ==> to empty drive, no errorsn@ 2. delete original file (delete/log),  delete status was success1 3. copy the converted file back to original drivel5 4. the copy failed because the output drive was full.m  B The converted file is smaller than the original file, so how could the drive be full?  I No users are on the system while this process occurs.  No Batch processes? runninga# other than the file conversion job.sI The command procedure does a stop/id on any interactive users to be sure.-  E So either the delete, really didn't or the drive was not really full.oB An analyze/disk/repair on the disk in question indicted no errors.   My $.02T   Regards, Tom!  F "Phillip Helbig" <HELBPHI@sysdev.deutsche-boerse.com> wrote in message5 news:01KKTSPIA8UM96Z9MP@sysdev.deutsche-boerse.com... ) > > I'll bet that your RUJ device filled.t >nH > It did---before I got the error.  When I got the error, there was more > than enough space. > J > > as the program exited, the RUJ file was deleted and thus things looked > > better all of a sudden.6 >eF > Makes sense.  Is the following summary correct?  When the RUJ deviceI > filled up, there was the "cannot extend" error.  An ARBITRARY amount ofiC > time later, after having created some space on the device (NOT byCI > removing anything from the database!), this now-obsolete error crops up8F > in a new command issued in a completely different context.  In otherG > words, the error state gets "frozen" when the device fills up and theiC > corresponding errors can appear later, when the problem no longer 	 > exists.t   ------------------------------  # Date: Sat, 03 Aug 2002 15:00:22 GMTA. From: "Tom Simpson" <simpsont@attbi.com.fubar>/ Subject: Re: device full: wrong error messages?a= Message-ID: <aeS29.38547$Ru5.13255@rwcrnsc52.ops.asp.att.net>)  L I forgot - OpenVMS 7.2-1 Alpha (ES40, 2 node cluster), all current "1" rated patches.J except the last RMS patch which was released only a week or so ago. CSC of course? recommended applying the latest RMS patch even though the patcha
 documentatione lists no similar problems...   Regards, Tom   9 "Tom Simpson" <simpsont@attbi.com.fubar> wrote in messagei8 news:ASR29.269011$uw.152768@rwcrnsc51.ops.asp.att.net...A > We had a similar experience last weekend during our weekly fileu conversions.! > No explanation so far from CSC.s >l > The process went like this:d9 > 1. convert large RMS file ==> to empty drive, no errorsaB > 2. delete original file (delete/log),  delete status was success3 > 3. copy the converted file back to original drive-7 > 4. the copy failed because the output drive was full.R >cD > The converted file is smaller than the original file, so how could > the drive be full? >5K > No users are on the system while this process occurs.  No Batch processesr	 > runnings% > other than the file conversion job. K > The command procedure does a stop/id on any interactive users to be sure.o >oG > So either the delete, really didn't or the drive was not really full.wD > An analyze/disk/repair on the disk in question indicted no errors. > 	 > My $.02v >h
 > Regards, > TomP >sH > "Phillip Helbig" <HELBPHI@sysdev.deutsche-boerse.com> wrote in message7 > news:01KKTSPIA8UM96Z9MP@sysdev.deutsche-boerse.com...V+ > > > I'll bet that your RUJ device filled.  > > J > > It did---before I got the error.  When I got the error, there was more > > than enough space. > >eL > > > as the program exited, the RUJ file was deleted and thus things looked > > > better all of a sudden.e > > H > > Makes sense.  Is the following summary correct?  When the RUJ deviceK > > filled up, there was the "cannot extend" error.  An ARBITRARY amount of E > > time later, after having created some space on the device (NOT by)K > > removing anything from the database!), this now-obsolete error crops up H > > in a new command issued in a completely different context.  In otherI > > words, the error state gets "frozen" when the device fills up and theiE > > corresponding errors can appear later, when the problem no longer1 > > exists.m >o >R   ------------------------------  $ Date: Sat, 3 Aug 2002 14:18:14 -0400  From: John Santos <JOHN@egh.com>/ Subject: Re: device full: wrong error messages?c5 Message-ID: <1020803140225.3497A-100000@Ives.egh.com>e  & On Sat, 3 Aug 2002, Tom Simpson wrote:  N > I forgot - OpenVMS 7.2-1 Alpha (ES40, 2 node cluster), all current "1" rated	 > patchestL > except the last RMS patch which was released only a week or so ago. CSC of > courseA > recommended applying the latest RMS patch even though the patch  > documentationl > lists no similar problems... > 
 > Regards, > Tom  > ; > "Tom Simpson" <simpsont@attbi.com.fubar> wrote in messagee: > news:ASR29.269011$uw.152768@rwcrnsc51.ops.asp.att.net...C > > We had a similar experience last weekend during our weekly file, > conversions.# > > No explanation so far from CSC.o > >) > > The process went like this:t; > > 1. convert large RMS file ==> to empty drive, no errorssD > > 2. delete original file (delete/log),  delete status was success  : What does SHOW DEVICE say for free space after the delete?? Does SHOW DEVICE/FILES  show any open files (especially the oneo you are trying to delete)?  A What kind of disk?  If a file is marked as having a suspected bad B block, the bad block searching process grabs it when it is deletedB and beats on it a while, trying to verify the existence of the badC block, and add it to the bad-block list.  This might only happen ongB very old, non-BBR drives; I can't recall ever having seen it on anG SDI or SCSI disk, but it might just be rare or fast with modern drives.   G If you did a DELETE/ERASE, or if the file was marked "erase on delete",n? it might return control to you immediately, but take a while tot= return the blocks to the free space pool.  (Need to test thiso to be sure.)  @ Since it's a cluster, are you sure nothing on the other node has it open?  ? Maybe the free block numbers are off due to a crash or impropert? dismount some time ago.  SET VOLUME/REBUILD (on both nodes) andrF ANALYZE/DISK again to check for other problems,  (I think your earlier> ana/disk/repair should have detected and fixed this situation, but I'm not certain.)l  ? These are the things I would look at  - hope one of them helps.t  5 > > 3. copy the converted file back to original drivee9 > > 4. the copy failed because the output drive was full.f > > F > > The converted file is smaller than the original file, so how could > > the drive be full? > >qM > > No users are on the system while this process occurs.  No Batch processes- > > running-' > > other than the file conversion job.mM > > The command procedure does a stop/id on any interactive users to be sure.u > >oI > > So either the delete, really didn't or the drive was not really full.dF > > An analyze/disk/repair on the disk in question indicted no errors. > >o > > My $.02e > >  > > Regards, > > Tom@ > >sJ > > "Phillip Helbig" <HELBPHI@sysdev.deutsche-boerse.com> wrote in message9 > > news:01KKTSPIA8UM96Z9MP@sysdev.deutsche-boerse.com...h- > > > > I'll bet that your RUJ device filled.r > > > L > > > It did---before I got the error.  When I got the error, there was more > > > than enough space. > > >rN > > > > as the program exited, the RUJ file was deleted and thus things looked > > > > better all of a sudden.e > > >hJ > > > Makes sense.  Is the following summary correct?  When the RUJ deviceM > > > filled up, there was the "cannot extend" error.  An ARBITRARY amount ofcG > > > time later, after having created some space on the device (NOT by M > > > removing anything from the database!), this now-obsolete error crops up J > > > in a new command issued in a completely different context.  In otherK > > > words, the error state gets "frozen" when the device fills up and the.G > > > corresponding errors can appear later, when the problem no longere
 > > > exists.e > >  > >d >  >  >  >    -- h John Santos  Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------  % Date: Sat, 03 Aug 2002 21:38:19 +02009- From: Didier Morandi <Didier.Morandi@Free.fr> / Subject: Re: device full: wrong error messages? ' Message-ID: <3D4C312B.2CB38499@Free.fr>    John Santos wrote: >  ../..rI > If you did a DELETE/ERASE, or if the file was marked "erase on delete",-A > it might return control to you immediately, but take a while tol? > return the blocks to the free space pool.  (Need to test thisS > to be sure.)  N Which "free space pool"? We are not talking memory here, we are talking header files entries in INDEXF.SYS.   D.   ------------------------------  # Date: Sat, 03 Aug 2002 20:32:10 GMTo. From: "Tom Simpson" <simpsont@attbi.com.fubar>/ Subject: Re: device full: wrong error messages?e/ Message-ID: <a5X29.773904$cQ3.118810@sccrnsc01>.  F There was no delete/erase.  The disk is a 32gb Storageworks drive in a shared SCSI configuration F w/2 HSZ70 controllers.  No device errors noted.  There are less than a hundred files onH the drive, so we aren't running out of header space.  We are not running disk quotas.G If another process has the file open, my experience is that the converte command will generates6 an error.  No convert errors appeared in the log file.  G My first though was to make the command procedure check the free blocks. first and do aJ show device/files but I haven't been given the opportunity to do that yet. We'll see what happensI tonight when the procedure runs again.  After the problem, the free spacek
 looked ok andiJ should not have caused the problem, but that was 3-4 hours after the error occurred...i  L This procedure has run for years without problems, but only recently has the file size grown toE the point that 2 copies of this large file will not fit on the drive.m   Regards, Tome  - "John Santos" <JOHN@egh.com> wrote in message / news:1020803140225.3497A-100000@Ives.egh.com...t( > On Sat, 3 Aug 2002, Tom Simpson wrote: >WJ > > I forgot - OpenVMS 7.2-1 Alpha (ES40, 2 node cluster), all current "1" rated  > > patchescK > > except the last RMS patch which was released only a week or so ago. CSCl of
 > > courseC > > recommended applying the latest RMS patch even though the patch  > > documentationl  > > lists no similar problems... > >) > > Regards, > > Tom  > > = > > "Tom Simpson" <simpsont@attbi.com.fubar> wrote in messagei< > > news:ASR29.269011$uw.152768@rwcrnsc51.ops.asp.att.net...E > > > We had a similar experience last weekend during our weekly filer > > conversions.% > > > No explanation so far from CSC.u > > >s! > > > The process went like this:i= > > > 1. convert large RMS file ==> to empty drive, no errors8F > > > 2. delete original file (delete/log),  delete status was success >a< > What does SHOW DEVICE say for free space after the delete?A > Does SHOW DEVICE/FILES  show any open files (especially the one  > you are trying to delete)? >.C > What kind of disk?  If a file is marked as having a suspected badiD > block, the bad block searching process grabs it when it is deletedD > and beats on it a while, trying to verify the existence of the badE > block, and add it to the bad-block list.  This might only happen onhD > very old, non-BBR drives; I can't recall ever having seen it on anI > SDI or SCSI disk, but it might just be rare or fast with modern drives.i >eI > If you did a DELETE/ERASE, or if the file was marked "erase on delete", A > it might return control to you immediately, but take a while to ? > return the blocks to the free space pool.  (Need to test thise > to be sure.) > B > Since it's a cluster, are you sure nothing on the other node has
 > it open? >hA > Maybe the free block numbers are off due to a crash or impropersA > dismount some time ago.  SET VOLUME/REBUILD (on both nodes) and H > ANALYZE/DISK again to check for other problems,  (I think your earlier@ > ana/disk/repair should have detected and fixed this situation, > but I'm not certain.)w >oA > These are the things I would look at  - hope one of them helps.n >b7 > > > 3. copy the converted file back to original driveo; > > > 4. the copy failed because the output drive was full.  > > >nH > > > The converted file is smaller than the original file, so how could > > > the drive be full? > > >yE > > > No users are on the system while this process occurs.  No BatchP	 processes 
 > > > runningT) > > > other than the file conversion job. I > > > The command procedure does a stop/id on any interactive users to bee sure.a > > > K > > > So either the delete, really didn't or the drive was not really full.oH > > > An analyze/disk/repair on the disk in question indicted no errors. > > >r
 > > > My $.02e > > >m > > > Regards,	 > > > Tomv > > >tL > > > "Phillip Helbig" <HELBPHI@sysdev.deutsche-boerse.com> wrote in message; > > > news:01KKTSPIA8UM96Z9MP@sysdev.deutsche-boerse.com... / > > > > > I'll bet that your RUJ device filled.a > > > >nI > > > > It did---before I got the error.  When I got the error, there was  more > > > > than enough space. > > > > I > > > > > as the program exited, the RUJ file was deleted and thus thingsk looked! > > > > > better all of a sudden.r > > > >mL > > > > Makes sense.  Is the following summary correct?  When the RUJ deviceL > > > > filled up, there was the "cannot extend" error.  An ARBITRARY amount ofI > > > > time later, after having created some space on the device (NOT by L > > > > removing anything from the database!), this now-obsolete error crops upL > > > > in a new command issued in a completely different context.  In otherI > > > > words, the error state gets "frozen" when the device fills up andu thelI > > > > corresponding errors can appear later, when the problem no longerh > > > > exists.8 > > >6 > > >5 > >  > >- > >- > >- >- > --
 > John Santos, > Evans Griffiths & Hart, Inc. > 781-861-0670 ext 539 >y   ------------------------------  $ Date: Sat, 3 Aug 2002 18:21:31 -0400  From: John Santos <JOHN@egh.com>/ Subject: Re: device full: wrong error messages? 5 Message-ID: <1020803181738.3497B-100000@Ives.egh.com>m  & On Sat, 3 Aug 2002, John Santos wrote:  ( > On Sat, 3 Aug 2002, Tom Simpson wrote: > P > > I forgot - OpenVMS 7.2-1 Alpha (ES40, 2 node cluster), all current "1" rated > > patches N > > except the last RMS patch which was released only a week or so ago. CSC of
 > > courseC > > recommended applying the latest RMS patch even though the patch  > > documentationn  > > lists no similar problems... > >  > > Regards, > > Tomb > > = > > "Tom Simpson" <simpsont@attbi.com.fubar> wrote in messageM< > > news:ASR29.269011$uw.152768@rwcrnsc51.ops.asp.att.net...E > > > We had a similar experience last weekend during our weekly filem > > conversions.% > > > No explanation so far from CSC.! > > >g! > > > The process went like this:a= > > > 1. convert large RMS file ==> to empty drive, no errors F > > > 2. delete original file (delete/log),  delete status was success > < > What does SHOW DEVICE say for free space after the delete?A > Does SHOW DEVICE/FILES  show any open files (especially the one. > you are trying to delete)? > C > What kind of disk?  If a file is marked as having a suspected bad2D > block, the bad block searching process grabs it when it is deletedD > and beats on it a while, trying to verify the existence of the badE > block, and add it to the bad-block list.  This might only happen onsD > very old, non-BBR drives; I can't recall ever having seen it on anI > SDI or SCSI disk, but it might just be rare or fast with modern drives.a > I > If you did a DELETE/ERASE, or if the file was marked "erase on delete",iA > it might return control to you immediately, but take a while to4? > return the blocks to the free space pool.  (Need to test thisl > to be sure.) > B > Since it's a cluster, are you sure nothing on the other node has
 > it open? > A > Maybe the free block numbers are off due to a crash or improper-A > dismount some time ago.  SET VOLUME/REBUILD (on both nodes) andsH > ANALYZE/DISK again to check for other problems,  (I think your earlier@ > ana/disk/repair should have detected and fixed this situation, > but I'm not certain.)e > A > These are the things I would look at  - hope one of them helps.   B P.S. Forgot to mention another one... Do you have a disk-defraggerA running?  I think I've seen cases where Diskeeper, in particular,/@ had allocated a large chunk of space for moving a file, and thenA the file was deleted from under it, and it took Diskeeper a while @ to notice and release its work space.  Though if the new file is> smaller than the old file, and there was room for the old file= plus the work space, there must be room for the new file plush= work space.  Or are there other large files on the same disk,/& which a defragger might be defragging?     > 7 > > > 3. copy the converted file back to original drivel; > > > 4. the copy failed because the output drive was full.c > > >eH > > > The converted file is smaller than the original file, so how could > > > the drive be full? > > >aO > > > No users are on the system while this process occurs.  No Batch processesr
 > > > runningl) > > > other than the file conversion job..O > > > The command procedure does a stop/id on any interactive users to be sure.r > > >eK > > > So either the delete, really didn't or the drive was not really full.nH > > > An analyze/disk/repair on the disk in question indicted no errors. > > > 
 > > > My $.02e > > >e > > > Regards,	 > > > Tom  > > >RL > > > "Phillip Helbig" <HELBPHI@sysdev.deutsche-boerse.com> wrote in message; > > > news:01KKTSPIA8UM96Z9MP@sysdev.deutsche-boerse.com...e/ > > > > > I'll bet that your RUJ device filled.a > > > >lN > > > > It did---before I got the error.  When I got the error, there was more > > > > than enough space. > > > >dP > > > > > as the program exited, the RUJ file was deleted and thus things looked! > > > > > better all of a sudden.0 > > > >2L > > > > Makes sense.  Is the following summary correct?  When the RUJ deviceO > > > > filled up, there was the "cannot extend" error.  An ARBITRARY amount ofoI > > > > time later, after having created some space on the device (NOT byaO > > > > removing anything from the database!), this now-obsolete error crops up L > > > > in a new command issued in a completely different context.  In otherM > > > > words, the error state gets "frozen" when the device fills up and the I > > > > corresponding errors can appear later, when the problem no longerR > > > > exists.6 > > >s > > >. > >  > >  > >  > >  >  > -- e
 > John Santosw > Evans Griffiths & Hart, Inc. > 781-861-0670 ext 539 >  >  >    -- C John Santosh Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------  $ Date: Sat, 3 Aug 2002 18:43:52 -0400  From: John Santos <JOHN@egh.com>/ Subject: Re: device full: wrong error messages? 5 Message-ID: <1020803183813.3497D-100000@Ives.egh.com>R  & On Sat, 3 Aug 2002, Tom Simpson wrote:  H > There was no delete/erase.  The disk is a 32gb Storageworks drive in a > shared SCSI configurationsH > w/2 HSZ70 controllers.  No device errors noted.  There are less than a > hundred files onJ > the drive, so we aren't running out of header space.  We are not running > disk quotas.I > If another process has the file open, my experience is that the converta > command will generaten8 > an error.  No convert errors appeared in the log file.  E I don't think convert requires exclusive access to its input file, som@ if another process has it open with read access and allows writeE access, don't think CONVERT will notice, but it will cause the DELETE 1 to delay until the other process closes the file.o   > I > My first though was to make the command procedure check the free blockse > first and do aL > show device/files but I haven't been given the opportunity to do that yet. > We'll see what happensK > tonight when the procedure runs again.  After the problem, the free spaceR > looked ok and L > should not have caused the problem, but that was 3-4 hours after the error
 > occurred...n > N > This procedure has run for years without problems, but only recently has the > file size grown toG > the point that 2 copies of this large file will not fit on the drive.h  @ Good luck.  I hope it turns out to be easy to fix, and not a VMS# bug that could be biting all of us!x   > 
 > Regards, > Tom-   -- - John Santos- Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------    Date: 03 Aug 2002 23:54:30 +0800, From: Paul Repacholi <prep@prep.synonet.com>" Subject: F&A?? Was VAX Hardware ID0 Message-ID: <87eldg6iq1.fsf_-_@prep.synonet.com>  $ "Hans Vlems" <hvlems@iae.nl> writes:  E > A "B" license is not very common, which is probably the reason thatl& > Bob Supnik got the 3900's microcode.  8 > > Type: B, Units Required: 100    (VAX/VMS F&A Server)  % OK, what the F&A is an `F&A Server' ?r   -- m< Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda.1@                                              West Australia 6076. Raw, Cooked or Well-done, it's all half baked.F EPIC, The Architecture of the future, always has been, always will be.   ------------------------------  $ Date: Sat, 3 Aug 2002 16:56:34 -04001 From: "Island (hpaq.net)" <dbturner@islandco.com> F Subject: Free  New High Res 19" Monitor with Xp1000 667 purchase !!!!!/ Message-ID: <ukogp0an73eidb@news.supernews.com>i  2 This month only for sales starting August 1st 2002       -- Island Computers US Corp.r 2700 Gregory Streetc Savannah GA 31404e Toll Free: 1-877 636 4332s International: 001 912 447 6622   Facsimile:      001 912 201 0096 dbturner@hpaq.netf www.hpaq.net   ------------------------------    Date: 03 Aug 2002 23:09:41 +0800, From: Paul Repacholi <prep@prep.synonet.com>0 Subject: Re: OpenVMS comes to Itanium - Roadshow- Message-ID: <87n0s46ksq.fsf@prep.synonet.com>y  , "Bill Todd" <billtodd@metrocast.net> writes:  F > Perhaps.  But there's no way those could account for anything like aE > speed-up by a factor of about 1000: either the data layout changed,t? > or the algorithms used to process the data differed radicallyo! > between Rdb and Oracle Classic.a  F Or you plonked enough memory into the 45 to zero the IOs... That could? make for a radicle speed-up. Pity somone didnot ask for a validI comparison figure...   -- r< Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda. @                                              West Australia 6076. Raw, Cooked or Well-done, it's all half baked.F EPIC, The Architecture of the future, always has been, always will be.   ------------------------------  # Date: Sat, 03 Aug 2002 20:42:16 GMTu* From: "Bill Todd" <billtodd@metrocast.net>0 Subject: Re: OpenVMS comes to Itanium - Roadshow@ Message-ID: <IeX29.76237$nm.2904334@bin5.nnrp.aus1.giganews.com>  9 "Paul Repacholi" <prep@prep.synonet.com> wrote in messagee' news:87n0s46ksq.fsf@prep.synonet.com...e. > "Bill Todd" <billtodd@metrocast.net> writes: >tH > > Perhaps.  But there's no way those could account for anything like aG > > speed-up by a factor of about 1000: either the data layout changed, A > > or the algorithms used to process the data differed radicallya# > > between Rdb and Oracle Classic.v >uH > Or you plonked enough memory into the 45 to zero the IOs... That couldA > make for a radicle speed-up. Pity somone didnot ask for a validh > comparison figure...  H Good point (being a storage kind of guy, I just don't naturally think ofG possibilities that eliminate storage *entirely* when I'm thinking about H optimizations, since the only kind of storage that's interesting is thatG which won't fit in main memory...).  Going from an essentially uncachedoK database to a database fully resident in cache would produce something like H a factor of 1000 speed-up in many cases (at least given fast processing,) which the ES45 certainly have in spades).m   - bill   ------------------------------  $ Date: Sun, 4 Aug 2002 08:53:09 -0400' From: "Main, Kerry" <Kerry.Main@hp.com>r0 Subject: RE: OpenVMS comes to Itanium - RoadshowT Message-ID: <BE56C50EA024184DAF48F0B9A47F5CF4026608CF@kaoexc01.americas.cpqcorp.net>   Paul,   B >>> Or you plonked enough memory into the 45 to zero the IOs...<<<  F Fwiw - They mentioned there are 2 ES45's. I just love the way databaseF marketing folks like to highlight "this job used to take x hrs on thisA database and now only takes x min's (or sec's) on this database."r without mentioning-T  E - the processors they are now using are a huge number of times faster  (VAX 4000 vs. ES45 x 2)yD - they were likely using a very old version of the previous databaseG - as with most databases, memory is likely the biggest tuning parameter F and they are likely using many Gb's compared to a small Mb environment previously.-  E Now, Oracle 9i RAC does have some good new features and capabilities, F but Oracle Rdb also has some extremely cool new features - like Galaxy@ support i.e.. sharing cache in common memory between separate OSH instances. CPU's can dynamically move between OS instances to which ever( one needs more processing capability.=20  B On a related note - we have a Cust that wants to consolidate theirE Oracle 8 UNIX/NT applications on a multi-site Oracle 9i RAC config onnG OpenVMS. Consolidation 101 states "never consolidate to one site on itseE own" and being able to establish a full Oracle 9i RAC back end config C with a common clustered batch environment over 10-50-100+ km can beo attractive.r  B For articles how to establish Oracle "split config's" - see recent articles in Oracles Metalink.t   :-)a   Regardsl  
 Kerry Main Senior Consultantt Hewlett-Packard Canada! Consulting & Integration Servicesk Voice: 613-592-4660u Fax   : 613-591-4477 Email: Kerry.Main@hp.com     -----Original Message-----6 From: Paul Repacholi [mailto:prep@prep.synonet.com]=20 Sent: August 3, 2002 11:10 AMi To: Info-VAX@Mvb.Saic.Com 0 Subject: Re: OpenVMS comes to Itanium - Roadshow    , "Bill Todd" <billtodd@metrocast.net> writes:  I > Perhaps.  But there's no way those could account for anything like a=20tH > speed-up by a factor of about 1000: either the data layout changed, or  H > the algorithms used to process the data differed radically between Rdb   > and Oracle Classic.   F Or you plonked enough memory into the 45 to zero the IOs... That could? make for a radicle speed-up. Pity somone didnot ask for a valido comparison figure...   --=20l< Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda. E                                              West Australia 6076 Raw,aG Cooked or Well-done, it's all half baked. EPIC, The Architecture of the.( future, always has been, always will be.   ------------------------------   Date: 4 Aug 2002 09:01:03 -0600S- From: Kilgallen@SpamCop.net (Larry Kilgallen)d) Subject: Re: Second KLEZ from ATTBI Todayt3 Message-ID: <gkJtjcFEJTIZ@eisner.encompasserve.org>   q In article <Ik039.42286$Ru5.16270@rwcrnsc52.ops.asp.att.net>, "Terry C. Shannon" <terryshannon@attbi.com> writes: + > Verizon DSL is looking better and better!   6 Whereas VMSmail has always looked good in this regard.   ------------------------------   Date: 4 Aug 02 19:16:04 +0200 ) From: p_sture@elias.decus.ch (Paul Sture)t3 Subject: Re: Second KLEZ from ATTBI Today - TROLL !h) Message-ID: <GuTz4WtHFeKs@elias.decus.ch>B  c In article <Odc39.780716$cQ3.119310@sccrnsc01>, "Terry C. Shannon" <terryshannon@attbi.com> writes:s > 5 > "Jan-Erik Sderholm" <aaa@aaa.com> wrote in message # > news:3D4D4DDE.2ABE52D1@aaa.com...t1 >> - "Sorry sir, but you are standing on my foot"  >> - "So what ? Sue me !!" >> >>? >> Come on Terry, a correct answer to Anders' (factual correct)) >> note, *could* have been : >>= >> "Yes I know it of topic, but I was a bit upset at the time  >> I posted. I'm sorry..." >>> >> I have not looked but there must be some other newsgroup(s)1 >> ment to handle computer virus issues anyway...n >> > M > Thing of it is, ATTBI.COM (who I would recommend no nonody) uses BRIGHTMAILeL > antispam and antivrus filtering. They (ATTBI) are completely unresponsive,N > and the Klez attacks are increasing daily. ATTBI refuses to explain why, butI > if you've very has the misfortune of talking to their tech support, youu > might know why). >   E Sorry Terry, but blaming your ISP does not normally get you anywhere.u  L The last time I was subject to a DoS, all the previous skilled support staffM at the ISP I had chosen were no longer there and all I got was the suggestionfG to reinstall my modem driver. Quite a recommendation since I didn't usen a modem!  O I understand your frustration and the wish to lash out, but please seek anothereN solution (VMS, Linux, or if you wish to continue with Windows, Eudora and many# other mail programs - NOT Outlook).0 __
 Paul Sture Switzerland    ------------------------------  # Date: Sun, 04 Aug 2002 17:25:17 GMTc1 From: "Terry C. Shannon" <terryshannon@attbi.com>@3 Subject: Re: Second KLEZ from ATTBI Today - TROLL !a. Message-ID: <1sd39.146233$uh7.23572@sccrnsc03>  6 "Paul Sture" <p_sture@elias.decus.ch> wrote in message# news:GuTz4WtHFeKs@elias.decus.ch...cD > In article <Odc39.780716$cQ3.119310@sccrnsc01>, "Terry C. Shannon"  <terryshannon@attbi.com> writes: > >e7 > > "Jan-Erik Sderholm" <aaa@aaa.com> wrote in messages% > > news:3D4D4DDE.2ABE52D1@aaa.com...h3 > >> - "Sorry sir, but you are standing on my foot"t > >> - "So what ? Sue me !!" > >> > >>A > >> Come on Terry, a correct answer to Anders' (factual correct)N > >> note, *could* have been : > >>? > >> "Yes I know it of topic, but I was a bit upset at the timen > >> I posted. I'm sorry..." > >>@ > >> I have not looked but there must be some other newsgroup(s)3 > >> ment to handle computer virus issues anyway...o > >> > > D > > Thing of it is, ATTBI.COM (who I would recommend no nonody) uses
 BRIGHTMAIL@ > > antispam and antivrus filtering. They (ATTBI) are completely
 unresponsive, L > > and the Klez attacks are increasing daily. ATTBI refuses to explain why, butAK > > if you've very has the misfortune of talking to their tech support, you  > > might know why). > >  >eG > Sorry Terry, but blaming your ISP does not normally get you anywhere.2 >oH > The last time I was subject to a DoS, all the previous skilled support staffOD > at the ISP I had chosen were no longer there and all I got was the
 suggestionI > to reinstall my modem driver. Quite a recommendation since I didn't usef
 > a modem! > I > I understand your frustration and the wish to lash out, but please seeku anothernK > solution (VMS, Linux, or if you wish to continue with Windows, Eudora andT many% > other mail programs - NOT Outlook).i  K I'll load ALL-In-One and MS-OFFICE and Claris on my XP1000 tomorow. That'll  fix the problem.  F A hangman's noose (short-drop) ought to fix the Klez problem, too. ;-} > __ > Paul Sture
 > Switzerland    ------------------------------  * Date: Sat, 3 Aug 2002 13:46:21 +0000 (UTC) From: david20@alpha2.mdx.ac.uk Subject: Re: Today's KLEZ Alert)* Message-ID: <aigmrd$qi$1@aquila.mdx.ac.uk>  r In article <5NA29.262046$uw.150566@rwcrnsc51.ops.asp.att.net>, "Terry C. Shannon" <terryshannon@attbi.com> writes:  C You can't trust the from address where the KLEZ virus is concerned.mF Looking at the received lines seems to show that them message was sent1 from 216.177.21.60 which a dns lookup confirms is E 4158.mht.nh.dsl.customer.g4.Net. This was then sent through this ISPso mailhub boston3.g4.net.s; All you can say is that someone using this ISP who has youreM terryshannon@attbi.com mail address and the jtcarney@comcast.net mail addressrN stored somewhere on his system (addressbook or elsewhere) is infected with the KLEZ virus.   J Of course KLEZ isn't exactly a new virus anymore hence ATTBI.COM should byG now be either sanitising or better yet dropping such infected messages.oK Note. There is absolutely no point in trying to bounce back warnings to theeF sender with KLEZ since the reply-to address is forged you just end up M confusing some innocent third party about an infected message he didn't send.   
 David Webb VMS and Unix team leader CCSS Middlesex University  G >As part of their overpriced and incompetent service, the cable guys at,L >ATTBI.COM sent me the following copy of KLEZ today. It allegedly originated >from JTCARNEY# >Return-Path: <jkrccoin@gsinet.net>rF >Received: from boston3.g4.net ([216.177.0.33]) by rwcrgwc54.attbi.comH >          (InterMail vM.4.01.03.34 201-229-121-134-20020625) with ESMTPK >          id <20020802185428.XHEO22288.rwcrgwc54.attbi.com@boston3.g4.net>kG >          for <terryshannon@attbi.com>; Fri, 2 Aug 2002 18:54:28 +0000fG >Received: from Ypiru (4158.mht.nh.dsl.customer.G4.NET [216.177.21.60])l= > by boston3.g4.net (8.11.3/8.11.3) with SMTP id g72IsKQ64442oD > for <terryshannon@attbi.com>; Fri, 2 Aug 2002 14:54:20 -0400 (EDT)% > (envelope-from jkrccoin@gsinet.net) + >Date: Fri, 2 Aug 2002 14:54:20 -0400 (EDT)i7 >Message-Id: <200208021854.g72IsKQ64442@boston3.g4.net>r& >From: jtcarney <jtcarney@comcast.net> >To: terryshannon@attbi.como7 >Subject: You permit to use your Member identification.  >MIME-Version: 1.0% >Content-Type: multipart/alternative;u > boundary=Y7AIYAP7XQ44738lKHS7u >n >--Y7AIYAP7XQ44738lKHS7f >Content-Type: text/html; , >Content-Transfer-Encoding: quoted-printable >a >vI >KLEZ stuff deleted of course. Anyone interested in joining me in a classt> >action suit against ATTBI.COM? Either way, be VERY careful... >  >--i >Terry C. Shannon , >Consultant and Publisher, Shannon Knows HPC9 >Director, Technical Communications, Science Medicus Inc.E& >Director at Large, Encompass US, Inc. >terryshannon@attbi.comK >http://www.openvms.orgu >h >o   ------------------------------  # Date: Sat, 03 Aug 2002 14:03:40 GMT 1 From: "Terry C. Shannon" <terryshannon@attbi.com>t Subject: Re: Today's KLEZ Alert . Message-ID: <0pR29.135905$uh7.21702@sccrnsc03>  + <david20@alpha2.mdx.ac.uk> wrote in messageh$ news:aigmrd$qi$1@aquila.mdx.ac.uk...J > In article <5NA29.262046$uw.150566@rwcrnsc51.ops.asp.att.net>, "Terry C.) Shannon" <terryshannon@attbi.com> writes:u >tE > You can't trust the from address where the KLEZ virus is concerned.iH > Looking at the received lines seems to show that them message was sent3 > from 216.177.21.60 which a dns lookup confirms iseG > 4158.mht.nh.dsl.customer.g4.Net. This was then sent through this ISPsr > mailhub boston3.g4.net. = > All you can say is that someone using this ISP who has youruG > terryshannon@attbi.com mail address and the jtcarney@comcast.net maile addresseL > stored somewhere on his system (addressbook or elsewhere) is infected with then
 > KLEZ virus.r >iL > Of course KLEZ isn't exactly a new virus anymore hence ATTBI.COM should byI > now be either sanitising or better yet dropping such infected messages.-  G Damn right they should, especially at what the theives charge (two rate.K hikes in one year, bandwidth cut back 3x, max outgoing email size now 5MB).8  I > Note. There is absolutely no point in trying to bounce back warnings to  therG > sender with KLEZ since the reply-to address is forged you just end uprI > confusing some innocent third party about an infected message he didn'tT send.e  G You are right. Public hanging is the answer. Where is Jack "Short-Drop"h. Ketch when you need him? Still on Tyburn Hill?   >f > David Webb > VMS and Unix team leader > CCSS > Middlesex University >mI > >As part of their overpriced and incompetent service, the cable guys at.C > >ATTBI.COM sent me the following copy of KLEZ today. It allegedly,
 originated > >from JTCARNEY% > >Return-Path: <jkrccoin@gsinet.net>eH > >Received: from boston3.g4.net ([216.177.0.33]) by rwcrgwc54.attbi.comJ > >          (InterMail vM.4.01.03.34 201-229-121-134-20020625) with ESMTP > >          ido= <20020802185428.XHEO22288.rwcrgwc54.attbi.com@boston3.g4.net>wI > >          for <terryshannon@attbi.com>; Fri, 2 Aug 2002 18:54:28 +0000eI > >Received: from Ypiru (4158.mht.nh.dsl.customer.G4.NET [216.177.21.60])r? > > by boston3.g4.net (8.11.3/8.11.3) with SMTP id g72IsKQ64442dF > > for <terryshannon@attbi.com>; Fri, 2 Aug 2002 14:54:20 -0400 (EDT)' > > (envelope-from jkrccoin@gsinet.net)o- > >Date: Fri, 2 Aug 2002 14:54:20 -0400 (EDT)s9 > >Message-Id: <200208021854.g72IsKQ64442@boston3.g4.net>w( > >From: jtcarney <jtcarney@comcast.net> > >To: terryshannon@attbi.comt9 > >Subject: You permit to use your Member identification.  > >MIME-Version: 1.0' > >Content-Type: multipart/alternative; ! > > boundary=Y7AIYAP7XQ44738lKHS7  > >- > >--Y7AIYAP7XQ44738lKHS7  > >Content-Type: text/html;+. > >Content-Transfer-Encoding: quoted-printable > >u > >:K > >KLEZ stuff deleted of course. Anyone interested in joining me in a class @ > >action suit against ATTBI.COM? Either way, be VERY careful... > >o > >--h > >Terry C. Shannone. > >Consultant and Publisher, Shannon Knows HPC; > >Director, Technical Communications, Science Medicus Inc.)( > >Director at Large, Encompass US, Inc. > >terryshannon@attbi.com  > >http://www.openvms.org1 > >c > >d   ------------------------------  % Date: Sat, 03 Aug 2002 16:44:04 +0200 B From: Michiel Erens <I.dont.want.spam@this.mailaddress.is.invalid> Subject: Re: Today's KLEZ AlertP7 Message-ID: <3D4BEC34.7A78@this.mailaddress.is.invalid>y   david20@alpha2.mdx.ac.uk wrote:- > E > You can't trust the from address where the KLEZ virus is concerned. H > Looking at the received lines seems to show that them message was sent3 > from 216.177.21.60 which a dns lookup confirms iseG > 4158.mht.nh.dsl.customer.g4.Net. This was then sent through this ISPs  > mailhub boston3.g4.net. = > All you can say is that someone using this ISP who has your1H > terryshannon@attbi.com mail address and the jtcarney@comcast.net mail G > address stored somewhere on his system (addressbook or elsewhere) is - > infected with the KLEZ virus.+  D There may be more. G4 is a Massachusetts and New Hampshire based DSLF provider. The NH in de dns-name means New Hampshire, and MHT probably C means Manchester. So he lives in or near Manchester, New Hampshire.u  F Another interesting line is the "(envelope-from jkrccoin@gsinet.net)".@ This is put in by the provider who knows who's connected at the = other end of the DSL line. Klez only spoofs the from address e and the computername (Ypiru). 6 If you put that mailaddress in Google you get the pageB http://rarecoins.powerfulhosting.com/ The mail address on the page@ mentions a PO box in Bedford NH, what happens to be a town just  outside Manchester NH. e? So my guess is that jkrccoin@gsinet.net is the infected person.a   --   ME Posted by news://news.nb.nu    ------------------------------    Date: 04 Aug 2002 00:03:11 +0800, From: Paul Repacholi <prep@prep.synonet.com> Subject: Re: Today's KLEZ Alert - Message-ID: <87ado46ibk.fsf@prep.synonet.com>   3 "Terry C. Shannon" <terryshannon@attbi.com> writes:r  B > Yep. A damn shame Bill Strecker rolled over and took Microsoft's? > first offer in '95--Intel server-side parity, NOT client-side A > parity. This is one of the Top Ten Stupid DEC Pet Tricks of thes > 1990s! ;-}  D Comsidering he could have hung billy out to dry with 3x penalty PLUSF damages etc... I've never heard of a guy folding on a Royal Flush till then. :(   -- t< Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda. @                                              West Australia 6076. Raw, Cooked or Well-done, it's all half baked.F EPIC, The Architecture of the future, always has been, always will be.   ------------------------------  # Date: Sat, 03 Aug 2002 19:23:26 GMTo1 From: "Terry C. Shannon" <terryshannon@attbi.com>e Subject: Re: Today's KLEZ Alertk/ Message-ID: <O4W29.773283$cQ3.118124@sccrnsc01>   9 "Paul Repacholi" <prep@prep.synonet.com> wrote in messagee' news:87ado46ibk.fsf@prep.synonet.com...c5 > "Terry C. Shannon" <terryshannon@attbi.com> writes:u >pD > > Yep. A damn shame Bill Strecker rolled over and took Microsoft'sA > > first offer in '95--Intel server-side parity, NOT client-side)C > > parity. This is one of the Top Ten Stupid DEC Pet Tricks of the0 > > 1990s! ;-} >rF > Comsidering he could have hung billy out to dry with 3x penalty PLUSH > damages etc... I've never heard of a guy folding on a Royal Flush till
 > then. :(  L Nor have I. But hey, he got his Golden Parachute, and is now busy plying hisG trade here in the Boston area. Glad I am not a client who leverages his 
 clairvoyance!e   ------------------------------   Date: 4 Aug 2002 08:18:05 -0700h- From: merritt.robert@spsd.sk.ca (rob merritt)'; Subject: trying to install CPQ java131 on a alpha 250 4/266o= Message-ID: <b6bf97d5.0208040718.6ea233f2@posting.google.com>4   Hi her is what I have:w7   Compaq TCP/IP Services for OpenVMS Alpha Version V5.1a2   on a AlphaStation 250 4/266 running OpenVMS V7.3L Physical Memory Usage (pages):     Total        Free      In Use    ModifiedL   Main Memory (128.00Mb)           16384        5351       10157         876      K I am trying to get java131 installed on this machine , so I pcsi install itr fine try to run it in test   $ java -versionn   $ java -versione **Out of memory, exiting**    5 at this point  tried aotogening to get more resource r    autogen getdata setparams reboot     still the same error message  	 any ideasa   ------------------------------  $ Date: Sun, 4 Aug 2002 16:25:17 +01005 From: "Robert A.M. van Lopik" <lopik@mail.telepac.pt>s? Subject: Re: trying to install CPQ java131 on a alpha 250 4/266 " Message-ID: <3d4d47f9@news.wau.nl>  0 My Alpha server 400 4/233 with 256 Mb of memory:  G After installing  gotsame error message, which went away after autogen.l# Still very very slow at starting ope something like $ java -versiont  H seems to need lots of memory. Release notes don't seem to indicate exact figures.   hthI
 rob van lopiki    : "rob merritt" <merritt.robert@spsd.sk.ca> wrote in message7 news:b6bf97d5.0208040718.6ea233f2@posting.google.com...p > Hi > her is what I have:n9 >   Compaq TCP/IP Services for OpenVMS Alpha Version V5.1b4 >   on a AlphaStation 250 4/266 running OpenVMS V7.3B > Physical Memory Usage (pages):     Total        Free      In Use ModifiedB >   Main Memory (128.00Mb)           16384        5351       10157 876  >t >o >bJ > I am trying to get java131 installed on this machine , so I pcsi install it > fine try to run it in test >e > $ java -versionc >C > $ java -versionp > **Out of memory, exiting** >t >e6 > at this point  tried aotogening to get more resource > " > autogen getdata setparams reboot >s >f > still the same error message >  > any ideas    ------------------------------  % Date: Sun, 04 Aug 2002 17:00:05 -0000 * From: Rick Retterer <rick0157@charter.net>? Subject: Re: trying to install CPQ java131 on a alpha 250 4/266'/ Message-ID: <ukqnclajd53ce2@corp.supernews.com>    Check the web site:,Y http://www.compaq.com/java/documentation/1.3.1/ovms/docs/RELEASE_NOTES.HTML#ProcessQuotasm  - Make sure your process quotas are sufficient.c& -------------------------------------- Posted by: Rick Retterer   ------------------------------  % Date: Sun, 04 Aug 2002 17:00:04 -0000.* From: Rick Retterer <rick0157@charter.net>? Subject: Re: trying to install CPQ java131 on a alpha 250 4/266r/ Message-ID: <ukqnckmf8qaie1@corp.supernews.com>h   Check the web site:-Y http://www.compaq.com/java/documentation/1.3.1/ovms/docs/RELEASE_NOTES.HTML#ProcessQuotasS  - Make sure your process quotas are sufficient. & -------------------------------------- Posted by: Rick Retterer   ------------------------------    Date: 03 Aug 2002 23:51:26 +0800, From: Paul Repacholi <prep@prep.synonet.com> Subject: Re: VAX Hardware ID- Message-ID: <87it2s6iv5.fsf@prep.synonet.com>>  ) carl@gerg.tamu.edu (Carl Perkins) writes:t  ' > I doubt that any VAX knows this info.C  < Several of them have provision for the SN to be wired in the2 backplane. In the case of 750s, it is 4 I believe.   --  < Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda.e@                                              West Australia 6076. 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 2002.426 ************************TTBI refuses to explain why, butI > if you've very has the misfortune of talking to their tech support, youu > might know why). >   E Sorry Terry, but blaming your ISP does not normally get you anywhere.u  L The last time I was subject to a DoS, all the previous@     A     B     C     D     E     F     G     H     I     J     K     L     M     N     O     P     Q     R     S     T     U     V     W     X     Y     Z     [     \     ]     ^     _     `     a     b     c     d     e     f     g     h     i     j     k     l     m     n     o     p     q     r     s     t     u     v     w     x     y     z     {     |     }     ~                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           !    !    !    !    !    !    !    !    !    	!    
!    !    !    
!    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !     !    !!    "!    #!    $!    %!    &!    '!    (!    )!    *!    +!    ,!    -!    .!    /!    0!    1!    2!    3!    4!    5!    6!    7!    8!    9!    :!    ;!    <!    =!    >!    ?!    @!    A!    B!    C!    D!    E!    F!    G!    H!    I!    J!    K!    L!    M!    N!    O!    P!    Q!    R!    S!    T!    U!    V!    W!    X!    Y!    Z!    [!    \!    ]!    ^!    _!    `!    a!    b!    c!    d!    e!    f!    g!    h!    i!    j!    k!    l!    m!    n!    o!    p!    q!    r!    s!    t!    u!    v!    w!    x!    y!    z!    {!    |!    }!    ~!    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    !    