Concurrent REST requests for downloading PDS members results in several abended IZUFPROC jobs

Say that I have a sample application that makes multiple, concurrent requests to the z/OSMF REST API to download PDS members. It uses the endpoint for retrieving the contents of a data set member: https://www.ibm.com/docs/en/zos/2.4.0?topic=interface-retrieve-contents-zos-data-set-member

If I use this API to download all the PDS members from a set of partitioned data sets, for example:

["SYS1.PROCLIB",
 "SYS1.LINKLIB",
 "SYS1.CMDLIB",
 "SYS1.CSSLIB",
 "SYS1.DBBLIB",
 "SYS1.FONTLIB",
 "SYS1.HELP",
 "SYS1.MACLIB"]

Making an API request for each member in each data set results in several IZUFPROC jobs under my username. These jobs seem to be used for spawning TSO address spaces and satisfying these data set requests. Each job abends with code S222 once the address space is no longer in use. However, these jobs remain on the system after the requests are finished.

In an effort to alleviate this job pollution, we investigated using the header X-IBM-Obtain-ENQ, but this passes the responsibility to the client for holding/releasing data set enqueues. This presents its own risks as the API consumer could lose network connectivity after obtaining an exclusive enqueue, effectively locking that data set until the timer elapses. Still, the API consumer would need to locate and delete any jobs created by these requests. However, the client is not aware of what address spaces/jobs were used to satisfy each request, whereas the server already has access to that information.

The expected behavior is for the z/OSMF server to periodically delete/clean-up the abended jobs that were created for addressing previous data set requests.

---

Another bottleneck for this API endpoint: the amount of requests needed to download all requested members. As it currently stands, to download 10 data sets with 2,500 members in each data set, I would have to make 25,000 HTTP requests. Depending on the rate at which each request goes out and how many requests are needed to satisfy the download operation, this could be perceived as a denial of service attack.

The z/OSMF team could consider implementing a batch API that would process several download requests, allowing the client to fetch all the members of a given data set with one request. Or, they could enhance the current endpoint to allow passing a list of data sets, leveraging multipart streaming for the downloads.