File Format Overview

The IDL save file format is an extensible format. By this I mean that new record types can in principle be added without disturbing the overall format of the file, which enhances the probability that even an older version of IDL will be able to read the file, even if some information is lost.³ This is possible because IDL files are stored in a standard ``tagged record'' format.

By ``tagged record'' format, I mean that the components of an IDL save file are each stored as a separate record type. Each record type is ``tagged'' or marked with a code which identifies the format of the record. Thus, the reader of the file can decide whether it is able to read a record based on its format code.

At its core level, the format of an IDL save file is very simple. It starts with a signature block which identifies the file as an IDL savefile, followed by a stream of records:

Format: SAVEFMT        (overall save file format)

Type	Name	Description
BYTE$\times$2	SIGNATURE	IDL SAVE file signature (=BYTE(['S','R']))
BYTE$\times$2	RECFMT	IDL SAVE record format (=['00'xb, '04'xb])
Record 1
Record 2
$\vdots$
Record $n$ -- END_MARKER

The meaning of the above table is is that the first two bytes of the file are a ``signature,'' followed by two bytes which identify the record format of the file, followed by a series of standard records, the last of which is a standard END_MARKER record (described below).

These tables will appear throughout this document. The first column contains the format or structure of the element being described. In this case ``BYTE$\times$2'' means 2 consecutive bytes. As more complex data structure formats are described, these may also appear in the first column. The second column contains the name of the element as used in this document. The final column contains any descriptive comments.

It should now be clear how an IDL save file should be read. The first process is to open the file and read the first four bytes. If the first four bytes do not match the expected signature, then the file is not in a recognized format and must be rejected. If the match succeeds, then the reader proceeds to read each record in turn, until the END_MARKER record is reached.

Footnotes

... lost.³

However, even RSI did not appear to follow their own prescription when they released IDL version 5.4. In that version the record header (RECHEADER) format was changed incompatibly, so that earlier versions of IDL could not read files produced by IDL 5.4. This situation is apparently be corrected in the release of IDL version 5.5.