Make a backup copy of the audit file BEFORE you run this process. You may ruin your audit data if made incorrectly.
Even in the most stable systems, from time to time you change a table design. As FullRecord stores the full record in the audit file, and relies in the current record definition for inspecting its fields, its important to change the stored record to keep it current with the actual definition. Otherwise, the old audit data may become inaccesible (you will see garbled or wrong data).
There is one special case; if you just add a field (or more) to the end of the record structure, you don't need to touch the audit file.
However, if you change a record, normally you shall update the stored record in the audit file.
There are many ways of doing this, I prefer one of them as it involves several operational advantages.
First, you need to keep a separate dictionary with a copy of the audit files definitions, and each time you change a record you stores a copy of the old record definition and a copy of the current record definition in that dictionary. I suggest you to append a "date" suffix to each definition (like People_051230 to identify the copy valid until 30th of December of 2005), and number each prefix sequentialy (like Peo1, Peo2, etc.).
Note that if you change the same file several times, the "current" record for the last time becomes the "old" record for the next one.
You might do this in the "work" dictionary, but as you keep adding definitions each time you change a record definition, you fill the dictionary with clutter and I strongly recommend to use a separate dictionary for that matter. Doing this in the working DCT may lead to problems like the "too many segdef" error.
You just make a "process" template on the audit file to change (you might need to make a process for the current audit file and a copy of it for the auditbck historic file).
In the following example, I assume the same files and field names that I shipped in the example. Change them accordingly to your own.
You need to add the JALExtUpdateStoredRecord extension template, as follows:
And you need to fill the prompts for the extension template as shown below:
"Old File" is the previous file definition, currently stored in the audit file.
"New File" is the current file definition.
In "Search for file" you have to name the file which record changed, as it is named in the Audit file. This entry will generate a filter embed in the "Validate Record" section, before parent call, priority 2500. This entry is case sensitive.
If you don't mark the "INSTRING" checkbox, a line like this will be generated:
IF AUD:DEFILE <> 'people' THEN ReturnValue = Record:Filtered; RETURN ReturnValue.
If you do mark the "INSTRING" checkbox, a line like this will be generated:
IF INSTRING('people',AUD:DEFILE,1,1) = 0 THEN ReturnValue = Record:Filtered; RETURN ReturnValue.
The latest allows you to select those records in the Audit file that include the word you typed in the "Search for file" entry.
That is all. PLEASE, make a backup copy of the audit file BEFORE you run this process. The process will check the buffers to verify if the procedure run before, therefore it won't ruin the stored record if you run it more than once, but if you type the wrong file in the "Search for file" entry field, you may be altering other file definition than the correct one. It's a good idea to inspect one old entry for the file in the audit file, before and after running the process, to check that all went ok.
You don't need to make the conversion right away after the audit file layout is changed, however, while you don't change the stored record layout, the data provided by the audit file (up to that moment) could be incomplete or unreadable. Nevertheless, the new stored data will be ok.