INFO-VAX Fri, 16 Nov 2007 Volume 2007 : Issue 627 Contents: "Mysterious" system crashes Re: "Mysterious" system crashes Re: "Mysterious" system crashes Re: "Mysterious" system crashes Re: "Mysterious" system crashes Re: "Mysterious" system crashes Re: "Mysterious" system crashes Re: "Mysterious" system crashes Re: "Mysterious" system crashes Re: "Mysterious" system crashes Re: "Mysterious" system crashes Re: "Mysterious" system crashes CISM - Cert. Exam Is VMS 8.3 available for hobbyist users and can it be installed on amd64 ( anybo Re: Is VMS 8.3 available for hobbyist users and can it be installed on amd64 ( a MIME utility buglet OT: YouTube on The day the Routers Died Re: Status of the VMS Hobbyist media kit(s) ? Re: Status of the VMS Hobbyist media kit(s) ? Re: Status of the VMS Hobbyist media kit(s) ? Re: system constants in COBOL Re: system constants in COBOL Re: system constants in COBOL Re: system constants in COBOL Re: system constants in COBOL Re: system constants in COBOL Re: system constants in COBOL Re: system constants in COBOL The NBA and VMS VAX design out of fashion ? Maybe not. Re: VIOC: sizing and performance Re: VIOC: sizing and performance Re: VIOC: sizing and performance Re: VIOC: sizing and performance Re: VIOC: sizing and performance ---------------------------------------------------------------------- Date: Thu, 15 Nov 2007 18:23:57 -0500 From: bradhamilton Subject: "Mysterious" system crashes Message-ID: <473CD50D.70109@comcast.net> Hello all, Environment: Digital PWS433au VMS V8.3 with the following patches: UPDATE V4 SYS V5 LAN V2 TCPware V5.7-2, with all required patches This is a home hobbyist system. I've been experiencing "mysterious" system reboots each day for the past four days (when I say "mysterious", I mean that there is no CLUE$*.LIS files in sys$errorlog, and no entries in the CLUE$history.dat file, either). There are no console error messages that appear before the crashes. These crashes happen while I am away at work, so I guess the system misses me. :-) They do not happen at the same time each day, and questioning of family members that are home at the time reveal no unusual "power" glitches. I recently patched the system each day after the crashes, with the OS patches listed above. I have now downloaded SHADOWING V1 and FIBRE_SCSI V3 (and will patch/reboot the system shortly), in a last desperate attempt to abate the (seemingly) inevitable daily crash. A quick scan of the ITRC OpenVMS forum entries for the past 3 weeks reveal nothing. Has anyone out there seen a "footprint" like this recently? My apologies in advance for asking a technical question in this forum, :-) but I feel a sense of loyalty to this group, and I want to give you folks first crack at this before I venture onto ITRC. TIA ------------------------------ Date: Thu, 15 Nov 2007 15:46:33 -0800 (PST) From: Rich Jordan Subject: Re: "Mysterious" system crashes Message-ID: <496afec4-6c0c-427e-a0c9-c6b5c172ca3b@d61g2000hsa.googlegroups.com> On Nov 15, 5:23 pm, bradhamilton wrote: > Hello all, > > Environment: > > Digital PWS433au > VMS V8.3 with the following patches: > UPDATE V4 > SYS V5 > LAN V2 > TCPware V5.7-2, with all required patches > > This is a home hobbyist system. I've been experiencing "mysterious" > system reboots each day for the past four days (when I say "mysterious", > I mean that there is no CLUE$*.LIS files in sys$errorlog, and > no entries in the CLUE$history.dat file, either). There are no console > error messages that appear before the crashes. > > These crashes happen while I am away at work, so I guess the system > misses me. :-) They do not happen at the same time each day, and > questioning of family members that are home at the time reveal no > unusual "power" glitches. > > I recently patched the system each day after the crashes, with the OS > patches listed above. I have now downloaded SHADOWING V1 and FIBRE_SCSI > V3 (and will patch/reboot the system shortly), in a last desperate > attempt to abate the (seemingly) inevitable daily crash. > > A quick scan of the ITRC OpenVMS forum entries for the past 3 weeks > reveal nothing. > > Has anyone out there seen a "footprint" like this recently? My > apologies in advance for asking a technical question in this forum, > > :-) > > but I feel a sense of loyalty to this group, and I want to give you > folks first crack at this before I venture onto ITRC. > > TIA My DS10-L acted like this with faulty memory DIMMs in it. I understand a failing power supply _can_ do this also but in my case the system hung rather than rebooted. Over time mine got worse and worse until it would only start to boot before failing (and I found out I had a faulty main logic board too after the DIMMs were replaced so thats also a possibility). I'd do a preventative maintenance. Open it up, clean out the dust bunnies, clear the fans and grilles, reseat cards, connectors, and cables, reseat the DIMMs, etc. As long as your careful it shouldn't hurt and just might help. ------------------------------ Date: Thu, 15 Nov 2007 19:09:07 -0500 From: bradhamilton Subject: Re: "Mysterious" system crashes Message-ID: <473CDFA3.7040306@comcast.net> Rich Jordan wrote: > On Nov 15, 5:23 pm, bradhamilton wrote: [...] > My DS10-L acted like this with faulty memory DIMMs in it. I > understand a failing power supply _can_ do this also but in my case > the system hung rather than rebooted. Over time mine got worse and > worse until it would only start to boot before failing (and I found > out I had a faulty main logic board too after the DIMMs were replaced > so thats also a possibility). > > I'd do a preventative maintenance. Open it up, clean out the dust > bunnies, clear the fans and grilles, reseat cards, connectors, and > cables, reseat the DIMMs, etc. As long as your careful it shouldn't > hurt and just might help. Hi Rich, Thanks for the suggestion - I'll schedule a PM this weekend, and I might do a cursory external cleaning of the grilles and fan before then. Of course, my system runs in a "clean-room" environment, with filtered power supplies and plenty-o'-AC, so that *can't* be the problem. :-) ------------------------------ Date: Thu, 15 Nov 2007 20:08:04 -0500 From: "Richard B. Gilbert" Subject: Re: "Mysterious" system crashes Message-ID: <473CED74.2010303@comcast.net> bradhamilton wrote: > Hello all, > > Environment: > > Digital PWS433au > VMS V8.3 with the following patches: > UPDATE V4 > SYS V5 > LAN V2 > TCPware V5.7-2, with all required patches > > This is a home hobbyist system. I've been experiencing "mysterious" > system reboots each day for the past four days (when I say "mysterious", > I mean that there is no CLUE$*.LIS files in sys$errorlog, and > no entries in the CLUE$history.dat file, either). There are no console > error messages that appear before the crashes. > > These crashes happen while I am away at work, so I guess the system > misses me. :-) They do not happen at the same time each day, and > questioning of family members that are home at the time reveal no > unusual "power" glitches. > > I recently patched the system each day after the crashes, with the OS > patches listed above. I have now downloaded SHADOWING V1 and FIBRE_SCSI > V3 (and will patch/reboot the system shortly), in a last desperate > attempt to abate the (seemingly) inevitable daily crash. > > A quick scan of the ITRC OpenVMS forum entries for the past 3 weeks > reveal nothing. > > Has anyone out there seen a "footprint" like this recently? My > apologies in advance for asking a technical question in this forum, > > :-) > > but I feel a sense of loyalty to this group, and I want to give you > folks first crack at this before I venture onto ITRC. > > TIA Do you have a dump file? SYS$SYSTEM:SYSDUMP.DMP Is a dump being written to it? Note that your family might not even notice a "power glitch" that could cause a computer to reboot. Invest in a UPS. Small units, suitable for PCs and workstations can frequently be found at flea markets or yard sales. I've seen them up to 1000 VA. If you buy used you may have to replace the battery which, depending on the size of the unit, may cost you anywhere from $25 to $100 US. Note that automobile batteries are NOT suitable for this service!!! ------------------------------ Date: Thu, 15 Nov 2007 20:36:28 -0500 From: bradhamilton Subject: Re: "Mysterious" system crashes Message-ID: <473CF41C.1060500@comcast.net> Richard B. Gilbert wrote: [...] > Do you have a dump file? SYS$SYSTEM:SYSDUMP.DMP > Is a dump being written to it? RABBIT::SYSTEM$ dir/dat=(cre,mod) sys$system:sysdump.dmp Directory SYS$SYSROOT:[SYSEXE] SYSDUMP.DMP;2 245215/245248 28-DEC-2002 23:33:40.29 12-NOV-2006 22:20 :02.28 Not for a year or so... > Note that your family might not even notice a "power glitch" that could > cause a computer to reboot. True. After the second question this evening, my wife asked, "No we haven't had a power problem - why? Are you expecting one??" :-) She always gets a glazed-over look in her eye when my explanations are too detailed or technical, so I've learned to keep my questions (and answers) simple. :-) :-) > Invest in a UPS. Small units, suitable for PCs and workstations can > frequently be found at flea markets or yard sales. I've seen them up to > 1000 VA. If you buy used you may have to replace the battery which, > depending on the size of the unit, may cost you anywhere from $25 to > $100 US. Note that automobile batteries are NOT suitable for this > service!!! Yes, I've thought about the "small" APC units that I see for sale at HW stores, but I've never experienced these problems until this week, so I never saw a need for one. I guess I'll price some units (keeping in mind that I need to match capacity with my estimated power draw from the CPU, disks and disk shelves). My wife keeps asking me what I want for Yule - perhaps I have a legitimate need... ------------------------------ Date: Thu, 15 Nov 2007 20:46:51 -0500 From: "Richard B. Gilbert" Subject: Re: "Mysterious" system crashes Message-ID: <473CF68B.4060607@comcast.net> bradhamilton wrote: > Richard B. Gilbert wrote: > [...] > >> Do you have a dump file? SYS$SYSTEM:SYSDUMP.DMP >> Is a dump being written to it? > > > RABBIT::SYSTEM$ dir/dat=(cre,mod) sys$system:sysdump.dmp > > Directory SYS$SYSROOT:[SYSEXE] > > SYSDUMP.DMP;2 245215/245248 28-DEC-2002 23:33:40.29 > 12-NOV-2006 22:20 > :02.28 > > Not for a year or so... > >> Note that your family might not even notice a "power glitch" that could >> cause a computer to reboot. > > > True. > > After the second question this evening, my wife asked, "No we haven't > had a power problem - why? Are you expecting one??" :-) > > She always gets a glazed-over look in her eye when my explanations are > too detailed or technical, so I've learned to keep my questions (and > answers) simple. :-) :-) > >> Invest in a UPS. Small units, suitable for PCs and workstations can >> frequently be found at flea markets or yard sales. I've seen them up >> to 1000 VA. If you buy used you may have to replace the battery >> which, depending on the size of the unit, may cost you anywhere from >> $25 to $100 US. Note that automobile batteries are NOT suitable for >> this service!!! > > > Yes, I've thought about the "small" APC units that I see for sale at HW > stores, but I've never experienced these problems until this week, so I > never saw a need for one. I guess I'll price some units (keeping in > mind that I need to match capacity with my estimated power draw from the > CPU, disks and disk shelves). My wife keeps asking me what I want for > Yule - perhaps I have a legitimate need... > "Disk Shelves" implies a rather large installation. How many VA for the whole thing? ------------------------------ Date: Thu, 15 Nov 2007 20:22:05 -0600 From: "Joe H. Gallagher" Subject: Re: "Mysterious" system crashes Message-ID: <13jpvmcn5ds4c8e@corp.supernews.com> bradhamilton wrote: > Hello all, > > Environment: > > Digital PWS433au > VMS V8.3 with the following patches: > UPDATE V4 > SYS V5 > LAN V2 > TCPware V5.7-2, with all required patches > > This is a home hobbyist system. I've been experiencing "mysterious" > system reboots each day for the past four days (when I say "mysterious", > I mean that there is no CLUE$*.LIS files in sys$errorlog, and > no entries in the CLUE$history.dat file, either). There are no console > error messages that appear before the crashes. > > These crashes happen while I am away at work, so I guess the system > misses me. :-) They do not happen at the same time each day, and > questioning of family members that are home at the time reveal no > unusual "power" glitches. > > I recently patched the system each day after the crashes, with the OS > patches listed above. I have now downloaded SHADOWING V1 and FIBRE_SCSI > V3 (and will patch/reboot the system shortly), in a last desperate > attempt to abate the (seemingly) inevitable daily crash. > > A quick scan of the ITRC OpenVMS forum entries for the past 3 weeks > reveal nothing. > > Has anyone out there seen a "footprint" like this recently? My > apologies in advance for asking a technical question in this forum, > > :-) > > but I feel a sense of loyalty to this group, and I want to give you > folks first crack at this before I venture onto ITRC. > > TIA Since you are not running a production system, I suggest that you run some hardware diagnostics to try to "beat the hell" out of the CPU, memory, and I/O bus to see if you get any failures when "VMS" is not running. "Mysterious" system crashes suggest possible hardware issue(s). In any event, it would be nice to KNOW that the cpu, memory, and I/O controllers are "rock solid" before trying to track down any possible flaky software. While you are at work, the hobbyist system has plenty of time to .... When some things don't work 'right', it is really helpful to know which ones of the pieces and parts ARE working correctly. I suggest running the diagnostics 2 to 4 time as long as the average failure time you are currently experiencing. And , yes, an appropriate small UPS is a good suggestion to rule out power issues. Good luck at isolating this problem! Joe H. Gallagher, Ph. D. Former DATATRIEVE/4GL SIG Chair/Newsletter Editor Former WRUG LUG Chair ------------------------------ Date: Thu, 15 Nov 2007 21:34:38 -0500 From: bradhamilton Subject: Re: "Mysterious" system crashes Message-ID: <473D01BE.6040202@comcast.net> Richard B. Gilbert wrote: [...] >> Yes, I've thought about the "small" APC units that I see for sale at >> HW stores, but I've never experienced these problems until this week, >> so I never saw a need for one. I guess I'll price some units (keeping >> in mind that I need to match capacity with my estimated power draw >> from the CPU, disks and disk shelves). My wife keeps asking me what I >> want for Yule - perhaps I have a legitimate need... >> > > "Disk Shelves" implies a rather large installation. How many VA for the > whole thing? PWS433au: 100-120 VAC 5.5A (550-660 VA?) 2 fully-populated BA356 (top-gun blue) shelves: 100-120 VAC 7.0A (1400-1680 VA?) For an approximate total of: 1950-2340 VA Assuming my math is not too far off, then approximately $675-750 for an APC rated at 2500 VA. Out of my price range as a mere hobbyist. :-( ------------------------------ Date: Thu, 15 Nov 2007 21:46:39 -0500 From: Robert Deininger Subject: Re: "Mysterious" system crashes Message-ID: In article <473CF41C.1060500@comcast.net>, bradhamilton wrote: > Richard B. Gilbert wrote: > [...] > > Do you have a dump file? SYS$SYSTEM:SYSDUMP.DMP > > Is a dump being written to it? > > RABBIT::SYSTEM$ dir/dat=(cre,mod) sys$system:sysdump.dmp > > Directory SYS$SYSROOT:[SYSEXE] > > SYSDUMP.DMP;2 245215/245248 28-DEC-2002 23:33:40.29 > 12-NOV-2006 22:20 > :02.28 > > Not for a year or so... Dunno if the modification date on the file is a good indicator. Use ANALYZE/CRASH to see what, if anything, is in the dump file. When you can tolerate downtime, force a crash, and verify that the dump is written to the dump file as it should be. If there are any problems with this, fix them. -- Robert ------------------------------ Date: Thu, 15 Nov 2007 21:54:39 -0500 From: bradhamilton Subject: Re: "Mysterious" system crashes Message-ID: <473D066F.40903@comcast.net> Now that I've had some time to think about this, another possibility comes to mind... The Alpha is located in a small workshop room, off of our home "office". The office has no heating ducts, and is located next to the kitchen, so to keep the office warm, we use a combination of: Opening the kitchen door, and using an oil-filled electric heater (one that looks like an old-fashioned steam radiator). My wife works nights, so she gets up between 3-5 PM, and opens the kitchen door, and turns on the electric heater, to warm up the office. She's at work right now, so I can't ask her, but tomorrow I'll ask her what time she performed those activities on the last three days, and I'll ask her to hold off the "ritual" until after I come home from work tomorrow night... Assuming my suspicion is correct, why did this only start happening a few days ago? We've been running the heater in that "pattern" for a month or so now... ------------------------------ Date: Thu, 15 Nov 2007 21:58:45 -0500 From: bradhamilton Subject: Re: "Mysterious" system crashes Message-ID: <473D0765.2050904@comcast.net> Robert Deininger wrote: > In article <473CF41C.1060500@comcast.net>, > bradhamilton wrote: > >> Richard B. Gilbert wrote: >> [...] >>> Do you have a dump file? SYS$SYSTEM:SYSDUMP.DMP >>> Is a dump being written to it? >> RABBIT::SYSTEM$ dir/dat=(cre,mod) sys$system:sysdump.dmp >> >> Directory SYS$SYSROOT:[SYSEXE] >> >> SYSDUMP.DMP;2 245215/245248 28-DEC-2002 23:33:40.29 >> 12-NOV-2006 22:20 >> :02.28 >> >> Not for a year or so... > > Dunno if the modification date on the file is a good indicator. > > Use ANALYZE/CRASH to see what, if anything, is in the dump file. Hi Robert, Just an old crash from July of this year (unrelated). See my latest post in this thread for a possible hypothesis... [...] ------------------------------ Date: Fri, 16 Nov 2007 01:33:52 -0500 From: JF Mezei Subject: Re: "Mysterious" system crashes Message-ID: <9fb3d$473d39d1$cef8887a$31145@TEKSAVVY.COM> bradhamilton wrote: > Assuming my suspicion is correct, why did this only start happening a > few days ago? We've been running the heater in that "pattern" for a > month or so now... Do you have an electronic voltage meter for AC lines ? Utilities sometimes drop voltages when the power load is very high as this reduces demand. (although this is not true for compact fluorescent and switched power supplies, but was true of incadescent, ovens and conventional electric heating). A deffective/old transformer that serves your house may also end up proviing lower than expected voltages, and if the computer's power suppl y is getting old, it could explain. Another possibility is lint accumulating in your computer's navel(s) and when your wife turns on the heater, it causes the temperature in the computer to rise to a point when it automatically shuts off. The temperature range isn't very high between normal operating temperature (about 40-48-C) and the default shutoff at 55°C. So if ventilation is poor and you have a heater near the unit that causes warmer than usual air being sucked into the computer, it could explain it. ------------------------------ Date: Thu, 15 Nov 2007 14:43:07 -0500 From: Chuck Aaron Subject: CISM - Cert. Exam Message-ID: Has anyone taken this exam during 2007? Thanks, Chuck ------------------------------ Date: Thu, 15 Nov 2007 17:40:59 -0800 (PST) From: siju Subject: Is VMS 8.3 available for hobbyist users and can it be installed on amd64 ( anybo Message-ID: <6bd248a2-fb26-4506-aa35-6ba42c6f3ff2@l22g2000hsc.googlegroups.com> Hi, The last time I checked http://groups.google.com/group/comp.os.vms/browse_thread/thread/9afeaa57bafb66b/7434358826b1a9e6?lnk=st&q=simh#7434358826b1a9e6 OpenVMS was not download able from any where. has this changed recently? Can hobbyist users get version 8.3 and can it be installed on amd64 since it runs on IA64? Is there anybody here from India? who could lend me the hobbyist CD? Thank you so much Kind Regards Siju ------------------------------ Date: Thu, 15 Nov 2007 19:44:25 -0700 From: "Michael D. Ober" Subject: Re: Is VMS 8.3 available for hobbyist users and can it be installed on amd64 ( a Message-ID: <13jq10a6pj392f0@corp.supernews.com> IA64 is the Itanium family of processors. The AMD64 is based on the Intel 386 and the Intel x64 instruction set. So no, VMS will not run on an AMD64 processor. Mike. "siju" wrote in message news:6bd248a2-fb26-4506-aa35-6ba42c6f3ff2@l22g2000hsc.googlegroups.com... > Hi, > > The last time I checked > > http://groups.google.com/group/comp.os.vms/browse_thread/thread/9afeaa57bafb66b/7434358826b1a9e6?lnk=st&q=simh#7434358826b1a9e6 > > OpenVMS was not download able from any where. > has this changed recently? > > Can hobbyist users get version 8.3 and can it be installed on amd64 > since it runs on IA64? > > Is there anybody here from India? who could lend me the hobbyist CD? > > Thank you so much > > Kind Regards > > Siju > > ------------------------------ Date: Fri, 16 Nov 2007 01:27:16 -0500 From: JF Mezei Subject: MIME utility buglet Message-ID: <5be9a$473d3846$cef8887a$31027@TEKSAVVY.COM> MC MIME SYS$LOGIN:TEMP.MIME MIME> LIST MIME> list Message Headers: Content-Type: multipart/alternative Content-Transfer-Encoding: 7bit/8Bit ASCII Attachment: 1 Content-Type: text/plain Content-Transfer-Encoding: Base64 Attachment: 2 Content-Type: text/html Content-Transfer-Encoding: Base64 MIME> extract/att=1 sys$output: %MIME-E-FILEERROR, file error: Filename requires a file type delimiter, '.' %MIME-I-NOEXTRACT, attachment was not extracted Since more and more emails unfortunatly and stupidly get their simple text encoded in base64 for some absolutely silly reason, one needs MIME more and more to read simple emails. It should be possible to get the output of mime to go to one's screen without Mime making serious complaints. The first time I attempted this, due to the silly SMG screen management that is used, part of the text of the message was overwritten by the error message (and in this case, it was a 3 line text message). Interestingly, it says that the attachement was not extracted, but it does get displayed on the screen. Perhaps VMS managemt can argue that the MIME is middleware and not an edn user application and this make make it easier to justify deploying a few man hours to fix this. (and please remove the SMG stuff from it). And I just found out that my new handset now sends simple text emails as UTF-8 character set encoded as BAS64. Bewaark. I assume that there is no hope in getting the GUI MAILI application updated to support the varous text encodings ? I don't want to see support for HTML. But I wouldn't mind being able to click on a button on the menu bar to get the app to convert quoted printable and base64 text/plain contents and attachements so we can read them. One of the big advantages of the GUI MAIL app over firefox and others and that you can truly see the full headers and unformatted contents before you can decide whether it is worth to decode that message for display or not. ------------------------------ Date: Fri, 16 Nov 2007 01:13:44 -0500 From: JF Mezei Subject: OT: YouTube on The day the Routers Died Message-ID: <226a2$473d3521$cef8887a$30668@TEKSAVVY.COM> If you have a few minutes to wait for a compile on your all mighty Microvax II or Alpha server: http://www.youtube.com and search for "The day the routers died" and choose the one from RIPENCC . If you click on the "more" for the About this Video, all the lyrics are shown. Have a nice friday. (and no, this won't run on VMS). (and for absolutely truly OT, do a search for "Bangkong market", you see a train go through a market in asia, very impressive). ------------------------------ Date: Thu, 15 Nov 2007 15:02:49 -0500 From: JF Mezei Subject: Re: Status of the VMS Hobbyist media kit(s) ? Message-ID: <78f4a$473ca5ee$cef8887a$2065@TEKSAVVY.COM> Jan-Erik Söderholm wrote: > HP is asking aprox $1000 USD localy over here > in Sweden for a LP-kit... If you send me an email for what individual packages you want, I may make it possible for you to accidentally stumble on those kits while trying your FTP software. Specify vax or alpha. ------------------------------ Date: Thu, 15 Nov 2007 20:38:54 +0000 (UTC) From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) Subject: Re: Status of the VMS Hobbyist media kit(s) ? Message-ID: In article , =?ISO-8859-1?Q?Jan-Erik_S=F6derholm?= writes: > Got a personal mail from Steven M. Schweda, but his/your > mail system rejected my reply. > > - SMTP protocol diagnostic: 550 Your IP address or > subnet is in my list of bad ones. > > I'm using the largets ISP in Sweden, and I do not > have any mail problems otherwise. Sounds like your IP address is in a list of bad clients. Do you have a dynamic IP address? If so, that probably means a previous user of that address sent spam and thus the IP address was put on a list of bad addresses. With spam as prevalent as it is, a provider needs to force customers to send email through a special SMTP server. The provider can block spam sent through it and thus keep it off black lists. Even if your provider doesn't require it (and I think he should), see if you can find a trusted SMTP server to send mail through. I'm not quite that aggressive, but have resorted to using a public RBL to keep out spam. Running my own SMTP server on my VMS cluster, I get about 6000 connections per day. About 95% of those are dropped due to being on an RBL. Of the other 300, 200 are to non-existent users. Of the remaining 100, perhaps 20 are legitimate and the rest spam. ------------------------------ Date: 15 Nov 2007 20:46:42 GMT From: billg999@cs.uofs.edu (Bill Gunshannon) Subject: Re: Status of the VMS Hobbyist media kit(s) ? Message-ID: <5q3phhFsrttcU1@mid.individual.net> In article , helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) writes: > In article , > =?ISO-8859-1?Q?Jan-Erik_S=F6derholm?= > writes: > >> Got a personal mail from Steven M. Schweda, but his/your >> mail system rejected my reply. >> >> - SMTP protocol diagnostic: 550 Your IP address or >> subnet is in my list of bad ones. >> >> I'm using the largets ISP in Sweden, and I do not >> have any mail problems otherwise. > > Sounds like your IP address is in a list of bad clients. Do you have a > dynamic IP address? If so, that probably means a previous user of that > address sent spam and thus the IP address was put on a list of bad > addresses. Not necessarily. If it is a dynamic address the entire dynamic block is most likely in the list. Individula machines sohuld never try to be an MTA because with the number of zombied machines the chances of someone accepting their email is real low and dropping more everyday. Some of us look forward to the day when no individual machine will be allowed to send mail to anything but their local ISP's MTA, which is how it should have been all along. > With spam as prevalent as it is, a provider needs to force > customers to send email through a special SMTP server. The provider can > block spam sent through it and thus keep it off black lists. Even if > your provider doesn't require it (and I think he should), see if you can > find a trusted SMTP server to send mail through. You would be amazed at how many major ISP's have some (if not all) of their MTA's blacklisted because they eiter don't care or are making too much profit supporting SPAMers. > > I'm not quite that aggressive, but have resorted to using a public RBL > to keep out spam. Running my own SMTP server on my VMS cluster, I get > about 6000 connections per day. About 95% of those are dropped due to > being on an RBL. Of the other 300, 200 are to non-existent users. Of > the remaining 100, perhaps 20 are legitimate and the rest spam. I get more aggressive with SPAM filtering on our MTA everyday and even at that the amount of SPAM that gets through is still going up. They can adapt just as quickly as we can. 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: Thu, 15 Nov 2007 11:25:58 -0800 (PST) From: Hein RMS van den Heuvel Subject: Re: system constants in COBOL Message-ID: <2c9e47bd-dd4d-4da9-9b62-9ec0deda8fde@w34g2000hsg.googlegroups.com> On Nov 15, 7:56 am, koeh...@eisner.nospam.encompasserve.org (Bob Koehler) wrote: > In article <8a757094-7ea1-4d1c-ac0d-daeffb86e...@d50g2000hsf.googlegroups.com>, Hein RMS van den Heuvel writes: > > > > > Yeah,that's what folks do, > > If it was me, I'd create a DCL / Perl / Macro-defintion tool to turn > > the MACRO $xxxdef sources from STARLET,MLB into cobol include (.LIB) > > files and define the constants in the source instead of having the > > linker resolve them. > > I wouldn't since that's not a documented, supported interface and > I've seen it break in the past. So what? You just generate it once, and be happy. You gotta give the compiler a chance to optimize those constant, By using a linker resolved reference the compilers options are severly hed back imho. The constants defined in say DVIDEF are NOT going to change. They can not. Too many executables out there with those constants embedded. New ones may be added, but then the program needs to be changed anyway to use those. Just re-generate as needed, or add the new one with an editor. If the re-generation breaks, which it will not, then just fix that. Sometimes a shortcut is perfectly safe. Cheers, Hein. ------------------------------ Date: 15 Nov 2007 15:23:19 -0500 From: brooks@cuebid.zko.hp.nospam (Rob Brooks) Subject: Re: system constants in COBOL Message-ID: Hein RMS van den Heuvel writes: > (Bob Koehler) wrote: >> Hein RMS van den Heuvel writes: >> >> > Yeah,that's what folks do, >> > If it was me, I'd create a DCL / Perl / Macro-defintion tool to turn >> > the MACRO $xxxdef sources from STARLET,MLB into cobol include (.LIB) >> > files and define the constants in the source instead of having the >> > linker resolve them. >> >> I wouldn't since that's not a documented, supported interface and >> I've seen it break in the past. > > So what? You just generate it once, and be happy. [...] > > The constants defined in say DVIDEF are NOT going to change. > > They can not. Too many executables out there with those constants > embedded. In general, stuff in the STARLET library does not change, while stuff in the LIB library can change at will. While I do know of some things that have changed within STARLET (specifically, an undocumented system service changing its arguments), I'd be really surprised if a documented and supported constant or offset defined in STARLET has changed from release to release. -- Rob Brooks MSL -- Nashua brooks!cuebid.zko.hp.com ------------------------------ Date: Thu, 15 Nov 2007 13:23:30 -0800 From: "Tom Linden" Subject: Re: system constants in COBOL Message-ID: On Thu, 15 Nov 2007 11:25:58 -0800, Hein RMS van den Heuvel wrote: > On Nov 15, 7:56 am, koeh...@eisner.nospam.encompasserve.org (Bob > Koehler) wrote: >> In article >> <8a757094-7ea1-4d1c-ac0d-daeffb86e...@d50g2000hsf.googlegroups.com>, >> Hein RMS van den Heuvel writes: >> >> >> >> > Yeah,that's what folks do, >> > If it was me, I'd create a DCL / Perl / Macro-defintion tool to turn >> > the MACRO $xxxdef sources from STARLET,MLB into cobol include (.LIB) >> > files and define the constants in the source instead of having the >> > linker resolve them. >> >> I wouldn't since that's not a documented, supported interface and >> I've seen it break in the past. > > > So what? You just generate it once, and be happy. > > You gotta give the compiler a chance to optimize those constant, > By using a linker resolved reference the compilers options are severly > hed back imho. Huh? Unless I misunderstood the constants are dealt with by the parser and never get to the linker. > > The constants defined in say DVIDEF are NOT going to change. > > They can not. Too many executables out there with those constants > embedded. > > New ones may be added, but then the program needs to be changed anyway > to use those. Just re-generate as needed, or add the new one with an > editor. > > If the re-generation breaks, which it will not, then just fix that. > > Sometimes a shortcut is perfectly safe. > > Cheers, > Hein. -- PL/I for OpenVMS www.kednos.com ------------------------------ Date: Thu, 15 Nov 2007 14:38:20 -0800 (PST) From: Hein RMS van den Heuvel Subject: Re: system constants in COBOL Message-ID: On Nov 15, 3:23 pm, "Tom Linden" wrote: > On Thu, 15 Nov 2007 11:25:58 -0800, Hein RMS van den Heuvel > > You gotta give the compiler a chance to optimize those constant, > > By using a linker resolved reference the compilers options are severly > > hed back imho. > > Huh? Unless I misunderstood the constants are dealt with by the parser > and never get to the linker. But that's exactly my point. It should be the parser seeing the numeric values and the cobol optimizer to do the right thing. But these lame cobol programs stick it into an '88' and let the linker fill in the value. That will increase the code size slightly (notably for values like 0 and 1, less so for RMS$_FNF) What is worse the extra code will be a memory reference. Here is sample generated code (source below) 8 01 RETURN-STATUS PIC S9(09) COMP. 9 88 SYS$_NORMAL VALUE IS EXTERNAL SS$_NORMAL. 10 88 SYS__NORMAL VALUE IS 1. 11 88 RMS$_FNF VALUE IS EXTERNAL RMS$_FNF. 12 88 RMS__FNF VALUE IS 98962. 13 01 X PIC S9(9) COMP. 14 PROCEDURE DIVISION. 15 P0. CALL "TEST" GIVING RETURN-STATUS. 16 IF SYS$_NORMAL THEN MOVE 123 to X. 17 IF SYS__NORMAL THEN MOVE 345 to X. 18 IF RMS$_FNF THEN MOVE 567 to X. 19 IF RMS__FNF THEN MOVE 789 to X. : JSR R26, TEST LDQ R1, 56(R2) ; 000016 MOV 123, R17 LDL R16, (R1) XOR RETURN-STATUS, R16, R16 BNE R16, L$1 STL R17, -8(R3) L$1: XOR RETURN-STATUS, 1, R19 ; 000017 BNE R19, L$3 MOV 345, R20 STL R20, -8(R3) L$3: LDL R1, -4(R1) ; 000018 XOR RETURN-STATUS, R1, R1 BNE R1, L$5 MOV 567, R22 STL R22, -8(R3) L$5: LDAH R24, 2(R31) ; 000019 MOV 789, R25 LDA R24, -32110(R24) XOR RETURN-STATUS, R24, R0 BNE R0, L$7 STL R25, -8(R3) L$7: LDQ R26, 96(R2) ; 000020 See the straight 1 in XOR for line 17? Compare that with the LDQ R1, 56(R2) to fetch SS$_NORMAL ! For FNF as a literal it uses: LDA R24, -32110(R24) So that is also NOT a memory reference, but a clever instruction. Specially for SS$_NORMAL it is ludicrous to have the linker fill it in. An insult to the injury of not just doing an BLBS ("IF SUCCES") Cheers, Hein van den Heuvel HvdH Performance Consulting IDENTIFICATION DIVISION. PROGRAM-ID. LNM. ENVIRONMENT DIVISION. CONFIGURATION SECTION. DATA DIVISION. WORKING-STORAGE SECTION. 01 IO$_READVBLK PIC S9(09) COMP VALUE IS EXTERNAL IO$_READVBLK. 01 RETURN-STATUS PIC S9(09) COMP. 88 SYS$_NORMAL VALUE IS EXTERNAL SS$_NORMAL. 88 SYS__NORMAL VALUE IS 1. 88 RMS$_FNF VALUE IS EXTERNAL RMS$_FNF. 88 RMS__FNF VALUE IS 98962. 01 X PIC S9(9) COMP. PROCEDURE DIVISION. P0. CALL "TEST" GIVING RETURN-STATUS. IF SYS$_NORMAL THEN MOVE 123 to X. IF SYS__NORMAL THEN MOVE 345 to X. IF RMS$_FNF THEN MOVE 567 to X. IF RMS__FNF THEN MOVE 789 to X. DISPLAY X. END PROGRAM LNM. ------------------------------ Date: Thu, 15 Nov 2007 15:11:07 -0800 From: "Tom Linden" Subject: Re: system constants in COBOL Message-ID: On Thu, 15 Nov 2007 14:38:20 -0800, Hein RMS van den Heuvel wrote: > On Nov 15, 3:23 pm, "Tom Linden" wrote: >> On Thu, 15 Nov 2007 11:25:58 -0800, Hein RMS van den Heuvel >> > You gotta give the compiler a chance to optimize those constant, >> > By using a linker resolved reference the compilers options are severly >> > hed back imho. >> >> Huh? Unless I misunderstood the constants are dealt with by the parser >> and never get to the linker. > > But that's exactly my point. It should be the parser seeing the > numeric values > and the cobol optimizer to do the right thing. So this Cobol does not have the concept of include statements with replace constants? That is lame. If done correctly it should never even get to the optimizer. > > But these lame cobol programs stick it into an '88' and let the linker > fill in the value. > That will increase the code size slightly (notably for values like 0 > and 1, less so for RMS$_FNF) > What is worse the extra code will be a memory reference. > > > Here is sample generated code (source below) > 8 01 RETURN-STATUS PIC S9(09) COMP. > 9 88 SYS$_NORMAL VALUE IS EXTERNAL SS$_NORMAL. > 10 88 SYS__NORMAL VALUE IS 1. > 11 88 RMS$_FNF VALUE IS EXTERNAL RMS$_FNF. > 12 88 RMS__FNF VALUE IS 98962. > 13 01 X PIC S9(9) COMP. > 14 PROCEDURE DIVISION. > 15 P0. CALL "TEST" GIVING RETURN-STATUS. > 16 IF SYS$_NORMAL THEN MOVE 123 to X. > 17 IF SYS__NORMAL THEN MOVE 345 to X. > 18 IF RMS$_FNF THEN MOVE 567 to X. > 19 IF RMS__FNF THEN MOVE 789 to X. > : > JSR R26, TEST > LDQ R1, 56(R2) ; 000016 > MOV 123, R17 > LDL R16, (R1) > XOR RETURN-STATUS, R16, R16 > BNE R16, L$1 > STL R17, -8(R3) > L$1: > XOR RETURN-STATUS, 1, R19 ; 000017 > BNE R19, L$3 > MOV 345, R20 > STL R20, -8(R3) > L$3: > LDL R1, -4(R1) ; 000018 > XOR RETURN-STATUS, R1, R1 > BNE R1, L$5 > MOV 567, R22 > STL R22, -8(R3) > L$5: > LDAH R24, 2(R31) ; 000019 > MOV 789, R25 > LDA R24, -32110(R24) > XOR RETURN-STATUS, R24, R0 > BNE R0, L$7 > STL R25, -8(R3) > L$7: > LDQ R26, 96(R2) ; 000020 > > See the straight 1 in XOR for line 17? > Compare that with the LDQ R1, 56(R2) to fetch SS$_NORMAL ! > > For FNF as a literal it uses: LDA R24, -32110(R24) > So that is also NOT a memory reference, but a clever instruction. > > Specially for SS$_NORMAL it is ludicrous to have the linker fill it > in. > An insult to the injury of not just doing an BLBS ("IF SUCCES") > > Cheers, > Hein van den Heuvel > HvdH Performance Consulting > > > > IDENTIFICATION DIVISION. > PROGRAM-ID. LNM. > ENVIRONMENT DIVISION. > CONFIGURATION SECTION. > DATA DIVISION. > WORKING-STORAGE SECTION. > 01 IO$_READVBLK PIC S9(09) COMP VALUE IS EXTERNAL IO$_READVBLK. > 01 RETURN-STATUS PIC S9(09) COMP. > 88 SYS$_NORMAL VALUE IS EXTERNAL SS$_NORMAL. > 88 SYS__NORMAL VALUE IS 1. > 88 RMS$_FNF VALUE IS EXTERNAL RMS$_FNF. > 88 RMS__FNF VALUE IS 98962. > 01 X PIC S9(9) COMP. > PROCEDURE DIVISION. > P0. CALL "TEST" GIVING RETURN-STATUS. > IF SYS$_NORMAL THEN MOVE 123 to X. > IF SYS__NORMAL THEN MOVE 345 to X. > IF RMS$_FNF THEN MOVE 567 to X. > IF RMS__FNF THEN MOVE 789 to X. > DISPLAY X. > END PROGRAM LNM. > > -- PL/I for OpenVMS www.kednos.com ------------------------------ Date: Thu, 15 Nov 2007 15:44:39 -0800 (PST) From: Hein RMS van den Heuvel Subject: Re: system constants in COBOL Message-ID: <9e6d098f-3213-4fb4-9717-0e81619903b6@d61g2000hsa.googlegroups.com> On Nov 14, 6:55 pm, Jim Duff wrote: > VAXman- @SendSpamHere.ORG wrote: > I've had to use: > > > 01 blah PIC 9(4) COMP VALUE IS EXTERNAL LNM$_STRING. > For some obscure reason best known to the COBOL compiler team, some > system constants are resolved and some are not. Jim, that's total nonsense. You know better. This has NOTHING to do with Cobol It has everything with the linker and the system provide default library STARLET Take a silly macro test program like: .entry start,0 pushl #rms$_fnf pushl #ss$_normal calls #2, g^test .end start Compile and LINK/MAP/CROSS Now the MAP will show: : Module Name Ident Bytes File ----------- ----- ----- ----- : RMS$GLOBALS X-1 0 SYS$COMMON: [SYSLIB]STARLET.OLB;6 SYS$SSDEF V04-000 0 SYS$COMMON: [SYSLIB]STARLET.OLB;6 : Symbol Value Defined By ------ ----- ---------- RMS$_FNF 00018292 RMS$GLOBALS SS$_NORMAL 00000001 SYS$SSDEF The linker will happily do the same thing for a cobol generated reference. Hein. ------------------------------ Date: Fri, 16 Nov 2007 01:47:26 GMT From: John Santos Subject: Re: system constants in COBOL Message-ID: Rob Brooks wrote: > Hein RMS van den Heuvel writes: > >>(Bob Koehler) wrote: >> >>>Hein RMS van den Heuvel writes: >>> >>> >>>>Yeah,that's what folks do, >>>>If it was me, I'd create a DCL / Perl / Macro-defintion tool to turn >>>>the MACRO $xxxdef sources from STARLET,MLB into cobol include (.LIB) >>>>files and define the constants in the source instead of having the >>>>linker resolve them. >>> >>> I wouldn't since that's not a documented, supported interface and >>> I've seen it break in the past. >> >>So what? You just generate it once, and be happy. > > [...] > >>The constants defined in say DVIDEF are NOT going to change. >> >>They can not. Too many executables out there with those constants >>embedded. > > > In general, stuff in the STARLET library does not change, while stuff in > the LIB library can change at will. > > While I do know of some things that have changed within STARLET (specifically, > an undocumented system service changing its arguments), I'd be really surprised > if a documented and supported constant or offset defined in STARLET has changed > from release to release. > Sometimes things change without a corresponding change in STARLET... In V8.3 (8.2?) mailbox unit numbers can now be greater then 32767. In BASIC, LIB$GETDVI returns the mailbox unit number as a longword, as it alway has. The SYS$CREPRC description says the mailbox unit number for the termination mailbox is an unsigned word. Since BASIC doesn't have unsigned integer datatypes, the BASIC prototype for it (from the STARLET module in SYS$LIBRARY:BASIC$STARLET.TLB) defines it as a word (as always.) So if you create a mailbox, get its unit number with getdvi, and try to pass that unit number to $CREPRC, you get an integer overflow as soon as the unit number exceeds 32767 Trying to mask the low 16 bits out of the longword unit number and treat that was a word, you end up with a negative number (bit 15 is set), which on the call to SYS$CREPRC seems to get sign-extended to a longword. The large negative number ends up in termination mailbox unit number (visible with f$getjpi from DCL) while the process is running, and at process termination, it seems to be a non-existent mailbox, so the creating process doesn't get notified. To cure this, I extracted STARLET from BASIC$STARLET, and created a new prototype for SYS$CREPRC by deleting everything else and changing the mailbox argument to a long. (Fortunately, the module that was calling SYS$CREPRC didn't need anything else from STARLET.) The replaced the %include "STARLET" %from %library "sys$library:basic$starlet" with %include "$CREPRC.TXT" Of course, if SYS$CREPRC() changes, my prototype will be out of data. I could have set device_naming SYSGEN to 8 (to force a wrap at 32767, but we use lots of devices :-), and I really didn't want to disable this. Is there a better way? Or should CREPRC be changed to accept a long instead of an unsigned word for this argument? Or is there some way to finagle BASIC into passing a signed word (or a longword with bit 15 set) to a function expecting an unsigned word? (Short of writing a MACRO glue routine to do a movzwl instead of a cvtwl when constructing the arg list for $creprc.) Should I SPR this? -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 ------------------------------ Date: Fri, 16 Nov 2007 01:50:53 GMT From: John Santos Subject: Re: system constants in COBOL Message-ID: <1I6%i.27289$CI1.14659@trnddc03> Tom Linden wrote: > On Thu, 15 Nov 2007 14:38:20 -0800, Hein RMS van den Heuvel > wrote: > >> On Nov 15, 3:23 pm, "Tom Linden" wrote: >> >>> On Thu, 15 Nov 2007 11:25:58 -0800, Hein RMS van den Heuvel >>> > You gotta give the compiler a chance to optimize those constant, >>> > By using a linker resolved reference the compilers options are severly >>> > hed back imho. >>> >>> Huh? Unless I misunderstood the constants are dealt with by the parser >>> and never get to the linker. >> >> >> But that's exactly my point. It should be the parser seeing the >> numeric values >> and the cobol optimizer to do the right thing. > > > So this Cobol does not have the concept of include statements with replace > constants? That is lame. If done correctly it should never even get to > the optimizer. Of course it does. All it needs is something to include that defines the constants. Which doesn't exist. D'oh! > >> >> But these lame cobol programs stick it into an '88' and let the linker >> fill in the value. >> That will increase the code size slightly (notably for values like 0 >> and 1, less so for RMS$_FNF) >> What is worse the extra code will be a memory reference. >> >> >> Here is sample generated code (source below) >> 8 01 RETURN-STATUS PIC S9(09) COMP. >> 9 88 SYS$_NORMAL VALUE IS EXTERNAL SS$_NORMAL. >> 10 88 SYS__NORMAL VALUE IS 1. >> 11 88 RMS$_FNF VALUE IS EXTERNAL RMS$_FNF. >> 12 88 RMS__FNF VALUE IS 98962. >> 13 01 X PIC S9(9) COMP. >> 14 PROCEDURE DIVISION. >> 15 P0. CALL "TEST" GIVING RETURN-STATUS. >> 16 IF SYS$_NORMAL THEN MOVE 123 to X. >> 17 IF SYS__NORMAL THEN MOVE 345 to X. >> 18 IF RMS$_FNF THEN MOVE 567 to X. >> 19 IF RMS__FNF THEN MOVE 789 to X. >> : >> JSR R26, TEST >> LDQ R1, 56(R2) ; 000016 >> MOV 123, R17 >> LDL R16, (R1) >> XOR RETURN-STATUS, R16, R16 >> BNE R16, L$1 >> STL R17, -8(R3) >> L$1: >> XOR RETURN-STATUS, 1, R19 ; 000017 >> BNE R19, L$3 >> MOV 345, R20 >> STL R20, -8(R3) >> L$3: >> LDL R1, -4(R1) ; 000018 >> XOR RETURN-STATUS, R1, R1 >> BNE R1, L$5 >> MOV 567, R22 >> STL R22, -8(R3) >> L$5: >> LDAH R24, 2(R31) ; 000019 >> MOV 789, R25 >> LDA R24, -32110(R24) >> XOR RETURN-STATUS, R24, R0 >> BNE R0, L$7 >> STL R25, -8(R3) >> L$7: >> LDQ R26, 96(R2) ; 000020 >> >> See the straight 1 in XOR for line 17? >> Compare that with the LDQ R1, 56(R2) to fetch SS$_NORMAL ! >> >> For FNF as a literal it uses: LDA R24, -32110(R24) >> So that is also NOT a memory reference, but a clever instruction. >> >> Specially for SS$_NORMAL it is ludicrous to have the linker fill it >> in. >> An insult to the injury of not just doing an BLBS ("IF SUCCES") >> >> Cheers, >> Hein van den Heuvel >> HvdH Performance Consulting >> >> >> >> IDENTIFICATION DIVISION. >> PROGRAM-ID. LNM. >> ENVIRONMENT DIVISION. >> CONFIGURATION SECTION. >> DATA DIVISION. >> WORKING-STORAGE SECTION. >> 01 IO$_READVBLK PIC S9(09) COMP VALUE IS EXTERNAL IO$_READVBLK. >> 01 RETURN-STATUS PIC S9(09) COMP. >> 88 SYS$_NORMAL VALUE IS EXTERNAL SS$_NORMAL. >> 88 SYS__NORMAL VALUE IS 1. >> 88 RMS$_FNF VALUE IS EXTERNAL RMS$_FNF. >> 88 RMS__FNF VALUE IS 98962. >> 01 X PIC S9(9) COMP. >> PROCEDURE DIVISION. >> P0. CALL "TEST" GIVING RETURN-STATUS. >> IF SYS$_NORMAL THEN MOVE 123 to X. >> IF SYS__NORMAL THEN MOVE 345 to X. >> IF RMS$_FNF THEN MOVE 567 to X. >> IF RMS__FNF THEN MOVE 789 to X. >> DISPLAY X. >> END PROGRAM LNM. >> >> > > > -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 ------------------------------ Date: Thu, 15 Nov 2007 17:59:51 -0800 (PST) From: "tomarsin2015@comcast.net" Subject: The NBA and VMS Message-ID: <356ccbb0-38ec-4b49-9b1e-7f4100086331@b32g2000hsa.googlegroups.com> Hello Going to my junk I found a poster of Larry Bird standing next to a 6000-560, 9000, a couple of 4000 series and 3100's and acourse it states THE OFFICAL COMPUTER SYSTEM OF THE NBA. Just wondering if HP/ VMS is still the offical computer system or did the NBA drop VMS like the Celtics stopped winning championships.??? phil ------------------------------ Date: Fri, 16 Nov 2007 00:20:54 +0100 From: Michael Kraemer Subject: VAX design out of fashion ? Maybe not. Message-ID: http://search-desc.ebay.de/search/search.dll?sofocus=bs&sbrftog=1&catref=C6&saetm=1195204374&from=R10&fstype=1&satitle=vax+design&sacat=160%26catref%3DC6&fts=2&a6=-24&a56=-24&a26446=-24&a14=-24&alist=a6%2Ca56%2Ca26446%2Ca14%2Ca3801&pfmode=1&reqtype=1&gcs=2060&pfid=3033&pf_query=vax+design&sargn=-1%26saslc%3D3&sadis=200&fpos=64291&sabfmts=1&saobfmts=insif&ga10244=10425&ftrt=1&ftrv=1&saprclo=&saprchi=&fsop=1%26fsoo%3D1&coaction=compare&copagenum=1&coentrypage=search ( search for VAX under "Computer" ) ------------------------------ Date: Thu, 15 Nov 2007 11:12:27 -0800 (PST) From: Bob Gezelter Subject: Re: VIOC: sizing and performance Message-ID: <6194e3a6-e54d-4783-afac-a10162f8ffd7@w73g2000hsf.googlegroups.com> On Nov 15, 11:57 am, Ken.Fairfi...@gmail.com wrote: > On Nov 15, 3:15 am, Bob Gezelter wrote: > [...] > > > > > While the original post did not include details of the disk > > configuration, it is likely that there are (at least) three levels of > > caching actually present: within the database, the VIOC/XFC, and the > > caching within the storage controller. The optimum performance > > settings are a balancing act between all three and their effects. > > Right, sorry about that. As in my reply to Michael Forster, I'm > actually less concerned about the database node than the two > application server nodes. > > The two application server nodes each have 14x1.3Ghz processors > and 32GB of memory. The storage is on an EVA6000 where we're > using, what's the term, "fully mirrored vdisks"? The VIOC caches > are 250MB on the DB node, 250MB on one app server, and > 375MB on the other. > > And it is VIOC, *not* XFC, caching. > > [...] > > > As to the hit rate, the effect of a reduction in cache size depends > > where on the curve one is at the present value. The general curve for > > cache performance is a curve approximating exponential decay of > > benefits as size increases. The true metric here is not really hit > > rate, but eviction rate: How often data must be evicted from the cache > > to make room for other data. A hit rate of 50% with an eviction rate > > of 0% is far different than a hit rate of 50% with a 100% eviction > > rate (the latter gains by adding size, the former does not). > > I include here the output of Show Memory/Cache/Full from the > three nodes. What I see is that on each node, about 100 files > are cached. There is a lot of I/O bypassing the cache, and on > the two app server nodes, most of the cache is in use (not much > in the "Free" column. What I can't see from this output is the > eviction rate... > > ------------------------------------------------------------------------------------ > SYSMAN> do sho mem/cach/ful > %SYSMAN-I-OUTPUT, command execution on node DBB1 > System Memory Resources on 15-NOV-2007 08:46:58.82 > > Virtual I/O Cache > Total Size (MBytes) 250.00 Read IO Count > 1170423898 > Free (MBytes) 151.07 Read Hit Count > 670193435 > In Use (MBytes) 98.92 Read Hit > Rate 57% > Write IO Bypassing Cache ********* Write IO Count > 2501817621 > Files Retained 99 Read IO Bypassing Cache > 390546546 > > Write Bitmap (WBM) Memory Summary > Local bitmap count: 251 Local bitmap memory usage (MB) > 41.69 > Master bitmap count: 117 Master bitmap memory usage (MB) > 18.86 > %SYSMAN-I-OUTPUT, command execution on node APP1 > System Memory Resources on 15-NOV-2007 08:46:58.87 > > Virtual I/O Cache > Total Size (MBytes) 250.00 Read IO Count > 2485755609 > Free (MBytes) 22.03 Read Hit Count > 371641860 > In Use (MBytes) 227.96 Read Hit > Rate 14% > Write IO Bypassing Cache 29108623 Write IO Count > 738910797 > Files Retained 100 Read IO Bypassing > Cache1954885777 > > Write Bitmap (WBM) Memory Summary > Local bitmap count: 285 Local bitmap memory usage (MB) > 47.58 > Master bitmap count: 71 Master bitmap memory usage (MB) > 12.17 > %SYSMAN-I-OUTPUT, command execution on node APP2 > System Memory Resources on 15-NOV-2007 08:46:58.96 > > Virtual I/O Cache > Total Size (MBytes) 375.00 Read IO Count > 103022387 > Free (MBytes) 0.03 Read Hit Count > 68204994 > In Use (MBytes) 374.96 Read Hit > Rate 66% > Write IO Bypassing Cache 2681158 Write IO Count > 156859274 > Files Retained 100 Read IO Bypassing Cache > 497166 > > Write Bitmap (WBM) Memory Summary > Local bitmap count: 285 Local bitmap memory usage (MB) > 47.58 > Master bitmap count: 71 Master bitmap memory usage (MB) > 12.17 > SYSMAN> > ------------------------------------------------------------------------------ > > Thanks, Ken > -- > Ken & Ann Fairfield > What: Ken dot And dot Ann > Where: Gmail dot Com Ken, I would hazard a guess that the workload is different on the two application servers. I hesitate to "prescribe" over the newsgroup, but I would not generally look at reducing the size of cache that is fully used. In fact, I would seriously consider resizing in the other direction. Depending on my flexibility, and some performance studying, I might also very well consider re-organizing the file locations, to reduce useless caching. The comment in my original post was not a case of mis-speak. The precise same argument holds for VIOC in this respect as XFC, so, while the installation described in the original post uses VIOC, I wanted those following this thread to understand that the phenomenology is similar in both cases. - Bob Gezelter, http://www.rlgsc.com ------------------------------ Date: Thu, 15 Nov 2007 11:35:35 -0800 (PST) From: Ken.Fairfield@gmail.com Subject: Re: VIOC: sizing and performance Message-ID: <97d1a3fc-a635-43e2-a979-48e32aac15b8@d4g2000prg.googlegroups.com> On Nov 15, 11:12 am, Bob Gezelter wrote: [...] > I would hazard a guess that the workload is different on the two > application servers. I hesitate to "prescribe" over the newsgroup, but > I would not generally look at reducing the size of cache that is fully > used. In fact, I would seriously consider resizing in the other > direction. Thanks, Bob, that's exactly what I was thinking and what was behind my questions, that the resizing proposed by the vendor is in the wrong direction. I just wanted some confirmation that I wasn't completely off-base on this one. Thanks, Ken -- Ken & Ann Fairfield What: Ken dot And dot Ann Where: Gmail dot Com ------------------------------ Date: Thu, 15 Nov 2007 11:37:55 -0800 (PST) From: Hein RMS van den Heuvel Subject: Re: VIOC: sizing and performance Message-ID: <853f343f-e2b9-4892-ac97-9ce6c7611ae6@c29g2000hsa.googlegroups.com> On Nov 14, 10:46 pm, Ken Fairfield wrote: > For reasons best known to the vendor of the primary application, Cerner > Millennium, we're using VIOC rather than XFC file caching. Do NOT accept that without a modicum of a fight. DO question. They probably do NOT know why this (still) is. The softest question is probably 'for which versions of OpenVMS/Millennium should we use VIOC' You also want to ask whether it is a (dated) recommendation, or a requirement in order to have a supported configuration The VIOC/XFC is transparant. If Cerner believes it is not transparant, then they had better be able to articulate that. Without clear and concise argument I would not accept the suggestion to use VIOC and switch to XFC for it is far superior. I suspect there was an early incident with XFC in some OpenVMS version. Surely that has been adressed by OpenVMS and folks need to move on. fwiw, Hein. ------------------------------ Date: Thu, 15 Nov 2007 12:56:35 -0800 (PST) From: Ken.Fairfield@gmail.com Subject: Re: VIOC: sizing and performance Message-ID: <4df18083-bc09-4aae-a1f1-5d695982f927@e6g2000prf.googlegroups.com> On Nov 15, 11:37 am, Hein RMS van den Heuvel wrote: > On Nov 14, 10:46 pm, Ken Fairfield wrote: > > > For reasons best known to the vendor of the primary application, Cerner > > Millennium, we're using VIOC rather than XFC file caching. > > Do NOT accept that without a modicum of a fight. > DO question. They probably do NOT know why this (still) is. > > The softest question is probably > 'for which versions of OpenVMS/Millennium should we use VIOC' > You also want to ask whether it is a (dated) recommendation, or a > requirement in order to have a supported configuration > > The VIOC/XFC is transparant. If Cerner believes it is not transparant, > then they had better be able to articulate that. Without clear and > concise argument I would not accept the suggestion to use VIOC and > switch to XFC for it is far superior. > > I suspect there was an early incident with XFC in some OpenVMS > version. > Surely that has been adressed by OpenVMS and folks need to move on. Thanks for weighing in, Hein. :-) I doubt there was any incident. I suspect it's more like they got things working, "back in the day", with VIOC, and didn't want to bother with testing XFC. :-( I will ask if XFC is "a problem" with them support-wise. And I agree, if I can, and if we want to bother putting the resources into it (planning, testing, etc.), I'd like to change to XFC. Thanks again, Ken -- Ken & Ann Fairfield What: Ken dot And dot Ann Where: Gmail dot Com ------------------------------ Date: Thu, 15 Nov 2007 15:17:10 -0800 (PST) From: AEF Subject: Re: VIOC: sizing and performance Message-ID: On Nov 15, 2:37 pm, Hein RMS van den Heuvel wrote: > On Nov 14, 10:46 pm, Ken Fairfield wrote: > > > For reasons best known to the vendor of the primary application, Cerner > > Millennium, we're using VIOC rather than XFC file caching. > > Do NOT accept that without a modicum of a fight. > DO question. They probably do NOT know why this (still) is. > > The softest question is probably > 'for which versions of OpenVMS/Millennium should we use VIOC' > You also want to ask whether it is a (dated) recommendation, or a > requirement in order to have a supported configuration > > The VIOC/XFC is transparant. If Cerner believes it is not transparant, > then they had better be able to articulate that. Without clear and > concise argument I would not accept the suggestion to use VIOC and > switch to XFC for it is far superior. So Hein, can you please tell us what makes XFC so much better than VIOC? I'm sure you're right -- I would just like to know the details behind it. Thanks! > I suspect there was an early incident with XFC in some OpenVMS > version. > Surely that has been adressed by OpenVMS and folks need to move on. Yes, I clearly remember Hoff warning us to get very important ECO kits when XFC first came out. > > fwiw, > Hein. AEF ------------------------------ End of INFO-VAX 2007.627 ************************