1 INFO-VAX	Sat, 23 Apr 2005	Volume 2005 : Issue 225       Contents:3 CDE under DECwindows: customization, documentation? 7 Re: CDE under DECwindows: customization, documentation? > Re: changing node name: RENAME/IDENTIFIER SYS$NODE_oldnodename> Re: changing node name: RENAME/IDENTIFIER SYS$NODE_oldnodename Re: Could a PC do this?  Re: Could a PC do this?  Re: Could a PC do this?  Re: Could a PC do this?  Re: Could a PC do this?  Re: Could a PC do this?  Re: Could a PC do this?  Re: Could a PC do this?  Re: Distribution Media Re: Distribution Media3 HP and IntelR Developer Workshops Update / Reminder  Re: Login mystery  Re: Login mystery  Re: Question about HBMM  Re: Question about HBMM N Re: selecting the preferred merge host (was: Re: two questions about MINICOPY)P Re: selecting the preferred merge host (was: Re: two questions about MINICOPY) M  Re: two questions about MINICOPY  Re: two questions about MINICOPY  Re: two questions about MINICOPYP Re: VMS FAQ: changing volume label of system disk: DECnet MOP or LANCP LANCPLANC  F ----------------------------------------------------------------------  % Date: Fri, 22 Apr 2005 12:07:03 -0700 , From: Ken Fairfield <my.full.name@intel.com>< Subject: CDE under DECwindows: customization, documentation?+ Message-ID: <d4bi0n$f9e$1@news01.intel.com>   I      Over the years, I got pretty facile at customizing the "traditional" F DECwindows/Motif Session Manager, including both "public" system wide,D and private-to-me, changes and additions to various menus, etc.  DECE had published a slim book about customizing Motif and that was enough # to point me in the right direction.   C      I'd like to do the same now under CDE but feel like I'm flying / blind.  For example, in another thread I asked:   D      "... do you, or does anyone, know how to add custom backgroundsF       to CDE?  Where do they live and what format are they (jpeg, bpm,       gif, etc.)?"  B Can anyone provide an answer to that question?  Can aynone suggest? a good starting point to learn about custom CDE (as implemented  under DECwindows)?   	Thanks, Ken --  6 I don't speak for Intel, Intel doesn't speak for me...  
 Ken Fairfield ! D1C Automation VMS System Support " who:   kenneth dot h dot fairfield where: intel dot com   ------------------------------  % Date: Fri, 22 Apr 2005 23:01:41 +0100 # From: issinoho <issinoho@gmail.com> @ Subject: Re: CDE under DECwindows: customization, documentation?5 Message-ID: <1114207221.48435.0@demeter.uk.clara.net>    Ken Fairfield wrote:J >     Over the years, I got pretty facile at customizing the "traditional"H > DECwindows/Motif Session Manager, including both "public" system wide,F > and private-to-me, changes and additions to various menus, etc.  DECG > had published a slim book about customizing Motif and that was enough % > to point me in the right direction.  > D >     I'd like to do the same now under CDE but feel like I'm flying1 > blind.  For example, in another thread I asked:  > E >     "... do you, or does anyone, know how to add custom backgrounds G >      to CDE?  Where do they live and what format are they (jpeg, bpm,  >      gif, etc.)?"  > D > Can anyone provide an answer to that question?  Can aynone suggestA > a good starting point to learn about custom CDE (as implemented  > under DECwindows)? >  >     Thanks, Ken   ? I can't help but agree, it's an incredibly hostile environment. E And why, please someone explain, is it still referred to as the "New  D Desktop Environment" a full 10 years after it first appeared and is . probably the only OS that still ships with it.F It's no wonder we're considered a legagcy OS: where is KDE, Gnome, or # GOD FORBID a newer proprietary GUI.    ------------------------------  % Date: Fri, 22 Apr 2005 13:58:36 -0500 / From: Chris Scheers <chris@applied-synergy.com> G Subject: Re: changing node name: RENAME/IDENTIFIER SYS$NODE_oldnodename 2 Message-ID: <4269495C.2000808@applied-synergy.com>  / Phillip Helbig---remove CLOTHES to reply wrote:  > F > Which reminds me: is the limit on the size of the system disk for a K > VAXstation 3100 only applicable if it is a boot server, i.e. is it OK to  I > network boot a VAXstation 3100 satellite off of a 2-GB VAX system disk   > on a boot-server node?  G The 1GB restriction only applies to disk access by the ROM drivers, so  4 it only applies to a directly connected system disk.  : Remote disks are accessed by the remote machine's drivers.  H Local data disks are accessed by the local machine's VMS drivers, which 6 don't have the 1GB restriction (at least after 5.3-1).   --  G ----------------------------------------------------------------------- $ Chris Scheers, Applied Synergy, Inc.  B Voice: 817-237-3360            Internet: chris@applied-synergy.com    Fax: 817-237-3074   ------------------------------  # Date: Fri, 22 Apr 2005 22:59:07 GMT   From: John Santos <john@egh.com>G Subject: Re: changing node name: RENAME/IDENTIFIER SYS$NODE_oldnodename ' Message-ID: <%kfae.184$Nc.104@trnddc08>   / Phillip Helbig---remove CLOTHES to reply wrote: I > In article <9hV9e.4350$Lj3.1192@news.cpqcorp.net>, hoff@hp.nospam (Hoff  > Hoffman) writes:   >  > J >>  No shared SCSI support on VAX.  DSSI was the option for various of the= >>  low-end VAX boxes, where a DSSI controller was available.  >  > J > I have a DSSI controller on the VAX 4000/100A, but only on that machine.H > Thus, no possibility to share anything (though I do use a disk on it). > I > Which reminds me: that DSSI disk has a different allocation class than  K > the machine itself (which is used for the SCSI disks).  Everything works  G > fine.  Is there any reason to prefer them to be the same?  To prefer   > them to be different?  > H > Which also reminds me: it also has an adapter so that one can connect H > SCSI disks to the DSSI bus (it also has a completely independent SCSI K > bus as well).  Is there any limit on the size of such SCSI disks one can  J > connect?  This is low on my priority list, but once when testing things H > out I saw some RZ26 and/or RZ28 disks show up with substantially less  > than their real size.  >  > L >>  For a hobbyist cluster, one disk per architecture will usually work justH >>  fine, and it's less maintenance -- and more experience with cluster ; >>  operations and with common cluster configurations, too.  >  > I > For various reasons, my hobbyist cluster is located 500 km from where I G > am most of the time.  At the non-cluster location, I have a couple of G > standalone VAXstation 4000/60 machines connected to a really nice old G > |d|i|g|i|t|a|l| 21-inch monitor.  Essentially, I use them just to run F > DECwindows, so that I can log in remotely elsewhere (usually into myH > hobbyist cluster).  (I also use it as a display for Mozilla running onB > another remote cluster where I have an account, since none of myE > machines are powerful enough to run Mozilla.  A bit slow due to the J > low-end DSL connection, but usable.  LYNX or Netscape 3.03, even on VAX,B > is good enough for many sites.  But I digress.)  Thus, I want myH > hobbyist cluster, which I use for essentially everything I do, to stayH > up no matter what.  Thus, I want to be able to survive the loss of anyJ > node; with non-shared system disks, this means that each node needs its J > own system disk.  Also, when I am on-site doing maintenance etc, I want K > the cluster to be up so that I have internet access etc should I need to  I > consult with some online documentation or whatever.  Also, with just a  I > 10 Mb/s LAN for all the traffic, it's probably more efficient for each  J > node to have a direct SCSI connection to its system disk, as opposed to  > being a satellite.  B Even 10Mb/s is surprisingly fast for lots of stuff.  One key is to> make sure you have an ethernet switch, rather than just a hub.  This can make a huge difference.    H > Since I have just a low-end DSL connection, if there is a failure suchG > that the dynamic-DNS update isn't performed, I can't get in to repair H > anything from outside.  Thus, the batch job which does the DNS update F > has to be rather robust (SUBMIT/RESTART, failover queues etc and of J > course coded to handle failures), and of course the cluster has to stay  > up.  > I > I also have an ISDN router which I can dial in to, and thus access the  D > cluster independent of DSL and even independent of the internet.  J > However, to make use of this I think I will have to add a node (perhaps L > a satellite) or two which have the ISDN router as the default TCPIP route K > so that I can actually log in via the ISDN router and have a functioning  E > connection.  (Once inside, of course, I can use LAT (or Telnet, or  F > DECnet when I finally get it configured) to get to the other nodes.)  C You might want to consider getting a cheap old DECServer (should be B cheap on Ebay), and connecting one port to a dialup modem, and theF rest via null-modems to the console ports of your other systems.  Then@ you could dial in and reboot things, fix network routes, etc. ifC necessary.  The server could offer the various console ports as LAT H services, so you could connect to a dead or down system from any workingF system, using SET HOST/LAT.  (If you have a DS90/DS700 (or later) thatE supports TCP/IP, you could also TELNET in from the outside and do the  same.)   A sort of poor-man's VCC.   B Obviously, you would need to carefully consider security, firewall. access to the DECserver from the outside, etc.  G > Which reminds me: can one have more than one TCPIP cluster alias in a D > VMS cluster, one for three nodes, say, and another for another two: > nodes, and of course have them both work simultaneously? > I > Nevertheless, I plan to use some VAXstation 3100 machines I have (some  K > quite slow, such as the model 30, and/or diskless) as satellites, mainly  I > just to get some experience with cluster operations and common cluster   > configurations.  > F > Which reminds me: is the limit on the size of the system disk for a K > VAXstation 3100 only applicable if it is a boot server, i.e. is it OK to  I > network boot a VAXstation 3100 satellite off of a 2-GB VAX system disk   > on a boot-server node? >      --   John Santos  Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------  % Date: Fri, 22 Apr 2005 20:38:28 +0200 3 From: "Dr. Dweeb" <NOSPAM_5msg0h202@sneakemail.com>   Subject: Re: Could a PC do this?= Message-ID: <426944a1$0$78286$157c6196@dreader1.cybercity.dk>    Stanley F. Quayle wrote:* > On 21 Apr 2005 at 18:03, JF Mezei wrote:G >> Although this might put Stan Quayle out of work, the best bet is for B >> the VMS engineers to hurry up with the port of VMS to the 8086. > G > Not to worry.  I didn't become a CHARON-VAX reseller to sell widgets. G > It's just one of the tools I have available.  I even send some people & > to Island Computer for cheap Alphas. > B > I also do VMS software development and system management.  There. > seems to be lots of opportunities available. > F > Get VMS onto my Palm phone and I'll be a really happy camper.  Right5 > now, I have to settle for my laptop and CHARON-VAX.  >   & So, how about CHARON-ALPHA or similar?F Now that the Alpha is dead and smelly, it seems that this is the next  obvious development.  
 Dr. Dweeb.   > --Stan Quayle  > Quayle Consulting Inc. >  > ----------/ > Stanley F. Quayle, P.E. N8SQ  +1 614-868-1363 5 > 8572 North Spring Ct., Pickerington, OH  43147  USA 3 > stan-at-stanq-dot-com       http://www.stanq.com     ------------------------------  % Date: Fri, 22 Apr 2005 15:56:08 -0400 2 From: "Stanley F. Quayle" <squayle@insight.rr.com>  Subject: Re: Could a PC do this?. Message-ID: <42691E98.7156.2F05890C@localhost>  ) On 22 Apr 2005 at 20:38, Dr. Dweeb wrote: ( > So, how about CHARON-ALPHA or similar?G > Now that the Alpha is dead and smelly, it seems that this is the next  > obvious development.  = Well, you can still buy new Alphas, so it's not as urgent as  ( replacing VAXen.  However, stay tuned...  
 --Stan Quayle  Quayle Consulting Inc.  
 ----------- Stanley F. Quayle, P.E. N8SQ  +1 614-868-1363 3 8572 North Spring Ct., Pickerington, OH  43147  USA 0 stan-at-stanq-dot-com       http://www.stanq.com   ------------------------------   Date: 22 Apr 2005 20:21:09 GMT$ From: "Doc." <doc@openvms-rocks.com>  Subject: Re: Could a PC do this?7 Message-ID: <Xns9640E38DF980Bdcovmsrox@212.100.160.126>   + %NEWS-I-NEWMSG, Stanley F. Quayle wrote in  % news:42691E98.7156.2F05890C@localhost   + > On 22 Apr 2005 at 20:38, Dr. Dweeb wrote: ) >> So, how about CHARON-ALPHA or similar? H >> Now that the Alpha is dead and smelly, it seems that this is the next >> obvious development.  > ? > Well, you can still buy new Alphas, so it's not as urgent as  * > replacing VAXen.  However, stay tuned...  J Isn't there the issue of having a processor with enough "oomph" to run an I emulator and original platform software at an acceptable speed?  The way  L I've seen things posted recently it's a big deal that Charon-VAX can run on L a PC and have better performance than the best VAX ever.  That's now, which 2 is *how* many years after VAX development stopped?     Doc. --  G OpenVMS:     Eight out of ten hackers prefer *other* operating systems. G http://www.openvms-rocks.com    Deathrow Public-Access OpenVMS Cluster.    ------------------------------   Date: 22 Apr 2005 22:26:26 GMT( From: bill@cs.uofs.edu (Bill Gunshannon)  Subject: Re: Could a PC do this?, Message-ID: <3ctc0iF6q9islU1@individual.net>  = In article <426944a1$0$78286$157c6196@dreader1.cybercity.dk>, 6 	"Dr. Dweeb" <NOSPAM_5msg0h202@sneakemail.com> writes: > Stanley F. Quayle wrote:+ >> On 21 Apr 2005 at 18:03, JF Mezei wrote: H >>> Although this might put Stan Quayle out of work, the best bet is forC >>> the VMS engineers to hurry up with the port of VMS to the 8086.  >>H >> Not to worry.  I didn't become a CHARON-VAX reseller to sell widgets.H >> It's just one of the tools I have available.  I even send some people' >> to Island Computer for cheap Alphas.  >>C >> I also do VMS software development and system management.  There / >> seems to be lots of opportunities available.  >>G >> Get VMS onto my Palm phone and I'll be a really happy camper.  Right 6 >> now, I have to settle for my laptop and CHARON-VAX. >> > ( > So, how about CHARON-ALPHA or similar?H > Now that the Alpha is dead and smelly, it seems that this is the next  > obvious development. >   D Nothing has come out yet with enough performance to match, much less emulate the Alpha.   bill   --  J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>       ------------------------------  % Date: Fri, 22 Apr 2005 19:54:59 -0400 2 From: "Stanley F. Quayle" <squayle@insight.rr.com>  Subject: Re: Could a PC do this?/ Message-ID: <42695693.22166.2FE034B9@localhost>   / On 22 Apr 2005 at 22:26, Bill Gunshannon wrote: F > Nothing has come out yet with enough performance to match, much less > emulate the Alpha.  # Not yet.  Give it 10 or 15 years...   
 --Stan Quayle  Quayle Consulting Inc.  
 ----------- Stanley F. Quayle, P.E. N8SQ  +1 614-868-1363 3 8572 North Spring Ct., Pickerington, OH  43147  USA 0 stan-at-stanq-dot-com       http://www.stanq.com   ------------------------------   Date: 23 Apr 2005 01:02:48 GMT( From: bill@cs.uofs.edu (Bill Gunshannon)  Subject: Re: Could a PC do this?, Message-ID: <3ctl5oF6p16qqU1@individual.net>  / In article <42695693.22166.2FE034B9@localhost>, 5 	"Stanley F. Quayle" <squayle@insight.rr.com> writes: 1 > On 22 Apr 2005 at 22:26, Bill Gunshannon wrote: G >> Nothing has come out yet with enough performance to match, much less  >> emulate the Alpha.  > % > Not yet.  Give it 10 or 15 years...  >   C How's that?  5 years for Itanium to die and then 10 more to develop  the new architecture?    bill   --  J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>       ------------------------------  % Date: Fri, 22 Apr 2005 19:52:44 -0700 # From: "Tom Linden" <tom@kednos.com>   Subject: Re: Could a PC do this?( Message-ID: <opspnzl6ylzgicya@hyrrokkin>  F On 23 Apr 2005 01:02:48 GMT, Bill Gunshannon <bill@cs.uofs.edu> wrote:  1 > In article <42695693.22166.2FE034B9@localhost>, 7 > 	"Stanley F. Quayle" <squayle@insight.rr.com> writes: 2 >> On 22 Apr 2005 at 22:26, Bill Gunshannon wrote:H >>> Nothing has come out yet with enough performance to match, much less >>> emulate the Alpha. >>& >> Not yet.  Give it 10 or 15 years... >> > E > How's that?  5 years for Itanium to die and then 10 more to develop  > the new architecture? F Itanium is on life support, I'll give you odds that it will be dropped within a year. >  > bill >    ------------------------------  % Date: Sat, 23 Apr 2005 04:54:58 +0200 + From: Karsten Nyblad <nospam@nospam.nospam>   Subject: Re: Could a PC do this?= Message-ID: <4269b90c$0$78285$157c6196@dreader1.cybercity.dk>    Bill Gunshannon wrote:1 > In article <42695693.22166.2FE034B9@localhost>, 7 > 	"Stanley F. Quayle" <squayle@insight.rr.com> writes:  > 1 >>On 22 Apr 2005 at 22:26, Bill Gunshannon wrote:  >>G >>>Nothing has come out yet with enough performance to match, much less  >>>emulate the Alpha.  >>% >>Not yet.  Give it 10 or 15 years...  >> >  > E > How's that?  5 years for Itanium to die and then 10 more to develop  > the new architecture?  >  > bill >   I 7 years for the Chinese to develop the needed technology and 5 years for   them to design the chip.   ------------------------------  % Date: Fri, 22 Apr 2005 22:20:33 +0200 " From: "Bill" <balings@zfree.co.nz> Subject: Re: Distribution Media < Message-ID: <50399$42696a8f$513b9e33$20899@news.versatel.nl>  < "David Coolbear" <david@thecoolbears.org> schreef in bericht* news:JZOdncg2w5yUzfXfRVn-gw@comcast.com...J > Some time ago I purchased a CD with VMS and, using a hobbyest license, IH > installed VMS under SIMH. I've acquired a VAXStation 3200 and I'd likeE > to get VMS installed on it. The 3200 has a TK50 and an RX50, but no H > CD-ROM drive. HP isn't selling VMS on TK50s, so is there anyway to getA > VMS installed? Can you get a hobbyest license for this machine?  >   D The license is not the problem: Montagar supplies all you need for a hobbyist user./ The easiest way to boot the 3200 is as follows:   - install VMS on a simh emulatorG - there's a question somewhere like this: "is this system a member of a 	 cluster?"    answer YES to that oneG - after the installation is completed, @cluster_config and set up an NI  cluster.H - boot the 3200 across the ethernet, using the appropriate boot root and ethernet device !    (example: >>> B/A0000000 QNA0)    ------------------------------  % Date: Fri, 22 Apr 2005 16:33:19 -0700 - From: David Coolbear <david@thecoolbears.org>  Subject: Re: Distribution Media 0 Message-ID: <TsednV3QyrwiFPTfRVn-rQ@comcast.com>   Dave Froble wrote: > David Coolbear wrote:  > J >> Some time ago I purchased a CD with VMS and, using a hobbyest license, G >> I installed VMS under SIMH. I've acquired a VAXStation 3200 and I'd  I >> like to get VMS installed on it. The 3200 has a TK50 and an RX50, but  I >> no CD-ROM drive. HP isn't selling VMS on TK50s, so is there anyway to  F >> get VMS installed? Can you get a hobbyest license for this machine? >> > B > I've never seen a 3200, but it's a Q-BUS machine as others have J > indicated.  If you can get a SCSI adapter for Q-BUS, then you have some 
 > chances. > 9 > What is the size of the disk(s) you have on the system?  > J > If you have enough storage, then, I could dig, DEEP, and either come up F > with some TK-50 media, or TK-50 tape(s) that I could load with some # > version of VMS distribution data.  > J > I cannot promise that any of the TK50 drives I have will still function. >  > Dave > --  6 > David Froble                       Tel: 724-529-04506 > Dave Froble Enterprises, Inc.      Fax: 724-529-0596@ > DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com > 170 Grimplin Road  > Vanderbilt, PA  15486 H I'm using ESDI drives. I have several to choose from, mostly 160MB, but  also 300 or 600 MB.    ------------------------------  % Date: Fri, 22 Apr 2005 17:11:53 -0400 ' From: "Main, Kerry" <kerry.main@hp.com> < Subject: HP and IntelR Developer Workshops Update / ReminderR Message-ID: <FD827B33AB0D9C4E92EACEEFEE2BA2FB5ECC5D@tayexc19.americas.cpqcorp.net>   All,  C The following info may be of interest to those on this list server:   H http://h21007.www2.hp.com/dspp/bus/bus_BusDetailPage_IDX/1,1252,6045,00. html   [extract from url]  E With the success of last years Itanium Developer series, HP and Intel H have continued their collaboration to bring a complete suite of productsG and services to support developer adoption of the Intel(r) Itanium(r) 2  microarchitecture.=20   0 hardware +plus training =3D exceptional value=20  E Purchase a specially priced rx1620 HP Integrity server for $2,000 and A you receive everything you need to complete the migration of your D products to the performance-leading, industry-standard architecture.H Beyond the HP Integrity server, this package includes training deliveredF by engineers who have provided the foundation of support for developerC adoption of Itanium(r) and share not only the fundamentals, but the ; insider tips on how to smoothly migrate you application.=20   G After three days of interactive lectures and proctored hands-on labs in H HP-UX 11i, Linux (64-bit), OpenVMS, or Windows Server 2003 environments,B you head back to your business with your Itanium-based applicationF porting efforts well underway and an HP Integrity server featuring theC Intel(r) Itanium(r) 2 processor on its way to you ... plus software B development tools and membership in both HP's Developer & Solution3 Partner Program and Intel's Early Access Program=20    2005 Locations   =20& > Tampa, FL    April 26 - 28, 2005 =20- > Washington, DC     July 12 - 14, 2005   =20 + > San Diego, CA   August 23 - 25, 2005  =20 ' > Houston, TX    October 18-20, 2005=20    ------------------------------    Date: 22 Apr 2005 13:33:11 -0500; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler)  Subject: Re: Login mystery3 Message-ID: <r59hisjglhII@eisner.encompasserve.org>   Z In article <d4bd97$crb$1@news01.intel.com>, Ken Fairfield <my.full.name@intel.com> writes: > J >      I still use "MCR SYSMAN", even though I use SYSMAN daily and should& >   have defined a symbol for it. :-}   8    You haven't yet realized MC is a unique abbreviation?   ------------------------------  % Date: Fri, 22 Apr 2005 13:34:06 -0700 , From: Ken Fairfield <my.full.name@intel.com> Subject: Re: Login mystery+ Message-ID: <d4bn42$i2o$1@news01.intel.com>    Bob Koehler wrote:\ > In article <d4bd97$crb$1@news01.intel.com>, Ken Fairfield <my.full.name@intel.com> writes: > J >>     I still use "MCR SYSMAN", even though I use SYSMAN daily and should& >>  have defined a symbol for it. :-}  >  > : >    You haven't yet realized MC is a unique abbreviation?  ?      Where's the smiley, Bob?  Of course.  What I actually type ; is "mc sysman", lowercase and all.  But I'm in the habit of 8 spelling out verbs and/or image names fully when writing? command procedures or in corresponance (with users, etc.).  ;-p    	-Ken  --  6 I don't speak for Intel, Intel doesn't speak for me...  
 Ken Fairfield ! D1C Automation VMS System Support " who:   kenneth dot h dot fairfield where: intel dot com   ------------------------------    Date: 22 Apr 2005 14:04:45 -0500/ From: brooks@cuebid.zko.dec.nospam (Rob Brooks)   Subject: Re: Question about HBMM- Message-ID: <0cUFOZ6kJ$Z1@cuebid.zko.dec.com>   $ dave.baxter@bannerhealth.com writes:  G > When setting up a policy for MiniMerge, the parameter RESET_THRESHOLD G > is used to determine how many modified blocks are recorded before the B > bitmap is "eligible to be cleared" (Quote is from the VMS HELP). > C > My question relates to how the "UP" systems behave regarding this $ > parameter when a system is "DOWN". > F > i.e., if a system crashes, however master bitmaps are being maintainI > for all required volumes on one of the remaining nodes, what do they do A > if RESET_THRESHOLD is reached, and the crashed node has not yet  > returned to the cluster.  F > The thought that they are going to be reset, gives me a bad feeling,3 > but maybe I am not thinking it through correctly.  > ( > I can only think of 2-3 possibilities; > < > 1.  the bitmap is extended until the crashed node returns.? > 2.  the bitmap is discarded and a full merge must take place. B > 3.  I/O to the volume is stopped until the crashed node returns. > G > #2 strikes me a most likely, however I would really like to hear what I > the ACTUAL behaviour is.     I am intrigued by the phrasing of the HELP 9 > text, i.e. the bitmap becomes "eligible" to be cleared. D > Does this mean that it might not be cleared, but extended instead?  1 There appears to be a bit of confusion here . . .   C The bitmap cannot be cleared if the bitmap is being used to perform J a host-based minimerge (hence the wording about "eligible to be cleared").I Also, we don't reset the bitmaps as soon as the threshold is crossed; the F SYSGEN param SHADOW_HBMM_RTC determines how often we check the bitmapsI to see if the threshold is crossed (the default interval is 2.5 minutes). J So, it's quite common to see bitmaps with more than RESET_THRESHOLD blocksF written, if the shadow set is getting a fair amount of write activity.  H When/if a (mini) merge takes place has absolutely nothing to do with the) crashing node returning to the cluster.     L If the crashing node was the only node in cluster that had a specific shadowO set mounted, then an HBMM cannot take place for that specific shadow set, since N no other HBMM bitmaps would have existed in the cluster for that shadow set.  O If the shadow set(s) of interest were mounted on other nodes in addition to the O crashing nodes AND at least one of the other remaining nodes had HBMM bitmap(s) C for the shadow set(s) of interest, then HBMM will work as expected.   L The connection manager component of VMS has a notification mechanism wherebyM interested parties can register their interest in being told of "interesting" I events.  When a shadow set is mounted, the shadowing driver registers its L interest in being told when any node crashes.  When a crash occurs, a threadK of execution for each shadow set mounted checks to see if the crashing node J had the shadow set mounted.  If it did not, then the crash is dismissed asL not interesting.  If the crashing node did have the shadow set mounted, thenL each remaining node that has the shadow set mounted will (eventually) try toK start a merge.  There is rather complicated logic that determines what type 3 of merge (controller-based, HBMM, or full) is done.   H For those of you that subscribe to the source listings, the stuff in the6 [SHADOWING] facility can make for interesting reading!  B Please let me know if I've answered your fears about how we manage the bitmaps related to HBMM!  H Once you get past the byzantine DCL command structure to configure whereK bitmaps are created, I think you'll find that we did a rather comprehensive ! job in making this a useful tool.    --    M Rob Brooks    VMS Engineering -- I/O Exec Group     brooks!cuebid.zko.dec.com    ------------------------------  % Date: Fri, 22 Apr 2005 11:22:34 -0700 , From: Ken Fairfield <my.full.name@intel.com>  Subject: Re: Question about HBMM+ Message-ID: <d4bfdb$e08$1@news01.intel.com>   # dave.baxter@bannerhealth.com wrote: G > When setting up a policy for MiniMerge, the parameter RESET_THRESHOLD G > is used to determine how many modified blocks are recorded before the B > bitmap is "eligible to be cleared" (Quote is from the VMS HELP). > C > My question relates to how the "UP" systems behave regarding this $ > parameter when a system is "DOWN". > F > i.e., if a system crashes, however master bitmaps are being maintainI > for all required volumes on one of the remaining nodes, what do they do A > if RESET_THRESHOLD is reached, and the crashed node has not yet  > returned to the cluster.  D     Ah ha!  You're asking the same question that I had early on. :-)  F > The thought that they are going to be reset, gives me a bad feeling,3 > but maybe I am not thinking it through correctly.  > ( > I can only think of 2-3 possibilities; > < > 1.  the bitmap is extended until the crashed node returns.? > 2.  the bitmap is discarded and a full merge must take place. B > 3.  I/O to the volume is stopped until the crashed node returns. > G > #2 strikes me a most likely, however I would really like to hear what I > the ACTUAL behaviour is.     I am intrigued by the phrasing of the HELP 9 > text, i.e. the bitmap becomes "eligible" to be cleared. D > Does this mean that it might not be cleared, but extended instead?  F      And the correct answer is <drum roll please>:  NONE OF THE ABOVE!  E      There are two points that a careful reading of the docs may have . revealed, but i missed them on the first pass.  C      First, the SIZE of the bitmap is FIXED and depends ONLY on the D size of the disk, with each bit mapping one 127-block "chunk" of the disk.   D      Second, the RESET_THRESHOLD is just monitoring a COUNTER of howE many bits are currently set in the bitmap, i.e., the count of "dirty"  bits.   D      Under normal circumstances, an idle shadowset may not reach theB RESET_THRESHOLD for days or weeks...if ever...and its bitmaps willC not be reset.  SHOW SHADOW/FULL DSAxxx includes a line like this if   the bitmap has never been reset:  /      Modified blocks since bitmap creation: 762   ( or lines like this if it has been reset:  F    HBMM Reset Count      3       Last Reset    22-APR-2005 06:55:29.693      Modified blocks since last bitmap reset: 12319   C For the examples shown, we are using the default RESET_THRESHOLD of @ 50000 on a test cluster in which I rebooted one of the two nodes yesterday afternoon.  A      In the case of a system crash, the number of modified blocks @ simply grows until a mini-merge can be performed on it, that is,= the bitmap is not reset until the mini-merge is complete.  In A principle, that means more disk blocks must merged the longer the % mini-merge is delayed and is pending.   G      In practice, with the exception of our busiest database disks, the H elapsed time to execute the mini-merge depends MOSTLY on the size of theD bitmap, i.e., the size of the disk, NOT on the number of blocks thatG need to be merged.  Basically, the Shadow_Server has to walk the bitmap E and FIND the dirty bits to know which blocks to read and compare, and G that takes far longer than the actual disk I/O given the number of disk = blocks to compare is a very SMALL fraction of the total disk.   G      Finally, you will want to take advantage of setting Priorities for C your shadow sets: if any of them have significantly higher I/O than B others, set them to higher priority so they will mini-merge first.D I actually set unique priorities for all of our shadow sets, even inG our non-I/O intensive environments, since it makes the order of merging  predictable and reproducible.    	-Ken  --  6 I don't speak for Intel, Intel doesn't speak for me...  
 Ken Fairfield ! D1C Automation VMS System Support " who:   kenneth dot h dot fairfield where: intel dot com   ------------------------------  + Date: Fri, 22 Apr 2005 23:02:10 +0000 (UTC) P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)W Subject: Re: selecting the preferred merge host (was: Re: two questions about MINICOPY) $ Message-ID: <d4bvpi$97r$1@online.de>  9 In article <d4bgic$ek4$1@news01.intel.com>, Ken Fairfield ! <my.full.name@intel.com> writes:    + > > What I'm thinking of is the following:   > > H > >    o have SHADOW_MAX_COPY set to 1 (a higher value leads to too many& > >      ethernet errors) on all nodes > > D > >    o when a VAX boots, as soon as SYSMAN is up and running, set & > >      SHADOW_MAX_COPY to 0 on ALPHA  " Should be "1", not "0", of course.  J >      If the VAX system disk is mounted on the Alpha, the shadow copy mayE > start on the Alpha before you have a chance to "touch" the Alpha...	    Yes, I suppose that is possible.  G >      You might consider setting SHADOW_MAX_COPY to 0 on all nodes allEG > the time, by default.  This means you need a periodic job that checksIA > whether there is any merge or copy work to do, and if so, takesTF > appropriate action, or only initiate merges and/or copies "by hand".  I That might be the best thing to do.  There is a lot of information which  F can be returned by lexical functions.  I'll look into this.  I have a E few periodic jobs running anyway; this could be added to one of them.t  F >      In another post, I think you said that the Alpha would not do aE > minicopy of the VAX system disk even if that shadow set was mountedtD > on the Alpha and the one shadow set member got DISMOUNTED from the5 > Alpha before the system went down, is that right?  e  C When testing the VAX system disk, the system didn't go down.  When s7 testing a system going down, it wasn't the system disk.e  I To summarise, I found that SHADOW_MAX_COPY has to be 0 on VAX, otherwise CI (at least sometimes) the VAX will do the copy, even if the MOUNT command  I comes from an ALPHA, and that the MOUNT command must always come from an @G ALPHA, even if SHADOW_MAX_COPY is 0 on VAX.  In other words, one needs   both.-   ------------------------------  % Date: Fri, 22 Apr 2005 11:42:20 -0700a, From: Ken Fairfield <my.full.name@intel.com>Y Subject: Re: selecting the preferred merge host (was: Re: two questions about MINICOPY) Ms+ Message-ID: <d4bgic$ek4$1@news01.intel.com>a  / Phillip Helbig---remove CLOTHES to reply wrote: H > Now that I am pleased as punch that minicopy works fine on VAX as longG > as all operations are performed from an ALPHA, I'm looking to avoid a,C > potential problem:  If a VAX system-disk shadow set needs a mergewK > (normally, this would happen only after an unplanned reboot), I want the rK > VAX in question to do the merge, not an ALPHA over the network.  In such tH > a case, a minimerge will not be possible, so for a full merge I would @ > rather have the load on the node which just booted (everythingH > else---batch jobs, TCPIP cluster alias etc---will have failed over to D > the remaining nodes) rather than a) on another node and b) on the 3 > network (ALL my traffic is on a 10 Mb/s UTP LAN).- > J > The problem can occur since I should set SHADOW_MAX_COPY on VAX to 0 to K > avoid a full copy when a minicopy is possible (this is necessary even if eI > all MOUNT and DISMOUNT commands come from an ALPHA).  However, in this :0 > case, the VAX can't merge its own system disk. > ) > What I'm thinking of is the following: S > F >    o have SHADOW_MAX_COPY set to 1 (a higher value leads to too many$ >      ethernet errors) on all nodes > B >    o when a VAX boots, as soon as SYSMAN is up and running, set $ >      SHADOW_MAX_COPY to 0 on ALPHA  H      If the VAX system disk is mounted on the Alpha, the shadow copy mayC start on the Alpha before you have a chance to "touch" the Alpha...   J >    o after the VAX has had time to merge its system disk (if necessary),7 >      set SHADOW_MAX_COPY to 0 on it and to 1 on ALPHAe [...]   E      You might consider setting SHADOW_MAX_COPY to 0 on all nodes alloE the time, by default.  This means you need a periodic job that checksD? whether there is any merge or copy work to do, and if so, takes D appropriate action, or only initiate merges and/or copies "by hand".  D      Since you have VAXes in your cluster, you would need to use theB "hack" I posted in another of your threads to get the COPY startedD on a VAX if it boots with SHADOW_MAX_COPY set to 0.  If you get yourC Alphas upgraded to V7.3-2 and install the HBMM kit, you can write apE procedure to automate the "check for work to do", set SHADOW_MAX_COPY @ to a non-zero value, and trigger the pending work via SET SHADOWC /EVALUATE=RESOURCES (we do that at my site).  That job could be setnF to skip or ignore the VAX system disk (although there are "edge cases"B where the Alpha might accidentally pick up the COPY if you weren't	 careful).o  D      In another post, I think you said that the Alpha would not do aC minicopy of the VAX system disk even if that shadow set was mountedoB on the Alpha and the one shadow set member got DISMOUNTED from theC Alpha before the system went down, is that right?  Too bad, really.dD But it does simply the logic of whether to let the Alpha do the workG versus the VAX.  On the Alpha, you will be able to use SHOW SHAD/ACTIVEdF to find out what shadow sets are in "merge pending" or "copy pending",E but my recollection is that you can't tell whether the merge is going-D to be a minimerge or full merge, or the copy will be mini- or full-,E until they start (I could probably test, but the time at the moment).s   	-Kens -- y6 I don't speak for Intel, Intel doesn't speak for me...  
 Ken Fairfield,! D1C Automation VMS System Supporto" who:   kenneth dot h dot fairfield where: intel dot com   ------------------------------  % Date: Fri, 22 Apr 2005 11:53:27 -0700d, From: Ken Fairfield <my.full.name@intel.com>) Subject: Re: two questions about MINICOPY1+ Message-ID: <d4bh77$etg$1@news01.intel.com>   / Phillip Helbig---remove CLOTHES to reply wrote:p; > In article <d43p64$kg9$1@news01.intel.com>, Ken Fairfield-# > <my.full.name@intel.com> writes: r [...]aJ >>     Yep.  A conundrum.  As Rob Brooks mentioned (off thread?), the HBMMJ >>stuff gives you all sorts of control that has never been present before.E >>You get this in V8.2, or in V7.3-2 with the HBMM kit installed, buta >>*only* on *Alpha*. >  > K > I hope to go to 7.3-2 in a couple of weeks.  Is the HBMM kit a patch for e  > 7.3-2 or is it a separate kit?  1      A kit: VMS732_HBMM-V0200 is the current one.e  D >>     There is an undocumented, unsupported hack that can allow youB >>the control you need on the VAXes.  I'll throw this on the tableB >>without much discussion...contact me offline if you want to knowJ >>more.  If you set SHADOW_MAX_COPY to 0 in the CURRENT SYSGEN parameters,H >>when a VAX boots, it won't be able to do any merges or copies.  If youF >>want the VAX to do a copy or merge that is _pending_, the hack is toH >>(a) set SHADOW_MAX_COPY to 1 in the ACTIVE parameters (post-boot), andJ >>(b) reissue the MOUNT command for the shadow set that has an outstandingI >>merge or copy pending.  At this point the shadow server on the VAX will F >>"notice" that there is a merge or copy to do.  If all other nodes inG >>the cluster have SHADOW_MAX_COPY at 0, only the VAX will pick up thatoH >>work.  Once the merge or copy starts, you can set SHADOW_MAX_COPY back >>to 0.1 >  > 7 > Sounds interesting.  Why is that unsupported, though?s  A      Because it wasn't designed to work that way, VMS EngineeringtC didn't know it would work that way, it's an accident that it works,tC and HP won't answer any support calls if doesn't work for you?  Oh,n) and because it's not documented?  :-) :-)i  C > I would like to keep SHADOW_MAX_COPY at 1 on the ALPHAs so that acF > minicopy occurs in the case of an unexpected reboot which lasts longJ > enough so that a copy is needed, assuming this can be done automatciallyD > by specifying /POLICY=MINICOPY on mount (see above) and not on theE > (unplanned) dismount.  (That is, a job which periodically remounts t& > things will initiate this minicopy.)  B      So you need to test that.  As I said elsewhere, I don't thinkB you'll ever get a minicopy if the dismount is "unexpected", either@ due to a crash, a reboot, or the dismount being executed without the /POLICY=MINICOPY.A  B > Something I've noticed which is not EXPLICITLY mentioned in the K > documentation, as far as I can see:  Minicopy works fine for shadow sets  G > even if ALL members have direct connections ONLY to VAX machines, as kK > long as BOTH of the following are fulfilled: SHADOW_MAX_COPY is 0 on the sK > VAXes AND both the DISMOUNT and MOUNT commands with /POLICY=MINICOPY are nE > issued from an ALPHA.  If just one of these is true, then at least rH > sometimes a VAX and not an ALPHA will do the (full) copy.  (I haven't J > tried specifying /POLICY=MINICOPY on the FIRST mount, only on DISMOUNT.)  A     So you're saying you have to do the MOUNT on the Alpha _with_f@ /POLICY=MINICOPY in _addition_ to DISMOUNT on the Alpha with theC same qualifier.  Interesting.  I was wonder what use that qualifiere would have for a mount...e   [...]f   	-Kenr --  6 I don't speak for Intel, Intel doesn't speak for me...  
 Ken Fairfieldp! D1C Automation VMS System Supporte" who:   kenneth dot h dot fairfield where: intel dot com   ------------------------------  # Date: Fri, 22 Apr 2005 20:50:44 GMTc* From: "FredK" <fred.nospam@nospam.dec.com>) Subject: Re: two questions about MINICOPY 1 Message-ID: <Esdae.4414$h84.156@news.cpqcorp.net>o   This is from Lenny...g  / <dave.baxter@bannerhealth.com> wrote in messageE> news:<1114184709.608969.10180@o13g2000cwo.googlegroups.com>...  G > When setting up a policy for MiniMerge, the parameter RESET_THRESHOLD     Snipn   > Dave Baxter.  L It sounds like you may be blurring the distinction between shadow set mergesH and shadow set member copies. I believe that the shadowing manual does aG pretty good job of explaining the distinction and explaining under what(J circumstances each one is needed and why. I'll try to answer your questionH about bitmap resets considering a node crash with no member removals and' then a node crash with member removals.a  I The moment that a node crashes the remaining shadow sets are in need of a F merge. In the general case, the merge can start immediately and is notF dependent on the return of the crashed node. When a shadow set is in aJ merge-required or merge-in-progress state the reset of HBMM master bitmapsG is automatically suppressed regardless of the threshold value until the0F merge of the shadow set completes. Reads and writes are allowed to theK shadow set while an HBMM minimerge recovery takes place and additional bitsc can be set in the HBMM bitmaps.   I For example, consider a two member shadow set consisting of fibre channelbH disks on a SAN that is shared by all members of the cluster. When a nodeI crashes any of the cluster members with an HBMM master bitmap can performo/ the minimerge the moment that the crash occurs.-  L However, in a cluster with shadow set members that are accessed via MSCP andJ are private to either one, or a proper subset, of the nodes in the clusterL the crash of a node can cause some members of a shadow set to go offline forF as long a that node is down. In such a case you have member removal toK contend with as well as the node crash. The member removal is addressed viaoG a shadow set copy (as opposed to a shadow set merge) when the member is  available again.  H For example, consider a 3 member shadow set. Some node crashes and takesL away a member from that shadow set. The crash puts the shadow set in a mergeJ required state. But one member is missing, so that puts a hold on startingG the merge and all application level I/O is blocked to the shadow set byMJ mount verification. After shadow member timeout seconds the offline memberA is removed from the shadow set, mount verification completes, andRK application I/O is resumed. Now the merge can commence on the two survivingiH members (If the shadow set only had 2 members to begin with it would nowK have a single member and there would be nothing to merge). When the crashed6I node eventually reboots and returns the removed member back to the shadownK set, a full copy is required to bring that member back into the shadow set.-L HBMM is not involved in returning the member to the shadow set. In addition,H the minicopy capability is not available for shadow set members that areK removed due to an unplanned event like a node crash or device going offlineo due to an error.  D We do realize that we have a good opportunity to extend the HBMM andI minicopy capabilities to provide minicopy for unexpected member removals. L That is, conceptually we could do a minicopy operation using an HBMM bitmap.G In the case of such a facility we would automatically suppress the HBMM,J bitmap reset until the member was returned and the minicopy was completed.K We would like to deliver this sort of capability in a future release in the- not too distant future.A   I hope this helps.   ------------------------------  + Date: Fri, 22 Apr 2005 23:08:13 +0000 (UTC)DP From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)) Subject: Re: two questions about MINICOPYo$ Message-ID: <d4c04s$97r$2@online.de>  9 In article <d4bh77$etg$1@news01.intel.com>, Ken Fairfield ! <my.full.name@intel.com> writes:    3 >      A kit: VMS732_HBMM-V0200 is the current one.l  H Is there any way for a hobbyist to get this kit?  Obviously it's not on * my 7.3-2 CDs, since they pre-date the kit.  F > >>     There is an undocumented, unsupported hack that can allow youD > >>the control you need on the VAXes.  I'll throw this on the tableD > >>without much discussion...contact me offline if you want to knowL > >>more.  If you set SHADOW_MAX_COPY to 0 in the CURRENT SYSGEN parameters,J > >>when a VAX boots, it won't be able to do any merges or copies.  If youH > >>want the VAX to do a copy or merge that is _pending_, the hack is toJ > >>(a) set SHADOW_MAX_COPY to 1 in the ACTIVE parameters (post-boot), andL > >>(b) reissue the MOUNT command for the shadow set that has an outstandingK > >>merge or copy pending.  At this point the shadow server on the VAX will H > >>"notice" that there is a merge or copy to do.  If all other nodes inI > >>the cluster have SHADOW_MAX_COPY at 0, only the VAX will pick up thatmJ > >>work.  Once the merge or copy starts, you can set SHADOW_MAX_COPY back	 > >>to 0.e > > 9 > > Sounds interesting.  Why is that unsupported, though?  > C >      Because it wasn't designed to work that way, VMS Engineering E > didn't know it would work that way, it's an accident that it works,sE > and HP won't answer any support calls if doesn't work for you?  Oh,e+ > and because it's not documented?  :-) :-)a  C Actually, I would be surprised if it didn't work.  The distinction mF between ACTIVE and CURRENT parameters is rather clear.  I realise now H that you might be referring to reissuing the MOUNT command for a shadow D set which is already mounted.  This is of course not an hour, and I D suppose it's normal that at MOUNT there is a check done to see if a G shadow is needed.  I still don't see what is at all strange about this.   D >      So you need to test that.  As I said elsewhere, I don't thinkD > you'll ever get a minicopy if the dismount is "unexpected", eitherB > due to a crash, a reboot, or the dismount being executed without > the /POLICY=MINICOPY.d  2 Then what is the purpose of MOUNT/POLICY=MINICOPY?  D > > Something I've noticed which is not EXPLICITLY mentioned in the M > > documentation, as far as I can see:  Minicopy works fine for shadow sets  I > > even if ALL members have direct connections ONLY to VAX machines, as 6M > > long as BOTH of the following are fulfilled: SHADOW_MAX_COPY is 0 on the oM > > VAXes AND both the DISMOUNT and MOUNT commands with /POLICY=MINICOPY are  G > > issued from an ALPHA.  If just one of these is true, then at least lJ > > sometimes a VAX and not an ALPHA will do the (full) copy.  (I haven't L > > tried specifying /POLICY=MINICOPY on the FIRST mount, only on DISMOUNT.) > C >     So you're saying you have to do the MOUNT on the Alpha _with_ B > /POLICY=MINICOPY in _addition_ to DISMOUNT on the Alpha with theE > same qualifier.  Interesting.  I was wonder what use that qualifieri > would have for a mount...<  G No, the /POLICY=MINICOPY doesn't have to be specified on MOUNT, but it .F is the default if it was specified on DISMOUNT (i.e. if a WBM exists).   ------------------------------  % Date: Sat, 23 Apr 2005 00:38:07 +0800e From: prep@prep.synonet.com Y Subject: Re: VMS FAQ: changing volume label of system disk: DECnet MOP or LANCP LANCPLANC - Message-ID: <87r7h2sr68.fsf@prep.synonet.com>l  4 David J Dachtera <djesys.nospam@comcast.net> writes:  F > Now, that I have *NOT* seen. DECnet, MOP, LAT, etc., all seem to use > my single ExA0 device.  B They all `use' ExA0: as it is a template, and them use the created ExAn: for that channel.   - Do a SHO DEV E/ful/page and have a good look.    -- 5< Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda.@@                                              West Australia 6076* comp.os.vms,- The Older, Grumpier Slashdot. Raw, Cooked or Well-done, it's all half baked.F EPIC, The Architecture of the future, always has been, always will be.   ------------------------------   End of INFO-VAX 2005.225 ************************