Open zFernand0 opened 1 month ago
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.
I'm sure this will come up if/when this is taken on, but a quick note on "migrate". It may need to be an additional flag to request the new behavior to maintain backwards compatibility for users that are back-level, haven't configured the new API behavior, or if there is some unexpected limitation within the new API.
Is your feature or enhancement request related to a problem or limitation? Please describe
Since the inception of the CLI and the
issueTsoCommand
feature, we've been using APIs introduced in z/OS 2.2 which require proper handling of the TSO Address Spaces (AS). That means starting the AS, sending the TSO command, collecting responses from the AS, and ultimately closing the AS. With the newer APIs (introduced in z/OS 2.4), we can send the TSO command to the REST API, and z/OSMF will manage start an AS and manage it with similar configuration and retention parameters as it manages the AS used for other z/OSMF related operations (e.g. listing datasets, submitting jobs). The configuration and retention parameters mentioned above refer to when to start a new AS or when to terminate/close the AS after X minutes of inactivity.Describe your enhancement idea
Migrate the TSO
issueTsoCommand
SDK to use the newer APIs (introduced in z/OS 2.4)Describe alternatives you've considered
Continue using the old z/OS 2.2 APIs to operate (e.g. start, send-to, collect-from, close) the AS
Provide any additional context
This is related to:
690