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.
