Downloaded members may receive wrong extension

[adam-wolfe]

Describe the bug

If I have a PDS named ADAM.TEST.JCL that contains a member named CBLTEST (to CLG some program for example), then try to save all members or save just the CBLTEST member, the downloaded member will be given a .cbl extension. This differs from how the member is opened by Zowe Explorer (which correctly assignes the .jcl extension).

It appears that the member name is being factored into how the extension is being assigned when we should be relying on the name of the PDS.

To Reproduce

1. Find a PDS that clearly contains a certain kind of data (JCL, COBOL, REXX, etc.).
2. Within that PDS, ensure that there are members whose names indicate some other data type. Types are inferred based on this logic:

   zowe-explorer-vscode/packages/zowe-explorer-api/src/fs/types/datasets.ts

   Lines 20 to 32 in e744429

   	export const DS_EXTENSION_MAP: Map<string, (string | RegExp)[]> = new Map([
   	[".c", ["C"]],
   	[".jcl", ["JCL", "JCLLIB", "CNTL", "PROC", "PROCLIB"]],
   	[".cbl", ["COBOL", "CBL", "COB", "SCBL"]],
   	[".cpy", ["COPYBOOK", "COPY", "CPY", "COBCOPY"]],
   	[".inc", ["INC", "INCLUDE", "PLINC"]],
   	[".pli", ["PLI", "PL1", "PLX", "PCX"]],
   	[".sh", ["SH", "SHELL"]],
   	[".rexx", ["REXX", "REXEC", "EXEC"]],
   	[".xml", ["XML"]],
   	[".asm", ["ASM", /ASSEMBL/]],
   	[".log", ["LOG", /SPFLOG/]],
   	]);

3. Download all members
4. Notice that extensions are not consistent among the downloaded members

Expected behavior

We should only be basing the extension on the DSN and not the member name, e.g., if I download all members from ADAM.TEST.JCL, every downloaded member should be given the .jcl extension.

Screenshots

Desktop (please complete the following information):

• OS:
• Zowe Explorer Version: 3.5.0
• (Optional) Zowe CLI Version:
• (Optional) Do you have secure credentials enabled?
• (Optional) Are you using a custom credential manager?

Additional context

[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.

[Vinayak9769]

Hi can I work on this? :)

[JWaters02]

We should only be basing the extension on the DSN and not the member name, e.g., if I download all members from ADAM.TEST.JCL, every downloaded member should be given the .jcl extension.

When implementing the download stuff I always had it in the back of my head that the way we currently detect file extension is not good, because guessed based on PDS name is unreliable at best. But now that I look back on it, setting the extension based on the member name is not good at all, because:

1. you almost always have one type/language of members per PDS
2. the PDS is usually named with the language involved (as DS_EXTENSION_MAP shows)
3. you can use file associations in vscode to extend this

Fix for now would be to switch getExtensionMap to just use the getExtension function instead of matching on per member names.

I know we've had chats about the file extension detection stuff before (over a year ago) and I think it was determined that most of that should be done by the LSP extensions that can detect languages when doing the analysis on the contents of the file. However when we download data sets we don't get the luxury of opening each file for download, so it really is just down to ZE to figure it out itself.

We could revisit this problem later or talk about it during a standup. As a quick example I just thought up while typing this, we could allow LSP extenders to implement a smarter file extension detection API which ZE can then use, that would obviously have a trade off of being slower, but maybe there could be an option for the user to select it if they want it with a known speed trade off. Or something else. What do you think? Thanks

[JWaters02]

Hi can I work on this? :)

@Vinayak9769 Of course, as I caused this issue originally add me as a reviewer to your PR, thanks!