Decimal data error in production in AS400
Hi,
I am working on production server and we are getting a decimal data error for a batch job. How can i find the record which as got the problem amd how can i rectify the same with out ending the job?
Thanks in advance for the help.
Software/Hardware used:
AS400, RPGLe
I am working on production server and we are getting a decimal data error for a batch job. How can i find the record which as got the problem amd how can i rectify the same with out ending the job?
Thanks in advance for the help.
Software/Hardware used:
AS400, RPGLe
ASKED:
December 25, 2009 7:38 PM
UPDATED:
January 1, 2010 3:20 AM
Answer Wiki:
AFAIK, you might only "rectify" the situation through debug -- service the job, alter the value(s) in memory and continue. That assumes the job is stopped at an instruction and waiting on a response. And that the programming can be successfully debugged.
Keep in mind that if one record has a decimal data error, then other records can easily have the same kind of problem. You might need to correct any number of them before the job finishes. Also be careful which values you change in memory -- that you change the right ones and that you appropriately change all related ones.
IMO, your better choice is to let the job fail, correct all decimal data errors and run a recovery. Then run the job again.
Tom
.
To see all answers submitted to the Answer Wiki: View Answer History.
You can do a DSPJOB on the job in error, take option 14 to “Display Open Files,” the press cmd 11 to “Display I/O Details”. This will show you the current releative record number each file is positioned to. Chances are, your bad data is in one of those records. I have had to do this when running programs with no ability to debug or get a dump and no source for the programs.
To address the question ‘How can i find the record which as got the problem’ I would suggest that you find a record counter in your program (assuming your program counts records) or check the number of records in your output (assuming you have some number of output records for each input, or take a look at what was recently written to a report (assuming you have a report).
If you don’t have a *PSSR in the program that generates a dump, respond with a D (formatted dump) to the error message. The ensuing report will have everything you need to identify the offending data.
Note the responding D to an error message might or might not dump anything useful. If debug info isn’t compiled in, then little will come out. I can’t quite think of a good reason not to have debug included nowadays in in-house programs, but I’ve seen it done.
Tom