1 INFO-VAX	Sat, 11 Oct 2003	Volume 2003 : Issue 564       Contents:  anyone running 7.3-1 with 64 MB?$ Re: anyone running 7.3-1 with 64 MB?E concerned and confused about adding shadow-set members to system disk I Re: concerned and confused about adding shadow-set members to system disk I Re: concerned and confused about adding shadow-set members to system disk I Re: concerned and confused about adding shadow-set members to system disk I Re: concerned and confused about adding shadow-set members to system disk I Re: concerned and confused about adding shadow-set members to system disk , concerned and confused about MOUNT/NOREBUILD0 Re: concerned and confused about MOUNT/NOREBUILD0 Re: concerned and confused about MOUNT/NOREBUILD8 cpu upgradable in HP x4000 and Dell Precision dual xeon?< Re: cpu upgradable in HP x4000 and Dell Precision dual xeon?< Re: cpu upgradable in HP x4000 and Dell Precision dual xeon?2 Re: EVA question: How many vdisks should I create?/ Re: HGFTP - how to troubleshoot data connection D How clean is the snapshot when dismounting a member of a shadow set?H Re: How clean is the snapshot when dismounting a member of a shadow set?H Re: How clean is the snapshot when dismounting a member of a shadow set?H Re: How clean is the snapshot when dismounting a member of a shadow set?H Re: How clean is the snapshot when dismounting a member of a shadow set?H Re: How clean is the snapshot when dismounting a member of a shadow set? Re: Info about HP # Re: Laptop, Reflections, delete key P looking for free (or very cheap) used hardware in the Dallas/Fort Worth area, 22 Re: MD5 source code ? 1 NISCS_LOAD_PEA0: confusion in the cluster manual? B Re: ppp on OpenVMS AlphaServer hardware port for remote gui access Re: Sickening, isn't it? Re: Sickening, isn't it? Re: Sun takes a hit = Re: The VAX/VMS to Itanium Migration Letter, Vol. 1 Number 1.   What does MSCP_SERVE_ALL=4 mean?$ Re: What does MSCP_SERVE_ALL=4 mean?$ Re: What does MSCP_SERVE_ALL=4 mean?/ where to buy memory for |d|i|g|i|t|a|l| systems 3 Re: where to buy memory for |d|i|g|i|t|a|l| systems   F ----------------------------------------------------------------------  + Date: Sat, 11 Oct 2003 12:41:06 +0000 (UTC) P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)) Subject: anyone running 7.3-1 with 64 MB? $ Message-ID: <bm8tp1$guf$3@online.de>  G I have an ALPHAstation 255/233 with 64 MB at 7.2-1.  I plan to upgrade  H to 7.3-1 soon, possibly this weekend.  Is anyone actually running 7.3-1 & with just 64 MB?  Is it even possible?  B Note that I am not just running core VMS, but also DECwindows.  InC addition, the machine is running the OSU server, has 7 SCSI devices D attached, some of them shadowed (with devices on the same controllerG (there is only one on the machine) or with other disks in the cluster)   and is in a cluster.  H Performance now is acceptable, though it could be better of course.  (I ? haven't analysed things to see where the real bottlenecks are.)   G I understand that 7.3-1 has many performance improvements.  So, things  H might actually get better.  On the other hand, perhaps I need more than ' 64 MB to actually take advantage of it.   H A related question---is there ever any reason at all not to put as much H memory into the machine as possible?  (I think I can put 8 128-MB SIMMs  in the 255.)   ------------------------------    Date: 11 Oct 2003 17:53:36 +0100K From: pmoreau@ath.cena.fr (Patrick MOREAU, CENA Athis, Tel: 01.69.57.68.40) - Subject: Re: anyone running 7.3-1 with 64 MB? ! Message-ID: <+6VVZJBdqWWe@sinead>   w In article <bm8tp1$guf$3@online.de>, helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) writes: I > I have an ALPHAstation 255/233 with 64 MB at 7.2-1.  I plan to upgrade  J > to 7.3-1 soon, possibly this weekend.  Is anyone actually running 7.3-1 ( > with just 64 MB?  Is it even possible?  O The more memory you have, the better VMS feels. In the past, I have run VMS 6.2 M with only 32 Mb on a 255/233 (an also on a 300). With just one Decterm it was - acceptable, with two...  swap  swap swap ....   M The 255/233 has now 192 Mb (runs far better). And with greater memory you can ' allow a greater VIOC for caching files.    Patrick  --O =============================================================================== N pmoreau@ath.cena.fr  (CENA)      ______      ___   _          (Patrick MOREAU)4 moreau_p@decus.fr (DECUS)       / /   /     / /|  /|J CENA/Athis-Mons FRANCE         / /___/     / / | / |   __   __   __   __  N BP 205                        / /         / /  |/  |  |  | |__| |__  |__| |  |N 94542 ORLY AEROGARE CEDEX    / /   ::    / /       |  |__| | \  |__  |  | |__|N http://www.ath.cena.fr/~pmoreau/            http://www.multimania.com/pmoreau/O ===============================================================================    ------------------------------  + Date: Sat, 11 Oct 2003 09:36:15 +0000 (UTC) P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)N Subject: concerned and confused about adding shadow-set members to system disk$ Message-ID: <bm8iuf$609$1@online.de>  E Actually, I think the documentation is confused.  It's been discussed C many times here that one boots from a physical disk (though perhaps ? there can be a list of devices) and that the shadowing software @ automatically determines what other members should be added to aE system-disk shadow set during boot.  In particular, it is a Very Bad  F Thing to have MOUNT commands in the startup procedure to add disks to  the system-disk shadow set.   G Consider, however, Volume Shadowing for OpenVMS.  Section 3.3 seems to  D confirm the recommendations above.  So far, so good.  Now, consider + OpenVMS Cluster Systems.  Section 6.5 says:   <        System disks can be shadowed. All nodes booting from#         shadowed system disks must:   8          -  Have a Volume Shadowing for OpenVMS license.  ?          -  Specify the same physical member of the system disk ,               shadow set as the boot device.  =          -  Set shadowing system parameters to enable shadow- B               ing and specify the system disk virtual unit number.  =          -  Mount additional physical members into the system ;               disk shadow set early in the SYSTARUP_VMS.COM                 command procedure.  9          -  Mount the disks to be used in the shadow set.   D Based on what the shadowing manual says, and on discussion here, it H seems that the cluster manual is JUST PLAIN WRONG here.  In particular, B the fourth point above "Mount additional physical members into theH system disk shadow set early in the SYSTARUP_VMS.COM command procedure."% seems like a very bad recommendation.   / Shouldn't the cluster manual be corrected here?    ------------------------------  % Date: Sat, 11 Oct 2003 13:12:13 +0200 ( From: "H Vlems" <hvlems.nieuw@zonnet.nl>R Subject: Re: concerned and confused about adding shadow-set members to system disk9 Message-ID: <bm8om5$j6ca4$1@ID-143435.news.uni-berlin.de>   G You do come up with interesting questions on an early Saturday morning,  don't you Phillip :-)   H There are two options in handling shadowed system disks across a reboot:  L 1) if the system is shutdown and  the systemdisk shadowset has more than oneG volume then these volumes will be part of the system shadowset when the L system is rebooted (unless you change SYSBOOT parameters in between but that would be cheating, right) J 2) if volumes are removed from the systemdisk shadowset, in SYSHUTDWN.COM,C then they must be mounted explicitly; that is in SYSTARTUP_VMS.COM.   H Both methods work and it just depends on how much you have faith in yourH diskfarms. The trouble with it is that if one volume fails then you mustH correct the situation manually. That takes a quick analysis of what justL went wrong during the boot process and the knowledge to fix the problem. NotG that this is really difficult but VMS systems are usually only rebooted I after a calamity (a problem, or a new VMS version), anyway at a time when / your blood pressure might be higher than usual. K That is why Digital recommends the second option. It is safer and easier to ? handle when something has broken during the shutdown procedure. G BTW there are sites where the recommendation to mount the shadowmembers A early was taken to seriously and the mount statements ended up in   SYLOGICALS.COM. Not a good idea.  H Simply put, if you trust your hardware then use the first method, if you don't use the second. C The way you end your post I take it you tend to trust hardware over  software, right :-)   L "Phillip Helbig---remove CLOTHES to reply" <helbig@astro.multiCLOTHESvax.de>1 schreef in bericht news:bm8iuf$609$1@online.de... G > Actually, I think the documentation is confused.  It's been discussed E > many times here that one boots from a physical disk (though perhaps A > there can be a list of devices) and that the shadowing software B > automatically determines what other members should be added to aF > system-disk shadow set during boot.  In particular, it is a Very BadG > Thing to have MOUNT commands in the startup procedure to add disks to  > the system-disk shadow set.  > H > Consider, however, Volume Shadowing for OpenVMS.  Section 3.3 seems toE > confirm the recommendations above.  So far, so good.  Now, consider - > OpenVMS Cluster Systems.  Section 6.5 says:  > > >        System disks can be shadowed. All nodes booting from% >         shadowed system disks must:  > : >          -  Have a Volume Shadowing for OpenVMS license. > A >          -  Specify the same physical member of the system disk . >               shadow set as the boot device. > ? >          -  Set shadowing system parameters to enable shadow- D >               ing and specify the system disk virtual unit number. > ? >          -  Mount additional physical members into the system = >               disk shadow set early in the SYSTARUP_VMS.COM " >               command procedure. > ; >          -  Mount the disks to be used in the shadow set.  > E > Based on what the shadowing manual says, and on discussion here, it I > seems that the cluster manual is JUST PLAIN WRONG here.  In particular, D > the fourth point above "Mount additional physical members into theJ > system disk shadow set early in the SYSTARUP_VMS.COM command procedure."' > seems like a very bad recommendation.  > 1 > Shouldn't the cluster manual be corrected here?  >    ------------------------------  + Date: Sat, 11 Oct 2003 12:20:24 +0000 (UTC) P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)R Subject: Re: concerned and confused about adding shadow-set members to system disk$ Message-ID: <bm8si7$dnl$2@online.de>  C In article <bm8om5$j6ca4$1@ID-143435.news.uni-berlin.de>, "H Vlems" ! <hvlems.nieuw@zonnet.nl> writes:    I > You do come up with interesting questions on an early Saturday morning,  > don't you Phillip :-)   C As Chaucer said, the lyf so short, the craft so long to lerne.  :-)   J > There are two options in handling shadowed system disks across a reboot: > N > 1) if the system is shutdown and  the systemdisk shadowset has more than oneI > volume then these volumes will be part of the system shadowset when the N > system is rebooted (unless you change SYSBOOT parameters in between but that > would be cheating, right)    Right.  That's what I'm doing.  L > 2) if volumes are removed from the systemdisk shadowset, in SYSHUTDWN.COM,E > then they must be mounted explicitly; that is in SYSTARTUP_VMS.COM.   4 Why would one do this (remove them during shutdown)?  J > Both methods work and it just depends on how much you have faith in yourJ > diskfarms. The trouble with it is that if one volume fails then you mustJ > correct the situation manually. That takes a quick analysis of what justN > went wrong during the boot process and the knowledge to fix the problem. NotI > that this is really difficult but VMS systems are usually only rebooted K > after a calamity (a problem, or a new VMS version), anyway at a time when 1 > your blood pressure might be higher than usual.    In scenario 2), right?  M > That is why Digital recommends the second option. It is safer and easier to A > handle when something has broken during the shutdown procedure.   ) Where is this recommendation spelled out?   J > Simply put, if you trust your hardware then use the first method, if you > don't use the second. E > The way you end your post I take it you tend to trust hardware over  > software, right :-)   H I trust the hardware.  I trust VMS to do the right thing in the case of B a hardware failure.  I don't always trust my own untested startup  procedures.  :-|   ------------------------------  % Date: Sat, 11 Oct 2003 16:29:03 +0200 ( From: "H Vlems" <hvlems.nieuw@zonnet.nl>R Subject: Re: concerned and confused about adding shadow-set members to system disk9 Message-ID: <bm9478$jkn40$1@ID-143435.news.uni-berlin.de>   L "Phillip Helbig---remove CLOTHES to reply" <helbig@astro.multiCLOTHESvax.de>1 schreef in bericht news:bm8si7$dnl$2@online.de... E > In article <bm8om5$j6ca4$1@ID-143435.news.uni-berlin.de>, "H Vlems" " > <hvlems.nieuw@zonnet.nl> writes: > K > > You do come up with interesting questions on an early Saturday morning,  > > don't you Phillip :-)  > E > As Chaucer said, the lyf so short, the craft so long to lerne.  :-)   & Mr. Chaucer had remarkable insight ...   > L > > There are two options in handling shadowed system disks across a reboot: > > L > > 1) if the system is shutdown and  the systemdisk shadowset has more than one K > > volume then these volumes will be part of the system shadowset when the K > > system is rebooted (unless you change SYSBOOT parameters in between but  that > > would be cheating, right)  >   > Right.  That's what I'm doing. > ? > > 2) if volumes are removed from the systemdisk shadowset, in  SYSHUTDWN.COM,G > > then they must be mounted explicitly; that is in SYSTARTUP_VMS.COM.  > 6 > Why would one do this (remove them during shutdown)? > L > > Both methods work and it just depends on how much you have faith in yourL > > diskfarms. The trouble with it is that if one volume fails then you mustL > > correct the situation manually. That takes a quick analysis of what justL > > went wrong during the boot process and the knowledge to fix the problem. Not K > > that this is really difficult but VMS systems are usually only rebooted H > > after a calamity (a problem, or a new VMS version), anyway at a time when3 > > your blood pressure might be higher than usual.  >  > In scenario 2), right?  H Actually that situation descibes scenario 1. If VMS reboots and expects,I say, a two member shadow set and one of those members is damaged then the F error messages seem to confuse the operators. As long as one volume is1 functional VMS itself proceeds without a problem.  > L > > That is why Digital recommends the second option. It is safer and easier toC > > handle when something has broken during the shutdown procedure.  > + > Where is this recommendation spelled out?   G Well,  you quoted a manual when you wrote the part about unmounting and H mounting shadowed system disks. I took that text as a recommendation for scenario 2.  > L > > Simply put, if you trust your hardware then use the first method, if you > > don't use the second. G > > The way you end your post I take it you tend to trust hardware over  > > software, right :-)  > I > I trust the hardware.  I trust VMS to do the right thing in the case of C > a hardware failure.  I don't always trust my own untested startup  > procedures.  :-| > L I understand the sentiment but have learned te be somewhat more careful with( non-Digital designed/built equipment :-(   ------------------------------  + Date: Sat, 11 Oct 2003 15:09:15 +0000 (UTC) P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)R Subject: Re: concerned and confused about adding shadow-set members to system disk$ Message-ID: <bm96eq$qet$2@online.de>  C In article <bm9478$jkn40$1@ID-143435.news.uni-berlin.de>, "H Vlems" ! <hvlems.nieuw@zonnet.nl> writes:     > > In scenario 2), right? > J > Actually that situation descibes scenario 1. If VMS reboots and expects,K > say, a two member shadow set and one of those members is damaged then the H > error messages seem to confuse the operators. As long as one volume is3 > functional VMS itself proceeds without a problem.   H That's good enough for me.  Presumably, BOOTDEF_DEV should be a list of I BOTH devices, so that if the first one has failed, it will boot from the  7 second one.  (This could be done with either scenario.)   G Any idea what VMS machines support a search list for BOOTDEF_DEV?  (Or  B its equivalent; I think some (VAX) consoles use a different term,  perhaps just BOOT.)   - > > Where is this recommendation spelled out?  > I > Well,  you quoted a manual when you wrote the part about unmounting and J > mounting shadowed system disks. I took that text as a recommendation for
 > scenario 2.   H OK.  That's in the cluster manual.  But the shadowing manual explicitly G says that it is a bad idea to mount additional members into the shadow  I set at startup.  It would be interesting, though, to know if this refers  D to the case that they had been removed during shutdown or not.  (Of D course, if there is a power failure or something, the site-specific ' shutdown procedure won't get executed.)   K > > I trust the hardware.  I trust VMS to do the right thing in the case of E > > a hardware failure.  I don't always trust my own untested startup  > > procedures.  :-| > > N > I understand the sentiment but have learned te be somewhat more careful with* > non-Digital designed/built equipment :-(  , My system disks are genuine |d|i|g|i|t|a|l|.   ------------------------------  % Date: Sat, 11 Oct 2003 19:40:25 +0200 ( From: "H Vlems" <hvlems.nieuw@zonnet.nl>R Subject: Re: concerned and confused about adding shadow-set members to system disk9 Message-ID: <bm9fe3$juf31$1@ID-143435.news.uni-berlin.de>   L "Phillip Helbig---remove CLOTHES to reply" <helbig@astro.multiCLOTHESvax.de>1 schreef in bericht news:bm96eq$qet$2@online.de... E > In article <bm9478$jkn40$1@ID-143435.news.uni-berlin.de>, "H Vlems" " > <hvlems.nieuw@zonnet.nl> writes: >  > > > In scenario 2), right? > > L > > Actually that situation descibes scenario 1. If VMS reboots and expects,I > > say, a two member shadow set and one of those members is damaged then  the J > > error messages seem to confuse the operators. As long as one volume is5 > > functional VMS itself proceeds without a problem.  > I > That's good enough for me.  Presumably, BOOTDEF_DEV should be a list of J > BOTH devices, so that if the first one has failed, it will boot from the9 > second one.  (This could be done with either scenario.)   : I did not even know BOOTDEF_DEV did support a search list.   > H > Any idea what VMS machines support a search list for BOOTDEF_DEV?  (OrC > its equivalent; I think some (VAX) consoles use a different term,  > perhaps just BOOT.)  > / > > > Where is this recommendation spelled out?  > > K > > Well,  you quoted a manual when you wrote the part about unmounting and L > > mounting shadowed system disks. I took that text as a recommendation for > > scenario 2.  > I > OK.  That's in the cluster manual.  But the shadowing manual explicitly H > says that it is a bad idea to mount additional members into the shadowJ > set at startup.  It would be interesting, though, to know if this refersE > to the case that they had been removed during shutdown or not.  (Of E > course, if there is a power failure or something, the site-specific ) > shutdown procedure won't get executed.)  >   L Agreed, the text in the shadowing manual is somewhat ambiguous. The term "..E at startup .." may be read as "during SYSTARTUP" or as "as VMS itself = starts" (basically as long as STARTUP.COM itself is running).   J > > > I trust the hardware.  I trust VMS to do the right thing in the case ofG > > > a hardware failure.  I don't always trust my own untested startup  > > > procedures.  :-| > > > K > > I understand the sentiment but have learned te be somewhat more careful  with, > > non-Digital designed/built equipment :-( > . > My system disks are genuine |d|i|g|i|t|a|l|. > H True for my VAX systems, the two Alpha's both use a 4.3GB Cheetah at 10k rpm. Not bad either...   ------------------------------  + Date: Sat, 11 Oct 2003 09:22:41 +0000 (UTC) P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)5 Subject: concerned and confused about MOUNT/NOREBUILD $ Message-ID: <bm8i51$2n0$3@online.de>  H I want to avoid the delay caused by a rebuild during boot.  Reading the F cluster manual, I'm a bit confused as to what the recommendation is.   The way I understand it:  0 ALWAYS use MOUNT/NOREBUILD for non-system disks.  I For system disks, set ACP_REBLDSYSD to 0 on satellites and to 1 for boot   servers.  ( Of course, do a MOUNT/REBUILD regularly.   Three questions:  , Is this what the manual actually recommends?  - Do folks here agree with this recommendation?   F What about system disks on one system which are MSCP mounted on other D systems?  I mount all disks on all nodes.  I don't actually use the ? system disks on nodes to which they are MSCP served, but it is   convenient for things like    3    SYSMAN> DO SEARCH SYS$SYSTEM MODPARAMS.DAT VOTES   I Presumably, these should also be mounted with /NOREBUILD, though perhaps  I it doesn't matter since the system to which the system disk has a direct  D connection will rebuild it if ACP_REBLDSYSD is set to 1 (as per the I recommendation) before another system has a chance to mount it---or am I   wrong here?    ------------------------------  % Date: Sat, 11 Oct 2003 07:38:29 -0500 ( From: Wayne Sewell <wayne@tachysoft.com>9 Subject: Re: concerned and confused about MOUNT/NOREBUILD / Message-ID: <00A27353.2097EE63.3@tachysoft.com>   J >From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to
 >      reply)  >X-Newsgroups: comp.os.vms6 >Subject: concerned and confused about MOUNT/NOREBUILD > I >I want to avoid the delay caused by a rebuild during boot.  Reading the  G >cluster manual, I'm a bit confused as to what the recommendation is.    >The way I understand it:  > 1 >ALWAYS use MOUNT/NOREBUILD for non-system disks.  > J >For system disks, set ACP_REBLDSYSD to 0 on satellites and to 1 for boot 	 >servers.  > ) >Of course, do a MOUNT/REBUILD regularly.  >  >Three questions:  > - >Is this what the manual actually recommends?  > . >Do folks here agree with this recommendation? > G >What about system disks on one system which are MSCP mounted on other  E >systems?  I mount all disks on all nodes.  I don't actually use the  @ >system disks on nodes to which they are MSCP served, but it is  >convenient for things like  > 4 >   SYSMAN> DO SEARCH SYS$SYSTEM MODPARAMS.DAT VOTES > J >Presumably, these should also be mounted with /NOREBUILD, though perhaps J >it doesn't matter since the system to which the system disk has a direct E >connection will rebuild it if ACP_REBLDSYSD is set to 1 (as per the  J >recommendation) before another system has a chance to mount it---or am I  >wrong here? >   L It's really not a big deal.  I mount all the disks /norebuild during startupO and then automatically submit a command procedure to do the rebuilds.  That way H the rebuilds get done *soon* after startup, but don't actually delay the startup.   Wayne O =============================================================================== N Wayne Sewell, Tachyon Software Consulting  (281)812-0738   wayne@tachysoft.com; http://www.tachysoft.com/www/tachyon.html and wayne.html    O =============================================================================== H Randolph Duke (in Trading Places): "Mother always said you were greedy."1    Mortimer Duke: "She meant it as a compliment!"    ------------------------------  % Date: Sat, 11 Oct 2003 12:07:00 -0400 % From: "John Vottero" <John@mvpsi.com> 9 Subject: Re: concerned and confused about MOUNT/NOREBUILD / Message-ID: <vogal5am6plo22@news.supernews.com>   L "Phillip Helbig---remove CLOTHES to reply" <helbig@astro.multiCLOTHESvax.de>/ wrote in message news:bm8i51$2n0$3@online.de... I > I want to avoid the delay caused by a rebuild during boot.  Reading the F > cluster manual, I'm a bit confused as to what the recommendation is. > The way I understand it: > 2 > ALWAYS use MOUNT/NOREBUILD for non-system disks. > J > For system disks, set ACP_REBLDSYSD to 0 on satellites and to 1 for boot
 > servers. > * > Of course, do a MOUNT/REBUILD regularly.  * I think you really want SET VOLUME/REBUILD   >  > Three questions: > . > Is this what the manual actually recommends? > / > Do folks here agree with this recommendation?   L Yes.  Make sure you rebuild shortly after booting.  I have systartup_vms.com* submit a batch job that does the rebuilds.   > G > What about system disks on one system which are MSCP mounted on other E > systems?  I mount all disks on all nodes.  I don't actually use the @ > system disks on nodes to which they are MSCP served, but it is > convenient for things like > 5 >    SYSMAN> DO SEARCH SYS$SYSTEM MODPARAMS.DAT VOTES  > J > Presumably, these should also be mounted with /NOREBUILD, though perhapsJ > it doesn't matter since the system to which the system disk has a directE > connection will rebuild it if ACP_REBLDSYSD is set to 1 (as per the J > recommendation) before another system has a chance to mount it---or am I
 > wrong here?  >    ------------------------------    Date: 11 Oct 2003 08:25:30 -0700' From: ballbustingbabe@hotmail.com (Lia) A Subject: cpu upgradable in HP x4000 and Dell Precision dual xeon? = Message-ID: <f98a9e28.0310110725.6e78bd74@posting.google.com>   
 Hey there,  B I'm looking at two used systems to buy right now...a Dell 620 withD dual xeon 1ghz processors, and an HP x4000 with dual xeon p4 1.7 ghz processors.   @ Two questions: First, are these cpu chips upgradable and to what7 speed? Second, I'm not sure if the Dell is a P3 or a P4 2 processor...what's the difference between the two?  # I look forward to hearing from you!    Lia    ------------------------------  % Date: Sat, 11 Oct 2003 19:18:31 +0200 ( From: "H Vlems" <hvlems.nieuw@zonnet.nl>E Subject: Re: cpu upgradable in HP x4000 and Dell Precision dual xeon? 9 Message-ID: <bm9e51$ivebd$1@ID-143435.news.uni-berlin.de>   6 "Lia" <ballbustingbabe@hotmail.com> schreef in bericht7 news:f98a9e28.0310110725.6e78bd74@posting.google.com...  > Hey there, > D > I'm looking at two used systems to buy right now...a Dell 620 withF > dual xeon 1ghz processors, and an HP x4000 with dual xeon p4 1.7 ghz
 > processors.  > B > Two questions: First, are these cpu chips upgradable and to what9 > speed? Second, I'm not sure if the Dell is a P3 or a P4 4 > processor...what's the difference between the two? > % > I look forward to hearing from you!  >  > Lia   H Glad to help Lia, but one of the rules in this group is that you have toL specify the version of the operating system you're running. Now what version- of VMS do you (want to) run on those systems?    Hans   ------------------------------  % Date: Sat, 11 Oct 2003 19:31:40 +0200 $ From: Michael Unger <unger@decus.de>E Subject: Re: cpu upgradable in HP x4000 and Dell Precision dual xeon? 9 Message-ID: <bm9f0i$k5o9n$1@ID-152801.news.uni-berlin.de>   % On 2003-10-11 19:18, "H Vlems" wrote:   8 > "Lia" <ballbustingbabe@hotmail.com> schreef in bericht9 > news:f98a9e28.0310110725.6e78bd74@posting.google.com... 
 >> Hey there,  >>E >> I'm looking at two used systems to buy right now...a Dell 620 with G >> dual xeon 1ghz processors, and an HP x4000 with dual xeon p4 1.7 ghz  >> processors. >> >> [...] > J > Glad to help Lia, but one of the rules in this group is that you have toN > specify the version of the operating system you're running. Now what version/ > of VMS do you (want to) run on those systems?    VMS running on XEONs???    Michael    --  ; Real names enhance the probability of getting real answers. @ Please do *not* send "Security Patch Notifications" or "SecurityA Updates"; this system isn't running a Micro$oft operating system. = And don't annoy me <mailto:postmaster@[127.0.0.1]> please ;-)    ------------------------------  % Date: Sat, 11 Oct 2003 05:33:39 -0400 * From: "Bill Todd" <billtodd@metrocast.net>; Subject: Re: EVA question: How many vdisks should I create? 2 Message-ID: <UoKdnV2KXffvUxqiU-KYuA@metrocast.net>  8 "Rob Young" <young_r@encompasserve.org> wrote in message- news:O7zYMXbqiWx3@eisner.encompasserve.org...    ...   @ > If Unix and Windows are throttling, Unix can make up for it by= > striping a filesystem across multiple LUNs.  But if you had A > 60 disks and a Windows LUN is bound at 32 outstanding requests, B > it seems Windows can't take advantage of the other 28 drives (or< > leaving a lot of IO on the table), or can it?  If so, how?  I Windows can stripe across multiple LUNs as well, so just use two or more.    ...   ? > >> It makes little sense to send from the OS more IO requests 0 > >> if the LUN you are talking to is saturated. > > H > > What do you mean by 'saturated'?  It certainly makes sense to submitJ > > additional requests even if they can't be satisfied immediately (i.e., all F > > disks are busy at the time the next request arrives):  that's what allowsG > > individual disks (or higher-level intelligence in the EVA) to start J > > optimizing request orders (taking into account the head and rotationalG > > position of the individual disks) to improve overall throughput and  average  > > response time. > = > Saturated is weak and vacuous.  Saturated to the point that 7 > average IO response is trailing off dramatically with A > little throughput gained.  Actual data on the same non-EVA LUN:  > , > Queue Depth  IO size IOPS Average Response > 16 2 KB 400 35 ms  > 29 2 KB 415 65 ms  > 32 2 KB 419 71 ms  > D > Going from Queue Depth 16 to 32 gains little more than 19 IOPS and > yet doubles response time.  H Indeed - but so what?  Either you need better response time and must addL more spindles to spread the load across, or for one reason or another you'reK stuck with the spindles you have - in which (latter) case you might as well L give them as much optimization latitude to work with as possible, even if itJ only improves throughput marginally (if you instead hold back the requestsD in a driver queue, it won't improve their response time - rather the
 opposite).   - bill   ------------------------------  # Date: Sat, 11 Oct 2003 17:43:16 GMT ( From: Alder <PGDEHMKOKIMD@spammotel.com>8 Subject: Re: HGFTP - how to troubleshoot data connection* Message-ID: <UiXhb.5613$Pe5.1495@edtnps84>    david20@alpha1.mdx.ac.uk wrote::  K >>I found that clients CAN connect to my HGFTP server, but only if they're  I >>using Active mode and don't have a firewall on their end.  I'd like to  J >>support Passive mode connections, but I don't see anything in the HGFTP H >>docs that would suggest it supports Passive mode.  I also checked the H >>docs for the FTP server in TCPIP Services for OpenVMS and didn't find  >>anything in there either.  >>H >>Does anyone know if either of these servers DOES support Passive mode $ >>connections, and how to enable it? >> >  > H > Don't need to do anything special to the DEC TPIP services ftp server.0 > The client just needs to request passive mode.   David,  @ I definitely cannot get a passive-mode data connection from the 1 non-firewalled client I'm using to test all this.   F The way I understand this is that my server receives the PASV command H from the client and should then - if it supports passive mode - respond E with an ephemeral port number it is willing to listen for and accept  F data connections on.  The client should then make its data connection G attempt on this ephemeral port.  But, because I don't know which ports  A the HGFTP or TCPIP Services FTP server will want to use, I can't  B configure the gateway to open the proper range.  Hence the client C "hangs" when it asks for a directory listing.  Are the two servers  % simply using any old port above 1024?    Any suggestions folks?   Cheers,    Alder    ------------------------------  + Date: Sat, 11 Oct 2003 09:09:20 +0000 (UTC) P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)M Subject: How clean is the snapshot when dismounting a member of a shadow set? $ Message-ID: <bm8hc0$2n0$2@online.de>  D If I dismount one member of a shadow set, and files are open on the ? shadow set, how "clean" is the snapshot of the shadow set?  In mG particular, I'm looking for the easiest way to clone a disk---I'd like mI to avoid dismounting and remounting the shadow set with one less member, m) which would mean closing the files first.o  F In making such a clone, I wouldn't be concerned about the files which B are open---I'm more concerned about possible side effects of this 	 approach.f   ------------------------------  % Date: Sat, 11 Oct 2003 12:55:56 +0200d( From: "H Vlems" <hvlems.nieuw@zonnet.nl>Q Subject: Re: How clean is the snapshot when dismounting a member of a shadow set?p9 Message-ID: <bm8nnk$kkpv0$1@ID-143435.news.uni-berlin.de>   L "Phillip Helbig---remove CLOTHES to reply" <helbig@astro.multiCLOTHESvax.de>1 schreef in bericht news:bm8hc0$2n0$2@online.de...sE > If I dismount one member of a shadow set, and files are open on the @ > shadow set, how "clean" is the snapshot of the shadow set?  InH > particular, I'm looking for the easiest way to clone a disk---I'd likeJ > to avoid dismounting and remounting the shadow set with one less member,+ > which would mean closing the files first.s > G > In making such a clone, I wouldn't be concerned about the files which C > are open---I'm more concerned about possible side effects of thiss > approach.o >iL Interesting question. My initial reaction to the question was that you'd endJ up with the same situation as running BACKUP/IMAGE/IGNORE=INTERLOCK on theJ disk. The only difference being that backup takes time to complete and theI actual on-disk state of an open file is never known for sure. AFAIK it is K the reason why an image backup of a database disk won't work when restored.iL Dismounting a shadowset with files open would give you a much "cleaner" cut.L I doubt whether that would help with a database, even if the system is quiet during the dismount operation.E But perhaps you could elaborate on what you consider "side effects" ?i   ------------------------------  + Date: Sat, 11 Oct 2003 12:14:12 +0000 (UTC)-P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)Q Subject: Re: How clean is the snapshot when dismounting a member of a shadow set?n$ Message-ID: <bm8s6k$dnl$1@online.de>  C In article <bm8nnk$kkpv0$1@ID-143435.news.uni-berlin.de>, "H Vlems"2! <hvlems.nieuw@zonnet.nl> writes: s  N > Interesting question. My initial reaction to the question was that you'd endL > up with the same situation as running BACKUP/IMAGE/IGNORE=INTERLOCK on theL > disk. The only difference being that backup takes time to complete and the@ > actual on-disk state of an open file is never known for sure.   B Right, it's faster.  (Well, when I replace the disk I remove with D another one, a shadow copy will happen, but I don't care about that # since I don't have to wait for it.)(  
 > AFAIK it issM > the reason why an image backup of a database disk won't work when restored.a  9 This definitely wouldn't be possible with database files.y  N > Dismounting a shadowset with files open would give you a much "cleaner" cut.   Indeed.o  N > I doubt whether that would help with a database, even if the system is quiet  > during the dismount operation.  * No, I don't plan to do this to a database.  G > But perhaps you could elaborate on what you consider "side effects" ?1  B I'm mainly concerned with cloning system disks.  That is, after a I successful upgrade when I have a valid shadow set, remove one member and VI use it for the system disk on another machine, replacing it with a fresh tF disk (which will be the target of a shadow copy).  There are a lot of H open files on a system disk, but presumably most of these are just open > for reading.  I'm sure they don't change on disk under normal F circumstances; the question is if they can become corrupted when I do F the dismount.  (There are also log files open, but I don't care about F these since they are of no interest on the other machine.  SYSUAF etc # are not on the system disk at all.)w  F The other alternative, of course, is to shut down the system, replace I one of the disks, and reboot.  It means an additional reboot.  Actually,  G with a three-node cluster, this is not really a problem.  It does take = more time, though.  F Now that I think about it, perhaps the best thing to do is, after the F upgrade, move to a THREE-member shadow set.  That way, if I shut down H the system, remove a disk and reboot, I end up with a two-member shadow 1 set (which is what I want) without a shadow copy!   C This leads to another question: can I have one of the members of a _G SYSTEM-DISK shadow set be directly connected to another machine in the iG cluster (even one with different architecture) and only MSCP served to =I the system using it as a system disk, as long as I add this member after 1G all machines in the cluster are up and running (or at least if I don't PF boot from it)?  If I can do this, the extra reboot would be worth the . trouble of avoiding an additional shadow copy.   ------------------------------  % Date: Sat, 11 Oct 2003 16:14:53 +0200o( From: "H Vlems" <hvlems.nieuw@zonnet.nl>Q Subject: Re: How clean is the snapshot when dismounting a member of a shadow set?s9 Message-ID: <bm93cn$k0cmo$1@ID-143435.news.uni-berlin.de>l  L "Phillip Helbig---remove CLOTHES to reply" <helbig@astro.multiCLOTHESvax.de>1 schreef in bericht news:bm8s6k$dnl$1@online.de... E > In article <bm8nnk$kkpv0$1@ID-143435.news.uni-berlin.de>, "H Vlems"y" > <hvlems.nieuw@zonnet.nl> writes: >eL > > Interesting question. My initial reaction to the question was that you'd endiJ > > up with the same situation as running BACKUP/IMAGE/IGNORE=INTERLOCK on the.J > > disk. The only difference being that backup takes time to complete and the A > > actual on-disk state of an open file is never known for sure.  > C > Right, it's faster.  (Well, when I replace the disk I remove withhE > another one, a shadow copy will happen, but I don't care about that % > since I don't have to wait for it.)e  % OK, that's something I can relate to.c   >h [database stuff removed] >mI > > But perhaps you could elaborate on what you consider "side effects" ?  > C > I'm mainly concerned with cloning system disks.  That is, after aoJ > successful upgrade when I have a valid shadow set, remove one member andJ > use it for the system disk on another machine, replacing it with a freshG > disk (which will be the target of a shadow copy).  There are a lot of I > open files on a system disk, but presumably most of these are just opend? > for reading.  I'm sure they don't change on disk under normal G > circumstances; the question is if they can become corrupted when I do G > the dismount.  (There are also log files open, but I don't care about0G > these since they are of no interest on the other machine.  SYSUAF etc:% > are not on the system disk at all.)a  I On a quiescent system only OPERATOR.LOG and the event log are written to.iI Part of the data may remain in cache and thus missing on the disk. If youd5 want to create clones then that shouldn't bother you.p >nG > The other alternative, of course, is to shut down the system, replaceiJ > one of the disks, and reboot.  It means an additional reboot.  Actually,H > with a three-node cluster, this is not really a problem.  It does take > more time, though. >BG > Now that I think about it, perhaps the best thing to do is, after theuG > upgrade, move to a THREE-member shadow set.  That way, if I shut downeI > the system, remove a disk and reboot, I end up with a two-member shadows3 > set (which is what I want) without a shadow copy!i   Correct. >mD > This leads to another question: can I have one of the members of aH > SYSTEM-DISK shadow set be directly connected to another machine in theH > cluster (even one with different architecture) and only MSCP served toJ > the system using it as a system disk, as long as I add this member afterH > all machines in the cluster are up and running (or at least if I don'tG > boot from it)?  If I can do this, the extra reboot would be worth theo0 > trouble of avoiding an additional shadow copy. > F AFAIK host based shadowsets cannot be MSCP served. The DSA devices areL listed without an ALLOCLASS prefix. If you use a shadowset member all by itsJ own then VMS will mount that volume read-only. No idea how VMS would react; when it encounters such an isolated member as a systemdisk.    ------------------------------  + Date: Sat, 11 Oct 2003 15:03:01 +0000 (UTC) P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)Q Subject: Re: How clean is the snapshot when dismounting a member of a shadow set?w$ Message-ID: <bm9635$qet$1@online.de>  C In article <bm93cn$k0cmo$1@ID-143435.news.uni-berlin.de>, "H Vlems"y! <hvlems.nieuw@zonnet.nl> writes: h  F > > This leads to another question: can I have one of the members of aJ > > SYSTEM-DISK shadow set be directly connected to another machine in theJ > > cluster (even one with different architecture) and only MSCP served toL > > the system using it as a system disk, as long as I add this member afterJ > > all machines in the cluster are up and running (or at least if I don'tI > > boot from it)?  If I can do this, the extra reboot would be worth thev2 > > trouble of avoiding an additional shadow copy. > >yH > AFAIK host based shadowsets cannot be MSCP served. The DSA devices areN > listed without an ALLOCLASS prefix. If you use a shadowset member all by itsL > own then VMS will mount that volume read-only. No idea how VMS would react= > when it encounters such an isolated member as a systemdisk.s  E Right, shadow sets cannot be MSCP served.  However, the members of a  C shadow set can be MSCP served.  That's what I mean here.  I have a iD shadow set like this, one member on a VAX and one on an ALPHA.  The I shadow set is mounted on these two nodes and on an additional VAX.  (See M' the output from $ SHOW DEVICE D below.).  C I'm thinking of something similar here.  Now, with the system-disk  H shadow set, both members have a direct connection to the node it is the D system disk for.  Suppose that when things are up and running, I do  something like  N   $ MOUNT/SYSTEM DSA133:/SHADOW=($33$DKA100:,$33$DKA600:,$44$DKA100:) ALPHASYS  H but only on the machine with ALLOCLASS=33 (GLADIA in the example below, * which is an ALPHA---the others are VAXes).  H It seems to me that $44$DKA100: should be added to the shadow set.  But & I'd like to be sure before I try this!  G What happens if I then shut down the (only) node which has this shadow eH set mounted (normally, all nodes mount it, but I can dismount it on the F other nodes first---no problem since they have no files open on it)?  I Will all three members have equivalent, consistent, clean data after the nH shutdown?  (A related question, out of curiosity and not because I plan F to do it: what would happen when I reboot the system?  Would the MSCP > served third member get added to the shadow set at boot time?)  P ---------8<---------------------------------------------------------------------  P Device                  Device           Error    Volume         Free  Trans MntP  Name                   Status           Count     Label        Blocks Count CntP DSA122:                 Mounted              0  OVMSVAXSYS_2    620523     1   3P DSA133:                 Mounted              0  ALPHASYS_3     3688407   570   3P DSA144:                 Mounted              0  OVMSVAXSYS_4    832524     1   3P DSA510:                 Mounted              0  USER           3216825    35   3. DPA0:         (GLADIA)  Online               0C $5$DIA3:      (DANEEL)  ShadowSetMember      0  (member of DSA122:) P $22$DKA400:   (DANEEL)  Mounted wrtlck       0  VAXVMS073         5265     1   3P $33$DKA0:     (GLADIA)  Mounted              0  SOFT           1126218     7   3C $33$DKA100:   (GLADIA)  ShadowSetMember      0  (member of DSA133:)rC $33$DKA200:   (GLADIA)  ShadowSetMember      0  (member of DSA510:) P $33$DKA300:   (GLADIA)  Mounted              0  DATA           1178660     3   3P $33$DKA400:   (GLADIA)  Mounted wrtlck       0  OVMSDOC071       61179     1   3C $33$DKA600:   (GLADIA)  ShadowSetMember      0  (member of DSA133:)n. $33$DVA0:     (GLADIA)  Online               0. DAD0:         (GLADIA)  Online               0C $44$DKA0:     (ELIJAH)  ShadowSetMember      0  (member of DSA144:)h. $44$DKA100:   (ELIJAH)  Online               0P $44$DKA200:   (ELIJAH)  Mounted              0  SCRATCH         214578     4   3. $44$DKA300:   (ELIJAH)  Online               0C $44$DKA500:   (ELIJAH)  ShadowSetMember      0  (member of DSA510:)u   ------------------------------  % Date: Sat, 11 Oct 2003 19:49:08 +0200 ( From: "H Vlems" <hvlems.nieuw@zonnet.nl>Q Subject: Re: How clean is the snapshot when dismounting a member of a shadow set?e9 Message-ID: <bm9fuf$kk3f1$1@ID-143435.news.uni-berlin.de>.  L "Phillip Helbig---remove CLOTHES to reply" <helbig@astro.multiCLOTHESvax.de>1 schreef in bericht news:bm9635$qet$1@online.de...7E > In article <bm93cn$k0cmo$1@ID-143435.news.uni-berlin.de>, "H Vlems"e" > <hvlems.nieuw@zonnet.nl> writes: >oH > > > This leads to another question: can I have one of the members of aL > > > SYSTEM-DISK shadow set be directly connected to another machine in theL > > > cluster (even one with different architecture) and only MSCP served toH > > > the system using it as a system disk, as long as I add this member after L > > > all machines in the cluster are up and running (or at least if I don'tK > > > boot from it)?  If I can do this, the extra reboot would be worth theh4 > > > trouble of avoiding an additional shadow copy. > > >yJ > > AFAIK host based shadowsets cannot be MSCP served. The DSA devices areL > > listed without an ALLOCLASS prefix. If you use a shadowset member all by itsmH > > own then VMS will mount that volume read-only. No idea how VMS would reactl? > > when it encounters such an isolated member as a systemdisk.i >rF > Right, shadow sets cannot be MSCP served.  However, the members of aD > shadow set can be MSCP served.  That's what I mean here.  I have aE > shadow set like this, one member on a VAX and one on an ALPHA.  TheoJ > shadow set is mounted on these two nodes and on an additional VAX.  (See) > the output from $ SHOW DEVICE D below.)h >rD > I'm thinking of something similar here.  Now, with the system-diskI > shadow set, both members have a direct connection to the node it is the)E > system disk for.  Suppose that when things are up and running, I dou > something like >aG >   $ MOUNT/SYSTEM DSA133:/SHADOW=($33$DKA100:,$33$DKA600:,$44$DKA100:)o ALPHASYS >tI > but only on the machine with ALLOCLASS=33 (GLADIA in the example below,h, > which is an ALPHA---the others are VAXes). > I > It seems to me that $44$DKA100: should be added to the shadow set.  But ( > I'd like to be sure before I try this!  F Not sure I understand your concern here. $44$DKA100: is a datadisk forH GLADIA which does not (have to) know that the other two members use thatK disk as a systemdisk. I did this on a three node VAXcluster where the thirduK (quorum) node mounted a similar shadowset. That way the quorum system couldn? when necessary be used to boot the other VAXes across ethernet.a   >eH > What happens if I then shut down the (only) node which has this shadowI > set mounted (normally, all nodes mount it, but I can dismount it on theeF > other nodes first---no problem since they have no files open on it)?J > Will all three members have equivalent, consistent, clean data after theI > shutdown?  (A related question, out of curiosity and not because I plan G > to do it: what would happen when I reboot the system?  Would the MSCPp@ > served third member get added to the shadow set at boot time?)  L OK, I see what you're driving at and I did not catch up on this point beforeI so my comments may have been completely off up to now. AFAIK only locallygF attached shadowset members of a system disk get mounted automatically.   >nL > ---------8<--------------------------------------------------------------- ------ >nG > Device                  Device           Error    Volume         Free 	 Trans MnteH >  Name                   Status           Count     Label        Blocks	 Count Cnt H > DSA122:                 Mounted              0  OVMSVAXSYS_2    620523 1   3lH > DSA133:                 Mounted              0  ALPHASYS_3     3688407 570   3sH > DSA144:                 Mounted              0  OVMSVAXSYS_4    832524 1   3 H > DSA510:                 Mounted              0  USER           3216825 35   30 > DPA0:         (GLADIA)  Online               0E > $5$DIA3:      (DANEEL)  ShadowSetMember      0  (member of DSA122:)iH > $22$DKA400:   (DANEEL)  Mounted wrtlck       0  VAXVMS073         5265 1   3 H > $33$DKA0:     (GLADIA)  Mounted              0  SOFT           1126218 7   3lE > $33$DKA100:   (GLADIA)  ShadowSetMember      0  (member of DSA133:)tE > $33$DKA200:   (GLADIA)  ShadowSetMember      0  (member of DSA510:)KH > $33$DKA300:   (GLADIA)  Mounted              0  DATA           1178660 3   3 H > $33$DKA400:   (GLADIA)  Mounted wrtlck       0  OVMSDOC071       61179 1   3IE > $33$DKA600:   (GLADIA)  ShadowSetMember      0  (member of DSA133:)h0 > $33$DVA0:     (GLADIA)  Online               00 > DAD0:         (GLADIA)  Online               0E > $44$DKA0:     (ELIJAH)  ShadowSetMember      0  (member of DSA144:) 0 > $44$DKA100:   (ELIJAH)  Online               0H > $44$DKA200:   (ELIJAH)  Mounted              0  SCRATCH         214578 4   3t0 > $44$DKA300:   (ELIJAH)  Online               0E > $44$DKA500:   (ELIJAH)  ShadowSetMember      0  (member of DSA510:)h >    Another I.Asimov fan :-) BTW what is a DPA0: ?e   ------------------------------  % Date: Sat, 11 Oct 2003 10:04:16 +0200a* From: Paul Sture <nospam@sture.homeip.net> Subject: Re: Info about HP0 Message-ID: <3F87D5A0.46863214@sture.homeip.net>   healyzh@aracnet.com wrote: > 0 > David Turner <davidnospam@hpaq_dot_net> wrote:% > > So far I have seen the following:e > J > > 1) Dec parts source - a place where you could buy Digital/Compaq AlphaJ > > spares no longer accept calls outside of their contractual obligation. > D > > 2) HP Field Service can no longer accept ANY purchase orders forA > > product, even when it's not on the standard Compaq price filee > K > > 3) A drove of Authorised Resellers are now losing their "right" to sell  > > Alpha systemsm > F > > 4) Compaq is now plaming off their non service contract stuff to aH > > rather unknown parts reseller (some kind of search company that goes. > > into the market and tacks on a percentage) > M > You know, this is really depressing.  You make me wonder if I don't want to,L > Migrate to something better supported such as OpenBSD or Mac OS X, and I'mO > a Hobbyist!  (Though I have purchased hardware and software from DEC/Compaq).d >   G Well, I currently enjoy my home VMS as a Hobbyist (and it's great beingeG able to explore the layered products i've never had acccess to before),O8 but I have worked with VMS for many years, and still do.  F However, there is a lot of merit in exploring other systems. By way ofH example, when DEC were saying that NT was the future, I went out and gotC an NT system and learnt it. Entering that field with my DEC/IBM/DECnF background (IOW using a disciplined approach) meant that I could standG on level footing with established experts within a matter of weeks. And H before anyone chips in with snide remarks, no, these guys and girls were1 not "Windows Weenies", but serious professionals.r  F But that was a few years ago. Today, I have a Mac laptop, which I haveG grown to like in spite of early mishaps, lack of documentation etc, andn9 am seriously contemplating a desktop OS X system as well."  D That doesn't rule out Solaris either. After all, I have a Wintel boxF here which I refuse to turn on when connected to the outside world ( aF pity, because I have the best newsreader/mail program I have ever comeE across on it). That box is worthless for resale, so I may as well putcE Solaris or *BSD on it to explore those. Wet and cold rainy nights ande" weekends are now here, so why not? -- -   --  
 Paul Sture   ------------------------------  % Date: Sat, 11 Oct 2003 17:48:06 +0100r- From: John Laird <nospam@laird-towers.org.uk> , Subject: Re: Laptop, Reflections, delete key8 Message-ID: <mqcgovon81n1t01s6ihrinofum8inf5pg1@4ax.com>  7 On Fri, 10 Oct 2003 20:46:31 -0500, "David J. Dachtera"x <djesys.nospam@fsi.net> wrote:  " >VAXman-, @SendSpamHere.ORG wrote: >> uG >> Argh!  I have to use a CRAPTOP and it has Reflections.  I can TELNETtF >> to my systems but I can't seem to figure out how to make the delete, >> key send a delete instead of a backspace. >> mG >> I've looked at the keymap stuff and I think I have it setup to map arE >> PeeCee delete to the VT keyboard delete but it still doesn't work.l >> a >> Any pointers? >> vH >> FWIW, this exercise only goes to enforce my disdain for these loathe-H >> some piece of shit toys.  I have diddled about with this cybertoy andH >> its playwarez for hours and still can't do a simple character delete. >uH >Depending what version of WRQ Reflection (singular), Setup -> Terminal,H >click the Keyboard tab, select the radio button that says "VT BackspaceI >sends" (*)Delete. Then, click <OK> and save your settings (File -> Save)M >at some appropriate point.h  F What he said.  You will also find that shift+proper-delete-key sends aI delete character.  (I guess this might flip if you make that radio buttonwL change.)  It is also very worthwhile mapping the E1-E6 keys above the arrowsK if you would prefer to touch-type than work out whether page-up is the same-D as prev and what the hell home and end do.  Key re-mapping is just aI question of clicking on the map button, then the pc keyboard key and then J the required vt keyboard key (all on the dialog).  I also map pause to do.  E Oh, hang on, you said a laptop.  Ah, now you're really struggling :-(o   --   John Mail john rather than nospam...S   ------------------------------  + Date: Sat, 11 Oct 2003 12:33:51 +0000 (UTC)lP From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)Y Subject: looking for free (or very cheap) used hardware in the Dallas/Fort Worth area, 22N$ Message-ID: <bm8tbf$guf$1@online.de>  F I will be in the Dallas/Fort Worth Metroplex area 22--25 October.  My H schedule is very tight, and I am limited by the baggage restrictions of  an intercontinental flight.a  I However, if anyone has any interesting |d|i|g|i|t|a|l| hardware, I might eG be able to come by and pick it up, unfortunately only if it is free or e@ reasonably cheap.  In particular, I'm looking for the following:  @    o  memory for an ALPHAstation 255/233 (I have just 64 MB now)  >    o  lower priority: memory for any of the following systems:         -  VAX 400 100AA         -  VAXstation 4000 90t         -  VAXstation 400 60         -  VAXstation 3100 38          -  VAXstation 3100 30s         -  DEC 3000 600i         -  DEC 3000 300 LX         -  ALPHAserver 2000D         -  ALPHAserver 2100       o  diskso  5       -  SBB-disks: RZ26, RZ28, RZ29 (narrow or wide)   >       -  "internal" disks: 3.5", single height (any capacity),7           5.25", single or double height (any capacity)y  >       -  can be original DEC or compatible (as can the memory)  +    o  DLT drive (SBB or in its own housing)   E    o  SCSI controllers on cards which can be installed in a free slot="       in any of the above machines  F    o  21164 (EV5) or better ALPHA machines (small enough to be allowed?       by the baggage restrictions, even when packed for flight)a   ------------------------------  % Date: Sat, 11 Oct 2003 06:59:14 -0700=6 From: "Doc.Cypher" <Use-Author-Address-Header@[127.1]> Subject: Re: MD5 source code ?6 Message-ID: <200310111359.h9BDxEkx019227@www.aarg.net>  E On Sat, 11 Oct 2003, Mark Daniel <Mark.Daniel@wasd.vsm.com.au> wrote:0 >Doc.Cypher wrote:O >> On Mon, 06 Oct 2003, peter@langstoeger.at (Peter 'EPLAN' LANGSTOEGER) wrote:  >> sM >>>Does anyone have a source code ready which does a MD5 checksum of an inputS4 >>>file and puts the hash/checksum in a DCL symbol ? >>>aP >>>I know I could do it myself but I'm lazy^Wshort of time and ask here first... >> i >> oP >> There's a md5 routine in WASD.  Doesn't put the hash in a symbol, but all the >> hard work is done.e >> dK >> You can find md5.c and md5.h in http://vmsbox.cjb.net/ht_root/src/httpd/m >> s >> HTH >> L >>   >> Doc.a >l2 >It can Doc.  From the prologue of that module ...  * Oh well, learn something new every day. :)     Doc. --  K OpenVMS.         Eight out of ten hackers prefer *other* operating systems.lK [PGP Key via finger]     http://openvms-rocks.com     http://vmsbox.cjb.net    ------------------------------  + Date: Sat, 11 Oct 2003 13:30:26 +0000 (UTC)bP From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply): Subject: NISCS_LOAD_PEA0: confusion in the cluster manual?$ Message-ID: <bm90lh$j4m$1@online.de>   The cluster manual says:  E Caution: If the NISCS_LOAD_PEA0 parameter is set to 1, the VAXCLUSTER E system parameter must be set to 2. This ensures coordinated access tomD shared resources in the OpenVMS Cluster and prevents accidental data corruption.   H This warning is given in Table A-1 both in the section about VAXCLUSTER ) and in the section about NISCS_LOAD_PEA0.a  H I have VAXCLUSTER set to 2 and NISCS_LOAD_PEA0 set to 1 on all systems, 2 so I'm OK. I am confused by the following, though:  D   1-Specifies that the computer should participate in a cluster if H    hardware supporting SCS (CI or DSSI) is present or if NISCS_LOAD_PEA0G    is set to 1, indicating that cluster communications  is enabled overm!    the local area network (LAN). t  H This is from the section on VAXCLUSTER, which also contains the warning C above.  While this description might be true, shouldn't VAXCLUSTER s= always be 2 if NISCS_LOAD_PEA0 is 1, as in the warning above??   ------------------------------  % Date: Sat, 11 Oct 2003 11:44:04 -0500d1 From: "David J. Dachtera" <djesys.nospam@fsi.net>rK Subject: Re: ppp on OpenVMS AlphaServer hardware port for remote gui access ' Message-ID: <3F883354.CE5F1C5F@fsi.net>l   Jim Strehlow wrote:u > 
 > Problem:H > We need help in configuring a PPP TCP/IP connection so that developers	 > can run1F > a Windows-based database GUI browser through a modem connection to a > TTA0:c) > or TTB0: port on an OpenVMS AlphaServern1 > if it is possible and you have already done it.t  . To my knowledge, there are two major problems:  B 1. The TTAx: ports are not capable of high-enough data rates to be	 suitable.c  B 2. TTDRIVER does not provide for sufficient hardware flow control.  F I could be wrong on both of those, but wanted to bring them up anyway.   -- o David J. Dachterae dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/s   ------------------------------  % Date: Sat, 11 Oct 2003 08:40:12 +0200s* From: Paul Sture <nospam@sture.homeip.net>! Subject: Re: Sickening, isn't it?e0 Message-ID: <3F87C1EC.47D5C467@sture.homeip.net>   John Smith wrote:3 >    <snip>  2 > Microsoft Unveils Small Business Server Software > Thu Oct 9, 2:45 PM ET0 >  > ....I > While Linux is free, it requires constant upkeep and maintenance, Ayala.L > said. By contrast, the Small Business Server software, for example, can be# > set up in 15 minutes, Ayala said.f >  > ...more...  ( Excuse me while I step outside and puke.   .  > J > Instead of dedicating different computers to different server tasks, theI > Small Business Server software is designed to be loaded onto one serveroK > computer with networking, e-mail, secure Internet tools, file and printergB > sharing, as well as backup capabilities straight out of the box.  G You'll enjoy this one. IIRC this was written in the NT 4.0 timeframe ore earlier:  ( http://www.taronga.com/~peter/io/nt.html  ( "How to keep a Windows NT server stable"  5 ---------- start quote ------------------------------t  B   During a recent Usenet discussion, I commented that I had littleF difficulty keeping an NT server stable and functioning (as much as the> term can be applied to a Windows box, anyway), and was rightlyH challenged by my fellow Monks to explain just how it was that I was ableF to avoid suffereing the weekly (or more frequent) reboots just to keepC them from chewing up random resources and eating themselves alive. e     This was my response.     (  How to keep a Windows NT server stable.?          1. Don't use an NT server for file and print services.nF          2. Overspec them by at least a decimal order of magnitude: ifG             you were previously running a 486/33 with 8M of RAM, you'lls9             need a K6-2/300 with 128M to do the same job.23          3. Don't run ANY applications on a server. G          4. In fact, don't run more than one thing on a server. If it'ss8             important, split the load between 2 servers.G          5. Don't let point 2 lead you to believe you can neglect pointn 4.E          6. Don't share files from servers you're doing anything elsey on.s             See point 1.A          7. Multiple CPUs help keep the lusers from noticing when  they've done<             something to lock you into a hard infinite loop.E          8. Don't log on to servers. Do everything from workstations.)G          9. You can't do everything from workstations, so apply point 7n soG             you don't bog the machine down when you log on. Don't leaveh             yourself logged in.tC          A. Don't install any 3rd party software. Don't install anya	 MicrosoftgF             software. Only install software you'd use on UNIX systems, like             Apache.aC          B. Reapply service packs constantly. Even if you think you  didn'tH             change anything. Remember, any time it says "For this change toA             take effect you must restart Windows NT." it probablye reinstalled '             something behind your back.bG          C. Don't install more than one kind of hardware device (modem,, scanner,8             printer, etc) on any given box. See point 4.F          D. Don't let any users on the box. Even for a moment. Even if theyG             just want to check the print queue... besides, you disabledm!             printing, didn't you? E          E. Disable write access to anything under %systemroot%. This  will(             break printing. See point 1.H          F. I really mean what I said about the users. Don't let them on theKD             network if you can avoid it. That way they'll never know you'reE             really running a UNIX box because all you were running onk the NT!             box is Apache anyway.e     5 ------------ end quote ------------------------------m     -- o
 Paul Sture   ------------------------------  + Date: Sat, 11 Oct 2003 09:34:46 +0000 (UTC)o! From: Bagbourne <noway@noway.com>o! Subject: Re: Sickening, isn't it?a( Message-ID: <3F87D18F.7060008@noway.com>   Steve Bainbridge wrote:Sx > "John Smith" <a@nonymous.com> wrote in message news:<FLohb.269357$Lnr1.175241@news01.bloor.is.net.cable.rogers.com>... >  > [chop...]m >  > L >>It reads almost exactly like a Microsoft press release, but that's not the@ >>most sickening thing about the following Reuters 'news' story. >>F >>The most sickening thing is that the lame excuse for a VMS MarketingL >>Department does zero, zilch, nichts, nada, zip, gornischt, and squat aboutM >>marketing VMS even when Reuters seems so desperate for material to send outr >>over the newswires.d >  >  > [chop...]s > N > Give Reuters a break. We use loads of Alpha and VAX systems running OpenVMS. >  > Steve   ! I was just about to mention this.l  H Are you still using my "status format" to XML converter to convert from  the $$T $$M $$etc.. format?    Nige   ------------------------------   Date: 11 Oct 03 08:24:26 +0200) From: p_sture@elias.decus.ch (Paul Sture)H Subject: Re: Sun takes a hit) Message-ID: <45lUpOddqHWe@elias.decus.ch>t   In article <blu5jl$osa$1@new-usenet.uk.sun.com>, Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com> writes: > Greg Cagle wrote:  >> Fred Kleinsorge wrote:  >>  ; >>> "Paul Sture" <nospam@sture.homeip.net> wrote in messageH. >>> news:3F7FF321.64F09CCE@sture.homeip.net... >>   >> uE >>>> But this is something I don't get. Why is HP pushing Linux as an K >>>> alternative to Solaris rather than HP-UX, or even, heaven forbid, VMS?w >>>>D >>>> Why not give those away and go for the software maintenance and >>>> consulting revenue? >>>>
 >>>> ????????' >>>>7 >>>> It all sounds like dot com boom economics to me...t >>>>L >>>> Come on Keith, we know you aren't daft. Please explain the economics of >>>> this one. >>>  >>>r >>>bM >>> I don't know the specifics of this, but it would make sense to me to push L >>> Linux or HP-UX as an alternative to Solaris in general - as they are allI >>> more-or-less UNIX.  Trying to push VMS onto a Solaris user is likely H	 >>> to be 2 >>> as popular as pushing Solaris onto a VMS user. >>   >> gE >> It's actually very simple. You flush your $$$ Sun servers down the-A >> toilet and replace them with (perceived) cheap Linux machines.eE >> HP-UX machines are not as cheap, and the migration from Solaris torB >> Linux is less arduous than that from Solaris to HP-UX. Besides,B >> there's always storage and other stuff to think about; many SunB >> installations are set up with direct attached disks that can be7 >> replaced with SAN or NAS boxes as part of the shift.  >> cF >> Also, the migration path depends on the market segment. Some placesH >> Linux doesn't make sense. You can't today replace a UE10K with a rackI >> of Proliants running Linux in any sensible way, for example. And LinuxsK >> doesn't yet scale onto big MP machines. The sweet spot are the thousandseH >> of old 4-8 way Solaris machines that can be outperformed by a two-way  >> Proliant running a "free" OS. >> e > A > Of course you then find that none of your commercial ISV's willw > support "free" Linux.  > @ > That you cannot self support the paid for Linux because if you: > do you violate the terms of your commercial ISV support. > A > And that you naturally progress from Free to the most expensivesA > paid for Linux, Red Hat AS because its the most likely platform  > to be supported by you ISV's.a >o  : Ah. In that light I was too swift to criticise HP's offer.   C > Exentually you realise that Free Linux is in fact Expensive LinuxiC > unless you think that paying 7500K over 3 years for SW support on:% > a box that costs 6K is a good deal.t >   I Do you mean 7500K or just 7500 there? I do have memories of Red Hat abouteM 4 years ago quoting on their website something like USD 50K p.a. for support.tI Of course that was when dot com money was flowing freely, Red Hat had yetoE to make a profit, so it may have been a figure plucked from the etherA4 to make investors think they were onto a good thing.  ( Whatever, it didn't exactly sound cheap.  C > Then IBM GS or HP services who helped you migrate to Linux in the @ > first place (to save you money) ha ha turn up with an offer to: > help you consolidate all those little Linux boxes onto aA > pSeries/zSeries/SuperDome (something with a commercial strengthiB > OS with resource management etc etc) to save you money ha ha ha. > J Andrew, that makes eminent sense. Thanks, it's a compelling argument _for_ HP's offer.   F Just for the record, I will say I have tried various flavours of LinuxF at home. I liked it for the vast array of utilities that came with theG CD sets, but as discussed here, that doesn't make the essential core oftI Linux necessarily the best flavour of *nix. The publicity and availabiltyrG on the high street is great, but I'll tell you now that the Red Hat 6.naM documentation was a disgrace, SuSE 7.n was excellent (except that configuringeA the networking was extremely labour intensive), with far superiorgK documentation. SuSE 8.0 and 8.2 also had great documentation but as shippedaM were so broken I simply gave up. At 40-50 quid a shot (for SuSE - Red Hat 6.nt8 was a _lot_ more expensive than that), I could afford to  just write it off to experience.    @ Now, comparing Linux with the Tru64 man pages and documentation,@ I came to the conclusion that Linux could be (sort of) fine, butD a reasonably fast Internet "always on" Internet connection is pretty) mandatory to get the info that's missing.e  G In contrast, with Tru64 I could probably get to grips with it using the / printed documentation and (superior) man pages.a  G I believe you are correct to point out that in spite of the hype, LinuxaF is far from "free", but any manufacturer who chooses to ignore all the& free publicity does so at their peril.   ------------------------------  % Date: Sat, 11 Oct 2003 13:00:12 +0200o9 From: Jan-Erik =?iso-8859-1?Q?S=F6derholm?= <aaa@aaa.com>eF Subject: Re: The VAX/VMS to Itanium Migration Letter, Vol. 1 Number 1.' Message-ID: <3F87E2BC.4ED7D024@aaa.com>   
 Looks great !S Havn't had time to read yet :-)d  	 Jan-Erik.a   Didier Morandi wrote:e > 8 > http://www.didiermorandi.com/vaxvms2itanium_200310.pdf > (English, 8 pages) > 2 > Feedback welcome: mailto:didiermorandi@nerim.net
 > Danke schn  > Thank your > Merci. >  > D.   ------------------------------  + Date: Sat, 11 Oct 2003 15:41:49 +0000 (UTC)bP From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)) Subject: What does MSCP_SERVE_ALL=4 mean?4$ Message-ID: <bm98bt$sdg$1@online.de>  I As I understand it, MSCP_SERVE_ALL can take on the values 0, 1 and 2.  I bD have it hard-coded to 1 in MODPARAMS.DAT on all nodes on my cluster.  ; When running AUTOGEN, I see the following on the VAX nodes:g  I         Override Information - parameter calculation has been overridden. ;            The calculated value was 4.  The new value is 1. D            MSCP_SERVE_ALL has been set to the hard-coded value of 1.  8 Why does it want to set it to 4 and what does this mean?  C One VAX is at 7.2, the other at 7.3.  The documentation is 7.1.  (IE@ think this was the last documentation CD where everything was inD BOOKREADER format (which is why I use it)---please correct me if I'm wrong!)   I It is possible to have MSCP_LOAD > 1, and the docs recommend starting at  H 4 if one increases this.  Thus, at first, this is what I thought it was + doing, but it is definitely MSCP_SERVE_ALL.r  D While I'm on the topic of MODPARAMS.DAT, I found these things which E I've had in there for a long time but don't remember the reasons for "F putting them in (I now include comments!).  Does anyone have any idea < a) why I could have done this and b) whether it makes sense?   On an ALPHAstation 255/233:d   MIN_MAXPROCESSCNT=100 	 QUANTUM=2t   On some VAXes:   WINDOW_SYSTEM=1h  ' Also, on a VAX 4000 100 A I have added:d  " ! change to at leasts 12 for tcpip( MIN_INTSTKPAGES=18 ! after first install  B I did a completely fresh install of VMS 7.3 on this machine, also H installing TCPIP, and the TCPIP startup failed, complaining about a too F low value for INSTKPAGES.  Should the installation set this parameter  higher by default?   ------------------------------  % Date: Sat, 11 Oct 2003 19:16:45 +0200t( From: "H Vlems" <hvlems.nieuw@zonnet.nl>- Subject: Re: What does MSCP_SERVE_ALL=4 mean? 9 Message-ID: <bm9e1n$k5ral$1@ID-143435.news.uni-berlin.de>   % $ mc sysgen help sys_param mscp_serve C produced a lot of output on an AXP/VMS V7.3 system, but a fragment:h  C Bit 2           Serve the system disk. This is the default setting. A      (4)        This setting is important when other nodes in theaE                   cluster rely on this system being able to serve itseG                   system disk. This setting prevents obscure contentioneC                   problems that can occur when a system attempts tohG                   complete I/O to a remote system disk whose system haso                   failed.b  L "Phillip Helbig---remove CLOTHES to reply" <helbig@astro.multiCLOTHESvax.de>1 schreef in bericht news:bm98bt$sdg$1@online.de...oJ > As I understand it, MSCP_SERVE_ALL can take on the values 0, 1 and 2.  IF > have it hard-coded to 1 in MODPARAMS.DAT on all nodes on my cluster. > = > When running AUTOGEN, I see the following on the VAX nodes:  >IK >         Override Information - parameter calculation has been overridden.a= >            The calculated value was 4.  The new value is 1.rF >            MSCP_SERVE_ALL has been set to the hard-coded value of 1. >p: > Why does it want to set it to 4 and what does this mean? >DE > One VAX is at 7.2, the other at 7.3.  The documentation is 7.1.  (IsB > think this was the last documentation CD where everything was inF > BOOKREADER format (which is why I use it)---please correct me if I'm	 > wrong!)m >kJ > It is possible to have MSCP_LOAD > 1, and the docs recommend starting atI > 4 if one increases this.  Thus, at first, this is what I thought it wasO- > doing, but it is definitely MSCP_SERVE_ALL.n >hE > While I'm on the topic of MODPARAMS.DAT, I found these things which$F > I've had in there for a long time but don't remember the reasons forG > putting them in (I now include comments!).  Does anyone have any ideat> > a) why I could have done this and b) whether it makes sense? >h > On an ALPHAstation 255/233:t >n > MIN_MAXPROCESSCNT=100  > QUANTUM=2  >  > On some VAXes: >e > WINDOW_SYSTEM=1P >r) > Also, on a VAX 4000 100 A I have added:  >k$ > ! change to at leasts 12 for tcpip* > MIN_INTSTKPAGES=18 ! after first install >iC > I did a completely fresh install of VMS 7.3 on this machine, also I > installing TCPIP, and the TCPIP startup failed, complaining about a toodG > low value for INSTKPAGES.  Should the installation set this parameterD > higher by default? >w   ------------------------------  % Date: Sat, 11 Oct 2003 19:22:27 +0200 $ From: Michael Unger <unger@decus.de>- Subject: Re: What does MSCP_SERVE_ALL=4 mean?o9 Message-ID: <bm9elb$k8s5j$1@ID-152801.news.uni-berlin.de>s  F On 2003-10-11 17:41, "Phillip Helbig---remove CLOTHES to reply" wrote:  K > As I understand it, MSCP_SERVE_ALL can take on the values 0, 1 and 2.  I sF > have it hard-coded to 1 in MODPARAMS.DAT on all nodes on my cluster. > = > When running AUTOGEN, I see the following on the VAX nodes:o > K >         Override Information - parameter calculation has been overridden.t= >            The calculated value was 4.  The new value is 1.tF >            MSCP_SERVE_ALL has been set to the hard-coded value of 1. > : > Why does it want to set it to 4 and what does this mean?  H >From the "OpenVMS System Management Utilities Reference Manual", Vol 2,: Section C.2, page C-35, "System Parameters", Descriptions:   | Bit 0 (1)HH | Serve all available disks (locally attached and those connected to HSxG | and DSSI controllers). Disks with allocation classes that differ fromhF | the system’s allocation class (set by the ALLOCLASS parameter) are" | also served if bit 3 is not set. |i | Bit 1 (2)d2 | Serve locally attached (non-HSx and DSSI) disks. |e | Bit 2 (4) E | Serve the system disk. This is the default setting. This setting istE | important when other nodes in the cluster rely on this system beingiI | able to serve its system disk. This setting prevents obscure contentionyE | problems that can occur when a system attempts to complete I/O to a - | remote system disk whose system has failed.- |- | Bit 3 (8)-F | Restrict the serving specified by bit 0. All disks except those withM | allocation classes that differ from the system’s allocation class (set by & | the ALLOCLASS parameter) are served.D | This is pre-Version 7.2 behavior. If your cluster includes systemsG | running OpenVMS 7.1-x or earlier, and you want to serve all availableSF | disks, you must specify 9, the result of setting this bit and bit 0.   andS  C | Although the serving types are now implemented as a bit mask, the  values of 0,I | 1, and 2, specified by bit 0 and bit 1, retain their original meanings:5E | * 0 — Do not serve any disks (the default for earlier versions of$	 OpenVMS).D$ | * 1 — Serve all available disks.C | * 2 — Serve only locally attached (non-HSx and non-DSSI) disks. D | If the MSCP_LOAD system parameter is 0, MSCP_SERVE_ALL is ignored.    E > One VAX is at 7.2, the other at 7.3.  The documentation is 7.1.  (ImB > think this was the last documentation CD where everything was inF > BOOKREADER format (which is why I use it)---please correct me if I'm
 > wrong!)   F The current (7.3 as well as 7.3-1) documentation is available from the* HP web site. I prefer using the PDF files.  K > It is possible to have MSCP_LOAD > 1, and the docs recommend starting at  J > 4 if one increases this.  Thus, at first, this is what I thought it was - > doing, but it is definitely MSCP_SERVE_ALL.   " Same document as above, page C-34:   | 0 9 | Do not load the MSCP server. This is the default value.E |A | 1n: | Load the MSCP server and serve disks as specified by the | MSCP_SERVE_ALL parameter.u    F > While I'm on the topic of MODPARAMS.DAT, I found these things which G > I've had in there for a long time but don't remember the reasons for  H > putting them in (I now include comments!).  Does anyone have any idea > > a) why I could have done this and b) whether it makes sense? >  > On an ALPHAstation 255/233:m >  > MIN_MAXPROCESSCNT=100n  " Same document as above, page C-29:  C | MAXPROCESSCNT sets the number of process entry slots allocated ats	 bootstrapmG | time. One slot is required for each concurrent process on the system. 	 Each sloto2 | requires 6 bytes of permanently resident memory. |eE | The default value is normally configured to allow you to create thed desiredaD | number of processes. If the following message appears, you need to increase the | value of MAXPROCESSCNT:  |e, | %SYSTEM-F-NOSLOT, No PCB to create process     > QUANTUM=2   " Same document as above, page C-49:    | QUANTUM defines the following: |uJ | * Processor time: maximum amount of processor time a process can receiveD | before control passes to another process of equal priority that is ready to	 | computew |oL | * Balance set residency: minimum amount of service a compute-state process< | must receive before being swapped out to secondary storage     > On some VAXes: >  > WINDOW_SYSTEM=1a  " Same document as above, page C-74:   | 1a@ | Load the DECwindows Motif for OpenVMS workstation environment. |s | 2n' | Load the UIS workstation environment..    ) > Also, on a VAX 4000 100 A I have added:o > $ > ! change to at leasts 12 for tcpip* > MIN_INTSTKPAGES=18 ! after first install  " Same document as above, page C-23:  L | (VAX only) INTSTKPAGES sets the size of the interrupt stack in pages. EachE | page on the interrupt stack requires a page of permanently residente memory.t |nH | Use the default value of 6 unless interrupt-stack-not-valid exceptions occur.G | These may be caused by either an unusually large number of devices or: a driver. | that requires a large amount of stack space.    D > I did a completely fresh install of VMS 7.3 on this machine, also J > installing TCPIP, and the TCPIP startup failed, complaining about a too H > low value for INSTKPAGES.  Should the installation set this parameter  > higher by default?     Michaeln   -- r; Real names enhance the probability of getting real answers. @ Please do *not* send "Security Patch Notifications" or "SecurityA Updates"; this system isn't running a Micro$oft operating system.n= And don't annoy me <mailto:postmaster@[127.0.0.1]> please ;-)l   ------------------------------  + Date: Sat, 11 Oct 2003 12:35:57 +0000 (UTC)tP From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)8 Subject: where to buy memory for |d|i|g|i|t|a|l| systems$ Message-ID: <bm8tfd$guf$2@online.de>  ? I'm looking to buy some additional memory, particularly for an  H ALPHAstation 255/233.  Can anyone recommend somewhere where I can order H the stuff online, pay by credit card, be 100% sure that what I get will I work, have it shipped to Germany with no hassle or exhorbitant cost, and d get it for a reasonable price?  B What IS a reasonable price for DEC(-compatible) memory these days?   ------------------------------  % Date: Sat, 11 Oct 2003 17:53:02 +0100K- From: John Laird <nospam@laird-towers.org.uk> < Subject: Re: where to buy memory for |d|i|g|i|t|a|l| systems8 Message-ID: <m5dgovsvv30fp5aaq09arc9hhshlpotskq@4ax.com>  I On Sat, 11 Oct 2003 12:35:57 +0000 (UTC), helbig@astro.multiCLOTHESvax.de 1 (Phillip Helbig---remove CLOTHES to reply) wrote:t  @ >I'm looking to buy some additional memory, particularly for an I >ALPHAstation 255/233.  Can anyone recommend somewhere where I can order SI >the stuff online, pay by credit card, be 100% sure that what I get will  J >work, have it shipped to Germany with no hassle or exhorbitant cost, and  >get it for a reasonable price?   J Philip, we used to get compatible memory from a company called Transtec inH the UK.  I'm fairly sure they have a significant presence in Germany andF Holland.  However, 255s are getting long in the tooth and many genericH suppliers may not bother to hold stock any more.  I think these machinesJ took memory that was still a bit "different"  (ecc if I remember rightly).H It is usually quite easy to locate a Kingston compatible part number andI search the web for that as well.  (Or obviously try Kingston themselves.)   C >What IS a reasonable price for DEC(-compatible) memory these days?   9 Well, that depends whether you are buying or selling :-))$   --   John Mail john rather than nospam...m   ------------------------------   End of INFO-VAX 2003.564 ************************