INFO-VAX Wed, 28 Feb 2007 Volume 2007 : Issue 117 Contents: %TPU-E-INVINTERFACE Alpha mystery! Only on Sundays?? Re: Alpha mystery! Only on Sundays?? Re: Alpha mystery! Only on Sundays?? Re: Alpha mystery! Only on Sundays?? Re: Alpha mystery! Only on Sundays?? C RTL logical features Re: C RTL logical features Re: C RTL logical features Re: C RTL logical features Re: DECforms Re: Intel Moves Towards Itanium and Xeon Convergence Re: Intel Moves Towards Itanium and Xeon Convergence Re: Intel Moves Towards Itanium and Xeon Convergence Re: Is it possible to boot OpenVMS from an IDE disk on an ES40? Re: Outputting Variables from C Language Re: Outputting Variables from C Language oversight or are my libraries no longer supported on VMS? Re: oversight or are my libraries no longer supported on VMS? RE: Quebec Health Care Virus Re: Quebec Health Care Virus Re: Quebec Health Care Virus ---------------------------------------------------------------------- Date: Tue, 27 Feb 2007 14:14:36 -0800 From: DeanW Subject: %TPU-E-INVINTERFACE Message-ID: <3f119ada0702271414h76d815a2ude86524426eb7cc4@mail.gmail.com> So, I patched a customer's 7.3-2 cluster (two ES-40s) this morning. Patched, rebooted, happiness. Except, on one node only, EDIT/TPU gives us (any user) %TPU-E-INVINTERFACE, unrecognized interface and exits. SHO TERM is the same between the two hosts. Help? Terminal: _TNA462: Device_Type: VT200_Series Owner: D_WOODWARD Remote Port Info: Host: Locn: _TNA280:/D_WOODWARD Input: 9600 LFfill: 0 Width: 132 Parity: None Output: 9600 CRfill: 0 Page: 48 Terminal Characteristics: Interactive Echo Type_ahead No Escape Hostsync TTsync Lowercase Tab Wrap Scope No Remote Eightbit Broadcast No Readsync No Form Fulldup No Modem No Local_echo No Autobaud Hangup No Brdcstmbx No DMA No Altypeahd Set_speed No Commsync Line Editing Overstrike editing No Fallback No Dialup No Secure server No Disconnect No Pasthru No Syspassword No SIXEL Graphics Soft Characters Printer port Application keypad ANSI_CRT No Regis No Block_mode Advanced_video Edit_mode DEC_CRT DEC_CRT2 No DEC_CRT3 No DEC_CRT4 No DEC_CRT5 No Ansi_Color VMS Style Input ------------------------------ Date: 27 Feb 2007 11:57:34 -0800 From: fred@soho.umd.edu Subject: Alpha mystery! Only on Sundays?? Message-ID: <1172606254.005251.191470@k78g2000cwa.googlegroups.com> Hi all, We've got a strange problem with our Alpha. We have two identical computers, both: Alpha Digital Personal Workstation 600au VMS V7.3-2 Installation date: FEB-1999 SCSI System Disk: Device Name Size Label Make/Model Drive DKA0: 4.2Gb DISKF0_SYS Compaq RZ2CC-KB A few weeks ago, one of them started generating thousands of system disc errors, in a Mount/Verification loop. The computer was basically unusable, a reboot was required. This sequence has now happened 3 times. Strange fact #1: these errors all start on a Sunday morning! Here are the 3 failure times, all are a Sunday: 11-FEB-2007 10:31:06.38 18-FEB-2007 09:27:22.19 25-FEB-2007 09:28:06.25 Fact #2: a simple reboot fixed the problem each time. There were then no more disk errors for 7 days. Fact #3: the *other* computer also had this problem one time. That was on 19 Nov 2006, also a Sunday! It too was fixed with a simple reboot, but it has not had any problems since then. The odds that all 4 of these errors occur on the same day of week is 7**3::1, not very likely. The 2 computers are in different, though adjacent, rooms. Neither has any batch job running Sunday mornings. We didn't find anything strange in any of the system logs near the times of the failures. Since the two RZ2CC disks have been in use since 1999, it could be time for them to fail. But why only on Sundays?? We lost our system guy some time ago, so a few of us scientist-types are trying to maintain these computers in order to continue our data analysis. Any ideas would be greatly appreciated. ------------------------------ Date: Tue, 27 Feb 2007 20:32:39 GMT From: Rob Brown Subject: Re: Alpha mystery! Only on Sundays?? Message-ID: On Tue, 27 Feb 2007 fred@soho.umd.edu wrote: > A few weeks ago, one of them started generating thousands of system > disc errors, in a Mount/Verification loop. The computer was > basically unusable, a reboot was required. This sequence has now > happened 3 times. > > Strange fact #1: these errors all start on a Sunday morning! > Here are the 3 failure times, all are a Sunday: > 11-FEB-2007 10:31:06.38 > 18-FEB-2007 09:27:22.19 > 25-FEB-2007 09:28:06.25 > > Fact #2: a simple reboot fixed the problem each time. > There were then no more disk errors for 7 days. > > Fact #3: the *other* computer also had this problem one time. > That was on 19 Nov 2006, also a Sunday! It too was fixed > with a simple reboot, but it has not had any problems since then. > > The odds that all 4 of these errors occur on the same day of week is > 7**3::1, not very likely. The 2 computers are in different, though > adjacent, rooms. Neither has any batch job running Sunday mornings. > We didn't find anything strange in any of the system logs near the > times of the failures. Since the two RZ2CC disks have been in use > since 1999, it could be time for them to fail. But why only on > Sundays?? Look for something external. Old story about the guy who comes in with the floor polisher, unplugs the critical patient's life support system, plugs in the floor polisher, .... Another old story about the system that shut down every Friday afternoon at 4:00 pm. Janitorial staff arrived at that time, rang the doorbell, and entered. You know, that door bell with the big red button that shuts down everything. Although this seems kind of unlikely give that the disk drives are internal to the workstations, right. -- Rob Brown b r o w n a t g m c l d o t c o m G. Michaels Consulting Ltd. (780)438-9343 (voice) Edmonton (780)437-3367 (FAX) http://gmcl.com/ ------------------------------ Date: 27 Feb 2007 13:09:19 -0800 From: "Doug Phillips" Subject: Re: Alpha mystery! Only on Sundays?? Message-ID: <1172610559.133475.107400@a75g2000cwd.googlegroups.com> On Feb 27, 1:57 pm, f...@soho.umd.edu wrote: > Hi all, > > We've got a strange problem with our Alpha. [...] > Strange fact #1: these errors all start on a Sunday morning! > Here are the 3 failure times, all are a Sunday: > 11-FEB-2007 10:31:06.38 > 18-FEB-2007 09:27:22.19 > 25-FEB-2007 09:28:06.25 > > Fact #2: a simple reboot fixed the problem each time. > There were then no more disk errors for 7 days. > > Fact #3: the *other* computer also had this problem one time. > That was on 19 Nov 2006, also a Sunday! It too was fixed > with a simple reboot, but it has not had any problems since then. > > The odds that all 4 of these errors occur on the same day of week > is 7**3::1, not very likely. But they did, and the likely cause is (as Rob said), external. And, something that happens Sunday AM but not on other days. Could be in your building or anyplace along the power grid if you don't have sufficient power protection & conditioning. If you don't have UPS' on the systems, get some (appropriately rated models, of course). If you do, check them out; they might be old and failing or no longer doing all of their job. >From experience, the majority of these types of problems are power related. ------------------------------------------ (no more UPS wars, please) ------------------------------ Date: 27 Feb 2007 23:19:20 GMT From: bill@cs.uofs.edu (Bill Gunshannon) Subject: Re: Alpha mystery! Only on Sundays?? Message-ID: <54jsjoF210s09U1@mid.individual.net> In article , Tad Winters writes: > "Doug Phillips" wrote in > news:1172610559.133475.107400@a75g2000cwd.googlegroups.com: > >> On Feb 27, 1:57 pm, f...@soho.umd.edu wrote: >>> Hi all, >>> >>> We've got a strange problem with our Alpha. >> [...] >>> Strange fact #1: these errors all start on a Sunday morning! >>> Here are the 3 failure times, all are a Sunday: >>> 11-FEB-2007 10:31:06.38 >>> 18-FEB-2007 09:27:22.19 >>> 25-FEB-2007 09:28:06.25 >>> >>> Fact #2: a simple reboot fixed the problem each time. >>> There were then no more disk errors for 7 days. >>> >>> Fact #3: the *other* computer also had this problem one time. >>> That was on 19 Nov 2006, also a Sunday! It too was fixed >>> with a simple reboot, but it has not had any problems since then. >>> >>> The odds that all 4 of these errors occur on the same day of week >>> is 7**3::1, not very likely. >> >> But they did, and the likely cause is (as Rob said), external. And, >> something that happens Sunday AM but not on other days. Could be in >> your building or anyplace along the power grid if you don't have >> sufficient power protection & conditioning. >> >> If you don't have UPS' on the systems, get some (appropriately rated >> models, of course). If you do, check them out; they might be old and >> failing or no longer doing all of their job. >> >>>From experience, the majority of these types of problems are power >> related. >> >> ------------------------------------------ >> (no more UPS wars, please) >> >> > > A story from the Anchorage office of a former employer: > About once a month (as I recall) all the only computer in the office, a > MicroVAX, would reboot without any explanation. Digital field engineers > visited the site several times and could not find an explanation. This > came to be an expected event, although no one ever stated a prediction of > when it would next occur. Finally, when one employee was relaying the > story to a relative, who correlated dates and location and said it was > the result of training flights by the US Air Force. The story goes that > the employer, another government agency, made contact with the Air Force, > locally and through government channels and the flights over that area > ceased. The reboots also ceased. > Urban legend? Maybe. I never visited that office. > > A second story, and definitely not a legend: > A formwer co-worker of mine visited another of the company's offices in > the SW. To his surprise, the office was in two apartments (side by side) > whose only external doors were sliding glass. The servers (MicroVAX and > Windows NT) were in one of the two small rooms in the back of one of the > apartments. The room also doubled as the break room, since that's where > they made the coffee and that had the microwave. Needless to say, the > people running that office lacked in the area of security and safety for > the critical functioning of their office, since they made money providing > a service requiring the computer applications to be available. OK, as long as we are telling stories I have two........ The first is second hand and some here may remember seeing it on Usenet quite some time ago. I think it may have been in Risks. Seems with the reduction of the datacenter some remodeling was done and the unused portion of the computer room became a conference room. Seems one of the things that ended up on the wrong side of the wall was the "Big Red Emergency Shutoff Switch". Even with a sign posted t said "Do Not Touch" people waiting for meetings had the bad habit of pushing it to see what it did. :-) But the second is more in line with the theme of this thread and I was there and saw it in person. Seems I was working the nightshift in a datacenter in Germany back in 1971. An IBM 1401 shop. Every couple of days the system would just stop processing. No crash or anything, just seemed to stop right in the middle of a job. This would result in a call to IBM. The CE would drive down from Frankfurt (to Kaiserslautern). He would walk around the room looking at all the boxes. Then he would take out a stack of freezer thermometers and stick them through the grills on most of the boxes (except the printer and tale drives). Then he would go out and have a cigarette. After that he would come back in and read all the thermometers. Then he would go out to the HVAC room and turn the temperature up in the AC. Then out for another cigarette (Germans smoked like chimneys then and based on my recent visit, still do!) Come back in later, read the thermometers, collect them and put them back in his bag. Hit "Continue" on the console and away things would go. Seems there was something about the 1401 that made it just come to a halt if it got cold. Temperatures during the day would go up, people would turn up the AC. When the night shift was on the outside temps were much lower and so the computer room temp would also drop. It always amazed me that the supervisor continued to call the CE when all of us knew what the problem was and how to fix it! bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves bill@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: Wed, 28 Feb 2007 00:17:20 +0000 (UTC) From: moroney@world.std.spaamtrap.com (Michael Moroney) Subject: Re: Alpha mystery! Only on Sundays?? Message-ID: bill@cs.uofs.edu (Bill Gunshannon) writes: >OK, as long as we are telling stories I have two........ I have one. It's not really that "good", just a variant of the janitor with the floor buffer story, but it did take place in ZK3-4, where VMS Engineering lives, so you may be interested. ZK3 was built pretty much with the assumption every cubicle would have a VT100 terminal and some additional desk lights and little more, with the computers all in the central labs. Of course, smaller computers like MV IIs and VS 3100s and their monitors started showing up in offices, which started to stress the electric wiring. One cube was being used as a small lab, with a few small systems and nobody actually using it as their office. The circuit breaker for this cube would trip, but only at night. The electricians would check its circuit, and say it was heavily loaded but within limits and shouldn't trip. They replaced the circuit breaker itself once or twice, since they sometimes go bad and trip too soon. It didn't help. I had the cube next door but was on a different circuit and wasn't affected. One day I added a 3100 and plugged it into a different outlet, on the common wall. Late one night, I was using the new system while a janitor vacuumed the hall. The power for my system, the ones in the neighboring cube and the vacuum went out all at once. The janitor didn't miss a beat, he pulled the vacuum's plug from a hall outlet outside the lab cube and plugged it into a different outlet and continued vacuuming. The next day, I reported what happened to the manager responsible for the systems in the cube. Facilities updated the wiring in the office area shortly thereafter. Oh, another one. They changed the key card access system to the labs, part of which was adding big green buttons next to the doors in the lab to unlock the doors from the inside. However, once in a while someone would push the nearby big _red_ button instead... (The green buttons were totally unnecessary, since you could always open the doors from the inside by pushing the crash bars. Nowadays nobody presses either color button) ------------------------------ Date: Tue, 27 Feb 2007 20:48:06 GMT From: VAXman- @SendSpamHere.ORG Subject: C RTL logical features Message-ID: <00A63E0F.22D9CF7D@SendSpamHere.ORG> I want to enable certain C RTL features which are, AFAICT, enabled only with logicals (For example, DECC$EFS_CASE_PRESERVE and DECC$EFS_CHARSET) on a case by case basis within a program. Can these features be turned on an off "per call" to decc${translate/to/from}_vms? -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM "Well my son, life is like a beanstalk, isn't it?" ------------------------------ Date: Tue, 27 Feb 2007 15:09:45 -0600 (CST) From: sms@antinode.org (Steven M. Schweda) Subject: Re: C RTL logical features Message-ID: <07022715094575_2020028F@antinode.org> From: VAXman- @SendSpamHere.ORG > I want to enable certain C RTL features which are, AFAICT, enabled only > with logicals (For example, DECC$EFS_CASE_PRESERVE and DECC$EFS_CHARSET) > on a case by case basis within a program. Can these features be turned > on an off "per call" to decc${translate/to/from}_vms? It's all in the manuals. Or look at almost anything I've worked on in recent years (http://antinode.org/dec/index.html#Software). http://h71000.www7.hp.com/doc/83final/5763/5763pro.html http://h71000.www7.hp.com/doc/83final/5763/5763pro_004.html#index_x_93 The tricky one is DECC$ARGV_PARSE_STYLE which must be set using LIB$INITIALIZE, or else it'll be too late. I normally do all of them together, and leave them set, but most are dynamic, and may be changed at any time. ------------------------------------------------------------------------ Steven M. Schweda sms@antinode-org 382 South Warwick Street (+1) 651-699-9818 Saint Paul MN 55105-2547 ------------------------------ Date: Tue, 27 Feb 2007 21:28:59 GMT From: VAXman- @SendSpamHere.ORG Subject: Re: C RTL logical features Message-ID: <00A63E14.D8EBB11A@SendSpamHere.ORG> In article <07022715094575_2020028F@antinode.org>, sms@antinode.org (Steven M. Schweda) writes: > > >From: VAXman- @SendSpamHere.ORG > >> I want to enable certain C RTL features which are, AFAICT, enabled only >> with logicals (For example, DECC$EFS_CASE_PRESERVE and DECC$EFS_CHARSET) >> on a case by case basis within a program. Can these features be turned >> on an off "per call" to decc${translate/to/from}_vms? > > It's all in the manuals. Or look at almost anything I've worked on >in recent years (http://antinode.org/dec/index.html#Software). > > http://h71000.www7.hp.com/doc/83final/5763/5763pro.html > http://h71000.www7.hp.com/doc/83final/5763/5763pro_004.html#index_x_93 > > The tricky one is DECC$ARGV_PARSE_STYLE which must be set using >LIB$INITIALIZE, or else it'll be too late. I normally do all of them >together, and leave them set, but most are dynamic, and may be changed >at any time. Well, I've set and deleted definitions of DECC$EFS_CHARSET and DECC$EFS_CASE_PRESERVE around decc$translate_vms() and it makes no difference. If I define these prior to running the program, they do make a difference. If I define them and then delete in the program it makes no difference; therefore, it looks like an initialization of the RTL and it looks to be all or nothing. -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM "Well my son, life is like a beanstalk, isn't it?" ------------------------------ Date: Tue, 27 Feb 2007 20:56:41 -0600 From: "Craig A. Berry" Subject: Re: C RTL logical features Message-ID: In article <00A63E14.D8EBB11A@SendSpamHere.ORG>, VAXman- @SendSpamHere.ORG wrote: > In article <07022715094575_2020028F@antinode.org>, sms@antinode.org (Steven > M. Schweda) writes: > > > > > >From: VAXman- @SendSpamHere.ORG > > > >> I want to enable certain C RTL features which are, AFAICT, enabled only > >> with logicals (For example, DECC$EFS_CASE_PRESERVE and DECC$EFS_CHARSET) > >> on a case by case basis within a program. Can these features be turned > >> on an off "per call" to decc${translate/to/from}_vms? > > > > It's all in the manuals. Or look at almost anything I've worked on > >in recent years (http://antinode.org/dec/index.html#Software). > > > > http://h71000.www7.hp.com/doc/83final/5763/5763pro.html > > http://h71000.www7.hp.com/doc/83final/5763/5763pro_004.html#index_x_93 > > > > The tricky one is DECC$ARGV_PARSE_STYLE which must be set using > >LIB$INITIALIZE, or else it'll be too late. I normally do all of them > >together, and leave them set, but most are dynamic, and may be changed > >at any time. > > Well, I've set and deleted definitions of DECC$EFS_CHARSET and > DECC$EFS_CASE_PRESERVE around decc$translate_vms() and it makes > no difference. If I define these prior to running the program, > they do make a difference. If I define them and then delete in > the program it makes no difference; therefore, it looks like an > initialization of the RTL and it looks to be all or nothing. Did you set the logical names or did you set the features (using decc$feature_set or decc$feature_set_value)? I believe the logical names are only read once at start-up time, but setting the features should be something you can do on the fly. I can't say that I've actually tried it though. -- Posted via a free Usenet account from http://www.teranews.com ------------------------------ Date: 27 Feb 2007 22:22:45 -0800 From: "dank" Subject: Re: DECforms Message-ID: <1172643765.300877.57210@p10g2000cwp.googlegroups.com> On Feb 27, 5:35 am, pech...@pechter.dyndns.org (William Pechter) wrote: > Too bad the FrameMaker product forLinuxwas never released. I did all > my best courseware in it. For what it's worth, the copy of Framemaker 6 I have on my shelf runs pretty well under Wine. See http://appdb.winehq.org/appview.php?iVersionId=299 - Dan ------------------------------ Date: Tue, 27 Feb 2007 14:48:36 -0500 From: Bill Todd Subject: Re: Intel Moves Towards Itanium and Xeon Convergence Message-ID: JF Mezei wrote: > n.rieck@sympatico.ca wrote: >> Intel Moves Towards Itanium and Xeon Convergence >> >> http://www.dailytech.com/article.aspx?newsid=6236 > > > The CSI was announced back in 2004 (or early 2005). (Common system > chipset that will allow the 8086 to scale to same size as IA64). Not necessarily: Intel could choose to hobble x86 if it wanted to - the surrounding chipset may allow the same number of sockets, but the on-CPU use of it could have different socket (and local RAM support) limits. > > Note that HP apparently intends to continue to use its own proprietary > system chipsets, so it is not clear how this will play out within HP. Have a reference for that? At this point, I'd be somewhat surprised to see HP rolling its own CSI chipsets: while years ago the theory was that Intel would only provide, say, direct support for 4 sockets in CSI and leave larger system support up to its major OEMs, the competition on the x86 front (with the likelihood that AMD will be supporting larger configurations natively before then: 8 sockets by the end of this year in a more effective configuration than its current 8-socket offerings, and 32 sockets some time next year) may make this strategy less feasible. Furthermore, making the other Itanic OEMs invest in developing their own CSI chipsets would be a good way to drive them away entirely: they have far less dependency on the platform than HP does, and might well choose to drop it rather than either play second-fiddle to HP or shovel additional bucket-loads of cash down that rat-hole. SGI could be the sole exception here, since they need to support systems (whether x86 or Itanic) larger than anyone else, hence have no choice but to develop such support on their own if they wish to continue in that market space. > > Also, if the dates quoted in this article are correct, it means that > Intel is ahead of its delayed schedule. Last I have heard, the 8086 was > to get that CSI in 2008 and that IA64 thing would get CSI with Tukwilla > late 2009. I haven't heard anything that disputes shipping CSI support with x86 next year, and Gelsinger's statement about the 'realization' of Tukwila in 'late 2008' could well refer to something earlier than an actual ship date (though probably something later than first silicon - otherwise, they'd be shipping closer to 2010). Then again, Intel has been scrambling lately, and it's not completely inconceivable that they could pull in Tukwila ship to, say, December of next year: Itanic will sure as hell be hurting badly until Tukwila hits the streets, given that Montvale seems to be only a somewhat warmed-over version of Montecito (which POWER5+ already blows out of the water commercially, with POWER6 promising to about double POWER5+'s per-core performance this year and POWER6+ due some time in 2009 - not to mention the continuing x86 improvements by both Intel and AMD this year and next and improved competition from Fujitsu/Sun's SPARC64 platforms). > > (Back in 2004 when the announcement was made, both were to get the CSI > at the same time in 2007). Which makes Gelsinger's claim that "the first Montecito slip aside, we're back on track" just a tad disingenuous. Perhaps he just meant that, after the 1.5 year Montecito slip, there were no *additional* amounts of slippage yet perceived as likely in the program (i.e., the whole program had slipped by that amount). > > What is significant here is that the 8086 will get the same system level > features as IA64. (Remember that RAS argument made by the HP rep who > tried to find one reason for IA64, well by that time, RAS won't be a > differentiating factor even to marketers) That, again, depends on the CPU chips, not the surrounding chipset: Intel *could* still choose to differentiate x86 from Itanic on that basis if it doesn't feel compelled to compete in that area with AMD x86 products. - bill ------------------------------ Date: Tue, 27 Feb 2007 15:05:32 -0500 From: JF Mezei Subject: Re: Intel Moves Towards Itanium and Xeon Convergence Message-ID: <66f97$45e48f15$cef8887a$11477@TEKSAVVY.COM> Bill Todd wrote: >> Note that HP apparently intends to continue to use its own proprietary >> system chipsets, so it is not clear how this will play out within HP. > > Have a reference for that? At the toronto seminar, I specifically asked that question. (Considering Intel is to come out with the CSI in 2008/2009, will HP continue to produce its ow proprietary chipsets ?) and the answer from the HP rep was a resounding" I see no reason why HP would stop since it is HP's chipset which gives HP some competitive advantage opver other IA64 manufacturers". Now, one needs to take HP statements with a grain of salt, of course. But at this point in time, HP should have already made decisions and be working on the 2009 servers lines that will support that Tukwilla thing, since, as the HP rep said, this would bring forth a totally new line of IA64 servers. ------------------------------ Date: Tue, 27 Feb 2007 15:42:49 -0500 From: Bill Todd Subject: Re: Intel Moves Towards Itanium and Xeon Convergence Message-ID: <35ydnVDfD9dXCnnYnZ2dnUVZ_t-mnZ2d@metrocastcablevision.com> JF Mezei wrote: > Bill Todd wrote: >>> Note that HP apparently intends to continue to use its own >>> proprietary system chipsets, so it is not clear how this will play >>> out within HP. >> >> Have a reference for that? > > At the toronto seminar, I specifically asked that question. (Considering > Intel is to come out with the CSI in 2008/2009, will HP continue to > produce its ow proprietary chipsets ?) and the answer from the HP rep > was a resounding" I see no reason why HP would stop since it is HP's > chipset which gives HP some competitive advantage opver other IA64 > manufacturers". If you parse that statement you will find no indication whatsoever that HP is still working on its own chipset to support the CSI architecture: rather, it sounds very like the kind of waffle that would be offered up if it were not but didn't wish to admit it yet. Of course, there's also the question of whether HP's chipset actually *does* give it any competitive advantage over the other Itanic vendors who are rolling their own rather than just using Intel's: last I knew, Fujitsu's and NEC's were at least as good (and in some cases better) in both performance and scalability (though NEC's may still top out at 64 cores). - bill ------------------------------ Date: Tue, 27 Feb 2007 21:08:26 -0600 From: David J Dachtera Subject: Re: Is it possible to boot OpenVMS from an IDE disk on an ES40? Message-ID: <45E4F22A.1498DB13@spam.comcast.net> Stephen Hoffman wrote: > > David J Dachtera wrote: > > Stephen Hoffman wrote: > >> [snip] > >> The whole box is emulated. > >> > >> That is orders of magnitude larger than an emulated IDE ATA disk > >> interface. This could be something in the structures leading back to > >> the controller that's not quite right, or an instruction-level error, or > >> most anything else that could conceivably be wrong with "hardware". > >> > >> APB has not gotten as far along as the "real" OpenVMS drivers here. > >> APB and SYSBOOT both use APB-based drivers. Once SYSBOOT is rolling, > >> then more advanced drivers are loaded and activated. > > > > What we sem to be overlooking here also is that WRITEBOOT enables the PRIMARY > > bootstrap to find APB (the SECONDARY bootstrap). However, APB can't find SYSBOOT > > (the tertiary bootstrap). > > APB.EXE is the primary bootstrap for OpenVMS Alpha. > > SYSBOOT.EXE is the secondary bootstrap. I start counting one layer lower: Boot block - Primary (WRITEBOOT "patches" it so APB can be found) APB - Secondary SYSBOOT - Tertiary -- David J Dachtera dba DJE Systems http://www.djesys.com/ Unofficial OpenVMS Marketing Home Page http://www.djesys.com/vms/market/ Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/ Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/ Unofficial OpenVMS Hobbyist Support Page: http://www.djesys.com/vms/support/ ------------------------------ Date: Tue, 27 Feb 2007 13:07:41 -0800 From: Fred Bach Subject: Re: Outputting Variables from C Language Message-ID: <45E49D9D.9010004@triumf.ca> Tom Linden wrote: > On Tue, 20 Feb 2007 14:30:51 -0800, wrote: > >> I wrote this DCL script to execute some calculations however I need to >> do decimal math so I need to introduce a C script into the DCL [snip] Some years ago Carl J. Lydick dropped a little gem on us - his DCL math program which could work to about as many decimal places as you chose. I tried it to about 12 places and it was fine as far as I tested it. As I recall, it could multiply or divide. One of the command-line arguments was how many decimal places you wanted. Unfortunately, in January 2003 I lost my entire file of saved (really old) comp.os.vms articles when a VMS VAX system was phased out in favour of free linux when I was away. (I guess ya shouldn't rely on other people's backups.) Did anyone else make a collection of Carl's stuff? .. fred bach music at triumf dot c a ------------------------------ Date: 27 Feb 2007 16:20:12 -0800 From: raggden@gmail.com Subject: Re: Outputting Variables from C Language Message-ID: <1172622011.774711.224190@k78g2000cwa.googlegroups.com> Thanks for all the responses. I was able to get it to work finally. Yay! Thanks again! ------------------------------ Date: 27 Feb 2007 13:39:07 -0800 From: "jbigboote" Subject: oversight or are my libraries no longer supported on VMS? Message-ID: <1172612347.275724.185890@a75g2000cwd.googlegroups.com> I got my HP alert email last Friday, and yesterday I checked out the link for tape library firmware upgrades: http://tinyurl.com/2ls4yg I see about every OS HP supports listed there except VMS: Type: Firmware - Bundle Version: February 2007 (22 Feb 2007) Operating System(s): HP-UX 11.x, Red Hat Enterprise Linux 3 (AMD64/ EM64T), Red Hat Enterprise Linux 3 (Itanium), Red Hat Enterprise Linux 3 (x86), Red Hat Enterprise Linux 4 (AMD64/EM64T), Red Hat Enterprise Linux 4 (Itanium), Red Hat Enterprise Linux 4 (x86), Red Hat Linux 7.0, Red Hat Linux 7.1, Red Hat Linux 7.2, Red Hat Linux 7.3, Red Hat Linux 8.0, Red Hat Linux 9, SUSE Linux Enterprise Server 9 (AMD64/ EM64T), SUSE Linux Enterprise Server 9 (x86), Tru64 UNIX 5.x File name: ltt_msl_feb07.tar (36 MB) ------------------------------ Date: Tue, 27 Feb 2007 21:33:19 -0600 From: David J Dachtera Subject: Re: oversight or are my libraries no longer supported on VMS? Message-ID: <45E4F7FF.9D993C80@spam.comcast.net> jbigboote wrote: > > I got my HP alert email last Friday, and yesterday I checked out the > link for tape library firmware upgrades: > http://tinyurl.com/2ls4yg > > I see about every OS HP supports listed there except VMS: > > Type: Firmware - Bundle > > Version: February 2007 (22 Feb 2007) > > Operating System(s): HP-UX 11.x, Red Hat Enterprise Linux 3 (AMD64/ > EM64T), Red Hat Enterprise Linux 3 (Itanium), Red Hat Enterprise Linux > 3 (x86), Red Hat Enterprise Linux 4 (AMD64/EM64T), Red Hat Enterprise > Linux 4 (Itanium), Red Hat Enterprise Linux 4 (x86), Red Hat Linux > 7.0, Red Hat Linux 7.1, Red Hat Linux 7.2, Red Hat Linux 7.3, Red Hat > Linux 8.0, Red Hat Linux 9, SUSE Linux Enterprise Server 9 (AMD64/ > EM64T), SUSE Linux Enterprise Server 9 (x86), Tru64 UNIX 5.x > > File name: ltt_msl_feb07.tar (36 MB) These days, I'm not sure even VMS is supported on VMS anymore! -- David J Dachtera dba DJE Systems http://www.djesys.com/ Unofficial OpenVMS Marketing Home Page http://www.djesys.com/vms/market/ Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/ Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/ Unofficial OpenVMS Hobbyist Support Page: http://www.djesys.com/vms/support/ ------------------------------ Date: Tue, 27 Feb 2007 17:00:04 -0500 From: "Main, Kerry" Subject: RE: Quebec Health Care Virus Message-ID: > -----Original Message----- > From: Michael D. Ober [mailto:"obermd."@.alum.mit.edu.nospam]=20 > Sent: February 27, 2007 2:46 AM > To: Info-VAX@Mvb.Saic.Com > Subject: Re: Quebec Health Care Virus >=20 > Kerry, >=20 > I agree with you on the need for more long term rational=20 > approaches to=20 > decision making. The problem is that it's a rare politician=20 > who looks past=20 > the next election and a rare CEO/CIO's who looks past the=20 > next quarter or=20 > two's earning reports. Given the short time frame these=20 > decision makers=20 > work with, Windows/Linux makes more rational sense to them,=20 > even when over=20 > the lifetime of the systems they're making decisions for,=20 > something along=20 > the lines of VMS or even IBM's MVS would be a far better=20 > choice, despite the=20 > higher up-front costs. >=20 > Mike. >=20 [snip...] While this may have been true in the past, recent events like this health care issues and many other issues where serious security issues have been highlighted and potentially have struck some serious nerves at high places. As an example, would you continue to do business with a company that just sent you and many thousands of others a registered letter that stated your personal information had been compromised and you should watch your bank accounts and credit cards for the next year or two? Exec's are starting to wake up and smell the roses - these IT decisions are potentially career ending and/or business crippling decisions with regards to app's being deployed on platforms that have 5-20 security patches per month. And keep in mind that 50-60% of security issues are internal issues - not related to the Internet. Btw, the costs between OpenVMS and Windows are typically very small when you compare it to the total costs of most projects. In the past, it was usually OS religion that was the major determining factor with little or no concerns about security. >=20 > Case in point: > http://www.openvms.org/stories.php?story=3D07/02/16/3329759 >=20 > Regards Kerry Main Senior Consultant HP Services Canada Voice: 613-592-4660 Fax: 613-591-4477 kerryDOTmainAThpDOTcom (remove the DOT's and AT)=20 OpenVMS - the secure, multi-site OS that just works. ------------------------------ Date: 27 Feb 2007 23:04:21 GMT From: bill@cs.uofs.edu (Bill Gunshannon) Subject: Re: Quebec Health Care Virus Message-ID: <54jrnlF1vp63bU1@mid.individual.net> In article , "Main, Kerry" writes: > > While this may have been true in the past, recent events like this > health care issues and many other issues where serious security issues > have been highlighted and potentially have struck some serious nerves at > high places. > > As an example, would you continue to do business with a company that > just sent you and many thousands of others a registered letter that > stated your personal information had been compromised and you should > watch your bank accounts and credit cards for the next year or two? You mean like the VA? So, what are my options if I choose not to use them? A national Health System would suffer the exact same shortcoming. > > Exec's are starting to wake up and smell the roses - these IT decisions > are potentially career ending and/or business crippling decisions with > regards to app's being deployed on platforms that have 5-20 security > patches per month. And keep in mind that 50-60% of security issues are > internal issues - not related to the Internet. Yeah, just look at how bad decisions affected the careers and financial futures of the former heads of Compaq and HP. bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves bill@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: 27 Feb 2007 22:26:27 -0800 From: davidc@montagar.com Subject: Re: Quebec Health Care Virus Message-ID: <1172643987.794666.204750@s48g2000cws.googlegroups.com> On Feb 27, 4:00 pm, "Main, Kerry" wrote: > Exec's are starting to wake up and smell the roses - these IT decisions > are potentially career ending and/or business crippling decisions with > regards to app's being deployed on platforms that have 5-20 security > patches per month. And keep in mind that 50-60% of security issues are > internal issues - not related to the Internet. I'm waiting for the cla$$-action lawsuit$ from hungry lawyer$ seeing "negligence" in putting such critical information on insecure or at least systems where not every possible virus-checker/firewall/security- update is in place or out of date. Simply signing someone up for a credit watch service isn't going to be enough. ------------------------------ End of INFO-VAX 2007.117 ************************