In a file I use a simple encryption scheme in one of the data fields (name field). The letter 'D' changes to SPACE during the encryption. (SPACE in the normal text encrypts to 'W').

In the XREF index definition, the delimiters are: VM SVM TM .,/;W

When doing a lookup for a word containg 'D' the index cannot find it, because it interprets the corresponding SPACE as a delimiter.

How can I exclude SPACE from the delimiters within the index definition?

TIA

Wilhelm

Wilhelm-

In the _XREF symbolic, the formula contains a string of hex that is passed to the XREF subroutine. Is 20 in the string? That is hex for space (ascii 32).

Removing it may help….

Mike Ruane

Removing the \20\ will help, he'll just need to rebuild the index to get the new entries into the index.

The Sprezzatura Group

World Leaders in all things RevSoft

Mike,

the symbolic for the _XREF field has the following function call:

CALL XREF({NAME},\FDFCFB2E2C2D2F3B57\,"",""), corresponding to the delimiters VM SVM TM .,/;W, there is no mention of \20\.

When I LIST FILE NAME NAME_XREF and the encrypted text contains "W " or starts with a space then XREF() seems to LTRIM the parsed word.

The example string (starting with a space)

EXVW AHWZXO PEHHKWHEA,WNKYANPK

evaluates to the

EXV:@vm:AH:@vm:ZXO PEHHK:@vm:HEA:@vm:NKYANPK

it should really be:

EXV:@vm: AH:@vm:ZXO PEHHK:@vm:HEA:@vm:NKYANPK

Any suggestions?

Wilhelm

Mike,

the example of my posting came out confusing, because it doesn't adequately indicate the spaces:

It should read this way:

The example string:

{space}EXVW{space}AHWZXO{space}PEHHKWHEA,WNKYANPK

evaluates to:

EXV:@vm:AH:@vm:ZXO{space}PEHHK:@vm:HEA:@vm:NKYANPK

It should really be:

{space}EXV:@vm:{space}AH:@vm:ZXO{space}PEHHK:@vm:HEA:@vm:NKYANPK

I hope this points clearly to the problem.

Wilhelm

It appears the XREF subroutine does a trim of some sorts.

What you will need to do is create a symbolic and place a btree on this, effectively writing your own XREF subroutine.

To do this, have your routine convert all delimiters to @VM.

If required, you can loop through the results and remove the words from the stop list. This an be found in @DEFAULT.STOPS.

All a cross-reference is is a btree index on a symbolic so there should not be any adverse affects on your system.

I would refrain from calling the index SOMETHING_XREF so the system does not run into problems with the missing xref pointers.

The Sprezzatura Group

World Leaders in all things RevSoft

Thanks for the hint.

Wilhelm

View this thread on the forum...