Allocation units are not handled correctly when copying data sets between LPARs

[adam-wolfe]

Describe the bug

Zowe Explorer allocates either too much space or fails silently when attempting to copy a data set between LPARs if that data set was not allocated in tracks.

I moved this to the CLI repo since I'm seeing the issue of data sets allocated in cylinders being copied to 225-track data sets on the target system on both Zowe CLI and Zowe Explorer.

There seem to be other issues with non-track/cylinder allocation units for copying PDSs with Zowe Explorer, so there may need to be an additional fix for Zowe Explorer.

To Reproduce
Copying a data set allocated in cylinders:

1. Allocate a 1 cylinder data set (which amounts to 15 tracks).
2. Attempt to copy that data set from one LPAR to another.
3. Check the allocation information for the new copy of the data set.
4. Note that size is now 225 tracks (15^2).

Copying a PDS allocated in MB (attempting to copy a data set allocated in blocks fails similarly):

1. Allocate a 1 MB data set (which seemed to amount to ~23 tracks).
2. Attempt to copy that data set from one LPAR to another.
3. Note that nothing seems to happen with Zowe Explorer.
   a. Both Zowe CLI and Zowe Explorer handle this allocation correctly when given a sequential data set.

Expected behavior

I would expect the new data set to have the same number of allocated tracks as the original data set (assuming we cannot get more granular allocation information than track count - which is provided to us by z/OSMF).

Presumably, it would be safe to always allocate the copy in tracks since that is the allocation unit described by the Size field in the 'show attributes' view. Is there any harm in ignoring the Space Unit field?

Screenshots

Desktop (please complete the following information):

• OS:
• Zowe Explorer Version: 3.3.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.

[awharn]

This is due to a bug in the z/OSMF List APIs. When the listing is returned, the size is always returned as the number of tracks, but also returns with the ALCUNIT used to originally create the data set, which in this case is CYLS.

Thusly, when the original data set is listed, it has a size of 15 and an ALCUNIT of CYLS.

This method then uses the options from the original data set to provision a new data set. However, because of the faulty data returned, it allocates using 15 CYLS, which is 225 TRACKS.