Handle converting characters to IBM-1047 codepage before listing data sets

[traeok]

Is your feature or enhancement request related to a problem or limitation? Please describe

z/OSMF does not currently support converting characters within data set search patterns to the IBM-1047 codepage. However, since data set names are coerced into IBM-1047 before they are created, a data set search pattern may not return the appropriate data sets as expected.

For example, consider the data set named MYUSER.$IGN. With some z/OSMF APIs, you have the ability to pass the header X-IBM-Dsname-Encoding, which will inform z/OSMF of what codepage the given data set name is encoded in. It will handle the conversion on server-side - so if you go to save a data set named MYUSER.£IGN with this header set to 285, it will convert the name from IBM-285 to IBM-1047 before uploading the contents, resulting in a successful upload.

However, if you search for MYUSER.£IGN when listing data sets, the data set MYUSER.$IGN is not returned as the search pattern is interpreted as is. This is because the list APIs do not convert the characters in the pattern before searching for it.

Describe your enhancement idea

We could consider implementing a conversion table to handle these characters and "coerce" them into the expected characters for z/OSMF API.

Describe alternatives you've considered

Ideally, z/OSMF would make their endpoints consistent by using the X-IBM-Dsname-Encoding header to convert the search patterns from the given codepage (when specified).

[github-actions]

Thank you for raising this enhancement request.
The community has 90 days to vote on it.
If the enhancement receives at least 5 upvotes, it is added to our development backlog.
If it receives fewer votes, the issue is closed.