Why SRCHFOR didn’t find my string (and how I fixed it)

 Not long ago, I was trying to search for a string inside a PDS using the SRCHFOR command. To my surprise, the command returned the message:String(s) not found

Invoking the SRCHFOR command with the search string

String(s) not found

But I knew for sure that the member contained the exact string!

Here is the member in PDS with the exact string that we are searching for.

This reminded me of a post I had read about two years ago where someone faced the same issue. At that time, I noted it as an interesting quirk of ISPF. Now that I’ve stumbled upon it again, I thought I’d document the problem, the solutions I explored, and how I eventually rediscovered that original tip.

The problem: SRCHFOR and case sensitivity

The root cause is simple: SRCHFOR automatically converts the search string to uppercase after you press Enter.

So if your dataset member has mixed-case text (e.g., HelloWorld) and you try:

SRCHFOR 'HelloWorld'

it silently changes it to:

SRCHFOR 'HELLOWORLD'

…and of course, the match fails.

Step 1: Checking the documentation

To be sure I wasn’t missing something, I pulled out the z/OS ISPF User Guide. I even uploaded the manual to NotebookLM and asked how to prevent SRCHFOR from changing the case of my search string.

NotebookLM suggested two options:

    1. Use ISPF 3.15 (Extended Search-For)

• This option provides an ASIS field.
• When you specify ASIS=YES, the search is performed without converting the string to uppercase.

• This worked perfectly.

Type the search string in the Asis field. As you see, multiple search strings can be searched in one go. 

String(s) found. Yeahh!

    2. Use the SFE Command

• SFE is a panel-driven version of SRCHFOR.
• You can invoke it directly against a PDS and provide the search key.
• This also respected the case and gave correct results.

Type 'SFE' in the line command area against the PDS.

Type the search string. Put a '/' on the Any case process option at the bottom left to select it. 

String(s) found.

Both solutions worked, but I still felt there must be a simpler way.

Step 2: Rediscovering the Reddit Tip

While searching online, I found the exact Reddit post I had read two years ago. The OP there had shared a neat trick:

• Invoke SRCHFOR without parameters:

  SRCHFOR
  

• This opens up the Search-For Options panel.

• From there, select the “Any case” process option.

Once you do this, SRCHFOR will no longer force your search string to uppercase. Problem solved!

(Credit to the Redditor who originally shared this tip)

Invoke SRCHFOR from the command line without passing a search string.

In the SRCHFOR options displayed, put a '/' on the Any case process option at the bottom left.

Try searching for the string (with lowercase) again

String(s) found.

Three Ways to Solve the Problem

Here’s a quick summary of the methods I tested:

1. ISPF 3.15 (Extended Search-For) with ASIS

   • Best for detailed searches with lots of parameters.

2. SFE Command

   • Quick, panel-based, and respects the case.

3. SRCHFOR (no parameters) → Select “Any case”

   • Simple, and once set, it keeps SRCHFOR from changing your string.

Bonus: SRCHFOR vs. SRCHFORE

While digging around, I also refreshed my memory on the difference between the two commands:

• SRCHFOR → Searches within a single dataset (PDS or sequential).

• SRCHFORE → The extended version, which lets you search across multiple datasets or a dataset list.

So if you often search across a group of libraries, SRCHFORE is your friend.

Wrap-Up

This little exercise was a reminder that even tools we’ve used for years can have hidden quirks. SRCHFOR changing case silently tripped me up, but now I know at least three ways around it.

If you ever find SRCHFOR telling you “No strings found” when you’re sure otherwise, try one of these fixes. And a big thanks to that Redditor from two years ago—your tip still saves the day!