Conference iosg::all-in-1_v30

902.0. "BEGINNING operator fails binding to descending data files" by COMICS::BARHAM (Norbert:) Fri Jun 19 1992 17:29

ALL-IN-1 2.4 unpatched, BEGINNING operator fails on descending data files

I have a simple entry form called ALAN:-

;;.type;;

entry/mode=update

;;.file;;

oa$lib:mlg.dat,mlg$unique_ref



I create a data file with the CFI option and then add three records :-

19920611
19920612
19921225

If I then have a script that says

bind_break/all
bind *a to ALAN with .mlg$unique_ref beginning "199206"
for *a do get .mlg$unique_ref

it returns correctly two values 19920612 and 19920611.

If I then decide I want the file in descending order, I do 
$anal/rms/fdl mlg.dat to get mlg.fdl. If I edit this file and change the word 
'string' to 'dstring' (for descending) and convert mlg.dat with
$convert/fdl=mlg.fdl mlg.dat mlg.dat I get a descending order file :-

19921225
19920612
19920611

If I then run my script on it again I find it picks up incorrectly no records.
If I change the script to pick up records beginning "19920" it still picks
up nothing. But if I change it to read "1992", it picks up all three as
expected.

If I change the script to use the CONTAINING operator then it works for all
search strings.
So it seems the BEGINNING operator only likes ascending strings or
descending strings of less than 5 characters.
My customer has the same problem with far more complex files and I have 
reproduced with the simple example shown.

Is there a restriction on the BEGINNING operator? Same results with '='.

Any workarounds please ?

FDL for descending file follows.

Thanks

Clive

IDENT	"19-JUN-1992 12:37:47	VAX/VMS ANALYZE/RMS_FILE Utility"

SYSTEM
	SOURCE                  VAX/VMS

FILE
	ALLOCATION              9
	BEST_TRY_CONTIGUOUS     no
	BUCKET_SIZE             2
	CLUSTER_SIZE            3
	CONTIGUOUS              no
	EXTENSION               0
	FILE_MONITORING         no
	GLOBAL_BUFFER_COUNT     0
	NAME                    "DISK$TECH:[ALLIN1.SITE.LIB_BRITISH]MLG.DAT;2"
	ORGANIZATION            indexed
	OWNER                   [ALLIN1]
	PROTECTION              (system:RWED, owner:RWED, group:RE, world:)

RECORD
	BLOCK_SPAN              yes
	CARRIAGE_CONTROL        none
	FORMAT                  fixed
	SIZE                    16

AREA 0
	ALLOCATION              9
	BUCKET_SIZE             2
	EXTENSION               0

KEY 0
	CHANGES                 no
	DATA_KEY_COMPRESSION    yes
	DATA_RECORD_COMPRESSION no
	DATA_AREA               0
	DATA_FILL               100
	DUPLICATES              no
	INDEX_AREA              0
	INDEX_COMPRESSION       yes
	INDEX_FILL              100
	LEVEL1_INDEX_AREA       0
	NAME                    ""
	NULL_KEY                no
	PROLOG                  3
	SEG0_LENGTH             16
	SEG0_POSITION           0
	TYPE                    dstring   <- this is the line I changed

ANALYSIS_OF_AREA 0
	RECLAIMED_SPACE         0

ANALYSIS_OF_KEY 0
	DATA_FILL               6
	DATA_KEY_COMPRESSION    54
	DATA_RECORD_COMPRESSION 0
	DATA_RECORD_COUNT       3
	DATA_SPACE_OCCUPIED     2
	DEPTH                   1
	INDEX_COMPRESSION       72
	INDEX_FILL              2
	INDEX_SPACE_OCCUPIED    2
	LEVEL1_RECORD_COUNT     1
	MEAN_DATA_LENGTH        16
	MEAN_INDEX_LENGTH       18

Several of the functions will not work with the beginning operator if the
key is descending.  I presume that ALL-IN-1 assumes that all index files
are ascendind (hence the logic around FIXER).

My solution has been to change '=' to '<=>' when looking for records 
beginning with a certain string.  Of course this doesn't guarantee that the
records actually begin with the string only that they contain it.  This
also causes a serious performance hit since all searches are sequentinal.

Anyone have any better ideas than comming up with FIXER logic for customized
applications to fabricate an ascending key out of a descending key?

Joe

    Use SQL/Relational Access for ALL-IN-1 ? ;-)

    Joe Duncan @ OPA

If it's of any consolation, the problems with descending keys (visible using 
the FOR function and with phantom data-sets) have been fixed in 3.0. I don't 
know of any 2.4 patch for this problem.

Cheers,
Derek