1. *Difficulties to reach SAM web interface sometimes * https://gus.fzk.de/pages/ticket_details.php?ticket=33045
   ANSWER: For the moment SAM portal is quite functional. Judit is now working to use better SQL queries in SAM portal.
2. *Last escalation step reached for site YerPhI* https://gus.fzk.de/pages/ticket_details.php?ticket=26634 => answer from site : "Hi, The SAM tests failures are caused by known issue in the SE software (https://gus.fzk.de/pages/ticket_details.php?ticket=30752). We have been advised to upgrade to the latest certified version. Currently we are trying to do that. Artem "

• making the service more suitable for use by the HEP VO
• extending the scope of the pre-deployment testing

1. ROC CE: There is a possible bug in latests lcg_utils (lcg_util-1.6.8-1.slc4). See https://gus.fzk.de/pages/ticket_details.php?ticket=33262
   All three PPS sites from ROC CE have problems with lcg-cr.

1. Glite 3.1.0 PPS Update 19 was released to production and it is now in pre-deployment testing
   
   • WN 3.1 for sl4 64bits
   • glite-LSF_utils
   • lcg-vomscerts-4.8.0 adds next cert for biomed + egeode
   • new version of lcg-ManageVOTag fixing bug #31848
   Release notes in:
   https://twiki.cern.ch/twiki/bin/view/EGEE/PPSReleaseNotes_310_PPS_Update19
   
2. A new update, gLite3.1.0 PPS Update20 is in preparation.
   This Update will introduce the MONBOX on the 3.1 baseline (for SLC4)

1. (ROC DECH): GGUS ticket because of JS failing SAM. Reason was that the test jobs hit the resource limit of the queue. SAM needs to be submissioned with proper requirements. (DESY-HH)
2. (ROC DECH): Problems with "larger" input sand boxes on WMS, where larger means 10MB or more. The WMS is configured to accept up to 100MB. Jobs go in running state but the input sand box does not arrive on the WN. GGUS ticket: 33136 (DESY-HH)
3. (ROC DECH): Problems with publishing accounting data: APEL claims that data are missing since quite some time (Oct 2007), actually we have published already since then, perhaps not all. The big amount of accounting records can then not be published failing with: Exception in thread "main" java.lang.OutOfMemoryError. We are getting tired spending every other week a lot of effort in this business. (DESY-HH)
   ANSWER:
   ** Has this been reported through GGUS? **
   a) I was aware of long-standing discussion between DESY and Dave but I cannot see an open GGUS ticket.
   b) DESY run multiple CEs and there have been problems with such sites but we have successfully got most of them running. We are also working with YAIM people to make configuring multiple CEs easier.
   c) The problem of catching up a large number of job records is recognised and a solution is being researched (but see d) Meanwhile Cristina has a manual method of helping sites catch up by inserting their data directly into the database. I am afraid it requires her manual intervention so it will have to wait. Following CERN's example I recommend sites which run a lot of jobs to publish more than once per day
   d) The Gap Publisher allows a site to publish for a specified time interval. This is designed to help sites fill gaps when publishing failed but can also be used to reduce the number of records published at once and thus reduce memory problems.
   
4. (ROC UKI): Why is MON not yet supported on SL4? Seems odd as it is java based!

1. FZK (GridKa) SCHEDULED downtime : 26-02-2008 08:30 to 10:30[UTC] AT RISK due to "After the dCache upgrade to patch 12p6 the pools have to be restarted which might take a while."
2. FZK (GridKa) SCHEDULED downtime: 10-03-2008 06:00 to 08:00[UTC] AT RISK due to "There is a network maintenance but it is unlikely that problems occur."

Time at WLCG T0 and T1 sites.

• Item 1