PMR54458 - ever increasing % tep addresses -- MIDRANGE-L

All,

I would like to share the following experience we are having with IBM:

Recently, at a client site I have noticed that the '%temp addresses' does not get cleared after an IPL. We reported the problem to IBM and below is their official reply. In summary they are saying we won't do anything to the way the system is designed, you change the way your application works.

Well the application in question is irrelevant. What is pushing the % temp space used is Journalling and Mirroring product. This is the way mirroring works on the iSeries. You journal something to a receiver, mirroring sw reads it sends it applies it, how else? IBM is pushing clustring and solutions based around it but they are refusing to address a fundemental design limitation / defect.

******** IBM's Response ************** "There are a finite number of virtual addresses available for use by temporary objects. These addresses do not get reused. So, as they are used, the % temp address field on WRKSYSSTS keeps track of how many have been used. If that number reaches 100%, the system will crash and a scratch install will be required to recover.

Programs that use heap space can use an address for each 16MB of heap in the same thread. Each thread and/or activation group will use a new address. Query can use temp addresses for internal processing of joins and sorts. Some API calls can create temporary space which would use one or more temp address. To determine the the specific objects being created and the jobs and specific programs doing it would need to be investigated under a Consult Line contract.

Obviously, the system is creating and deleting MANY temp spaces and most likely it could be corrected by changing an application (or maybe more than one). For example, let's say they have lot of remote devices that connect for a short time to transfer data many times through the day. Let's suppose each time they dial in, a job is started up and creates a temporary space for the data to be held in before being processed and then the job ends. Perhaps this could be improved by having the just one server job per device that does not end, but waits for the device to reconnect and re-uses it temporary space each time instead of creating a new one for each connection.

Action Plan:

Further Rochester involvement would require a Consult Line contact to determine what is actually using the temp addresses to make a proper recommendation for this customer. " ******** IBM's Response Ends *********

OK, I admit, the rate we are using the % temp addressis is around 0.5%/month and before anything serious can occur, we are likely to upgrade the OS (which I hope will initialise the % temp address), but I can see some scenarios where this rate of growth can be higher.

Omer Ozen.