1 INFO-VAX	Sat, 03 Aug 2002	Volume 2002 : Issue 424       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 0 Re: Bad shadowing and SCSI bus error interaction2 Re: Can ANYONE explain HP's rationale on this one?2 Re: Can ANYONE explain HP's rationale on this one? Re: Compression on DLT backup $ Re: Help - Problem with keys in TPU.$ Re: Help - Problem with keys in TPU.$ Re: Help - Problem with keys in TPU.% Re: Help MRU! Robot is not responding ! Re: Hex to decimal conversion dcl ! Re: Hex to decimal conversion dcl  Re: Low-level format SCSI disk% Re: No Andrew, slowaris can't be VMS! ' Re: OpenVMS comes to Itanium - Roadshow ' Re: OpenVMS comes to Itanium - Roadshow < Re: Robust exception handler context in C (well, C++ really)< Re: Robust exception handler context in C (well, C++ really) Today's KLEZ Alert Re: Today's KLEZ Alert Re: Today's KLEZ Alert/ Re: Two-headed hard drive as a security bandaid  Re: VAX Hardware ID  Re: VAX Hardware ID  Re: VAX Hardware ID   F ----------------------------------------------------------------------   Date: 2 Aug 02 20:27:40 +0200 ) From: p_sture@elias.decus.ch (Paul Sture) L Subject: Re: Arithmetic Data Corruption - Compaq TCP/IP Services 5.3 and NFS) Message-ID: <p9wjBj1BJ1ah@elias.decus.ch>   ` In article <3D4A2542.4010807@wasd.vsm.com.au>, Mark Daniel <Mark.Daniel@wasd.vsm.com.au> writes:J > We recently had a *real significant* problem after an upgrade to Compaq L > TCP/IP 5.3.  Not to labour the story too heavily, but as this causes data M > corruption, a *warning* is in order and I couldn't find an existing one on   > c.o.v. > M > If you have this version of TCP/IP installed, are using the NFS server and  I > 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. > F > There is an interesting story behind this.  Perhaps someone who has 5 > first-hand knowlege might be in a position to post.  >   N I got a message about this from an ex-colleague who is in Oz, and got my localO HP guy to look it up on the CSC database. It seems it was first reported by CSC H Australia, and came with a reproducer in FORTRAN. That's the limit of my knowledge I'm afraid.     __
 Paul Sture Switzerland    ------------------------------   Date: 2 Aug 2002 13:45:25 -0700 1 From: nothome@spammers.are.scum (Malcolm Dunnett) L Subject: Re: Arithmetic Data Corruption - Compaq TCP/IP Services 5.3 and NFS- Message-ID: <tdIHW5rF$SyH@malvm7.mala.bc.ca.>   . In article <3D4A2542.4010807@wasd.vsm.com.au>,5     Mark Daniel <Mark.Daniel@wasd.vsm.com.au> writes:   J > We recently had a *real significant* problem after an upgrade to Compaq L > TCP/IP 5.3.  Not to labour the story too heavily, but as this causes data M > corruption, a *warning* is in order and I couldn't find an existing one on   > c.o.v. > M > If you have this version of TCP/IP installed, are using the NFS server and  I > have any application that does floating point arithmetic :^) apply the  ; > just-released AXPVMS-TCPIP_MUP-V0503-181-4 *immediately*.  >   J    This doesn't seem to be available on ftp.service.digital.com ( at least I can't find it ).   ------------------------------    Date: 03 Aug 2002 01:07:04 +0800, From: Paul Repacholi <prep@prep.synonet.com>9 Subject: Re: Bad shadowing and SCSI bus error interaction - Message-ID: <87r8hh9olj.fsf@prep.synonet.com>   " John Santos <JOHN@egh.com> writes:  & > On 1 Aug 2002, Paul Repacholi wrote:   & > > John Santos <JOHN@egh.com> writes:   E > > > The 2nd problem is why doesn't volume shadowing hide this error D > > > from the user apps?  Shouldn't it either declare DKI100: dead,? > > > and drop it from the shadow set, or retry (which seems to 4 > > > succeed, since the drive is running fine now)?   B > > Shadowing returns the bad news on writes, and the good news on
 > > reads....    A > > On a read, any member that can return the correct data, fine.    B > > On a write, we NEED to know if we have an error. else we wouldE > > silently end up with a 0 unit shadow set and no notice :( When it E > > returns to you, it must have expelled the unit, written the data, E > > or had the IO canceled. Anything else is a massive bug waiting to  > > kill your data!!   > > *WE* need to know, but the application sure as hell doesn't!   : > Shadowing is supposed to hide hardware failures from the > application.  D No, shadowing is designed to enable your app to continue in the face of disk errors.    C > Put it in the error log, tell OPCOM, send an emergency message to C > the console, put the shadow set into mount verify and let a human < > sort it out, do whatever it takes, but don't blow away the > application!  E You should attempt a read *with whatever is needed to get it from the A metal, not from caches* and use the success/failure from that for  further processing.    D > Suppose there is a more traditional error, such as a power failureD > on one of the disk cabinets or at one site of a wide-area cluster.F > The drive goes offline, and the shadow driver, AFAIK, is supposed toE > drop it from the shadow set and continue.  Are you claiming that if E > the next I/O after the power failure happens to be a read, the read F > will be satisfied from a working member, and the power-failed memberE > will be dropped from the shadow set, but if the next I/O happens to E > be a write, then the application will receive an error (even though D > the data may have already been writen to the non-failed members of= > the shadow set, since the relative order of writes can't be E > assumed)?  It just throws up its hands and surrenders?  What use is ! > shadowing, if this is the case?   A The read will win if there are one or more surviving members with B valid data.* The read will probably go to the local drive, and theC death of the other end may not even be known as yet, but we get the  bits, and are happy.  > Now on the write, there are two cases. 1) the failure has beenA detected already, and the failed member has been expelled for the E shadow set.  But in this case, we can write to all (remaining) shadow C members, so we are happy. 2) We discover the failure as part of the E write , the write is stalled while shadowing sorts out the mess. Then 
 go to case 1.   F If, *at the time of the QIO* a drive is a member of a shadow set, then) any error on that drive will be reported.   ? * Assuming that reads preferentially go to local drives if they  have a short queue length.   --  < 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: Fri, 2 Aug 2002 19:35:53 +0000 (UTC), From: lewis@mazda.mitre.org (Keith A. Lewis); Subject: Re: Can ANYONE explain HP's rationale on this one? . Message-ID: <aiemuo$11f$1@newslocal.mitre.org>   "John Smith" <a@nonymous.com> writes in article <Rnx29.5279$wh1.2646@news01.bloor.is.net.cable.rogers.com> dated Fri, 02 Aug 2002 15:17:05 GMT: M >Dell is thinking about getting into the printer business. In retaliations HP   B Can you explain what this has to do with the VMS operating system?  J If the answer is anywhere between "nothing" and "HP sells both" then wouldK you kindly STFU until you have a subject that is on-topic here?  Thank you.   E I would have e-mailed this but couldn't figure out your addy from the 
 article.    + --Keith Lewis              klewis$mitre.org > The above may not (yet) represent the opinions of my employer.   ------------------------------  # Date: Fri, 02 Aug 2002 23:52:30 GMT   From: "Bill" <billmuy@attbi.com>; Subject: Re: Can ANYONE explain HP's rationale on this one? . Message-ID: <2XE29.130348$uh7.20947@sccrnsc03>  9 "Keith A. Lewis" <lewis@mazda.mitre.org> wrote in message ( news:aiemuo$11f$1@newslocal.mitre.org...1 > "John Smith" <a@nonymous.com> writes in article L <Rnx29.5279$wh1.2646@news01.bloor.is.net.cable.rogers.com> dated Fri, 02 Aug 2002 15:17:05 GMT:L > >Dell is thinking about getting into the printer business. In retaliations HP > D > Can you explain what this has to do with the VMS operating system? >   E From his last paragraph, it seems that he now expects HP's enterprise I business, presumably VMS, to subsidize its printer business by taking the  hit for the lost revenue!!!!   Bill   ------------------------------  * Date: Fri, 2 Aug 2002 18:58:19 +0000 (UTC), From: lewis@mazda.mitre.org (Keith A. Lewis)& Subject: Re: Compression on DLT backup- Message-ID: <aiekob$uu$1@newslocal.mitre.org>   z Virginia Rogers <vrogers@umich.edu> writes in article <3D493708.7274C648@umich.edu> dated Thu, 01 Aug 2002 09:26:32 -0400:Q >My question is, why can I not fit more than about 30Gb on one tape?  I'm using a P >DLT IV tape.  It doesn't seem to make any difference whether I have compressionQ >set or not (either with the button on the front panel of the drive, or using the L >/media_format=compaction qualifier with the INIT and BACKUP commands).  TheP >files that I'm backing up are image files which should be able to be compressedP >(using 'compress' on unix I can compress an image file by 40%).  I'm backing upH >35GB disks and would like to be able to fit the whole disk on one tape.  F Sometime around VMS 7.2 the /MEDIA=COMPACTION flag broke in the BACKUPF utility.  We use a simple workaround -- MOUNT/FOREIGN/MEDIA=COMPACTIONH before doing the BACKUP command.  If the tape is already mounted, BACKUP# doesn't change the compaction flag.   + --Keith Lewis              klewis$mitre.org > The above may not (yet) represent the opinions of my employer.   ------------------------------   Date: 2 Aug 02 20:13:29 +0200 ) From: p_sture@elias.decus.ch (Paul Sture) - Subject: Re: Help - Problem with keys in TPU. ) Message-ID: <6P242xwCYLa$@elias.decus.ch>   ] In article <01KKTOQIQXEQ000UPX@tgmail.tg.nsw.gov.au>, paddy.o'brien@zzz.tg.nsw.gov.au writes:  > David J. Dachtera wrote: >  >>> "Kaledas, Ronald" wrote: >>> I >>> Actually, com files only need "E" access for someone to run them, not J >>> "R".  Read access allows non-priv users to copy and type the com file, >>> Execute-only does not. >>F >>Um, better check that. Last time I tried that, RE access was needed.G >>(Unlike UN*X, you need read access to DCL proc.'s in order to execute H >>them using "@" where on UN*X, x permission will do.) Don't confuse DCL/ >>command indirection with the image activator.  > M > I cannot check this without setting myself up with a new account, since my  Q > development account also has READALL.  However, I have some memory of problems  B > that users experienced and we came to the following conclusions. > 7 > 1).  A .com file only needs E if on the same cluster. 6 > 2).  A .com file needs RE if on a different cluster. > A > For the purpose above, "cluster" also implies a single machine.  > Q > 3).  If $ set verify is on, I forget what happens for 1).  It might need RE to  ) > even run, or it might run without echo.  > P > If someone can correct or affirm my memory, I'd be interested, otherwise I'll - > create an account over the weekend to test.   H I've just tested 1 on a standalone system and it's executes fine, givingN RME-E_PRV on a TYPE command. This from an account with only TMPMBX and NETMBX. __
 Paul Sture Switzerland    ------------------------------   Date: 2 Aug 02 20:35:10 +0200 ) From: p_sture@elias.decus.ch (Paul Sture) - Subject: Re: Help - Problem with keys in TPU. ) Message-ID: <E1gzIhOP6R5h@elias.decus.ch>   ] In article <01KKU0G308UQ000U62@tgmail.tg.nsw.gov.au>, paddy.o'brien@zzz.tg.nsw.gov.au writes: J > Dave Weatherall wrote (again with snips), referencing my post and David 
 > Dachtera's:  > H >>I seem to remember years ago trying to change some of my .COMS to W:E. >>G >>As has been said, the @T worked OK. Where I had problems was calling  G >>another .COM from the first level. i.e. T.COM contained @S. If S.COM  A >>was also W:E then it could not be executed and T failed with a  D >>privilege violation. That was under VMS 5.n. I've never tested it  >>again since.   >  > O > That's an interesting one.  I'll set myself up a very bland account over the  N > weekend and test some of these.  (Unless Hoff or some colleague can jump in / > and tell us definitively what the rules are).  > C > What has also come to mind is that .exe files need RE if between   > clusters/machines. > N > The situation that I was remembering occurred when I wanted a user to check G > out my development executable, which involved a .COM across machines.  >   Doh! To expand my previous test:   $ dir/prot x.com   X.COM;4              (RWED,E,,) $ X.COM;3              (RWED,RWED,RE,)$ X.COM;2              (RWED,RWED,RE,)$ X.COM;1              (RWED,RWED,RE,)   Total of 4 files.  $ @x hello 
 $ ty x.com> %TYPE-W-OPENIN, error opening USER_DISK:[TEST]X.COM;4 as input? -RMS-E-PRV, insufficient privilege or file protection violation  $ @mynode"test somepassword"::x C %DCL-E-OPENIN, error opening MYNODE"test password"::X.COM; as input ? -RMS-E-PRV, insufficient privilege or file protection violation  $   ; From which I conclude that DECnet itself wants read access.    This is on Alpha V7.3.     hello        __
 Paul Sture Switzerland    ------------------------------  % Date: Fri, 02 Aug 2002 12:36:21 -0700 0 From: Mark Berryman <Mark.Berryman@Mvb.Saic.Com>- Subject: Re: Help - Problem with keys in TPU. , Message-ID: <3D4A7CC5.7BD16417@Mvb.Saic.Com>  & paddy.o'brien@zzz.tg.nsw.gov.au wrote: > I > Dave Weatherall wrote (again with snips), referencing my post and David 
 > Dachtera's:  > I > >I seem to remember years ago trying to change some of my .COMS to W:E.  > > G > >As has been said, the @T worked OK. Where I had problems was calling G > >another .COM from the first level. i.e. T.COM contained @S. If S.COM A > >was also W:E then it could not be executed and T failed with a D > >privilege violation. That was under VMS 5.n. I've never tested it > >again since.  > N > That's an interesting one.  I'll set myself up a very bland account over theM > weekend and test some of these.  (Unless Hoff or some colleague can jump in / > and tell us definitively what the rules are).  > B > What has also come to mind is that .exe files need RE if between > clusters/machines. > M > The situation that I was remembering occurred when I wanted a user to check G > out my development executable, which involved a .COM across machines.   G Well, I certainly don't claim to be Hoff but I can give an answer here.   F DCL only needs E access to execute a command procedure.  As long as itF is DCL opening the command procedure, E access is the minimum requiredG and is true regardless of whether the procedure being invoked is nested  or not.   6 When a command procedure is invoked via DECnet (.e.g.,A @node::procedure.com) then DCL's attempt to open the command file F invokes FAL to obtain the file.  FAL (the DECnet File Access protocol)F must be able to Read the command procedure on the remote node in orderA to transfer it to the local node for execution.  For this reason, G whatever account FAL is running under on the remote need needs R access D to the command file in question (but doesn't care if E is present or not).   A So, as long as DCL can get to the file directly, only E access is E needed.  If its being read over the network, then R access is needed.   
 Mark Berryman  Mark.Berryman@Mvb.Saic.Com   ------------------------------  * Date: Fri, 2 Aug 2002 19:24:41 +0000 (UTC), From: lewis@mazda.mitre.org (Keith A. Lewis). Subject: Re: Help MRU! Robot is not responding. Message-ID: <aiem9p$10r$1@newslocal.mitre.org>  { "Steven Xie" <r33300@email.mot.com> writes in article <aicmqr$t1k$1@newshost.mot.com> dated Fri, 2 Aug 2002 09:21:02 +0800: I >I have one OpenVMS box (ES40, Vms 7.2-1, Media Robot Utility V1.4-1). On K >this system I have one DLT891 tape library attached and I'm try to use MRU K >to control the tapes. I have created the device GKA501 (The tape device is F >MKA500), However it doesn't work. The error message shows like below. > E >ROBOT gka501: is not responding: Robot illegal request. SENSE KEY:5,n >ASC:25,ASCQ:0.n >iL >I have also created a device named gka500, this one shows "device offline". >T. >Dose anybody there has the experience before?  J I think that's the same library as I have -- 6 SCSI connectors on the backD for 3 possible devices (2 tape drives and the robot).  The pairs are< labelled "Library" (that's the robot), "DLT 1", and "DLT 2".  I My setup has a long SCSI cable going from the Alpha to "Library", a shortmJ cable from "Library" to "DLT 1", and a terminator on the remaining "DLT 1"H connection.  Because the robot does't use much bandwidth, it can share a5 SCSI bus with the DLT without a performance penalty. o  I I used the console to make sure the SCSI ID of the DLT was different fromrI that of the robot ("library"), then did "MC SYSMAN IO AUTO".  Both the MKI and GK devices were detected.-  L There's also a console setting that disables the robot completely, don't set
 that!  :^)  , And don't be afraid to RTFM once in a while.  + --Keith Lewis              klewis$mitre.orgs> The above may not (yet) represent the opinions of my employer.   ------------------------------   Date: 2 Aug 02 20:41:23 +0200@) From: p_sture@elias.decus.ch (Paul Sture) * Subject: Re: Hex to decimal conversion dcl) Message-ID: <0xwcK$fL$NxZ@elias.decus.ch>t  ] In article <01KKU2QKYE02000UZH@tgmail.tg.nsw.gov.au>, paddy.o'brien@zzz.tg.nsw.gov.au writes:n > Joseph "Sepp" Huber wrote: > J >>Just for the lazy, here is the dcl code I use as a command "cvt number": >> >>$ if p1 .eqs. "" a	 >>$ then t7 >>$ write sys$output "converts numbers specified in p1"t >>$ else >>$ Decimal = 'P1' >>$ SH SYM Decimal	 >>$ endif  >>I >>Yould refine it by checking the symbol p1 is really of integer type ...c > O > I use my DECW calculator :-)  But your solution gives all three bases in one   > hit. >   H I suspect everyone has assumed the questioner knows about the %X prefix:  L $ write sys$output %X99 ! substitute 99 with the number you wish to convert.   and it's %O for octal numbers. __
 Paul Sture Switzerlandk   ------------------------------  * Date: Fri, 2 Aug 2002 19:51:10 +0000 (UTC), From: lewis@mazda.mitre.org (Keith A. Lewis)* Subject: Re: Hex to decimal conversion dcl. Message-ID: <aienrd$11f$2@newslocal.mitre.org>   tarunm_2000@yahoo.com (tmrana) writes in article <e8f11ce1.0208020150.7137b969@posting.google.com> dated 2 Aug 2002 02:50:42 -0700:rF >Can anyone tell me any dcl command to convert a hexadecimal number to? >decimal number. or any system routine in vax for that matter...  " $ inquire hex "Give it to me baby" $ write sys$Output %x'hex'  F This works for 32-bits and less (but the high-order bit becomes the 2s complement sign).t  + --Keith Lewis              klewis$mitre.orgs> The above may not (yet) represent the opinions of my employer.   ------------------------------  % Date: Fri, 02 Aug 2002 20:56:11 +0200P& From: Michael Joosten <joost@c-lab.de>' Subject: Re: Low-level format SCSI diskt$ Message-ID: <3D4AD5CB.59E2@c-lab.de>   Jan-Erik Sderholm wrote:M >  > Michael Joosten wrote: > > H > > With Linux, you could try 'sformat'. But you have to take a break toC > > understand the options and read the manpage. It's use is littleA > > bizarre... >  > You mean Linux is ?i > :-)p  D Compared with the normal command line argument syntax of UNIX tools, sformat IS worse/wierder ! -- @* Michael Joosten, SBS C-LAB, joost@c-lab.de* Fuerstenallee 11, 33094 Paderborn, Germany, Phone: +49 5251 606127, Fax: +49 5251 6060658 C-LAB is a cooperation of University Paderborn & SIEMENS   ------------------------------   Date: 2 Aug 2002 16:11:06 -0700i1 From: keithparris_NOSPAM@yahoo.com (Keith Parris)t. Subject: Re: No Andrew, slowaris can't be VMS!< Message-ID: <cf15391e.0208021511.77e944a@posting.google.com>  r "Bill Todd" <billtodd@metrocast.net> wrote in message news:<IAj29.54531$cm.1852387@bin3.nnrp.aus1.giganews.com>... > expecting them to throw awayN > HP-UX's existing clustering facilities (such as they are) and *replace* themK > with something better (but different) is not all that much more realisticuH > than expecting them to throw away Itanic and replace it with something! > better (but different:  Alpha).b  > I'm only just learning about HP-UX clustering (Peter Weygant's9 'Clusters for High Availability' book from HP Press, ISBNsF 0-13-089355-2), but MC/Service Guard seems to provide roughly the sameE "fail-over" clustering as ASE did on Tru64: storage accessible to twooB systems, but in an active/standby configuration (or what is calledE active/active, but which is really just different applications active F simultaneously on different nodes, but with each one in standby on theA opposite node).  MC/Service Guard OPS Edition supports Oracle OPSdF (parallel access to the storage is allowed because Oracle does its own DLM-style coordination).  B When Compaq introduced TruClusters in 5.0[a], instead of ASE beingE "thrown away", Compaq provided what from what I've read & heard was aeE smooth interoperability/migration story for ASE users, and so I would E expect MC/Service Guard users to get no less smooth a transition patha; from HP when TruCluster features start to show up in HP-UX.s  D Sure, giving 2004 as a date only gives them another 2.5 years to get6 TruClusters into HP-UX, but it's not like they have to? reverse-engineer the features or try to mimic the technology ofaC another vendor -- they have all the original source code, they havelE the engineers, they have the expertise, plus the recent experience of D exactly what it takes to incorporate clustering features into Unix. 8 If anything, publicly stating such a short timeframe for@ implementation stresses the critical importance that HP gives to getting TruClusters into HP-UX.a  D And even if, as you suspect, someone is naive and underestimated the= technical challenges involved, would that really constitute anE disaster?  Alpha will continue to be sold until people stop buying itaF (estimated at this point to be 2006 at the earliest) and supported forA at least 5 years after the last sale, and significant releases ofsC Tru64/TruCluster code are planned for 2003 and 2004 (and more couldo, certainly be produced if things dragged on).: ----------------------------------------------------------: Keith Parris | parris <at> DECUServe <dot> decus <dot> org   ------------------------------  % Date: Fri, 02 Aug 2002 13:00:07 -0400f( From: David Froble <davef@tsoft-inc.com>0 Subject: Re: OpenVMS comes to Itanium - Roadshow, Message-ID: <3D4ABA97.9020604@tsoft-inc.com>   Jan-Erik Sderholm wrote:    > Larry Kilgallen wrote: > 1 >>The Oracle marketing attitude came across quitea2 >>clearly however -- "Is there anybody in the room >>still using Oracle Rdb?".o >> >  > I hope there was some... >  > Jan-Erik Sderholm >   # So what's wrong with this question?   Q You have product 'A' which needs very little user intervention, and requires few A' or no in-house people to keep it going.   P You have product 'B' which needs a staff of high priced 'DBA's and such to keep 	 it going.i  M You have a meeting for customers, attended more by high priced IT staff than 29 users, and ask what is being used out there in the world.e  Q The consumer advocates thought that 'bait and switch' was bad.  These guys don't e even bother with the bait.  P If Oracle has any sense, they will base their actions, with regard to continued O support, on revenue and profit, not some show of hands in a 'packed' audience. eO The sad thing is the recent absense of 'sense' in many IT decisions.  If there  N is good profit, real sense would be to try to expand the usage that generates  such profit.  P And then, if Oracle doesn't give proper respect to it's RDB customers, I'm sure > IBM will be quite happy to talk to them.  You want that Larry?   Dave   ------------------------------  # Date: Sat, 03 Aug 2002 00:05:44 GMTKL From: winston@SSRL.SLAC.STANFORD.EDU ("Alan Winston - SSRL Admin Cmptg Mgr")0 Subject: Re: OpenVMS comes to Itanium - Roadshow8 Message-ID: <00A11DCF.4D5A39D6@SSRL04.SLAC.STANFORD.EDU>  l In article <gCx29.5308$wh1.2205@news01.bloor.is.net.cable.rogers.com>, "John Smith" <a@nonymous.com> writes: >bG >"Phillip Helbig" <HELBPHI@sysdev.deutsche-boerse.com> wrote in messagei6 >news:01KKTTTFP02Y96Z9MP@sysdev.deutsche-boerse.com... >>F >> There might not have been many people in the room, but Rdb is stillG >> going strong (and getting significant new features).  Maybe Not THATnJ >> many sites and not THAT many people at each site (but, hey, it's a goodK >> product so not that many are needed), but they tend to be sites which do:6 >> a lot of work where there really is no alternative. >cI >All that may be true for the sites that use it, but at some point Oracle4M >will probably say, "That's it for Rdb. We'll give you full credit to migratei8 >to Oracle Xi on *ix. Sorry, that's the best we can do."  M Oracle charges plenty for Rdb licenses and support. They're making no visiblecM effort to fold the development organization (which is some 3k miles away from,E the Dark Towers in Redwood Shores) into the Oracle Server developmentAN organization, and they'd have to expect to lose quite a few of the New England' developers if they wanted them to move.'  K Why would it be a win for Oracle Corp to turn the lights out on Rdb?  While G the "it's stupid to stop a revenue-generating product" argument doesn'tnE carry much weight in arguing about what HP/Compaq will do, I've neveruJ noticed Larry Ellison being stupid about this kind of thing.  (My personalC experience of him has been that he's an  arrogant jerk, but that's e different from being stupid.)t  J Rdb is strongly entrenched at the same kinds of outfits that _have_ to useI VMS, like DirecTV.  Unless the plug gets pulled on VMS completely, Oracle2 has a captive audience there.@   -- Alan.  O ===============================================================================20  Alan Winston --- WINSTON@SSRL.SLAC.STANFORD.EDUM  Disclaimer: I speak only for myself, not SLAC or SSRL   Phone:  650/926-3056iM  Physical mail to: SSRL -- SLAC BIN 69, PO BOX 4349, STANFORD, CA  94309-0210 O ===============================================================================l   ------------------------------   Date: 2 Aug 02 21:13:30 +0200y) From: p_sture@elias.decus.ch (Paul Sture)sE Subject: Re: Robust exception handler context in C (well, C++ really)a) Message-ID: <I2zosHePp8iK@elias.decus.ch>   c In article <FRyE8FPe3j4D@eisner.encompasserve.org>, Kilgallen@SpamCop.net (Larry Kilgallen) writes:tV > In article <87wur95kvx.fsf@Alethion.systasis.net>, sasadmin <jec@nospam.net> writes:2 >> Kilgallen@SpamCop.net (Larry Kilgallen) writes: > G >>> But looking at Chapter 15 (Exception Handling) of The Annotated C++dD >>> Reference Manual by Ellis and Stroustrup I see try-block only asJ >>> related to a throw-expression.  I do not have the luxury of specifyingI >>> how the exception is generated -- it comes from a general purpose VMSc= >>> RTL routine (LIB$FIND_IMAGE_SYMBOL, if you must know :-). G >> The topic of exception handling occupies a statistically significant J >> portion of /The C/C++ Users Journal/ web site. I appreciate that you'reG >> on an hourly contract; http://www.cuj.com is an invaluable referenceeI >> for the problem you're trying to solve. And yes, I do subscribe to thea >> magazine. > B > I would suspect that source might describe methods to program inB > C and/or C++, but finding a method compatible with non-C signals7 > from LIB$FIND_IMAGE_SYMBOL seems unlikely over there.j > * > Google seems to agree, as searching for: >  > 	vms signal site:cuj.com > @ > provides one page talking about signal-to-noise ratios and one. > talking about "generic launching of VMs" :-)  J Larry, you might find "A Critique of C++" a useful read, if only to become% acquainted with some of its pitfalls.y  0 It is available in a HTML, PS and PDF formats at$ http://www.elj.com/cppcv3/s3/#s03-11 __
 Paul Sture Switzerland>   ------------------------------   Date: 2 Aug 2002 15:47:07 -0600 - From: Kilgallen@SpamCop.net (Larry Kilgallen)aE Subject: Re: Robust exception handler context in C (well, C++ really)v3 Message-ID: <36eCB+WF+HTd@eisner.encompasserve.org>s  U In article <I2zosHePp8iK@elias.decus.ch>, p_sture@elias.decus.ch (Paul Sture) writes:e  L > Larry, you might find "A Critique of C++" a useful read, if only to become' > acquainted with some of its pitfalls.h > 2 > It is available in a HTML, PS and PDF formats at& > http://www.elj.com/cppcv3/s3/#s03-11  K I printed that a long time ago, so I will have a copy if the Internet dies.u   ------------------------------  # Date: Fri, 02 Aug 2002 19:08:49 GMT 1 From: "Terry C. Shannon" <terryshannon@attbi.com>m Subject: Today's KLEZ AlertD> Message-ID: <5NA29.262046$uw.150566@rwcrnsc51.ops.asp.att.net>  F As part of their overpriced and incompetent service, the cable guys atK ATTBI.COM sent me the following copy of KLEZ today. It allegedly originated]
 from JTCARNEYt" Return-Path: <jkrccoin@gsinet.net>E Received: from boston3.g4.net ([216.177.0.33]) by rwcrgwc54.attbi.comEG           (InterMail vM.4.01.03.34 201-229-121-134-20020625) with ESMTPVJ           id <20020802185428.XHEO22288.rwcrgwc54.attbi.com@boston3.g4.net>F           for <terryshannon@attbi.com>; Fri, 2 Aug 2002 18:54:28 +0000F Received: from Ypiru (4158.mht.nh.dsl.customer.G4.NET [216.177.21.60])<  by boston3.g4.net (8.11.3/8.11.3) with SMTP id g72IsKQ64442C  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)6 Message-Id: <200208021854.g72IsKQ64442@boston3.g4.net>% From: jtcarney <jtcarney@comcast.net>n To: terryshannon@attbi.com6 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     H KLEZ stuff deleted of course. Anyone interested in joining me in a class= action suit against ATTBI.COM? Either way, be VERY careful...    -- Terry C. Shannon+ Consultant and Publisher, Shannon Knows HPCc8 Director, Technical Communications, Science Medicus Inc.% Director at Large, Encompass US, Inc.  terryshannon@attbi.com http://www.openvms.org   ------------------------------  # Date: Fri, 02 Aug 2002 21:44:26 GMT 1 From: "Terry C. Shannon" <terryshannon@attbi.com>r Subject: Re: Today's KLEZ Alert / Message-ID: <W2D29.228633$Wt3.187591@rwcrnsc53>,  4 "Elliott Roper" <elliott@yrl.co.uk> wrote in message, news:020820022228092208%elliott@yrl.co.uk...I > In article <5NA29.262046$uw.150566@rwcrnsc51.ops.asp.att.net>, Terry C.A) > Shannon <terryshannon@attbi.com> wrote:o >uJ > > As part of their overpriced and incompetent service, the cable guys at7 > > ATTBI.COM sent me the following copy of KLEZ today.m >d > <snip> > >nL > > KLEZ stuff deleted of course. Anyone interested in joining me in a classA > > action suit against ATTBI.COM? Either way, be VERY careful...l > >eA > C'mon Terry, You'll get nothing. If you are receiving mail on aoE > BillyBox with BillyMail, the court should decimate your damages fort > contributory negligence. >F& > One of the reasons we use VMS innit?  L Yep. A damn shame Bill Strecker rolled over and took Microsoft's first offerL in '95--Intel server-side parity, NOT client-side parity. This is one of the/ Top Ten Stupid DEC Pet Tricks of the 1990s! ;-},   ------------------------------  % Date: Fri, 02 Aug 2002 22:28:09 +0100 ' From: Elliott Roper <elliott@yrl.co.uk>r Subject: Re: Today's KLEZ Alert)2 Message-ID: <020820022228092208%elliott@yrl.co.uk>  G In article <5NA29.262046$uw.150566@rwcrnsc51.ops.asp.att.net>, Terry C.o' Shannon <terryshannon@attbi.com> wrote:a  H > As part of their overpriced and incompetent service, the cable guys at6 > ATTBI.COM sent me the following copy of KLEZ today.    <snip> > J > KLEZ stuff deleted of course. Anyone interested in joining me in a class? > action suit against ATTBI.COM? Either way, be VERY careful...r > ? C'mon Terry, You'll get nothing. If you are receiving mail on aeC BillyBox with BillyMail, the court should decimate your damages for  contributory negligence.  $ One of the reasons we use VMS innit?   ------------------------------    Date: 03 Aug 2002 00:39:10 +0800, From: Paul Repacholi <prep@prep.synonet.com>8 Subject: Re: Two-headed hard drive as a security bandaid- Message-ID: <87vg6t9pw1.fsf@prep.synonet.com>   3 keithparris_NOSPAM@yahoo.com (Keith Parris) writes:p  t > karcher@thuria.waisman.wisc.edu (Carl Karcher) wrote in message news:<25JUL02.16002420@thuria.waisman.wisc.edu>...  D > > Tokyo-based company Scarabs has developed a prototype hard driveC > > with two heads, one a read-write head and the other a read-only'	 > > head.b  w& > Connor made a dual-headed drive: see; > http://www.pcguide.com/ref/hdd/op/actMultiple-c.html (and C > http://www.fdml.com/03_mechanical.html for a description of theiro
 > patent).  tE > There's some (at least academic) interest in multiple-actuator diskd: > drives because although disk drive capacities have grownD > dramatically and data transfer rates have grown significantly over< > the years, as bit density and rotational speeds (RPM) haveB > increased, overall disk access times have not improved nearly as@ > fast as, for example, CPU speeds.  In fact, if you look at the@ > number of I/Os per second you can do per gigabyte of data, theE > numbers have actually gotten worse over the past couple of decades,t > rather than better.H  A Seagate did a dual port SCSI drive, but I don't know if you couldoF write protect on a per port basis. IBMs monster drive where dual armed so as to get higher throughput.   - ::note to self, ask Lynn on afc for details::y   -- t< Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda.i@                                              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: Fri, 2 Aug 2002 21:24:45 +0200" From: "Hans Vlems" <hvlems@iae.nl> Subject: Re: VAX Hardware ID6 Message-ID: <aiem9t$13s511$1@ID-143435.news.dfncis.de>  K There is a thing called SID, that might be the serialno you're looking for:m" $ write sys$output f$getsyi("SID")  	 318776834:  D The hardware model type is (was) just the way DEC called the system.K The rest of the output is quite normal for a VAX server (was it produced by0< a VMS kit that ran on the VAX simh simulator by any chance?)  G A "B" license is not very common, which is probably the reason that Bob  Supnik got the 3900's microcode.r   Hans  6 "Fausto Saporito" <fausap@unina.it> schreef in bericht6 news:2348b30e.0208020607.b35afa2@posting.google.com...* > "vlems" <hvlems@iae.nl> wrote in message2 news:<aidm5i$13amjf$1@ID-143435.news.dfncis.de>... > > $ sh lic/charges > > . > > VMS/LMF Charge Information for node CHLOOR > >o: > > This is a VAXstation 4000-90A, hardware model type 475 > In my case I have: >m > $ sh lic/chargej, > VMS/LMF Charge Information for node KELVIN: > This is a VAXserver 3900 Series, hardware model type 119K > Type: A, * Not Permitted *      (VAX/VMS Capacity or OpenVMS Unlimited oro Base) 6 > Type: B, Units Required: 100    (VAX/VMS F&A Server); > Type: C, * Not Permitted *      (VAX/VMS Concurrent User) 7 > Type: D, * Not Permitted *      (VAX/VMS Workstation)dF > Type: E, Units Required: 50     (VAX/VMS System Integrated Products)8 > Type: F, Units Required: 10     (VAX Layered Products), > Type: G, * Not Permitted *      (Reserved): > Type: H, * Not Permitted *      (Alpha Layered Products)4 > Type: I, Units Required: 10     (Layered Products) >- > Is it normal?-E > In this case my CPU Serial Number is 119, I suppose. Or am I wrong?y >o > thanks in advance, > Fausto   ------------------------------  $ Date: Fri, 2 Aug 2002 21:41:09 +0200" From: "Hans Vlems" <hvlems@iae.nl> Subject: Re: VAX Hardware ID6 Message-ID: <aien8l$13j7e2$1@ID-143435.news.dfncis.de>  H A note on the system serial number: on VAX systems other than the 11/7xxK series there is no way the O/S has access to the number that's on the labelt outside the box.F The 11/780 and 11/785 (and probably the 11/782) had unique sn's in the	 hardware.aL The 11/750 as well, but conveniently accessible for customers thru a bank of dipswitches.  3 For emulators, others have answered that in detail.i   Hans   ------------------------------   Date: 2 Aug 02 21:57:47 +0200G) From: p_sture@elias.decus.ch (Paul Sture)i Subject: Re: VAX Hardware ID) Message-ID: <5GnMdGoqmZ$W@elias.decus.ch>m  [ In article <aien8l$13j7e2$1@ID-143435.news.dfncis.de>, "Hans Vlems" <hvlems@iae.nl> writes:yJ > A note on the system serial number: on VAX systems other than the 11/7xxM > series there is no way the O/S has access to the number that's on the label  > outside the box.H > The 11/780 and 11/785 (and probably the 11/782) had unique sn's in the > hardware.rN > The 11/750 as well, but conveniently accessible for customers thru a bank of > dipswitches. >mO Aha, a mystery explained. I often wondered why all the 750s I worked on had ther same SID :-)     5 > For emulators, others have answered that in detail.o >  __
 Paul Sture Switzerlandp   ------------------------------   End of INFO-VAX 2002.424 ************************