What's new in KP3 computing ?

---

• December 22^nd, 1996
  
  • Software upgrades on the VAX cluster.

• December 20^th, 1996
  
  • Software upgrades on the AXP cluster.

• December 19^th, 1996
  
  • The GSI IP connection went out around 11:00 and also yesterday around 14:00. See also November 26^th).
  • The volume containing the scratch area al_temp0 was split into two logical partitions. The size of the scratch area is temporarily reduced from 8000000 to 5510000 blocks.
  • The Internet is still a maze, but the odd routing seen on December 4^th was improved after the provider was contacted. The route is now:

     1  cisco96 (140.181.96.1)  3 ms  1 ms  1 ms
     2  192.108.55.68 (192.108.55.68)  4 ms  3 ms  2 ms
     3  TH-Darmstadt1.WiN-IP.DFN.DE (188.1.11.17)  3 ms  3 ms  2 ms
     4  ZR-Frankfurt1.WiN-IP.DFN.DE (188.1.11.13)  4 ms  4 ms  4 ms
     5  XR-Frankfurt1.WiN-IP.DFN.DE (188.1.11.250)  5 ms  4 ms  5 ms
     6  ECRC-WiN.ECRC.DE (188.1.132.2)  143 ms  153 ms  85 ms
     7  ECRC-RBS.ECRC.DE (193.23.5.49)  123 ms  72 ms  57 ms
     8  gate-touchnet.ecrc.de (194.112.104.48)  80 ms  155 ms  181 ms
     9  mg1.touch.net (194.77.16.22)  333 ms  350 ms  286 ms
    10  * www.fnet.de (195.214.70.122)  533 ms *
    

    This improved performance should be compared with what one gets with a direct WIN attachment:

     1  cisco96 (140.181.96.1)  1 ms  30 ms  1 ms
     2  192.108.55.68 (192.108.55.68)  2 ms  2 ms  4 ms
     3  TH-Darmstadt1.WiN-IP.DFN.DE (188.1.11.17)  3 ms  3 ms  2 ms
     4  ZR-Frankfurt1.WiN-IP.DFN.DE (188.1.11.13)  4 ms  4 ms  4 ms
     5  ZR-Karlsruhe1.WiN-IP.DFN.DE (188.1.144.38)  16 ms  15 ms  15 ms
     6  ZR-Stuttgart1.WiN-IP.DFN.DE (188.1.144.42)  17 ms  18 ms  17 ms
     7  ZR-Muenchen1.WiN-IP.DFN.DE (188.1.144.46)  21 ms  21 ms  20 ms
     8  LRZ-Muenchen1.WiN-IP.DFN.DE (188.1.8.18)  21 ms  21 ms  21 ms
     9  KR-LRZ-Muenchen1.lrz-muenchen.de (188.1.8.22)  33 ms *  21 ms
    10  192.68.215.254 (192.68.215.254)  21 ms  21 ms  21 ms
    11  bro1cz.lrz-muenchen.de (129.187.4.251)  22 ms  21 ms  23 ms
    12  sunsystem4.informatik.tu-muenchen.de (131.159.0.14)  23 ms *  22 ms
    

    Note that both nodes a locaed in Munich.

• December 17^th, 1996
  
  • The scratch disk al_temp0: broke down again (many read errors) and had to be replaced. Note that this disk failed for the third time (seeNovember 19^th and June 3^rd) and that the second scratch disk a01_temp0: also failed recently (see December 6^th).
    The broken disk (type Quantum XP34300W) was replaced by a SEAGATE ST15150W drive, now located at $7$dkd200:(dl124). Most files could be copied to the new drive, but some were lost or corrupted.
  • The volume set al_data0 was moved back onto disks attached to node AXP607. It resides again on devices addresses $7$DKA100:, 7$DKA200: and 7$DKA300: on a set of RZ29B drives. This configuration replaces the temporary fix put in on November 18^th after some data corruption problems with the Quantum drives were discovered.
    The reference copies of all CMS libraries, which also reside on this volume set, had to be repaired. The cause in unknown, neither creation nor modification date showed modifications, also the file contents looked o.k.

• December 16^th, 1996
  
  • The AXP cluster software was updated. One major change is the installation of a new Motif version with CDE (Common Desktop Environment). In case you like the old style DECwindows session manager better you can set this up during the login dialog:

            1. Click the "Options" button in the login dialog box
            2. Select "Session"
            3. Select "DECwindows Session"
            4. Proceed with entering username
    

    Note also that you can terminate the login dialog with

    	  "Options" --> "Reset Login Screen"
    

    This can be used from an Xterminal to connect to a different node (so one doesn't need to reboot the XTerm anymore).

• December 12^th, 1996
  
  • The kp3$root: disk was cleaned up on the AXP cluster. The accounts

    	blaich
    	kleinevoss
    	strasbourg
    

    were backedup and removed.

• December 6^th, 1996
  
  • The disk $1$DIA260:(DC032), known as a01_temp0, which started to fail on December 4^th, was replaced. Most files could be recovered, but some were lost due to unrecoverable read errors.

• December 4^th, 1996
  
  • The disk $1$DIA260:(DC032), known as a01_temp0, failed this afternoon. There is currently no spare available and it is not clear whether the contents of the disk can be recovered.
  • The Internet is a maze, as we know. The route to www.fnet.de, which is located in Munich, is currently:

     1  cisco96 (140.181.96.1)  5 ms  2 ms  2 ms
     2  192.108.55.68 (192.108.55.68)  3 ms  3 ms  2 ms
     3  TH-Darmstadt1.WiN-IP.DFN.DE (188.1.11.17)  3 ms  3 ms  3 ms
     4  ZR-Wiesbaden1.WiN-IP.DFN.DE (188.1.11.13)  5 ms  5 ms  5 ms
     5  ipgate1.WiN-IP.DFN.DE (188.1.144.70)  13 ms  10 ms  10 ms
     6  ipgate2.win-ip.dfn.de (193.174.74.137)  21 ms  14 ms  27 ms
     7  DE-s0.dante.bt.net (194.72.26.65)  108 ms  179 ms  168 ms
     8  DE-f0-0.eurocore.bt.net (194.72.24.193)  50 ms  42 ms  62 ms
     9  CH-s1-0.eurocore.bt.net (194.72.24.206)  77 ms  95 ms  95 ms
    10  CH-f0.global.bt.net (194.72.24.67)  103 ms  110 ms  78 ms
    11  cern-ebs1.ebone.net (194.72.26.142)  470 ms * *
    12  * Paris-EBS2.Ebone.net (192.121.156.122)  582 ms  442 ms
    13  stockholm-ebs-s9-0.ebone.net (192.121.154.45)  417 ms  634 ms *
    14  Stockholm-DGIX.ubn.net (194.68.128.18)  563 ms  528 ms *
    15  * Stockholm4.ubn.net (194.23.0.84)  454 ms *
    16  s0.Frankfurt-1.Contrib.Net (194.17.1.22)  693 ms * *
    17  * s0.Muenchen-1.Contrib.Net (194.77.95.6)  796 ms *
    18  * * *
    19  * * mg1.touch.net (194.77.16.22)  2364 ms
    20  * * *
    21  * www.fnet.de (193.100.24.122)  1826 ms  1577 ms
    

    Needless to say that a 1.8 sec roundtrip time to Bavaria isn't exactly what gives good performance.

• December 3^rd, 1996
  
  • A disk controler on clri6c died and the user file systems became unavailable. The Failover doesn't work, so the whole AIX cluster was effectively unavailable the whole afternoon.

• December 2^nd, 1996
  
  • The al_pool0: disk was cleaned up. The directories

            al_pool0:[kunze...]
            al_pool0:[moehlenkamp...]
            al_pool0:[mudex...]
            al_pool0:[zude...]
    

    were backedup and removed.
  • The ProxyServer problems with expired documents (see November 15^th) are still not solved. An explicit reload in Netscape will however always get a fresh copy and update the server.

  ---

• November 26^th, 1996
  
  • The GSI IP connection went dead at 14:00. All connections to outside GSI are blocked. Was repaired on November 27^th between 8:00 and 10:00.
    Background: A Telekom contractor did some spliceing and obviously messed up the fibres. Even though the mistake was noticed quickly it took 24 hours to recover, mainlyt because the work stopped at 5 pm and resumed the next morning. The same contractor caused a similar breakdown in the Heidelberg MAN 1-2 month ago.

• November 22^nd, 1996
  
  • The weekly tape backup procedure was extended to save the directory structure of the TEMP disks. This allows to reconstruct at least the directory structure in case of a loss of one scratch disk. The weekly backup currently covers:

    Saved path	Comment
    disk$dl175:[aladinsoft...],[caveb...]	Reference copy areas
    al_temp0:[*...]*.dir	TEMP directories
    al_temp1:[*...]*.dir	TEMP directories
    a01_temp0:[*...]*.dir	TEMP directories
    disk$dl154:	KP3$ROOT:
    disk$dl178:	AL_POOL0:

• November 22^nd, 1996
  
  • The IP connection to the U.S. and possibly to many other contries went down on 18:00 and recovered some time next day. Reason: Problems on B-Win-Router (MAN-DA <=> B-Win).
  • The new ProxyServer introduced around November 15^th does not properly handle the expiration of documents. This causes the delivery of expired data and can lead to problems with all kinds of services which update their pages in regular intervals, e.g. the `new' listings of the LANL preprint server (for example nucl-th/new).

• November 19^th, 1996
  
  • The node vsbz crashed around 11:00 and recovered only after several reboot attempts around noon time. A hardware or network problem is suspected.

• November 18^th, 1996
  
  • The scratch disk al_temp0: broke down and had to be replaced. It was possible to copy the directory structure of the damaged disk, but all files were lost.
    The new disk is again a Quantum XP34300W and located in $7$dkd0:(dl124). Note, that the broken disk was installed on June 3^rd and lasted only a little more than 5 month !
  • The disks of the whole volume set al_data0 were exchanged after the data corruption problems seen on October 24^th. The three QUANTUM XP34300 were replaced by DEC RZ29B. The only visible difference of the drives is a slighly reduced capacity, 8380080 instead of 8399520 blocks.
    The volume names as well as all logicals didn't change. The physical drive addresses changed from $7$DKA100:, $7$DKA200: and $7$DKA300: to $1$DKA400:, $1$DKB400: and $1$DKC400:

• November 15^th, 1996
  
  • The ProxyServer, which speeds up WWW access to sites outside GSI by caching of information, has been upgraded recently by Kay Winkler. It uses now the software squid/1.0.15 instead of the old CERN server and executes on the node www-cache.gsi.de.

• November 6^th, 1996
  
  • The files of following accounts have been backedup and removed from the VAX cluster:

    	hongfei
    	kleinevoss
    	trzcinski
    	zude
    

• November 4^th, 1996
  
  • Full cluster crash of the VAX cluster around 17:00. Was caused by a AXP101 related problem, not by the GigaSwitch.

  ---

• October 29^th, 1996
  
  • Checked the validity of the data on the al_pool0 volume set by comparing against three old backups (taken between March and August 1996). No corrupted files were found. The data on the al_pool0 disks is therefore assumed to be o.k., whereas the problems with the al_data0 disks, which are of the same type and are connected to the same interface, remain unsolved.

• October 24^th, 1996
  
  • Finally diagnosed a major problem with the al_data0: file system. Five datafiles have been corrupted since they were created in May 1996:

            al_data0:[s117]s117_esp_xxxx.lmd
            with xxxx = 2433, 2659, 2838, 2947 and 3569
    

    The file s117_esp_2838.lmd was reconstructed from a backup done on August 19^th, the others were removed.
    A closer inspection of the damaged file s117_esp_2838.lmd showed that the problems were caused by a single extra byte. The data was shifted by one byte in a stretch of 122 blocks.
    An inspection of the error log files did not produce any evidence.
  • The get more information on the possible mechnism of the data corruption I have enable data checking for read and write for the al_data0 and the al_pool0 file system. Since this doubles the amount of I/O traffic we will see some performance degradation.

• October 23^rd, 1996
  
  • The hardware of the main Gigaswitch was completely replaced. Even though not full cluster crashes occured after the firmware upgrade on October 17^th, there had been still major problems indicating a potential hardware fault.
    The AXP cluster crashed, even though an on-the-fly swap was planned, the VMS cluster survived.
  • The Gigaswitch hardware problems caused numerous short network interuptions during the last two weeks. Even though most lasted only about 2 minutes and did not affect the cluster, they were long enough to exceed the timeout of LAT and DECnet sessions. So the many observed aborts of remote terminal sessions are most likely connected to Gigaswitch hickups.

• October 17^th, 1996
  
  • Gigaswitch was completely upgraded to newest firmware revision. AXP and VAX cluster unavailable during this time.

• October 16^th, 1996
  
  • Full AXP and VAX cluster crash around 11:00 due to GIGAswitch problems.

• October 15^th, 1996
  
  • The DEFRAGMENTER, down since October 10^th, is working again.
  • Full AXP cluster crash around noon time due to GIGAswitch problems.
  • Full AXP and VAX cluster crash around 18:00 due to GIGAswitch problems.

• October 12^th, 1996
  
  • Nodes axp605 and axp607 crashed due to FDDI and Gigaswitch problems and were unavailable for some extended time.
  • A new version of Netscape, Version 2.02, has been installed. This is a production version and replaces the beta-test version.

• October 10^th, 1996
  
  • The processors in node axp605 were upgraded from 5/300 to 5/400. The new boards have, besides the higher clock frequency, a larger 3^rd level cache (4 instead of 2 Mb). The performance gain is 40 to 50%. The new SPECmarks figures are: SPECint95: 12.1; SPECpf95 17.2 (1CPU).
  • Minor upgrades on VAX (10.10) and AXP (11,11) cluster. The AXP cluster is now completely on VMS V6.2-1H3.
  • The DEFRAGMENTER stopped working on axp607.

  ---

• September 16^th, 1996
  
  • The cache memory of node axp607 was finally exchanged. This ended the series of crashes since August 26^th.

• September 11^th, 1996
  
  • The node axp607 was entirely rebuild. The motherboard and both memory boards were swapped. The memory SIMM's as well as the cache modules and all I/O boards were kept. The system is now back with full memory capacity.
    The node axp607 had numerous crashes since August 26^th. Attempts to find a fault in the memory subsystem (see August 29^th) failed.

• September 9^th, 1996
  
  • Node axp607 crashed late night on September 6th and didn't reboot during the weekend.

• September 3^rd, 1996
  
  • Node axp607 runs still with half the nominal memory. An attempt to reinstall the 128 Mb removed on August 29^th failed.
  • The disk $27$DKA300, usually refered to as a27_pool0, which failed around August 29^th, was replaced. The files were restored from a backup done on April 3^rd, 1996.

  ---

• August 29^th, 1996
  
  • A board with a bad connector for memory SIMM's was swapped for node axp607, hopefully ending the frequent crashes (see August 26^th). However, axp607 runs currently with only half the memory (or 128 Mbyte).
  • The disk $27$DKA300 failed.

• August 26^th, 1996
  
  • Node axp607 crashed three times with memory problems. The memory was reduced to 128 Mbyte, but yet another crash happened.
  • Redirected the daily backup of user files on the kp3$root disk on the AXP cluster to the adsmcli interface. The procedure sbk_user was modified accordingly.
  • Discontinued the daily update of the MVS dataset lists. One final dataset listing was obtained and will be kept. It can be accessed as before with the MVS dataset query form.

• August 6^th, 1996
  
  • Changed login_aladin.com to activate a new release of the MOSAIC browser (V2.7beta5). It has table support (though no support for links in tables) and processes mailto: as well as compressed PostScript (from xxx.lanl.gov) correctly. The News support has also improved.

    The Proxy and NoProxy configuration is now handled by a configuration files in x11_root:[resources].

  ---

• June 12^th, 1996
  
  • The last days had numerous crashes of the AXP cluster. The cause has been (hopefully) isolated. It is a combination of a bug in the FDDI driver in the new VMS version and a firmware bug in the GigaSwitsch FDDI channel card. The VMS systems produce sometimes a FDDI reset. The Gigaswitch FDDI channel card errorously forwards this Loop reset to the other 3 FDDI channels of the same card. This produces kind of a `reset storm' were all VMS systems on one card fire FDDI resets at each other. This lead to situations were AXP601/602 `thought' they were the lone survivors of the cluster, which in turn lead to a `voluntarily exiting cluster' crash of all other nodes when the reset storm ceased. A new Gigaswitch firmware will be installed on friday, also driver patches.

• June 6^th, 1996
  
  • The nodes VSBZ, AXP601, AXP602, AXP603, AXP604 and AXP612 had up to now a special setup for the communication with the MVS system. It used an FDDI connection via a channel-to-channel connection between the MVS system and rzri6f. This special datapath has now been dedicated for the copying of data from the old MVS tape roboter to the new one and is unfortunately not longer available for data staging.
    All stage and store activities will from now on use the MVS Ethernet connection and might therefore have a somewhat reduced bandwidth.

• June 6^th, 1996
  
  • The AXP cluster is unstable since the modifications done last week. The whole cluster hung up on
    • Monday night (June 3rd)
    • Tuesday night (June 4th); HSD controller swapped
    • Wednesday afternoon (June 5th); AXP601/2 memory increased
    • Wednesday night. (all except AXP601/602)

• June 3^rd, 1996
  
  • Disk $7$dkb200:(dl124), a 3.5 Gbyte DEC DSP5350S drive, finally broke down. This disk was unstable since several months (e.g. went into mount verify every week or so and had to be power cycled). It was replaced by $7$dkd0:(dl124), a 4.3 Gbyte Quantum XP34300W drive located in the 2nd Storage Works chasis.
    The path al_temp0 should now be available as before.
  • The defragmenter didn't work since the rearrangements done on April 4^th and all disks got slowly fragmented. The DEFRAG setup got fixed and all scripts were recreated to execute of AXP607.
  • The queue bz_system should now start again after a reboot.

  ---

• May 30^th, 1996
  
  • The whole AXP cluster was shutdown for two days and reconfigured. For a detailed account check the summary provided by the system management.

    AXP601 and AXP602 are not longer available for interactive use.
    They can however still be used for batch jobs !

    The replacement, a 4100 system with 1 Gbyte memory and 3 or 4 very fast CPU's will be installed within 4-6 weeks.

  • The node AXP612 was upgraded from a AXP 3000 Model 400 to an Alphastation 400 4/233. The CPU speed improved by about 50%, the memory capacity decreased slightly from 192 to 160 Mbytes. The screens AXP625 and AXP612 were swapped to match the graphic cards (the 400 has external synch).

• May 24^th, 1996
  
  • The area a01_temp0 was moved back to a central disk, this time $1$dia260:(DC032). This undoes the move from February 15^th and frees $34$dka100

  ---

• April 29^th, 1996
  
  • The node AXP601 was shutdown last thursday and will be unavailable for a few days because extensive hardware modifications are done. This causes all activities explicitely requesting AXP601 to fail. For example mail forwards from the VAX cluster to AXP601 will bounce. The email problem can be avoided by using the cluster alias name for the AXP cluster: CLEX2.
  • The IP alias DDAGSI5, setup to forward emails with old Bitnet style adddresses, became disfunctional in early February when the MX package was installed on the VAX cluster. All nodes except V6000A were configured to run MX. Unfortunately is DDAGSI5 an alias of V6000A, so all mails sent to DDAGSI5 either bounced or were lost.

• April 16^th, 1996
  
  • The volume set $7$dkb0,$7$dkb100(dl063,dl109) consisting of two older 2 Gbyte 5 1/4" disks (type DEC DSP5200S) was replaced by a single 4 Gbyte 3 1/2" disk (type Quantum XP34300). The new physical device name is $7$dka0. The volume name is dl063 and thus identical to the root volume name of the old volume set. This means that the change is transparent to all users.

• April 9^th, 1996
  
  • The logical kp3$root wasn't set consistently on all cluster nodes after the rearrangements on April 4^th. This got fixed during the easter weekend.
  • The whole Internet mail distribution hung up on April 4th around noon time (also because of the rearrangements). This got fixed this morning. No mail should have been lost, only delivered after easter instead of before.

• April 4^th, 1996
  
  • Our group server was replaced by a faster system:

    		old		new
                    -----------     ------------
       node		AXP604		AXP607
       model	400 4/233	600 5/266
       memory	192 Mbyte	256 Mbyte
    

    The new server with all KP3 disks on AXP systems is now located in the main computer room. This should prevent the heat problems we had in the last summer and might reduce the failure rate of our disks. The new server axp607 is about twice as fast as the old one and has slightly more memory.

    Please note that axp604 has been traded in for axp607 is not longer available to KP3 !

    Note, that axp612 with the two DLT drives as well as vsbz are still located in the printer room next to 4.168. axp612 is connect to FDDI as before and acts as a tape server.

    The all disk served previously by axp612 and axp604 are now attached to axp607. This should be transparent to all users since all logicals have been updated (or go by volume name anyway). Nevertheless here the mapping:

             old		      new		  Volume (set)
       ------------------   ------------------   ----------------------
       $4$dkb100,200,300    $7$dka100,200,300    dl175,dl176,dl177
       $4$dkb400,500,600    $7$dka400,500,600    dl178,dl179,dl180
       $12$dkb400,500	$7$dkb000,100	     dl063,dl109
       $12$dka100,200	$7$dkb200,300	     dl124,dl125
       $12$dka300	        $7$dkb400	     dl126
       $12$dkc0             $7$dkc100            dl154
    

  • The node vsbz was rebooted after an astounding uptime

      VAX/VMS V6.1 on node VSBZ 4-APR-1996 11:51:07.01 Uptime 157 01:49:35
    

    fix catchup with some software changes and in the hope that the SNMP hickup's go away.

  ---

• March 5^th, 1996
  
  • The disk $12$dkc0 (dl154), which is used as kp3$root started to fail (at least 4 files with bad blocks) and was replaced. All but the 4 files could be copied to a new disk. The 4 damaged files

      [KP3.BLAICH.PAW]BORMIO_RSQZPT.PS;1
      [KP3.POCHODZALLA.PAW.GJK.PIC]PAP_10.EPS;1
      [KP3.SCHNITT.LOGDIR]AD_PARTCORFINAL.LOG;3
      [KP3.ZUDE.PAW.S114.PIC]PRFR1EP4_AU600AU_HIPL.PS;1
    

    were recovered from a weekly backup. The disk, a Seagate ST15150N, was installed on December 15^th, 1994 and served as kp3$root since September 13^th, 1995.

  ---

• February 26^th, 1996
  
  • The TurboChannel SCSI Adapter on node axp612 was exchanged. The might fix the disk problems seen with dl124 on February 9^th, dl125 on January 22nd and before on November 3^rd, 1995. The removed adapter, type PMAZB-AA had SN: ME419M1408 Rev D01.
  • Reinstalled disk $12$dka200(dl125) which was removed on January 22^nd.
  • Exchanged the DLT drive $axp612$mkd100. It was replaced by a DLT2000XT drive on loan from DVEE. This might fix some of the tape problems we have recently seen. The removed drive had the GSI property number 75383.

• February 15^th, 1996
  
  • The disk $4$dkb300(DL177), part of the al_data0 volume set, went offline after a hard write error occured. All details are in the `Trouble Log'. Since this had happended already the night before, the disk was exchanged. Since no 4 Gb spare disk was available, the disk $1$dia540:(DC032), used as a01_temp0 was used as replacement. The area a01_temp0 was moved to $34$dka100, thanks to Wolfgang Schiebel.
    Note, that a01_temp0 is now on a system with only Ethernet connection and should not longer be used for high thoughput activities. The definition of sys$scratch for sessions on axp601 and axp602 has therefore been changed to al_temp0.
  • A 4Gb disk, former $4$dkb300(DL177),, type XP34300S-VA, SN: CX50941687, Rev: 589G, was send for repair.

  ---

• January 26^th, 1996
  
  • The specification of Internet email addresses has been simplified on the AXP cluster. It is not longer necessary to prefix an Internet address by MX% and to enclose it in quotes. It can now be entered in the normal form user@host. For details see the following note picked up from the OpenVMS Frequently Asked Questions by Steve Lionel on the newsgroup comp.os.vms:

       As of OpenVMS V6.2, this will not be necessary - if the address has
       an @ in it (not in a quoted string), MAIL will look to see if the
       logical name MAIL$INTERNET_TRANSPORT is defined.  If it is, it will
       use the translation as the transport protocol, otherwise it will use
       SMTP (as is used by UCX).
       For example, if you wanted MX% added, you'd define
            MAIL$INTERNET_TRANSPORT as "MX".
    

    The logical MAIL$INTERNET_TRANSPORT is now defined in the ALADIN login. Note, that the VAX cluster still runs VMS 6.1 and does not provide this function.

• January 23^rd, 1996
  
  • Changed the mailing lists to use the new MX transport. All mailing lists should now work as before.

• January 22^nd, 1996
  
  • The disk $12$dka200(DL125) failed (controler problems, didn't respond, caused unexpected interrupts) during the weekend, causing at least one hangup + reboot of axp612 and was removed. The al_temp0: volume set is now reduced to a single disk ($12$dka100(DL124)). All the contents of al_temp0: was lost, including the directory structure. It is unclear whether this failure is related to the previous power supply and fan failures (see November 22^nd and September 13^th).
  • A new Internet Mail System was installed on the cluster to resolve the mail delivery problems seen since January 8^th. The transport is now called MX% instead of SMTP%. Mail addressed starting with SMTP% are still accepted, so reply to old emails and private mailing lists should continue to work.

• January 8^th, 1996
  
  • Email problems on AXP cluster. There are problems with SMTP email delivery to AXP nodes since the UCX update last week. Emails sent from an AXP node fails with about 50% probability with the error

    %UCX-E-SMTP_UNREACHABL,  Can't connect to remote host, axp602.gsi.de
    -SYSTEM-F-LINKDISCON, network partner disconnected logical link
    

    The net effect is that SMTP mail delivery beteen VMS/UCX nodes is essentially defunct. Email from other platforms, where the mailer retries under those circumstances, may arrive, but can be late by up to several days.