A decimal data error means that you have character data in a numeric field. A program dump will give you the current value of the fields in the program. Use that to find the record in error and fix it.
You might not be able to “recover” — it very much depends on how your program is coded. And at best, the record that is causing the problem probably will not be processed correctly.
Further, there is an excellent chance that many more records will show the same kind of problem. You are likely to get this error many more times before the job finishes. A couple million records with just a single “decimal data” error seems unlikely to me. I would expect that something like “blanks for zeros” or a similar field format method may be applied throughout the file.
I’d expect only two reasonable alternatives.
First, a reply of ‘D’ for ‘Dump’ will end the process but may dump information that lets you review what the cause was. You might then locate and fix any records that had the decimal-data problem(s) and perhaps restart the process from where it left off or run the whole thing over.
Second (a long-shot), ‘G’ for start the Cycle at ‘*GETIN’ <i>might</i> get you past this record and on to the next record. Depending on whether or not this is a Cycle program that is coded to respond well, if you’re lucky enough that this is the only bad input record (or there are only a couple bad ones), maybe this would get you through the vast majority of records. Only bad ones might be left out. You’d still need to locate and figure out what the problem was for each of the bad records. Then you’d need to run those records through after they were corrected.
If the program that is failing is yours, it needs to be changed to handle this kind of error. If it’s not your program, then the supplier should fix it and you should separately fix the input file.