TAS Files
One of the segment protocols is "TAS". Under this protocol, series data are stored in Tiled Array Storage files (aka TAS files) in SUMS directories. This option exists because it allows the user to combine multiple images (or collections of data) into a single file for storage purposes. It is beneficial to do this, as this results in fewer, larger files and this improves disk-and-tape management performance. It is also a method for keeping related data together as it shuttles between disk and tape.
A TAS file comprises one or more, equally-sized data slices. Each slice is the data for a single DRMS record of a DRMS data series. In fact, TAS files are simply FITS files that contain data slices. A series creator specifies the number of slices in a TAS file by using the Unitsize field in the series' JSD. Just as the unitsize determines the maximum number of slot directories in a SUMS storage-unit directory for data with a segment protocol of FITS, for TAS segments, the unitsize determines the maximum number of data slices in a TAS file (and since a slice corresponds to a single DRMS record, it is equivalent to say that the unitsize is the maximum number of DRMS records whose data are contained by the TAS file).
To create a DRMS data series with a TAS segment, you simply need to specify "tas" in the protocol field of the segment's series definition file (please see the discussion on Jsd series definition files for more information). You should also consider choosing appropriate <tile-compression arguments> should you decide that you want your TAS files compressed (yes, you want your TAS files compressed). This field in the JSD is a string that is passed directory to CFITSIO (remember, TAS files are FITS files) as the file-name modifier (please see the latest CFITSIO documentation). The file-name in the CFITSIO paradigm is how a user controls various aspects of compression. In general, you want to use "compress Rice <tilesize1>,<tilesize2>...<tilesizeN>", where N is equivalent to the maximum data dimension. These <tilesizeX> describe the size of a single COMPRESSION TILE (not the same thing, necessarily, as a data slice). A compression tile is the unit of compression that CFITSIO uses. The compression algorithm compresses each tile independently of all other tiles.
The "X" in <tilesizeX> refers to the same dimension that the "X" in naxisX refers to. So, in both cases, X = 2 would refer to the second dimension, and <tilesize2> would refer to the size in the second dimension of the compression tile, and naxis2 would refer to the total number of pixels in the second dimension. <tilesizeX> must be less than or equal to naxisX. The Nth dimension is the one in which TAS slices are added. Each time a record's data is written to the tas file, a new slice is added along the Nth dimension. And in all but the Nth dimension, the data slice spans the entire hypercube. In this way, a data slice has dimensions of naxis1, naxis2, ..., 1. Because each record's data can be read independently of all other record's data, you really want your compression tiles to fit entirely within each data slice. So, a compression tile could be equivalent in size to the data slice, or it could be 1/2 the size of a slice, or a 1/3 of the size of a slice, or a 1/4 of the size of a slice, etc. As long as you can break the data slice into an integral number of equally size tiles, things will work well. This means that <tilesizeN> must be 1, and for all other dimensions, naxisX must be a "multiple" of sorts of <tilesizeX>.
Please see the discussion on Jsd series definition files for more information about the tile-compression arguments, and also the remaining fields of the segment specification.
Once you create a series with TAS segments, then reading from such segments or writing to them is no different that it is for FITS segments - the same code will work on both types of segments.