[daip] Problem with LISTR

[David Titterington]

> David Titterington writes:
> 
>  > A user reports recent problems with the behaviour of LISTR in the 31DEC04
>  > release of AIPS, which is being updated regularly via the midnite job:
>  > 
>  > > Trying to run LISTR (with OPTYPE='SCAN', to list the scans in a UV dataset)
>  > > gives this message (in the main window, not the message window):
>  > > 
>  > > >go listr
>  > > > ZTTYIO: INVALID NCHARS =   0
>  > > >AIPS 1: Resumes
>  > > >AIPS 1: RETURN CODE      1 RECEIVED: STOPPING
>  > > 
>  > > when trying to write to the screen, whereas writing to a file
>  > > gives no error, but has only the odd character at the beginnings
>  > > of lines, as per printout.
>  > 
>  > 
>  > Further tests show the same behaviour for another user, another dataset:
>  > 
>  > ----------
>  > >docrt 0
>  > >go
>  > LISTR1: Task LISTR  (release of 31DEC04) begins
>  > LISTR1: ZLPOPN: printer file = /tmp/ZLPOPN.a19099
>  > AIPS 1: Resumes
>  > >LISTR1: request id is oki-744 (1 file)
>  > LISTR1: Messages sent to the Oki Microline dot matrix printer
>  > LISTR1: a child process will delete /tmp/ZLPOPN.a19099 in 300 seconds
>  > LISTR1: Appears to have ended successfully
>  > LISTR1: mraosv       31DEC04 TST: Cpu=       0.1  Real=       1
>  > 
>  > >docrt 1
>  > >go
>  > LISTR1: Task LISTR  (release of 31DEC04) begins
>  >  ZTTYIO: INVALID NCHARS =   0
>  > LISTR1: MATXUV: ERROR    2 DOING I/O TO TERMINAL
>  > LISTR1: Purports to die of UNNATURAL causes
>  > LISTR1: mraosv       31DEC04 TST: Cpu=       0.0  Real=       0
>  > AIPS 1: Resumes
>  > AIPS 1: RETURN CODE      1 RECEIVED: STOPPING
>  > ----------
>  > 
>  > where in the case of output to a file, only the initial letter of each line
>  > is printed.
>  > 
>  > Is this a known problem with the current version of AIPS?
> 
> We do not release aips for more than 1 day with a known problem.
> 
> I would guess - since the problem does not occur here - that something
> went wrong with your MNJ.  The call sequence to LPOPEN subroutine was
> changed to return the number of characters in a line.  The two errors
> you report look as if what is taken by LISTR.FOR is the error return
> (0) from the old version of the subroutine.
> 
> Needless to say, this should not happen.  The MNJ is supposed to
> detect failures in compiling subroutines and to then not do link edits
> and to repeat the process the next day.  The link can fail sometimes
> because the attempt to rebuild the libraries fails (usually /tmp has
> not enough room) but again that is supposed to be detected and to
> cause failure.
> 
> Let's try the following
> 
> cd $AIPS_ROOT
> source LOGIN.CSH   (or . LOGIN.SH)
> $CDTST
> more $APLSUB/LPOPEN.FOR    - is NACROS in the call sequence?
> 
> If yes - then CVS has probably worked fine (it always seems to)
> 
> cd $TST/$ARCH/UPDATE
> change each of LAST*DAT* to
> 
> 20040516.034550
> 
> Then re-run the MNJ and check things closely - look at COMRPL.LOG and
> COMLNK.LOG in this area.
> 
> Eric Greisen


Thanks, Eric.  That seems to have tidied things up and LISTR now runs
correctly.  I'm not sure what went wrong with the midnite job (the last
update to LPOPEN was picked up by our weekly job run on Jun 07, which
didn't report any problems, although I didn't check the COMLNK.LOG file
that day).

Thanks again for your speedy response.

David Titterington,
MRAO, Cambridge.