Contents of Article


Related Commands

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



Related Commands


See the following commands for more detailed information about the SPFLite Sequence Numbering feature.

AUTONUM

Set Number lines automatically on SAVE

NUMBER

Verify and correct sequence numbers if needed

NUMTYPE

Define Numbering Style to be used

RENUMBER

Renumber all sequence numbers

UNNUMBER

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