ICE185A S0C7 during DFSORT. Analyst swears the file is clean. Offset chasing in the sort is useless.
SORT fields include some PD/ZD. Could a wrong start position look exactly like bad data?
If DFSORT thinks a field is numeric and it is not, that is an S0C7. Period. Either the data is wrong or your position/length is wrong so you are reading the wrong bytes.
ICETOOL VERIFY is good for hunting bad ZD/PD. Also remember RDW offset on variable records - off-by-4 gets everyone once.
Split the file in half, run both halves. Narrows the bad record fast when VERIFY is not set up yet.
Position was wrong on a VB file (forgot RDW). Not the analyst's "fine" data after all. Good lesson.
You must be signed in to reply to this thread