INFO-VAX Sat, 16 Feb 2008 Volume 2008 : Issue 93 Contents: Re: Does dism/unload spin down a disk? Re: Does dism/unload spin down a disk? Re: FORTRAN MicroVAX connection machine question Re: HP OpenVMS Tele-Marketing?!? Re: NFS and version numbers Re: NFS and version numbers Re: ODS5, /NAMES = AS_IS, LIBRARY, MMS v. me Re: Open sourcing of VMS: bad precedent set Semi OT: Feedback to HP Re: Semi OT: Feedback to HP Re: Semi OT: Feedback to HP Re: Semi OT: Feedback to HP Re: Semi OT: Feedback to HP Re: Semi OT: Feedback to HP Re: Semi OT: Feedback to HP Re: SYS$OUTPUT vs PIPE Re: SYS$OUTPUT vs PIPE Re: Testing new rewired "cable adapters" for lights-out console use Re: Unusual mailbox status value Re: Unusual mailbox status value ---------------------------------------------------------------------- Date: Fri, 15 Feb 2008 15:58:10 -0800 (PST) From: FrankS Subject: Re: Does dism/unload spin down a disk? Message-ID: <522b2a83-5335-453a-be63-5235a83835f4@e25g2000prg.googlegroups.com> On Feb 14, 9:45=A0pm, John Santos wrote: > Oh, and actually, old hardware tends to last longer than modern > hardware. It's amazing that the RZ28 (2gb) and RZ29 (4gb) drives at my client's sites have been spinning error-free for generations, yet I install new 72gb and 146gb drives and some of them go within 6 months. There was an article somewhere recently about the so-called MTBF of modern disks and how misleading a metric it is, and I've certainly had enough bad experiences with disk drives to back that up. ------------------------------ Date: Fri, 15 Feb 2008 21:05:59 -0500 From: "Richard B. Gilbert" Subject: Re: Does dism/unload spin down a disk? Message-ID: <47B64507.5060105@comcast.net> FrankS wrote: > On Feb 14, 9:45 pm, John Santos wrote: > >>Oh, and actually, old hardware tends to last longer than modern >>hardware. > > > It's amazing that the RZ28 (2gb) and RZ29 (4gb) drives at my client's > sites have been spinning error-free for generations, yet I install new > 72gb and 146gb drives and some of them go within 6 months. There was > an article somewhere recently about the so-called MTBF of modern disks > and how misleading a metric it is, and I've certainly had enough bad > experiences with disk drives to back that up. There's at least one fundamental difference. The RZ28 and RZ29 spin at far lower speeds than some of the newer drives. A disk spinning at 15K RPM tends to have a shorter life; sometimes MUCH shorter! ------------------------------ Date: Sat, 16 Feb 2008 04:38:30 GMT From: Michael Austin Subject: Re: FORTRAN MicroVAX connection machine question Message-ID: <47B66912.2000808@firstdbasource.com> yyyc186 wrote: > Hello, > > Odd we have all of this MicroVAX chatting going on after I just got > rid of mine, but a question came up at work today. I searched a few > search engines and cannot find a link to the article I'm looking for. > > Does anyone here have a link to the article about the person from > Fermi (could have been Argonne) who took a bunch of left over MicroVAX > computers and some FORTRAN code to make a connection machine out of > them. I swear I remember this story from back in the days of DEC > Professional, but simply cannot find it. > > OK, it was a weird discussion, because we were also debating about DIP > switches on modems used with TCAM being used to set a modem number > which had to match an entry in the TCAM database (actually > authorization file) before it could communicate with TCAM on the IBM > mainframe. Apparently that knowledge is also pretty arcane because > there are only references to the IBM manuals which would have had such > information, but the manuals aren't on-line...at least in any capacity > ASK or GOOGLE could find them. Perhaps I'm just not getting lucky > with my query parameters. > > When unlucky with a search engine, post here, and search the grey > cells > NO.. but using "fortran connection machine vax" I get all sorts of hits where Fortran was used on VAXen (780/3600(mvIII) etc...) as a frontend to a Connection Machine.. ------------------------------ Date: Fri, 15 Feb 2008 20:19:36 +0000 (UTC) From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) Subject: Re: HP OpenVMS Tele-Marketing?!? Message-ID: In article <47B59096.6030902@comcast.net>, "Richard B. Gilbert" writes: > The do-not-call list is a big improvement. Unfortunately, it does not > cover "surveys" and some phone spammers never heard of it or they do > know about it and aren't afraid of it. > > Short of an enforceable law with a death penalty, you won't get rid of > telemarketers. I've found this to be effective: When you're sure it's an unsolicited call from a telemarketer (i.e. audial spam), the suppressed caller ID being the first clue, give them 2 or 3 sentences to make it look like you are interested, but, paying hommage to Basil Fawlty, speak softly. This will cause them to turn up their volume. Then, reach for one of those high-pitched dog-calling whistles and give it all you've got. ------------------------------ Date: Fri, 15 Feb 2008 12:12:08 -0700 From: Mark Berryman Subject: Re: NFS and version numbers Message-ID: <47b57389$1@mvb.saic.com> JF Mezei wrote: > Does anyone use VMS as an NFS server ? > > When multiple versions of a file exists, it is served as: > > name.type.version (for instance, login.com.37) > > Besides confusing the mac client on what type of file it is, when I > attempt to save it: > > If I do a "save" from the client, it is saved as loginˆ.com.37 > > If I do a "save as" and save it as "login.com" it asks me to confirm > overwiting an existing file and then , it either fails with some type of > error, or saves it as as "login.com;1" and zaps the previous version. > > > /disk2/users/jfmezei BRAKES, 10.0.0.20 > Options: Purge Typeless Name_cvt > > > > Has anyone found a way to make the NFS server on VMS behave as the FTP > server with the "TCPIP$FTP_NO_VERSION" = "1" where version numbers are > not supplied to remote clients, but the file system properly handles > them when files are being sent back to the server ? > > aka: a directory would only show the most recent version of a file > (without version number), and when you save it, it automatically creates > a new version but client is not aware of it, since it only asked for > "login.com" and is saving it as "login.com". Yes, I use VMS very successfully as an NFS server. It does not show version numbers but simply references the most recent version. A read reads the most recent version, a write replaces the most recent version. However, I do not use TCPIP services. I did an evaluation of the various IP stacks available for VMS for work and TCPIP services came out dead last. I use Multinet and have never had a problem using VMS as an NFS server. Mark Berryman ------------------------------ Date: Fri, 15 Feb 2008 22:05:10 -0600 From: David J Dachtera Subject: Re: NFS and version numbers Message-ID: <47B660F6.347A8E79@spam.comcast.net> Mark Berryman wrote: > [snip] > However, I do not use TCPIP services. I did an evaluation of the > various IP stacks available for VMS for work and TCPIP services came out > dead last. I use Multinet and have never had a problem using VMS as an > NFS server. Out of curiosity... May I assume that your primary criteria centered on function and not performance? Multinet does direct I/O, meaning that each network I/O generates an interrupt which must be serviced (see MONITOR MODES), while UCX uses buffered I/O which frees up CPU cycles for more user mode activity. In high-transaction rate applications like healthcare, that (and vendors' unwillingness / inability to fix their code) is a vital consideration. David J Dachtera DJE Systems ------------------------------ Date: Fri, 15 Feb 2008 13:20:23 -0600 (CST) From: sms@antinode.org (Steven M. Schweda) Subject: Re: ODS5, /NAMES = AS_IS, LIBRARY, MMS v. me Message-ID: <08021513202348_2062A39A@antinode.org> From: "Ed Vogel" > > #pragma module VMS > > ..............^ > > %CC-W-BADMODULEID, Invalid identifier found immediately following "#pragma > > modul > > e" or "#module" directive. > The warning is caused because VMS is a predefined macro with the > value of 1. So, the compiler really sees: > > #pragma module 1 > [...] Doh. If the code hadn't been _so_ simple, I might have tried /LIST /SHOW = ALL to see what was really happening, but that didn't seem necessary. Sigh. > #undef VMS Or, as someone (else) has already suggested (elsewhere), one could take advantage of this behavior with "#pragma module MODULE_MACRO", and then define MODULE_MACRO somewhere. Everything's complicated (especially when it looks simple). Thanks for the help. ------------------------------------------------------------------------ Steven M. Schweda sms@antinode-org 382 South Warwick Street (+1) 651-699-9818 Saint Paul MN 55105-2547 ------------------------------ Date: Sat, 16 Feb 2008 03:56:58 GMT From: D Gillbilly Subject: Re: Open sourcing of VMS: bad precedent set Message-ID: <47b65b17.5697531@news.aliant.net> On Sun, 27 Jan 2008 15:57:05 -0800 (PST), Sue wrote: > >Dear Folks, > >You know how much I care for you and for VMS. We just had and >Ambassadors meeting where Martin Fink called in. And while I value >the fact that at most every posting on COV the future of VMS is >discussed. We do have a roadmap which includes hardware and software >futures. in the last 6 months we have had more press than ever >before. Based on your request we had Martin Fink on Customer call, >more technical web casts than ever before. We are moving forward and >at the point we are just another one of the OS's in HP. We want to be >judged on our merit. > >Reality. >We are a business, we are not free, our engineers are (in my opinion) >the best in the industry hence deserve a pay check. > > What do you want? > >Do not flame me. Do not give me un realistic statments like >advertising, its not going to happen. Give me something, me Sue can >do. And I will do my best to do it. Tell me where the problem is and >I will try and find someone to fix it. I know your job depends on VMS >so does mine. Sorry for taking so long to post up. At first I didn't realize that this was a victory. >We want to be judged on our merit. Reading between the words (in this and other recent posts), I get the feeling that the OpenVMS BU has gained some additional control over it's own destiny. Control. Isn't that one of biggest problems in industry? Lack of control? Congratulations on a job well done (even if I am wrong). Is it still too early to try to encourage schools, developers, or companies to take another look at OpenVMS? OpenVMS may currently be lacking in modern features, but it also is lacking in a lot of the modern problems. The lack of developers is the ONLY THING that can kill OpenVMS. (Even the Vendors couldn't kill it (if they were even trying)) Duane (too small to be big, too big to be small) Disclaimer: Due to circumstances beyond my control, I now work for a company that has the absolute minimum number of people required to sell and support OpenVMS applications. As I have alluded in a number of posts, *I* am the biggest threat to my customers. I'm just describing my job to point out that there is a big empty gap between my situation and the enterprise. . But I am a optimistic realist. I can always achieve nothing by doing nothing. ================================================== **** What does the WooWoo DooDoo. **** I was hired by two researchers that were intent on providing computing power to a disadvantaged industry segment. At the time, they had a rack of Gandalf technology connecting remote Canadian sites to a hopped up and over worked PDP 11/70 (RSTS/E). I was new and had explicit instructions not to use any unnecessary CPU to do my job (we were selling cycles and storage at the time). I had to spend my days writing code, compiling overnight and hoping that in the morning I had something to test. Timesharing taught me how to manage multiple applications for multiple customers on the same machine. Toolkits full of modules were developed just to squeeze the most we could into memory. On the VAX, overlays were easily turned into libraries that turned into shareable images. They also grew comfortable with providing remotely managed applications in non-technical (and sometimes hostile) environments. An integrated security/authentication domain eased management tasks. Additional authentication provided exceptional auditor compliance. The customer bought or leased the equipment and for a monthly fee, my company handled the details. These are also the hardware years. I enjoyed working on the network gear. The Alpha brought a big slowdown to the growth. The bigger customers (that were more easily influenced by internal IT sources) got cold feet and bailed (or at least are still trying). For the rest, I immersed myself into R&D projects (being a writeoff is actually job security) while working with our customers to maintain flexible environments capable of meeting all the current business demands and regulations. A non reliance on *industry standard* services meant we never lost control of the office. (Thanks PATHWORKS (Advanced Server (SAMBA (gulp)))) Control can provide stability AND allows the users to enjoy (?) the *user experience* that they unfortunately have been brainwashed to expect. I'm still on the fence over the I-Box (but liking it more and more). I think the Management Processor offers the most hope of helping me black box my OpenVMS appliances. But I'm too busy working to have much I-Box fun right now. And the future??? I don't yet know where I fit into the present. Seems to me that I have been going the wrong way all these years. And whenever I look at the industry, all I ever see is the push towards the *next big thing* (or is that away from the *last big mistake*). I can't tell if I am way behind or if I am way ahead. Anyway, just don't try to do this yourself. If you are thinking of trying to deploy an OpenVMS solution, get some quality professional consultation (Now available!). The lessons that they have learned and the mistakes that they can help to avoid will go a long way to ensuring that you can develop applications that are designed to last longer than the latest fad. ============================================= ?Humor? A Salute To The Niche! Too bad small business was such a niche market. :-( But what if it was a big niche? :-) What if to an auditor, small companies all looked the same? :-) What if there was an operating system that was currently only niche. :-( But what if it was niche in a lot of industries! :-) Would that make it General Purpose? :-) Is that a good rank to have? :-) Where can I sign up? :-) ============================================= Laughing Here am I Laughing inside Cuz I don't know much About these times... Neil Osborne 54-40 I wonder what he would think if he found out that a small business nobody was using his song for inspiration to try and convince big business that big business already has the technology to help small business escape *industry (sub)standard* big business? Hopefully he would laugh. I think I need to lighten up anyway. Time for a change in tactics. What! A strategy? Yup, I'm gonna make someone laugh before I give up! =============================================== To the choir: Thank you for your tolerance as I tried to reach the congregation. Is everyone prepared for Critical Mass? ------------------------------ Date: Fri, 15 Feb 2008 14:22:42 -0500 From: JF Mezei Subject: Semi OT: Feedback to HP Message-ID: <47b5e69f$0$25414$c3e8da3@news.astraweb.com> A while I ago, I was prompted to send the security issue descripton for IMAP to HP via some website feedback. Just to let everyone know that as expected, I received no reply at all. HP should be leveraging hobbyists by making it easy for then to install the lastest software and report problems before the serious commercial customers install that software. ------------------------------ Date: Fri, 15 Feb 2008 14:18:44 -0800 (PST) From: Doug Phillips Subject: Re: Semi OT: Feedback to HP Message-ID: <7fce4524-f9e0-4366-94d5-cf9a91834668@s37g2000prg.googlegroups.com> On Feb 15, 1:22 pm, JF Mezei wrote: > A while I ago, I was prompted to send the security issue descripton for > IMAP to HP via some website feedback. Just to let everyone know that as > expected, I received no reply at all. > "Report a potential security vulnerability to HP" Did you post it there? ------------------------------ Date: Fri, 15 Feb 2008 19:13:08 -0500 From: JF Mezei Subject: Re: Semi OT: Feedback to HP Message-ID: <47b62ab3$0$25428$c3e8da3@news.astraweb.com> Doug Phillips wrote: > "Report a potential security vulnerability to HP" > > > > Did you post it there? Nop. I posted it at the URL that Mr SMS had provided. It was something like customer feedback form. ------------------------------ Date: Fri, 15 Feb 2008 17:57:58 -0800 (PST) From: Doug Phillips Subject: Re: Semi OT: Feedback to HP Message-ID: <810b76fc-62f7-466f-92ad-767718dcbed9@s13g2000prd.googlegroups.com> On Feb 15, 6:13 pm, JF Mezei wrote: > Doug Phillips wrote: > > "Report a potential security vulnerability to HP" > > > > > > Did you post it there? > > Nop. I posted it at the URL that Mr SMS had provided. It was something > like customer feedback form. Yea, that sounds like a better place to report a security vulnerability than on a page called "Report a potential security vulnerability to HP". Jeez. Wonder why you haven't heard anything back? ------------------------------ Date: Fri, 15 Feb 2008 21:31:50 -0500 From: bradhamilton Subject: Re: Semi OT: Feedback to HP Message-ID: <47B64B16.20903@comcast.net> Doug Phillips wrote: > On Feb 15, 6:13 pm, JF Mezei wrote: >> Doug Phillips wrote: >>> "Report a potential security vulnerability to HP" >>> >>> Did you post it there? >> Nop. I posted it at the URL that Mr SMS had provided. It was something >> like customer feedback form. > > Yea, that sounds like a better place to report a security > vulnerability than on a page called "Report a potential security > vulnerability to HP". Jeez. Wonder why you haven't heard anything > back? To be fair, back in December of 2007, he did ask where to report the problem; there were few answers back then, except for SMS's response. Your response is the best so far, but I can't recall seeing that page before your post; it's unfortunate that more folks don't know about this page. It is indeed easy to find from www.hp.com, if you type, "report a security vulnerability" in the site's search engine; the resultant link is approximately ten links from the top of the choices returned. Still, you'd think that at least one of the hp OpenVMS denizens that lurk here might have provided the link. :-) I think that some folks are reluctant to use hp.com's search feature (or indeed most .com search feature) because of the lousy initial attempts (was it ask.com from COMPAQ's OpenVMS page or hp's OpenVMS web page that produced horrendous results?) ------------------------------ Date: Fri, 15 Feb 2008 21:41:52 -0500 From: bradhamilton Subject: Re: Semi OT: Feedback to HP Message-ID: <47B64D70.2090206@comcast.net> Doug Phillips wrote: > On Feb 15, 6:13 pm, JF Mezei wrote: >> Doug Phillips wrote: >>> "Report a potential security vulnerability to HP" >>> >>> Did you post it there? >> Nop. I posted it at the URL that Mr SMS had provided. It was something >> like customer feedback form. > > Yea, that sounds like a better place to report a security > vulnerability than on a page called "Report a potential security > vulnerability to HP". Jeez. Wonder why you haven't heard anything > back? My apologies for the previous post; you have provided this link back in January of 2008, in response to JF's question. Sorry I missed it. ------------------------------ Date: Fri, 15 Feb 2008 23:48:53 -0500 From: JF Mezei Subject: Re: Semi OT: Feedback to HP Message-ID: <0201b840$0$17589$c3e8da3@news.astraweb.com> bradhamilton wrote: >>>> > My apologies for the previous post; you have provided this link back in > January of 2008, in response to JF's question. Sorry I missed it. I just used google (deja news) on the above url and it only came out into this thread, not the original one. Out of curiosity, how did you find the original mention of the above url ? It is possible that such a similar link was provided after I had already submitted the report to the link Mr SMS had provided and I wasn't going to rewrite it to the new one. The reason I made *this* thread was simply to point out that some of those web forms just don't do anything. It isn't a big deal, I didn't expect a response. If HP were truly serious about security, they would publish a real email address where we can send a real email with real information instead of having to enter text in some dumb web text entry window of 6 lines * 38 characters. ------------------------------ Date: Fri, 15 Feb 2008 13:50:32 -0500 From: JF Mezei Subject: Re: SYS$OUTPUT vs PIPE Message-ID: <47b5e0ad$0$6319$c3e8da3@news.astraweb.com> Albrecht Schlosser wrote: > work as expected for me on: OK, it must be because I exist in a dfferent dimension/universe where things always seem a tad different. I tried define/user of sys$output, sys$error and tt and all still got the output to the terminal. But $define sys$output temp.txt did redirect the output to the file. perhaps as part of their tutorial on VMS, the indian maintainers were told to become familiar with SYS$TRNLNM and SYS$ASSIGN and SYS$QIO and the chap assigned to port the unix DIG decided to get his hands dirty and did a $TRNLNM at the process or job level followed by a $ASSIGN and $QIOs instead of just using the standard unix io routines. ------------------------------ Date: 15 Feb 2008 13:38:18 -0600 From: briggs@encompasserve.org Subject: Re: SYS$OUTPUT vs PIPE Message-ID: In article <47b5c451$0$21969$ec3e2dad@news.usenetmonster.com>, "Jilly" writes: > > "JF Mezei" wrote in message > news:47b5c136$0$14043$c3e8da3@news.astraweb.com... >> VMS , Alpha 8.3 >> >> $DEFINE/USER SYS$OUTPUT TEMP.TXT >> $DIG @ns.chocolate.com chocolate.com axfr >> >> The output is still displayed on the terminal. >> >> But... >> >> >> $PIPE DIG @ns.chocolate.com chocolate.com axfr > temp.txt >> >> The output goes to temp.txt >> >> The HELP text for PIPE mentions redirection of SYS$OUTPUT. >> >> >> >> This isn't the end of the world, but I am curious on why the output of a >> simple unix utility most likely written in C wouldn't be caught by the >> DEFINE/USER but would be caught by the PIPE ? >> >> >> (Programs I write in C have no problems working with the DEFINE/USER of >> SYS$OUTPUT). >> > > WAG - DIG is figuring out what the terminal is and doing it's IO to that > thus in the 1st case the terminal is your screen and the 2nd since PIPE is > SPAWNing the DIG the terminal is a mailbox. That guess does not hold water. PIPE is not SPAWNing in this scenario. What PIPE does with a simple redirection (">") is to save the predefined translations for SYS$OUTPUT in supervisor and user mode, create a redirected translation, run the command _in the current process context_ and then restore the saved translations. One can thus: $ define /user sys$output file2.dat $ pipe command1 > file1.dat $ command2 and see the output of command1 in file1 and the output of command2 in file2 even though one would have ordinarily expected image rundown of command1 to kill the user mode logical. ------------------------------ Date: 15 Feb 2008 22:24:14 GMT From: Hans Bachner Subject: Re: Testing new rewired "cable adapters" for lights-out console use Message-ID: AEF wrote: > Maybe this is a dumb question, but at least it's on topic!!! > > We're moving our servers and such to a new data center in a new > building. My "manager" wants to go "lights-out" so I need a better > terminal server. The old terminal server (a MOXA CN 2100) has the > problem that power-ups and power-downs cause it to emit break signals, > [...] > > So I have a new terminal server lined up: a Cisco 2610. Digital Networks, which has been acquired by Vnetek Communications (http://www.vnetek.com) recently, still builds and sells various DECserver 700 models (with up to 32 ports). Hans. ------------------------------ Date: Fri, 15 Feb 2008 15:50:15 -0800 (PST) From: FrankS Subject: Re: Unusual mailbox status value Message-ID: <645d6b80-6f75-45cf-891e-a415fd47cca1@e25g2000prg.googlegroups.com> Just to wrap this up, the problem had nothing to do with the $QIOW. To try and shorten the story, in addition to the maibox writer and reader processes, there are three other processes running which talk to the reader process via a mapped global section. Right there, I'm sure a lot of lights are turning up in folks minds. The linker option file (thank you, Hein, for making me check) that is used to build the programs was wrong. It put the PSECT on a page boundary, but did not isolate the PSECT into it's own image section. The result was that in addition to the shared global data, a number of other common blocks were also mapped to the same global page range. One of the other processes was clobbering data in the mailbox reader, and it was just a matter of timing and coincidence that the error became apparent at the completion of the mailbox read $QIOW. The next question from the client will be "why has it worked all these years?" Just dumb luck. The other common blocks that ended up in the global section were no longer used, or coincidentally did not overlap in the global page. When I rewrote the reader application and renamed and/or added some common blocks (like the one for the I/O status block) it created a conflict between the reader and one of the other processes. Changing the linker option to PSECT=, PAGE, SOLITARY makes everything work correctly. ------------------------------ Date: Fri, 15 Feb 2008 18:57:55 -0800 (PST) From: Hein RMS van den Heuvel Subject: Re: Unusual mailbox status value Message-ID: <93d9d61a-f3ee-472c-a40f-d92363ea756e@34g2000hsz.googlegroups.com> On Feb 15, 6:50=A0pm, FrankS wrote: > Just to wrap this up, the problem had nothing to do with the $QIOW. : > The linker option file (thank you, Hein, for making me check) that is > used to build the programs was wrong. =A0 All is well that ends. :-) Thanks for the follow up. Well appreciated. > a number of other common blocks were also mapped to the same global page r= ange. Please be aware that in the linker map, imported PSECTs are listed with the relocatable VA of the exporting shareable image. Therefore they show as if they would overlap other sections of the to be linked image. This is confusing. If a reader ever thinks this might plays a role (not here it seems) then the best you can do is to create a FULL map. Then you can see the PSECT contributors. You will see that psect X (NCR$IOSB) is from the main, and from the shareable (and from shareable its length is 0). That's an indication that the PSECT comes from shareable and that the VA is not an VA within the linked image. (Thanks Hartmut!) > "why has it worked all these years?" =A0Just dumb luck. I tend to call that 'bad luck'. Had it never worked, errored 10 years ago, the problem would have been recognized with much less total aggravation. Hein. ------------------------------ End of INFO-VAX 2008.093 ************************