Important Note:
- The past few slides have shown the most common ways of accessing frame-based and record-based data.
  - NeXtMidas provides alternative methods that may be more appropriate to a given situation.
    - FILE COPY treats all files as simple binary ones and uses byte-based read and write methods.
  - It is possible to treat most frame-based data as record-based and record-based as frame-based.
    - LIST2 treats all data as record-based (listing is an inherently record-based activity).
    - NOOP treats all data as frame-based (simplifies this primitive and improves copy speed).
  - See the DataFile API for more examples of modifying/writing frame and record-based data.

Don't Make This Mistake:

Don't Make This Mistake:
Do not forget to close your input/output files in your primitive's `close` method, otherwise not all data may be written or your primitive may be holding on to resources that it no longer needs, causing a "resource/memory leak". Additionally, you should check if your file is null otherwise you may get a NullPointerException. public int close() { if (outfile!=null) { outfile.close(); } }

Do not forget to close your input/output files in your primitive's close method, otherwise not all data may be written or your primitive may be holding on to resources that it no longer needs, causing a "resource/memory leak".
Additionally, you should check if your file is null otherwise you may get a NullPointerException.

public int close() {
  if (outfile!=null) {
    outfile.close();
  }
}

Java Experts Take Note:

Java Experts Take Note:
File offsets and sizes are of type `double`. There are two reasons for this: It allows bit indexing (fractional part indicates bit in byte) for frame-based data. It is consistent with the definition of Midas Blue files. (The definition of a Blue file pre-dates widespread support for 64-bit integers, and the only way to support file size larger than 2GB was to use a `double`.) Many new applications/primitives (like LIST2) that work with record-based data internally store row numbers as a `long` and cast it to `double` when reading/writing (this prevents the user from entering a fractional record number).

File offsets and sizes are of type double. There are two reasons for this:

It allows bit indexing (fractional part indicates bit in byte) for frame-based data.
It is consistent with the definition of Midas Blue files. (The definition of a Blue file pre-dates widespread support for 64-bit integers, and the only way to support file size larger than 2GB was to use a double.)

Many new applications/primitives (like LIST2) that work with record-based data internally store row numbers as a long and cast it to double when reading/writing (this prevents the user from entering a fractional record number).