Re: Sorting SMF records

--- In [email protected], Rick Fochtman <rfochtman@...> wrote:
>
> -----------------------------------------<snip>-------------------------------------
> yvette hirth wrote:
> 
> >  
> >
> > 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.
> >
> ---------------------------------<unsnip>-------------------------------
> OS/360 didn't support any DASD device beyond the 3330-11. 3380/3390 are 
> out of the question because of that limitation.
> 
> -----------------------------------------<snip>--------------------------------
> 
> >
> > 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
> >
> -------------------------------------<unsnip>-----------------------------------
> It would help immensely if the SORT JCL and control statements could be 
> posted. OS/360 SORT/MERGE handled VBS records very nicely but the 
> control statements had to be perfect to do so. It may also be that the 
> data contains an incomplete spanned record, not at all unusual.
> 
> Also, if you could find the FIXVBS program on the CBTTAPE.org web site, 
> that might be useful in this situation. FIXVBS will delete any "partial" 
> logical records that might be causing the problem. It should work just 
> fine on OS/360, since that's where it was originally developed.
> 
> Rick 
> <mailto:yvette@...?subject=Re:%20%5Bturnkey-mvs%5D%20Re:%20Sorting%20SMF%20records> 
> <mailto:[email protected]?subject=Re:%20%5Bturnkey-mvs%5D%20Re:%20Sorting%20SMF%20records>
>
I have used the following JCL to sort dumped SMF data on MVS 3.8 using the OS/360 sort utility, no special mods or anything.  My sort work devices are 2314's.  Hope this helps!

//SORTSMF  JOB ACCT,DSTONE,CLASS=1,MSGCLASS=T,NOTIFY=DSTONE
//*
//SORT    EXEC PGM=SORT,REGION=4096K PARM='MSG=AP'
//SORTLIB  DD  DISP=SHR,DSN=SYS1.SORTLIB
//SYSOUT   DD  SYSOUT=*
//SYSIN    DD  *
  SORT     FIELDS=(6,1,BI,A)
  END
//SORTIN   DD  DISP=OLD,DSN=DSTONE.SMFDUMP
//SORTOUT  DD  UNIT=SYSTS,SPACE=(19069,(5000,500),RLSE),
//             DISP=(,DELETE),
//             DCB=(LRECL=32756,BLKSIZE=19069,RECFM=VBS)
//SORTWK01 DD  UNIT=SORTWK,SPACE=(CYL,(199))
//SORTWK02 DD  UNIT=SORTWK,SPACE=(CYL,(199))
//SORTWK03 DD  UNIT=SORTWK,SPACE=(CYL,(199))

Dennis Stone