zowe-install shell allocates runtime libs under temporary volumes (lost after 3days)

[pavelzlatnik]

Describe the bug
When launching zowe-install.sh script to allocate runtime datasets, there is missing option to specify under which volume or storage class should be those datasets allocated. Because of that, datasets are allocated under temporary volume and got lost after 3 days.
ZFS runtime dataset we are allocating by us, so we have support for both, non-sms (volume) or sms (storage class). AUTH and SAMP are allocated by shell script, and it accept neither of them (and that is the reason why system allocate it under temporary volume).

To Reproduce
Steps to reproduce the behavior:
run zowe-install.sh for example under your pmfid datasets, see results for allocated datasets

Expected behavior
Script should have two new parameters and optionally accept either volume or storage class, and based on those should be done dateset allocation.

I have checked the code inside the script, there is not finished call to other shell script which should be probably responsible for datasets allocation. But even if this script would be called, it accepts only volume. But for sms managed system, it should accept also storage class, I have checked IBM doc about allocate and it should be supported as well.

So fix zowe-install.sh to accept new parameters like -v for volume, -sc for storage class and either enhance zowe-install-MVS.sh to accept as well volume and storage class parameter, or modify it to call allocate-dataset.sh, and enhance allocate-dataset.sh to support storage class in it (it has volume support, but storage class support is missing in allocate-dataset.sh ).

Screenshots
If applicable, add screenshots to help explain your problem.

how to use storage class with allocate based on IBM doc

links:
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.ikjc500/ikj2l2_Example_26__Override_the_data_class.htm

https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ikjc500/alloccmd.htm

[Martin-Zeithaml]

Reported for V1, but the same is happening for V2/3.