INFO-VAX Fri, 04 Jan 2008 Volume 2008 : Issue 7 Contents: Re: Help identifying a cable Re: I64 VMS 8.3/DECwindows 1.6 problem with DECW$SERVER_0 processing crashing cr Re: I64 VMS 8.3/DECwindows 1.6 problem with DECW$SERVER_0 processing crashing cr Re: I64 VMS 8.3/DECwindows 1.6 problem with DECW$SERVER_0 processing crashing Re: I64 VMS 8.3/DECwindows 1.6 problem with DECW$SERVER_0 processing crashing Re: I64 VMS 8.3/DECwindows 1.6 problem with DECW$SERVER_0 processing crashing Re: OT: More daylight savings hassles Re: OT: The penultimate legal schmuckery of 2007. Re: OT: The penultimate legal schmuckery of 2007. Re: OT: The penultimate legal schmuckery of 2007. Re: Question about INSTALLing shared images Re: upgrading from 7.3-2 Re: upgrading from 7.3-2 ---------------------------------------------------------------------- Date: Thu, 03 Jan 2008 16:12:42 -0600 From: Michael Austin Subject: Re: Help identifying a cable Message-ID: Tad Winters wrote: > Thanks for identifying the last item! (Bill and others.) > > I have a cable I'd like to identify now. If you can take a look at: > > http://mysite.verizon.net/stafford.winters2/Unknown-Clear-Signal-cable.html > > (Sorry if it wrapped.) > The jacket itself has INMAC CLEAR SIGNAL CABLE on it, but there is no > identifying tag as I'm used to seeing. It's only cluttering up my home > office, so I'd like to figure out what it is and get it outta here. > Thanks, > > Tad Based on your other post about the Sigma card (LPV11 clone) this could be the cable that plugs into that card and into the printer. It has been almost 20 years since I serviced any of the LP series printers and the memory is fading... ------------------------------ Date: Thu, 3 Jan 2008 12:16:44 -0800 (PST) From: mjjerabek Subject: Re: I64 VMS 8.3/DECwindows 1.6 problem with DECW$SERVER_0 processing crashing cr Message-ID: On Jan 3, 7:15 am, "FredK" wrote: > "mjjerabek" wrote in message > > news:1503a949-aa96-4fbd-9ceb-c277361f5d06@i7g2000prf.googlegroups.com... > > > The last time we had a DECwindows problem, posting it here help as > > much as calling HP technical support, so here the scoop ... > > I suggest the call to support. We can't fix things that we don't know > about. Already done ... I called HP first and then posted here second. It turns out from testing that the "memory leak" is caused because I am using a 24bpp displays. If I switch the display to 16bpp as suggested by HP technical support, and repeat my test, the problem does not appear. My application runs as either PseudoColor or 24bpp TrueColor, so if one of my customers has not used the enhanced color features in my application, I will temporarily switch them to PseudoColor until a fix from HP can be generated. I have never tested my application as 16bpp, but it should work. I will have to do some small testing to validate that my application features don't break under 16bpp. > > Now to answer some misconceptions... > > Logging out of a session resets the server, but it does not restart the > process. > > The most common cause of server page count growth is pixmaps that are > created and never deleted. In addition, it is possible to fragment heap > space because alloc/free does not do garbage collection. > > The X11 server code source is identical between Alpha and IPF. But it is > possible you don't see the issue on Alpha because IPF uses more memory - and > you are stablizing on Alpha before you hit a quota limit. It is also > possible that the memory footprint of the device specific layer is different > if the graphics adapters are not identical - the Radeon server will use a > lot more memory that a VX1 or TGA2 for example. Or it is possible there is We have a 100 or so DS10/DS20 machines running with radeon cards at 24bpp with no problems. This is exclusively a IPF issue. Also, it does not matter whether we use an I64 machine with management console hosted radeon, or an addon radeon card for systems with no management console, the problem happens everywhere. Also, this is exclusively a HP application problem. I can crash the x- server by logging into a CDE or old DECwindow session, creating a DECterm, logging out, and repeating this sequence a 100 or so times. My customer tend to have 24x7 coverage with 3 shifts per day. Their systems tend to crash after about a month. The old legacy AXP systems that sit right next some of these I64 systems have no worries. This problem is extremely reproducible. Generate a rx26xx system running basic OpenVMS V83. Added the UPDATE5 patch for rx2660 systems so the management console radeon gets recognized, and run my test. The problem always happens. > a memory leak in the XServer (to be honest, I know that the code leaks like > a sieve - the MIT folks were terrible at cleaning up memory). > > The first thing to do is to increase pagefile quota in the server. The > temporary workaround is to periodically restart the server instead of ending > the session and logging back in (@SYS$MANAGER:DECW$STARTUP RESTART) Done. It was the first lesson taught at a AXP to I64 porting class I attended that HP taught last year. My DECW quotas turn out to be a bit more generous than the suggested quotas from that class and from HP technical support (yesterday). > > There is (or should be) a graphics update patch for V8.3 I64 that you should > apply, since it fixes many problems. This problem happens whether the graphics patch #1 is installed or not. I also added the Motif ECO2 to the mix hoping that it would contribute to a solution, but nothing changed. As a side question, am I the only person using OpenVMS/DECWindow with 24bpp displays. I can not believe no one else has seen this problem. This problem has been elevated to HP engineering. I will continue to post progress and the eventual solution. ------------------------------ Date: Thu, 3 Jan 2008 17:24:43 -0800 (PST) From: mjjerabek Subject: Re: I64 VMS 8.3/DECwindows 1.6 problem with DECW$SERVER_0 processing crashing cr Message-ID: <461adcf1-dc61-44ca-9621-379a117ee6bc@i7g2000prf.googlegroups.com> On Jan 3, 3:22 pm, "FredK" wrote: > "mjjerabek" wrote in message > > news:f0db0db6-3a7a-4142-ac51-64d331861c1f@d21g2000prf.googlegroups.com... > > > On Jan 3, 7:15 am, "FredK" wrote: > >> "mjjerabek" wrote in message > > >>news:1503a949-aa96-4fbd-9ceb-c277361f5d06@i7g2000prf.googlegroups.com... > > > As a side question, am I the only person using OpenVMS/DECWindow with > > 24bpp displays. I can not believe no one else has seen this problem. > > 24 bit is the default for the Radeon, so I expect that most customers are > using 24 bit. It is entirely possible that customers don't log in/out > enough times between boots to see a problem. > > The Radeon code and server code is common between Alpha and IA64 - so that > too is a mystery. > > One thing that changing the depth to 16bpp does is to disable 3D and run the > server in a mostly PIO mode instead of DMA. You might as an experiment try > editing DECW$DEVICE_CONFIG_GH.COM and comment out the adding of the OpenGL > extension to the extension list, and > > $ define /system DECW$SERVER_NOACCEL 1 > > This will disable loading the OpenGL direct rendering code. In additional testing I found yet another radeon/I64 problem. As I said before I would be telling my customer who can to use PseudoColor/ 8bpp visuals with my application. Before I did this I decided, all things being considered, to test it out on a few I64 systems we have. PseudoColor is how we ran our application for 15 years on Vaxen and Alphas under VMS, but I had a bad feeling. On an rx2620 with an add in radeon and no management console, I set the visual number to 3, the BPP to 8, the pixel resolution to 1280x1024@75Hz and restarted DECwindows. The display came up Technicolor (all the colors were wrong). I was amazed. I tried this same test on an rx2660 (copied the decw$private_server_setup file from the rx2620) using the management console video card and everything worked perfectly. I am most likely going to open an additional service call (tomorrow) on this problem, but ??? Please note, I have been also doing all of these tests on a DS10 with an add in radeon card with no troubles. The DS10 is running VMS 7.3-2 with DECwindows 1.2-6 and all the ECO's. The I64 machines are running VMS V83, with DECWindows 1.6, at least UPDATE3, and all the DECwindows ECOs. All machines have at least 2GB of ram and the quotas for the x- server are generous. I will try (tomorrow) as you suggested in you comments above. It will be a good data point for technical support. I will continue to post progress and the eventual solution. ------------------------------ Date: Fri, 04 Jan 2008 02:41:35 GMT From: John Santos Subject: Re: I64 VMS 8.3/DECwindows 1.6 problem with DECW$SERVER_0 processing crashing Message-ID: mjjerabek wrote: > On Jan 3, 3:22 pm, "FredK" wrote: > >>"mjjerabek" wrote in message >> >>news:f0db0db6-3a7a-4142-ac51-64d331861c1f@d21g2000prf.googlegroups.com... >> >> >>>On Jan 3, 7:15 am, "FredK" wrote: >>> >>>>"mjjerabek" wrote in message >> >>>>news:1503a949-aa96-4fbd-9ceb-c277361f5d06@i7g2000prf.googlegroups.com... >> >>>As a side question, am I the only person using OpenVMS/DECWindow with >>>24bpp displays. I can not believe no one else has seen this problem. I've never seen it, but I seldom log off my I64 console. (I'm the only person who uses the graphics console, I just lock the screen when I go home and unlock it in the morning. I usually create about a dozen DECterms when I log in, and usually leave them up until I log out, so if there is a memory leak as you describe, I probably wouldn't notice it.) Usually I only log out if I need to reboot for some reason, which would clear any such problem. (rx2620, console Radeon graphics, default settings, VMS V8.3, DECwindows V1.6 with all patches.) >> >>24 bit is the default for the Radeon, so I expect that most customers are >>using 24 bit. It is entirely possible that customers don't log in/out >>enough times between boots to see a problem. >> >>The Radeon code and server code is common between Alpha and IA64 - so that >>too is a mystery. >> >>One thing that changing the depth to 16bpp does is to disable 3D and run the >>server in a mostly PIO mode instead of DMA. You might as an experiment try >>editing DECW$DEVICE_CONFIG_GH.COM and comment out the adding of the OpenGL >>extension to the extension list, and >> >>$ define /system DECW$SERVER_NOACCEL 1 >> >>This will disable loading the OpenGL direct rendering code. > > > In additional testing I found yet another radeon/I64 problem. As I > said before I would be telling my customer who can to use PseudoColor/ > 8bpp visuals with my application. Before I did this I decided, all > things being considered, to test it out on a few I64 systems we have. > PseudoColor is how we ran our application for 15 years on Vaxen and > Alphas under VMS, but I had a bad feeling. > > On an rx2620 with an add in radeon and no management console, I set > the visual number to 3, the BPP to 8, the pixel resolution to > 1280x1024@75Hz and restarted DECwindows. The display came up > Technicolor (all the colors were wrong). I was amazed. I tried this > same test on an rx2660 (copied the decw$private_server_setup file from > the rx2620) using the management console video card and everything > worked perfectly. I am most likely going to open an additional service > call (tomorrow) on this problem, but ??? > > Please note, I have been also doing all of these tests on a DS10 with > an add in radeon card with no troubles. The DS10 is running VMS 7.3-2 > with DECwindows 1.2-6 and all the ECO's. The I64 machines are running > VMS V83, with DECWindows 1.6, at least UPDATE3, and all the DECwindows > ECOs. All machines have at least 2GB of ram and the quotas for the x- > server are generous. > Didn't you assert previously that this was an I64 problem and not an Alpha problem? If it hasn't been tried on an Alpha with VMS 8.3 and DECwindows V1.6, it could very well be a generic VMS 8.3 problem and not an I64-specific problem. > I will try (tomorrow) as you suggested in you comments above. It will > be a good data point for technical support. I will continue to > post progress and the eventual solution. > -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 ------------------------------ Date: Thu, 3 Jan 2008 18:22:09 -0500 From: "FredK" Subject: Re: I64 VMS 8.3/DECwindows 1.6 problem with DECW$SERVER_0 processing crashing Message-ID: "mjjerabek" wrote in message news:f0db0db6-3a7a-4142-ac51-64d331861c1f@d21g2000prf.googlegroups.com... > On Jan 3, 7:15 am, "FredK" wrote: >> "mjjerabek" wrote in message >> >> news:1503a949-aa96-4fbd-9ceb-c277361f5d06@i7g2000prf.googlegroups.com... >> > As a side question, am I the only person using OpenVMS/DECWindow with > 24bpp displays. I can not believe no one else has seen this problem. > 24 bit is the default for the Radeon, so I expect that most customers are using 24 bit. It is entirely possible that customers don't log in/out enough times between boots to see a problem. The Radeon code and server code is common between Alpha and IA64 - so that too is a mystery. One thing that changing the depth to 16bpp does is to disable 3D and run the server in a mostly PIO mode instead of DMA. You might as an experiment try editing DECW$DEVICE_CONFIG_GH.COM and comment out the adding of the OpenGL extension to the extension list, and $ define /system DECW$SERVER_NOACCEL 1 This will disable loading the OpenGL direct rendering code. ------------------------------ Date: Thu, 3 Jan 2008 23:53:22 -0500 From: "FredK" Subject: Re: I64 VMS 8.3/DECwindows 1.6 problem with DECW$SERVER_0 processing crashing Message-ID: "mjjerabek" wrote in message news:461adcf1-dc61-44ca-9621-379a117ee6bc@i7g2000prf.googlegroups.com... > On Jan 3, 3:22 pm, "FredK" wrote: >> "mjjerabek" wrote in message >> >> news:f0db0db6-3a7a-4142-ac51-64d331861c1f@d21g2000prf.googlegroups.com... >> >> > On Jan 3, 7:15 am, "FredK" wrote: >> >> "mjjerabek" wrote in message >> >> >>news:1503a949-aa96-4fbd-9ceb-c277361f5d06@i7g2000prf.googlegroups.com... >> > Alphas under VMS, but I had a bad feeling. > > On an rx2620 with an add in radeon and no management console, I set > the visual number to 3, the BPP to 8, the pixel resolution to > 1280x1024@75Hz and restarted DECwindows. The display came up > Technicolor (all the colors were wrong). I was amazed. I tried this > same test on an rx2660 (copied the decw$private_server_setup file from > the rx2620) using the management console video card and everything > worked perfectly. I am most likely going to open an additional service > call (tomorrow) on this problem, but ??? > There is an ECO patch kit that *should* be available to fix this and other problems (for V8.3, we will also be doing a V7.3-2 and V8.2 kit). The workaround is to use the other video connector. The Radeon card has two connectors (DVI and analog) and we run the same video out both of them - but each has a seperate RAMDAC. The driver developer was pre-enabling a feature he never completed... and broke the code that updates *both* of the RAMDACs. So you get the correct colors on one, and bogus colors on the other (which never gets updated). The problem has been out there since V8.3. ------------------------------ Date: Thu, 03 Jan 2008 16:03:20 -0600 From: Michael Austin Subject: Re: OT: More daylight savings hassles Message-ID: JF Mezei wrote: > http://uk.reuters.com/article/oilRpt/idUKN2734841120071227 > > BUENOS AIRES, Dec 27 (Reuters) - Argentina's Congress approved a > daylight savings measure late on Wednesday, part of a broader government > plan to conserve energy as demand for power surges amid brisk economic > growth. > > Under the new law, which both houses of Congress passed the same day, > the time in Argentina will jump forward an hour starting on Sunday. The > clocks will turn back on March 16. > > etc > > Talk about quick implementation. Pass a law on wednesday for a time > change that takes effect 4 days later ! > > > It appears Microsoft has already issued patches for this. Are updated > time zone files available for VMS yet ? :-) :-) They must have followed the lead of the US in which they passed these similar "energy-saving" measures by extending DST by 3 weeks (2 in Spring and 1 in the Fall) to combat the non-existent global warming. They used a study on how/when Americans went to work and came home to show how much energy could be saved by implementing DST. Problem is - the study was 30+ years old and in no way represents current day work trends. The only thing they did was, once again, line the pockets of the big 5 consulting companies and a bunch of lawyers as well as most of the computer industry. In essence, what it caused was having to do another Y2K effort in < 1 year - when it took almost 10 years to prepare for Y2K. The to top it off, SUN announced a bug in Java (another "bright idea") 3 days before DST causing my company to patch 4000+ servers in 2 days... not to mention the patches required for Oracle because of it... GRRRRR Morons, I tell you, they are all Morons!!! ------------------------------ Date: Thu, 03 Jan 2008 14:16:58 -0500 From: "Richard B. Gilbert" Subject: Re: OT: The penultimate legal schmuckery of 2007. Message-ID: <477D34AA.2070805@comcast.net> Phillip Helbig---remove CLOTHES to reply wrote: > In article > , AEF > writes: > > >>On Jan 2, 6:33 am, hel...@astro.multiCLOTHESvax.de (Phillip Helbig--- >>remove CLOTHES to reply) wrote: >> >>>In article <477AC30E.C02C3...@spam.comcast.net>, David J Dachtera >>> >>> writes: >>> >>>>VAXman-, @SendSpamHere.ORG wrote: >>> >>>>>This group of scum never ceases to amaze me... >>>> >>>>>http://tmesis.com/r_scum >>>> >>[...] >> >>>"I believe in supporting the musicians, but most of the money goes to >>>the record company." Depends on the contract, but probably true. On >>>the other hand, no-one is FORCED to sign a record deal, and these days >>>any band who wants to distribute their own music electronically, for >>>free or for pay, rather than signing with a label, is free to do so. >>>However, most don't. Presumably, this is because what the record >>>company offers is worth it to them. >> >>This is a little too much like saying, "No one is FORCED to eat, pay >>rent, get a job, etc." So I don't buy this argument. A friend of mine >>once had some of his expensive stereo equipment fried by a surge from >>the electric company. He asked the electric company to pay damages but >>they refused. One could say: "You don't HAVE to buy electricity from >>them". You see the point? > > > Not really. In practice, one usually doesn't have a choice which > electric company to buy electricity from. Also, I would say that, these > days, electricity is a "basic need" while that is not true of a record > contract. My point was that, in contrast to even 10 years ago, anyone > who wants to distribute his recordings via the internet can do so, > without a record company. If all record companies don't have anything > but unfair contracts on offer, surely this means there is a market for a > better record company? Will the big boys send over their axe-men if I > set one up? > The big boys will scarcely notice you. The public will scarcely notice you! Unless you are extremely lucky, you will probably lose your shirt. Most of the music you could record would have a useful life of three to six months! Most of the music composed and performed today is tomorrow's garbage. How many of the tunes recorded in the early 1950s would anyone want to listen to today? One tenth of one percent would probably be a generous estimate. If you played some of that shit over the PA system in a prison, you'd probably be sued for "cruel and unusual punishment"! If you are lucky enough to acquire the rights to to a "smash hit", you will have to defend those rights against electronic copies being passed from hand to hand. I think I could send you a song from my cellular phone if you had a compatible device to receive it! I wouldn't, because I don't HAVE any music on my cell phone even though the device is capable of storing it and playing it if I wanted to pay for the download. The last I heard it cost about $1500 to master a CD plus one dollar per copy. This is just the cost of physically producing it. Silk screening the label (Black) is extra. More than one color on the label costs extra. The $1500 does NOT include purchasing reproduction rights to the contents. It also does not include the cost of the "jewel case", the printed insert, the cost of advertising, etc. You might be able to sell it for $15. It doesn't look to me like a reasonable way to get rich unless you can get a million suckers to buy a copy each! ------------------------------ Date: Thu, 03 Jan 2008 15:04:43 -0500 From: JF Mezei Subject: Re: OT: The penultimate legal schmuckery of 2007. Message-ID: <477d4062$0$4317$c3e8da3@news.astraweb.com> Phillip Helbig---remove CLOTHES to reply wrote: > contract. My point was that, in contrast to even 10 years ago, anyone > who wants to distribute his recordings via the internet can do so, > without a record company. Not quite. Most well known artists are locked into contracts with the major record companies which prevent them from releasing material on their own. And when you leave a record company, you might be able to distribute low quality MP3s on the net, but you'll have a hard time getting your high quality CDs into stores and into every radio station in the world. What would be needed is some "youtube" style of web site where independant artists could publish low quality songs and a pointer to their own web site where you can get the high quality version. ------------------------------ Date: Thu, 03 Jan 2008 22:07:56 GMT From: VAXman- @SendSpamHere.ORG Subject: Re: OT: The penultimate legal schmuckery of 2007. Message-ID: <01dfj.6$JK4.0@newsfe11.lga> In article <477d4062$0$4317$c3e8da3@news.astraweb.com>, JF Mezei writes: >{...snip...} >Not quite. Most well known artists are locked into contracts with the >major record companies which prevent them from releasing material on ^^^^^ >their own. The big (bad) 4... Sony, EMI, Universal and Warner. There are MANY indie labels. A boon to the small artist who will not be signed by the big (bad) 4 because they don't fit the current mould of the pablum they are feeding this week. -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM "Well my son, life is like a beanstalk, isn't it?" http://tmesis.com/drat.html ------------------------------ Date: Thu, 03 Jan 2008 22:33:07 GMT From: John Santos Subject: Re: Question about INSTALLing shared images Message-ID: AEF wrote: > On Jan 2, 9:44 pm, D Gillbilly wrote: > >>On 2 Jan 2008 07:53:53 -0600, koeh...@eisner.nospam.encompasserve.org (Bob >> >>Koehler) wrote: >> >>>In article , AEF writes: >> >>>>When you INSTALL an executable as a shared image, can it be any >>>>executable? I once discussed this with my developer for a program run >>>>by multiple traders and he said we'd have to check for traders >>>>stepping on each other, so to speak. So my question is: Doesn't VMS >>>>automatically provide each process running shared executable its own >>>>private data area in memory or does the program have to be explicitly >>>>written with the assumption that it will be installed shared? >> >>> Each image is broken up into program sections (PSECTs). PSECTs can >>> be read only, writeable, shareable, ... >> >>> You need to look at the LINK map >> >> I once installed an image with one psect incorrectly marked as SHR. >> Oops. >> >> Duane >> >> >>> and verify that you don't have any >>> PSECTs that are both writeable and shareable. If that's true you >>> can install /shared and you will use less physical RAM. If that's >>> not then you can re-LINK the image using a linker options file to >>> change the PSECT characteristics. >> >>> The older Fortran compilers for VAXen made all the COMMON blocks >>> shareable and writeable. Current Fortran compilers and other >>> language compilers don't tend to do this. Many compilers have ways >>> of specifying this in the source code, so you don't have to use >>> linker options. > > > Thanks every one for your answers. > > It looks like I better abort. My developer isn't going to be assigned > time for this at this time. Thanks again! > > AEF Abort? I think the odds are about 99.9999% that it would be fine. If you "install add/share/header/open" and then do "install list/global" on the image, you will see whether or not there are any writable shared sections. (Writable non-shared sections will be copy-on- reference.) If there are none, then you're fine. If you want to test a particular image before installing it, copy it to a test directory under a different name, install the copy, and check. If okay, then uninstall and delete the copy, and install the original. If not okay, uninstall and delete the copy, and add it to your list of things to fix someday. -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 ------------------------------ Date: Thu, 3 Jan 2008 13:05:24 -0600 (CST) From: sms@antinode.org (Steven M. Schweda) Subject: Re: upgrading from 7.3-2 Message-ID: <08010313052451_206002CA@antinode.org> From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) > After some distractions, I hope I will find time soon to upgrade from > 7.3-2. What version do folks recommend I upgrade to? V8.3. ("-1" for IA64.) > Can I get there > directly from 7.3-2? Yes. (But why trust me? Check the official docs.) > I have no Itanium yet, but do have VAX at 7.3. > Any news of a newer VMS for VAX? You would have heard about it before now. > What will stop working after the > upgrade (MONITOR?)? PATHWORKS for Macintosh. > What version of TCPIP for ALPHA should I aim for > after the VMS upgrade? The one which comes with VMS V8.3 (V5.6). Look for ECO kits, too. ------------------------------------------------------------------------ Steven M. Schweda sms@antinode-org 382 South Warwick Street (+1) 651-699-9818 Saint Paul MN 55105-2547 ------------------------------ Date: Thu, 3 Jan 2008 19:48:17 +0000 (UTC) From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) Subject: Re: upgrading from 7.3-2 Message-ID: In article <08010313052451_206002CA@antinode.org>, sms@antinode.org (Steven M. Schweda) writes: > > What version of TCPIP for ALPHA should I aim for > > after the VMS upgrade? > > The one which comes with VMS V8.3 (V5.6). Sometimes a new version of TCPIP comes out before a new version of VMS does, so I want to avoid picking up an old distribution with a too old TCPIP. > Look for ECO kits, too. I'm always pretty much up to date on those. ------------------------------ End of INFO-VAX 2008.007 ************************