Sequence Numbering
Contents of Article
Differences Between ISPF Numbering and the SPFLite Support
Protect yourself from sequence numbering mistakes
Dealing with the two use case of sequence numbering
Understanding sequence numbering types
Dealing with sequence numbers that get in your way
Automatic sequence renumbering during SAVE and END
Determining the value of the new sequence numbers for RENUM
Determining the value of the new sequence numbers for NUMBER
Synchronizing sequence numbers with SPFLite
See the following commands for more detailed information about the SPFLite Sequence Numbering feature.
Set Number lines automatically on SAVE |
|
Verify and correct sequence numbers if needed |
|
Define Numbering Style to be used |
|
Renumber all sequence numbers |
|
Remove sequence numbers |
Introduction
ISPF users have the ability to add, renumber and remove sequence numbers in their data, SPFLite users can now perform sequence-numbering actions using commands that are highly compatible with ISPF, and which also provide the additional flexibility you have come to expect from SPFLite.
Differences Between ISPF Numbering and the SPFLite Support
There is a significant difference between the way ISPF and SPFLite manage files containing sequence numbers.
Once a valid set of sequence numbers exist, ISPF will maintain sequence numbers as lines are inserted, copied and moved around within the file. This is done dynamically as you edit.
SPFLite does not perform this function, line numbers are only set when a NUMBER or RENUM command is performed, not dynamically during editing.
Differences can be summarized as:
- No dynamic numbering support from SPFLite. As a result, the concepts of NUMBER ON and NUMBER OFF do not exist, and these keywords are not supported by the Numbering commands.
- Since the sequence number fields are simply treated as part of the normal data in SPFLite, the former ISPF concepts of NUMBER DISPLAY and NUMBER NODISPLAY do not exist. Therefore the DISPLAY and NODISPLAY keywords are not supported by the Numbering commands.
- AUTONUM with no operands in ISPF is treated as AUTONUM ON. This is not true in SPFLite, you must explicitly enter ON or OFF as this is the normal SPFLite convention for On/Off settings
- ISPF supports a LEVEL concept for the sequence field. SPFLite does not support this.
- ISPF supports files which have both COBOL and Standard numbering. This was rarely, if ever, used. SPFLite will only allow one numbering style to be defined or applied at any given time.
- ISPF links the numbering style to the file type. SPFLite maintains the numbering style within the Edit Profile, which may or may not be the same name as the file extension.
The ISPF keywords NOSTD, NOCOBOL and NOCOB are also unsupported as they were used in ISPF to manage sequencing of a file when both STD and COBOL numbering types are in effect at the same time.
Protect yourself from sequence numbering mistakes
When first using numbering, be cautious until you become familiar with it. Unlike many other commands, the Numbering commands have the potential to overlay and destroy data unexpectedly if you specify things incorrectly. Make sure you know how to use UNDO to reverse the effects of any editing action. Or simply use CANCEL to exit your edit session, resolve the problem, and try again. Finally, it is recommended that you experiment with test files first, to help you understand how these commands operate.
Lastly, note that the sequence numbering commands consider a non-text file type as "exempt" from being numbered or renumbered, and will reject a numbering command from being applied to it. The file extensions of non-text files are listed in the File Manager tab of the SPFLite Global Options GUI.
Understanding sequence numbering types
Unlike ISPF, which only knew about two "types" of numbering: "Standard" numbering, and COBOL numbering, SPFLite has not tied itself to any preconceived ideas about where in a text line the sequence numbers should appear, nor their length.
SPFLite has introduced a new numbering command - NUMTYPE - to allow you to describe how you want to place the sequence number field. Once defined by the NUMTYPE command, the NUMBER / RENUM / UNNUMBER commands all perform their function under control of those NUMTYPE specifications.
So just what options can be specified?:
- Sequence number fields may be from 4 to 8 characters in length.
- The field may be placed anywhere within the text record, you specify the start and end columns.
- If a text line is shorter than needed to contain the field, it will be automatically padded with sufficient blanks.
- Fields may even be specified using relative columns from the right end of the line.
- The numbering function can be requested to truncate the line following the sequence field.
- You may request the sequence field be set equal to the SPFLite line number itself rather than an artificial incrementing number.
Note: It is quite possible for you to specify a NUMTYPE specification that is spectacularly harmful. SPFLite will slavishly follow your orders. E.G. If you really specify putting sequence numbers right in columns 20-27 of your source file, SPFLite will not question it.
BE CAREFUL!
However, to help you, SPFLite doesn't just ignore the old ISPF standards. The NUMTYPE command accepts 3 shortcuts to accommodate this:
NUMTYPE COB |
Will setup a COBOL sequence field in columns 1 - 6. |
NUMTYPE STD |
Will setup a standard sequence field in columns 73 - 80 |
NUMTYPE IBM |
Will setup a standard sequence field in columns 73 - 80 and request truncation after column 80. |
Dealing with sequence numbers that get in your way
ISPF integrates the presence of sequence numbers into its editor logic. SPFLite does not. As a result, there is nothing "magic" or "special" about these numbers. They are just strings of digit characters that exist in your data.
In particular, ISPF maintains the screen locations for displayed sequence numbers if you use the LEFT or RIGHT primary commands (normally mapped to F10 and F11) so they don't shift on the screen. However, in SPFLite, LEFT and RIGHT will include those numbers as simply another part of your user data, and they will get shifted along with everything else.
As you edit your file, if you have sequence numbers, say in columns 73-80, these will get "pulled" or "pushed" as you use the DEL key or type data in Insert Mode. That may cause problems, including making your data invalid for the purposes you intend. For instance, it could create syntax errors in a source program.
To resolve such problems, you can UNNUMBER your file, perform your changes and then NUMBER the file.
Automatic sequence renumbering during SAVE and END
SPFLite supports the AUTONUM ability. Simply issue AUTONUM ON or AUTONUM OFF to control this.
To use automatic sequence numbering a valid NUMTYPE specification must exist.
Determining the value of the new sequence numbers for RENUM
The RENUM commands will completely assign new sequence numbers. The starting number and increment are based on the number of lines in the file, and the specified size of the sequence number field. The following table summarizes this.
File Size |
Sequence # Size |
Starting Number |
Increment |
Under 1000 |
4 |
0010 |
10 |
5 |
00100 |
100 |
|
6 |
000100 |
100 |
|
7 |
0000100 |
100 |
|
8 |
00000100 |
100 |
|
Under 10000 |
4 |
0001 |
1 |
5 |
00010 |
10 |
|
6 |
000100 |
100 |
|
7 |
0000100 |
100 |
|
8 |
00000100 |
100 |
|
Under 100000 |
4 |
0001 |
1 |
5 |
00001 |
1 |
|
6 |
000010 |
10 |
|
7 |
0000100 |
100 |
|
8 |
00000100 |
100 |
|
Under 1000000 |
4 |
0001 |
1 |
5 |
00001 |
1 |
|
6 |
000001 |
1 |
|
7 |
0000010 |
10 |
|
8 |
00000100 |
100 |
Determining the value of the new sequence numbers for NUMBER
The NUMBER command is different from RENUM, in that it will only conditionally renumber a file, and then only where needed. Its primary purpose is to verify that a file's sequence numbers are present, valid and in ascending order, and only acts to correct the file if those conditions are not met.
If NUMBER finds the file already contains a valid set of sequence numbers, no action will be performed.
Otherwise, NUMBER attempts to correct out-of-sequence numbers in a way that causes the fewest changes to the current sequence numbers that are already present. As such, you may end up with lines numbered with varying increments between them. This is not an error, merely the result of keeping the current valid numbers and fitting in the corrections between them. If your file is severely out of sequence, NUMBER could end up abandoning most or all of the original sequence numbers.
Synchronizing sequence numbers with SPFLite
ISPF provides two basic numbering options. NUMBER will attempt to change as little as possible, keeping existing sequence numbers when it can. RENUM changes every line, creating new numbers that have uniform values.
SPFLite provides a third option, using the NUMTYPE option REAL. Specifying REAL on NUMTYPE will cause the RENUM command to use the line numbers known to SPFLite as the numeric values of the new sequence number field, rather than trying to retain any existing numbers or calculating new values for them.
Created with the Personal Edition of HelpNDoc: Free PDF documentation generator