Skip to content
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

Feature Request: pyRACF should Leverage IRRSMO00's ability to compensate for small buffers #71

Open
ElijahSwiftIBM opened this issue Feb 6, 2024 · 0 comments
Assignees
Labels
enhancement New feature or request

Comments

@ElijahSwiftIBM
Copy link
Collaborator

Is your feature request related to a problem? Please describe.
pyRACF is about to start using a dynamic buffer size to interact with IRRSMO00 which means it is possible for a user or application to specify a buffer too small for command output. This will result in a DownstreamFatalError surfacing IRRSMO00 return codes of 8/4000/Len, but the partial data would be discarded and this would require the application or user to re-drive the activity with a larger buffer which is undesirable.

Describe the solution you'd like
Note: It is possible for IRRSMO00 to process a part of the input document, and then find there is not enough space in the result buffer to return the results. In this situation, the results for that portion of the input are lost, and that part of the request is repeated on the next call to IRRSMO00. This may result in unexpected output, such as a 'not found' error if the work in question was a delete operation. This can only happen If the result is too small.

https://www.ibm.com/docs/en/zos/3.1.0?topic=rsismo-usage-notes

Describe alternatives you've considered
We could try to implement this at the C level, but it would complicate the simple nature of its existing structure, and it would also require a lot of dynamic memory management as there would need to be a lot of "simultaneous" storage held to build the buffer into a large response before returning to the python layer.

We could try to implement this at the python layer, but I am uncertain all the necessary memory objects will exist and still be accessible when a call comes in to re-drive the c code from python with the added handle pointer.

Additional context
N/A

@ElijahSwiftIBM ElijahSwiftIBM added the enhancement New feature or request label Feb 6, 2024
@ElijahSwiftIBM ElijahSwiftIBM self-assigned this Feb 6, 2024
@ElijahSwiftIBM ElijahSwiftIBM added this to the Beta 1.0b6 milestone Feb 20, 2024
@lcarcaramo lcarcaramo removed this from the Beta 1.0b6 milestone Sep 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants