Re: Re: Sorting SMF records

halfmeg wrote:

>> 1. I reblock my SMF data using IEBGENER to a 2314 volume with a
>> BLKSIZE of 7004 (LRECL=7000,RECFM=VBS).  At this point I don't have
>> to worry about capacity, since I only have about 800 TRKS worth of
>> data.

can you move this to a 3380/3390 volume, and can you "unspan" your data?

a larger "track size" really means little wrt Hercules, as all the 
"disks" are files.  but using an 80 or a 90 would give you the ability 
to use larger blocksizes.

to me, the "spanned" DCB attribute might be causing the issue. 
traditionally, spanned attributes arose when either the record could be 
bigger than the LRECL, or in some cases to attempt to maximize space 
utilization.  if spanned is not needed and can be removed, that will 
simplify the i/o logic and reduce the potential number of issues.

see here:

http://publib.boulder.ibm.com/infocenter/zos/v1r9/index.jsp?topic=/com.ibm.zos.r9.cbcpx01/recfmv.htm

i remember VS/VBS being more frequently used during 3330 and 3350 days. 
  once the larger 3380 track size became popular, there didn't seem to 
be any great need for VBS.

if you can (i.e., if the "S" spanned attribute is optional), try setting 
sortout to LRECL=7000,RECFM=VB (or even RECFM=V) and see what happens. 
or set LRECL=<as big as possible based on track size>.

yes, more i/o will occur, and your job will probably run slower, but 
it's a good debugging technique for the problem you're reporting.

yvette hirth