We are having an issue with a true AFP file. It appears when the input file has multiple TLE's (used for indexing) with same name on the first page group the file fails to load. BUT if they occur AFTER the first page group, the file will load successfully..the 88 msg indicates,.
Here is a screen shot of input file showing where multiple TLE's exist for ACCOUNT. When this occurs at start of file, process fails with 88 msg of 2 fields submitted by the indexer, 5 expected.
DOC CNTL....NOOP: B0204000001200013247300000003.
REPORT ID....I203
BANK NUMBER....47086
ACCOUNT NUMBER....2000132473
ACCOUNT NUMBER....2000132465
DUPLICATE FLAG....Y
ADDR TYPE IND....D
PRINT FLAG....N
Please
see below detailed explanation of the issue from the AFP programmer.
They correctly failed the load when these multiple indexed page groups were the first page group in the AFP file but not when it occurred after the first page group; that is when the indexes were created with incorrect values.
1) It seems from what we observed that the problem we had with the loads is related to how the index rows appear to be created.
- The process respects the page groups and the correct pages are always indexed.
o Though the index values seem to be available across the page groups; i.e. the index values from a previous page group would be used in a subsequent page groups index row.
o It does not seem to clear out TLE's at the point is moves to a new page group
o Once it finds a duplicate TLE Name it tries to create a new index row; and with the report requiring a specific set of TLE's the duplicate ACCOUNT on the first page group in the load file the set of TLE's failed as it had not yet found all the required TLE's.
o When the duplicate ACCOUNT TLE's are encountered after the first account the index row is created with the last value from each of the other required TLE's; and as they are not cleared across a page group then it picked up the previous values of DUPLICATE FLAG and PRINT FLAG (we found specific case for both of these situations)
o Clearing the TLE's after each page group would have prevented the invalid index row's; though it would likely have also produced the failed test loads from the start of our testing..
o It seems as though the load and index process currently does not enforce the integrity if the TLE's to be from the same page group currently being processed
