[ CRLF | CR | LF | NL | AUTO | AUTONL | hh | hhhh | NONE ]



Use the carriage return / line feed combination as the line separator.


Use the carriage return character as the line separator.


Use the line feed character as the line separator.


Use the new line character as the line separator.


Automatic detection of line separators is performed, with lone CR characters used to overprint.  See discussion below.


Automatic detection of line separators is performed, with lone CR characters treated as new lines. See discussion below.


Where 'hh' may be any two valid hex characters. The resulting character will be used as the line separator.


Where 'hhhh' may be any four valid hex characters. This two character string will be used as the line separator


There are no line separator characters used. The file must have an LRECL value greater than 0 which will be used to perform the line separation function


The EOL setting is stored in the file type's profile and is used when reading and writing files to support handling different file formats.

The command itself has no default; you must specify a line-delimiter operand. SPFLite will assume a never-before seen file-type uses CRLF, the standard delimiter in Windows.

For additional information on these values and their effect, see "Handling Non-Windows Text Files".

The value is stored as part of the PROFILE options which are maintained individually by file type.

Handling of EOL AUTO and EOL AUTONL

The End of Line options EOL AUTO and AUTONL allow for automatic detection of  line terminations, possibly containing inconsistent and spurious line terminators, so that files edited across different system, mainframe SYSOUT files, and other inconsistently-terminated text files can be opened, viewed and edited in a reasonable way.

EOL AUTO and AUTONL may be applied to non-mainframe files as well, to handle situations where a file's line termination is inconsistent for some reason. A possible cause of this is a file shared between Windows and Unix on a network and edited with different editors applying different line endings.

Line terminations under EOL AUTO and AUTONL are handled as follows:

FF characters delimit lines, and cause a =PAGE> marker to be placed in the sequence area.

    • Scrolling commands UP PAGE and DOWN PAGE will locate these marked lines.

    • Since UP PAGE and DOWN PAGE will move the file to these =PAGE marker lines, which may have a variable number of lines involved, to regain the ‘full screen motion' that UP/DOWN PAGE does in other files, you can use a scroll amount of HALF or DATA, or you could enter a numeric value for a specific number of lines. For most users who would have used UP/DOWN PAGE, UP/DOWN by the DATA scroll amount should work well for them.

    • When you have a file that shows this =PAGE> marker on a line, and you PRINT this file, you will have a Form Feed sent to the printer for every line containing the =PAGE> marker.

A lone LF is treated as a line delimiter equivalent to CR,LF

SpuriousCR characters that seemingly don't belong there, such as CR,CR,LF are ignored. For example, in the sequence CR,CR,LF, the first CR is spurious; the remaining CR,LF is a normal line termination.

A CR,FF or CR,LF,FF sequence is considered as the end of one line, followed by a page separator line.

A hex value of X'1A' (Ctrl-Z) at the end of the file is ignored.

Choosing between EOL AUTO and EOL AUTONL

A “lone CR” character – that is, a CR not followed by LF, FF or another CR – is sometimes produced by software that attempts to overprint the data in order to simulate underscores or bold print. It may also exist in non-Windows text files; older versions of Macintosh and some lesser-known systems used CR as a line termination.

Because of this, a lone CR character might be used for two different, conflicting purposes.

To handle this, you may choose between EOL AUTO and EOL AUTONL. These two options work as follows:

For all but the “lone CR” situation, EOL AUTO and EOL AUTONL work identically.

Action taken for EOL AUTONL:  CR = New Line

When EOL is set to AUTONL and SPFLite detects a lone CR in a file, the CR is considered to be a “new line” and is treated as if the lone CR were actually a normal CR/LF line termination.

Action taken for EOL AUTO:  CR = Overprint

When EOL is set to AUTO and SPFLite detects a lone CR in a file, it is considered to be an overprint request. At this point, SPFLite will buffer the lines involved in the overprint request until a ‘normal' line terminator is found, and then attempts to simulate an overprint. This means that, on a column-by-column basis, it examines the characters that are attempting to ‘occupy' the same column at the same time. For each two characters involved in this way:

    • When a blank and a non-blank character are in the same column, the non-blank character ‘wins out'.

    • When two non-blank characters are in the same column, and they are identical, it is recognized as a “bold font” type of overprint, and is not a problem; the non-blank character is retained.

    • When two non-blank characters are in the same column, but one of the non-blank characters is an underscore, the non-underscore character ‘wins out'. That way, the underscore character will never ‘obliterate' the meaningful data.

    • When two non-blank characters are in the same column, and they are not identical, and neither is an underscore, an “overprint clash” has occurred. When this happens, the first such character is retained and any others are discarded. Where SPFLite detects this, it will issue a warning message. If you frequently see this warning, it suggests the file having lone CR characters was not written to overprint, but either has foreign line delimiters or is perhaps ‘damaged' in some way. The way to address this is to change the EOL setting from EOL AUTO to EOL AUTONL.

Note for Hercules users

Hercules users are familiar with a utility called HercPrt, which (among other things) has the ability to take a SYSOUT file and format it into a PDF file that looks remarkably like a computer printout on "green bar" paper - complete with sprocket holes and perforation!  This is cute and very clever, but it also uses a large amount of disk space. By using alternating background colors (along with EOL AUTO and PAGE ON mode), it is possible to very closely simulate the effect of a HercPrt-formatted file without the PDF disk-space overhead. You will still be editing or browsing ordinary text files in native mode, but the display will have the look and feel of paging through an actual hard copy printout.

If you wish to match the same colors generated by the HercPrt utility, make the main background color white, and the alternative background color a light green. A good starting point for a HercPrt-like light green color you could try is BRG value 233, 255, 233. You may wish to tie the profile attributes to a specific file extension like SYSOUT.

Created with the Personal Edition of HelpNDoc: Free iPhone documentation generator