I/O Data in DDS applications are controlled by the use of "alias"
names (not to be confused with "alias" Definitions) in identifying
each input and output dataset. The "alias" name generally
specifies the Dictionary associated with a dataset. These
Dictionaries specify the format and binary data filename.
The user can override each dataset's "format
" and
"data
" (binary filename) Definition. However, if you
define "format
" or "data
" directly, then
that would override those Definitions for each input dataset that
might be associated with the application. (Likewise, any command
line or par file parameter like "axis=
" or
"delta.t=
" would apply to each input dataset to the
application.)
So to get around this DDS uses a modified Definition name for each
dataset base on each alias name
(eg. alias_format
). So for example if you
have an input dataset identified as "in
", you can
override it's format by specifying "in_format=
".
For example a full specification of an input and output dataset
might look like:
in= line34 in_data= Hline34_@ in_format= ccube out= line34_migrated out_data= Hline34_migrated_@ out_format= fcube
If you look at a created dataset's Dictionary you may see this
override Definition (eg. "in_format=fcube
") that came
as an input parameter followed by DDS creating an alias Definition
for the format (eg. "$format=in_format
"). The next
time DDS tries to open up this dataset, it will look backwards
through the Dictionary for "format=
". When it finds
"$format=in_format
" it will then change it's search
to "in_format=
" and continue searching backward from
that point.