[daip] 31DEC09 LINUX midnite job (dave, 20100301.222716)

[aipsmgr at nrao.edu]

dave update report for 31DEC09 on Mon Mar  1 22:27:34 UTC 2010 (UT)

Copies and compiles:

AIPSUPD - Using CVS for copying files.
UPDCVS - cvs copy of 31DEC09 begun, 1st character means
 - U added, P updated, M your file differs from master
 - C you have a changed file needing work (error!)
 - ? you have a file not on the master (ignore)
? 31DEC09/ERRORS
? 31DEC09/LINUX/SUM-EFAGRELI
? 31DEC09/SUL/LIBRold
? 31DEC09/SUL/SYSTEM/NRAOAOC
U 31DEC09/TIMESTAMP
P 31DEC09/HIST/CHANGE.DOC
P 31DEC09/Q/PGM/NOTST/CVEL.FOR
P 31DEC09/UPDATE/COMLNK.UPD
U 31DEC09/UPDATE/COMLNK.UPD.SUM
U 31DEC09/UPDATE/LASTCVS.DAT
P 31DEC09/UPDATE/PUTBCK.UPD
U 31DEC09/UPDATE/PUTBCK.UPD.SUM
P 31DEC09/UPDATE/REASONS.UPD
U 31DEC09/UPDATE/REASONS.UPD.SUM
UPDCVS - cvs update of 31DEC09 completed
UPDCVS - cvs update of TEXT completed
AIPSUPD - UPDCVS apparently worked

UPDCONTROL - /home/AIPS/31DEC09/LINUX/UPDATE/LASTREMOVE.DAT = 20100211.165408
UPDCONTROL - /home/AIPS/31DEC09/LINUX/UPDATE/LASTCOPY.DAT = 20100211.165408
UPDCONTROL - /home/AIPS/31DEC09/LINUX/UPDATE/LASTCOMRPL.DAT = 20100211.165408
UPDCONTROL - /home/AIPS/31DEC09/LINUX/UPDATE/LASTCOMLNK.DAT = 20100211.165408

UPDCONTROL - Everything seems in order

UPDCOMRPL: COMRPLs


UPDCOMRPL: currently in /home/AIPS/31DEC09/LINUX/UPDATE

UPDCOMLNK: COMLNKs

01-MAR-2010 22:23:45 20100301 NEW QPGNOT   CVEL.FOR      egreisen

UPDCOMLNK: currently in /home/AIPS/31DEC09/LINUX/UPDATE
UPDCOMLNK: /home/AIPS/31DEC09/Q/PGM/NOTST/CVEL.FOR


UPDCONTROL - Reasons for file updates on Mon Mar  1 22:27:28 UTC 2010 (UT)

01-MAR-2010 22:23:18 20100301 NEW HIST     CHANGE.DOC    cvel
01-MAR-2010 22:23:35 20100301 NEW QPGNOT   CVEL.FOR      time inaccuracy, single-source fail to shift

CHANGE.DOC entries:


13092.  March 1, 2010            CVEL                   Eric
        My recent code contained the ability to go into an infinite
        loop when minor roundoff errors with times arose.  Added a
        slight extra bit to the time and added other checks to avoid
        the infinite loop.
        BUT - in the course of testing, I found that with
        single-source files, the source name was null which prevented
        the message showing the shift or lack thereof from being
        completed properly.  With single-source files having an index
        (NX) table, the task only shifted the first scan!  This fact
        was obscured by the error in the source name.  Corrected.
        Moved to patch this date.  The lack of shift is old and maybe
        needs to be in the NRAO newsletter.