With Local Buffer Pools (that's what we have at LA Times), cataloging modules in BATCH does not replace modules in the local on-line buffer pool (at least not under CICS and COM-PLETE). This is normal - although rather annoying. In order to refresh the on-line NATURAL Buffer Pool, you need to use SYSBPM on-line to release each module or all modules.
Some shops do migrations by batch in the evening and then re-cycle the TP monitor CICS or COM-PLETE. When the TP monitor comes up, it starts with a clean NATURAL Buffer Pool. During the day, the DBA's are responsible for refreshing the NATURAL Buffer Pool on all modules that were migrated. The problem with the "during the day" approach is that some users may get program version errors.
However, if you don't flush the NATURAL Buffer Pool on-line, the buffer may refresh some of the modules itself. And this could cause problems if there were several related modules and only some of them were refreshed.
The Global Buffer Pool (that's what we would like to have) is a segment of storage assigned from the MVS common system area (CSA or ECSA) above 16 MB (or below, if requested), used by NATURAL to load and execute NATURAL programs. This needs more memory, what we don't have today (11/99).
Via a global buffer pool, multiple NATURALs under different TP monitors (multiple copies of COM-PLETE, CICS, TSO, etc.) and batch share the same area - thus requiring less storage than would be required for a local buffer pool in each environment.
With the Global Buffer Pool, cataloging modules in BATCH can replace modules in the Global Buffer Pool. NAT-PAD supports this possibility.