Handling Line Numbers

Qedit is able to handle numbered as well as unnumbered files. Qedit determines the type of file it's dealing with by looking at specific portions of each line based on the Language of the file. Qedit can handle up to 99,999,999 lines in regular numbered files and 999,999 lines in Cobol source files. The maximum is attained if the smallest increment allowed (0.001) is used and all possible line number values are present (there are no "holes" in the sequence). In other words, you will be able to add new lines by changing the increment or using unassigned line numbers. Qedit is able to adjust the increment and renumber parts of the file as needed.

When it comes to line numbers, Qedit goes by the following rules. If this is a Cobol source file, Qedit expects the line numbers in the first 6 columns of each line. For some other files, it expects line numbers in the last 8 columns of each line. Furthermore, the first 5 lines of the file must contain valid numbers (all numeric digits) and be in ascending order. If one of these requirements is not met, Qedit reports a line number error and does one of 2 things:

1. Assumes the file is unnumbered, assigns its own line numbers and handles line number columns as part of the data.
2. Assumes there is a problem in the line numbering scheme and assigns line numbers starting from the last valid number.

A number of factors influence which option is used.

Unnumbered Files

In the case of an unnumbered file, it is pretty obvious what Qedit has done since the file is visually different. If the file is supposed to be numbered, you need to find the incorrect line number and fix it. This should be relatively easy as the line should be near the top of the file. To make it valid again, you may have to renumber many lines to make them consistent again.

False Alarm

There are cases where Qedit thinks the file is numbered when, in fact, the columns contain actual numeric data. If you need to edit such files but keep getting error messages and are not able to see the numeric data, simply use the Unnumbered option on the Text command. In this case, the data is used as line number which makes for an unusual list of values. On a side note, MPE's Print command also looks for line numbers in the last 8 columns. If the output doesn't look right, you should use the Nonum option to see if this might be the problem. This is one of the most common questions we get on Suprtool when people try to check the results of an extract task.

   abc     12345678
   def     23456789
   ghj     34567890
   
   :qedit
   /t myfile
   12345.678 abc     
   23456.789 def     
   34567.89  ghj
   /t myfile,unn
   /l all
       1     abc     12345678
       2     def     23456789
       3     ghj     34567890
   /e     
   :print myfile
   abc
   def
   ghj
   :print myfile;nonum
   abc     12345678
   def     23456789
   ghj     34567890

Invalid Line Numbers

In the case of invalid line numbers or out-of-sequence line numbers, Qedit displays an error message and tries to recover from the error.

Let's say you have the following Cobol file on HP-UX:

    000110*VERSION "Version Robelle 1.1 2003"       
    000130 IDENTIFICATION DIVISION.
    002222 PROGRAM-ID. POPRINT.
    000150 ENVIRONMENT DIVISION.
    000160 CONFIGURATION SECTION.
    000170 SOURCE-COMPUTER. HP3000.
    000180 OBJECT-COMPUTER. UNIX.
    000280 INPUT-OUTPUT SECTION.                    

Keep in mind that Cobol line numbers have 3 decimal places so the first line is 0.11, not 110. It's also worth noting that the default increment is 0.1. A simple Text will get you the following error:

   qux/t cobnonum.pco
   'Language' is now COBX
   Error: line number out of sequence (000150) - renumbering the rest
   9050 lines in file
   qux/listj [
    0.11  *VERSION "Version ECOMETRYRev532:1"
    0.13   IDENTIFICATION DIVISION.
    2.222  PROGRAM-ID. POPRINT.
    2.322  ENVIRONMENT DIVISION.
    2.422  CONFIGURATION SECTION.
    2.522  SOURCE-COMPUTER. HP3000.
    2.622  OBJECT-COMPUTER. UNIX.
    2.722  INPUT-OUTPUT SECTION.                

Notice the original line 0.15 ENVIRONMENT DIVISION. is now 2.322 (last valid line number 2.222 incremented by 0.1). In this case, line 2.222 is likely incorrect and should be fixed. Aside from the new numbers, the file is intact and Qedit has been able to text it all in.

Important: the line number on the out-of-sequence error message has been added in version 5.4.11. Earlier versions do not provide the information making it hard to find which line needs to be fixed.

Running Out of Line Numbers

Now let's say the invalid line number above (2.222) is 999.992 instead. Qedit tries to renumber the remaining lines from that value with an increment of 0.1.

    qux/t cobnonum.pco
    'Language' is now COBX
    Error: line number out of sequence (000150) - renumbering the rest
     Error: Too High
    23 lines in file
    qux/l all
        0.11  *VERSION "Version ECOMETRYRev532:1"
        0.13   IDENTIFICATION DIVISION.
      997.992  PROGRAM-ID. POPRINT.
      998.092  ENVIRONMENT DIVISION.
      998.192  CONFIGURATION SECTION.
      998.292  SOURCE-COMPUTER. HP3000.
      998.392  OBJECT-COMPUTER. UNIX.
      998.492  INPUT-OUTPUT SECTION.        
      ....                       

Qedit will run out of line numbers very quickly causing the Error: Too High message. This error is a lot more serious than a simple renumbering. When this error occurs, Qedit stops reading the file. That's why it shows 23 lines in the file instead of the expected 9,050 above. It's very important not to keep the file.

How To Fix Line Number Problems

If there really is a problem, here's how you go about fixing the line numbers. If Qedit does not run out of line numbers, Text the file in and use the Renum command.

There are a few options when Qedit runs out of line numbers. You can force Qedit to use a specific increment by specifying the Setincr option on the Text command. For example, the following commands forces Qedit to use a .01 increment instead of the default.

     /Set Incr .01
     /T myfile,setincr

If that does not work, you have to see the numbers. In order to do this, use the Unnumbered option on the Text command. Line numbers now appear as data. Find the invalid line number displayed in the error message (if any). If there are just a few lines to fix, enter valid numbers where needed. If there's a large number of lines to fix, it may be easier to remove them all with a Change command and re-enter a valid sequence in the first 10 lines or so. Keep the file and Text it back in.

Qedit for Windows

If you get a line number problem in Qedit for Windows older than 5.4.10, you will not get any error. In versions 5.4.10 or later, you will get the following message:

Qedit for Windows does not have equivalents for the Set Incr and Renum commands and Setincr option. There is, however, an equivalent for the Unnumbered option. Just enable the Force Unnumbered option on the Open Host File or Directory dialog boxes.

If you do not have host-based Qedit but have the Qedit for Windows server, you should open the file with Force Unnumbered enabled and fix the line numbers.

Where Do Invalid Numbers Come From?

Based on our experience, invalid line numbers come from editing files using tools that are not "line number"-aware. Although this could happen on MPE, it's most often seen on HP-UX. This could be as simple as adding lines using I/O redirection (">" or ">>") on MPE or HP-UX commands. It could also be done by more complex software such as version control packages. Often times, the offending lines have been imported from foreign systems. Once the root cause has been identified, it is important to document it properly and maybe set internal standards to prevent it in the future.

---

....Back to the Qedit Q&A Page