[daip] GETHEAD

[Eric Greisen]

Lincoln Greenhill writes:
 > Dear Eric,
 > 
 > I have investigated the problem further.
 > 
 > I experience anomalous behavior of GETHEAD for a particular 
 > VLBA data file on which I have run MERGECAL, MSORT (in place sort),
 > CPASS, FRING, CLCOR, CLCAL, SNCOR, etc as part of a "standard" VLBA
 > line reduction.
 > 
 > Below I list (1) the end of the file header, (2) a procedure I have
 > written to list what GETHEAD thinks are the extension tables, and (3) the
 > output of the procedure.
 > 
 > Please note that (1) for the problem-file, following the BP table, GETHEAD
 > behaves strangely, (2) a TASAV archive of my FITLD output (w/ no further
 > processing) does not trigger anomalous behavior in GETHEAD, and (3) a
 > TASAV archive of the problem-file does _not_ trigger the anomalous
 > behavior in GETHEAD. Could CPASS cause the problem?
 > .
 > .
 > .
 > AIPS 2: Coordinate equinox 2000.00
 > AIPS 2: Maximum version number of extension files of type HI is   1
 > AIPS 2: Maximum version number of extension files of type CL is   8
 > AIPS 2: Maximum version number of extension files of type AT is   1
 > AIPS 2: Maximum version number of extension files of type NX is   1
 > AIPS 2: Maximum version number of extension files of type IM is   1
 > AIPS 2: Maximum version number of extension files of type CT is   1
 > AIPS 2: Maximum version number of extension files of type MC is   1
 > AIPS 2: Maximum version number of extension files of type SN is   9
 > AIPS 2: Maximum version number of extension files of type OB is   1
 > AIPS 2: Maximum version number of extension files of type GC is   2
 > AIPS 2: Maximum version number of extension files of type PL is   2
 > AIPS 2: Maximum version number of extension files of type TY is   2
 > AIPS 2: Maximum version number of extension files of type WX is   1
 > AIPS 2: Maximum version number of extension files of type PC is   2
 > AIPS 2: Maximum version number of extension files of type BP is   2
 > AIPS 2: Maximum version number of extension files of type FQ is   1
 > AIPS 2: Maximum version number of extension files of type AN is   1
 > AIPS 2: Maximum version number of extension files of type SU is   1
 > AIPS 2: Maximum version number of extension files of type CQ is   1
 > AIPS 2: Maximum version number of extension files of type FG is   2
 > AIPS 2: Keyword = 'OLDRFQ  '  value =  4.28140300D+10
 > 
 > 
 > 
 > AIPS 2:  1 PROC TESTTEST
 > AIPS 2:  2 FOR I=1 TO 25
 > AIPS 2:  3 KEYWORD 'EXTYPE'!!CHAR(I)
 > AIPS 2:  4 GETHEAD
 > AIPS 2:  5 PRINT KEYSTRNG
 > AIPS 2:  6 END
 > AIPS 2:  7 RETURN
 > AIPS 2:  8 FINISH
 > 
 > AIPS 2: 'HI              '
 > AIPS 2: 'CL              '
 > AIPS 2: 'AT              '
 > AIPS 2: 'NX              '
 > AIPS 2: 'IM              '
 > AIPS 2: 'CT              '
 > AIPS 2: 'MC              '
 > AIPS 2: 'SN              '
 > AIPS 2: 'OB              '
 > AIPS 2: 'GC              '
 > AIPS 2: 'PL              '
 > AIPS 2: 'TY              '
 > AIPS 2: 'WX              '
 > AIPS 2: 'PC              '
 > AIPS 2: 'BP              '
 > AIPS 2: '                '     <---------- 
 > AIPS 2: '                '     <----------
 > AIPS 2: 'FQ              '
 > AIPS 2: 'AN              '
 > AIPS 2: 'SU              '
 > AIPS 2: 'CQ              '
 > AIPS 2: 'FG              '
 > AIPS 2: '                '
 > AIPS 2: '                '
 > AIPS 2: '                '

This really is not anomolous behavior.  Blanks with no extension
numbers are allowed.  IMHEADER does not display them (it would if
there were any files associated with that location).  You could run
your proc getting EXTVERn and printing KEYVAL and you will see 0's for
the empty slots.  Perhaps CPASS uses these for its purposes and then
clears them...

Eric