iraf.net

Dear Iraf Gurus, I am running an infrared reduction task I wrote and I am
getting an odd error message: "INTERNAL ERROR on line 108: dictionary
full." The line number reference is not helpful, it appears to be
occurring in a call to an external fortran/imfort program I wrote.
I doubt it is a problem in the program...the error occurs after the
calling task calls it ~430 times (and it does this consistently).
The disk is definitely not full, there is still some 500MB free,
and only ~2000 files on it. Any ideas what might be causing this,
and what I could do to avoid this problem? Stumped in LA...Dave.
--------------------------------------------------------------
David Thompson MS 320-47 Caltech
djt@mop.caltech.edu Pasadena, CA 91125 USA

On Mon, 18 Jan 1999, Dave Thompson wrote:>
> Dear Iraf Gurus,
>
> I am running an infrared reduction task I wrote and I am
> getting an odd error message: "INTERNAL ERROR on line 108: dictionary
> full." The line number reference is not helpful, it appears to be
> occurring in a call to an external fortran/imfort program I wrote.
> I doubt it is a problem in the program...the error occurs after the
> calling task calls it ~430 times (and it does this consistently).
> The disk is definitely not full, there is still some 500MB free,
> and only ~2000 files on it. Any ideas what might be causing this,
> and what I could do to avoid this problem?
> Dave,First, below is from our FAQ on the subject:------------------------------ `Dictionary full' means the CL's dictionary (what it uses to catalog
tasks, packages, parameters, etc.) is full. It can occur legitimately if
you are loading really long scripts with lots of loaded packages, local
variables, etc. It can also occur illegitimately, e.g. if a script were
repeatedly loading the same things (like packages) in a loop. Things like
list pointers used for filenames should also be "closed" when no longer
needed by setting them to a null string, for example a list = "input.dat"
while (....) {
:
}
list = ""The first thing to check is that you're not doing any of the latter; if
you have to, send us your script (you can put it in a directory at
ftp://iraf.noao.edu/pub) and we'll be happy to take a look at it for you.---------------------------You may also want to make sure that your script is a procedure script.
This forces you to adhere to a specific syntax, parameters need to be
defined, etc.If it turns out that it is not a fault in the script design, then the size
of the dictionary can be increased. The size of the dictionary has been
increased repeatedly in recent versions but if needed you can make it
larger by editing the cl$config.h and modifying the DICTSIZE and STACKSIZ
values. You would then need to relink the CL and install the new binary.
If you choose to do this, be sure you reset the system architecture before
doing this to avoid installing the binary in the iraf$bin.generic
directory by mistake. This is a "quick fix" solution that doesn't really
solve the inherent CL bugs, however.If you have questions about this let us know. Regards,Matt Cheselka
NOAO/IRAF

On Tue, 19 Jan 1999, Dave Thompson wrote:> This is probably what is happening for me...the task
> (procedure) I have runs for about 10 hours, and there are several
> thousand calls to various iraf commands. Is there a way to flush
> the dictionary in mid-procedure (e.g. flpr)?
>
> Thanks for the input...I'll check things over carefully,
> perhaps rearranging things a little will fix the problem (there
> is always a way around a problem in iraf!). It sounds like it
> should be pretty simple to fix...even if I have to re-install
> iraf.
> Well, there is no way to 'flush' the dictionary. I can suggest two
things:1. from the CL, you can type 'd_trace'. It's a toggle so typing it again
will return you to normal operation. It may allow you to see more clearly
where things are going wrong.2. As I said before, a quick fix is to increase the size of DICTSIZE and
STACKSIZ and relink the CL. (You don't have to re-install IRAF).Cheers,Matt