You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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):
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
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:
HLQ.USERID2.SOURCE shows its 2 members correctly
HLQ.USERID1.SOURCE shows both R80297O1 and R80297B1 as if it is following the same pattern as in the first PDS of the filter.
HLQ.USERID1.SOURCE.FINAL is also shown, with all members that are inside of it.
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.
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.
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:
HLQ.USERID2.SOURCE
, there are 50 members. One is called R80297B2 and another is called R80297O2. So searching (R80297*) should match on these two membersHLQ.USERID1.SOURCE(R80297O1)
, there are also 50 members. One is called R80297B1 and another is called R80297O1. This should simply match on the one itemR80297O1
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:
HLQ.USERID2.SOURCE
shows its 2 members correctlyHLQ.USERID1.SOURCE
shows bothR80297O1
andR80297B1
as if it is following the same pattern as in the first PDS of the filter.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:
HLQ.USERID2.SOURCE
,R80297B2
&EX1
HLQ.USERID1.SOURCE
,R80297O1
What actually happens:
R80297B2
file inHLQ.USERID2.SOURCE
, completely ignoring the second member filter on the same PDSHLQ.USERID1.SOURCE
(in v2.18.0 the PDS does not show up at all)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):
The text was updated successfully, but these errors were encountered: