I had one observation here which is contradictory for me
If we are going to leave upto the system to decide the blocksize it should take less time rather that if we code the blksize.The time here are .19(with blksize) and .20(without blksize)
May be possible I am wrong in my understanding.
Please clearify my doubt for following
a)What could be a better option coding bw coding the blksize option than to leaving up the system.
Please let me know incase I need to furnish any more information,thanks
Joined: 15 Feb 2005 Posts: 7129 Location: San Jose, CA
raghavmcs,
If you think its valid to draw conclusions about performance based on one job about which you haven't given any information (e.g. number of records, bytes sorted, etc), then I can easily counter your argument based on a job I ran with RECFM=VB, LRECL=2004 and BLKSIZE=2008 vs no BLKSIZE (-> SDB BLKSIZE=27998) and the same control statements you used.
Code:
EXCPs CPU Elapsed
With BLKSIZE=2008 1731 40.86 3.0
Without BLKSIZE (SDB) 1595 19.47 1.3
The lesson from this is - valid performance testing is an art.
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
The original statement was 80K records ... but one test for performance measurement is pretty much useless. 10 to 20 tests I could see maybe making some inferences from, but using one job output to determine performance isn't much better than closing your eyes and throwing darts to pick which way to go.
Not only that but the original difference was .20 vs .19 seconds -- which could very easily be not a difference if fully investigated (.194999 vs .195001 seconds for example). Not to mention the impact site standards could have on the job -- overriding the block size, for example.
Joined: 15 Feb 2005 Posts: 7129 Location: San Jose, CA
Quote:
The original statement was 80K records
The statement that "test.abc had 80K records" was a bit meaningless - we don't know how many records were deleted by the OMIT, sorted or written to the output data set.
