Re: Sorting SMF records
"Small" <suhrrog2002-/[email protected]> Tue, 14 Sep 2010 01:22:02 -0000
| Newsgroups | gmane.comp.emulators.turnkey-mvs |
|---|---|
| Message-ID | <[email protected]> |
Ok, so I allocated the reblocked data on WORK03, Which is a 3390. UCB=01B0,Volume=WORK03,date=10.256,time=20:40:19,VTOC=OS,parm= VTOC: CCHH=X'00000001'-X'0001000E',DS4VTOCI=X'08',DSCB/TRK=49,DIR/TRK=44 VTOC: Trks/cyl=15,Track length=57326,Number of cyls=01113 WORK03 free 1015 cyls 0 trks max: 931 cyls 0 trks 14 datasets Number of free VTOC index records (VIRS)= N/A , blank DSCBS= 1405 //* //S010 EXEC COPYVBS //SYSUT2 DD DISP=(,CATLG,DELETE),DSN=SMF.SMFREBLK, // DCB=(RECFM=VBS,LRECL=23996,BLKSIZE=24000), // UNIT=SYSDA,SPACE=(CYL,(50,50),RLSE), // VOL=SER=WORK03 (SYSUT1 DD is in the proc and points to the latest SMF archive.) //* //S020 EXEC SORT,COND=(4,LT),RGN=6144, // PARM='MSG=AP,CORE=6291456' //EXITLIB DD DISP=SHR,DSN=RWS01.LINKLIB //SYSIN DD * SORT FIELDS=(07,04,PD,A,03,4,BI,A) END //SORTIN DD DISP=SHR,DSN=SMF.SMFREBLK //SORTOUT DD DISP=(,CATLG,DELETE),DSN=SMF.SMFSORT, // UNIT=SYSDA,VOL=SER=WORK03, // SPACE=(CYL,(50,50),RLSE), // DCB=(LRECL=32756,BLKSIZE=32760,RECFM=VB) //* I didn't include the MODS statement for the exits, because I didn't want to introduce another variable. Once this works, I'll try the exits again. IEF285I JES2.JOB00010.SO0102 SYSOUT IEF285I JES2.JOB00010.SO0103 SYSOUT IEF285I JES2.JOB00010.SO0104 SYSOUT IEF285I SMF.DAILY.DATA.G0061V00 KEPT *-------45 IEF285I VOL SER NOS= WORK03. IEF285I SYS1.UCAT.MVS KEPT *--------0 IEF285I VOL SER NOS= MVSCAT. IEF285I SMF.SMFREBLK CATALOGED *-------62 IEF285I VOL SER NOS= WORK03. IEF373I STEP /COPYVBS / START 10256.2026 This resulted in the following messages: 001 COPYVBS STARTED COPYVBS_09/06/10_11.57 COPYVBS I/O: WRITTEN: 10,754 RECORDS 998 COPYVBS ENDED RC= 4 IER059A - REC LNG INVALID FOR DEVICE From SORT As you can see, I did get the CORE= parameter to work, with your help. Apparently this must be calculated exactly and matched to the region. So now I'm trying different record lengths . //S010 EXEC COPYVBS //SYSUT2 DD DISP=(,CATLG,DELETE),DSN=SMF.SMFREBLK, // DCB=(RECFM=VBS,LRECL=19096,BLKSIZE=19100), // UNIT=SYSDA,SPACE=(CYL,(50,50),RLSE), // VOL=SER=WORK03 //* I also tried 3350, 3375 with half, and third track blocks. All gave me the above message until I came down to this: //S010 EXEC COPYVBS //SYSUT2 DD DISP=(,CATLG,DELETE),DSN=SMF.SMFREBLK, // DCB=(RECFM=VBS,LRECL=07156,BLKSIZE=07160), // UNIT=2314,SPACE=(CYL,(50,50),RLSE), // VOL=SER=SORT01 //* //S020 EXEC SORT,COND=(4,LT),RGN=6144, // PARM='MSG=AP,CORE=6291456' //EXITLIB DD DISP=SHR,DSN=RWS01.LINKLIB //SYSIN DD * SORT FIELDS=(07,04,PD,A,03,4,BI,A) END That resulted in: 001 COPYVBS STARTED COPYVBS_09/06/10_11.57 COPYVBS I/O: WRITTEN: 10,754 RECORDS 998 COPYVBS ENDED RC= 4 IER036I - B = 7296 IER037I - G = 163 IER038I - NMAX = 790 IER050I - END MERGE PH IER054I - RCD IN 10754,OUT 10754 IER052I - EOJ As for speed, and efficiency - I don't recall the run times with the unmodified CORE, but with elapsed time of about a second, I don't think I have to worry about that right now. ************************************************************************\ ************************************************************ * 3. Jobstep of job: SMFSORT0 Stepname: SORT Program name: SORT Executed on 13.09.10 from 21.01.10 to 21.01.11 * * elapsed time 00:00:01,17 CPU-Identifier: RWS1 Page-in: 0 * * CPU time 00:00:00,65 Virtual Storage used: 6144K Page-out: 0 * * I/O Operation * * Number of records read via DD * or DD DATA: 2 * * DMY.......0 DMY.......0 DMY.......0 148.......0 136.....214 137......32 132......36 133......30 135......24 138.....100 * * 134.....206 136.....212 141.......0 141.......0 DMY.......0 131.....209 1B1.......0 1B0......46 135.......0 137.......0 * * * * Charge for step (w/o SYSOUT): 1,08 * ************************************************************************\ ************************************************************ It's nice to see though, that all of the region was actually used! More results in my next post! Thanks again Roger