Optionally, data in CSV format may also be sent to SYSLST for output. The content of the output data in CSV format is similar to that of the SYSLST output. However, there are some differences in the format of the output data due to the fact that the data will not subsequently be used in paper form but will be further processed in other programs:
All output in CSV format is stored in a file as part of a utility routine run.
The first column contains an identifier that permits the line-by-line evaluation of the data.
SYSLST output is restricted to the printing width of 132 characters per line. No such restriction applies to CSV output. Text information, e.g. headers, that has to be broken into several lines for SYSLST output is output in a single line in CSV format.
Abbreviated text components are written in full in CSV format in order to achieve greater clarity.There are no page-oriented subheads in the CSV output.
Repetitive explanatory texts from subtables are moved to additional headers.
The header line of each CSV file contains the name of the utility routine, the corresponding utility routine’s output format version, and the date and time of creation of the CSV output.
The version changes if the CSV output changes with respect to the assignment to output cells or the semantic of output cells.
Number notations which are represented in special formats in the SYSLST output for reasons of space (e.g. 25M or 14K in BSTATUS) are depicted in the correct digital form in the CSV output.
Unlike in the SYSLST output, uppercase/lowercase notation is used for explanatory texts in the CSV output. Technical UDS/SQL terms and names declared in the database continue to be written in uppercase only.
In the CSV output, BSTATUS also specifies the database name and the schema name.
BPRECORD outputs record contents and table entries in Hex and Char format to the CSV file in compact form. In the Char format any hexadecimal character may occur. If the CSV file is transferred to a different system environment then the presence of individual characters which have special meanings may destroy the line structure of the CSV output.
For example, on conversion to ISO8859-1 (ASCII), the EBCDIC character X'25' is converted to X'0A'. In Unix and Windows environments, X'0A' is interpreted as \n and therefore as a line feed. The EBCDIC character X'0D' remains unchanged on a switch from EBCDIC to ASCII. In a Windows environment it acts as an \r and generates a line feed. In a Unix environment, it returns to the start of the current line and may therefore result in elements of the output being overwritten.
A simple way of avoiding such disruptive effects is to replace the characters in question with others while still in the BS2000 environment. This can be done, for example, in EDT with the following statements
@ON & CA X'25' T '?'and@ON & CA X'0D' T '?'If the separator character occurs in the CHAR- output from BPRECORD, it is converted into X'00' in the CSV output in order to avoid any impairment to the continued higherlevel processing of the fields. If the separator character is required for further processing then this must be performed using the unchanged HEX output.