hdstrace not working with nlines=all

[sfgraves]

When running hdstrace with nlines=all, it produces the value {undefined} instead of listing all the lines of data from an object. This is with starlink

E.g.

hdstrace /jcmtdata/raw/acsis/spectra/20210122/00025/a20210122_00025_02_0001.sdf.MORE.ACSIS.TSYS nlines=ALL

A20210122_00025.MORE.ACSIS.TSYS  <_REAL>

   TSYS(2,120)    {undefined}

End of Trace.

Compared with:

hdstrace /jcmtdata/raw/acsis/spectra/20210122/00025/a20210122_00025_02_0001.sdf.DATA_ARRAY.DATA nlines=1  

A20210122_00025.DATA_ARRAY.DATA  <_REAL>

   DATA(1024,2,120)  -11.89733,-4.511675,1.544914,3.954085,-13.13234,4.956867,-1.235989,17.21816,-4.497518,14.96377,-18.7552,5.318614,4.16908,4.720294,-2.569708,
                     ... 0.1043725,-1.097263,0.8056812,-2.177749,0.5972329,-1.044847,-0.7468292,-2.397368,-0.5133806,-3.408734,0.7813984,-4.92592,4.521579,-3.541235

End of Trace.

Additionally, if you prompt for the allowed values it states you can use ALL or ONE, but the ONE option causes an error:

hdstrace /jcmtdata/raw/acsis/spectra/20210122/00025/a20210122_00025_02_0001.sdf.DATA_ARRAY.DATA nlines=?
!! The choice ? is ambiguous.  The options are ALL,ONE.
!  Invalid selection for parameter NLINES.
NLINES - Number of lines to contain the data values /'?'/ > ONE
!! ERR_/EMS_BEGIN: STATUS set with no error report (improper use of EMS).
!  Application exit status SAI__ERROR, Error
!  /jcmtdata/raw/acsis/spectra/20210122/00025/a20210122_00025_02_0001.sdf.DATA_
!     ARRAY.DATA nlines=?

This is with starversion; (detached from 5092f03) @ 5092f03ece96912df46398cecee3ccbf2d6cdd58 (2021-02-23T03:56:52) at EAO in Hilo.

[grahambell]

It might be confused by determining the terminal width, because piping to cat works for me:

$ hdstrace /jcmtdata/raw/acsis/spectra/20210122/00025/a20210122_00025_02_0001.MORE.ACSIS.TSYS nlines=all | cat

A20210122_00025.MORE.ACSIS.TSYS <_REAL>

TSYS(2,120) 225.992,90.21307,225.992,90.21307,225.992,90.21307, 225.992,90.21307,225.992,90.21307,225.992,90.21307,225.992,90.21307, 225.992,90.21307,225.992,90.21307,225.992,90.21307,225.992,90.21307, 225.992,90.21307,225.992,90.21307,225.992,90.21307,225.992,90.21307, 225.992,90.21307,225.992,90.21307,225.992,90.21307,225.992,90.21307, 225.992,90.21307,225.992,90.21307,225.992,90.21307,225.992,90.21307, 225.992,90.21307,225.992,90.21307,225.992,90.21307,225.992,90.21307, 225.992,90.21307,225.992,90.21307,225.992,90.21307,225.992,90.21307, 225.992,90.21307,225.992,90.21307,225.992,90.21307,225.992,90.21307, 225.992,90.21307,225.992,90.21307,225.992,90.21307,225.992,90.21307, 225.992,90.21307,225.992,90.21307,225.992,90.21307,225.992,90.21307, 225.992,90.21307,225.992,90.21307,225.992,90.21307,225.992,90.21307, 225.992,90.21307,225.992,90.21307,225.992,90.21307,225.992,90.21307, 225.992,90.21307,225.992,90.21307,225.992,90.21307,225.992,90.21307, 225.992,90.21307,225.992,90.21307,225.992,90.21307,225.992,90.21307, 225.992,90.21307,225.992,90.21307,225.992,90.21307,225.992,90.21307, 225.992,90.21307,225.992,90.21307,225.992,90.21307,225.992,90.21307, 225.992,90.21307,225.992,90.21307,225.992,90.21307,225.992,90.21307, 225.992,90.21307,225.992,90.21307,225.992,90.21307,225.992,90.21307, 225.992,90.21307,225.992,90.21307,225.992,90.21307,225.992,90.21307, 225.992,90.21307,225.992,90.21307,225.992,90.21307,225.992,90.21307, 225.992,90.21307,225.992,90.21307,225.992,90.21307,225.992,90.21307, 225.992,90.21307,225.992,90.21307,225.992,90.21307,225.992,90.21307, 225.992,90.21307,225.992,90.21307,225.992,90.21307,225.992,90.21307, 225.992,90.21307,225.992,90.21307,225.992,90.21307,225.992,90.21307, 225.992,90.21307,225.992,90.21307,225.992,90.21307,225.992,90.21307, 225.992,90.21307,225.992,90.21307,225.992,90.21307,225.992,90.21307, 225.992,90.21307,225.992,90.21307,225.992,90.21307,225.992,90.21307, 225.992,90.21307,225.992,90.21307,225.992,90.21307,225.992,90.21307, 225.992,90.21307,225.992,90.21307,225.992,90.21307,225.992,90.21307, 225.992,90.21307

End of Trace.

[MalcolmCurrie]

I tried this with 2018A and nlines=all worked.

[sfgraves]

I think Graham has the right idea -- it produces the same error if I set width to 150 or larger (174 is the default value for my terminal). Note this was found by Harriet when trying to use this, so its not just me having a weirdly giant terminal.

[sfgraves]

And to be clear works for terminal sizes 149 and smaller using the width parameter.

[MalcolmCurrie]

Yes after playing around I found that the terminal width at 149 causes the undefined.

Not sure why ONE is a string option for Parameter NLINES..ONE is not 1. That option is not documented or used in the code, so simple removing it is the obvious fix, However,
I'm searching historical documents to see if there was a rationale, not implemented.

[sfgraves]

The magical size it works at seems to depend on which object you are looking at -- I think this might be due to size allocated for the name of the object at the start.

Specifically, for DATA_ARRAY.DATA it works with 149 and smaller, and produces the text "DATA(1024,2,120) " before the first number ( 19 characters ). For MORE.ACSIS.TSYS it works with 146 and smaller, and produces the text "TSYS(2,120) " before the first number (16 characters). For MORE.JCMTSTATE.TCS_PERCENT_CMP it works with 153 and smaller, and produces the text "TCS_PERCENT_CMP(120) " (23 characters) before hand.

So the longer the initial name, the more space is allowed for the terminal width before it produces an error. I think this might be due to some handling of the historical WIDEPAGE option that allowed a 132 character terminal, taking 132 and adding on the space for the initial name (with some extra spacing included in the name) instead of using the new terminal width value?

[MalcolmCurrie]

My test was with MORE.ACSIS.RECEPPOS.

Looks like the ONE option dates back to TRACE before it was renamed to HDSTRACE. I've not found a copy of Dave Baines's original code, and any printout from the early ADAM days is at RAL.

So who is going to tackle the screen-width bug? Don't want more than one of us doing it in parallel.

[sfgraves]

Do you want to? I can take a look if you can't, but my fortran programming skills are non existent.

[MalcolmCurrie]

OK, I'll do it, probably in the morning.

[MalcolmCurrie]

Fixed in Commit 9797c1ed709e718daf41d817056eb7eb816dcc59.

Identifying the cause and making the fix didn't take long, but I noticed another oddity that I've yet to track down. Although MSG_SZMSG is 300, I found that a correspondingly wide terminal had the displayed values truncated at 200 characters. The line was formed correctly in the TRA_PUTS routine. IThus my guess is that there is some other parameter constraining to 200 characters. Many of the numerous arbitrary ADAM parameters were set last century...