Robert,
I've pretty much already answered these questions in our previous conversation in the forum. To recap...
Contrary to your statement, I NOT believe MINLEN is the problem that causes a crash.
The 'problem' is the way CHANGE works in its repetitive searching of the already changed line instead of searching the original line repetitively.
But I accept that we can't easily rectify that. So the spotlight falls on MINLEN as an alternative approach to avoid the crash.
I have no allegiance to MINLEN as such. Currently, it just happens to be the only SPFLite 'vehicle' that provides what I seek, albeit in a rather clunky way.
So what do I seek?
(And please don't reply with a series of commands or macros which could also achieve this effect. That isn't the point.
The point is that users 'see' a blank line and realistically expect the CHANGE command to support this and currently it does not.)
Let's look at an example.
A file contains a lot of lines of varying lengths.
You wish to place something in that file, to start in column 65, on all, or a selection of, lines, which have space for it.
It could be a comment at the end of source code lines or another column in a text table that was loaded. It matters not.
ISPF/PDF, accomplishes the task easily and logically (from the user's perspective who 'sees' blanks on the lines), with the command
CHANGE "<blank><blank><blank>" "<something>" 65 ALL
It doesn't matter if a line was 20 or 120 chars long. If there were 3 blanks in column 65 the <something> replaces them.
ISPF/PDF considered every short line (even for RECFM=V files and NULLS ON set) to be 'padded' by blanks WHEN REQUIRED see later.
SPFLIte cannot achieve the same result because the short lines do not have 'physical' blanks at the end, so <something> will not be placed on short or empty lines.
Enter MINLEN stage left.
For me, MINLEN>0 is a construct that enables the SPFLite CHANGE command to achieve the required effect, because short lines are padded when the file is loaded.
Hence the CHANGE command finds the blanks in col 65 and replaces them with <something> as the user requested.
I already mentioned in a previous post, that I set MINLEN to my typical display width (110 chars) and I don't mess about with LEFT/RIGHT scrolling.
So this works a treat.
Now let's go back to the WHEN REQUIRED phrase above. I ONLY need the short lines to be padded when the command specifies operands that require/imply it.
The column limit(s), 65 in the above example, does require padding short lines. Not endless padding, but to a minimum length of 65+LEN(<findstr>).
This padding could be added, immediately after the line is 'read in' in preparation for the search to begin and need not be applied to any line whose native length exceeds 65+LEN<fndstr>).
If FIND/CHANGE operated in this way,
a) I wouldn't touch MINLEN at all. For the above use case, it's a sledgehammer to crack a nut.
b) The many notes about 'you cannot find zero-length strings' in the HELP file become superfluous.
(They don't apply anyway because the user is searching for blanks, not nulls)
In short, users understand the CHANGE command and its ability to replace A with B. But it let's them down in certain scenarios.
- it cannot place data in a specified column on lines that end before that column
- it cannot remove (replace by "") a single character from the front of a line if that character is followed by one or more of the same character. It removes them all.
- it cannot remove (replace by "") a single occurrence of a repeating series of characters. It removes all of them in a line, even when column limits are specified.
Changing or removing MINLEN is a circumvention to avoid a crash elsewhere. It's like blaming the cop for being there when I've been caught speeding.
