====================================================================== Status 02/17/2000 T. W. Switched from MEX-MKI3 server to MEX-HERA server for all data to be fetched from the machine group. MEX-MKI3 is being outphased so HERA run numbers and state has to be fetched now from MEX-HERA. New header file hera.h (myhera.h) combines all machine relevant data. Used now instead of herap.h and herae.h for all clients. ====================================================================== Status 01/05/2000 T. W. Fix for Y2K bug in writing H1STATUS file is available but not yet implemented. Did a workaround for the server code in taking the UNIX timestamp from the data field as global timestamp for the H1 logging information (which is ok). ====================================================================== Status 01/03/2000 T. W. Found Y2K bug in source for H1 data. Date is in readable format corrupted due to wrong usage of IDATE in a FORTRAN subroutine belonging to the info and message daemon running on dice1 and communicating with the Supervisor. FPS data is ok. Lumi data status is unknown. ====================================================================== STATUS 26/11/99 T. W. Checked H1 NextMEX code for Y2K bugs. Handling of time and dates are done either with UNIX timestamps or converted into the MEX style date format with four digits representing the year. Used for conversion is the UNIX system function strftime which is Y2K compliant on IRIX 6.2. All the NextMEX data represented by Netkeys are accompanied by a UNIX timestamp. No Problems expected for transferring the data to other NextMEX clients. However sources for the H1 server are not checked. FPS server will be changed to NT system in December. Info for H1 depends on the H1 logging task and daemons, info for lumi system depends on several task running on lumi Sparcboard and Macintosh computers. No info about Y2K issues there. ======================================================================= STATUS 26/11/99 T. W. Switched server version to newest 3.05 release (TINE compatible). Changed the fill routine for getting the data from MEX files into the server due to changed design structure of the NextMEX code. Removed lumi keys from the h1server.h file. Lumi values are now only accessible by the H1 lumi server (h1lumi.h). Removed also the Lopez monitor values cause of no use by others. Remote tool does work now with the new code. Changed also the equipment name to MEX-H1, old name was DICE1. No problem when one uses the herans.csv file for getting the correct IPs for given Equipment names. Runs well. ======================================================================= STATUS 26/03/99 T.W. Fixed bug with synchronous call to FPS PC. After rebooting the PC the connection between PC Server and dice1 client wasn't reestablished. For the FPS PC still synchronous calls are used which have to reinitiated every system cycle. Call "SystemCycle(TRUE)" was at a wrong place outside the loop in "mexwrite.c". ======================================================================= STATUS 18/03/99 T.W. For the H1STATUS files all lumi values are not updated. Maybe due to the "new" logging, for which the communication between Supervisor and dice1/Lumi System is different. H1SHIFTS list is still taken via personal script from an old location -> no shift names available. on server and also for all MEX related files Restarted status to get the html file with H1 information. ======================================================================= STATUS 03/03/99 T.W. Problem with beam lifetimes fixed. Was a cabling problem on the front end. However, in consequence, key names for NextMEX were changed and hence the mexwrite client had to be rewritten. See HERINFO.KEY in /usr/log for changes. Now only HERAINFO, HERABINFO and FPSINFO are the written MEX files by mexwrite, H1STATUS is produced by the logging job (sgimsg). ZEUSINFO, HERMESINFO and PKTRINFO are not anymore available. ======================================================================= STATUS 15/11/98 T.W. HERAINFO seems still to get the same lifetime values for protons and electrons. Checked keys in code->ok, seems to be a provider error on MKI server, to be checked with machine group ======================================================================= STATUS 23/10/98 T.W. 1/ mexwrite and fpsmexwrite are combined -> problem: that breaks the hermes client stuff in that sense that subscribing is not possible although the server is seen by the client. all other client parts are ok. old server software at hermes ? However only the mexwrite process has to be run. 2/ Nothing done on PPU part, still working however pathologic. 3/ ZEUS LPS part shifted on server side to the main server -> to be changed on my side. At the moment no LPS data is correct, all zero. ======================================================================= STATUS: 20/10/98 TW only connection to gotland is: * fetch /tmp/H1SOLCOMP via scp from gotland -> /usr/log * fetch actual.data of ppu from /h1mex/ppu on gotland -> rpc ... also via scp Next to that there are no more connections to other computers via TCP/IP. The NextMEX client mexwrite/fpsmexwrite running via UDP/IP. On gotland no server is running, only remote accesses vi scp are done. All jobs are running on dice1 and being monitored via crond. Moving files around which are needed for the reco status is done now from getinfo, too. h1wgsinfo is not used anymore. Some links are pointing from /usr/log to ~h1 on dice1 which has the effect that the reco status cannot be displayed properly on h1 workgrouservers. However all MEX files can be seen on h1wgs. H1STATUS is up again, so no actions taken anymore for that. The following processes have to be run on dice1: 1/ mexwrite 2/ fpsmexwrite -> obsolete 20.10.98 3/ h1mexsrv 4/ copyH1MAGNETS 5/ getinfo 6/ h1wgsinfo -> obsolete 20.10.98 7/ rwPpuData -> obsolete 03.03.99 1,2,3,7 sind fuer den NextMEX Server 1,2,4,5,6 fuer den xctrspy H1STATUS Status -> sieht ok aus, wird von sunmsg/sgimsg geserved. =======================================================================