Re: Sorting SMF records

> Small wrote:

> Ok, I understand that.  Here is what's happening:
 
> 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.

SORT is suppose to handle variable length spanned records.  The SORT manual notes them as VRE instead of VBS however.  Don't know if unblocked input would make a difference.

> 2. I run SORT with 8 SORTWK daasets and PARM='MSG=AP,BALN,DIAG'
> (I also tried CRCX, but the result was the same.)

> 3. Sort runs for a little while and seems to read all the data, but
> then ABENDS with S0C1.  It appears that someone intentionally
> branched to an area initialized with x'00000000', hence the S0C1.

There were some items in SORT which may have changed since original TK3 was distributed.  Memory size for SORT to use was perhaps one of them.

> 4. The last messages from the DIAG output are:

><snip>

Believe memory size for SORT use is in the DIAG messages as well.  Is it too small?  For 7K size records it specified 100K minimum IIRC.

><snip>

> BTW:  Is it possible to attach files to these messages in theis
> forum?

Don't believe the forum supports attachments currently.

However you can get assistance with your exact SORT JCL and DATA files if you zip them up and upload them to the files section for others to work with.

Or, post a message with SORT JCL and JCL you use to prepare your SMF data so that folks may use their own data for input.

Some of the other problems you are having, IDCAMS on MVSCAT for instance may be due to bugs in the DASD image on original TK3 image ( 3375, 3380 & 3390 had various glitches ).  3270 error may be from attempting to attach other than 3270-2 ( ie 3270-2E and 3270-3,4,5? ) may give the error display initially.  This might not be it exactly as my memory on the issues are not in the forefront of my mind currently.

Phil