Every once in a while SOU’s bookstore feed fails and I’ve decided to share the process of how I figure out what happened with some of the folks at SOU. First thing is to find the job submission log in the spool directory. It can give you some information approximately where the job failed. The shell script writes most of it’s output in the folder invfeed on SOU’s flat directory on js1. Unfortunately the first thing an end user typically does when they get a failure message in Banner is try to run the script again. This overwrites or removes most of the files that will tell you what happened. So I check to see if any data made it to the temp tables and remove it if there. Then I move the archived data file back to the main directory, rename it properly, and have the user run again stopping after it aborts.
In a nut shell, the script reads the datafile (*bookinve.dat) and breaks it into 3 datafiles each of which gets sql loaded into a separate temp table (fwbinvh,fwrinvc,fwrinva). Each of these loads has a log file with it. 95% of the time you can find the problem in one of these logs. The job submission log will point you in this direction. In the last failure, I saw output from the first load but nothing from the 2nd or 3rd. So when I checked the 1st sql load log I found that a date column was erroring out. The datafile had a date column in the wrong format.
If the 3 loads were successful, fwrinvf runs. You should see a SOU_fwrierr.lis output from it in the invfeed folder. Look for any errors in there. After that, fgrtrni runs to mark the transactions postable. The output file is normally empty. If you see something in it that means you have an error. If you have an error here all the feeds will be screwed up till we get it fixed. Normally I have to delete the records in the fgbtrni table causing the error. Fgrtrnr runs to see if any of the posting ended up in suspense and then an email goes out with the SOU_fwrierr.lis in the body of the email.
