Regarding legacy reporting tools, which statement about sort/report generators versus index/report generators is generally correct in terms of resources and workflow?

Introduction / Context:
Classic reporting pipelines often relied on either pre-sorting data (sort/report) or leveraging indexes (index/report). Understanding their trade-offs clarifies performance tuning and storage planning for reporting workloads, especially in environments with limited resources or batch processing constraints.

Given Data / Assumptions:

• Sort/report workflows create sorted intermediate files prior to formatting output.
• Index/report workflows read records in indexed order without full re-sorts.
• Disk I/O and temporary storage are key resource considerations.

Concept / Approach:

A sort/report generator typically materializes temporary sorted datasets, consuming extra disk space and I/O. Index/report generators can stream records in key order via the index, which reduces temporary storage and can be faster in many cases. Therefore, it is generally true that sort/report generators require more disk space; the claim that they are faster or that they do not need to sort is usually false in comparison to index-driven approaches.

Step-by-Step Solution:

Verification / Alternative check:

Batch ETL and mainframe-era documentation consistently describe sort phases generating external files, while indexed scans minimize temporary storage.

Why Other Options Are Wrong:

Faster than index/report: Usually not; sorts add overhead.

No need to sort: Contradicts the very nature of sort/report.

Both (a) and (b): Incorrect because (a) is not generally true.

Common Pitfalls:

Assuming modern in-memory sorts always beat index scans; scale and I/O patterns matter.

Final Answer:

Sort/report generators require more disk space than index/report generators