Recently, I had the opportunity  to talk to Patrick at Adager.  I mentionned to him that our system was I/O bottleneck primarily because we updated credit cards randomly for a given tape supplier, one supplier at a time e.g GMAC.  He explained that when updating through an image key access, each trade line retrieval  from the database was picked up from a 4096 byte page access.  Also each trade line update was 1 io.  Since the access was random for a particular client supplier, say GMAC, then the system frequently had to dump what was in memory and read back from disk for the next update.

Since I was updating a series of credit cards from one tape supplier from a flat file, then if a could preload all the GMAC accounts into memory, then very few access would be made to disk.


He suggested that I create a B-tree out of the 26 character byte key (TRADE-KEY i.e. 10 char member code + 16 char account #)  I usually use for update.  Then do some kind of CHOOSE TRADE-KEY "GMAC@" when GMAC is say member code =1234567890 so CHOOSE TRADE-KEY "1234567890@"  and the account-nmbr is say 450...........  All GMAC records from the database would fit into memory.  Then all that is left to do is my usual key access for updating.

I'm sure some of you must have encountered this kind of io bottleneck because of random updates.  Have you solved the problem by preloading the account # into memory using B-tree access then updating them.?


Jean Huot
Northern Credit Bureaus Inc.