Something that no one has even mentioned is why a migrated APF-list data set is considered an exception. It is for possible function-loss and system security/integrity reasons.
The "problem case" is when the system recalls a migrated data set. The questions to be concerned with are: If the data set was APF-authorized, will it still be? If the data set was not APF-authorized, will it still be? I believe that there are scenarios where the answer to both of the questions are "no". The first would likely result in a loss of functionality, the second is a security problem. Both are things that should concern customers. These cases are why HSM chooses in general not to allow you to migrate APF authorized data sets. And that is why having a migrated APF authorized data set is an exposure. And that is why the Healthcheck flags them. Could HSM allow you to migrate an SMS-managed data set with an APF entry that indicates "SMS" without security concerns? HSM doesn't, but could, because whichever volume gets used for the HRECALL would still result in the data set being APF-authorized. Unless there is a requirement to allow this migration, I don't see this changing. It has not appeared to be a problem for the many years that this functionality has been in place. Should HSM allow you to migrate an SMS-managed data set with an APF entry that indicates the specific volume where the data set currently lives? HSM does (when you have a dynamic APF list). It probably should not. I am checking to see if HSM will consider changing that behavior. Should HSM allow you to migrate a non-SMS-managed data set with an APF entry for the specific volume? HSM does not. And that is correct. Should HSM allow you to migrate a non-SMS managed data set with an APF entry for SMS? HSM does not (at least that's what a test shows). This makes some sense, We know that, in a multi-system environment with shared data sets, mismatched APF lists can let the data set be migrated from one system where it is not APF authorized. Given the "problem cases", the simple fact of mismatched APF lists is quite possibly a customer environmental problem. But I do not see the system attempting to solve that problem for you (as it is only a problem for data sets that are shared between the "mismatched systems" and that could be cumbersome to detect). Seeing a migrated APF-authorized data set can be a clue that you have such a situation, and can be a clue that you might have a problem. One thing to add: When a data set is migrated, you cannot readily (if at all) determine if it is SMS-managed or not. Thus, any behavioral differences that you might want a check to have between SMS-managed and not-SMS-managed are not feasible. They would require the data set to be recalled just to tell what needs to be done, and we would not want the check to recall your data sets (even if it could be done quickly, which it probably cannot be). So given this, do you still want an option that says "do not flag this as an exception"? If that is what customers want, then I don't mind, but it should be based on sound, complete reasoning. Peter Relson z/OS Core Technology Design ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
