INFO-VAX Fri, 02 Mar 2007 Volume 2007 : Issue 122 Contents: Re: Canadian OpenVMS Seminar (07.02.20) Re: Canadian OpenVMS Seminar (07.02.20) Re: Canadian OpenVMS Seminar (07.02.20) For Charlie Hammond and his excellent DCL checker. Re: For Charlie Hammond and his excellent DCL checker. Re: History of VMS and related operating systems Re: History of VMS and related operating systems Re: History of VMS and related operating systems Re: History of VMS and related operating systems Re: Seeking for an ALPHA SCSI disk Re: SWAT using Samba v3 on VMS8.2 Symbolic links in VMS V8.3 Wanted: MicroVAX I / VAXstation I owners Re: Wanted: MicroVAX I / VAXstation I owners Re: Wanted: MicroVAX I / VAXstation I owners ---------------------------------------------------------------------- Date: Fri, 2 Mar 2007 10:23:33 -0000 From: "John Wallace" Subject: Re: Canadian OpenVMS Seminar (07.02.20) Message-ID: <12ufvk08j0i5169@corp.supernews.com> "Robert Deininger" wrote in message news:rdeininger-2402071048310001@dialup-4.233.173.233.dial1.manchester1.leve l3.net... > All marketing fluff should be taken with a grain of salt, and > fancy-sounding terms should be defined and understood before any > real-world value is assumed. Agreed (as with the rest of your stuff). Lots of interesting reading in your post, which unfortunately I may not be able to get around to for a while. In the meantime, are readers really supposed to conclude that HP's best marketing (and maybe other) folks consider that "cosmic rays" is the appropriate answer to the question of "What specific RAS-related features are not available in currently available AMD64 servers, when compared with features which are available in (comparably-priced?) currently available Itanium/Integrity servers?". Re: Solaris x86: Neil wrote about "running Solaris or LINUX on x86 to see "if the hardware is flaky" or "is Windoz just junk". (I put my money on Windoz being flaky which means HP should still start a Skunk Works to port OpenVMS to x86-64)." For this discussion, let's ignore Linux and stick to Solaris, which has a Fault Management Architecture, and one of the folks working on it is Gavin Maltby who has a blog at http://blogs.sun.com/gavinm/ It's no secret that AMD introduced Opteron Revision F last year, with support for DDR2 memory and support for online spare memory chips, amongst other stuff. Gavin's blog entry at http://blogs.sun.com/gavinm/entry/fma_support_for_amd_opteron talks in reasonable detail (far more than we've seen from HP so far) about other RAS-related differences but his summary seems to be that "... there are no new error types detected in these banks (icache, dcache, load-store unit, bus unit aka l2cache) so no additional error reports for us to raise or any change required to the diagnosis rules that consume those error reports." C'mon HP, plenty of folks understand soft memory errors and the like at some level of detail (which is presumably what the "cosmic rays" reference related to). Plenty of people also know that if Proliant-class systems (not just from HP, but from Dell, IBM, Sun, etc) couldn't already cope adequately (for some value of "adequate") with that kind of thing, they wouldn't sell in the kind of volumes we see. So, one more time: what specific RAS features are in Itanium systems that aren't in comparable AMD64 systems (or the Intel equivalent, for anyone in VMSland who for some reason might prefer to retain the exclusive commercial relationship with Intel)? The UK HP User Group has an Intel-sponsored seminar on the theme of Integrity, scheduled for April 24. Maybe someone in HP or Intel could arrange for a plausible answer to be available by then, but earlier would be better. regards John ------------------------------ Date: 2 Mar 2007 07:55:24 -0600 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: Canadian OpenVMS Seminar (07.02.20) Message-ID: In article <12ufvk08j0i5169@corp.supernews.com>, "John Wallace" writes: > > Re: Solaris x86: Neil wrote about "running Solaris or LINUX on x86 to see > "if the hardware is flaky" or "is Windoz just junk". (I put my money on > Windoz being flaky which means HP should still start a Skunk Works to port > OpenVMS to x86-64)." There is a lot-a, lot-a junk hardware in Windows land. Not quite as much as there was in DOS land (Windows is more demanding), but a lot. Just as VMS won't run on all IA64 hardware because HP isn't going to do the work on any hardware but thier own, a port to x86-64 would probably also ony be supported on HP hardware. But there might be more hobbyists interested in weekend hacks to Dell Pentiums than Dell Itaniums. ------------------------------ Date: Fri, 02 Mar 2007 13:59:24 GMT From: rdeininger@mindspringdot.com (Robert Deininger) Subject: Re: Canadian OpenVMS Seminar (07.02.20) Message-ID: In article <12ufvk08j0i5169@corp.supernews.com>, "John Wallace" wrote: >"Robert Deininger" wrote in message >news:rdeininger-2402071048310001@dialup-4.233.173.233.dial1.manchester1.leve >l3.net... > >> All marketing fluff should be taken with a grain of salt, and >> fancy-sounding terms should be defined and understood before any >> real-world value is assumed. > >Agreed (as with the rest of your stuff). > >Lots of interesting reading in your post, which unfortunately I may not be >able to get around to for a while. > >In the meantime, are readers really supposed to conclude that HP's best >marketing (and maybe other) folks consider that "cosmic rays" is the >appropriate answer to the question of "What specific RAS-related features >are not available in currently available AMD64 servers, when compared with >features which are available in (comparably-priced?) currently available >Itanium/Integrity servers?". The marketing folks mostly don't understand the technical details, so they can't describe them satisfactorily. What you really want is for technical folks to take the time to explain the details to non-experts, and then have the marketing folks make it presentable (without making it wrong) and then work to make sure everyone sees the information. Of course, company policy doesn't allow the technical folks to release internal information to the public. So it will only happen if the marketing folks see it as a priority. Which will only happen if they get feedback asking for more technical details about [pick your favorite topic]. AFAIK, no HP marketing folks pay attention to this newsgroup, so your message isn't getting through. I'm not a marketeer, and I have neither the time nor the inclination to dig through other CPU specs and argue the benefits. Though I find it a bit odd... you mentioned that you haven't had time to read the stuff I pointed out, but you're still flogging HP for not giving out enough information. I would expect that at least some of your questions would be answered if you looked at that stuff. And then you'd likely have more questions, some of which might be answerable by folks here. (If a document doesn't have the information you think it should have, the quickest way to get it fixed is to send feedback directly to the people who write the document. They don't read this newsgroup either.) A few (ok, a lot of) words about sources of faults that can make systems fail. These are things I have seen and/or heard about in systems I've worked on, in no particular order. Some of these don't involve the CPU at all, so folks only interested in Itanium-basing and/or AMD-worship are invited to ignore those items... 1. Power supplies and fans. These are the most frequent failures in many systems. The current fad (on all but the cheapest systems) is to make them redundant and hot-swapable, and make the system detect and report failures. System downtime should be almost non-existant, except when the user ignores indications of the first (N-1) failures. 2. Data corruption due to external events. Stuff like cosmic rays and background radiation. A big source is the inherent alpha-emitting radioactive stuff in the system components. These problems get worse as components get smaller, and also as the size of memory and caches increases. 3. Data corruption due to signal integrity problems. These don't get as much press, because they are harder to understand, and harder to detect, test for, and fix. Every generation of computer that's pushing the limits of it's technology to run as fast as possible has signal integrity issues. This gets into the "black magic" of high speed circuit design. Forget the stuff you learned in your introduction to digitial electronics. Ones and zeros aren't really represented by nice clean "high" and "low" voltage levels on the wires. Real circuits have crosstalk, voltage sag, time skew, ringing, and other problems. If you want the whole system to run fast, a small fraction of the circuits will produce the wrong output a small fraction of the time. This is true in every system. The engineers design to reduce these problems and detect the ones that slip through. They balance those goals against cost, time-to-market, and overall reliability. A sub-case here is components that work fine when new, but degrade in ways that weren't expected during the life of the system. For items 2 and 3, the only safe solution is error detection (or better, correction) on the WHOLE data path. For example, if you need to move 64 bits of data from a SCSI disk into a CPU register, you'd like to have error detection in at least these places: a. the disk platter b. all the registers and address and data paths in the disk's controller c. all the registers and address and data paths in the SCSI contrller chip d. all the PCI transceivers between the SCSI card and the system's IO controller e. all the data and address paths between the IO controller and memory f. all the cache levels in the system (cache data, cache tags, etc.) g. all the data paths and registers, and cache in the CPU's many functional units. Alternatively, make EVERYTHING dual-redundant, do everything two or more times in parallel, and reject every output where the answers don't match. 4. Data corruption caused by bugs in hardware, firmware, and software (including the OS and applications). In practice, components work most of the time, but fail for peculiar sets of conditions. These problems can be gradually reduced through testing, but extensive testing is the enemy of commodity (cheap) product and pricing models. We may be forced to use buggy, off-the-shelf components, but at least we can try to detect and contain the errors they generate. You really need to look at the whole system to judge the error-handling features. But if you want to focus on the CPU part, the Itanium Error Handling Guide I refered to in my other post is a good place to start. I expect you can compare Itanium and AMD64 feature-by-feature if you have time. My own opinion is that many people (including some in HP marketing) focus too much on the CPU, and OS and system features that have much more impact on the end-user. ------------------------------ Date: 2 Mar 2007 04:53:15 -0800 From: "Big John" Subject: For Charlie Hammond and his excellent DCL checker. Message-ID: <1172839995.673676.70160@v33g2000cwv.googlegroups.com> Hi. This is really a message aimed at Charlie Hammond (if you are out there anywhere reading this), but seems to me of general interest to the group anyway. I have discovered a little bug in your sublimely useful DCL_CHECK procedure. If you are still developing / perfecting it, maybe you could pop this on your list of things to do. It threw up an error when there was none. Here is an example of it: $ TYPE TEST.COM $ run /detach testproc /out=jp.out /error=jp.err /proc="JPTESTING" $ Now run this through the checker.. $ dcl_check test.com -*- Charlie Hammond's unsupported DCL checker (Version V2.0) -*- Checking file USRDISK:[JGP.GAUEN]TEST.COM; Starting Pass 1 -- 2-MAR-2007 12:33:29.02 ... Starting Pass 2 -- 2-MAR-2007 12:33:29.10 ... Starting Pass 3 -- 2-MAR-2007 12:33:29.30 ... Procedure contains: 1 total lines 1 code lines (including 0 lines w/ comments) 0 additional continuation lines 0 lines w/i $DECK/$EOD pairs 0 comment only lines 0 blank lines LINE CODE --DIAGNOSTIC MESSAGE-- 1 LNF label "JP.ERR" not found -*- END OF LISTING -*- 2-MAR-2007 12:33:29.69 $ It has interpreted the value attached to the /ERROR qualifier as a label. But it should be a file, as is explained in the help. $ help run proc /error RUN Process /ERROR /ERROR=filespec Defines an equivalence name string of 1 to 63 alphanumeric characters for the logical device name SYS$ERROR. The logical name and equivalence name are placed in the process logical name table for the created process. (The /ERROR qualifier is ignored if you are running SYS$SYSTEM:LOGINOUT.) Topic? $ No biggie, once you are aware of it, you can just ignore these errors. But I suspect somebody who wrote something as good as DCL_CHECK would be a real perfectionist, and want to ensure it is flawless. - John ------------------------------ Date: Fri, 2 Mar 2007 08:56:58 -0500 From: norm.raphael@metso.com Subject: Re: For Charlie Hammond and his excellent DCL checker. Message-ID: "Big John" wrote on 03/02/2007 07:53:15 AM: > Hi. This is really a message aimed at Charlie Hammond (if you are out > there anywhere reading this), but seems to me of general interest to > the group anyway. > > I have discovered a little bug in your sublimely useful DCL_CHECK > procedure. If you are still developing / perfecting it, maybe you > could pop this on your list of things to do. > > It threw up an error when there was none. Here is an example of it: > > $ TYPE TEST.COM > $ run /detach testproc /out=jp.out /error=jp.err /proc="JPTESTING" > $ > > Now run this through the checker.. > > $ dcl_check test.com > -*- Charlie Hammond's unsupported DCL checker (Version V2.0) -*- > Checking file USRDISK:[JGP.GAUEN]TEST.COM; > Starting Pass 1 -- 2-MAR-2007 12:33:29.02 ... > Starting Pass 2 -- 2-MAR-2007 12:33:29.10 ... > Starting Pass 3 -- 2-MAR-2007 12:33:29.30 ... > Procedure contains: 1 total lines > 1 code lines (including 0 lines w/ comments) > 0 additional continuation lines > 0 lines w/i $DECK/$EOD pairs > 0 comment only lines > 0 blank lines > LINE CODE --DIAGNOSTIC MESSAGE-- > 1 LNF label "JP.ERR" not found > -*- END OF LISTING -*- 2-MAR-2007 12:33:29.69 Unfortunately for you, you are running an outdated version of DCL_CHECK. V3.4 does not report this as an error and has many improvements over V2.0. $ @dcl_check test.com -*- Charlie Hammond's unsupported DCL checker (Version V3.4) -*- Checking file TEST.COM;1 2-MAR-2007 08:52:15.17 Checking for DCL_CHECK$ logicals... "DCL_CHECK$SUPPRESS_BL" = "TRUE" "DCL_CHECK$SUPPRESS_CCN" = "TRUE" "DCL_CHECK$SUPPRESS_CLD" = "TRUE" "DCL_CHECK$SUPPRESS_LFF" = "TRUE" "DCL_CHECK$SUPPRESS_LND" = "TRUE" "DCL_CHECK$SUPPRESS_LOD" = "TRUE" Starting Pass 1 -- 2-MAR-2007 08:52:16.89 ... Starting Pass 2 -- 2-MAR-2007 08:52:17.37 ... Starting Pass 3 -- 2-MAR-2007 08:52:17.48 ... Procedure contains: 3 total lines 3 code lines (including 0 lines (0%) w/ comments) 0 additional continuation lines 0 lines w/i $DECK/$EOD pairs 0 comment only lines (0% of code lines) 0 blank lines 0 diagnostics -*- No diagnostics -*- 2-MAR-2007 08:52:19.18 I strongly suggest you ask Charlie for the newer version. > $ > > It has interpreted the value attached to the /ERROR qualifier as a > label. But it should be a file, as is explained in the help. > > $ help run proc /error > > RUN > > Process > > /ERROR > > /ERROR=filespec > > Defines an equivalence name string of 1 to 63 alphanumeric > characters for the logical device name SYS$ERROR. The logical > name and equivalence name are placed in the process logical > name > table for the created process. (The /ERROR qualifier is ignored > if you are running SYS$SYSTEM:LOGINOUT.) > > > > Topic? > $ > > No biggie, once you are aware of it, you can just ignore these errors. > But I suspect somebody who wrote something as good as DCL_CHECK would > be a real perfectionist, and want to ensure it is flawless. > > - John > ------------------------------ Date: Fri, 02 Mar 2007 07:58:22 GMT From: Nigel Barker Subject: Re: History of VMS and related operating systems Message-ID: On 28 Feb 2007 08:19:24 -0800, "UnderMine" wrote: >It also mentions Desktop-VMS I had not heard of that one before and >unfortunately any search for it is swamped by desktop VMs. IIRC Desktop-VMS was a special packaging of VMS for MicroVAX systems with very small disk drives where part of the OS was run from a CD. -- Nigel Barker Live from the sunny Cote d'Azur ------------------------------ Date: 2 Mar 2007 02:25:54 -0800 From: "vaxorcist" Subject: Re: History of VMS and related operating systems Message-ID: <1172831154.791619.144620@30g2000cwc.googlegroups.com> > > > MicroVMS 4.x - numbers synced with VMS - pritty well documented but > > > sometimes hard to date. > > Still looking for confirmation of all the dates As to help clearing sight about VMS / MicroVMS versions: I've looked into some VMS V4.x tapes and found out the following: Version Type Date written MicroVAX support V4.0 Full 23-SEP-1984 NO V4.1 Update ?? V4.2 Full 12-JUL-1985 NO V4.3 Update 9-JAN-1986 VMS043.A-COMMON FILES / VMS043.B-VMS ONLY / Saveset VMS043.C-UVMS ONLY V4.4 Full 30-MAR-1986 YES (integral part of all Savesets) V4.5 Update 26-SEP-1986 same as with V4.3 (individual Savesets) V4.6 Full 15-JUN-1987 same as with V4.4 (integral part of all Savesets) V4.7 Update 29-OCT-1987 same as with V4.3 (individual Savesets) That seems to me a rather good proof that MicroVMS versions are (at least from V4.3 onwards) functionally equal (to the extend possible on MicroVAXen) to the corresponding VMS versions. Distribution tapes were identical, whereas the RX50 floppy sets most probably were not. Besides, what would you consider a "Release Date"? - A date given in an official DEC announcement - The Release Date of the Version Release Notes Manual - The date when distribution media was written - ... I'm still looking for the following versions: - VMS V4.1 - VMS V4.2 MUP (Mandatory Update) - VMS 4.3A - VMS 4.5A - VMS 4.5B - VMS 4.5C - VMS 4.6A - VMS 4.6B - VMS 4.6C - VMS 4.7A Can anybody help ??? Has anyone got any MicroVMS V1.0 media or software ??? Regards Ulli P.S. DEC called MicroVMS "retired" from VMS 5.0 onwards ------------------------------ Date: Fri, 02 Mar 2007 14:32:05 GMT From: Nigel Barker Subject: Re: History of VMS and related operating systems Message-ID: On 28 Feb 2007 08:19:24 -0800, "UnderMine" wrote: >It also mentions Desktop-VMS I had not heard of that one before and >unfortunately any search for it is swamped by desktop VMs. IIRC Desktop-VMS was a special packaging of VMS for MicroVAX systems with very small disk drives where part of the OS was run from a CD. -- Nigel Barker Live from the sunny Cote d'Azur ------------------------------ Date: 2 Mar 2007 07:49:06 -0600 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: History of VMS and related operating systems Message-ID: <+z57ZRmCvJVr@eisner.encompasserve.org> In article , Nigel Barker writes: > On 28 Feb 2007 08:19:24 -0800, "UnderMine" wrote: > >>It also mentions Desktop-VMS I had not heard of that one before and >>unfortunately any search for it is swamped by desktop VMs. > > IIRC Desktop-VMS was a special packaging of VMS for MicroVAX systems with very > small disk drives where part of the OS was run from a CD. Yes, and Desktop-VMS could not join a VAXcluster. So we dropped it and reused the hardware as cluster satellites. ------------------------------ Date: Fri, 2 Mar 2007 08:28:16 +0100 From: "Michel HERRSCHER" Subject: Re: Seeking for an ALPHA SCSI disk Message-ID: Thanks to all for all. Merci . Je vous appelle en privé. Je vous appelleDans un message Island Computers, D B Turner disait : > Nous avons le disque voulu > > Notre prix est $109 pu > > Veuillex me contacter pour commander > >> Hello to all, >> >> I am looking for a SCSI disk : the label on my dead one says : >> DS-RZ1DA-VW >> >> It goes into a disk bay of a BA350 ( not sure of the 350) >> >> If you have a spare , please make me an offer for one shipped and >> pakaged securely ;-)) >> >> destination FRANCE >> >> Thanks in advance >> -- >> Michel HERRSCHER -- Michel HERRSCHER ------------------------------ Date: Fri, 02 Mar 2007 13:01:03 +0100 From: Martin Vorlaender Subject: Re: SWAT using Samba v3 on VMS8.2 Message-ID: <54qhvvF21qug2U1@mid.individual.net> Gremlin wrote: > I wrote: >> Generally, I guess you'd have to define the service first, like: >> >> $ TCPIP SET SERVICE swat - >> /FILE=samba_root:[bin]start_swat.com - >> /PORT=901 - >> /PROTOCOL=TCP - >> /PROCESS_NAME=swat - >> /USER=vms_user_account > > Sadly, there is no start_swat, or any type of swat anything in the whole > tree, apart from swat.exe - that is what has me stumped!! Looking at the SWAT manual [1], I'd reckon SWAT isn't completely installed, as I can't find any of the support files mentioned under SAMBA_ROOT: . They aren't in the source kit either... According to the macro definition of SWATDIR in [src.include]config_vms.h, they should go to /SAMBA_ROOT/SWAT. But even with getting these files (from the original source distrib), putting them into that directory, writing a start_swat.com (consisting mostly of $ RUN SAMBA_ROOT:[BIN]SWAT.EXE), and setting up and enabling the service, I don't get far. I do get the authentication box, but nothing more. I managed to get it started in demo mode, but without images or any functionality. No time now for digging deeper. I guess we'll have to wait for Eval 4... cu, Martin [1] http://us4.samba.org/samba/docs/man/Samba-HOWTO-Collection/SWAT.html -- One OS to rule them all | Martin Vorlaender | OpenVMS rules! One OS to find them | work: mv@pdv-systeme.de One OS to bring them all | http://www.pdv-systeme.de/users/martinv/ And in the Darkness bind them.| home: martin@radiogaga.harz.de ------------------------------ Date: Fri, 2 Mar 2007 10:46:19 -0600 (CST) From: sms@antinode.org (Steven M. Schweda) Subject: Symbolic links in VMS V8.3 Message-ID: <07030210461921_2020028F@antinode.org> According to: http://h71000.www7.hp.com/doc/83FINAL/6679/6679pro_008.html#prog_chap we now (V8.3) have support for symbolic links, including new functions in the C run-time library, and changes in DCL, RMS, and so on. After some fooling around, I've started to think that there may be some problems with this stuff. Because good answers haven't been pouring in on the ITRC forum, I thought that I'd mention my complaints (so far) here as well, in case anyone with (mild) ITRCphobia has any wisdom. CREATE /SYMLINK v. SET PROCESS /PARSE_STYLE = EXTENDED http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1102555 RMS v. symbolic links http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1104571 BACKUP v. symbolic links http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1104948 I don't want to be seen as making threats, but if I don't get some better answers soon, I may be compelled to submit some "OpenVMS Systems Product feedback" at the product business feedback Web page (http://h71000.www7.hp.com/fb_business.html), and I'm sure that no one really wants that. ------------------------------------------------------------------------ Steven M. Schweda sms@antinode-org 382 South Warwick Street (+1) 651-699-9818 Saint Paul MN 55105-2547 ------------------------------ Date: 2 Mar 2007 03:04:16 -0800 From: "vaxorcist" Subject: Wanted: MicroVAX I / VAXstation I owners Message-ID: <1172833456.664174.120990@8g2000cwh.googlegroups.com> Who else has got (and eventually runs) the worlds slowest VAX ever ??? I'm going to build one from parts and will probably need some help. All OSes welcome! Regards Ulli ------------------------------ Date: Fri, 2 Mar 2007 11:18:52 +0000 (UTC) From: dfevans@bcr10.uwaterloo.ca (David Evans) Subject: Re: Wanted: MicroVAX I / VAXstation I owners Message-ID: In article <1172833456.664174.120990@8g2000cwh.googlegroups.com>, vaxorcist wrote: >Who else has got (and eventually runs) the worlds slowest VAX ever ??? > >I'm going to build one from parts and will probably need some help. >All OSes welcome! > I think NetBSD runs on it--I believe it's the slowest machine supported by any of their architectures. -- David Evans dfevans@bbcr.uwaterloo.ca Research Associate http://bbcr.uwaterloo.ca/~dfevans/ Computer Laboratory, University of Cambridge ------------------------------ Date: 2 Mar 2007 06:34:11 -0800 From: davidc@montagar.com Subject: Re: Wanted: MicroVAX I / VAXstation I owners Message-ID: <1172846051.292300.26320@v33g2000cwv.googlegroups.com> On Mar 2, 5:18 am, dfev...@bcr10.uwaterloo.ca (David Evans) wrote: > In article <1172833456.664174.120...@8g2000cwh.googlegroups.com>, > > vaxorcist wrote: > >Who else has got (and eventually runs) the worlds slowest VAX ever ??? > > >I'm going to build one from parts and will probably need some help. > >All OSes welcome! > > I think NetBSD runs on it--I believe it's the slowest machine > supported by any of their architectures. I had one once... I had to gently tease VMSKITBLD on a VAX 3100 to create a set of 5-1/4" floppies I could use to install OpenVMS on the thing (V5.5, I think). I think it took over 35 floppies. Good times... ------------------------------ End of INFO-VAX 2007.122 ************************