Buffer Pool

, ,
1

When we implement modules from our development environment to our test environment we use a home grown application.

This uses SYSMAIN to copy the source from one library to the other, then catalogs the source in the target library.

It appears that when we implement a map and a program, that the map is not removed from the buffer pool when it is catalogued.

Therefore, if for example fields have been added to the map, the result is a Nat 936, if the program is executed.

This can be cleared by stowing both modules or deleting the map from the buffer pool.

Is this a know problem?

We are wondering if we need to include a delete of the module from the buffer pool as a step in our implementation.

2

Hi Stephen,

Are you running with two different buffer pools? SYSMAIN/catalog process runs with another buffer pool than the process that executes your application?

3

Does the migration application ensure that the map is cataloged first? Otherwise, the program will still contain the old parameter list.

4

It is the same buffer pool.

The map is catalogued first.

I have also had a text module remain in the buffer pool. Used for JCL in on-line submission.

Is this a bug with AIX?

5

Hi Stephen,

I think something in your environment is not as you believe. Natural text objects are not loaded in the buffer pool.

6

Hi Stephen;

Just to recap, and clarify in my own mind, what you have said.

Step 1) SYSMAIN MAP-1 and PROG-1 to new library; STOW map, then program

Step 2) Modify MAP-1 to create MAP-2; SAVE and CAT MAP-2

Step 3) Modify PROG-1 to create PROG-2; SAVE and CAT PROG-2

Step 4) Test by “executing” (your word) PROG-2

You said that if you STOW MAP-2 and PROG-2 everything works fine.

Question. In steps 2) and 3) did you SAVE and CAT both the MAP and the program? If, for example, you only SAVE’d the program; then tried to test by “executing” (again, your word) PROG-2, you would get the 936. Then, if you STOW’ed (SAVE and CAT) PROG-2, it would work just fine.

Try doing a LIST DIR of the program and the Map. See if the process you followed indeed results in both the program and the Map showing up as -2, rather than -1 (the dates and times should tell you this).

steve

7

Hi Stephen;

Just to recap, and clarify in my own mind, what you have said.

Step 1) SYSMAIN MAP-1 and PROG-1 to new library; STOW map, then program

Step 2) Modify MAP-1 to create MAP-2; SAVE and CAT MAP-2

Step 3) Modify PROG-1 to create PROG-2; SAVE and CAT PROG-2

Step 4) Test by “executing” (your word) PROG-2

You said that if you STOW MAP-2 and PROG-2 everything works fine.

Question. In steps 2) and 3) did you SAVE and CAT both the MAP and the program? If, for example, you only SAVE’d the program; then tried to test by “executing” (again, your word) PROG-2, you would get the 936. Then, if you STOW’ed (SAVE and CAT) PROG-2, it would work just fine.

Try doing a LIST DIR of the program and the Map. See if the process you followed indeed results in both the program and the Map showing up as -2, rather than -1 (the dates and times should tell you this).

steve

8

Case 1. The map and program.

Step 1.

Map source copied from first library to second library using SYSMAIN.

Program source copied from first library to second library using SYSMAIN.

Step 2.

Map catalogued in second library.

Program catalogued in second library.

Step 3.

Invoke program. Fails with a Nat 936.

Step 4.

Delete map from buffer pool, using NATBPMON.

Step 5.

Invoke program. Displays map.

Step 4, can be a stow of the map and program as well.

Either way until step 4 is done, the program is not invoking the correct copy of the map.

Case 2.
A text module which contains JCL that is used by NATRJE.

Step 1.

Copy the text module from first library to second library.

Step 2.
Submit the JCL using NATRJE.

The JCL as executed is the previous version.

Step 3.
Delete text module from buffer pool using NATBPMON.

Step 4.
Submit the JCL using NATRJE.

The JCL executed is the correct version.

Is this due to the way SAG setup our buffer pool, or is it a bug?

Should we delete the appropriate entries from the buffer pool as part of out automated transfer process?

So far, only cases 1 and 2 appear to give us any problems.

9

If you’re describing your migration procedure to the production environment, then you should probably add the purge of the BP to it.

For development environments, consider setting BPSFI=OFF (Buffer Pool Search First Indicator).

10

Thanks, we will include a step to delete the appropriate entries from the buffer pool.