What's new in KP3 computing ?

---

• November 21^st, 1997
  
  • The area a01_temp0, which was created on May 20^th, 1995, has been withdrawn. The disk $1$DIA260: (DC032) now hold the area al_data2. The root directory was renamed from ALADIN_TEMP to ALADIN_DATA.

• November 20^th, 1997
  
  • The disk $1$DIA260: (DC032 holding a01_temp0) had more than a million blocks in lost files in [SYSLOST]. All those files have been removed. All other disk volumes were checked for [SYSLOST] files, just one was found.

• November 17^th, 1997
  
  • The default extend size for some disks was reset to reasonable values. Some operations (disk exchange ect.) in the past had obviously changed the extend sizes from the values setup on July 13th, 1995 and August 28th, 1995. Here the current situation:

    Volume(set)	Old extend size	New extend size
    kp3$root	256	256
    al_prod0	64	1024
    al_data0	64	1024
    al_data1	5	1024
    al_pool0	1024	1024
    al_temp0	1024	1024
    a01_temp0	1024	1024
    a25_pool0	63	1024
    a27_pool0	1024	1024

    To recheck simply use

      $ pipe sho dev al_data0 /full | grep "Extend"
    

• November 3^rd, 1997
  
  • The mailing lists ALADIN, KP3 and ALADIN-INDRA have now an archive. See the list of archives.

  ---

• October 20^th, 1997
  
  • On some nodes the From: field of DECnet mails send with VMSmail is corrupted.
  • Netscape was updated from V3.0b8Gold to V3.03b1Gold.

• October 15^th, 1997
  
  • The volume DL154, holding kp3$root, has 101460 files.

• October 14^th, 1997
  
  • The Xterm XWTAU returned from repair, the spare unit XWTCD obtained on August 12^th was returned.
  • The AXP cluster hung up on the evening of October 14^th, the evening of October 13^th and on the evening of October 10^th due to problems with the system disk shadows sets. A full cluster reboot was needed.

• October 10^th, 1997
  
  • The screen of Xterminal XWTAV (blured picture) was send to repair.

• October 9^th, 1997
  
  • The node VSAO, a VAX-3100/M30 system with 28Mb memory and a dual-head grafics configuration, was finally retired.

• October 1^st, 1997
  
  • The DO_CRON job for daily system maintenannce has been moved from the VAX to the AXP cluster.

  ---

• Septemper 25^th, 1997
  
  • Our VAX systems are outdated and rarely used for production work anymore. The low usage does not anymore justify to keep this platform up-to-date and operating. It is therefore planned to discontinue usage of the VAX cluster by end of this year. All applications and data should have been moved to the AXP cluster by this time.
  • The automatic update of CMS libraries on the VAX cluster has been discontinued for all application libraries. Since outdated files produce more confusion than good all affected reference copy areas have been removed:

    	ref_alib    ref_tfit    ref_mclib    ref_mc117
    	ref_s114    ref_s117    ref_wtb      ref_wpb
    	ref_amold
    

    The areas ref_asoft and ref_amgr are still available and updated.
  • The accounts

    	aichelin
    	gelbke
    	gjk [kunde]
    	hofmann
    	kunze
    	mahi
    	milano
    	sann
    	seidel
    	zwieglinski
    

    have been terminated on the VAX cluster. All files were backedup, email is forwarded. The files of all those accounts were essentially inactive since beginng of this year.
    The account markert has been moved to kp3$aroot:.

• Septemper 22^nd, 1997
  
  • The system disk on the central AXP systems filled up. This caused several services to block. Batch and print jobs may have been affected. Incoming emails may have been lost. Also emails send to the VAX cluster and forwarded to the AXP cluster may have been lost. Note, that failures were spotty, some things worked, others didn't.
    As far as reconstructable the problems started late friday, September 19^th, or early saturday, September 19^th, and were resolved during monday, September 22^th.

  • A problem using the cluster alias CLEX2 has been fixed. It caused emails forwarded from the VAX cluster to the AXP cluster with forwarding addresses of the form CLEX2::username to fail.

  ---

• August 27^th, 1997
  
  • The default login device was changed for all KP3 accounts to kp3$root. About half of the accounts had for historical reasons a default login device of kp3$broot, which however translates to the same disk device.
  • The netscape command was changed to allow only minimal priviledges for the subprocess executing Netscape.

• August 19^th, 1997
  
  • The WWW server moved from the VAX to the AXP cluster. For details check "What's new on the KP3 Web".

• August 12^th, 1997
  
  • The disk $9$DKA400: (DL094 on VSBZ), which failed around July 24^th, has been repaired and reinstalled. The power supply was broken, no data were lost.
  • The Xterm XWTAU was exchanged against XWTCD. The unit XWTAU has a broken grafics card and produces a rather poor display quality, especially for WinCenter screens.

• August 4^th, 1997
  
  • Recent changes in command procedures caused for some users sometimes

        %SYSTEM-F-EXLNMQUOTA, logical name table is full
    

    errors. This well known problem has been fixed for all active accounts by incresing the JTQUOTA quota to 32000.

  ---

• July 31^st, 1997
  
  • The AXP cluster uses now VMS V7.1 !
  • A new node AXP606 is now available. It is a 4 CPU system with 1.5 Gbyte memory. It should be about 15% faster than AXP605. KP3 financed one CPU on this machine.

• July 24^th, 1997
  
  • The disk $9$DKA400: (DL094 on VSBZ), holding the bz_temp0: area, failed sometime around July 24^th The disk is a rather old DEC DSP5200S drive with 2 Gbyte capacity. The power supply seems to be broken.

  ---

• June 13^th, 1997
  
  • The ACL entries for the masterfile directory on DISK$DL175 were lost, preventing the creation of new directories. The ACL's were recreated.

  ---

• May 27^th, 1997
  
  • The disk containing KP2$ROOT had to be replaced due to disk errors.

• May 22^th, 1997
  
  • The AXP cluster was rebooted for maintenance reasons. Afterwards, the backspace key did not work on Tektronix Xterminals. All Xterminals had to be rebooted.

• May 12^th, 1997
  
  • The disk $7$DKA500 (DL179), which failed on May 9^th, was replaced by a disk of the same type (Quantum XP34300).
    The al_pool0 area was restored from a backup taken on 7-MAY-1997 19:20. All updates done after that time are lost.

• May 9^th, 1997
  
  • One disk of the al_pool0 volume set failed. The disk $7$DKA500 (DL179), a QUANTUM XP34300, goes into the "mount verify" state when accessed. It recovers after some time, but it's not possible to read more than a few thousand blocks.
    Note, that the disk $7$dka600, which is another member of the three member (dka400, dka500, dka600) volume set al_pool0 had been changed on February 3^rd.

  ---

• March 24^th, 1997
  
  • Two more disks failed on central systems. Affected were cern$root on the AXP cluster and kp2$root on the VAX cluster. Both clusters had to be rebooted, the AXP cluster was back around 12:00 (cern$root was available at 17:00), the VAX cluster came back at 9:00 the following day.
    The mail delivery on the VAX cluster hung all monday. Most emails were delivered on tuesday morning, but some mails may be been lost.

• March 18^th, 1997
  
  • Node axp612 (failed on March 15^th) is back operating. The processor board was replaced.

• March 15^th, 1997
  
  • Node axp612 crashed at 06:19 and couldn't be rebooted.

• March 14^th, 1997
  
  • Various software upgrades on AXP and VAX cluster, for a detailed list check the release notes in sys$help:

    	$ dir sys$help:*.release_notes /since=14-mar
    

  • Two more Quantum XP34300W drive were changed on central systems because of hard errors.

• March 3^rd, 1997
  
  • Two disk drives failed (or were about to fail) and were replaced on central systems. This time two Quantum XP34300W drives. The local scatch area on axp605 was reinitialized.

  ---

• February 18^th, 1997
  
  • All AXP nodes needed a reboot. Problem: DECterms didn't start after an ECO ws installed yesterday. A reboot was the only way to get a consistent system state.

• February 17^th, 1997
  
  • The failed disk $12$dka300 (AXP612_62745) (see February 11^th), was replaced with SEAGATE ST31200N drive. The failed drive had a head crash (at least it sounds like), so all stored data (some backup log's) was lost. The area al_prod0 was reinitialized.
  • The secondary pagefile used by axp612 on disk$dl154 was removed. This increases the free space in kp3$root from about 800000 to over 1600000 blocks.
  • Discovered that the disk $9$dka200, holding the area kp3$broot on the VAX cluster, dropped somehow out of the backup scheme. The last full backup was obviously taken on 10-APR-1996 19:44. The backup of this disk was done via a procedure on node Fritz (V6000A) and is was forgotten to migrate this to AXP101 when Fritz was decommissioned in June 1996. A full backup was taken, the disk is now back in the general backup scheme.

• February 11^th, 1997
  
  • Yet another disk failed. This time $12$dka300 (AXP612_62745), a 1 GB RZ26 disk holding the primary pagefile for axp612 and the area al_prod0. The disk had some hard read errors lately which were, at least in part, responsible for some of the recent crashes of axp612.
    The node node axp612 runs now with just the secondary page file located on disk$dl154 (see September 19^th). This volume was moved on April 4^th from axp612 to axp607, so part of the paging of axp612 went over the FDDI backbone ever since...

• February 3^rd, 1997
  
  • One disk of the volume set containg al_pool0 failed on January 30^the and was replaced (by a disk of same make, type and location: Quantum XP34300 as $7$dka600 (dl180)).
    The al_pool0 area was restored from a backup taken on January 24^th between 18:00 and 21:00. All files created after this time are lost.
    One file ([SCHNITT.MEV150]T_T_50.DAT;2) had a unrecoverable disk error at the time the backup was taken and is probably corrupted.
  • The disk containing the al_temp1 area was exchanged again (replacing a narrow with a wide SCSI RZ29B drive) and relocated ($7$dkd100 instead of $7$dkd0). All data was copied, access to the path al_temp1 should be as usual.
  • The area data_s022 has been backedup and removed. This area was located on the same volume as bz_temp0. The logical data_s022 has been withdrawn.
  • The files data_s031:[music]*.dst have been backedup and removed.
  • The logical splitt of the volume containing the scratch area al_temp0 (see December 19^th) was undone and the full capacity of al_temp0 restored.

  ---

• January 30^th, 1997
  
  • The disk $7$dka600 (dl180), part of the al_pool0 volume set, starts to fail. The disk had 3 hard and 5 soft errors since January 1st.
  • Disabled Defragmenter for disk$dl178,179,180 volume set.

• January 24^nd, 1997
  
  • The stageing of S114 and S117 raw data is working again. The procedures:

    	ref_s114:stage_s114_raw
    	ref_s114:stage_s114_red
    	ref_s114:stage_s114_hbk
    	ref_s117:stage_s117_raw
    	ref_s117:stage_s117_red
    

    have been modified to work with the new ADSM tape robot system. They all use the new procedure ref_ulib:stasto_adsm.com.
    Please note, that all staging is currently synchronous. Note also, that ADSM access is only available on the AXP cluster.
  • Some accounts on the AXP cluster had a default directory protection of (RWE,RWE,RE,E), which means that a directory can not be browsed by other users. All directory protections of those accounts have been changed to (RWE,RWE,RE,RE), allowing everybody to see the directories. Affected accounts were:

    	BOTVINA GOURIO HERRMANN INDRA MARKERT LUEHNING TAKAHASHI
    

    Note: This affects only the ability to list the directories. The file access permissions were not changed !

• January 22^nd, 1997
  
  • The systems vsbd and vsbl (shut down on January 17^th), were transfered to KPI and are operating as an Xterminal. The disks DL045 and DL064 were transfered too.

• January 21^st, 1997
  
  • The retention date recording wasn't enabled for the volumes dl126 (holds al_temp1 and dl175,dl176,dl177 (holds al_data0). This slipped in when those disks were swapped on January 10^th and December 17^th, respectively. The problem was corrected, the automatic cleanup on al_temp1 should work properly again.

• January 17^th, 1997
  
  • Some of our oldest VAX-VMS systems were retired this week:

            VSAG   VSAH   VSAW   VSBD   VSBL
    

    The oldest system, node VSAG was in operation since 1990. The local disks of these systems were backedup. The following pool areas are not longer available:

     Node  Device       Label  Pool      Size    VUPS  Comment
    
     VSAG  $15$DKA300:  DL012  AG_POOL0  105Mb    2.1
     VSAH  $16$DKA300:  DL014  AH_POOL0  105Mb    2.1
     VSAO  $25$DKA100:  DL025  AO_POOL1  663Mb    2.1  Node available, disk retired
     VSAW  $38$DKB400:  DL034  AW_POOL0  663Mb         Disk crashed, NO FINAL BACKUP
     VSBD  $45$DKB100:  DL044  BD_POOL0  1.04Gb   7.6
           $45$DKB200:  DL045  BD_POOL1  1.04Gb
     VSBL  $55$DKB0:    DL064  BL_POOL0  1.04Gb   7.6
     VSCE  $68$DKA100:  DL110  CE_POOL1  426Mb         Node available, disk retired
    

    The logical names of the pools listed above have been removed. The logical bl_temp0, which was at the end just an alias to bl_pool0, was removed too.

    Note, that the systems (type VAX-3100/M30 and VAX-3100/M76) had a performance level of 2.1 and 7.6 on the VUPS scale. For comparison, the AXP607 has a rating of about 180. In case you don't buy that difference consider that VSBZ is about twice as fast as VSBD, AXP625 about three times VSBZ, AXP612 about twice AXP625 and AXP607 about twice AXP612.
    In summary, the oldest of the retired systems (VSAG,...) had only one percent of the CPU power of the newest (AXP607) systems.

• January 10^th, 1997
  
  • The disk $7$dkb400, one of our old 3.5 Gbyte DEC DSP5350S drives, was needed as a spare part for an Ultrix system and was replaced with $7$dkd0, a 4.2 Gbyte RZ29B drive. All data was copied, access to the path al_temp1 should be as usual.
  • The disk $7$DKB300:(DL125), our last DEC DSP5350S 3.5 GB disk drive, was found to be dead.

• January 2^nd, 1997
  
  • The AXP cluster worked well over Xmas and new year. The whole cluster was rebooted this morning to introduce a patch (fix Telnet remote login problem).