INFO-VAX Wed, 17 Jan 2007 Volume 2007 : Issue 34 Contents: Re: "no such file" from one node only Re: "no such file" from one node only Re: "no such file" from one node only AB379A FC Card on VMS Re: AB379A FC Card on VMS Re: AB379A FC Card on VMS Re: BACKUP causing alpha node to crash Re: BACKUP causing alpha node to crash Re: BACKUP causing alpha node to crash Re: BACKUP causing alpha node to crash Re: BACKUP causing alpha node to crash Re: BACKUP causing alpha node to crash Re: Diskmizer 2.1 License ES40 emulator source code available for download Re: Hello- ITRC? Anybody home? Nonstop UNIX takes another loss Re: Nonstop UNIX takes another loss Re: Nonstop UNIX takes another loss ---------------------------------------------------------------------- Date: 17 Jan 2007 07:29:39 -0600 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: "no such file" from one node only Message-ID: In article , norm.raphael@metso.com writes: > > One Node may have a cached view of the directory file from prior to > the corruption, while the other has/had to go the disk and read. > VMSclusters are designed to prevent that from happening. Of course, there is an assumption about properly operating hardware. ------------------------------ Date: 17 Jan 2007 05:31:11 -0800 From: "AEF" Subject: Re: "no such file" from one node only Message-ID: <1169040671.317292.19580@s34g2000cwa.googlegroups.com> BIO wrote: > All: (sorry about my sluggish reply, but my connection to Google groups > kept timing out on posting; so now that I'm at home it works ok again!) > > First - Hein: > I spoke too soon about the directory error. As it turns out it seems > that every file on every disk in every directory on the entire system > (well, those few that I sampled anyway) is showing this symptom. I'm > not sure what that means (incorrect dismount/mount maybe??), but I DO > know that it's NOT causing us any kind of problem whatsoever for any of > all those others. So I am reluctant to try anything to fix a possibly > more global problem. > > So I'm now thinking that recreating the directory won't eliminate the > %DUMP-E-JUNKINDIR error, and I should just delete the two files in > question, and move on. *Every* file? How will deleting two files fix anything then? > > As for your subsequent suggestions - too late for me to experiment now; > don't have infinite time to do the very best job possible. > > Second - Norm: > What do you mean by "is not two separate files"? There are (or should > be) two files (with two different file_id's), but one of them is not > accessible from one node (only). > > I did try the set volume/rebuild=force (on both nodes) and it had no > effect at all. > > Third - Alan: > Yes there are some disk errors (3) but none of those are recent. > The device info does not look unusual to me: > Disk $1$DKD306: (A.....), device type ........ HSZ70, is online, > mounted, file- > oriented device, shareable, available to cluster, error logging is > enabled. > > Error count 3 Operations completed [...] > > and $ anal/disk dkd306 shows nothing > Analyze/Disk_Structure for _$1$DKD306: started on 16-JAN-2007 > 16:04:15.86 This was run on the bad node. Right? > > %ANALDISK-I-OPENQUOTA, error opening QUOTA.SYS > -SYSTEM-W-NOSUCHFILE, no such file > $ > > Resolution? > I finally just plain deleted the file (on the node that could see it) > and the directory listings looked "clean" from both nodes. > > I then manually created a new file with the same name (from node G, the > one that appeared ok). But AAARRGGHH, it, too, was visible from G but > not from A!! Exactly the same symptom as before. So I created a file > with a different name -> no problems on either node. This suggests that > there is some issue with the directory itself at the specific location > of this filename. Then I did the creation from node A. Lo and behold, > it was visible from both nodes! Deleted it again. So I am now able to > create, see and delete files with this name from either node. Somehow > doing the creation/deletion from node A managed to make the directory > repair itself. I'm happy that it works, but still mightily puzzled. > > Ingemar I experienced a problem very much like this back in the late 80's as a neophyte VMS user. A directory listing would work fine on one node for a certain directory, but from another node the same exact directory listing would consistently crap out when it got to files starting with S or somewhere in the middle of files starting with S. I went to the node that worked, created a new directory, RENAMEd all the files from the old to the new directory, deleted the old directory, and renamed to new directory to the same name as the old. Then later (IIRC -- my memory is a little fuzzy on this) it happened again! (Maybe the old directory name was cached on the bad node? [!]) We never did get to the bottom of it. (We never had a professional system manager -- one of our research guys was also our system manager, with one of the profs and one of the postdocs helping out with SYSMGR duties. I'm talking about 1985-1991 here.) Another time I recall our VAX11/750 getting incredibly slow (this was when it was the only VAX we had). Not hung, but really, really slow. MONITOR PROC/TOPC showed processes getting plenty of CPU cycles, but it was as if only one percent or so (five percent? It's been a LONG time) of the CPU cycles did anything useful with the remaining somehow accomplishing nothing. A reboot fixed it and it never happened again. AEF [...] ------------------------------ Date: Wed, 17 Jan 2007 09:52:56 -0500 From: norm.raphael@metso.com Subject: Re: "no such file" from one node only Message-ID: koehler@eisner.nospam.encompasserve.org (Bob Koehler) wrote on 01/17/2007 08:29:39 AM: > In article 006B08DD@metso.com>, norm.raphael@metso.com writes: > > > > One Node may have a cached view of the directory file from prior to > > the corruption, while the other has/had to go the disk and read. > > > > VMSclusters are designed to prevent that from happening. Of course, > there is an assumption about properly operating hardware. > Agreed, and agreed. In any case, his further postings indicate the problem was somewhat different that the case to which I was responding, and we have seen times when resyncing the extent cache cured an out-of- diskspace, cannot-create-file error from a node in the cluster. Even now, from time to time, a process that takes, say, 20 minutes and writes a file, will take two hours and some minutes to write the same file, according to the DIRECTORY/DATE=MODIFED date on the file, but the batch log will show the same CPU time as prior logs. The next cycle time the process is run, the time returns to the expected 20 minutes or so. I have never been able to repeat this of devine an explanation. ------------------------------ Date: 17 Jan 2007 09:25:08 -0800 From: etmsreec@yahoo.co.uk Subject: AB379A FC Card on VMS Message-ID: <1169054707.081747.13020@11g2000cwr.googlegroups.com> Hiya, The documentation doesn't make it clear whether the AB379A PCI-X 2.0 2port 4Gb FC card is switched fabric only or whether it will do FC-AL. VMS (I guess) needs switched fabric, but is the card likely to be in some other state when it's new? If the answer is it may be in FC-AL mode, how do I change it to switched fabric please? thanks in advance Steve ------------------------------ Date: Wed, 17 Jan 2007 09:21:02 -0800 From: "Tom Linden" Subject: Re: AB379A FC Card on VMS Message-ID: On Wed, 17 Jan 2007 09:25:08 -0800, wrote: > Hiya, > > The documentation doesn't make it clear whether the AB379A PCI-X 2.0 > 2port 4Gb FC card is switched fabric only or whether it will do FC-AL. > VMS (I guess) needs switched fabric, but is the card likely to be in > some other state when it's new? > > If the answer is it may be in FC-AL mode, how do I change it to > switched fabric please? I suspect you need to run wwidmgr from the console. > > thanks in advance > > Steve > -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ------------------------------ Date: 17 Jan 2007 10:22:28 -0800 From: etmsreec@yahoo.co.uk Subject: Re: AB379A FC Card on VMS Message-ID: <1169058148.279959.131840@51g2000cwl.googlegroups.com> It's in an Integrity server, so there isn't a console. :o( Steve Tom Linden wrote: > On Wed, 17 Jan 2007 09:25:08 -0800, wrote: > > > Hiya, > > > > The documentation doesn't make it clear whether the AB379A PCI-X 2.0 > > 2port 4Gb FC card is switched fabric only or whether it will do FC-AL. > > VMS (I guess) needs switched fabric, but is the card likely to be in > > some other state when it's new? > > > > If the answer is it may be in FC-AL mode, how do I change it to > > switched fabric please? > > I suspect you need to run wwidmgr from the console. > > > > > thanks in advance > > > > Steve > > > > > > -- > Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ------------------------------ Date: Wed, 17 Jan 2007 05:39:23 -0500 From: JF Mezei Subject: Re: BACKUP causing alpha node to crash Message-ID: <45adfd2f$0$8780$c3e8da3@news.astraweb.com> Peter 'EPLAN' LANGSTOEGER wrote: > VMS83A_ADDENDUM V2.0 is already replaced too. Thanks for the warning. I am really not up to speed with the not-so-obvious nomenclature and hiearchy of patch names. They really should begin with a sequential number indicating the overall order in which they were issued, followed by whatever text they want. Right now, there is no way to know that VMS83A_UPDATE-V0100 was issued after VMS83A_ADDENDUM-V0200 just by looking at the names. If reading the master ECO text is a requirement, perhaps they should add a file that is automatically displayed when one CDs into that directory. ------------------------------ Date: Wed, 17 Jan 2007 11:16:59 GMT From: John Santos Subject: Re: BACKUP causing alpha node to crash Message-ID: JF Mezei wrote: > Peter 'EPLAN' LANGSTOEGER wrote: > >> VMS83A_ADDENDUM V2.0 is already replaced too. > > > Thanks for the warning. I am really not up to speed with the > not-so-obvious nomenclature and hiearchy of patch names. They really > should begin with a sequential number indicating the overall order in > which they were issued, followed by whatever text they want. > > Right now, there is no way to know that VMS83A_UPDATE-V0100 was issued > after VMS83A_ADDENDUM-V0200 just by looking at the names. If reading > the master ECO text is a requirement, perhaps they should add a file > that is automatically displayed when one CDs into that directory. Usually the dates on the files are accurate, and and using the magic unix command "dir -rlt" lists the files in date order (newest last), so you can see what's new, but every once in a while some dope does something to *all* the files, changing the dates to be exactly the same. In a year or so, everything will have aged nicely, and the dates will again be useful, until the next fat-fingered dolt strikes. (Do I sound ticked off? What's the point of having dates on files if you're going to randomly change them?) -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 ------------------------------ Date: Wed, 17 Jan 2007 13:33:59 GMT From: rdeininger@mindspringdot.com (Robert Deininger) Subject: Re: BACKUP causing alpha node to crash Message-ID: In article <45adfd2f$0$8780$c3e8da3@news.astraweb.com>, JF Mezei wrote: >Peter 'EPLAN' LANGSTOEGER wrote: >> VMS83A_ADDENDUM V2.0 is already replaced too. > >Thanks for the warning. I am really not up to speed with the not-so-obvious >nomenclature and hiearchy of patch names. They really should begin with a >sequential number indicating the overall order in which they were issued, >followed by whatever text they want. If you read the friendly documentation for PCSI, you'll find that the fields in the name are somewhat rigidly defined. The only way to make the kits "sequential" as you suggest would be to give all the patch kits for a release the same name, and just increment the version field. VMS83A_PATCH-V0100, VMS83A_PATCH-V0200, etc. I don't think many people would find that naming scheme an improvement. >Right now, there is no way to know that VMS83A_UPDATE-V0100 was issued >after VMS83A_ADDENDUM-V0200 just by looking at the names. That's what the release notes are for. You don't really want the whole release notes encoded into the patch name, do you? >If reading the >master ECO text is a requirement, perhaps they should add a file that is >automatically displayed when one CDs into that directory. Dunno what you mean by "master ECO text". You should definitely consider the release notes required reading before you install a patch. Naming conventions for VMS patches have evolved a bit over the years, but here are some guidelines... 1. When patches have the same name (e.g. V83A_ADDENDUM), the one with the highest version supersedes all the others. The content is cumulative. You would rarely, if ever, need to install V0100 and V0200. If V0200 is shipping, V0100 is redundant. 2. Many patch names are picked to show the main area of functionality. BACKUP, LAN, RMS, etc. follow this pattern. 3. SYS kits are usually something to do with the OS kernel. More precisely, they usually contain stuff from the [SYS...] facility within the VMS build. Functionally, they can affect almost anything. My advice is to ALWAYS read the release notes for any new SYS kit that comes out. 4. UPDATE kits have been used for quite a few releases now. Generally, there is NO new content in UPDATE kits; they are just bundles of existing patches. UPDATE kits are made specifically to reduce the work of installing individual patches. Generally all customers should install UPDATE kits. UPDATE kits will usually be prequisites for most patch kits that come later. UPDATE kits usually get an extended test cycle, so when they are issued there may be a few very recent individual patches that are NOT included in the UPDATE. 5. I think ADDENDUM kits are a recent (V8.3?) addition to the lineup. These are basically "stuff that didn't make it in time for the release", or "stuff that didn't make it in time for the previous ADDENDUM kit". Alas, occasionally there is "stuff to fix stuff in the previous ADDENDUM kit". The recent VMS Integrity releases have all included new functionality that's difficult to deliver in patch kits. Often this is support for new systems, which are coming faster than the traditional Alphaserver pace. Sometimes the new functionality is deeply-buried changes in the kernel. This new functionality often comes with its own schedule, not related to VMS and not under the control of VMS engineering. And this is often high-priority functionality, mainly customers clamoring for support for new system families. At the same time, VMS engineering has finite capacity. The comfort level is somewhere between 1 and 2 VMS releases in the pipeline at once. And customers have been saying VMS releases should be a bit farther apart; anything less than about 18 months seems to be too often. Taken together, these considerations mean that VMS releases have recently had, and will likely continue to have, randomly-changing, hardware-driven, must-ship dates. New functionality that isn't quite ready will tend to be ejected from the main release and moved into something like an ADDENDUM kit. Alternatives would be shipping stuff that's not ready (which unfortunately sometimes happens by accident), or holding back the ADDENDUM stuff until the next release. There are good arguments for rejecting both of these alternatives. Feedback about VMS policies for patch kits and releases can always be sent to VMS management. (I would not expect them to wade though the noise here in c.o.v. and notice feedback and suggestions.) Feedback about the ITRC patch delivery process should go to ITRC. There's no harm in copying the VMS patch release folks for relevant topics. I hope some of this information is useful to somebody. ------------------------------ Date: Wed, 17 Jan 2007 14:49:31 GMT From: rdeininger@mindspringdot.com (Robert Deininger) Subject: Re: BACKUP causing alpha node to crash Message-ID: In article <45ae2b17$0$9523$c3e8da3@news.astraweb.com>, JF Mezei wrote: >Robert Deininger wrote: >> fields in the name are somewhat rigidly defined. The only way to make the >> kits "sequential" as you suggest would be to give all the patch kits for a >> release the same name, and just increment the version field. >> VMS83A_PATCH-V0100, VMS83A_PATCH-V0200, etc. > >I am not concerned about the actual PCSI file name. I am concerned about >the file names as listed in the FTP web site (the .ZIPEXE) those could have >a more "sorted" nomemclature > >for instance, kit VMS083A-PATCH_0100 could be ZIPPED into >005_VMS083A-PATCH_0100.ZIPEXE and .txt > >So a directory listing on the FTP site could look like: > >FTP> ls >200 PORT command successful. >150 Opening ASCII mode data connection for file list. > >000_ALPHA_V83A_MASTER_ECO_LIST.ZIPEXE >000_ALPHA_V83A_MASTER_ECO_LIST.txt >001_VMS83A_RMS-V0100.ZIPEXE >001_VMS83A_RMS-V0100.txt >002_VMS83A_ADDENDUM-V0200.ZIPEXE >002_VMS83A_ADDENDUM-V0200.txt >003_VMS83A_SECSRV-V0100.ZIPEXE >003_VMS83A_SECSRV-V0100.txt >004_AXP_DNVOSIECO01-V83.ZIP >004_AXP_DNVOSIECO01-V83.txt >005_VMS83A_UPDATE-V0100.ZIPEXE >005_VMS83A_UPDATE-V0100.txt > >This way, you would know that 006 is the latest kit, no matter what date is > show by the FTP server. And you would see a clear order that the patches >of various names (UPDATE, ADDENDUM etc) were released. Interesting idea. What would the sequence numbers represent? The order in which the kits are frozen, built, and submitted for testing? Or the order in which they are released to ITRC? Those are not the same. I'm having trouble seeing how this sequence number is useful in terms of the content of the kits. Nothing about the design, kitting, or testing of these kits serializes them in most cases. What good is the number? If VMS engineering is aware of dependencies, they are expressed in the PCSI rules. Usually there are no dependencies. >(sorry, i did not sort the kits in the example, I merely added numeric >sequences to them just to show) > >Right now, this is truly not clear. Why does it matter? ------------------------------ Date: Wed, 17 Jan 2007 12:58:55 -0500 From: norm.raphael@metso.com Subject: Re: BACKUP causing alpha node to crash Message-ID: rdeininger@mindspringdot.com (Robert Deininger) wrote on 01/17/2007 09:49:31 AM: > In article <45ae2b17$0$9523$c3e8da3@news.astraweb.com>, JF Mezei > wrote: > > >Robert Deininger wrote: > >> fields in the name are somewhat rigidly defined. The only way to make the > >> kits "sequential" as you suggest would be to give all the patch kits for a > >> release the same name, and just increment the version field. > >> VMS83A_PATCH-V0100, VMS83A_PATCH-V0200, etc. > > > >I am not concerned about the actual PCSI file name. I am concerned about > >the file names as listed in the FTP web site (the .ZIPEXE) those could have > >a more "sorted" nomemclature > > > >for instance, kit VMS083A-PATCH_0100 could be ZIPPED into > >005_VMS083A-PATCH_0100.ZIPEXE and .txt > > > >So a directory listing on the FTP site could look like: > > > >FTP> ls > >200 PORT command successful. > >150 Opening ASCII mode data connection for file list. > > > >000_ALPHA_V83A_MASTER_ECO_LIST.ZIPEXE > >000_ALPHA_V83A_MASTER_ECO_LIST.txt > >001_VMS83A_RMS-V0100.ZIPEXE > >001_VMS83A_RMS-V0100.txt > >002_VMS83A_ADDENDUM-V0200.ZIPEXE > >002_VMS83A_ADDENDUM-V0200.txt > >003_VMS83A_SECSRV-V0100.ZIPEXE > >003_VMS83A_SECSRV-V0100.txt > >004_AXP_DNVOSIECO01-V83.ZIP > >004_AXP_DNVOSIECO01-V83.txt > >005_VMS83A_UPDATE-V0100.ZIPEXE > >005_VMS83A_UPDATE-V0100.txt > > > >This way, you would know that 006 is the latest kit, no matter what date is > > show by the FTP server. And you would see a clear order that the patches > >of various names (UPDATE, ADDENDUM etc) were released. > > Interesting idea. What would the sequence numbers represent? The order > in which the kits are frozen, built, and submitted for testing? Or the > order in which they are released to ITRC? Those are not the same. > > I'm having trouble seeing how this sequence number is useful in terms of > the content of the kits. Nothing about the design, kitting, or testing of > these kits serializes them in most cases. What good is the number? > > If VMS engineering is aware of dependencies, they are expressed in the > PCSI rules. Usually there are no dependencies. > > >(sorry, i did not sort the kits in the example, I merely added numeric > >sequences to them just to show) > > > >Right now, this is truly not clear. > > Why does it matter? I have found that any significant numbering system is destined to break over time. As you say, what is significant is open to debate. In this case only raw serialization at time of release would be non-significant and I for one would not want that. ------------------------------ Date: Wed, 17 Jan 2007 13:03:23 -0500 From: norm.raphael@metso.com Subject: Re: BACKUP causing alpha node to crash Message-ID: rdeininger@mindspringdot.com (Robert Deininger) wrote on 01/17/2007 08:33:59 AM: > In article <45adfd2f$0$8780$c3e8da3@news.astraweb.com>, JF Mezei > wrote: > > >Peter 'EPLAN' LANGSTOEGER wrote: > >> VMS83A_ADDENDUM V2.0 is already replaced too. > > > >Thanks for the warning. I am really not up to speed with the not-so-obvious > >nomenclature and hiearchy of patch names. They really should begin with a > >sequential number indicating the overall order in which they were issued, > >followed by whatever text they want. > > If you read the friendly documentation for PCSI, you'll find that the > fields in the name are somewhat rigidly defined. The only way to make the > kits "sequential" as you suggest would be to give all the patch kits for a > release the same name, and just increment the version field. > VMS83A_PATCH-V0100, VMS83A_PATCH-V0200, etc. > > I don't think many people would find that naming scheme an improvement. > > >Right now, there is no way to know that VMS83A_UPDATE-V0100 was issued > >after VMS83A_ADDENDUM-V0200 just by looking at the names. > > That's what the release notes are for. You don't really want the whole > release notes encoded into the patch name, do you? > > >If reading the > >master ECO text is a requirement, perhaps they should add a file that is > >automatically displayed when one CDs into that directory. > > Dunno what you mean by "master ECO text". > > You should definitely consider the release notes required reading before > you install a patch. > > Naming conventions for VMS patches have evolved a bit over the years, but > here are some guidelines... > > 1. When patches have the same name (e.g. V83A_ADDENDUM), the one with the > highest version supersedes all the others. The content is cumulative. > You would rarely, if ever, need to install V0100 and V0200. If V0200 is > shipping, V0100 is redundant. > > 2. Many patch names are picked to show the main area of functionality. > BACKUP, LAN, RMS, etc. follow this pattern. > > 3. SYS kits are usually something to do with the OS kernel. More > precisely, they usually contain stuff from the [SYS...] facility within > the VMS build. Functionally, they can affect almost anything. My advice > is to ALWAYS read the release notes for any new SYS kit that comes out. > > 4. UPDATE kits have been used for quite a few releases now. Generally, > there is NO new content in UPDATE kits; they are just bundles of existing > patches. UPDATE kits are made specifically to reduce the work of > installing individual patches. > > Generally all customers should install UPDATE kits. UPDATE kits will > usually be prequisites for most patch kits that come later. > > UPDATE kits usually get an extended test cycle, so when they are issued > there may be a few very recent individual patches that are NOT included in > the UPDATE. > My quibble with UPDATE ECO's is that they become prerequisites, so they must be installed even if one has previously installed each component ECO as it was released. I think there ought to be a way to run the UPDATE ECO that skips those component patches already in place and marks the database that UPDATE Vxxxx has been applied, and/or just the marking if the system manager determines that all ECO's in it that are needed on that instance have been applied (This is because sometimes ECO's that are not mandatory are included in UPDATE ECO's - which seems counter-intuitive). > 5. I think ADDENDUM kits are a recent (V8.3?) addition to the lineup. > These are basically "stuff that didn't make it in time for the release", > or "stuff that didn't make it in time for the previous ADDENDUM kit". > Alas, occasionally there is "stuff to fix stuff in the previous ADDENDUM > kit". > > > The recent VMS Integrity releases have all included new functionality > that's difficult to deliver in patch kits. Often this is support for new > systems, which are coming faster than the traditional Alphaserver pace. > Sometimes the new functionality is deeply-buried changes in the kernel. > > This new functionality often comes with its own schedule, not related to > VMS and not under the control of VMS engineering. And this is often > high-priority functionality, mainly customers clamoring for support for > new system families. > > At the same time, VMS engineering has finite capacity. The comfort level > is somewhere between 1 and 2 VMS releases in the pipeline at once. And > customers have been saying VMS releases should be a bit farther apart; > anything less than about 18 months seems to be too often. > > Taken together, these considerations mean that VMS releases have recently > had, and will likely continue to have, randomly-changing, hardware-driven, > must-ship dates. New functionality that isn't quite ready will tend to be > ejected from the main release and moved into something like an ADDENDUM > kit. > > Alternatives would be shipping stuff that's not ready (which unfortunately > sometimes happens by accident), or holding back the ADDENDUM stuff until > the next release. There are good arguments for rejecting both of these > alternatives. > > > Feedback about VMS policies for patch kits and releases can always be sent > to VMS management. (I would not expect them to wade though the noise here > in c.o.v. and notice feedback and suggestions.) > > Feedback about the ITRC patch delivery process should go to ITRC. There's > no harm in copying the VMS patch release folks for relevant topics. > > I hope some of this information is useful to somebody. ------------------------------ Date: Wed, 17 Jan 2007 11:31:44 -0500 From: "John E. Malmberg" Subject: Re: Diskmizer 2.1 License Message-ID: bclaremont wrote: > Hi, > > Anyone know where I might lay hands on a Diskmizer 2.1 license good for > 50 units? I have the product installed on a MicroVAX II/GPX running > VMS 5.5. I upgraded the CPU and memory to a straight MicroVAX II, > which had the unfortunate side effect of changing the Diskmizer license > requirements from 10 Type F units to 50. IIRC, there were only two variants of the MicroVAX II processor for the QBUS. One was a restricted configuration that ran VAXeln, but not VAX/VMS, and the other the normal one. So what module numbers did you replace with what? The amount of memory is only limited by the number of slots available in the backplane, and the /GPX used the same memory as the straight system. So such a CPU/MEMORY change should not have had any affect on the LURT table. What would have affected the LURT table is if the graphics hardware was removed or disabled as a side effect of the "upgrade". The other side effect of the LURT change is that you need a different base license for OpenVMS and the other products. Is there a specific reason that the graphics hardware was removed? Due to a change in Digital/Compaq/HP policy, multiple user licenses were made available for the VAXstation and VAXServer lines. I am not aware of the current status of sales of those licenses. See the OpenVMS faq available at http://www.hp.com/go/openvms and other locations like http://www.hoffmanlabs.org . -John wb8tyw@qsl.network Personal Opinion Only -- Need a senior system engineer? I am looking for employment. http://encompasserve.org/~malmberg/MALMBERG_CS1_RESUME.TXT ------------------------------ Date: 17 Jan 2007 09:17:50 -0800 From: "Camiel" Subject: ES40 emulator source code available for download Message-ID: <1169054270.652536.319860@m58g2000cwm.googlegroups.com> Hello Everyone, I've stopped development of the ES40 emulator for now, due to lack of time. Therefore, I've decided to put the source-code up for download at http://www.camicom.com/es40, so anyone interested can pick it up and see if they can make it work. If anyone does make it work, I'd appreciate it if you let me know! Camiel. ------------------------------ Date: Wed, 17 Jan 2007 09:40:45 -0500 From: norm.raphael@metso.com Subject: Re: Hello- ITRC? Anybody home? Message-ID: DeanW wrote on 01/16/2007 04:10:03 PM: > I prefer to download patch kits directly to the machine that needs > them whenever possible. Partly this is to reduce the chances of the > bits getting munged up on the wire, partly to avoid chances of the > bits getting munged up on a non-VMS machine, and partly to make most > efficient use of resources (bandwidth and my time). > > ITRC has an option to download a script that will then download your > files. I thought that would be cool. And it would, if it ran on VMS > (the platform for which I'm downloading patches.) But it's a *nix-y > shell script. Little good *that* does me. > FWIW, I just use COPY/FTP onto my OpenVMS systems, like: $COPY/FTP/ascii/verbose/nostruvms - FTP.ITRC.HP.COM"anonymous -"::- "/openvms_patches/alpha/V7.3-2/ALPHA_V732_MASTER_ECO_LIST.txt" - ALPHA_V732_MASTER_ECO_LIST_DEC21_06.txt > So, I'm using CSWB to yank 'em down to my local hobbyist box, then > I'll decnet-over-IP them to the box they're going to. > > FWIW, Verizon's FiOS service with fiber optic cable to the demarc does > not suck. ;) > > -- > Dean Woodward =o&o > dean.woodward@gmail.com ------------------------------ Date: 17 Jan 2007 05:58:05 -0800 From: "n.rieck@sympatico.ca" Subject: Nonstop UNIX takes another loss Message-ID: <1169042285.377185.315540@51g2000cwl.googlegroups.com> Nonstop UNIX takes another loss as the Toronto stock exchange moves to LINUX on AMD Opteron or Intel Xeon http://www.itbusiness.ca/it/client/en/home/News.asp?id=41862 Neil Rieck Waterloo, Ontario, Canada. ------------------------------ Date: Wed, 17 Jan 2007 14:53:37 GMT From: rdeininger@mindspringdot.com (Robert Deininger) Subject: Re: Nonstop UNIX takes another loss Message-ID: In article <1169042285.377185.315540@51g2000cwl.googlegroups.com>, "n.rieck@sympatico.ca" wrote: >Nonstop UNIX takes another loss as the Toronto stock exchange moves to >LINUX on AMD Opteron or Intel Xeon > >http://www.itbusiness.ca/it/client/en/home/News.asp?id=41862 I wonder what they mean by "HP NonStop Unix". That name isn't familiar to me. ------------------------------ Date: Wed, 17 Jan 2007 09:23:50 -0800 From: "Tom Linden" Subject: Re: Nonstop UNIX takes another loss Message-ID: On Wed, 17 Jan 2007 06:53:37 -0800, Robert Deininger = wrote: > In article <1169042285.377185.315540@51g2000cwl.googlegroups.com>, > "n.rieck@sympatico.ca" wrote: > >> Nonstop UNIX takes another loss as the Toronto stock exchange moves t= o >> LINUX on AMD Opteron or Intel Xeon >> >> http://www.itbusiness.ca/it/client/en/home/News.asp?id=3D41862 > > I wonder what they mean by "HP NonStop Unix". That name isn't familia= r = > to me. Maybe there was a Posix shell on Nonstop, aka, Guardian -- = Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ------------------------------ End of INFO-VAX 2007.034 ************************