1 INFO-VAX	Sun, 15 May 2005	Volume 2005 : Issue 270       Contents:/ Re: Downgrading to DECnet IV and Pathworks V6.1 4 HSx ECB (cache battery) troubleshooting/specs Part 2 Re: TCPIP rejection " Re: The continuing saga of the VAX" Re: The continuing saga of the VAX Re: VMS MAIL personal name  F ----------------------------------------------------------------------  % Date: Sun, 15 May 2005 11:43:48 -0400 $ From: "PEN" <paul.nuneznosp@mhp.com>8 Subject: Re: Downgrading to DECnet IV and Pathworks V6.1, Message-ID: <d67qnn$7al$1@hplms2.hpl.hp.com>   Hi,   , <tomarsin2015@comcast.net> wrote in message = news:1116117615.078902.310810@g44g2000cwa.googlegroups.com...  > Hello F > After some arguement we decide to go from DECnet Plus back to DECnet> > IV. Problem is now some of the Pathworks servers cannot beenG > seen on the network. Its not all the systems, just the ones that went I > from Plus back to IV. The VAXs and Alphas that where originally IV work H > okay, ie we can browse map drives, but the old Plus come back with net3 > work path not found, no domain servers found etc.  > phii >    Check:  # $ @sys$startup:pwrk$define_commands , $ pwshow   ! Is the NETBIOS process running?  I The DECnet related PATHWORKS log file is PWRK$LOGS:NETBIOS_nodename.LOG,  B which may have an error (at the end);  also check the tail end of L PWRK$LMLOGS:PWRK$LMMCP_nodename.LOG for indications it was unable to find a  DECnet interface or such...   . Are there any errors seen during PWRK$STARTUP?  H PATHWORKS uses DECnet object 64 and creates it when starting.   If  the F NETBIOS process is running, does object 64 exist ($ mc ncp show known K object)?   If not, one remote possibility is there are already the maximum  G number of  DECnet objects defined, which is controlled by the value of  K Maximum Declared Objects (last value displayed by $ mc ncp show exec char).   J If the NETBIOS process is running, you can do some DECnet NETBIOS testing  with:   A $ mc pcsa_claim_name /status   ! Space before /status is required   J Do you see the domain name and computername listed in the "DECnet NetBIOS  Name Table Contents" section?   9 You can send a DECnet NETBIOS name status query by doing:   C $ mc pcsa_claim_name /find <name>     ! Space before /find required   J If the "FNBuf.destAddr" and "FNBuf.sourceAddr" addresses are all 0's, the L name was not resolved.  Otherwise, you'll see the mac address of the decnet 3 node that responded in the "FNBuf.destAddr" field..   K On the remote chance you have to re-install PATHWORKS, de sure to first do:   # $ @sys$startup:pwrk$define_commands  $ pwver all   L To avoid the requirement to config/reboot (since you're installing the same 	 version):         $ delete sys$update:pw*.sav;J     $ create sys$common:[sysupd]pwrk$configured_<nodename>.dat    ! Empty  file. ,     $ deassign/system/exec PWRK$DEFER_REBOOT
     $ pwstart      Paul     ------------------------------    Date: 15 May 2005 08:39:46 -0700; From: "johnhreinhardt@yahoo.com" <johnhreinhardt@yahoo.com> = Subject: HSx ECB (cache battery) troubleshooting/specs Part 2 C Message-ID: <1116171586.913805.326520@g44g2000cwa.googlegroups.com>    For previous discussions see: t http://groups-beta.google.com/group/comp.os.vms/browse_frm/thread/8fe3dc470d7da8d5/03cd09dc82f0f314#03cd09dc82f0f314  G Just in case anyone was wondering, the ECB on a Model 2200 StorageWorks C controller shelf use the same cells and configuration.  You can buy 3 individual cells from Portable Power Systems (here: F http://www.gotbatteries.com/ProductPage.asp?ProductNum=37L142S1 ) or a$ built-up replacement from MDS (here:G http://www.mdsbattery.com/shop/productprofile.asp?ProductGroupID=1232 )   F Note this is not a recommendation for either of these two companies asF I have not yet purchsed from either, but I will be soon.  This is just  a bit of additional information.  E Many thanks to the original poster, Duncan Brown, for being the first 2 to cut one of these open and post the information.   ------------------------------  + Date: Sun, 15 May 2005 06:47:35 +0000 (UTC) P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) Subject: Re: TCPIP rejection$ Message-ID: <d66ra7$qp2$2@online.de>  6 In article <42867D19.C3547945@vaxination.ca>, JF Mezei( <jfmezei.spamnot@vaxination.ca> writes:   L > > I have a cluster.  Each node has its own system disk.  TCPIP$SMTP_COMMONJ > > points to SYS$SYSDEVICE:[SYS0.TCPIP$SMTP].  Is there any reason not toG > > define this on each node to point to a really common directory on a ? > > non-system disk, such as the one where I have SYSUAF etc?    > I > You may have problems with logfiles since their names are not tied to a J > node and would reside in the same directory and thus you'd have multipleG > versions growing at the same time and no way of knowing which version  > belongs to which node.  @ I'll have to read up on the documentation (if it is documented).G Theoretically, the log files could go to the named directory, and other G stuff could go to the logical, which by default is the named directory. < Also, perhaps I could define it as a search list, and put myC cluster-common stuff in a directory later in the search list.  Has   anyone done this?    ------------------------------   Date: 15 May 2005 12:25:50 GMT( From: bill@cs.uofs.edu (Bill Gunshannon)+ Subject: Re: The continuing saga of the VAX + Message-ID: <3eotedF46r5uU1@individual.net>   ! In article <1WCn9mP08KHT@wvnvms>, , 	cook@wvnvms.wvnet.edu (George Cook) writes:X > In article <3ejqaeF3gvvaU1@individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes: >> OK, on to the next problem. >>  B >> I can now see devices.  But apparently, not boot from them. :-) >  >  > Are both path A and B up?  >   E No, but I can probably do that first thing monday. I asked and no one F said that both had to be up.  I was hoping for up and then redundancy.   >  > G >> Here is some output.  I have repeated this about a half dozen times. 5 >> It sure isn't like booting one of ny VS3100's  :-)  >>   >> P00>>> sh dev/ >> polling for units on cixcd0, slot 3, xmi0... 4 >> dua1.2.0.3.0       $1$DUA1 (HSJ002)          HSX14 >> dua41.2.0.3.0      $1$DKA41 (HSJ002)        RRD46 >> P00>>> boot dua41.2.0.3.0 >> Initializing... >>  I >> F   E   D   C   B   A   9   8   7   6   5   4   3   2   1   0   NODE # F >>                             A   M   .   .   .   P   P   P   P   TYPF >>                             o   +   .   .   .   +   +   +   +   ST1F >>                             .   .   .   .   .   E   E   E   B   BPDF >>                             o   +   .   .   .   +   +   +   +   ST2F >>                             .   .   .   .   .   E   E   E   B   BPDF >>                             +   +   .   .   .   +   +   +   +   ST3F >>                             .   .   .   .   .   E   E   E   B   BPD >>  K >>     +   .   .   .   .   .   +   .   .   .   .   +   .   +       C0 XMI + E >> .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   C1 E >> .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   C2 E >> .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   C3  >>  F >>                             .  A0   .   .   .   .   .   .   .   ILVH >>                             . 512   .   .   .   .   .   .   .   512MB >>  K >> Firmware Rev = S4.4-4857      SROM Rev = S3.1-0      SYS SN = NI525N9935  >  > ? > What is this machine supposed to be?  It is not a VAX 6640.     E It doesn't say in it anywhere.  I thought when I looked up the CPU on B the NetBSD hardware list it said it was a 6640.  But I cou be (and' probably am) wrong.  How do I find out?   E >                                                             Are you + > sure it hasn't been upgraded to an Alpha    % No, it's definitely not an Alpha. :-)   J >                                           or a VAX 7xxx (I have not seenI > either at the console level, but I do know what a VAX 6xxx looks like)?    Maybe it is a 7xxx then.   >  >  > 
 >> P00>>> 
 >> Booting... * >> Connecting to boot device dua41.2.0.3.0  >> Created device: dua41.2.0.3.02 >> block 0 of dua41.2.0.3.0 is  a valid boot block' >> reading 87 blocks from dua41.2.0.3.0  >> bootstrap code read in  >> base = 154000, start = 200 # >> boot device name = dua41.2.0.3.0  >> boot flags  0,2,0   >> boot device type = 20 >> controller ID = a >> unit number = 41  >> node ID = 2 >> channel = 0 >> slot = 3  >> hose = 0 ! >> jumping to bootstrap at 154200  >>  ( >> ------------------------------------- >>  3 >> And there it sits.  Until I hit ^P.  Then I get.  >>   >>   >>  . >> CPU:0 Console entry reason: ^P or Node Halt >>  , >> Entry PC: 00154E07     Entry PSL:041F0200 >>   >> P00>>> ^C >> P00>>> sh dev/ >> polling for units on cixcd0, slot 3, xmi0...  >> Resetting IO subsystem... >> P00>>>   sh dev/ >> polling for units on cixcd0, slot 3, xmi0... 4 >> dua1.2.0.3.0       $1$DUA1 (HSJ002)          HSX14 >> dua41.2.0.3.0      $1$DKA41 (HSJ002)        RRD46 >>  2 >> Well, at least my devices are still there.  :-( >>  F >> Is there some bootflag I need to add either because of the model or& >> maybe because it's booting from CI? > I > You need to set the values to whatever (for the model machine you have) 0 > which will boot standalone backup from the CD.  H So all I need then is someone to tell me what those values might be. :-)   bill   --  J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>       ------------------------------    Date: 15 May 2005 08:14:25 -0700; From: "johnhreinhardt@yahoo.com" <johnhreinhardt@yahoo.com> + Subject: Re: The continuing saga of the VAX C Message-ID: <1116170065.667748.122160@g14g2000cwa.googlegroups.com>    Bill Gunshannon wrote:# > In article <1WCn9mP08KHT@wvnvms>, . > 	cook@wvnvms.wvnet.edu (George Cook) writes:F > > In article <3ejqaeF3gvvaU1@individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes:   > >> OK, on to the next problem. > >>D > >> I can now see devices.  But apparently, not boot from them. :-) > >  > >  > > Are both path A and B up?  > >  > G > No, but I can probably do that first thing monday. I asked and no one < > said that both had to be up.  I was hoping for up and then redundancy.  >   F Bill, I found a doc online which has a wealth of information about theE VAX7000 series (and yes, that's what you have. I had a cluster of two " 7620's from 1998-2001)  It is at <C http://www.update.uu.se/~bqt/vax7000/7XX0.PDF >  Get it and save it E locally.  See sections 14.1.10 and 14.1.11 about a known problem with D VAX7000's not booting if only one CI path is connected and a problem= booting from HSJ40's (I think you said that's what you had?).    > >  > > B > >> Here is some output.  I have repeated this about a half dozen times.7 > >> It sure isn't like booting one of ny VS3100's  :-)  > >> > >> P00>>> sh dev1 > >> polling for units on cixcd0, slot 3, xmi0... 6 > >> dua1.2.0.3.0       $1$DUA1 (HSJ002)          HSX16 > >> dua41.2.0.3.0      $1$DKA41 (HSJ002)        RRD46 > >> P00>>> boot dua41.2.0.3.0 > >> Initializing... > >>B > >> F   E   D   C   B   A   9   8   7   6   5   4   3   2   1   0 NODE #B > >>                             A   M   .   .   .   P   P   P   P TYP B > >>                             o   +   .   .   .   +   +   +   + ST1 B > >>                             .   .   .   .   .   E   E   E   B BPD B > >>                             o   +   .   .   .   +   +   +   + ST2 B > >>                             .   .   .   .   .   E   E   E   B BPD B > >>                             +   +   .   .   .   +   +   +   + ST3 B > >>                             .   .   .   .   .   E   E   E   B BPD  > >>G > >>     +   .   .   .   .   .   +   .   .   .   .   +   .   +       C0  XMI + G > >> .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   C1 G > >> .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   C2 G > >> .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   C3  > >>B > >>                             .  A0   .   .   .   .   .   .   . ILV B > >>                             . 512   .   .   .   .   .   .   . 512MB  > >>B > >> Firmware Rev = S4.4-4857      SROM Rev = S3.1-0      SYS SN =
 NI525N9935 > >  > > ? > > What is this machine supposed to be?  It is not a VAX 6640.  > G > It doesn't say in it anywhere.  I thought when I looked up the CPU on D > the NetBSD hardware list it said it was a 6640.  But I cou be (and) > probably am) wrong.  How do I find out?   B It's a 7x40 type.  The 4 CPU's are indicated by the 4 "P"'s in theE diagram and it's VAX 7000 series.  I don't know how to tell which one @ though. There were 3 models I know of - the 7600, 7700 and 7800.   > >> P00>>>  > >> Booting... , > >> Connecting to boot device dua41.2.0.3.0" > >> Created device: dua41.2.0.3.04 > >> block 0 of dua41.2.0.3.0 is  a valid boot block) > >> reading 87 blocks from dua41.2.0.3.0  > >> bootstrap code read in  > >> base = 154000, start = 200 % > >> boot device name = dua41.2.0.3.0  > >> boot flags  0,2,0 > >> boot device type = 20 > >> controller ID = a > >> unit number = 41  > >> node ID = 2 > >> channel = 0
 > >> slot = 3 
 > >> hose = 0 # > >> jumping to bootstrap at 154200  > >>* > >> ------------------------------------- > >>5 > >> And there it sits.  Until I hit ^P.  Then I get.  > >> > >> > >>0 > >> CPU:0 Console entry reason: ^P or Node Halt > >>. > >> Entry PC: 00154E07     Entry PSL:041F0200 > >> > >> P00>>> ^C > >> P00>>> sh dev1 > >> polling for units on cixcd0, slot 3, xmi0...  > >> Resetting IO subsystem... > >> P00>>>   sh dev1 > >> polling for units on cixcd0, slot 3, xmi0... 6 > >> dua1.2.0.3.0       $1$DUA1 (HSJ002)          HSX16 > >> dua41.2.0.3.0      $1$DKA41 (HSJ002)        RRD46      ^^^                   ^^^C Seems wrong.  Does a RRD46 on a HSJ have to be defined as a passthu D device? I know tape drives did but I never had a CD hanging off of aB HSJ.  Your RRD46 is in a SW cannister and plugs into the SW shelf?     > >>4 > >> Well, at least my devices are still there.  :-( > >>E > >> Is there some bootflag I need to add either because of the model  or( > >> maybe because it's booting from CI?  F Boot flags to boot from a CD should be 0,0,0.  Your default boot flagsG look to be set to 0,2,0 so you may want to change that.  Though I don't D think it should make a differents.  If it's trying to boot SYS2 fromF the CD is should still work since every VMS OS CD I've seen has all of the system roots on it.   E Here is a cut and paste of Sections 14.1.10 and 14.1.11 from that PDF G (It's still a good idea to download it from the above site. It has info > about other possible problems/hardware limitations that may beF informative).  Note 14.1.11 mentions a problem booting from devices onF a HSJ40 with consoles 2.9, 3.0 and 3.1.  I think you have console V3.1F (the "SROM Rev = S3.1-0" in the diagram after initializing) so you may* be getting bit by this if you have HSJ40's  7 14.1.10 VAX 7000 and HSJ40, Single Path Booting Problem G As described in Section 14.1.11, a VAX 7000 will not boot from an HSJ40  disk if one pathF to the HSJ40 controller is disabled. Unfortunately, this configurationE is needed as a workaround for the HSJ40 "dual receive crash" problem.   E The following console patch allows the VAX 7000 to boot over a single  path. It should onlyD be installed on systems that boot from an HSJ40 system disk and have console version V3.2- D 4041[A6] . It must be removed when the console is upgraded. (Use >>> build eeprom, to
 erase patch).   4 Execute the following commands to install the patch. >>> set mode advanced  >>> set eeprom script powerup  Script> set mode advanced  Script> ka7aa_pwrup F Script> echo "Applying single path boot patch to V3.2-4041[A6]" > tt ! Script> d -w 2DBA6 2811 -u Script> d -l 2dbce 05B13511 -u Script> d -l 2dbd2 B1471350 -u Script> d -l 2dbd6 42135011 -u Script> d -l 2dbda A0C401E0 -u Script> d -l 2dbde CA11DA00 -u Script> Set mode basic
 Script> ^Z >>> Set mode basicE On multi processor systems use this command to update the other CPUs:  P00>>> update ka7aa* -e C ! This message pops out at Initialise time to tell you the patch is  being applied.    4 14.1.11 VAX 7000 fails to reboot from HSJ-40 devices> VAX 7000 V2.X and V3.0, V3.1 consoles don't handle the virtual circuit with the HSC-40 E properly when attempting to reboot. This causes the boot to fail like  this:  P00>>>
 Booting...* Connecting to boot device dua403.10.0.13.0  Created device: dua403.10.0.13.0! device dua403.10.0.13.0 not found  failed to open dua403.10.0.13.0  P00>>>G The fix is to install VAX7000 Console V3.2. Note a problem still exists  when attempting toE SHOW DEVICE or boot a drive with PATH A or B disconnected or disabled  from an HSJ-G 40. You must have both paths enabled and connected for the console code  to work properly. # Alternatively, see Section 14.1.10.  39   ------------------------------  + Date: Sun, 15 May 2005 06:43:09 +0000 (UTC) P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)# Subject: Re: VMS MAIL personal name $ Message-ID: <d66r1t$qp2$1@online.de>  6 In article <42868A3E.7C9847D5@vaxination.ca>, JF Mezei( <jfmezei.spamnot@vaxination.ca> writes:   1 > Phillip Helbig---remove CLOTHES to reply wrote: H > > Another hack, of course, is to define TCPIP$SMTP_FROM to include the1 > > personal name as well as the email address.    > I > Won't work.  This is expected to be the routable email address which is F > also used in the SMTP protocol. And RFC822 From:  isn't valid in theG > SMTP protocol (MAIL FROM:) command, and the SMTP software isn't smart G > enough to parse a display name to extract the routable email address.   I Peter Weaver posted here recently that he does this.  I have never tried   it.   J > And with 5.3 on VAX, at least, VMS MAIL doesn't display the display nameD > in the VMS Mail header, only the routable email address (eg: From:# > SMTP%chef.pierre@chocolate.com" )  > C > I just sent myself an email via SMTP, and the personal name in my F > VMSmail profile did make it all the way around, and that is also the+ > case with mail sent to the outside world.   D That's not my experience.  What I get is: personal name visible withF non-SMTP mail within a cluster OR with SMTP mail to a non-VMS system, G but SMTP mail from one VMS system to another (not in the same cluster)  % doesn't keep the personal-name field.    ------------------------------   End of INFO-VAX 2005.270 ************************