INFO-VAX Sat, 01 Sep 2007 Volume 2007 : Issue 480 Contents: Re: DECnet-Plus for a hobbyist Re: DECnet-Plus for a hobbyist Re: The Common System Interface: Intel's Future Interconnect Re: The Common System Interface: Intel's Future Interconnect Re: The Common System Interface: Intel's Future Interconnect Re: The Common System Interface: Intel's Future Interconnect Re: Third sunday in the month Re: Third sunday in the month Re: Third sunday in the month Re: Third sunday in the month Re: VMS License Plates Re: VMS License Plates Re: VMS License Plates Re: VMS License Plates ---------------------------------------------------------------------- Date: Sat, 01 Sep 2007 09:38:10 GMT From: "Colin Butcher" Subject: Re: DECnet-Plus for a hobbyist Message-ID: <6qaCi.6302$c_1.926@text.news.blueyonder.co.uk> Maybe a little late to join the fray, but you might find this useful for some of the background: http://www.downloads.xdelta.co.uk/vmstjv5%20feb2005/decnet%20article%20vms%20tj%20v5%20feb2005.pdf - it's an article I wrote for the Technical Journal a while back. I'd recommend the effort to get to grips with Phase V as it does do a better job, especially in multiple LAN (or VLAN) networks, for example you get load balancing on all paths for the price of an end-system license. Phase V can also give you a lot more useful information when trying to figure out what's happening. Have fun! - Cheers, Colin. Legacy = Stuff that works properly! ------------------------------ Date: 1 Sep 2007 07:53:38 -0500 From: Kilgallen@SpamCop.net (Larry Kilgallen) Subject: Re: DECnet-Plus for a hobbyist Message-ID: In article <6qaCi.6302$c_1.926@text.news.blueyonder.co.uk>, "Colin Butcher" writes: > I'd recommend the effort to get to grips with Phase V as it does do a better > job, especially in multiple LAN (or VLAN) networks, But a worse job on Security, without the SET EXECUTOR DEFAULT ACCESS NONE capability of Phase IV. That is what is required by NIST SP 800-53 SC-7 Boundary Protection Control Enhancement (5) required for Moderate and High (FIPS-199) impact systems: (5) The information system denies network traffic by default and allows network traffic by exception (i.e., deny all, permit by exception). And the DECUS (sic) Security SIG made a formal request of DEC (sic) to fix that before Phase V was released, many years before NIST SP 800-53 was released. ------------------------------ Date: 1 Sep 2007 07:10:58 GMT From: "dave weatherall" Subject: Re: The Common System Interface: Intel's Future Interconnect Message-ID: <5jshk2F13cjuU1@mid.individual.net> Ron Johnson wrote: > On 08/30/07 22:44, JF Mezei wrote: > [snip] > > > > > > CSI will give the 8086 capabilities once reserved to high end > > chips. And porting VMS to it would give VMS access to a far greater > > market. > > QuickPath (new name of Common System Interface) offers nothing > that Athlon64 and Opteron using HyperTransport haven't had for 4 > years. Ah but this Intel QuickPath for Intel 64-bit extended machines :-) -- Cheers - Dave ------------------------------ Date: Sat, 1 Sep 2007 11:29:37 +0100 From: "John Wallace" Subject: Re: The Common System Interface: Intel's Future Interconnect Message-ID: <13difokt591vj39@corp.supernews.com> "JF Mezei" wrote in message news:a7262$46d78e82$cef8887a$6852@TEKSAVVY.COM... > VMS is hindered by running only on that IA64 thing. IA64 is not an asset > it is a liability to VMS. > Long post follows, sorry. That's your opinion, JF. In this picture, you don't count (Kerry says so :)). The people whose opinions count include: . end users . developers (in house or wherever) . consultants (from Gartner to Bruden and everywhere in between) . application builders . middleware builders . OS builders . server hardware builders . chip builders (I don't think that's misrepresenting what Kerry says, but that's certainly my opinion :)). As long as those folks are convinced that money spent on IA64 is at least as rewarding to them as money spent on AMD64 and its Intel clones, they will (continue to) invest in IA64. And as long as *all* the ones in that list relevant to any particular customer stay on the IA64 track, and are publically committed to stay on the IA64 track for the timescales relevant to any particular paying customer, the customer is probably OK with IA64. IA64 may even sometimes bring these folks some USPs not available elsewhere in the market (though afaict the obvious USPs would appear to be HP-UX and VMS and not much else, can anyone remind me of any other USPs or of the technical reasons why HP-UX and VMS are still IA64-specific?). As Kerry says, reliability and availability are very important to enterprise-class purchasing decisions these days. When it's anything like a "bet your business" operation, that applies at a *commercial* level too, not just at an exploding-gas-pipe technical level. Customers (and other folks on the above list) choosing AMD64 and stuff based on AMD64 know that they will almost always have a relatively simple/inexpensive "failover" path to another mostly-compatible usually-good-enough supplier. Customers choosing IA64-specific stuff don't have those same choices. Many folks are surprisingly happy to be locked in to Microsoft/x86 (even post-Vista) and/or to VMware/x86, but IA64 doesn't seem to have quite the same market pull yet, despite the attractions of VMS and HP-UX. If any *one* of the folks in a customer's IT ecosystem decides the IA64 route isn't a moneyspinner for them, the IA64 end customer is a bit embarrassed, and so are the brave folks who made the IA64 decision - IA64 may even become a "career-limiting decision" at that point. Intel HQ's opinion matters a great deal to the future of IA64. If something isn't making money for them, Intel *will* drop it. Who remembers I2O, which was going to be "the next big thing" around the same time as Merced was also going to be "the next big thing"? Intel could probably be persuaded to continue with an unprofitable (in commodity terms) IA64 if the external IA64 ecosystem paid Intel lots of money to cover the non-manufacturing costs, but then you're back to the very same scenario as the "development tax" which allegedly killed Alpha - development costs allegedly far too high to sustainably sensibly spread over a relatively low overall systems revenue. With Alpha, the development money was initially justified on the business plan as an "investment in the future", on the hope that Alpha would be a mass market architecture. IA64 doesn't have that opportunity, the world already knows that IA64 isn't ever going "industry standard", because AMD64 got there already. Hence IA64 won't get that "investment", hence IA64 is just a continuous drag on Intel's (and/or HP's?) profitability. CSI may reduce some of the hardware-related costs for IA64 system builders, but as many have spotted, for the IT industry in general it makes it even *more* difficult for IA64 to come out on top against genuine industry standard kit (which CSI just makes more attractive). Post-CSI, how long will HP be able to justify two separate sets of hardware engineering teams? At the low end, where's the difference going to be between an entry-level CSI-based IA64 box and a comparable decent Deskpro/Proliant equivalent? In the mid range, Proliant already does very nicely thank you, and CSI will just offer customers a sensibly-scalable Intel option as well as the existing nicely scalable AMD/Opteron option, and the box will allegedly be plug-compatible with IA64, so what will make IA64-specific boxes any better? At the high end? Who cares, blades are the answer (whether you believe it or not). The difference is mainly in the software and all that goes with it, and the HP decision as to what chip their software runs on still appears to be political/emotional rather than technical/commercial. 2p John ------------------------------ Date: Sat, 01 Sep 2007 05:38:44 -0500 From: Ron Johnson Subject: Re: The Common System Interface: Intel's Future Interconnect Message-ID: On 09/01/07 02:10, dave weatherall wrote: > Ron Johnson wrote: > >> On 08/30/07 22:44, JF Mezei wrote: >> [snip] >>> >>> CSI will give the 8086 capabilities once reserved to high end >>> chips. And porting VMS to it would give VMS access to a far greater >>> market. >> QuickPath (new name of Common System Interface) offers nothing >> that Athlon64 and Opteron using HyperTransport haven't had for 4 >> years. > > Ah but this Intel QuickPath for Intel 64-bit extended machines :-) And em64t opcodes soooooo much better than AMD64 opcodes. How could I have ever forgotten? -- Ron Johnson, Jr. Jefferson LA USA Give a man a fish, and he eats for a day. Hit him with a fish, and he goes away for good! ------------------------------ Date: Sat, 01 Sep 2007 11:07:39 -0400 From: JF Mezei Subject: Re: The Common System Interface: Intel's Future Interconnect Message-ID: Main, Kerry wrote: > Are you still harping on the Scott statement from 5 years ago? Not only did HP NOT counter Stallard's statement from 5 years ago, but Livermore confirmed it again a few weeks ago in a Computer World interview. When HP says so little about VMS, every little bit they say becomes very important. > The IBM VP of Software stated publicly that he thought AIX users would eventually > be migrated to Linux and he was fine with that. Reference: Replacing one version of unix with another is not quite the same as wanting customers to drop VMS in favour of Unix. > Big companies are made up of many smaller "companies" or BU's and their public > statements often reflect their own personal OS preferences and do not necessarily > reflect the official views of the company. Ahh, but here is the catch: Stallard and Livermore represent Official *HP* policy. Sue's statements represent VMS policy. And in the end, HP is the one that makes the big decisions on whether to allow VMS to thrive or to restrict it only to the installed base. > Know anyone from HP on this newsgroup that does not want OpenVMS to grow to the clouds? This newsgroup does not have HP participants. It only has VMS participants. And no matter how hard Sue tries, if she is not allowed by HP to send out a real press release, then that press release doesn't go out and stays limited to the VMS web site. > JF - with all due respect, I know you have the best interests of OpenVMS at heart, but > simply stating something out of the blue for shock value (as if it were fact) only does > discredit to yourself. If you are not happy with it, then you should complain to stallard and livermore and tell them that their statements are hurting HP's enterprise business and not helping build any trust between VMS customers and HP. ------------------------------ Date: Sat, 01 Sep 2007 05:49:29 -0700 From: apogeusistemas@gmail.com Subject: Re: Third sunday in the month Message-ID: <1188650969.496008.43610@k79g2000hse.googlegroups.com> On 31 ago, 22:45, Tad Winters wrote: > apogeusiste...@gmail.com wrote in news:1188427622.398539.57180@ > 22g2000hsm.googlegroups.com: > > [snip..] > > > $ set nover > > $ hour="''F$EXTRACT(12,2, F$TIME())'" > > $ day=F$CVTIME(,,"day") > > $ week=F$CVTIME(,,"weekday") > > $ if ((week .eqs. "Sunday") .and. (day .gt. "14") .and. (day .lt. > > "23") .and. (hour .eq. "12")) then goto dispara > > $exit > > $dispara: > > $ mail/subj=" >>> Restarte o Server <<< " sys > > $login:restart_server.txt "smtp%""schwa...@aaaaaaa.com.br""" > > $exit > > > Thanks a lot for your examples ! > > Forgetting the calculation of the third Sunday of the month, is this a > reminder to restart a VMS system? If the answer is yes, you certainly must > have some other question that needs to be answered. I need restart a W2K3 sql server every 3rd Sunday. Task passed by a Windows administrator... ------------------------------ Date: Sat, 01 Sep 2007 06:29:35 -0700 From: AEF Subject: Re: Third sunday in the month Message-ID: <1188653375.860361.214550@k79g2000hse.googlegroups.com> On Aug 30, 8:38 am, VAXman- @SendSpamHere.ORG wrote: > In article <1188437058.314136.41...@57g2000hsv.googlegroups.com>, apogeusiste...@gmail.com writes: > [...] > >I made this change: > > >$ hour=3D"''F$EXTRACT(12,4, F$TIME())'" > >$ day=3DF$CVTIME(,,"day") > >$ week=3DF$CVTIME(,,"weekday") > >$ if ((week .eqs. "Sunday") .and. (day .gt. 14) .and. (day .lt. > >22) .and. (hour .eq. "12:0")) then goto dispara > > >and I=B4ll receive only 2 alerts (maybe only 1) > > You can avoid the two date compares with this BTW: > > ((day .gt. 14) .and. (day .lt.22)) == ((day-1)/7 .eq. 2) What's the advantage of this? This is DCL, no? Why the double equals sign? > > -- > VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM > [...] AEF ------------------------------ Date: Sat, 01 Sep 2007 14:32:08 +0100 From: "R.A.Omond" Subject: Re: Third sunday in the month Message-ID: apogeusistemas@gmail.com wrote: > [...snip...] > > I need restart a W2K3 sql server every 3rd Sunday. > Task passed by a Windows administrator... Every *3rd* *Sunday* ? I thought you had to restart them every day ;-) ------------------------------ Date: Sat, 01 Sep 2007 16:37:42 GMT From: VAXman- @SendSpamHere.ORG Subject: Re: Third sunday in the month Message-ID: In article <1188653375.860361.214550@k79g2000hse.googlegroups.com>, AEF writes: > > >On Aug 30, 8:38 am, VAXman- @SendSpamHere.ORG wrote: >> In article <1188437058.314136.41...@57g2000hsv.googlegroups.com>, apogeusiste...@gmail.com writes: >> >[...] >> >I made this change: >> >> >$ hour=3D"''F$EXTRACT(12,4, F$TIME())'" >> >$ day=3DF$CVTIME(,,"day") >> >$ week=3DF$CVTIME(,,"weekday") >> >$ if ((week .eqs. "Sunday") .and. (day .gt. 14) .and. (day .lt. >> >22) .and. (hour .eq. "12:0")) then goto dispara >> >> >and I=B4ll receive only 2 alerts (maybe only 1) >> >> You can avoid the two date compares with this BTW: >> >> ((day .gt. 14) .and. (day .lt.22)) == ((day-1)/7 .eq. 2) > >What's the advantage of this? > >This is DCL, no? Why the double equals sign? Doh! The expression: ((day .gt. 14) .and. (day .lt.22)) can be expressed as or is equivalent to: ((day-1)/7 .eq. 2) It has nothing to do with DCL per se. Normalizing the day to 0 (day-1) allow one to check for the week using 0,1,2,3... for 1st, 2nd, 3rd, 4th 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: Sat, 01 Sep 2007 10:48:06 GMT From: VAXman- @SendSpamHere.ORG Subject: Re: VMS License Plates Message-ID: In article <8q6Ci.19183$Zk5.16187@newsfe23.lga>, Ron Johnson writes: > > >On 08/31/07 21:13, Main, Kerry wrote: >>> -----Original Message----- >>> From: Larry Kilgallen [mailto:Kilgallen@SpamCop.net] >>> Sent: August 31, 2007 12:20 PM >>> To: Info-VAX@Mvb.Saic.Com >>> Subject: RE: VMS License Plates >>> >>> Of course there are some of us who will display a license plate >>> (or other trinket) that says VMS but not one that says OpenVMS. >>> >>> I doubt there are any of the reverse persuasion. >>> >>> I suppose that means a chance to lower the production cost by adding >>> three letters. >> >> Well, something to consider about VMS vs. OpenVMS is that there are now other vendor >> products called VMS: >> >> http://www.networkworld.com/reviews/2002/0204rev.html > >That's a copyright violation if I every heard one. How is it a _copyright_ violation? What was said or printed in the article that is not "fair use" information possibly from some Cisco features documentation? -- 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: 1 Sep 2007 11:10:46 GMT From: bill@cs.uofs.edu (Bill Gunshannon) Subject: Re: VMS License Plates Message-ID: <5jsvlmF14tjjU1@mid.individual.net> In article , Ron Johnson writes: > On 08/31/07 17:00, Bill Gunshannon wrote: > [snip] >> >> Now, could someone provide the real answer? When did DECNET first come >> into existence? > > 1975. I wouldn't be surprised if network email arrive in Phase II > (1976) or Phase III (1980). > > http://en.wikipedia.org/wiki/DECnet > DECnet is a suite of network protocols created by Digital > Equipment Corporation, originally released in 1975 in order > to connect two PDP-11 minicomputers. It evolved into one of > the first peer-to-peer network architectures, thus transforming > DEC into a networking powerhouse in the 1980s. > >> Was there any serial machine-to-machine protocol for >> VMS before the first port of UUCP? > > DECnet III supported X.25. > OK, I worded that wrong. I knew tere was DECNET for the PDP-11. When was DECNET first avalable for VMS and was there any other inter-machine protocol before that? 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: Sat, 01 Sep 2007 16:13:10 +0200 From: Dirk Munk Subject: Re: VMS License Plates Message-ID: Sue wrote: > Dear Newsgroup, > > If you remember we have done VMS License plates over the years. The > last one we did had "When downtime is NOT an option" > > I was thinking about doing them again for our 30th. Let me know what > you think. > > Warm Regards, > Sue > HP OpenVMS - Not even HP management can shut it down. ------------------------------ Date: Sat, 01 Sep 2007 11:08:48 -0400 From: JF Mezei Subject: Re: VMS License Plates Message-ID: Main, Kerry wrote: > Well, something to consider about VMS vs. OpenVMS is that there are now other vendor > products called VMS: And why, may I ask, would the owned of the real VMS allow its trademark to lapse and/or be used by someone else ?????? ------------------------------ End of INFO-VAX 2007.480 ************************