×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
On 09-Jan-2012 12:16 , sjl wrote:
It is a one-off program for creating address information during a
system conversion.
As it reads records from the legacy address book file, the program
SCANs for for values in the name field and replace them with other
hard-coded values before writing out the address book information to
the file which will be imported into the new system.
For example:
C 'Abc ' SCAN PNAME P
C IF P > 0
C MOVEA 'ABC ' PL(P)
C ENDIF
The array named PL redefines the field PNAME.
Perhaps I can better improve the program's performance by replacing
the MOVEA with %replace:
Where I have added code in this routine, I have used %replace.
So basically a UDF against the column to effect replacement of some
'tokens' with modified variations; e.g. as with the upper-cased value as
shown.?
FWiW: Is the SCAN going to, or even need to, handle replacing the
token when found at the end-of-string; or for a ' Abc' at the beginning
of a string? That is, the space as token delimiter may limit
replacements [in]correctly at the beginning and end of strings.
Because there are apparently "hundreds" of tokens that can be
replaced within a string, I would probably just use %replace; i.e. the
scan is implicitly a part of that builtin.
I wonder however was there any consideration made for the order of
operations or to prevent accidental effects from "rescan" of the same
values; i.e. where one replaced value can become a value that will again
be replaced, having formed another matching token? For the effect of
"no rescan", the scanning for the specific tokens may be required
up-front, for which the offset-array may be more desirable.
The example does not show, though implies, the replaced value will
always match in length to the scanned value. I would think a loop
implementing the effective scan might be a better implementation to
limit the amount of times the full string is reprocessed; i.e. scanned
from begin-to-end for either an explicit %scan or the implicit scan when
using %replace. Checking to see if the current byte in the string
matches the first byte of any scan-strings, then checking only for the
number of bytes of each /potentially matching/ scan-string; for a match,
overwrite the data from that position for the length, and for no-rescan
continue scanning from the end of the replaced value.
Regards, Chuck
As an Amazon Associate we earn from qualifying purchases.