1 INFO-VAX	Thu, 11 May 2006	Volume 2006 : Issue 261       Contents:( 111 Alphaserever Memory Modules for sale Re: Compressing backup file  Re: Compressing backup file P Re: H P To Launch Multi Million Dollar Ad Campaign For The PC [WASRe:OT: Intels  Job Posting - Cobol Programmers  Re: New VAX Problem  Re: New VAX Problem  Re: New VAX Problem * Re: Reading 8mm tapes of an unknown format* Re: Reading 8mm tapes of an unknown format Re: SGI files for chapter 11 Re: SGI files for chapter 11 RE: SGI files for chapter 11 Re: SGI files for chapter 11 Re: SGI files for chapter 11 Re: SGI files for chapter 11 Re: SGI files for chapter 11M Re: This post will self-destruct in 10secs (Was Re: X windows  vulnerability) F Re: We need a recommendation of good VMS backup (non-library) softwareF Re: We need a recommendation of good VMS backup (non-library) softwareF Re: We need a recommendation of good VMS backup (non-library) softwareF Re: We need a recommendation of good VMS backup (non-library) softwareP Re: We need a recommendation of good VMS backup (non-library) software softwaresB Re: XtRemoveTimeOut() with value of 0 accvios under 7.3-2, but notB Re: XtRemoveTimeOut() with value of 0 accvios under 7.3-2, but notB Re: XtRemoveTimeOut() with value of 0 accvios under 7.3-2, but notP Re: XtRemoveTimeOut() with value of 0 accvios under 7.3-2, but not under 7.1-2 uP Re: XtRemoveTimeOut() with value of 0 accvios under 7.3-2, but not under 7.1-2 uP Re: XtRemoveTimeOut() with value of 0 accvios under 7.3-2, but not under 7.1-2 u  F ----------------------------------------------------------------------    Date: 11 May 2006 03:53:43 -0700 From: vanjkos@gmail.com 1 Subject: 111 Alphaserever Memory Modules for sale B Message-ID: <1147344823.836747.51640@u72g2000cwu.googlegroups.com>   Hi to everyone, @ I have some memory modules for Alphaservers to sell,if anyone isC interested please give me your e-mail address so I can send you the 5 images and information about them(photos include part  numbers,brand,model numbers...) F These modules were dismissed by the company I work in,and they are allD working,but you have the right to check it. :-) In all there are 111G (one hundred eleven) modules,by Samsung,Hyunday,Mt USA,Nec,Sec,and they @ should all be in "cuts" of 256MB,you should see it from the code printed on the memory chips.     Greetings,Vanjkos.   ------------------------------  % Date: Thu, 11 May 2006 05:52:30 -0700 # From: "Tom Linden" <tom@kednos.com> $ Subject: Re: Compressing backup file) Message-ID: <op.s9d0psapzgicya@hyrrokkin>   H On Fri, 05 May 2006 10:43:36 -0700, Phillip Helbig---remove CLOTHES to  . reply <helbig@astro.multiCLOTHESvax.de> wrote:  @ > In article <1146849711_3899@sp6iad.superfeed.net>, Kevin Handy > <kth@srv.net> writes:  > < >> Anyone familiar with doing compression on the a VAX, with= >> regards to the speed? Would gzip or bzip2 be better/faster * >> (which would probably lose attributes)? > I > If you need to compress and save file attributes, ZIP is the way to go. # > Get the latest, greatest version.  > G > Why not stick a faster machine with a big disk in the cluster and use & > that for backups and/or compression? > F Well I experimented with a large saveset, but had to use gzip, since  
 zip2.31 isH currently limited to 4GB,  and it compressed 13.7 GB to 6.2  and it tookJ about 2 1/2 hours on an XP1000 500MHz over 1GBit fibrechannel to an HSG80.J I was hoping to get it to a size so I could burn it on a DVD.  It would beK nice to have a /COMPRESS qualifier on backup.  Is DVD supported as output    deviceE for backup on 8.3?  If so, I suppose it would also need a qualifier   
 indicating whether to burn CD or DVD.   ------------------------------  + Date: Thu, 11 May 2006 11:41:28 -0500 (CDT) * From: sms@antinode.org (Steven M. Schweda)$ Subject: Re: Compressing backup file2 Message-ID: <06051111412835_2020743C@antinode.org>  # From: "Tom Linden" <tom@kednos.com>   H > Well I experimented with a large saveset, but had to use gzip, since   > zip2.31 is" > currently limited to 4GB,  [...]  F    More like 2GB, except on a very old VAX version (with VAX C).  BETAE source kits for large-file-capable UnZip 6.00c and Zip 3.0e should be 
 available at:   2       ftp://ftp.info-zip.org/pub/infozip/OLD/beta/  G Aside from an occasional spurious run-time warning from the UnZip, they B seem to be pretty reliable.  (Any problems which don't mention "76G bytes" should be reported promptly.)  The real release could be getting  closer.    > Is DVD supported as output   > device > for backup on 8.3?      Directly?  I doubt it.   H ------------------------------------------------------------------------  3    Steven M. Schweda               sms@antinode-org 4    382 South Warwick Street        (+1) 651-699-9818    Saint Paul  MN  55105-2547    ------------------------------  % Date: Thu, 11 May 2006 03:30:42 -0400 ( From: Bill Todd <billtodd@metrocast.net>Y Subject: Re: H P To Launch Multi Million Dollar Ad Campaign For The PC [WASRe:OT: Intels  = Message-ID: <jYqdnRibUZdpev_Z4p2dnA@metrocastcablevision.com>    Dan Notov wrote: > Bill Todd wrote: >> Dan Notov wrote:  >>> Bill Todd wrote: >>>> Dan Notov wrote:  >>>> >>>> ... >>>>= >>>>> HP has grabbed market share from Dell in the PC market.  >>>>G >>>> Please provide a credible source for this 'fact':  I think I read  I >>>> recently that Dell's Q1 growth was about the same as that which you  J >>>> report for PSG, but the items in the relevant market baskets may not  >>>> have been identical.  >>>>I >>>> Of course, Dell continues to make far higher *profits* on its sales   >>>> than HP does in any event.  >>>> >>>> - bill J >>> ...Until they warned the street that they will miss their 1Q earnings ' >>> estimates by 3-5 cents per share...  >>>  >>> About market share numbers: 9 >>> http://biz.yahoo.com/ap/060419/pc_shipments.html?.v=2 A >>> Computer shipments rose at a faster-than-expected 13 percent  G >>> worldwide in the first quarter, and the No. 1 PC maker, Dell Inc.,  L >>> lost ground to rivals, two technology research firms reported Wednesday. >>> ... H >>> Gartner said Round Rock, Texas-based Dell saw its share of industry I >>> computer shipments decline to 16.5 percent in the first quarter from  H >>> 16.9 percent a year ago. Dell shipped 10.2 percent more PCs than it G >>> did in last year's first quarter -- a growth rate Gartner said was  3 >>> Dell's slowest since the third quarter of 2001.  >>> ... J >>> IDC put Dell's market share at 18.1 percent, down from 18.6 percent a H >>> year ago. IDC's report said Dell "may have focused on profitability @ >>> at the expense of volumes, especially in the United States." >>> E >>> IDC and Gartner both put Palo Alto, Calif.-based Hewlett-Packard  J >>> Co.'s growth at about 22 percent. Gartner estimated HP's market share 3 >>> at 14.9 percent, and IDC put it at 16.4 percent  >>E >> Interesting, but not necessarily relevant:  your previous post to  C >> which I responded referred to gross revenue, not numbers of PCs  J >> shipped, so revenue numbers (specifically, for PCs vs., e.g., servers) $ >> are the numbers in question here. >>	 >> - bill D > I never stated growth in Revenue. Only when I showed you the unit . > numbers did you ask for the revenue numbers.  G You know, when matters of easily verifiable fact are concerned, rather  H than just shooting incompetently from the hip you really ought to check A the source (especially when the source happens to have been you).   D Your original post (to which I responded), after an assertion about G market share which was not qualified as to whether it was with respect  H to unit shipments or revenue, continued by stating that PSG had doubled G its *profits* year-over-year, and then quoted several numbers from the  B Q1 report - 5 of which concerned revenues, another of which again K mentioned profit, and only one of which said anything about unit shipments.   I So in total your post mentioned revenue 5 times, profits twice, and unit  G shipments once.  I'll suggest that where I got the impression that you  7 were primarily talking about revenue is rather obvious.      Anyway, the best I can seeH > for Dell is 9.4BN in Desktop & Notebooks, vs. 7.4BN for HP's PSG unit.A > This is based on quarterly numbers for the most recent filings.   I That's better - now you just have to come up with the comparable numbers  I for last year to determine whether HP's revenue share of the market grew  E faster than Dell's (which it certainly could have, but is not yet in  
 evidence).   > E > No comment on the fact that they are going to seriously miss their  
 > numbers?  G Despite its headline, the article which you cited actually stated that  I Dell was coming in exactly at the bottom of the sales range which it had  I forecast, not missing it.  It was, however, apparently going to miss its  G earnings-per-share estimate (suggesting that it had been counting upon  F higher per-unit profit than had actually occurred - which, given that F the article said it had been 'swept up in price-cutting wars', is not  all that surprising).   H When one's profit margin is as low as PSG's, doubling it YoY is not all ; that impressive.  Let us know if it ever approaches Dell's.    - bill   ------------------------------  % Date: Thu, 11 May 2006 11:31:09 -0400 0 From: "Steven W." <vmstech-nospam@rivrgroup.com>( Subject: Job Posting - Cobol Programmers- Message-ID: <7II8g.4$PK6.789@news.uswest.net>    Hello,  a We are looking for Cobol Programmers for our Manufacturing IT department. Our plan is to continue W to use Alphas/Itanium OpenVMS systems, and migrate from RMS/Cobol towards a MySQL based e data setup. If your interested and have the needed Cobol expertise, we would be interested in hearing  from you...   = vmstech-nospam@rivrgroup.com   (you can guess what to remove)   D We are based in South Florida. Salary is based on skill/performance.   Thanks,  Steve W.   ------------------------------  + Date: Thu, 11 May 2006 10:11:27 +0000 (UTC)  From: david20@alpha2.mdx.ac.uk Subject: Re: New VAX Problem) Message-ID: <e3v2kf$510$1@news.mdx.ac.uk>   W In article <4cel72F15gvheU4@individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes: * >In article <e3t5qt$f3t$1@news.mdx.ac.uk>," >	david20@alpha2.mdx.ac.uk writes:Z >> In article <4cej0aF15gvheU2@individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes:, >>>In article <e3svjq$ddi$1@news.mdx.ac.uk>,$ >>>	david20@alpha2.mdx.ac.uk writes:` >>>> In article <44618297.C304206@teksavvy.com>, JF Mezei <jfmezei.spamnot@teksavvy.com> writes: >>>>>Bill Gunshannon wrote: N >>>>>> on the console and the fault light lit ont he VAX.  Attempts to restartK >>>>>> the system result in nothing.  The fault light comes back on and the   >>>>>> console is unresponsive.  >>>>  S >>>> If this is a VAX 7000 is the yellow fault light full on, slow flashing or fast  >>>> flashing. >>>>   >>>> According to the manual at  >>>>  K >>>> http://h18002.www1.hp.com/alphaserver/vax/download/ek-7000b-op-002.pdf  >>>>   >>>>  @ >>>> Fault   Yellow    On          Fault on LSB or system IO bus >>>>  E >>>>                   Slow        Power sequencing is in progress or = >>>>                   Flash       air flow error is detected  >>>>  H >>>>                   Fast        Power system error, airflow error, orL >>>>                   Flash       keyswitch in Disable position transition + >>>>                               detected  >>>>   >>> N >>>Yeah, I found that manual after I had pushed the new box in and was lookingK >>>for boot options.  I would say Slow Flash.  What would cause an air flow K >>>error?  The fan is working (note my previous comment about sounding like K >>>a jet) because when you power it on it run at full speed for a minute or . >>>so before slowing down to normal operation. >>>  >>  J >> Section 2.6 Cooling system  of that manual has a diagram of the airflowP >> and a bit of text describing how much clearance is expected around the system8 >> (and warns not to put anything on top of the system). > H >Is there a filter in there that could be dirty and restricting airflow?A >Does it actually measure the airflow or is it temperature based?  > G According to the manual section 2.6 it has air pressure and temperature L sensors. The static air pressure sensors measure the air pressure across theH LSB card cage. If it drops below a certain level then power is disabled.E Similarly if the temperature sensor is tripped the system shuts down.   O It's a long time since I had a 7000 (and then it was a DEC 7000 AXP rather than L the VAX version ) but as I recall the blower was huge and if you opened the $ front door you could really feel it.      
 David Webb Security team leader CCSS Middlesex University       >bill  >  >-- K >Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves E >bill@cs.scranton.edu     |  and a sheep voting on what's for dinner.  >University of Scranton   | B >Scranton, Pennsylvania   |         #include <std.disclaimer.h>      ------------------------------   Date: 11 May 2006 12:10:42 GMT( From: bill@cs.uofs.edu (Bill Gunshannon) Subject: Re: New VAX Problem, Message-ID: <4cgnu2F14p8q2U1@individual.net>  ) In article <e3v2kf$510$1@news.mdx.ac.uk>, ! 	david20@alpha2.mdx.ac.uk writes: Y > In article <4cel72F15gvheU4@individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes: + >>In article <e3t5qt$f3t$1@news.mdx.ac.uk>, # >>	david20@alpha2.mdx.ac.uk writes: [ >>> In article <4cej0aF15gvheU2@individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes: - >>>>In article <e3svjq$ddi$1@news.mdx.ac.uk>, % >>>>	david20@alpha2.mdx.ac.uk writes: a >>>>> In article <44618297.C304206@teksavvy.com>, JF Mezei <jfmezei.spamnot@teksavvy.com> writes:  >>>>>>Bill Gunshannon wrote:O >>>>>>> on the console and the fault light lit ont he VAX.  Attempts to restart L >>>>>>> the system result in nothing.  The fault light comes back on and the! >>>>>>> console is unresponsive.   >>>>> T >>>>> If this is a VAX 7000 is the yellow fault light full on, slow flashing or fast >>>>> flashing.  >>>>>   >>>>> According to the manual at >>>>> L >>>>> http://h18002.www1.hp.com/alphaserver/vax/download/ek-7000b-op-002.pdf >>>>>  >>>>> A >>>>> Fault   Yellow    On          Fault on LSB or system IO bus  >>>>> F >>>>>                   Slow        Power sequencing is in progress or> >>>>>                   Flash       air flow error is detected >>>>> I >>>>>                   Fast        Power system error, airflow error, or M >>>>>                   Flash       keyswitch in Disable position transition  , >>>>>                               detected >>>>>  >>>>O >>>>Yeah, I found that manual after I had pushed the new box in and was looking L >>>>for boot options.  I would say Slow Flash.  What would cause an air flowL >>>>error?  The fan is working (note my previous comment about sounding likeL >>>>a jet) because when you power it on it run at full speed for a minute or/ >>>>so before slowing down to normal operation.  >>>> >>> K >>> Section 2.6 Cooling system  of that manual has a diagram of the airflow Q >>> and a bit of text describing how much clearance is expected around the system 9 >>> (and warns not to put anything on top of the system).  >>I >>Is there a filter in there that could be dirty and restricting airflow? B >>Does it actually measure the airflow or is it temperature based? >>I > According to the manual section 2.6 it has air pressure and temperature N > sensors. The static air pressure sensors measure the air pressure across theJ > LSB card cage. If it drops below a certain level then power is disabled.G > Similarly if the temperature sensor is tripped the system shuts down.  > Q > It's a long time since I had a 7000 (and then it was a DEC 7000 AXP rather than N > the VAX version ) but as I recall the blower was huge and if you opened the & > front door you could really feel it.  K Yeah, that describes my box.  I guess I need to open it up and see if I can M find any of these sensors.  I never found the machine room to be particularly K dusty, but then, the machine has been runningin there for a year without my " ever opening it up for a cleaning.   bill   --  J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>       ------------------------------  # Date: Thu, 11 May 2006 16:24:27 GMT , From: Hoff Hoffman <hoff-remove-this@hp.com> Subject: Re: New VAX Problem0 Message-ID: <%yJ8g.378$xM4.268@news.cpqcorp.net>   etmsreec@yahoo.co.uk wrote: E > I wouldn't have expected a year in a clean-ish machine room to be a F > problem.  Depends I guess on how hard a life they had before you got > them Bill.    F    Sensor-related problems are a classic spring-time event with smoke E detectors, for instance, and often involving pollen and bugs.   (And  E bugs just love to over-winter or to nest in nice, warm, dark places.  G Yes, I know; code bugs like to nest in the same sorts of places within  D source code. :-)  Year-round problems include construction dust and G concrete dust and the on-going accretion of the usual biologics (hair,  H dead skin cells, lint, etc) that occurs within a computer.  Pitot tubes A almost inevitably become plugged, whether the tubes are inside a  G computer or mounted on an aircraft.   A couple of times a year, I open  F up several of the local boxes and blow the fuzz out of the heat sinks.  F    The classic hardware preventive maintenance (PM) visit did serve a @ very useful purpose.  Even in an apparently-clean computer room.  H    And the fans sometimes fail, too -- sometimes the fault is for real. F   (That detection is central to the purpose of the sensor, of course.)   ------------------------------  % Date: Thu, 11 May 2006 08:25:13 +0200 ( From: Michael Kraemer <M.Kraemer@gsi.de>3 Subject: Re: Reading 8mm tapes of an unknown format / Message-ID: <e3ulbv$3fr$03$1@news.t-online.com>    Ken Robinson schrieb: E > We've gotten a request to read old data (circa 1993) from old tapes F > (8mm). Of course the data is in an unknown format. The people in ourD > data center were able to dig up an old TTI TKZ09 tape drive (modelA > CTS-8510-DDH). I'm able to hook it up to one of our Alpha boxes I > (running v7.3-2) which does see it. I'm able to mount a test tape using G > "/foreign", but when I try to read the tape, I get nothing but parity 	 > errors.  > H > Of course there is no manual available and I was unable to find one on
 > the web. > F > The tape drive box (it's a desktop model) has 12 dip switches in the! > back. Which are set as follows:  >  > 1 1 0 0 0 1 1 1 0 1 0 1  >   , well, I can't give a conclusive advice here, just some hints.6 The other posters have pointed out that after 13 years1 the media might be bad. 13 years ago I might have B agreed with them, I always considered 8mm technology to be "crap", especially when run under VMS.< However, a couple of months ago I had to learn the opposite,, I was able to recover a 12 year old 8mm tape@ (actually an Ultrix backup), copied it to a couple of DATs first+ and then restored the Ultrix system to disk E (the system wouldn't really boot afterwards, unfortunately, but most  C probable this has other reasons, at least I could read all ancient  
 filesystems). I The drive I used was a TTI-8510 (probably similar or identical to yours), G which operates with scary noises, but it works, even after a couple of   years.= So there's hope. You could check if the media is "datagrade", > not 8mm consumer Video, in this latter case your are probably : out-of-luck, those media often fail even during recording.= You should also insert an unworn cleaning cartridge (twice if D the drive was out-of-use for many years) before trying to read/write
 "real" tapes. > I could also imagine that the jumper settings are significant,A I've seen that e.g. with DAT drives which need different settings ; for different computer models. If you're very lucky I might 2 have some info about it in one of my dust bins :-)   ------------------------------    Date: 11 May 2006 09:56:17 -0700$ From: "AEF" <spamsink2001@yahoo.com>3 Subject: Re: Reading 8mm tapes of an unknown format C Message-ID: <1147366577.007641.175120@i40g2000cwc.googlegroups.com>    Michael Kraemer wrote: > Ken Robinson schrieb: G > > We've gotten a request to read old data (circa 1993) from old tapes H > > (8mm). Of course the data is in an unknown format. The people in ourF > > data center were able to dig up an old TTI TKZ09 tape drive (modelC > > CTS-8510-DDH). I'm able to hook it up to one of our Alpha boxes K > > (running v7.3-2) which does see it. I'm able to mount a test tape using I > > "/foreign", but when I try to read the tape, I get nothing but parity  > > errors.  > > J > > Of course there is no manual available and I was unable to find one on > > the web. > > H > > The tape drive box (it's a desktop model) has 12 dip switches in the# > > back. Which are set as follows:  > >  > > 1 1 0 0 0 1 1 1 0 1 0 1  > >  > . > well, I can't give a conclusive advice here, > just some hints.8 > The other posters have pointed out that after 13 years3 > the media might be bad. 13 years ago I might have D > agreed with them, I always considered 8mm technology to be "crap",  > especially when run under VMS.> > However, a couple of months ago I had to learn the opposite,. > I was able to recover a 12 year old 8mm tapeB > (actually an Ultrix backup), copied it to a couple of DATs first- > and then restored the Ultrix system to disk F > (the system wouldn't really boot afterwards, unfortunately, but mostD > probable this has other reasons, at least I could read all ancient > filesystems). K > The drive I used was a TTI-8510 (probably similar or identical to yours), H > which operates with scary noises, but it works, even after a couple of > years.? > So there's hope. You could check if the media is "datagrade", ? > not 8mm consumer Video, in this latter case your are probably < > out-of-luck, those media often fail even during recording.? > You should also insert an unworn cleaning cartridge (twice if F > the drive was out-of-use for many years) before trying to read/write > "real" tapes. @ > I could also imagine that the jumper settings are significant,C > I've seen that e.g. with DAT drives which need different settings = > for different computer models. If you're very lucky I might 4 > have some info about it in one of my dust bins :-)    F I, too, had good luck with an old 8mm tape. I had a tape I made (a VMSE BACKUP save set) on 12-SEP-1993 on a VAXstation and read it on an 8mm A tape drive in a Sun box on 3-SEP-2003 and once we found the right C command to read the tape it read fine. The guy who runs the Sun box G mailed it to me in a ZIP file (Exchange, Windows PC -- it even survived C through that!!!) and I FTP'd it to one of my MicroVAX 3100's and it A worked fine! (No, I don't recall why he didn't just let me FTP it  directly to the MicroVAX.)   .  .  . # Total of 19130 files, 302235 blocks  End of save set<CR><LF>    So Ken ... don't despair yet.    AEF    ------------------------------  % Date: Thu, 11 May 2006 03:24:45 -0400 ' From: Dave Froble <davef@tsoft-inc.com> % Subject: Re: SGI files for chapter 11 9 Message-ID: <V7mdnQIzsJ2Ve__ZnZ2dnUVZ_sOdnZ2d@libcom.com>    David J. Dachtera wrote: > "Richard B. Gilbert" wrote:  >> Dave Froble wrote:  >> >>> JF Mezei wrote:  >>>   >>>> etmsreec@yahoo.co.uk wrote: >>>>L >>>>> Why would HP want to port VMS, an established 64-bit operating system,  >>>>> back to a 32-bit platform? >>>> >>>> >>>> 8086 is now 64 bits.  >>> > >>> No, AMD64 is 64 bits.  The 8086 is a relic from years ago. >>> ) >> A SIXTEEN BIT relic!  From about 1984!  >  > Well, 8/16 bit.  >  > 80186 - 80586 are 16/32 bit. > E > The "unofficial" 80686 designation is harder to pin down (cue: Bill  > Todd). >   F Possibly unavailable.  Might be packed in ice trying to get his blood  below the boiling point.  :-)    --  4 David Froble                       Tel: 724-529-0450> Dave Froble Enterprises, Inc.      E-Mail: davef@tsoft-inc.com DFE Ultralights, Inc.  170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------    Date: 11 May 2006 02:38:36 -0700- From: "Andrew" <andrew_harrison@symantec.com> % Subject: Re: SGI files for chapter 11 B Message-ID: <1147340316.106484.53180@v46g2000cwv.googlegroups.com>   Malcolm Dunnett wrote:E > In article <1147179118.156007.254190@g10g2000cwb.googlegroups.com>, 4 >    "Andrew" <andrew_harrison@symantec.com> writes:  H > > Sadly I doubt that OpenVMS would satisfy any of these criteria. VeryA > > few customers would drop HP entirely if they ditched OpenVMS, K > > particularlry if the demise of OpenVMS was caused by Intel axing IA-64. F > > Even if they did its doubtfull that there are enough major OpenVMS8 > > customers left to seriously impact HP's bottom line. > > K >    I can only speak for myself, I'm one of those customers who would drop H > HP entirely if it weren't for VMS. We've never used HP Windows systemsJ > and I doubt we ever will ( though that's a commodity item and if HP everF > manages to sell their servers significantly cheaper than Dell we mayF > buy some ). Because Tru64 has been killed we're moving those systemsK > to Linux (with Dell hardware), not to Itanium with HP-UX. We're beginning K > to move away from HP printers, though of course like most people we still H > have a lot of them. For us VMS is the only product that differentiates9 > HP from a crowd of other ( typically cheaper ) vendors.  >   E >From what you have said as far as your company is concerned HP would F only lose their existing OpenVMS revenues and nothing else. Given thatD HP's decision to axe OpenVMS if it ever happens would have to factorF that loss in anyway its hard to see how your example helps make a case@ not to axe OpenVMS because of the potential wider impact for HP.     > G >     That's my point - the customers don't care that VMS runs on Alpha J > or IA64 or "Frammistat 3000", they care that they have a cost-effective,L > reliable platform; which is why making VMS run on x86 "commodity" hardwareF > would be a good business decision, especially if IA64 can't get it's > act together pretty soon.  >   G If all your apps and  every bit of OpenVMS platform sw has been written B in house by your company then moving platforms might be less of anE issue (except that you would still have to do it). But the reality is E that most OpenVMS customers also require 3rd party software and until G that software is ported to OpenVMS on whatever the new platform is they - will not be able to move to the new platform.   F Persuading ISV's to support platforms is hard work, I know having beenD on both sides of the argument while I was at Sun and with my currentE employer Symantec. Its probably true to say that the OpenVMS/IA-64 SW E portfolio is smaller than the OpenVMS/Alpha SW portfolio and its also F probably a fair guess to suggest that OpenVMS/x86 would have a smaller portfolio still.  G Every app that drops out fo the platform represents a loss of available = market as far as OpenVMS is concerned and furtner weakens its  usefullness.   Regards  Andrew Harrison    ------------------------------  % Date: Thu, 11 May 2006 06:59:58 -0400 ' From: "Main, Kerry" <Kerry.Main@hp.com> % Subject: RE: SGI files for chapter 11 T Message-ID: <FA60F2C4B72A584DBFC6091F6A2B868401404F3E@tayexc19.americas.cpqcorp.net>   > -----Original Message-----B > From: Michael D. Ober [mailto:"obermd."@.alum.mit.edu.nospam]=20 > Sent: May 10, 2006 4:34 PM > To: Info-VAX@Mvb.Saic.Com ' > Subject: Re: SGI files for chapter 11  >=20 > =20 H > The fact that SGI is having cash flow problems is probably a result ofB > commodity systems running Windows and Linux becoming powerful=20 > enough to A > handle the graphics loads.  Remember that SGI was originally=20  > a computerA > graphics company (Silicon Graphics, Inc.).  This should be a=20  > good warning to B > HP and other "big-iron" companies not to sit on their current=20 > products. H > They need to continue improving both features and performance or their9 > products will be overtaken by commodity hardware and=20  > software.  This warning > > includes VMS - despite the current "state of the art" for=20 > commodity systems,H > they are continually getting better, both in performance and security. >=20 > Mike Ober. >=20   Mike,   B You are correct that the lower end systems are getting cheaper and better.   
 <soap box on>   = However, one also needs to keep in mind that the security and ; performance bar is also constantly being raised as well.=20   H In addition, staffing costs are the biggest slice in most IT shops todayG so while the one-app, many servers model might have seemed like a great G way to go in the past, companies are also waking up to the reality that D the high cost (people, QA testing etc) of managing these servers has# become a huge, huge issue for them.   E It is why server, storage and application consolidation is one of the D hottest topics in most med-large companies today. And the number one+ target by far? X86 servers running Windows.   E Now, also consider a mission critical shop that follows accepted best F practices and tests OS patches with their applications before they areD rolled out. How can these folks be expected to keep up when their OSC platform keeps getting numerous monthly security patches? [RH Linux A average as I recall from their web site is about 10-20 *security*  patches per month]  C For those who are not familiar with large IT shops, this is serious H stuff - they simply will not roll out patches as the potential impact toC their custom applications is huge. This is especially true when you H consider the open source stuff where many custom patches are in play.=20  D So what are the internal IT groups to do? If they ignore the patchesE until they can get them thru their formal QA cycles, then they expose ) the business to major additional risk.=20   E Course, the on going battle between the "distributed" little guys and C the "centralized" big guys has been going on since the computer was > invented, so I do not expect this battle to end any time soon.  E My point, and pure personal opinion, is that this monthly OS platform B security patching can not continue as Customers are going to startA realizing that they can not afford these "cheaper" platforms. The D monthly QA testing is just going to become to expensive for them.=20  C They will also not be able to afford the risks associated with them F missing a patch and exposing Cust data to the world. Keep in mind thatF all it takes is one serious external breach and your online reputation takes a serious nose dive.=20   D Imagine what these companies must be thinking when they have to sendF official letters to their Customers explaining that their confidential0 information had been exposed to the Internet.=20  B Think about it from your perspective - if you receive one of those@ letters, with all the concerns about identity theft and personalH information being exposed, do you think you will continue to do business with that company?  C Yes, this scenario could happen with any platform, but the odds are D exponentially higher with a platform whereby the vendor is releasing monthly security patches.    <soap box off>   ------------------------------  % Date: Thu, 11 May 2006 06:04:25 -0700 # From: "Tom Linden" <tom@kednos.com> % Subject: Re: SGI files for chapter 11 ) Message-ID: <op.s9d09nnqzgicya@hyrrokkin>   K On Thu, 11 May 2006 02:38:36 -0700, Andrew <andrew_harrison@symantec.com>    wrote:  H > Persuading ISV's to support platforms is hard work, I know having beenF > on both sides of the argument while I was at Sun and with my currentG > employer Symantec. Its probably true to say that the OpenVMS/IA-64 SW G > portfolio is smaller than the OpenVMS/Alpha SW portfolio and its also H > probably a fair guess to suggest that OpenVMS/x86 would have a smaller > portfolio still.  F Reminds one of the russian babushka dolls, with the largest being VAX.K Of course, it didn't have to be that way, as you and others have commented, I all that was needed was a sane ISV policy.  Introducing new architectures J is a risky, reckless endeavour.  VAX should have been extended to 64 bits.I alpha should never have happened, Itanium should never have happened, not % without bringing all the ISV's along.    ------------------------------    Date: 11 May 2006 07:46:19 -0500; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) % Subject: Re: SGI files for chapter 11 3 Message-ID: <N5kYoewJ7G1D@eisner.encompasserve.org>   U In article <xZKdnUAcV8jCVf3ZRVn-tQ@bresnan.com>, GreyCloud <mist@cumulus.com> writes:  > H > I have a bigger question:  what is MIPS doing about their own line of 
 > processors?   F    IIRC SGI owns MIPS.  If SGI is chapter 11, then MIPS is Chapter 11.   ------------------------------  % Date: Thu, 11 May 2006 13:57:29 +0100 * From: "Richard Brodie" <R.Brodie@rl.ac.uk>% Subject: Re: SGI files for chapter 11 2 Message-ID: <e3vcbp$gdt$1@blackmamba.itd.rl.ac.uk>  I "Bob Koehler" <koehler@eisner.nospam.encompasserve.org> wrote in message  - news:N5kYoewJ7G1D@eisner.encompasserve.org...   G >   IIRC SGI owns MIPS.  If SGI is chapter 11, then MIPS is Chapter 11.   : It did but MIPS has a separate NASDAQ listing these days.    ------------------------------    Date: 11 May 2006 12:36:38 -0500; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) % Subject: Re: SGI files for chapter 11 3 Message-ID: <tUioAZzJ41zK@eisner.encompasserve.org>   O In article <op.s9d09nnqzgicya@hyrrokkin>, "Tom Linden" <tom@kednos.com> writes:  > H > Reminds one of the russian babushka dolls, with the largest being VAX.M > Of course, it didn't have to be that way, as you and others have commented, K > all that was needed was a sane ISV policy.  Introducing new architectures L > is a risky, reckless endeavour.  VAX should have been extended to 64 bits.K > alpha should never have happened, Itanium should never have happened, not ' > without bringing all the ISV's along.   E    VAX should not have been extended to 64 bits.  VAX was already too F    damn slow.  VAX couldn't compete against 32 bit RISC.  The decisionH    to make Alpha 64 bit was along the line of a good idea as long as DEC+    knew they had to replace the VAX anyhow.   F    Jumping from Alpha to IA64 is a much more serious question, as wellD    as deciding to stay with VAX instead of porting to 386 before DEC.    lost all its sales to UNIX RISC and Wintel.   ------------------------------    Date: 11 May 2006 07:58:35 -0500; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) V Subject: Re: This post will self-destruct in 10secs (Was Re: X windows  vulnerability)3 Message-ID: <t89WWqTkMoe4@eisner.encompasserve.org>   Y In article <G5GdnZITu91pa_3ZRVn-hg@libcom.com>, Dave Froble <davef@tsoft-inc.com> writes:  > Bob Koehler wrote:f >> In article <L9WdnfVuIpC_Xf3ZnZ2dnUVZ_s2dnZ2d@libcom.com>, Dave Froble <davef@tsoft-inc.com> writes:= >>> Now, does HP still sell licenses and SUPPORT for VAX/VMS?  >>  B >>    OpenVMS 5.5-2 originally sold as (and it's boot header says)@ >>    VAX/VMS 5.5-2.  HP's roadmap showsthat HP plans to supportB >>    this version at least until 2011 with 24 months announcement% >>    prior to actual end of support.  >>   > F > I'm hoping you're not just answering my question.  I knew that.  My E > point is that Kerry was comparing support on old Sun and Microsoft  A > versions with support on VAX/VMS, trying to justify not having  G > fixes/support for TCP/IP on VAX/VMS.  HP is glad to take the support  K > money from VAX users, but doesn't seem as willing to provide the support   > for which they took money.  A    Define support.  I was just reading over HP's plans to provide F    something for systems on extended version support all the way back G    to 5.5-2 to deal with the US DST changes.  And I don't recall those  -    old versions knew about DST to begin with.   G    I know of no other product from HP and no other software vendor that #    gets fixes for systems that old.    ------------------------------    Date: 11 May 2006 08:06:41 -0500; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) O Subject: Re: We need a recommendation of good VMS backup (non-library) software 3 Message-ID: <Q6QNGIMZUEEM@eisner.encompasserve.org>    In article <nYo8g.18356$Sl4.9271@bignews1.bellsouth.net>, "David Turner, Island Computers US Corp" <dbturner@icusc.com> writes: A > Can anyone suggest a "simple to use" VMS backup package that is  > INEXPENSIVE/CHEAP B > I know "backup" works fine but my customer wants some automation  F    Yep.  I wrote a batch job that runs overnight and resubmits itself.  A    All I have to do is watch for OPCOM messages and change tapes.    ------------------------------    Date: 11 May 2006 09:11:28 -0700; From: "johnhreinhardt@yahoo.com" <johnhreinhardt@yahoo.com> O Subject: Re: We need a recommendation of good VMS backup (non-library) software C Message-ID: <1147363888.554190.300470@y43g2000cwc.googlegroups.com>   < Are any of these packages available with a Hobbyist license?   ------------------------------    Date: 11 May 2006 09:28:37 -0700 From: etmsreec@yahoo.co.ukO Subject: Re: We need a recommendation of good VMS backup (non-library) software C Message-ID: <1147364917.772306.323390@i39g2000cwa.googlegroups.com>   F If you do end up rolling your own David, I'd strongly suggest that youD put in some web-page creation/reporting so that uneducated users canD easily check whether the backups worked or not.  If it's on the same3 machine then using logical names is ideal for this.    ------------------------------  # Date: Thu, 11 May 2006 16:46:20 GMT ) From: "John Vottero" <JVottero@mvpsi.com> O Subject: Re: We need a recommendation of good VMS backup (non-library) software > Message-ID: <wTJ8g.25103$4L1.11209@newssvr11.news.prodigy.com>  , <johnhreinhardt@yahoo.com> wrote in message = news:1147363888.554190.300470@y43g2000cwc.googlegroups.com... > > Are any of these packages available with a Hobbyist license? >   + A JAMS hobbyist license is available.  See:    http://www.mvpsi.com/hobby.html    ------------------------------  % Date: Wed, 10 May 2006 22:53:13 -0700 ( From: Jeff Cameron <roktsci@comcast.net>Y Subject: Re: We need a recommendation of good VMS backup (non-library) software softwares 0 Message-ID: <C0881F59.1F386%roktsci@comcast.net>  K On 5/10/06 9:57 AM, in article nYo8g.18356$Sl4.9271@bignews1.bellsouth.net, D "David Turner, Island Computers US Corp" <dbturner@icusc.com> wrote:  A > Can anyone suggest a "simple to use" VMS backup package that is  > INEXPENSIVE/CHEAP B > I know "backup" works fine but my customer wants some automation > J > If you are a reseller or manufacturer of backup/utility software I would > alsdo like to hear from @ > you so we can put a plug/link/"buy it now" section on our site >  > Thanks  < http://support.mti.com/MTICare/OpenVMS/TapeControl/index.htm   ------------------------------  % Date: Thu, 11 May 2006 07:05:07 -0700  From: Z <Z@ids.net> K Subject: Re: XtRemoveTimeOut() with value of 0 accvios under 7.3-2, but not $ Message-ID: <lwH8g.1$8v4.0@fe05.lga>   George Cook wrote: > All the code IF > have ever seen which uses XtAppAddTimeOut either validates the timer! > or has a safety check for zero.    "Validate the timer?"   9 Is there an Xt...() function that can validate the timer?    ------------------------------  # Date: Thu, 11 May 2006 16:09:20 GMT , From: Hoff Hoffman <hoff-remove-this@hp.com>K Subject: Re: XtRemoveTimeOut() with value of 0 accvios under 7.3-2, but not 0 Message-ID: <QkJ8g.376$IN4.294@news.cpqcorp.net>   Z wrote: > George Cook wrote: >> All the code I G >> have ever seen which uses XtAppAddTimeOut either validates the timer " >> or has a safety check for zero. >  > "Validate the timer?"  > ; > Is there an Xt...() function that can validate the timer?     G    Is the timer null?  If it is, it's not valid, and it's a bug in the  
 calling code.   E    Does the calling code stackdump when the caller passes in a bogus  C argument value?  If so, then that is a bug in the called code, and  ) secondary to the bug in the calling code.   E    Can we spend our time validating stuff further?  Sure.  I've been  E known to calculate an MD5 or a CRC32 for data structures, but that's  E overkill for most applications.  And it's probably overkill for this  D one.  I know of no standard X call that can verify the XtIntervalId F value as being valid, which means the application is left to maintain I it.  Without such a mechanism for checking the integrity, the programmer  B is left to use wrappers and local validation (up to and including = comparatively drastic measures such as checksumming the data  F structures), or to simply assume validity and blindly charge forward. D Being that this is X Windows involved here and given that X Windows B itself traditionally assumes error-free operations, the usual and F normally-recommended solution is reduce the bugs where identified and ( feasible, and to blindly charge forward.  G    Architectural changes to X Windows (to verify these structures, and  A to provide argument checking) is rather unlikely, as it involves  E detailed modifications to a gazillion internal and external X calls.  H (Should this have been part of the original MIT design?  Probably.  But ! we're way past that point now...)   H    The obvious steps here are to avoid passing in bad data (which fixes F the problem in the calling code), and to get a formal report into the H support center logged in, such that the response to an argument-passing B failure within the called code isn't a stackdump (which fixes the I misbehaviour of the called code -- but do remember, fixing the stackdump  @ in the X call here doesn't and won't fix the bug in the calling  application code.)  F    I know that the folks on the DECwindows team are at least somewhat G aware of this case right now, but the formal report is how the loop is  I closed for the contract support customer sites; how fixes are propagated  D back out.  But the central fix here involves fixing the application E code, regardless of any changes to DECwindows that might allow it to  + more gracefully field this particular case.    ------------------------------  % Date: Thu, 11 May 2006 09:57:07 -0700  From: Z <Z@ids.net> K Subject: Re: XtRemoveTimeOut() with value of 0 accvios under 7.3-2, but not & Message-ID: <C1K8g.97$Dv2.17@fe06.lga>   Hoff Hoffman wrote:  >>> All the code IH >>> have ever seen which uses XtAppAddTimeOut either validates the timer# >>> or has a safety check for zero.    >> "Validate the timer?"< >> Is there an Xt...() function that can validate the timer?  H >   Is the timer null?  If it is, it's not valid, and it's a bug in the  > calling code.  > F >   Does the calling code stackdump when the caller passes in a bogus E > argument value?  If so, then that is a bug in the called code, and  + > secondary to the bug in the calling code.  > F >   Can we spend our time validating stuff further?  Sure.  I've been  ...   I Hoff, checking for a non-zero value will not guarantee that the timer is  H valid; it might be uninitialized data or the code might not have set it * back to 0 after calling XtRemoveTimeOut().  5 Is there a function I can call to validate the timer?   G If I'm going to change this code, I want to change it *once* and do it  H *correctly*. If there's a function available to validate, then I should  be calling *that*.   Jeez.    ------------------------------  % Date: Wed, 10 May 2006 23:36:23 -0700  From: Z <Z@ids.net> Y Subject: Re: XtRemoveTimeOut() with value of 0 accvios under 7.3-2, but not under 7.1-2 u ( Message-ID: <FXA8g.130$2I1.125@fe05.lga>   Hoff Hoffman wrote: E > Assuming you are current with the installed DECwindows version and  H > with the DECwindows ECO kit (and if not, then I'd start with that), a 8 > small reproducer would be useful in chasing this down.  , Are the available ECO kits listed somewhere?   ------------------------------  # Date: Thu, 11 May 2006 12:57:41 GMT , From: Hoff Hoffman <hoff-remove-this@hp.com>Y Subject: Re: XtRemoveTimeOut() with value of 0 accvios under 7.3-2, but not under 7.1-2 u 0 Message-ID: <9xG8g.371$XG4.252@news.cpqcorp.net>   Z wrote: > Hoff Hoffman wrote: F >> Assuming you are current with the installed DECwindows version and I >> with the DECwindows ECO kit (and if not, then I'd start with that), a  9 >> small reproducer would be useful in chasing this down.  > . > Are the available ECO kits listed somewhere?  F    The URL <ftp://ftp.itrc.hp.com/openvms_patches/> is the usual spot 
 for ECO kits.   H    Fred's answered this elsewhere, however, in that this is a change in H the X Windows code (and an untoward response) that has exposed a bug in 
 your code.   ------------------------------  % Date: Thu, 11 May 2006 08:32:25 -0700  From: Z <Z@ids.net> Y Subject: Re: XtRemoveTimeOut() with value of 0 accvios under 7.3-2, but not under 7.1-2 u $ Message-ID: <cOI8g.4$8v4.1@fe05.lga>   FredK wrote:K > XtRemoveTimeOut() takes the timer ID returned by XtAppAddTimeOut().  Xlib K > and XT were upgraded to X11R6.x in V7.3-2 - so your error is probably not  > being silently ignored.   C I assume the entry points for the Xt...() functions are all in the  F SYS$LIBRARY:DECW$XTLIBSHRR5.EXE and DECW$XEXTLIBSHR.EXE images ... if H that's correct, is it possible to simply replace the new libraries with ! the old ones from a 7.1-2 system?     > > Why not just fix the bug in your code and pass the timer ID?  J This is legacy code. It would be very expensive to make any changes to it.   ------------------------------   End of INFO-VAX 2006.261 ************************                                                                                                                                                                                                                                                           Smith    Architecture: VAX,AXP    # of parts:   -    Language:     DECTPU-P -------------------------------------------------------------------------------- ATG_FT_PATCH    Version:      X1.05>    Description:  Add access port information for FTAn: devices    Author:       Nick de Smith    Architecture: VAX    # of parts:   -    Language:     MACRO-32-P --------------------------------------------------------------------------------
 ATR_DAEMON    Version:      21-SEP-1994(    Description:  ACMS Audit Trail Logger    Author:       Mike Frazier     Architecture: VAX    # of parts:   -    Language:     DCLP -------------------------------------------------------------------------------- AXP-DRIVER-EXAMPLE    Version:      fD    Description:  Example VAX VMS device driver ported to OpenVMS AXP/    Author:       Gerard K. Newman <gkn@TGV.COM>M    Architecture: VAX,AXP    # of parts:   -    Language:     MACRO-32-P -------------------------------------------------------------------------------- BAT #    Version:      V1.10, 11-FEB-2004rB    Description:  Easily execute multiple commands in a batch queue8    Author:       Hunter Goatley <goathunter@goatley.com>    Architecture: VAX,AXP,IA64-    # of parts:   -    Language:     BLISSP -------------------------------------------------------------------------------- BITNET    Version:      M/    Description:  BITNET tools (LPUNCH and GRAB)     Author:       Joe Meadows    Architecture: VAX    # of parts:   -    Language:     VAX BASICP -------------------------------------------------------------------------------- BLISS-ARTICLE-PS    Version:       @    Description:  PostScript version of article introducing BLISS:    Author:       Wulf, et al.  Formatted by Hunter Goatley    Architecture: -    # of parts:   -    Language:     PostScript-P -------------------------------------------------------------------------------- BLISS-INTRO     Version:      24-JUN-1993E    Description:  PostScript session notes for "Introduction to BLISS" 5    Author:       Matthew D. Madison <madison@TGV.COM>-    Architecture: VAX,AXP    # of parts:   -    Language:     PostScriptiP -------------------------------------------------------------------------------- BLOCKING#    Version:      V1.2-1, 6-JUN-1995:I    Description:  Show what process has a record locked in an indexed file-3    Author:       David G. North <D_North@tditx.com>-    Architecture: VAX,AXP    # of parts:   -    Language:     MACRO-32rP ------------------------------------------------