Peter My main objective of my posts were in regard to modifying file 192 general recovery.
One of my modifications in the case where sdwaec1 and sdwaec2 have different next address it is apparent that sdwaec1 ( PSW at time of error ) is not in the users code but likely in a SVC or PC rtn ( this is just general I’m sure there are exceptions ) It would then become more important to have the user program registers which are linked to sdwaec2 If for instance the user was running amode 64 I don’t think SDWASRSV has 64 bit area but if I have the correlating RB I can get the 64 bit regs from XSB Your post have definitely help me get the information I needed and for that I’m grateful Thanks and I apologize if sone of my posts made it seem like I wasn’t listening to what you were telling me > On Feb 26, 2024, at 6:18 PM, Peter Relson <[email protected]> wrote: > > Since it is apparent that Mr. Reichman does not respect the time of the > followers of IBM-Main, I choose not to continue rewarding bad behavior. > This will be my last response to any post he makes that demonstrates that > lack of respect, whether he has not seemed to pay attention to a post upon > which his post is based or has not provided sufficient information either > upon initial post of a thread or (especially) when asked for such information > by a responder. I'm trying to leave the door open for a change to what we > might call good behavior. > > Regarding SDWAEC1 (you should instead be using SDWAPSW16 to handle any RMODE > 64 cases that might surface for the time of error PSW) > > * If the address is in common storage, you could use CSVQUERY with > SEARCH=LPA and, if that does not succeed and the address is below 2G, use > NUCLKUP. > * If the error occurred in your current-primary address space, you could > use CSVQUERY with SEARCH=JPA with INADDR64=YES and maybe ANCESTORJPQ=YES and > maybe DIRLOAD=YES. (if the error address is in private, and you are not > running with the failing address space as your current primary, it would be > wrong to try to search the current-primary address space for a given address) > If you want to handle modules loaded with GLOBAL=YES, then tweak the above > also to search JPA (with or without LPA) in the case of common storage. Most > would not bother. LOAD with GLOBAL=YES is possible to get right, but in > almost all cases is not gotten right and results in a system integrity > exposure. Thus it is discouraged, with dynamic LPA and load with ADDR/ADDR64 > being the alternatives (most diagnosticians would prefer that you use dynamic > LPA in order to more easily learn what module name is associated with a given > address). > > Some day nucleus storage above 2G might be supported. If that happens there > would be something akin to NUCLKUP that accommodates an 8-byte input/output > address. > > I think that SDWAPRIM would be a good indicator of where the error occurred, > by ASID. There could be some tricky cases if the PSW indicated Home ASC mode. > In practice, all home ASC code is in common storage (it theoretically need > not be). If you have a private-area address and the PSW is in home ASC mode, > then it's the home address space that needs to be searched. The address > space that is available to you to search depends on the type of recovery (and > options) that you are using. SDWAFMID is set in only a few circumstances, it > seems (such as DAT error), so you won't find that helpful generally. > > Note that none of this discussion mentioned (or had a reason to mention) an > RB/XSB pair. > > Peter Relson > z/OS Core Technology Design > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
