Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Questionable dataset filtering on complex queries #3424

Open
JWaters02 opened this issue Jan 29, 2025 · 3 comments
Open

Questionable dataset filtering on complex queries #3424

JWaters02 opened this issue Jan 29, 2025 · 3 comments
Assignees
Labels
bug Something isn't working Research Needed

Comments

@JWaters02
Copy link

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?
Copy link

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
Copy link

JTonda commented Jan 30, 2025

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

@JWaters02
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working Research Needed
Projects
Status: New Issues
Development

No branches or pull requests

3 participants