it will sort the records in the proper sequence on both fields
only for the AF records it will leave them alone, but in the proper place relative to the others
********************************* TOP OF DATA **********************************
AB7
AB9
AF9
AF5
AF2
AF5
XB7
XB9
YA8
ZQ8
******************************** BOTTOM OF DATA ********************************
just a proof of concept, modify the fields positions according to Your needs
Joined: 27 Oct 2009 Posts: 2481 Location: Netherlands, Amstelveen
Quote:
You just started a religion war
I hope i didnt, its just what i think. Bill Woodger is a Cobol zealot, so i understand he loves to use SYMNAMES to define Cobol like names. Well
whoever wants to use it, thats ok with me.
Joined: 15 Feb 2005 Posts: 7129 Location: San Jose, CA
Quote:
SORT FIELDS=(FLD1,A,FLD2,A)
tells me nothing about field characteristics, now i have to browse another
dataset for the SYMNAMES definition. A waste of time.
It's NOT a waste of time when you consider that DFSORT Symbols allows you to stop worrying about the field characteristics. You just set the symbols up once in your SYMNAMES data set and forget about them until you need to change something. Then you go back to your SYMNAMES definition file and change it appropriately. As an example (if you use * for the fields), this makes it very easy to insert a new field between two existing fields without having to change all of the positions in your control statements.
If you want to know the field characteristics for some reason, you can look at the SYMNAMES definition data set, or run the job and look at SYMNOUT or the transformed statements in //SYSOUT.
Having a separate data set for the SYMNAMES definitions is very similar to what you do for most high level languages such as C, COBOL, etc. Are you suggesting that symbols SHOULD NOT be used for those languages either? I don't really see the difference between using Symbols for DFSORT and using Symbols for HLLs (which almost everyone would agree is a better way to go).
Joined: 06 Jul 2010 Posts: 765 Location: Whitby, ON, Canada
When a file layout changes, you usually have to chase down every sort control card used to process that file and make sure that you make the necessary adjustments to the hard-coded field positions. I have seen production jobs crash and burn because someone forgot to update a sort card. It's usually not the sort step that abends, but rather a downstream step that is now seeing the data in an unexpected sequence.
