The most likely causes would be 1. The TRANSWAP did not actually happen 2. After the TRANSWAP, something did a SYSEVENT OKSWAP
I would start with an SVC dump of the 0D5 abend, and use VERBX SRMDATA to see whether SRM thinks the address space is non-swappable. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY > We're experiencing an abend S0D5 that occurs at only one site. We > have an authorized program that issues a DSPSERV CREATE SCOPE=ALL to > establish a dataspace. It initializes several of the blocks in the > dataspace but does not touch the rest of the blocks. It then issues > SYSEVENT TRANSWAP and WAITs for the ECB to be posted (unless it was > already non-swappable). Then it publishes the availability of the > dataspace in CSA and WAITs for a MVS STOP command. > > Later we run a problem state program that invokes a proprietary PC > to acquire the dataspace ALET (ALESERV) and then accesses the > dataspace blocks. It runs fine until it tries to access a block > that was not referenced by the dataspace creating program. It then > abends S0D5. > > Are there conditions under which a non-swappable address space can > become logically swapped out? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
