Joined: 08 May 2006 Posts: 1205 Location: Dublin, Ireland
sergeyken wrote:
Garry Carroll wrote:
RECFM=VB,LRECL=204,BLKSIZE=27998 doesn't seem right either. Specification of space parameter in JCL seems to negate BLKSIZE=0.
e.g. (204 * 137) + 4 = 27952 or (204 * 138) +4 = 28152.
Garry.
Since long time parameter BLKSIZE=0 is supported, to automatically calculate the most appropriate value based on RECFM=/LRECL=/UNIT=
TS job shows both SPACE=(27998,(100,10),RLSE) and BLKSIZE=0. Syncsort output shows the BLKSIZE as 27998, which is not a value that the system would calculate in this case - but is the value coded in the SPACE parameter
TS job shows both SPACE=(27998,(100,10),RLSE) and BLKSIZE=0. Syncsort output shows the BLKSIZE as 27998, which is not a value that the system would calculate in this case - but is the value coded in the SPACE parameter
The value SPACE=(27998,... does not play any role in defining BLKSIZE shown by SYNCSORT.
The value for BLKSIZE is chosen by hierarchy:
1) from DD parameter [DCB=(]BLKSIZE=value, or calculated by zOS from RECFM=/LRECL=/UNIT= when value=0
2) from DSCB for output DSN, if one has been previously created with defined BLKSIZE
3) used the same value as LRECL[+4] when no other definition found
Joined: 08 May 2006 Posts: 1205 Location: Dublin, Ireland
sergeyken wrote:
Garry Carroll wrote:
TS job shows both SPACE=(27998,(100,10),RLSE) and BLKSIZE=0. Syncsort output shows the BLKSIZE as 27998, which is not a value that the system would calculate in this case - but is the value coded in the SPACE parameter
The value SPACE=(27998,... does not play any role in defining BLKSIZE shown by SYNCSORT.
The value for BLKSIZE is chosen by hierarchy:
1) from DD parameter [DCB=(]BLKSIZE=value, or calculated by zOS from RECFM=/LRECL=/UNIT= when value=0
2) from DSCB for output DSN, if one has been previously created with defined BLKSIZE
3) used the same value as LRECL[+4] when no other definition found
So,if the SPACE=(27998,.... doesn't play any role in calculating the value shown in SYNCSORT report, where does it come from? BLKSIZE=0 would not result in this value, based on LRECL=204. Is Syncsort reporting an incorrect blocksize (in which case it is a bug)? Or has Syncsort overridden the system-calculated value and imposed a blocksize based on the SPACE parameter?
Joined: 08 May 2006 Posts: 1205 Location: Dublin, Ireland
Joerg.Findeisen wrote:
@Garry: Try with FB vs VB in a IEFBR14. You will notice the difference.
Dataset attributes after allocating with IEFBR14 show LRECL=204 & BLKSIZE=0 regardless of whether FB or VB whether I specify SPACE=(27998,.. or SPACE=(TRK,...
I don't see this explaining why Syncsort is reporting a blocksize of 27998?
Joined: 15 Aug 2015 Posts: 1333 Location: Bamberg, Germany
Although different topic, when I try allocating with VB I get 27998, with FB I see what you commented. Syncsort is correctly reporting a valid BLKSIZE here.
So,if the SPACE=(27998,.... doesn't play any role in calculating the value shown in SYNCSORT report, where does it come from? BLKSIZE=0 would not result in this value, based on LRECL=204. Is Syncsort reporting an incorrect blocksize (in which case it is a bug)? Or has Syncsort overridden the system-calculated value and imposed a blocksize based on the SPACE parameter?
BLKSIZE=0 is converted by z/OS NFS Server while handling DISP=NEW from DD statement. Known values of RECFM=/LRECL=/UNIT= are taken into account.
If any of needed values of RECFM=/LRECL=/UNIT= is not known at dataset allocation time, then acceptable BLKSIZE cannot be calculated.
z/OS Network File System Guide and Reference wrote:
Block size (BLKSIZE) specifies the maximum length, in bytes, of a physical block of storage in MVS. If BLKSIZE(0) is specified, the system will determine the optimal block size based on the maximum record length (LRECL) and the physical characteristics of the disk, or approximately half of a physical track. Half track blocking is optimal in that it reduces the amount of wasted storage on the disk. If BLKSIZE(0) is specified for Direct Access (DA) data sets, the system does not determine the block size. z/OS NFS Server uses a formula to calculate the block size; see blksize(0) in Data set creation attributes syntax.
After running SYNCSORT with no DCB parameters specified in the SORTOUT or other output DD, nevertheless good value of BLKSIZE is assigned.
I use BLKSIZE=0 since long time in most of cases. Appropriate values are substituted successfully.
Often, for RECFM=VB, there is no need to calculate exactly BLKSIZE=(LRECL*n + 4), because V-records rarely are all of the same maximum size. It makes sense to choose maximum BLKSIZE fitting the given disk drive.
This commonly used value for commonly used UNIT - 27998 bytes - has been used by someone also to allocate space via parameter SPACE=(27998,... Here it is used ONLY to recalculate required block size of physical record to corresponding number of tracks, or cylinders, - in case different type of drive is ever used.
