-
Notifications
You must be signed in to change notification settings - Fork 87
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Migrate the TSO issueTsoCommand
SDK to use the newer APIs (in z/OS 2.4)
#2144
Comments
Thank you for raising this enhancement request. |
issueTsoCommand
SDK to use the newer APIs (introduced in z/OS 2.4)issueTsoCommand
SDK to use the newer APIs (in z/OS 2.4)
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. |
After some discussion, we decided to implement this as an optional parameter in the SDK functions. That way it can be easily consumed by Zowe Explorer. The other alternative discussed was to implement this functionality and have it be enabled via an environmental variable (ENV), but this way might be more cumbersome for Zowe Explorer users to leverage, and having a VSCode setting for Zowe Explorer would be preferable over ENV. |
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:
The text was updated successfully, but these errors were encountered: