outdisk/fits or related

[Michel Laget <mlaget@free.fr>]

Config: midas NOV99pl2.2 on intel_linux pII, RedHat 7.0 


Dear list, 

One point that may possibly bring some clue to the recent outdisk/fits
discussion: It looks like "outdisk/fits" becomes extremely slow ones a
table has been selected. Reading the descriptor selidx returns an 
error.   

Here below is the result of a midas sript which consists of 
getting a fresh table (tmp0); sh/tab and read/desc read correct. 
outdisk/fits takes about 8sec to perform. 
read/desc tmp0.tbl selidx 
adequately returns "...does dot exist." 

Now, the same table is selected on (say) the seq and the table copied
into tmp1: 

SELECT/TAB tmp0 seq.le.400000                                           
COPY/TABL tmp0 tmp1
READ/DESC tmp0.tbl *,selidx

frame: tmp0.tbl  (data = R4)
TBLENGTH:
 436207617 436207617 167772161 436207617         0         0         0
TBLOFFST:
         4         8        12        16         0         0         0

................everything reads ok

SH/TAB tmp1
 Table : tmp1                            [Transposed format]
 No.Columns :       4   No.Rows :  400000 
 All.Columns:       7   All.Rows:  400000         Sel.Rows:  400000
 Sorted  by :Sequence  Reference:Sequence     
 Col.#   1:X                Unit:PIXEL            Format:E15.5  R*4
 Col.#   2:Y                Unit:PIXEL            Format:E15.5  R*4
 Col.#   3:FRAME            Unit:FRAME            Format:I9     I*4
 Col.#   4:tsec             Unit:                 Format:E12.6  R*4
 Selection: ALL

................everything's ok


OUTDISK/FITS tmp1.tbl name=input t .mt
tmp1.tbl written to FITS file tmp1.mt
WRITE/OUT elapsed time for outdisk/fits = 0065

8 time longer than the parent table. 
A slightly longer table could take hours 

The only anomaly i could find is on the reading of the descriptor 
selidx which returns an error.All others are correct. The table can 
be read and SH/TAB is normal.

READ/DESC tmp1.tbl selidx
frame: tmp1.tbl  (data = R4)
(ERR) Problems in executing /midas/99NOVpl2.2/prim/exec/descr.exe
Ln.@d killed by signal 11

NOTE: the same sript runs without any difficulty on a more than 4 meg
lines comparable table with NOV99pl2.0 for OSF1/AXP.

Does anyone had the same experience or have an idea? 

Thank you.

M. Laget

PS: - this the first time i have noted such an effect though i am 
      used to back-up via outdisk and gzip. 
    - I have re-installed intel-linux 99NOVpl2.2