1 INFO-VAX	Tue, 11 Apr 2006	Volume 2006 : Issue 201       Contents: ANN: soyMAIL v1.0 released Re: ANN: soyMAIL v1.0 released' Cluster , locks and lock granting order + Re: Cluster , locks and lock granting order + Re: Cluster , locks and lock granting order  Re: DECnet IV routing errors DS10 April Special Re: DSPP and OpenVMS media Re: DSPP and OpenVMS media. Re: Getting the remote address for SET DISPLAY. Re: Getting the remote address for SET DISPLAY' Re: OpenVMS is the worlds best desktop! ' Re: OpenVMS is the worlds best desktop! " Re: Shadowed System disk questions" Re: Shadowed System disk questions" Re: Shadowed System disk questions" Re: Shadowed System disk questions Re: TCPIP$SMTP_POSTMASTER_ALIAS  Re: Using the Serial Terminal  Re: Using the Serial Terminal  Re: VAMP board changes  F ----------------------------------------------------------------------  % Date: Wed, 12 Apr 2006 00:09:44 +0930 * From: Mark Daniel <mark.daniel@vsm.com.au># Subject: ANN: soyMAIL v1.0 released 0 Message-ID: <123njdgauei5l6c@corp.supernews.com>  $ As recently announced on OpenVMS.org  <    http://www.openvms.org/stories.php?story=06/04/10/4433222   soyMAIL v1.0 has been released.   * Thanks to all those who help BETA test it.   ------------------------------    Date: 11 Apr 2006 10:38:59 -0700( From: "Rich Jordan" <jordan@ccs4vms.com>' Subject: Re: ANN: soyMAIL v1.0 released B Message-ID: <1144777139.051760.38480@u72g2000cwu.googlegroups.com>  B Thanks, Mark!  Really looking forward to trying it now that my new1 DS10L webserver/mailserver box is up and running.    ------------------------------  % Date: Tue, 11 Apr 2006 03:40:34 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 0 Subject: Cluster , locks and lock granting order, Message-ID: <443B5D42.BB39CC99@teksavvy.com>  A OK, say you have a 4 node cluster, node1 through node4, with each  running the same application.   ? I want to distribute processing AND provide automatic failover.   8 So, the configuration would stipulate for instance that   H "chocolate type"  requests would be handled primarily by the app runningF on NODE1, fail over to NODE2, fail over to NODE3 and finally, when all, other nodes are down, NODE4 would handle it.  A (different request types would be handled by different nodes with  different failover order).  H With $ENQ, to achieve this, it is correct to state that the applicationsD would have to each do the $ENQ in the the order NODE1, NODE2, NODE3,. NODE4 to achieve the desired failover effect ?  F Is there a way to prioritise $ENQs so that even if NODE2 registers itsH $ENQ late, it would still be the first to be given the lock should NODE1 fail ?  F Also, when the application starts, is there a way for it to get a listH of processes that either hold the lock or have a pending request to hold3 that lock ? (remembering that this is on a cluster)   F If all processes $ENQ with a NULL MODE (LCK$L_NLMODE), does it make itC easier to get the list of processes with an interest in that lock ?     H Also, given a process PID, is there a way to get the cluster node name ?E I looked at the item codes from $GETJPI and I didn't see an item code ? (or was this added since the last grey wall was printed (5.5) ?    ------------------------------  + Date: Tue, 11 Apr 2006 09:40:18 +0000 (UTC) . From: klewis@LUMINA.MITRE.ORG (Keith A. Lewis)4 Subject: Re: Cluster , locks and lock granting order. Message-ID: <e1fti2$4b1$1@newslocal.mitre.org>   JF Mezei <jfmezei.spamnot@teksavvy.com> writes in article <443B5D42.BB39CC99@teksavvy.com> dated Tue, 11 Apr 2006 03:40:34 -0400: B >OK, say you have a 4 node cluster, node1 through node4, with each >running the same application. > @ >I want to distribute processing AND provide automatic failover.  I Distributed processing sounds like a job for a generic queue, not a lock.   I You can have one generic queue feed into an execution queue on each node. J I *think* the queue manager uses the first non-busy queue in the generic's list.   9 >So, the configuration would stipulate for instance that   > I >"chocolate type"  requests would be handled primarily by the app running G >on NODE1, fail over to NODE2, fail over to NODE3 and finally, when all - >other nodes are down, NODE4 would handle it.  > B >(different request types would be handled by different nodes with >different failover order).  > I >With $ENQ, to achieve this, it is correct to state that the applications E >would have to each do the $ENQ in the the order NODE1, NODE2, NODE3, / >NODE4 to achieve the desired failover effect ?  > G >Is there a way to prioritise $ENQs so that even if NODE2 registers its I >$ENQ late, it would still be the first to be given the lock should NODE1  >fail ?   B Have NODE3 and NODE4 $DEQ their place in line and then $ENQ again.  G >Also, when the application starts, is there a way for it to get a list I >of processes that either hold the lock or have a pending request to hold 4 >that lock ? (remembering that this is on a cluster)   See $GETLKI.  G >If all processes $ENQ with a NULL MODE (LCK$L_NLMODE), does it make it D >easier to get the list of processes with an interest in that lock ? >  > I >Also, given a process PID, is there a way to get the cluster node name ? F >I looked at the item codes from $GETJPI and I didn't see an item code@ >(or was this added since the last grey wall was printed (5.5) ?   JPI$_NODENAME should do it.   0 --Keith Lewis              klewis {at} mitre.org> The above may not (yet) represent the opinions of my employer.   ------------------------------  % Date: Tue, 11 Apr 2006 07:39:57 -0500 ' From: "Earl Lakia" <elakia@hotmail.com> 4 Subject: Re: Cluster , locks and lock granting order0 Message-ID: <xs2dnRbqvaYSPqbZRVn-pw@comcast.com>  I I would think a cluster wide messaging service like IQR would make a nice J solution.  The message queue would cluster wide and each member would read8 a message from the queue.    Anyway, that's what we did.   -earl   : "JF Mezei" <jfmezei.spamnot@teksavvy.com> wrote in message& news:443B5D42.BB39CC99@teksavvy.com...C > OK, say you have a 4 node cluster, node1 through node4, with each  > running the same application.  > A > I want to distribute processing AND provide automatic failover.  > 9 > So, the configuration would stipulate for instance that  > J > "chocolate type"  requests would be handled primarily by the app runningH > on NODE1, fail over to NODE2, fail over to NODE3 and finally, when all. > other nodes are down, NODE4 would handle it. > C > (different request types would be handled by different nodes with  > different failover order). > J > With $ENQ, to achieve this, it is correct to state that the applicationsF > would have to each do the $ENQ in the the order NODE1, NODE2, NODE3,0 > NODE4 to achieve the desired failover effect ? > H > Is there a way to prioritise $ENQs so that even if NODE2 registers itsJ > $ENQ late, it would still be the first to be given the lock should NODE1 > fail ? > H > Also, when the application starts, is there a way for it to get a listJ > of processes that either hold the lock or have a pending request to hold5 > that lock ? (remembering that this is on a cluster)  > H > If all processes $ENQ with a NULL MODE (LCK$L_NLMODE), does it make itE > easier to get the list of processes with an interest in that lock ?  >  > J > Also, given a process PID, is there a way to get the cluster node name ?G > I looked at the item codes from $GETJPI and I didn't see an item code A > (or was this added since the last grey wall was printed (5.5) ?    ------------------------------  % Date: Tue, 11 Apr 2006 10:48:00 +0100 * From: "Richard Brodie" <R.Brodie@rl.ac.uk>% Subject: Re: DECnet IV routing errors 2 Message-ID: <e1fu0g$q09$1@blackmamba.itd.rl.ac.uk>  1 "Chris Moore" <no.one@no.where> wrote in message  3 news:nEw_f.2256$%U2.148306@news20.bellglobal.com...   M >I understand the adjacency down mechanism, just not really how it appears to  > lose adjacency to ITSELF.   H Not really a DECnet expert but it seems possible that something externalJ bounced its own hello packets back at it. It would then see itself one hop away.    ------------------------------  % Date: Tue, 11 Apr 2006 11:21:22 -0400 C From: "David Turner, Island Computers US Corp" <dbturner@icusc.com>  Subject: DS10 April Special 7 Message-ID: <%KP_f.6735$A41.476@bignews5.bellsouth.net>    Special this month  = We have 50 systems in stock and we NEED to sell some of these      Alphaserver DS10 466Mhz EV6  1GB Compaq Memory 5 Front Access Storage U160 Cage for two hot plug disks ! Dual Channel U160 Disk Controller + Dual 36GB 10KRPM U160 Compaq Hot Plug Disks  ATI Radeon 7500 Graphics Card  Dual 10/100 Ethernet Dual Serial Port   Total US$ 3575   Alphaserver DS10 617Mhz EV67 1GB Compaq Memory 5 Front Access Storage U160 Cage for two hot plug disks ! Dual Channel U160 Disk Controller + Dual 36GB 10KRPM U160 Compaq Hot Plug Disks  ATI Radeon 7500 Graphics Card  Dual 10/100 Ethernet Dual Serial Port    Total US$ 4375 + $55 US shipping   International shipping   Canada: $110# Western Europe and Scandinavia $160  Australasia $190     1 Year Island warranty) Systems can go on HP maintenance contract    Call or email for more info    --     David B Turner Island Computers US Corp 2700 Gregory St, Suite 180 Savannah GA 31404  Tel: 912 447 6622 X201 Cell: 912 447 6622 X252  Fax: 912 201 0402  Email: dbturner@icusc.com  Web: http://www.islandco.com% ===================================== < All orders are subject to the following terms and conditions. of sale. These should be read before ordering.% http://www.islandco.com/warranty.html    ------------------------------  # Date: Tue, 11 Apr 2006 14:13:23 GMT ( From: Mark Schafer <mark.schafer@hp.com># Subject: Re: DSPP and OpenVMS media 2 Message-ID: <7QO_f.6145$WA4.2156@news.cpqcorp.net>   Rich,   E Yes, it's true we ended the SDK subscription program.  I've tried to  G blunt the impact by getting permission to put the VMS compilers on the   DSPP portal.  PAKs too.   I The goal these days is to promote self-service on DSPP.  The SDK program  H cost more to maintain than the media itself.  The cost of putting stuff E on the portal is mostly me!  I ZIP the kits and verify the downloads.   E Login to www.hp.com/dspp, then select Partner Resources and Software  6 Downloads.  You'll find Alpha and Integrity compilers.   Mark   ------------------------------  % Date: Tue, 11 Apr 2006 07:34:25 -0700 # From: "Tom Linden" <tom@kednos.com> # Subject: Re: DSPP and OpenVMS media ) Message-ID: <op.s7ulfnlzzgicya@hyrrokkin>   H On Tue, 11 Apr 2006 07:13:23 -0700, Mark Schafer <mark.schafer@hp.com>   wrote:   > Rich,  > H > Yes, it's true we ended the SDK subscription program.  I've tried to  J > blunt the impact by getting permission to put the VMS compilers on the   > DSPP portal.  PAKs too.  > L > The goal these days is to promote self-service on DSPP.  The SDK program  K > cost more to maintain than the media itself.  The cost of putting stuff   G > on the portal is mostly me!  I ZIP the kits and verify the downloads.  > H > Login to www.hp.com/dspp, then select Partner Resources and Software  8 > Downloads.  You'll find Alpha and Integrity compilers. >  > MarkI Since we are no longer getting the quarterly updates, there is no cover    letterI that contains the next quarters ID and PASSWD for downloads.  How do we   	 get that?  Or have I missed something   Tom    ------------------------------  % Date: Tue, 11 Apr 2006 08:48:26 -0400 # From: sol gongola <sol@adldata.com> 7 Subject: Re: Getting the remote address for SET DISPLAY 0 Message-ID: <1144759722.443130@nntp.acecape.com>   Z wrote:
 > Z wrote:0 >>> $ remnode = F$TRNLNM ("SYS$REM_NODE") - "::"I >>> $ SETDISP     :== "SET DISPLAY /CREATE /NODE = " 'remnode /TRANSPORT   >>> = tcpip  >>, >> I don't have that logical [SYS$REM_NODE]. > " > Where does SYS$REM_NODE get set? > 9 > I'm using Excursion to access my VMS systems from a PC.  > I > When I access my 7.1-2 system with Excursion, SYS$REM_NODE is set to a  K > large number that can be broken down into 4 hex bytes that represent the   > IP of the client.  > J > When I access the 7.3-2 system - on the same subnet as the 7.1-2 system > > and with the same client - there is no SYS$REM_NODE logical. > I > The access method in the Excursion client (on the PC) is set to REXEC.  J > Could this be a problem with the way the REXEC service is configured on  > the 7.3-2 system?     G SYS$REM_NODE, the name of the connecting host, is most likely set using J name resolution (bind). One of your machines may not have it set properly.  G Also, a google search showed that some versions of vms tcpip had issues - with sys$rem_node and needed patches applied.   E Try "tcpip (or ucx) show host" for the ip address in question and the ) node name and see if they work correctly.   F Also, try :show log *rem* and see what you get for the other logicals.   regards  sol  sol    ------------------------------  # Date: Tue, 11 Apr 2006 13:59:30 GMT F From: lederman@star.enet.dec.DISABLE-JUNK-EMAIL.com (Bart Z. Lederman)7 Subject: Re: Getting the remote address for SET DISPLAY , Message-ID: <6DO_f.40$S4.36@news.oracle.com>  : In article <FQE_f.7$Va1.3@fe04.lga>, Z <Z@ids.net> writes:	 >Z wrote: 0 >>> $ remnode = F$TRNLNM ("SYS$REM_NODE") - "::"K >>> $ SETDISP     :== "SET DISPLAY /CREATE /NODE = " 'remnode /TRANSPORT =  	 >>> tcpip  >>  , >> I don't have that logical [SYS$REM_NODE]. > ! >Where does SYS$REM_NODE get set?  > 8 >I'm using Excursion to access my VMS systems from a PC. > H >When I access my 7.1-2 system with Excursion, SYS$REM_NODE is set to a J >large number that can be broken down into 4 hex bytes that represent the  >IP of the client. > I >When I access the 7.3-2 system - on the same subnet as the 7.1-2 system  = >and with the same client - there is no SYS$REM_NODE logical.  > H >The access method in the Excursion client (on the PC) is set to REXEC. I >Could this be a problem with the way the REXEC service is configured on   >the 7.3-2 system? >   ? I believe it's set by LOGINOUT.  I don't have Excursion or some : similar product to test with where I am currently located.   ------------------------------    Date: 11 Apr 2006 08:04:58 -0700- From: "Andrew" <andrew_harrison@symantec.com> 0 Subject: Re: OpenVMS is the worlds best desktop!C Message-ID: <1144767898.929841.172850@e56g2000cwe.googlegroups.com>    JF Mezei wrote:  > Andrew wrote: K > > Its pretty clear that Sun want to capture developers, students etc onto J > > Solaris make it easy for them to learn and develop new products on theI > > platform and then charge them to support the platform when it is used  > > to deploy commercial apps. >  > J > The VMS hobbyist programme was way ahead of Sun in that respect. The bigG > difference is that Sun made a lot of noise about Solaris going "free"  > and allows commercial use. >    Sort of.? "The OpenVMS  Hobbyist Program is a program from HP and OpenVMS D engineering that enables OpenVMS enthusiasts throughout the world toE obtain OpenVMS Operating System Licenses and over 100 OpenVMS layered E products  for their VAX, Alpha or Itanium hardware for Individual use  and education."   E It is not for commercial use and thats the crucial difference between F Solaris and OpenVMS because there is no such restriction on the use of6 free to download Solaris and the accompanying toolsets   regards  Andrew Harrrison   ------------------------------    Date: 11 Apr 2006 08:55:58 -0700 From: etmsreec@yahoo.co.uk0 Subject: Re: OpenVMS is the worlds best desktop!C Message-ID: <1144770958.110400.145720@g10g2000cwb.googlegroups.com>   < Andrew's right.  The VMS hobbyist is for non-commercial use.  E One thing I would pick up on with this whole thread though is that if D you buy an AlphaServer in the UK now and over the past few years youE can get a free unlimited user VMS license with it as well.  So, a new ; AlphaServer costs you whatever the list price is with those G complimentary products (TCP/IP Services, DECnet end node, DW-Motif etc) > and the options that you want and that's that.  You want it on& maintenance then that's another story.   Steve    ------------------------------  % Date: Tue, 11 Apr 2006 02:57:55 -0400 ' From: Dave Froble <davef@tsoft-inc.com> + Subject: Re: Shadowed System disk questions 9 Message-ID: <19ydnUwmSt96z6bZnZ2dnUVZ_vadnZ2d@libcom.com>   , Alan Winston - SSRL Central Computing wrote: > VMS 7.3-2  > DS20E  > AlphaServer 800  >  > RA7000 disk array  > EVA4000 SAN disk array > M > (The DS20E and AS800 share a SCSI connection to the RA7000.  Only the DS20E K > has a Fibre Channel interface to the EVA.  [There's also an RX2600 in the Q > cluster with an EVA interface.]  The DS20E is the production server; the RX2600 Q > is being commissoned and will take over a number of servces from the DS20E when O > fully commissioned.  The AS800 is an underpowered system used for testing and  > patching.    <snip> > O > (Another issue is that the RA7000 will eventually go away.  At this point I'd N > be looking at trying to boot the AS800 from an MSCP-served disk, and I don'tP > think the console is smart enough to do that.  I presume I'll have to reconfig; > the AS800 as a satellite and MOP-boot.  Is that correct?)   A Based upon the designated usage, why try to get complex with the  G AlphaServer 800?  Why not just install a disk in the enclosure for the  E system disk?  Don't place anything except VMS on the disk, and there  I wouldn't be any reason for the other systems to have access to it.  That  H would make usage of the AlphaServer 800 more flexible, not depending on  anything else being available.   KISS   --  4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596> DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com 170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------  # Date: Tue, 11 Apr 2006 07:02:14 GMT L From: winston@SSRL.SLAC.STANFORD.EDU (Alan Winston - SSRL Central Computing)+ Subject: Re: Shadowed System disk questions 6 Message-ID: <00A54083.A6DC22E9@SSRL.SLAC.STANFORD.EDU>  j In article <1144723360.652612.196460@i39g2000cwa.googlegroups.com>, "AEF" <spamsink2001@yahoo.com> writes: > - >Alan Winston - SSRL Central Computing wrote:  >> VMS 7.3-2 >> DS20E >> AlphaServer 800 >> >> RA7000 disk array >> EVA4000 SAN disk array  >>N >> (The DS20E and AS800 share a SCSI connection to the RA7000.  Only the DS20EL >> has a Fibre Channel interface to the EVA.  [There's also an RX2600 in theR >> cluster with an EVA interface.]  The DS20E is the production server; the RX2600R >> is being commissoned and will take over a number of servces from the DS20E whenP >> fully commissioned.  The AS800 is an underpowered system used for testing andP >> patching.  DS20E and AS800 share a system disk on the RA7000.  The RX2600 hasR >> MSCP-only access to the RA7000 disks; the AS800 has MSCP-only access to the EVAM >> disks.  Servers and EVA are in two racks next to each other; RA7000 in two F >> cabinets a few feet away; this is not a disaster-tolerant cluster.) >>Q >> We've already used HBVS to migrate a lot of data disks to the EVA with minimal P >> downtime.  We expect to continue using it even after we've dropped the RA7000M >> members from the shadow sets (which will leave us with a lot of one-volume H >> shadow sets, but that doesn't seem to take much overhead and gives usQ >> tremendous flexibility; if we can afford another EVA in a distant room we just P >> change mount procedures to have disaster tolerance, or when we migrate to the; >> _next_ storage technology we can use the same apporach.)  >>N >> So now we're interested in shadowing the system disk.  The RA7000 (or, moreP >> precisely, the HSZ70s) have been giving us trouble, and we're thinking that aP >> step in getting away from that with minimal downtime is to shadow to the EVA. >>H >> A quick trawl through the volume shadowing docs refers to some sysgenN >> parameters you have to set to do this at all, but doesn't seem to answer my >> chicken-and-egg question: >>Q >>  Is there any way to mount the currently-booted system disk into a shadow set? O >> (I don't see how; it seems you'd have to dismount it, which would presumably D >> have bad effects on the running system even if it were possible.) > H >If the system disk is not already a 1-member shadow set, then I believeH >you have no choice but to set SHADOW_SYS_DISK to 1, set the system diskF >unit number with another SYSGEN param (whose exact name escapes me atF >the moment -- SHADOW_SYS_UNIT ? ) and reboot. Then you get a 1-member= >system-disk shadow set that you can manually add members to.  > F >BE SURE NOT TO ADD MEMBERS TO A SYSTEM DISK SHADOW SET IN ANY STARTUP@ >PROCEDURES. YOU COULD LOSE CURRENT DATA. SEE THE MANUAL FOR THEB >SCENARIO. Only add members manually. Upon reboot, the system willE >attempt to reconstruct the system disk shadow set as it was prior to  >the shutdown.   Thanks, that makes sense.    -- Alan    ------------------------------  # Date: Tue, 11 Apr 2006 07:04:14 GMT L From: winston@SSRL.SLAC.STANFORD.EDU (Alan Winston - SSRL Central Computing)+ Subject: Re: Shadowed System disk questions 6 Message-ID: <00A54083.EE703320@SSRL.SLAC.STANFORD.EDU>  c In article <19ydnUwmSt96z6bZnZ2dnUVZ_vadnZ2d@libcom.com>, Dave Froble <davef@tsoft-inc.com> writes: - >Alan Winston - SSRL Central Computing wrote:  >> VMS 7.3-2 >> DS20E >> AlphaServer 800 >>   >> RA7000 disk array >> EVA4000 SAN disk array  >>  N >> (The DS20E and AS800 share a SCSI connection to the RA7000.  Only the DS20EL >> has a Fibre Channel interface to the EVA.  [There's also an RX2600 in theR >> cluster with an EVA interface.]  The DS20E is the production server; the RX2600R >> is being commissoned and will take over a number of servces from the DS20E whenP >> fully commissioned.  The AS800 is an underpowered system used for testing and >> patching. >  ><snip>  >>  P >> (Another issue is that the RA7000 will eventually go away.  At this point I'dO >> be looking at trying to boot the AS800 from an MSCP-served disk, and I don't Q >> think the console is smart enough to do that.  I presume I'll have to reconfig < >> the AS800 as a satellite and MOP-boot.  Is that correct?) > B >Based upon the designated usage, why try to get complex with the H >AlphaServer 800?  Why not just install a disk in the enclosure for the F >system disk?  Don't place anything except VMS on the disk, and there J >wouldn't be any reason for the other systems to have access to it.  That I >would make usage of the AlphaServer 800 more flexible, not depending on   >anything else being available.   K Then it's another system disk to maintain.  Now it's kind of handy to throw H multinet patches, etc, on via the AS800 (even during working hours) and K reboot it if necessary, reserving the reboot for the DS20E for a convenient  time.    -- Alan    ------------------------------  % Date: Tue, 11 Apr 2006 16:24:39 +0200 / From: Paul Sture <paul.sture.nospam@hispeed.ch> + Subject: Re: Shadowed System disk questions ; Message-ID: <72596$443bbc28$50db5015$22910@news.hispeed.ch>   , Alan Winston - SSRL Central Computing wrote:l > In article <1144723360.652612.196460@i39g2000cwa.googlegroups.com>, "AEF" <spamsink2001@yahoo.com> writes: >    <snip>  Q >>> Is there any way to mount the currently-booted system disk into a shadow set? O >>>(I don't see how; it seems you'd have to dismount it, which would presumably D >>>have bad effects on the running system even if it were possible.) >>I >>If the system disk is not already a 1-member shadow set, then I believe I >>you have no choice but to set SHADOW_SYS_DISK to 1, set the system disk G >>unit number with another SYSGEN param (whose exact name escapes me at G >>the moment -- SHADOW_SYS_UNIT ? ) and reboot. Then you get a 1-member > >>system-disk shadow set that you can manually add members to. >>G >>BE SURE NOT TO ADD MEMBERS TO A SYSTEM DISK SHADOW SET IN ANY STARTUP A >>PROCEDURES. YOU COULD LOSE CURRENT DATA. SEE THE MANUAL FOR THE C >>SCENARIO. Only add members manually. Upon reboot, the system will F >>attempt to reconstruct the system disk shadow set as it was prior to >>the shutdown.  >  >  > Thanks, that makes sense.  > 	 > -- Alan  >     * I'll back up Alan's advice (pun intended).  G A few things to think about once you have system disk shadowing enabed:   A o - When possible/feasible, use disks on separate controllers for ,      shadow set  members within a given set.  G o - At the console, define bootdev_def as unit1, unit2, where these are I      the system disk unit names as seen by the console. Then if the first F      system disk unit isn't available on a boot, it will try the other
      disk.  D o - Before applying a boatload of patches (or other work which couldH      render your system disk unusable), add a third member, wait for theA      shadow copy to complete, and dismount it before applying the C      patches. If you don't have a third disk handy, simply drop the G      second one to act as a backup. As long as you have followed Alan's E      advice about startup procedures, if the second member is already H      dismounted at shutdown, it won't come in at the next reboot. If youF      have multiple disks defined in bootdev_def, make sure you specifyF      the desired disk in the boot command to make sure you boot to theG      correct one. THIS IS IMPORTANT - it is all too easy to boot to the @      wrong disk and potentially lose your work with a subsequentI      shadow copy. I'm perhaps stating the obvious, but once caught, twice 1      shy (and that was 10 years ago for me!). :-)   G o - If you have a set of patches which advise a reboot between each one G      (warning of system instability if you don't), boot into standalone D      mode to apply them. Since working at the console can be a pain,F      I prefer to create a command procedure beforehand to do this, and0      take a printout of it with me just in case.  B o - VMS upgrades require that you switch system disk shadowing offE      before applying the upgrade. Don't forget this step (I did once, $      which is why I mention it). :-)  3 That's all I can think of at the moment. Good luck.    ------------------------------  + Date: Tue, 11 Apr 2006 10:27:13 +0000 (UTC)  From: david20@alpha2.mdx.ac.uk( Subject: Re: TCPIP$SMTP_POSTMASTER_ALIAS) Message-ID: <e1g0a1$lst$1@news.mdx.ac.uk>   w In article <e1eaok$8cu$3@online.de>, helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) writes: C >In article <e1dlnh$rrp$2@news.mdx.ac.uk>, david20@alpha2.mdx.ac.uk 	 >writes:   > O >> If DEC TCPIP Service's SMTP server is not sending bounces with null envelope - >> from addresses then it is severely broken.  > ( >It does send them with null envelope.    M Good. I haven't used UCXs SMTP server in quite sometime so couldn't be sure - = though I didn't remember it as having been quite that broken.   # >The "problem" is that, out of the  8 >box, they come from TCPIP$SMTP and not from Postmaster. >  > O In a bounce message as long as the envelope from is null it shouldn't make any  2 difference what the from message header is set to.N Setting the from message header to an address which can accept queries such asL postmaster (which the RFCs say must exist) makes sense since it indicates anC address to which the user who receives the bounce can send a query.   M Having said that you can never be sure what other people will have configured N their mail servers to accept/reject in the name of blocking spam - hence it isE possible there may be some who reject bounces if they don't come from  postmaster.   B >Does it matter if it's Postmaster or POSTMASTER or postmaster or  >PostMaster?       RFC 2821 says that   " L Any system that includes an SMTP server supporting mail relaying or deliveryJ MUST support the reserved mailbox "postmaster" as a case-insensitive local name.  "   L Hence all of Postmaster, POSTMASTER, postmaster, PostMaster  are equivalent.    
 David Webb Security team leader CCSS Middlesex University   ------------------------------    Date: 11 Apr 2006 01:12:45 -0700/ From: "doypapio@gmail.com" <doypapio@gmail.com> & Subject: Re: Using the Serial TerminalC Message-ID: <1144741401.828486.319810@v46g2000cwv.googlegroups.com>   : Hi....Thanks for all the inputs. I really appreciate them.  E The serial terminal setting is the usual...9600, 8 bits, no parity...   F Actually, I already have the output on my VT. What I cannot seem to do6 is to capture one of the values to, say a text file...  F My VT displays certain outputs or fields...for example, name, address,E height, weight...etc. on the screen. My concern now is how to be able C to use any one of these values say for another command procedure or D maybe output it to a file triggered for example by pressing the "DO" key.   Many thanks again.   ------------------------------    Date: 11 Apr 2006 02:47:44 -0700/ From: "doypapio@gmail.com" <doypapio@gmail.com> & Subject: Re: Using the Serial TerminalC Message-ID: <1144741295.511513.243930@g10g2000cwb.googlegroups.com>   : Hi....Thanks for all the inputs. I really appreciate them.  E The serial terminal setting is the usual...9600, 8 bits, no parity...   F Actually, I already have the output on my VT. What I cannot seem to do6 is to capture one of the values to, say a text file...  F My VT displays certain outputs or fields...for example, name, address,E height, weight...etc. on the screen. My concern now is how to be able C to use any one of these values say for another command procedure or D maybe output it to a file triggered for example by pressing the "DO" key.   Many thanks again.   ------------------------------  % Date: Tue, 11 Apr 2006 10:08:28 +0100 % From: "issinoho" <issinoho@gmail.com>  Subject: Re: VAMP board changes 0 Message-ID: <123msgjerhg5gfc@corp.supernews.com>  L Thanks to David Dachtera, VAMP is now running on the more user-friendly URL  of http://vamp.issinoho.com       1 "issinoho" <issinoho@gmail.com> wrote in message  . news:e1e6e5$78t$1$8302bc10@news.demon.co.uk... > For information. > L > The VAMP (VMS-Apache-MySQL-PHP) message board has been upgraded to run on , > the latest version of phpBB, namely 2.0.20H > A full changelog is contained on the board forum, however changes are & > mainly bug fixes & security-related. > K > I've also done a little spring-clean. All users that I could identify as  M > being spammers have been deleted and a new shiny theme and banner has been   > added. > M > Other than that it's business as usual. Hope you like the changes; any and   > and all comments welcome.  > K > One of these days I'll get round to getting a decent URL for this to run  I > on; until that time it remains at http://www.issinoho.com:8080/phpbb2/     ------------------------------   End of INFO-VAX 2006.201 ************************        ve mode; use PORT (198,151,12,104,18,225)t <<< LIST /vmslt98a >>> 150 List started.  >>> 226 Transfer completed.e <<< TYPE A >>> 200 Type A ok.
 <<< PASVA >>> 227 Entering passive mode; use PORT (198,151,12,104,18,226)t <<< LIST /vmslt98b >>> 150 List started.  >>> 226 Transfer completed.e <<< TYPE A >>> 200 Type A ok.
 <<< PASVA >>> 227 Entering passive mode; use PORT (198,151,12,104,18,227)t <<< LIST /vmslt99a >>> 150 List started.  >>> 226 Transfer completed.e <<< TYPE A >>> 200 Type A ok.
 <<< PASVA >>> 227 Entering passive mode; use PORT (198,151,12,104,18,228)t <<< LIST /vmslt99b >>> 150 List started.  >>> 226 Transfer completed.e <<< TYPE A >>> 200 Type A ok.
 <<< PASVA >>> 227 Entering passive mode; use PORT (198,151,12,104,18,229)t <<< LIST /x11r6dist> >>> 150 List started.A >>> 226 Transfer completed.m <<< TYPE A >>> 200 Type A ok.
 <<< PASVA >>> 227 Entering passive mode; use PORT (198,151,12,104,18,230)d <<< LIST /zzzvirtdisk_filler >>> 150 List started.  >>> 226 Transfer completed.P <<< TYPE A >>> 200 Type A ok.
 <<< PASVA >>> 227 Entering passive mode; use PORT (198,151,12,104,18,231)  <<< LIST /00avmslt/00avmslt >>> 150 List started.i >>> 226 Transfer completed.1 <<< TYPE A >>> 200 Type A ok.
 <<< PASVA >>> 227 Entering passive mode; use PORT (198,151,12,104,18,232)  <<< LIST /00bvmslt/00bvmsltV >>> 150 List started.i >>> 226 Transfer completed.0 <<< TY