When using the keywords DATA or INDICDATA, each record must be in the following format:
- The record begins with either a two-byte or four-byte length field, that contains an unsigned binary integer whose value is the number of bytes in the record (not including the bytes in the length field and not including the byte(s) in the end-of-record field). For two-byte record length fields, the RECORDLENGTH option value must be MAX64. For four-byte record length fields, the RECORDLENGTH option value must be MAX1MB.
- The record follows with binary-formatted fields that contain the column values of the returned row in record or indicator format.
- The record ends with an end-of-record (line) indicator, appropriate for the workstation and operating system. For example, for a UNIX system, the indicator is a new line. For Windows, the indicator is a carriage return/line feed pair. In all cases, the end-of-record character, or characters, are in the bit-format appropriate for the workstation. For example, in ASCII for an ASCII workstation.
Numeric data fields are corrupted if the data is reimported using a REPORT format export file.
When using a file originally exported using BTEQ’s EXPORT command as the source for IMPORT command across a different platform type, ensure that the endianness type of both platforms is the same. This can be verified using the SHOW CONTROLS BYTE ORDER command.
When using the keywords DATA or INDICDATA, a record must consist of binary formatted fields that contain the column values of the selected row in record or indicator format. It does not contain a record length field or an end-of-record indicator, since that information is inherent in the way z/OS stores records.
For both workstation-attached and mainframe-attached systems a BOM is not valid at the beginning of a DATA (or INDICDATA) import file when a Unicode session character set is being used.