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.
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.
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
DownstreamFatalErrorsurfacing IRRSMO00 return codes of8/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