Memory-based ntuples are implemented exactly like histograms. In the book entrypoint you call HBOOKN and in your code you call HFN. This is the easiest way to deal with relatively small ntuples. For example, this works quite well for accumulating endrun statistics, where each ntuple row contains the run number, run length, efficiencies etc. The ntuple will be saved (with your histograms) to the filename of your choice when you give the HIST/WRITE command. The HIST/WRITE command simply gets the filename of the DASH command line and calls HRPUT(0,HBKFIL,'T').
But if you wish to make an ntuple summarizing information over thousands of events on an event by event basis, the standard technique is to make a disk-based ntuple. The problem for DASH is that information about the top directory name of the RZ file (CHRZPA) must be coordinated between HROPEN and HBOOKN. Since HBOOKN must be coded by the user, the user should also take care of calling HROPEN. Once the ntuple is booked and associated with a directory in an RZ-file, the user never has to worry about which hbook subdirectory he is in when filling the ntuple. Therefore, these ntuples will not interfere with the automatic subdirectory features discussed in section 5.5.
In addition, the user must call HREND at the end of his job to cause the last flush from memory to RZ file. In this case, you must HCDIR to the top directory of the RZ file first. This would best be done in the FINI entrypoint, although it may be useful to have a way to close these files available from the TALK entrypoint as well.
The user may specify the filename for HROPEN as a fixed name, or calculate it from the run number or date. The most flexible choice would be to control the filename from the TALK command (with a good default to handle the case where the TALK command has not been given). See appendix C for sample code.
In summary: since disk-based ntuples require management of the top level directory of the RZ file as well as the file name, I have left this completely up to the module-author. If new ways to handle this become available in HBOOK, they might be incorporated into future DASH features.