Questionable dataset filtering on complex queries

[JWaters02]

Describe the bug

Some more complex dataset filters cause unexpected results. Occurs in both v2.18.0 and v3.1.0 with the same results.

Consider the example for the following search datasets filter (HLQ and USERIDs are placeholder - I'd show screenshots to make it easier, but then I'd have to take the time to censor the results to not reveal internal PDS names in public):

HLQ.USERID2.SOURCE(R80297*),HLQ.USERID1.SOURCE(R80297O1)

Here's a breakdown of the filter:

1. Inside HLQ.USERID2.SOURCE, there are 50 members. One is called R80297B2 and another is called R80297O2. So searching (R80297*) should match on these two members
2. Inside HLQ.USERID1.SOURCE(R80297O1), there are also 50 members. One is called R80297B1 and another is called R80297O1. This should simply match on the one item R80297O1 inside that SOURCE library. Note that the USERID part of the PDS name is slightly different than in the above two parts.

What actually happens:

1. HLQ.USERID2.SOURCE shows its 2 members correctly
2. HLQ.USERID1.SOURCE shows both R80297O1 and R80297B1 as if it is following the same pattern as in the first PDS of the filter.
3. HLQ.USERID1.SOURCE.FINAL is also shown, with all members that are inside of it.

So the unexpected results are in 3 and 4.

==============================

Now let's consider the next example:

HLQ.USERID2.SOURCE(R80297B2),HLQ.USERID2.SOURCE(EX1),HLQ.USERID1.SOURCE(R80297O1)

Expectations:

1. Two files in HLQ.USERID2.SOURCE, R80297B2 & EX1
2. The one file in HLQ.USERID1.SOURCE, R80297O1

What actually happens:

1. Only the R80297B2 file in HLQ.USERID2.SOURCE, completely ignoring the second member filter on the same PDS
2. "No data sets found" in HLQ.USERID1.SOURCE (in v2.18.0 the PDS does not show up at all)
3. "No data sets found" in HLQ.USERID1.SOURCE.FINAL (in v2.18.0 the PDS does not show up at all)

So here all 3 results are unexpected.

Desktop (please complete the following information):

• OS: Windows 10
• Zowe Explorer Version: v2.18.0/v3.1.0
• (Optional) Zowe CLI Version:
• (Optional) Are you using Secure Credential Store?

[github-actions]

Thank you for creating a bug report.
We will investigate the bug and evaluate its impact on the product.
If you haven't already, please ensure you have provided steps to reproduce the bug and as much context as possible.

[JTonda]

Plan to test this on the CLI first to rule out any upstream bugs.

[JWaters02]

Apologies, I haven't used zowe CLI before so it did not cross my mind.

I am not sure what the CLI command(s) would be for this. There is the zowe zos-files list data-set and zowe zos-files list all-members commands, but not sure how exactly I would apply it to this scenario. If someone could let me know how I could test this on CLI with my cases, that would be useful, thanks.

[JWaters02]

I think the issue is in how zowe explorer is dealing with multiple datasets with similar HLQs in the same filter but where one (or multiple) has member filters. To make the simplest example:

A filter on HLQ.1.SOURCE,HLQ.2.SOURCE returns all members in both PDS's

A filter on HLQ.1.SOURCE(HELLO),HLQ.2.SOURCE where only HLQ.1.SOURCE contains a member "HELLO", has HLQ.1.SOURCE successfully filter on the HELLO member, but HLQ.2.SOURCE returns empty, despite it expected return being all of its members.

The same goes with using wildcards, it seems to apply the wildcard from the first PDS's filter, to the second, that has a similar name. That is what I was trying to get at in my original comment.

Hope this helps!

[traeok]

I tested a few filters and found the right members to be returned, but the PDS nodes aren't always updated to reflect the new filter. After collapsing and reexpanding the PDS, the members are updated to match the filter.

For example, with the following filter:

trae.encoding.tests, trae.testpds

I get the following PDSes with members as expected:

Once I search for a new filter trae.encoding.tests(IBM1*), trae.testpds, the member list is kept intact for the trae.encoding.tests PDS (incorrect):

After collapsing and expanding both PDSes w/ the above pattern, the members are corrected for both: