iraf.net

I'm trying to reduce some data from the CTIO smart data. I'm using some scripts written by Phil Massey, which ought to mean they work perfectly , but I'm having a problem that neither I nor Phil can figure out.The symptom is that a task is being reported as having no param file, i.e,
cl> y4kphot
Py051109.0006
Py051109.0007
Py051109.0017
[snip bunch of lines]
Py051109.0096
Py051109.0097
Py051109.0098
ERROR on line 35: task `y4kphotit' has no param file
y4kphot ()
y4kphot ()
cl> However, I belive I have the tasks defined properly in my login.cl file,
[gsh@libra ~/iraf]$ grep phot loginuser.cl
task $y4kphot=/opt/massey/y4kphot.cl
task y4kphotit=/opt/massey/y4kphotit2.cl
$ ls -al /opt/massey/y4kphot*.cl
-rw-r--r-- 1 gsh gsh 813 Oct 7 14:25 /opt/massey/y4kphot.cl
-rw-r--r-- 1 gsh gsh 674 Oct 7 15:05 /opt/massey/y4kphotit2.cl
[gsh@libra ~/iraf]$I'm running iraf PC-IRAF V2.12 on a 64 bit dual opteron with Fedora Core 5.Does anyone have any sugguestions?

Two possible issues: The "snip bunch of lines" makes me think this is a file descriptor leak, i.e. as the script (??is it a script??) processes each file it uses new FD for each file until it runs out. This most often happens in a construct like[code:1:96154a841e]
list = myfile
while (fscan(list,x,y) != EOF) {
.....
}
list = ""
[/code:1:96154a841e]The last line effectively "closes" the file and may be what's missing. Check also your underlying environment with a "limit descriptors" (csh version) command, the iraf limit is something like 4096.A second issue may be an underlying 64-bit filesystem in which the inode for the file isn't 'seen' because of 64-bit support issues. Since the error is on the uparm file I don't think this is the case however. Hope this helps.Cheers,
-Mike

I added a line
flist = "" to the script, but the behavior did not change.My environment is
[gsh@libra massey]$ limit
cputime unlimited
filesize unlimited
datasize unlimited
stacksize 10240 kbytes
coredumpsize 0 kbytes
memoryuse unlimited
vmemoryuse unlimited
descriptors 1024
memorylocked 32 kbytes
maxproc 16379If it were the 64 bit issue you referred to, how might I test that possibility?

I just discovered the weirdest thing. I made a copy of the script so I could endit it down to try to find the smallest script that worked, thinking that might help isolate the problem, and having defined a new task in my loginuser.cl file
I found that the copy runs.I thought computers were *supposed* to be repeatable.This is probably some subtle bug that will be almost impossible to debug properly.