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
