II JV Feed
Overview:
The inter institutional jv feed is the most complex one we run. JVs get input into owag via 2 methods: a form FWAIITD which institutions bring up in owag and spreadsheets from all the institutions and telecom. Telecom, UO, and CO use the spreadsheets and the others use the form. The spreadsheets can get up to 3100 lines of data. Text that can go with a JV comes from the form FOATEXT in owag. The JV doc codes are typically VA######. In the chps flat directory you will see files with J00xxxxxx which are not part of the iitfeed process. These are related to chpsfeed which uses the same directory. 90% of issues with the ii jv feed come from the spreadsheets. Anyway, there are 3 owag oracle scheduler jobs that run around 5 am. Two are related to some pre and post feed reports. The other, IITPROC_DAILY_JOB, runs the feeds. The data from the form and spreadsheets get loaded into some custom tables in owag (fwbiitd, fwbiith, fwbfedh). Then a process runs which splits them into several files for each institution and places them in the institution’s appropriate flat directory. From there we handle feeding these files that came from the owag split into the 5th site databases. The big 3 handle feeding these files into their databases themselves. UO feeds theirs at 8 am, OSU at 3 pm, and PSU at 6 pm. What you typically have is JVs moving from the schools to controller’s and jv’s from controller’s running to the schools(including chps). The telecom stuff runs out to all the schools once a month. There is a cutoff date set by Nick Miller a few days before period end which will not allow the II JVs to process if they are in the period but after the cutoff date. This is in ftvsdax. At year end there is also a setting to only allow controllers to send ii jvs.
Scripts in owag subversion:
iitproc.shl – main one
iitchps.shl
iiteou.shl
iitoit.shl
iitsou.shl
iitwou.shl
Generated files in institution flat directories:
Ie. /san/flat/wou/wouprd/fin/iitfeed/
fwbfdhe.dat
fwbtxte.dat
fwpfdhe1.lis
fwpfdhe2.lis
fwpfdhe4.lis
Issues:
Controller’s calls and can’t remember if they already uploaded a spreadsheet:
– Go to /san/flat/ecs/chps/fin/iitfeed and look for it there and the arch directory.
Controller’s calls and ask if a certain VA####### loaded:
– See if they ever uploaded the file if it’s from a spreadsheet. Do a grep for it in /san/flat/ecs/chps/fin/iitfeed/ and in the arch directory
– Check the history table in owag, fwbfedh, for it. You can get the date it loaded and whether or not it was placed in the institution files by the fwbfedh_transmitted_ind flag.
Controller’s calls and ask you to help them figure out why a JV didn’t load:
– First see if it loaded. Keep in mind the same JV can go to multiple institutions. If it was in a spreadsheet, make sure the file was there
– If the file was there but you have no record in fwbfedh, go to the owag spool directory and do a ll *iit* and look through the files to see if you can find anything. Also check fwpiitd.lis which will tell you what loaded into fwbfedh that morning and fwpfedh.lis which will tell yo what document went where that morning
– Go to TreasOps/IITFEED folder in restricted share and look for fwpfeeed_error.lis file. It will show any issues with loading the file into owag.
– If it loaded and you see the flag on fwbfedh_transmitted_ind set to Y, go to the flat directory of an institution (say chps) and look for the furfeed and fgrtrnr files. Ask controller’s if the JV ended up in suspense.
– The spreadsheet consist of a type 1 header record and then 1 to many type 2 detail records for each JV. A lot of times the total of the detail records doesn’t equal the total on the header record. They sometimes forget a header record. The sqlldr is position driven so sometimes they mess up a column width. They may have tried to feed it before and forgot they did. Sometimes they put in a blank line at the end of the file.
Controller’s calls and says they want to re-feed a file:
– If it posted, you can’t re-feed the records that posted. If it’s in suspense, controller’s has to remove it from all the banner instances that it went to before you re-feed.
– Check the tables fwbiitd, fwbiith, and fwbfedh and remove records for the JV.
– You want the morning job to take care of it and not run manually unless you have to.
Controller’s or UO calls you and says the feed bombed:
– Review the iitproc log in the owag spool directory and figure out where it bombed.
– Ask controller’s to send out an email to the campus business officers informing them that the ii jv load failed that morning. OSU does their institution load at 3 pm but the other two bigs do it in the morning so chances are they tried to load files from the previous day and had their process abort.
– Chances are a spreadsheet caused a sqlld to abort
– Remove file and run job manually on owag oracle scheduler unless controller’s wants to try and fix the file first
– Ask controller’s to inform campuses when you’ve run it.
