If your DBA is suggesting a READ, then he should suggest how to code it, too.
FIND returns a set of records based on some logical criteria. READ returns a sequence of records - in your example, by a key, but physical and internal sequences are also possible. FIND syntax allows a combination of descriptors; READ does not.
If your logical condition was an AND, then you could code
READ FILE-1 BY DESCRIPTOR-DATE1 FROM #start-date THRU #end-date
WHERE DESCRIPTOR-DATE2 = #start-date THRU #end-date
AND Indicator = "C"
“WHERE DESCRIPTOR-DATE2” limits the records to a subset of DESCRIPTOR-DATE1. Can you
guarantee that all records with the specified DESCRIPTOR-DATE2 values also contain the
specified DESCRIPTOR-DATE1 values? With an OR condition, you need a descriptor which
will return all values specified for both DESCRIPTOR-DATE1 and DESCRIPTOR-DATE2.
Here’s a simpler example.
FIND file with SURNAME = 'ZBROG'
OR FIRSTNM = 'RALPH'
This returns all ZBROGs and all RALPHs.
If you were certain that all RALPHs were ZBROGs, then you could code
READ file BY SURNAME FROM 'ZBROG' THRU 'ZBROG'
WHERE FIRSTNM = 'RALPH'
But if RALPH SMITH exists on the file, the FIND will return this record, but the READ
will not. You need a descriptor which returns all ZBROGs and all RALPHs, and then you
can ignore those records which do not satisfy both criteria.
You cannot do what you needed in a single READ
You may have to use two read statements and store the values in workfile and merge the two files and then use the work file for processing.
READ FILE-1 BY DESCRIPTOR-DATE1 FROM #start-date THRU #end-date
WRITE WORK 1 #REC
END-READ
READ FILE-1 BY DESCRIPTOR-DATE2 FROM #start-date THRU #end-date
WRITE WORK 1 #REC
END-READ
The disadvantage of two READs: If the periods of time are overlapping each other, you will process some records twice…
The advantage is perhaps: It could be faster and you don’t need space on the Adabas WORK-area.