Some might question allowing APF libraries to migrate? > -----Original Message----- > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On > Behalf Of Mike Schwab > Sent: Wednesday, August 17, 2022 12:49 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Problems caused by Health Checker? > > [EXTERNAL EMAIL] > > So the proper response is to enable recalls if possible, wait to enable > recalls if recalls will become available, or cancel and leave down until > recalls can be enabled. Correct? > > On Wed, Aug 17, 2022, 10:36 Peter Relson <rel...@us.ibm.com> wrote: > > > <snip> > > One problem we've seen is that sometimes when HZSPROC starts during > an > > IPL, it for some reason seems to try to access a migrated dataset (we use > > FDRABR for dataset migration) and since DFRMM hasn't started yet the > recall > > fails. (We don't know what dataset it is trying to access; none of the > > datasets explicitly in the PROC ever migrate.) Everything seems to freeze > > until we reply "CANCEL" to the EDG4012D message. > > </snip> > > > > If a particular health check does an allocation/open that results in > > attempting to recall a migrated data set and results in a WTOR, that > > particular task would wait for response, but that would have no effect on > > the running of other checks (HC has 20 tasks available for running of > > checks; only the single task running the check would be held up). The > > RACF_SENSITIVE_RESOURCES check does check on the existence of > > APF-authorized data sets. So perhaps doing that checking does result in > > recalling the dataset in order to do that validation. I don't know if the > > recall (versus do not recall) is intentional or an oversight; I will be > > asking that question of the owners. > > > > In any case, there would be no effect on the rest of the HZSPROC address > > space or the rest of the system. > > > > 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 > > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
