Unless the client is terminating and restarting in between (in which case this is not surprising), I would guess that either your server is setting up an alet for a different client that overlays the original (some sort of multithreading bug) or VSE has a bug. I don't know what sorts of facilities VSE provides for establishing ALETs, so I couldn't guess which is more probable. Do you know how the contents of the alet change? Do all the fields change or just the ALESN?
Gary Weinhold Data Kinetics, Ltd On 9/20/2010 9:47 AM, Tony Thigpen wrote:
First off, I work in the VSE area, not z/OS, so things may be a little different, but should be close to the same. But, I don't think asking this on the VSE list will yield an answer. Over the years of using cross-address space moves, we have seen things that we don't understand that we would like to better understand. We have client/server applications running in different address spaces that use access register moves to transfer the data. What we have learned over time is that the access register value needed for the moves can change during the process. We would like to know why. Here is the simple flow: Job Server is waiting for work Job Client posts job Server telling the server the address and length of the data. Job Server wakes up, acquires the ALET of the client and copies the data to his address space Job Server then processes the data Job Server then writes data back into a buffer area set up by the client in the client address space Job Server posts the client and goes back to sleep Job Client wakes up and processes the data. The above process works almost all the time, but sometimes, while the Server is processing the data, the ALET for the client partition changes. This causes the reply write back to fail. In other words, some time between the time the Server moves the data to his address space and the time he attempts to move data back to the client, the value that we need to stuff into the Access Register changes. We know we can just reacquire the ALET before we write the data back even if it is an CPU expensive action. We just want to better understand why the value may change. Any ideas? -- Tony Thigpen
