AS/400: Why would DB2 table changes not immediately take effect throughout entire system?

Question

I've got an issue where I updated a table in our AS/400 - db2 on the backend but the changes are not reflected through the front end.

We have a table called "SH.PROM" which is to specify our monthly promotions' date ranges. I have updated "SH.PROM" with the proper packed & zoned decimals and EBCDIC characters. However, when other people try to enter in the item #s of discounted items, the discounts aren't showing on the front end.

Is there a command to invoke a system wide update so that changes take effect immediately?

Answer 1

Let's assume that you are updating the table with an RPG program. Let's further assume that the RPG program declares SH.PROM as an update primary file without keys. In this case, RPG (for the sake of efficiency) will buffer the database operations, storing the updated rows in an internal buffer until the program ends and the buffer is flushed to disk. If this is the case, there will be a message at the bottom of the RPG compiler listing to the effect that blocking is being used. Under this circumstance, it is possible that a table can be updated by one program but the updated row is not yet known to the database.

There is a slightly different scenario if you are operating under commitment control, but if we assume that a row is locked for update and not yet COMMITted then other jobs will hold on that lock. Instead of seeing the old data, they won't be able to read the uncommitted change at all and will instead eventually get a record wait timeout.

There is another scenario where you have a logical file built over SH.PROM which is MAINT(*REBLD). You update SH.PROM; the end users read through SH.PROML1 and it takes some time to rebuild the index before they can see the records.

Aside from that, there really isn't a way to delay or defer database updates. Generally speaking, if you update a row, it's immediately available. None of the above scenarios seem to reflect what you are reporting. Check to make sure that you are updating the same table that the users are accessing. It is possible that you are updating TESTLIB/SH.PROM and the users are reading PRODLIB/SH.PROM. Or, there might be some nightly process which propagates SH.PROM into other tables, and it is these tables which the end users access.

The bit about 'proper packed & zoned decimals and EBCDIC characters' is confusing. How are you updating SH.PROM? JDBC? RPG? SQL statement run via IBM i Navigator? Why is it interesting to note 'proper packed & zoned decimals'? Is it because SH.PROM is a flat file (no actual columns defined) and you've had to emulate packed decimal fields via use of SQL built in functions?