Problem:
There are a number of reasons why the editor might display this message when a file is displayed (as an aside, the editor only loads a file when it needs to display a line from within it; this means that a program might load and the message not appear until you page into a copyfile or copybook at some later point).
Historically, the editor engine has detected changes to compiled files by counting the number of lines within the file; if this matches the linecount processed by the compiler and recorded in the IDY file, then no message is displayed. If the linecount differs, the message appears.
Resolution:
So how could the linecount differ? This might happen for a number of reasons:
1 - The file has actually been modified. This should always be the first cause to suspect - if the error occurs after recompiling then this reason can be discounted.
2 - Your source contains copy...replaced code which isn't being handled very well. The editor displays the replaced version of affected source files, i.e. "what the compiler saw, not what's in the raw source file". Sometimes the editor misinterprets the replacing data placed into the IDY file and ends up 'replacing' more or less lines than it should do. This then generates the warning message.
3 - Use of a preprocessor. When a preprocessor is involved, the compiler is itself sometimes misinformed of the number of lines there are in the actual source file (although this is very rare), again triggering the message.
4 - Use of embedded ASCII control characters or other control/graphics characters in source files. This can occur through three cases:
a - coding of screen displays by embedding the actual graphics characters in the source code;
b - downloading source code from a mainframe or Unix system; the transfer program may add extra control characters or fail to remove such characters (which only have meaning on the original host);
c - use of source files which contain an embedded ASCII "end of file" character (hex "1A" or right-arrow symbol).
When the source code is compiled, these characters may get misinterpreted by the compiler, which uses COBOL line-sequential file handling (in the case of (c), all source code which occurs after the EOF symbol is ignored by the compiler - by default, the editor will read this extra source code).
The editor uses byte-stream file access to "emulate" line-sequential access as far as possible (this is because the editor needs far greater control of the underlying bytes in a source file). The most notorious character is hex "1A", the right-arrow graphic (case (c) above). This actually terminates a line sequentialread, yet by in byte stream reads is ignored, thus causing a linecount mismatch.
Second in notoriety is the null character hex"00". By default, the line-sequential handler treats this byte as "protecting" the next byte in the file (it is used by many Micro Focus tools, including the editor to allow us to embed ASCII control characters in text files that would otherwise be treated as the appropriate control character rather than a graphic symbol). When the compiler reads the source, the null is discarded on-the-fly by the file handler; when the editor reads it, it usually does the same as the file handler but changing the COBSW "N" switch (see below) between compiling the source file and then loading it into the editor can cause the null to be retained when it should be discarded and vice-versa.
To cure the ASCII "end of file" (hex "1A" case), the editor has an option that terminates file load on detection of the 1A byte, provided it was not protected by a preceeding null byte and null protection (the COBSW "N" switch) is on. If it was preceeded by a null and null protection was off, the 1A would then be obeyed. This option can be found on the Edit Options dialog, profiles page. It is the check box entitled "Detect ASCII end of file", towards the bottom of the dialog. Check the box to have the 1A bytes detected and obeyed. NOTE: CHECKING THIS OPTION WILL CAUSE ALL SOURCE CODE FOLLOWING AN UNPROTECTED 1A BYTE TO BE DISCARDED IF THE FILE IS MODIFIED AND SAVED. Unless you are certain that you want to keep 1A bytes in your source code, your best option (having ascertained that they are causing a problem) is to find and remove them or null protect them by inserting a preceeding null, and ensuring COBSW does not contain the -N switch.
To turn null protection off, set COBSW=-N. The default setting is on, or COBSW= N. Care should be taken with this switch as it may cause side effects with some other data files and tools.
5 - The editor finds a different version of the source file than that when the program was compiled. When the editor loads a source file in a program, it uses the file location stored in the .idy file first when trying to open it. If this is pathed, then the editor will pick up the correct version of the file (provided it hasn't been moved). If it's unpathed, then the editor must search for the file which it does in a manner very similar to the compiler. Sometimes however differences in the search algorithm may occur which then lead the editor to find the wrong version.
6 - You are using multi-program source files. A multi-program source file is one which contains several independant programs (i.e. they are not nested, which is another way of writing COBOL source code). A nested program, appears as:
identification division.
program-id. prog1.
.
.
.
identification division.
program-id. prog2.
.
.
.
end-program. prog2.
.
.
.
end-program. prog1.
A multi-program file would appear thus:
identification division.
program-id. prog1.
.
.
.
end-program. prog1.
identification division.
program-id. prog2.
.
.
.
end-program. prog2.
During compilation of a multi-program source file, separate .IDY files are created for each program encountered. I mentioned in (1) that the .idy file contains line counts for the source files; in this case, only the lines counted whilst compiling prog1 are in prog1's .idy file. Prog2's .idy file contains the linecounts for prog1 and prog2, and so on.
When the editor loads prog1, it immediately detects excess lines (i.e. those belonging to prog2 etc) and so displays the message. Currently there is no fix or workaround for this situation, other than to split the programs into separate files.
#MFDS
#EnterpriseDeveloper
