M.Savino
04-21-2004, 05:37 AM
With Sar-Box compliance on everybody's mind there's probably a good chance you'll need to do some File Auditing. If you're working on your own application and plan on using Journals to accomplish this, just though I'd share a few things we've run into. I think I've mentioned this before but it's worth repeating; None of the 5 *OUTFILE Formats of the DSPJRN Command include a field that specifies a File Format. So, you upgrade your packaged software and they change some of the Physical File layouts. The post-upgrade Entry Specific Data for these files will be different from the pre-upgrade Data..... That's important to know when you start doing Reporting but unfortunately there's nothing in the Outfile to tell you that. So you'll need to keep track of that on a File by File basis, probably using a date range. The other little "gotcha" has to do with the Date of Entry Format. In the Outfile Formats with the least overhead, the Type One and Two outfiles, this is the Job Date Format. At our shop, this is usually in MMDDYY Format. Makes it a little tough to Sort/Select on... but the Outfile itself wasn't intended to be a permanent repository for this information. So a conversion to a more "Developer" freindly Date Format at the time the Data is moved to it's permanent home would take care of the problem. Assuming we know the Date Format of the Job that created the Journal Entry. Which unfortunately, is nowhere to be found in the Type 1 and 2 Outfiles. So if you're at a shop where Jobs are run with various Date Formats, you're outta luck. Luckily the Type 3 Outfile uses a TimeStamp Field for the Date/Time of Entry which is always in *ISO Format. This Format adds about a hundred Bytes to the Record Length (compared to Type 1) but it's the Leanest of the Outfile Types with a dependable Entry Date Format. BTW: We considered using the Journal API's to do this but decided on the DSPJRN Command instead. DSPJRN gives us everything we need and performance is very good.... At least on a machine our size (825, Nitro burning, 12 squirrel processor I think). The API's seemed a little cryptic (even more so than most api's). So unless you're doing something really tricky, I'm not sure if there's much advantage to using them.