Enhance logical dump of PSE data set to effectively use the larger blksizes provides by z/OS 1.12 BSAM support

In fact, searching further from our database I found following
interesting info around how DSS proceeds the sequencial data set in
extended format
---
Because of the interface DSS uses to DUMP PSE data sets, we have never
"chained" the tracks of a PSE together in our dump buffer. So even
though our buffer size and the DCBEBLKSI we put into the tape label (
ie 256k ). We still only dump 1 track at a time for PSE data sets.
.
Also Because DSS uses Record Format U for our dump data set, we will
only dump the actual used space in our buffer. Even though our buffer is
256k, if you only put a single track into the buffer, we will only write
a block that is 56664 bytes long (plus some meta data). It is important
to know that DSS has always used record format U and the DCBEBLKSI
whether its 64k or 256k is only a "possible Maximum Blocksize". The
actual blocks written can be smaller and of varied sizes.

It is this design of DSS for PSE data sets that is the reason why the
TOTALBLOCKS count is very similar between tests with different blocks
( 32, 64 or 256k )
PSE data sets do not take advantage of the increased 256k blksize
introduced in z/OS 1.12. This is because the design of DSS does not
block together multiple tracks of data in order to fill the block for
PSE data sets. It reads 1 track (56664 bytes) at a time, and writes at
most 1 track of data per block regardless of the blksize (64K blocksize
or 256K blocksize).
PS and other data set types, DSS can block together