NETDATA is a file format used primarily for data transfer and storage on IBM mainframe systems, although implementations are available for other systems.
NETDATA files are 80-byte card image files containing unloaded file data plus metadata to allow the original file to be reconstituted on the receiving system. A complete NETDATA file consists of a number of control records, followed by data records and terminated by a trailer record. All records have the same format:
Control records have a six-character EBCDIC identifier in bytes 2-7 following the length and flags. They contain a number of self-defining fields, called text units. Each text unit consists of a two byte text unit key identifying this text unit, a two-byte big-endian binary number of length-data pairs that follow for this key (usually one), a two byte length field identifying the length of the text unit data, and a text unit of the specified length. Implementations are expected to ignore any text unit information not relevant to the receiving system.
Header Control Record
The header record must be the first record of a NETDATA file. It has the identifier "INMR01". It contains information identifying the sender: node (host), timestamp, and user id, the length of the control record segments, and the target (receiving) node and user id. It may optionally contain a request for acknowledgement of receipt, the version number of the data format, the number of files in the transmission, and a "user parameter string." CMS allows only one file per transmission, but TSO/E and other systems may allow more than one.
File Utility Control Record
This record describes how the file's data is to be reconstituted. Its identifier is "INMR02". Bytes 8-11 contain the big-endian binary number of the file to which this record applies. If there are multiple files in a transmission they are numbered starting with one. The rest of this record describes the file's format, and one or more steps ("utility programs") which must be executed in order to rebuild this file. The text units identify the file's organization (INMDSORG: sequential, partitioned, etc.), its fixed of maximum record length (INMLRECL), its record format (INMRECFM: fixed, variable, etc) the approximate size of the file (IBMSIZE), and the utility program name(s) (INMUTILN). It may also contain the file's block size, creation date, number of directory blocks, name, expiration date, file mode number, last change date, last reference date, member name list (for partitioned datasets), a note file, and a user parameter string.
Data Control Record
The Data Control Record immediately precedes the data and describes its format, similar to the Utility Control Record. Its identifier is "INMR03". This record is ignored by CMS, but is used by TSO/E. It contains the file's organization (INMDSORG), its record length (INMLRECL), its record format (INMRECFM), and the file size (IBMSIZE).
User Control Record
The User Control record can appear at any point in the data stream. Its identifier is "INMR04". If present it is ignored by CMS, but may be used by other systems. It contains only a User Parameter String (INMUSERP).
Trailer Control Record
This record marks the end of the file. Its identifier is "INMR06". No other data is defined for this record.
Acknowledgement Control Record
This record has an id of "INMR07". It is used by the receiving system to acknowledge receipt of a transmission. It contains one of the text units File Name (INMDSNM) or Note File (INMTERM) plus, optionally, the Origin Time Stamp (INMFTIME).
A note file (sometimes called a "PROFS note") "is a short communication, the kind usually done by letter.".[2]
Data records (identified by their flag value), follow the Data Control Record, if present, and precede the Trailer Control Record. Records can be any size up to INMLRECL. They are sent as multiple segments of up to 253 bytes, split into 80 byte records for transmission, and reassembled by the receiver. Settings of the flags byte in each record mark the beginning, end, or a complete record of the file. Bytes of a record can contain any bit pattern. No character values are reserved.
