It should be apparent that if you're using a 4-byte address from an 8-byte PSW, you cannot possibly handle information from an extent list that might have addresses above 2G.
16-byte PSW with its 8-byte address (and similarly GR high halves) is provided only for time of error. That's not either SDWAEC1/SDWAEC2 of course. If using 8-byte PSW, XTL64 is not needed, the "normal" extent list will do. Further, I don't recall how you are actually thinking to locate the XTL64. If you're using CSVQUERY (such as based on the address that you seem to be interested in), I can say only that that is a bad thing to do in a "general recovery routine" for all the reasons I laid out long ago to one of your earlier posts, including making sure that your recovery routine actually gets the opportunity to do the things that recovery routines must do (and not get short-circuited by calling an unnecessary routine that (just because of the nature of things) might unexpectedly fail). You might survive if you have established nested recovery to catch such a failure (which would surely be the minimum you have to do). But if you do provide CSVQUERY with an address and it finds it (based on such things as your search criteria - JPALPA or just JPA, for example), then you have a change to get an XTL64. Peter Relson z/OS Core Technology Design ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
