ISPF ISRSUPC to permit FINDALL to work against individual PDS members

The suggested enhancement as originally described was not considered practical, and we did not get any response to an alternative suggestion. We have logged the alternative suggestion as a possible future minor enhancement. We are however clearly unable to proceed with the original RFE enhancement, so we are closing it as rejected.

Jonathan Scott, HLASM and Toolkit team

The current FINDALL option primarily sets the return code after a search according to whether all search strings are flagged as having been matched somewhere. It still shows the matches as it scans the files even if not all matches are found.

When multiple PDS members are being scanned, it is difficult to see how an equivalent option could work. The suggestion that matches for a member are only to be listed if the member matches all strings would require deferral and buffering of a potentially unlimited amount of output, which would require major changes that do not seem justified.

Would it perhaps be enough to add an optional output line after each member saying how many of the search strings matched, for example in the form "n of m search strings matched", which would make it easy to scan for cases where all match? This would have to be optional because ISPF SRCHFOR post-processes the current SUPERC output format and could be confused by additional lines, in which case it would need a separate update to tolerate them. I suspect there might be other programs which do the same.

Also, as there is only one return code, it cannot indicate multiple results, but it could for example be set to 1 if all strings matched in at least one member.

It's not difficult to write a post-processing utility to read the output (as suggested) and list files with any combination of matches (not just ALL, but any logical combination) so I think that would be a simpler and more flexible solution for now.

Given that alternative solution, competing requirements and limited development resources, even the simple suggested solution of a message "n of m search strings matched" would not necessarily be accepted for implementation in the near future, but in my opinion it appears it would provide useful function for a reasonably small development effort.

Jonathan Scott, HLASM and Toolkit team

Due to processing by IBM, this request was reassigned to have the following updated attributes:
Brand - Servers and Systems Software
Product family - Enterprise Tooling
Product - High Level Assembler (HLASM)
Component - Other
Operating system - IBM z/OS
Source - None

For recording keeping, the previous attributes were:
Brand - Servers and Systems Software
Product family - z Systems Software
Product - z/OS
Component - ISPF
Operating system - IBM z/OS
Source - None