The Bounds column range is in effect unless you specify overriding boundaries when entering a command. The action of some, but not all, primary commands are modified by changes to the BOUNDS setting. Refer to the individual command descriptions for the effect the current bounds settings have.
If you do not explicitly set bounds, the editor uses the default bounds, which are the entire data line. When the bounds are the entire line, the editor may be said to be operating in "unbounded mode", which will cause a status line display of Bnds: MAX to appear. You can set the editor to operate in unbounded mode by issuing a primary command of BOUNDS 1 MAX, and typically this is how SPFLite is operated.
Note: When the BOUNDS setting is anything other than MAX, the status line display will show the BOUNDS setting in white letters on a red background, like Bnds: 1 to 40 so that it can't be ignored. This will help users to avoid the unexpected and nonstandard handling of data that occurs when non-default bounds are in effect, if that was not their intent.
A word about the use of BOUNDS
The BOUNDS feature of ISPF is one that IBM did not extensively document, and in practice, mainframe ISPF users do not tend to use this feature very often. Every effort was made to implement BOUNDS in SPFLite in an ISPF-compliant manner. However, it may produce surprising and unexpected results if you are not familiar with the actions taken by various commands when operating under restricted column BOUNDS. The "surprising and unexpected" aspect is even more of a factor for SPFLite users without a prior mainframe ISPF background.
For many users, you will likely get the most benefit from SPFLite by operating in unbounded mode most or all of the time, and not worry about using BOUNDS unless you have very particular editing requirements.
Created with the Personal Edition of HelpNDoc: Easily create iPhone documentation