View previous topic :: View next topic
|
Author |
Message |
subdalal
New User
Joined: 27 Sep 2010 Posts: 21 Location: Boudh
|
|
|
|
Recently, I have come across a number of sorts, some existing, some new, that are using parms and control statements that can cause runtime and cpu degradation, as well as cause unnecessary abends. Below are just a few of those statements and/or parms that have been found to cause issues when not used properly.
The most frequently used sort control statement that is being misused is the OUTREC. In some instances it is being used in conjunction with INREC or in place of INREC. Keep in mind if the intent is to reduce the size of the file entering the sort then use INREC.
Below are some guidelines to consider, in order to determine when to use either the INREC or OUTREC options.
• Use the INREC control statement to delete irrelevant data fields, reformat numeric
fields to a shorter length, or combine numeric fields with arithmetic operations(mul,add,sub) and
functions. Reducing the size of the input records before they are sorted or merged
usually improves performance.
• Use either the OUTREC control statement or the OUTREC parameter of the OUTFIL
control statement to expand the data record, create new numeric fields, realign data
fields, convert and edit numeric data, and change from variable-length format to fixed length
format when creating one output file.
• Use the OUTREC control statement when creating multiple output files with
the same output record formatting.
• Use the OUTREC parameter of the OUTFIL control statement when creating
multiple output files with different output record formatting.
• Use the OUTREC control statement if a numeric field needs to be converted to printable
format so it can be displayed in an OUTFIL header.
There are other reasons to use outrec or Inrec but these cover the vast majority of reasons.
Another parm that can be used are is ELAP for large sorts. The options are Balance, Elap, I/O and CPU. The default if not specifically coded for is Balance. This tells syncsort to determine on it’s own which of the options to use. Most often syscsort will try to reduce cpu at the expense of Elapsed time. For small sorts this will be fine. For large sorts Elap should be coded as the overall elapsed time will be reduced. Since, sysnsort offloads most processing to the ziip processor cpu is not the biggest concern.
VSCORET is another parm this is often misused. This parm tells syncsort how much core to try an to retrieve. This can cause abends when not enough core is available. Never code VSCORET=MAX as this will most likely cause the sort or other processes to abend. |
|
Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007 Posts: 10873 Location: italy
|
|
|
|
Quote: |
This tells syncsort to determine on it’s own which of the options to use. |
if You are talking about SYNCSORT why did You post to the DFSORT section of the forum ??? |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
If you are going to quote chunks of a SyncSort manual at least give attribution, and don't post it in the DFSORT forum.
Note how it is best not to use OUTREC on OUTFIL at all, instead to use BUILD on OUTFIL (they are equivalent) and avoid the confusion. |
|
Back to top |
|
|
subdalal
New User
Joined: 27 Sep 2010 Posts: 21 Location: Boudh
|
|
|
|
Sorry Guys!! Enricho and Bill !! Could not locate the Synsort Forum.
Wil take care in Future.
And thanks for moving the same to Syncsort.
Thanks
Subhasis |
|
Back to top |
|
|
|