Providing a new HPU parameter so that we can chose the number of BSAM buffers for SORTIN.

• When unloading and sorting data due to ORDER BY option, HPU reads data from tablespace and write it to DFSORT SORTIN dataset via QSAM with BUFNO=60, that is a default.
• In the environment where zHPF is enabled, DFSORT has used BSAM for SORTIN since z/OS V2.2. 
• DFSMS builds BSAM buffers below the 16MB line based on its design.
• If a previous PGM/process ready the DCB for input with specific BUFNO, DFSORT open the INPUT with that DCB. It means that BUFNO for the previous QSAM is passed to the subsequent BSAM.
• If we use parallel unloading (Default: PARALLEL=20, MAXSORT=20), we're likely to run short of private storage below 16MB line and it can cause S878-10 abend. It's more likely to occur when migrating to z/OS V2.2 or higher.

For example:

27993 (BLKSIZE) * 60 (BUFNO) * 5 (Parallel) = 8,397,900 KB = 8.2 MB

=> If the maximum size of virtual private storage below 16MB line is 8 MB, a job must abnormally terminate with S878-10.

Refference:

1. DFSORT: Summary of Changes by Release

https://www-01.ibm.com/support/docview.wss?uid=isg3T7000084&aid=1

"A program that invokes DFSORT, ICETOOL or ICEGENER will now be able to exploit the High PerformanceFicon (zHPF) hardware. When zHPF is available, DFSORT SORT or MERGE applications will use BSAM forSORTIN, SORTOUT and OUTFIL data sets."

2. z/OS DFSMS Using Data Sets: Managing SAM Buffer Space

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/com.ibm.zos.v2r2.idad400/bufaq.htm

"If the system builds the buffer pool for a BSAM user, the buffer pool resides below the 16 MB line."

3. DFSORT development comment in CSP Case #TS002838843

"I confirmed this to DFSORT development. He said DFSORT use all the information it is available at run time. So, if a previous PGM/process ready the DCB for input with specific BUFNO, DFSORT OPEN the INPUT with that DCB. As a result, buffer pool is obtained using provided blocksize and bufno.(if zHPF is enabled)"