Re: Healthcheck (IBMCSV,CSV_APF_EXISTS)
I'll try again with the possible security / function-loss scenarios. Let us assert that HSM can recall a migrated non-SMS-managed data set back to a different volume than when it was migrated (I think this is true, but not being an HSM expert, cannot swear to it). We know that HSM can recall a migrated SMS-managed data set back to a different volume. We know that mismatched APF lists can let a shared data set be migrated on the system where the data set is not in the APF list. The question, then, is: Is there a possible problem that the system where the data set is in the APF list could encounter upon recall. There are 4 cases (well, 6, counting my 1A and 3A below) 1.Non-SMS-managed data set, APF entry is for the specific volume 1A.Non-SMS-managed data set, APF entry is for some other volume 2.Non-SMS-managed data set, APF entry is for SMS 3.SMS-managed data set, APF entry is for the specific volume 3A.SMS-managed data set, APF entry is for some other volume 4.SMS-managed data set, APF entry is for SMS Case 1: If the data set is recalled to a different volume, it is not APF authorized on this system. Function Loss Case 1A: If the data set is recalled to this volume, it becomes APF authorized on this system when it apparently wasn't supposed to be. Security problem. Case 2: Wherever the data set is recalled, it is not APF authorized. That is more or less OK. But there is a spurious APF entry that could inadvertently authorize something in the future. That is not good. Case 3: If the data set is recalled to a different volume, it is not APF authorized on this system. Function Loss Case 3A: If the data set is recalled to this volume, it becomes APF authorized on this system when it apparently wasn't supposed to be. Security problem. Case 4: No problem Some of these cases are detected and flagged by health checker when the data set is not migrated. No one appears to be contesting those cases (such as APF list entry is for a specific volume but data set is not on the volume). And even for a migrated data set (SMS-managed or not), when the APF list entry is for a specific volume, this will show up as data set is not on the volume. Thus I believe migrated is indicated currently only when: The APF list entry is for SMS and the data set is migrated (whether it is SMS-managed or not) Those are cases 2 and 4. Current processing cannot tell if the data set is SMS-managed or not when the data set is migrated. Thus current processing cannot differentiate between cases 2 (problem to report on) and 4 (not really a problem, just perhaps something of interest) Hypothesizing that we could differentiate these two cases, would you want us to -- never flag migrated as an exception -- flag migrated as an exception only for case 2 -- flag both cases as exceptions -- have a 2-way parameter that lets you say both or never -- have a 3-way parameter that lets you say both, only case 2, or never If we agree that case 2 is a problem and case 4 is not, I would tend towards no option, flag the problem case if we can differentiate. If we cannot differentiate, then provide a parameter. 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
Re: Healthcheck (IBMCSV,CSV_APF_EXISTS)
Hypothesizing that we could differentiate these two cases, would you want us to -- never flag migrated as an exception -- flag migrated as an exception only for case 2 -- flag both cases as exceptions -- have a 2-way parameter that lets you say both or never -- have a 3-way parameter that lets you say both, only case 2, or never As you may know My vote goes to flag migrated as an exception only for case 2 Roland -- 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
Re: Healthcheck (IBMCSV,CSV_APF_EXISTS)
Peter, Given the problem cases, the simple fact of mismatched APF lists is quite possibly a customer environmental problem. Can you please elaborate why you consider different APF lists in a sysplex a customer environmental problem? Actually, how many installations really *need* identical setups on all systems in the plex because everything can run everywhere? I find the identical APF list more bothersome than having different ones: - In our installation the products are just not set up to run on every system in the sysplex, and there is no need to run them everywhere. So defining not-needed APF-Authorizations is not considered a good thing here. - In one sysplex they share the APF list, and we just migrated one of those systems to 1.8. I had a bloody row with my colleagues when the RACF sensitve resources health check hit exactly because APF-authorized datasets are still needed in the old release but not the new one, so they're not on the new sysres's, but the shared PROG-APF member still defines them. Talk about getting them to define a command member that removes those APF-Auths! Thanks and regards, Barbara -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger -- 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
Re: Healthcheck (IBMCSV,CSV_APF_EXISTS)
Peter F wrote: Is it actually possible to migrate a non-SMS-managed dataset? If the answer is yes, where will the dataset be restored when HRECALL is done? Will it be restored to the non-SMS volume from which it came? I am no HSM expert, but the information I was given leads me to answer Yes, somewhere, and not necessarily. Roland wrote: I don't care if a dataset is really SMS-managed or not. If it's flagged as SMS-managed in the APF entry I don't care about the DS migrated healthcheck exception as this is a well known expection and we know this. Roland, Could you elaborate for the user group why you do not care about the possible function-loss and security exposures? 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
Re: Healthcheck (IBMCSV,CSV_APF_EXISTS)
On Tue, 30 Oct 2007 08:31:49 +0100, Barbara Nitz [EMAIL PROTECTED] wrote: Peter, Given the problem cases, the simple fact of mismatched APF lists is quite possibly a customer environmental problem. Can you please elaborate why you consider different APF lists in a sysplex a customer environmental problem? - In our installation the products are just not set up to run on every system in the sysplex, and there is no need to run them everywhere. So defining not-needed APF-Authorizations is not considered a good thing here. We do this to keep some ISV products from getting executed on LPARs where they are not licensed. Some products don't have CPU keys or even if they do, they allow execution with warnings. With shared DASD, catalogs / RACF etc. it is difficult to keep execution on the proper LPARs for these products. If the product requires APF authorization, the easiest way to protect it from execution on an LPAR you don't want it to run on is to NOT APF authorize it. I have used RACF program protection with WHEN(SYSID()) for this also, but that is a last resort. First, the loadlib dsn has to be coded in ADDMEM, so if it changes, protection is lost. And the next person that installs something may not look for this (even if documented). Naming standards change also... so that is another way that gets lost. Second, at DR not all LPARs are recovered and the product may not work without RACF changes. Much easier to APF authorize something after an S047 abend. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- 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
Re: Healthcheck (IBMCSV,CSV_APF_EXISTS)
Peter, Roland wrote: I don't care if a dataset is really SMS-managed or not. If it's flagged as SMS-managed in the APF entry I don't care about the DS migrated healthcheck exception as this is a well known expection and we know this. Roland, Could you elaborate for the user group why you do not care about the possible function-loss and security exposures? I don't see a function-loss and/or securtity exposure, perhaps I missed something. If it's flagged as SMS-managed in APF it will have APF regardless of the volume it might be recalled. I also said the healtcheck exception for SMS-flagged APF entries and DS migrated should be an option for this healthcheck before deactived this check at all. roland -- 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
Re: Healthcheck (IBMCSV,CSV_APF_EXISTS)
snip--- Given the problem cases, the simple fact of mismatched APF lists is quite possibly a customer environmental problem. Can you please elaborate why you consider different APF lists in a sysplex a customer environmental problem? unsnip Read more carefully: quite possibly a customer environmental problem. Many shops, including my old shop at Clearing, ran with identical APF lists throughout the entire 'plex. Our OEM product list was licensed for the entire 'plex, because we used them for both test/development and production. (Sometimes to my strenuous objection!) It was also useful at DR exercises, when we weren't told until we arrived onsite which part of the 'plex was to be recovered in that exercise. Bottom line: Your mileage may vary. While duplicate APF lists across a 'plex might work for you, differing lists might also be workable, and desirable. but there's a POTENTIAL problem vis-a-vis HSM if those lists are different. I believe that Peter was just trying to point out, clearly, that possibility. -- 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
Re: Healthcheck (IBMCSV,CSV_APF_EXISTS)
Rick, how do you keep the APF list sync during software upgrade in SYSPLEX or did your APF list include all entries regardless during the upgrade/rollout? Roland snip--- Given the problem cases, the simple fact of mismatched APF lists is quite possibly a customer environmental problem. Can you please elaborate why you consider different APF lists in a sysplex a customer environmental problem? unsnip Read more carefully: quite possibly a customer environmental problem. -- 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
Re: Healthcheck (IBMCSV,CSV_APF_EXISTS)
--snip Rick, how do you keep the APF list sync during software upgrade in SYSPLEX or did your APF list include all entries regardless during the upgrade/rollout? Roland -unsnip- Since APF-listed libraries were under the exclusive control of the Systems staff, we add all libraries to a single list and removed entries as they became unnecesssary. -- 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
Re: Healthcheck (IBMCSV,CSV_APF_EXISTS)
Rick, this means it contains more entries as needed on some images not to say unnecessary. Ok this keeps the healthcheck and HSM happy. Well we use system symbols for APF and there can be only one. Roland --snip Rick, how do you keep the APF list sync during software upgrade in SYSPLEX or did your APF list include all entries regardless during the upgrade/rollout? Roland -unsnip- Since APF-listed libraries were under the exclusive control of the Systems staff, we add all libraries to a single list and removed entries as they became unnecesssary. -- 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
Re: Healthcheck (IBMCSV,CSV_APF_EXISTS)
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
Re: Healthcheck (IBMCSV,CSV_APF_EXISTS)
Peter, I believe such an option is much better before deactivate this healthcheck because of a well-known wanted situation. Roland 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 -- 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
Re: Healthcheck (IBMCSV,CSV_APF_EXISTS)
I made a mistake in my previous append. It turns out that we can determine if a migrated data set is SMS-managed without recalling it, in case it is deemed appropriate to differentiate between the migrated-and-SMS-managed case and the migrated-but-not-SMS-managed case. 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
Re: Healthcheck (IBMCSV,CSV_APF_EXISTS)
Peter, I don't care if a dataset is really SMS-managed or not. If it's flagged as SMS-managed in the APF entry I don't care about the DS migrated healthcheck exception as this is a well known expection and we know this. Roland I made a mistake in my previous append. It turns out that we can determine if a migrated data set is SMS-managed without recalling it, in case it is deemed appropriate to differentiate between the migrated-and-SMS-managed case and the migrated-but-not-SMS-managed case. Peter Relson -- 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
Re: Healthcheck (IBMCSV,CSV_APF_EXISTS)
The question is: *Can* CSV recognize that the data set is SMS managed when it does the IPL progxx-members? The answer is No. APF processing does not, and will not be changed to, do anything with the actual data set. And during IPL it really is not in a position to do so. The APF entry is merely a data definition. This is precisely why there is a health check. SMS managed SMS managedSuccessful ===!!! The above entry denoted with ===!!! is wrong. Whatever the cause in your environment, I assume it's APARable. I agree with the conclusion. The entry is wrong. If your system is behaving that way, then you should open a PMR with HSM. 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
Re: Healthcheck (IBMCSV,CSV_APF_EXISTS)
Was Barbara saying that other mechanisms than HSM were used to migrate data sets? If so, then we can consider some sort of rules parameter. I was talking about the time when our ISV data sets in APFlist were not SMS-managed. My RACFadmin used to complain a lot about apf datasets being migrated (command migration). This year we have converted to SMS, so this behaviour has stopped (more or less). I just did the same test the others did and got (predictably) the same ARC rc/rsn everyone else had *except* in the case where an APF-auth SMS dataset was only APF-auth'd on one system in the sysplex, not the other. From the other system the command migration went through without a hitch. Given that HC doesn't have XCF communication, but HSM definitely does - I thing in a sysplex HSM should prevent migration by first making sure the dataset in not in APF on *any* system in the sysplex. Now the second case of not using SMS but a volser works as far as APF is concerned but DFSMShsm does not recognize it and WILL migrate it. As you indicated, the APF-EXISTS health check recognizes this (had a lengthy discussion with a colleague who used volser on an SMS-managed dataset and was muttering about the HC). In this case, I think that CSV should not allow an SMS-managed dataset into APF when it is specified via volser (given that HC recognizes this as a bad practise!) The question is: *Can* CSV recognize that the data set is SMS managed when it does the IPL progxx-members? Best regards, Barbara -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser -- 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
Re: Healthcheck ((IBMCSV,CSV_APF_EXISTS)
Knutson, Sam wrote: CHECK(IBMCSV,CSV_APF_EXISTS) START TIME: 10/23/2007 20:03:57.740282 CHECK DATE: 20050720 CHECK SEVERITY: LOW A problem was found with each APF list entry displayed. VOLUME DSNAME ERROR G10078 U06T03.LOAD.TEST.APFMIG DS is SMS-managed DS is SMS-managed The data set is SMS-managed, but the APF list entry specified a volume. If the APF list entry represents a SMS-managed data set but has specified the volume parameter, the data set would not be authorized if it were moved to a different volume. In order for DFSMShsm to verify APF-authorization properly, the APF list entry must indicate that the data set is SMS-managed. I think you could make a good case for DFSMShsm not functioning correctly. It should refuse to migrate both since using SMS is recommended by not required by APF. The check's documentation states that, In order for [HSM] to verify APF-authorization properly, the APF list entry must indicate that the data set is SMS-managed. And, that's exactly what you've demonstrated here. HSM is unable to verify the APF property when an SMS-managed data set is improperly defined as non-SMS-managed in the APF list. So, the data set gets migrated in that case. In summary, HSM will allow migration when the APF list entry is erroneously defined: |Data Set is APF Entry Indicates Erroneous Can Be |SMS Managed SMS-Managed Definition Migrated? |--- --- -- - |YES YES NO NO |NO NO NO Not if matching volume |YES NO YES YES |NO YES YES YES So, the CSV_APF_EXISTS check is doing its job! Right? -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- 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
Re: Healthcheck ((IBMCSV,CSV_APF_EXISTS)
Hi, I agree the CSV_APF_EXISTS check is working correctly. I think DFSMShsm certainly can and should determine a data set is APF regardless of weather it was defined in the recommended way using SMS or incorrectly using a volume serial. SCP honors a volser specified for an SMS managed data for APF till that changes everyone else should too. I don't know if HSM uses CSVAPF for each data set that it has selected to migrate. If so then it probably is invoking it with VOLTYPE=SMS for an SMS managed library and so no match. This is a lot of guessing but if that is the case just using VOLTYPE=ANY would get correct results. If HSM has some sort of RYO code to inspect a list retrieved once from CSVAPF at the beginning of migration then that code would need to change. HSM should not care if you have defined a data set to APF using the correct style. IMHO the CSV_APF_EXISTS is useful and is working correctly telling me what I should do. HSM should honor the APF processing as it is warts and all. Extending HSM to do this protection HSMPlex wide would be an enhancement but I think the case discussed of migration of an SMS managed library APF by volser is defect. The HSM team may not agree I have not reported this. CSVAPF ,VOLTYPE=SMS ,VOLTYPE=ANY,VOLUME=volume Specifies the status of the library specified on the DSNAME parameter, which is one of the following: SMS The library is managed by the storage management subsystem (SMS). ANY The library may or may not be SMS-managed. The library is located on volume volume, which specifies the address of a 6-character volume serial number; for an ADD request, you can also specify ** (six asterisks) to indicate the current sysres volume, or *MCAT* to indicate the volume on which the master catalog resides. If volume is all zeros, the system assumes that the library is SMS-managed. Note: The return code on a Query is determined by whether the match is exact or inexact. A return code of 0 indicates an exact match which could be: o You coded DSNAME=d and VOLTYPE=ANY and VOLUME=v and there is an entry in the APF list that matches both the data set and the volser. o You coded DSNAME=d and an indication of SMS-managed (VOLTYPE=SMS) and there is an entry in the APF list that matches the data set and indicates SMS-managed. A return code of 4 with a reason code = 0401 indicates an inexact match which is: o You coded DSNAME=d and VOLTYPE=ANY and VOLUME=v and there is no exact match, but there is an entry in the APF list that matches the data set and indicates SMS-managed. Best Regards, Sam Knutson, GEICO System z Performance and Availability Management mailto:[EMAIL PROTECTED] (office) 301.986.3574 Think big, act bold, start simple, grow fast... -Original Message- Knutson, Sam wrote: I think you could make a good case for DFSMShsm not functioning correctly. It should refuse to migrate both since using SMS is recommended by not required by APF. The check's documentation states that, In order for [HSM] to verify APF-authorization properly, the APF list entry must indicate that the data set is SMS-managed. And, that's exactly what you've demonstrated here. HSM is unable to verify the APF property when an SMS-managed data set is improperly defined as non-SMS-managed in the APF list. So, the data set gets migrated in that case. In summary, HSM will allow migration when the APF list entry is erroneously defined: |Data Set is APF Entry Indicates Erroneous Can Be |SMS Managed SMS-Managed Definition Migrated? |--- --- -- - |YES YES NO NO |NO NO NO Not if matching volume |YES NO YES YES |NO YES YES YES So, the CSV_APF_EXISTS check is doing its job! Right? -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ This email/fax message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email/fax is prohibited. If you are not the intended recipient, please destroy all paper and electronic copies of the original message. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET
Re: Healthcheck ((IBMCSV,CSV_APF_EXISTS)
I want to thank everyone for trying out these scenarios and letting us know the results. Now I have some evidence with which to pursue this with the HSM folks. I will report back if I find anything out Perhaps Rob Scott and Allan Staller could confirm if Sam Knutson's and Ed Jaffe's (and others) thoughts are correct, with respect to the actual APF list entry. The key pieces of data are: -- is the data set SMS-managed or not that you are trying to HMIGrate? -- is the APF list entry by volume or *SMS*? So the 4 cases are -- data set is SMS-managed, APF list entry is *SMS* -- data set is SMS-managed, APF list entry is by volume -- data set is not SMS-managed, APF list entry is *SMS* -- data set is not SMS-managed, APF list entry is by volume Obviously the 3rd case is not what you would want, but I included it for completeness... 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
Re: Healthcheck ((IBMCSV,CSV_APF_EXISTS)
Peter, APF list entry in PROGxx is : APF ADD DSNAME(some.dataset) SMS some.dataset is SMS managed, and is migrated to ML2. It is likely that at some point in the past on this system (or one of the other systems in the sysplex) that this dataset was migrated whilst NOT in the APF list. Rob Scott Rocket Software, Inc 275 Grove Street Newton, MA 02466 617-614-2305 [EMAIL PROTECTED] -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Peter Relson Sent: 24 October 2007 12:56 To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Healthcheck ((IBMCSV,CSV_APF_EXISTS) I want to thank everyone for trying out these scenarios and letting us know the results. Now I have some evidence with which to pursue this with the HSM folks. I will report back if I find anything out Perhaps Rob Scott and Allan Staller could confirm if Sam Knutson's and Ed Jaffe's (and others) thoughts are correct, with respect to the actual APF list entry. The key pieces of data are: -- is the data set SMS-managed or not that you are trying to HMIGrate? -- is the APF list entry by volume or *SMS*? So the 4 cases are -- data set is SMS-managed, APF list entry is *SMS* -- data set is SMS-managed, APF list entry is by volume -- data set is not SMS-managed, APF list entry is *SMS* -- data set is not SMS-managed, APF list entry is by volume Obviously the 3rd case is not what you would want, but I included it for completeness... 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 -- 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
Re: Healthcheck ((IBMCSV,CSV_APF_EXISTS)
Peter, et. al. My results: APF List Attribute Dataset Attribute Migration Result SMS managed SMS managedSuccessful SMS managed Non-SMS managedSuccessful Non-SMS managed Non-SMS managedFailed Non-SMS managed SMS managedSuccessful This was done with a ordinary dataset and dynamic APF commands on a z/OS 1.7 monopolex. All migration attempts were with the command HMIG dataset snip Perhaps Rob Scott and Allan Staller could confirm if Sam Knutson's and Ed Jaffe's (and others) thoughts are correct, with respect to the actual APF list entry. The key pieces of data are: -- is the data set SMS-managed or not that you are trying to HMIGrate? -- is the APF list entry by volume or *SMS*? So the 4 cases are -- data set is SMS-managed, APF list entry is *SMS* -- data set is SMS-managed, APF list entry is by volume -- data set is not SMS-managed, APF list entry is *SMS* -- data set is not SMS-managed, APF list entry is by volume /snip -- 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
Re: Healthcheck ((IBMCSV,CSV_APF_EXISTS)
Staller, Allan wrote: APF List Attribute Dataset Attribute Migration Result SMS managed SMS managedSuccessful ===!!! SMS managed Non-SMS managedSuccessful Non-SMS managed Non-SMS managedFailed Non-SMS managed SMS managedSuccessful The above entry denoted with ===!!! is wrong. Whatever the cause in your environment, I assume it's APARable. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- 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
Re: Healthcheck ((IBMCSV,CSV_APF_EXISTS)
For me it works I get the expected RC=99 RSN=14 for a HMIG. However I still believe such a condition (SMS-Managed, APF with SMS and migrated) shouldn't throw an expection for this healthcheck Roland -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Staller, Allan Sent: Wednesday, October 24, 2007 3:52 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Healthcheck ((IBMCSV,CSV_APF_EXISTS) Peter, et. al. My results: APF List Attribute Dataset Attribute Migration Result SMS managed SMS managedSuccessful SMS managed Non-SMS managedSuccessful Non-SMS managed Non-SMS managedFailed Non-SMS managed SMS managedSuccessful This was done with a ordinary dataset and dynamic APF commands on a z/OS 1.7 monopolex. All migration attempts were with the command HMIG dataset -- 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
Re: Healthcheck (IBMCSV,CSV_APF_EXISTS)
I had not responded yet because I have not yet been able to get the complete answer. But it seems that something needs to be said in the meantime. When we had developed the check, we had conferred with the HSM folks and were told that they did not allow APF data sets to be migrated. If that proves to be incorrect, then we will change the check not to flag that case as an exception. If that is correct, however, and your scenario was that the data set was migrated and then subsequently added to the APF list, then an exception is reasonable. Was Barbara saying that other mechanisms than HSM were used to migrate data sets? If so, then we can consider some sort of rules parameter. . 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
Re: Healthcheck (IBMCSV,CSV_APF_EXISTS)
Peter, On one of our z/OS 1.8 systems I definitely have APF-list datasets that are migrated. Rob Scott Rocket Software, Inc 275 Grove Street Newton, MA 02466 617-614-2305 [EMAIL PROTECTED] -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Peter Relson Sent: 23 October 2007 14:00 To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Healthcheck (IBMCSV,CSV_APF_EXISTS) I had not responded yet because I have not yet been able to get the complete answer. But it seems that something needs to be said in the meantime. When we had developed the check, we had conferred with the HSM folks and were told that they did not allow APF data sets to be migrated. If that proves to be incorrect, then we will change the check not to flag that case as an exception. If that is correct, however, and your scenario was that the data set was migrated and then subsequently added to the APF list, then an exception is reasonable. Was Barbara saying that other mechanisms than HSM were used to migrate data sets? If so, then we can consider some sort of rules parameter. . 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 -- 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
Re: Healthcheck (IBMCSV,CSV_APF_EXISTS)
On Tue, 23 Oct 2007 09:15:08 -0400, Rob Scott [EMAIL PROTECTED] wrote: On one of our z/OS 1.8 systems I definitely have APF-list datasets that are migrated. Might this be a case such Sam Knutson mentioned, Rob, where HSM on some other system that doesn't have that data set in the APF list migrated it? Or perhaps a case where you did not have the data set in the APF list at the time HSM decided to migrate it, and added it to the APF list after the migration occurred? -- Walt Farrell, CISSP IBM STSM, z/OS Security 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
Re: Healthcheck (IBMCSV,CSV_APF_EXISTS)
Hi, If I understand correctly APF data sets cannot be migrated on the system where they are APF authorized. If you have an asymmetrical configuration in a Sysplex with shared DASD you can have data sets that are infrequently used and APF authorized only a test system migrated on another LPAR where DFHSM migration runs. This could also occur in the same scenario with command migration on the other LPAR. We worked through this scenario with RACF Level-2 when we saw data sets flagged V instead of M in RACF_SENSITIVE_RESOURCES. APAR OA15290 corrected the display in the check. The CSV_APF_EXISTS and RACF_SENSITIVE_RESOURCES checks have been very useful to us! This has allowed us to close real integrity exposures identified by RACF_SENSITIVE_RESOURCES and to tightly police the APF list. We discover typos or miscommunication between groups making requests and the z/OS team right away. I would like to see the checking done by CSV_APF_EXISTS removed from RACF_SENSITIVE_RESOURCES. The biggest problem with RACF_SENSITIVE_RESOURCES is that it surfaces too many different problems in once check where some are much more urgent than others. I imagine some customers would like to see CA ship checks ACF_SENSITIVE_RESOURCES and TOP_SECRET_SENSITIVE_RESOURCES for their customers! I think the Health Checker for z/OS as delivered combined with the way IBM continues to enhance it, developing and shipping meaningful checks is one of the most useful and beneficial features implemented in base z/OS in years. We had for so long not had a framework for exceptions that could be known to be available. Now we have a good framework with great content provided by IBM and the ability to add our own in as well as integrate checks from third party vendors. Best Regards, Sam Knutson, GEICO System z Performance and Availability Management mailto:[EMAIL PROTECTED] (office) 301.986.3574 Think big, act bold, start simple, grow fast... -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Peter Relson Sent: Tuesday, October 23, 2007 9:00 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Healthcheck (IBMCSV,CSV_APF_EXISTS) I had not responded yet because I have not yet been able to get the complete answer. But it seems that something needs to be said in the meantime. When we had developed the check, we had conferred with the HSM folks and were told that they did not allow APF data sets to be migrated. If that proves to be incorrect, then we will change the check not to flag that case as an exception. If that is correct, however, and your scenario was that the data set was migrated and then subsequently added to the APF list, then an exception is reasonable. Was Barbara saying that other mechanisms than HSM were used to migrate data sets? If so, then we can consider some sort of rules parameter. . Peter Relson z/OS Core Technology Design This email/fax message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email/fax is prohibited. If you are not the intended recipient, please destroy all paper and electronic copies of the original message. -- 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
Re: Healthcheck (IBMCSV,CSV_APF_EXISTS)
Addendum, this was on the same system that the dataset was authorized on. SNIP snip When we had developed the check, we had conferred with the HSM folks and were told that they did not allow APF data sets to be migrated. /snip This is incorrect. I APF added a test dataset and issued a HMIGRATE command. (Command migration). The migrate was successful. IIRC, the dataset will not auto-migrate. HTH, /SNIP -- 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
Re: Healthcheck (IBMCSV,CSV_APF_EXISTS)
snip When we had developed the check, we had conferred with the HSM folks and were told that they did not allow APF data sets to be migrated. /snip This is incorrect. I APF added a test dataset and issued a HMIGRATE command. (Command migration). The migrate was successful. IIRC, the dataset will not auto-migrate. HTH, -- 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
Re: Healthcheck (IBMCSV,CSV_APF_EXISTS)
On Tue, 23 Oct 2007 09:15:08 -0400, Rob Scott [EMAIL PROTECTED] wrote: On one of our z/OS 1.8 systems I definitely have APF-list datasets that are migrated. Might this be a case such Sam Knutson mentioned, Rob, where HSM on some other system that doesn't have that data set in the APF list migrated it? This is what happened to us, that is, we had a library defined in APF on one system (SYSA) but not another another system (SYSB) in a plex. The library got migrated on SYSB. George Fogg Or perhaps a case where you did not have the data set in the APF list at the time HSM decided to migrate it, and added it to the APF list after the migration occurred? -- Walt Farrell, CISSP IBM STSM, z/OS Security 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 -- 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
Re: Healthcheck ((IBMCSV,CSV_APF_EXISTS)
Ted MacNEIL wrote: I was under the impression that data sets in the APF list were ineligible for migration. Nope! ARC1001I apf.authorized.data.set MIGRATE FAILED, RC=0099, REAS=0014 ARC1299I UNSUPPORTED DATA SET FOR MIGRATION ARC1299I UNSUPPORTED DATA SET FOR MIGRATION Explanation: DFSMShsm was considering if a data set was eligible for a space management operation and determined that the data set type is one that DFSMShsm does not process, by command or automatically, regardless of the selection criteria being applied. The name of the data set is given in the preceding ARC1001I message or the associated ARC0734I message. The return code field in the ARC1001I or ARC0734I message has a value of 99 (to correspond to the ARC1299I message). The reason code field in the ARC1001I or ARC0734I message lists the reason that DFSMShsm could not space manage the data set. Reascode Meaning 14The data set is an authorized program facility (APF) authorized library. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- 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
Re: Healthcheck ((IBMCSV,CSV_APF_EXISTS)
Ed, Was this from auto-migration or command migration? snip ARC1001I apf.authorized.data.set MIGRATE FAILED, RC=0099, REAS=0014 ARC1299I UNSUPPORTED DATA SET FOR MIGRATION ARC1299I UNSUPPORTED DATA SET FOR MIGRATION Reascode Meaning 14The data set is an authorized program facility (APF) authorized library. /snip -- 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
Re: Healthcheck ((IBMCSV,CSV_APF_EXISTS)
ARC1001I apf.authorized.data.set MIGRATE FAILED, RC=0099, REAS=0014 ARC1299I UNSUPPORTED DATA SET FOR MIGRATION Others on the list have shown that it can happen, with HMIG. I have not tried. But, in an SMS-Managed world should it matter? As long as updates are protected and it doesn't stray too far from its point of origin, who cares? If it's not SMS managed, it's probably on a had-built pack -- why would you send HSM after it? - Too busy driving to stop for gas! -- 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
Re: Healthcheck ((IBMCSV,CSV_APF_EXISTS)
Staller, Allan wrote: Ed, Was this from auto-migration or command migration? READY hmig linklib ARC1007I MIGRATE REQUEST 0117 SENT TO DFSMSHSM READY ARC1001I userid.LINKLIB MIGRATE FAILED, RC=0099, REAS=0014 ARC1299I UNSUPPORTED DATA SET FOR MIGRATION READY -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- 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
Re: Healthcheck ((IBMCSV,CSV_APF_EXISTS)
Ted MacNEIL wrote: ARC1001I apf.authorized.data.set MIGRATE FAILED, RC=0099, REAS=0014 ARC1299I UNSUPPORTED DATA SET FOR MIGRATION Others on the list have shown that it can happen, with HMIG. I have not tried. But, in an SMS-Managed world should it matter? As long as updates are protected and it doesn't stray too far from its point of origin, who cares? If it's not SMS managed, it's probably on a had-built pack -- why would you send HSM after it? HSM disallows all migration activity (auto or command) for an SMS managed data set on the APF list. If the data set is not SMS managed, HSM will allow migration if the data set being migrated is on a volume other than what's specified in the APF list. Otherwise, the migration is disallowed exactly as in the SMS managed case. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- 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
Re: Healthcheck ((IBMCSV,CSV_APF_EXISTS)
HSM disallows all migration activity (auto or command) for an SMS managed data set on the APF list. Okay. I shall take your word for it, since I cannot check it out. But, other posters have given examples, where it (supposedly) works. - Too busy driving to stop for gas! -- 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
Re: Healthcheck ((IBMCSV,CSV_APF_EXISTS)
Hi, I think this might explain different perceptions of what is possible. Case 1 HMIGRATE attempt for SMS managed dataset defined to APF by using the SMS keyword MIGRATE REQUEST 00019980 SENT TO DFSMSHSM ARC1001I U06T03.LOAD.TEST.APFMIG MIGRATE FAILED, RC=0099, REAS=0014 ARC1299I UNSUPPORTED DATA SET FOR MIGRATION Case 2 HMIGRATE attempt for SMS managed APF dataset defined to APF incorrectly using an explicit DASD volser. MIGRATE REQUEST 00019995 SENT TO DFSMSHSM ARC1000I U06T03.LOAD.TEST.APFMIG MIGRATE PROCESSING ENDED *** Now the second case of not using SMS but a volser works as far as APF is concerned but DFSMShsm does not recognize it and WILL migrate it. This wrinkle had not occurred to me until today reading seemingly contradictory statements of fact. The CSV_APF_EXISTS will flag the second case but it is ignored by RACF_SENSITIVE_RESOURCES. CHECK(IBMCSV,CSV_APF_EXISTS) START TIME: 10/23/2007 20:03:57.740282 CHECK DATE: 20050720 CHECK SEVERITY: LOW A problem was found with each APF list entry displayed. VOLUME DSNAME ERROR G10078 U06T03.LOAD.TEST.APFMIG DS is SMS-managed DS is SMS-managed The data set is SMS-managed, but the APF list entry specified a volume. If the APF list entry represents a SMS-managed data set but has specified the volume parameter, the data set would not be authorized if it were moved to a different volume. In order for DFSMShsm to verify APF-authorization properly, the APF list entry must indicate that the data set is SMS-managed. I think you could make a good case for DFSMShsm not functioning correctly. It should refuse to migrate both since using SMS is recommended by not required by APF. Best Regards, Sam Knutson, GEICO System z Performance and Availability Management mailto:[EMAIL PROTECTED] (office) 301.986.3574 Think big, act bold, start simple, grow fast... -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Edward Jaffe Sent: Tuesday, October 23, 2007 5:32 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Healthcheck ((IBMCSV,CSV_APF_EXISTS) Staller, Allan wrote: Ed, Was this from auto-migration or command migration? READY hmig linklib ARC1007I MIGRATE REQUEST 0117 SENT TO DFSMSHSM READY ARC1001I userid.LINKLIB MIGRATE FAILED, RC=0099, REAS=0014 ARC1299I UNSUPPORTED DATA SET FOR MIGRATION READY -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ This email/fax message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email/fax is prohibited. If you are not the intended recipient, please destroy all paper and electronic copies of the original message. -- 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
Re: Healthcheck ((IBMCSV,CSV_APF_EXISTS)
On Oct 23, 2007, at 4:06 PM, Edward Jaffe wrote: Ted MacNEIL wrote: I was under the impression that data sets in the APF list were ineligible for migration. Nope! ARC1001I apf.authorized.data.set MIGRATE FAILED, RC=0099, REAS=0014 ARC1299I UNSUPPORTED DATA SET FOR MIGRATION ARC1299I UNSUPPORTED DATA SET FOR MIGRATION Explanation: DFSMShsm was considering if a data set was eligible for a space management operation and determined that the data set type is one that DFSMShsm does not process, by command or automatically, regardless of the selection criteria being applied. The name of the data set is given in the preceding ARC1001I message or the associated ARC0734I message. The return code field in the ARC1001I or ARC0734I message has a value of 99 (to correspond to the ARC1299I message). The reason code field in the ARC1001I or ARC0734I message lists the reason that DFSMShsm could not space manage the data set. Reascode Meaning 14The data set is an authorized program facility (APF) authorized library. -- Ed, Somewhere back in the mist of time Late 1990's(?) I *THOUGHT* IBM stated that if you specified a dsn as SMS managed it (the system) would not care what dasd volume it was on (in otherwords it kept the apf authorization after recall. This really sticks in my memory. I think this issue arose out of SMS conversions in the 90's as a reason not to go SMS. IBM (I Think) indicated in the future this would be fixed. Does anyone else remember this? Ed -- 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
Re: Healthcheck ((IBMCSV,CSV_APF_EXISTS)
Ed Gould wrote: On Oct 23, 2007, at 4:06 PM, Edward Jaffe wrote: Reascode Meaning 14The data set is an authorized program facility (APF) authorized library. Somewhere back in the mist of time Late 1990's(?) I *THOUGHT* IBM stated that if you specified a dsn as SMS managed it (the system) would not care what dasd volume it was on (in otherwords it kept the apf authorization after recall. This really sticks in my memory. I think this issue arose out of SMS conversions in the 90's as a reason not to go SMS. IBM (I Think) indicated in the future this would be fixed. The current behavior was implemented with DFSMS/MVS V1R0 in the MVS/ESA V4R3 time frame. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- 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
Re: Healthcheck ((IBMCSV,CSV_APF_EXISTS)
ok so the HC should omit such a combination (SMS-managed and migrated) So the remaining question is this a wrong setup or just the HC miss this valid combination. In the sysprog sandplex we tended to have this check trip quite a bit, too. Nobody and nothing is going to prevent a sysprog from hmigrating datasets to ML2 manually, least of all DFHSM. Here it was usually for vendor data sets, and when we made them (almost) all SMS-managed, this has disappeared. (Well, the most guilty sysprog is currently on a longer absence..., coinciding with sms-conversion:-) ). So HC doesn't really catch this valid combination, so just ignore it. (And if that APF-data set is also in lnklst, it cannot be hmigrated). Regards, Barbara -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser -- 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
Re: Healthcheck ((IBMCSV,CSV_APF_EXISTS)
Hmmhhh. no comments from IBM so far. Seems a RCF should do. If time permit I'll do. Roland ok so the HC should omit such a combination (SMS-managed and migrated) So the remaining question is this a wrong setup or just the HC miss this valid combination. In the sysprog sandplex we tended to have this check trip quite a bit, too. Nobody and nothing is going to prevent a sysprog from hmigrating datasets to ML2 manually, least of all DFHSM. Here it was usually for vendor data sets, and when we made them (almost) all SMS-managed, this has disappeared. (Well, the most guilty sysprog is currently on a longer absence..., coinciding with sms-conversion:-) ). So HC doesn't really catch this valid combination, so just ignore it. (And if that APF-data set is also in lnklst, it cannot be hmigrated). Regards, Barbara -- 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
Healthcheck ((IBMCSV,CSV_APF_EXISTS)
I get the following healthcheck exception CHECK(IBMCSV,CSV_APF_EXISTS) START TIME: 10/21/2007 23:15:31.955168 CHECK DATE: 20050720 CHECK SEVERITY: LOW CSVH0955I A problem was found with each APF list entry displayed. VOLUME DSNAME ERROR *SMS* xxx.xxx.xxx DS is migrated *SMS* xxx.xxx.xxx DS is migrated * Low Severity Exception * CSVH0957E Problem(s) were found with data sets in the APF list. Explanation: CSVH0955I has been placed in the message buffer to describe the APF list entry error and condition that caused the exception. A potential system integrity risk exists when a data set cannot be allocated using the criteria specified in the system APF list. If this data set were created it would be considered APF-authorized. The error is one of the following conditions: DS is alias The data set name is an alias of another data set. An APF list entry that has the alias of a data set rather than the real data set does not APF-authorize the data set. DS is migrated The data set is migrated. APF-authorized data sets should not be migrated because they might not be restored to the same volume. Yes the DS is migrated on our sandbox and is *SMS-managed* so a DS migrated is ok What did you think? Roland Schiradin ALTE LEIPZIGER Lebensversicherung auf Gegenseitigkeit IT Betrieb - DB/DC Tel. (06171) 66-4095, Fax (06171) 66-7500-4095 mailto:[EMAIL PROTECTED] http://www.Alte-Leipziger.de -- 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
Re: Healthcheck ((IBMCSV,CSV_APF_EXISTS)
Schiradin,Roland HG-Dir itb-db/dc wrote: Yes the DS is migrated on our sandbox and is *SMS-managed* so a DS migrated is ok What did you think? I was under the impression that data sets in the APF list were ineligible for migration. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- 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
Re: Healthcheck ((IBMCSV,CSV_APF_EXISTS)
me either. Roland -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Edward Jaffe Sent: Monday, October 22, 2007 12:04 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Healthcheck ((IBMCSV,CSV_APF_EXISTS) Schiradin,Roland HG-Dir itb-db/dc wrote: Yes the DS is migrated on our sandbox and is *SMS-managed* so a DS migrated is ok What did you think? I was under the impression that data sets in the APF list were ineligible for migration. -- 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
Re: Healthcheck ((IBMCSV,CSV_APF_EXISTS)
Yes the DS is migrated on our sandbox and is *SMS-managed* so a DS migrated is ok What did you think? I think this should be fine. SMS managed APF DS are volume independent. (I remember when a SYSPROG got caught on this over 10 years ago.) This is a design flaw! - Too busy driving to stop for gas! -- 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
Re: Healthcheck ((IBMCSV,CSV_APF_EXISTS)
I was under the impression that data sets in the APF list were ineligible for migration. Nope! - Too busy driving to stop for gas! -- 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
Re: Healthcheck ((IBMCSV,CSV_APF_EXISTS)
I agree but I thought an APF dataset should never migrate like Ed said. Well I'm not a HSM person so I don't know for sure However migrated datasets while SMS managed shouldn't throw this healthcheck exception. Roland -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ted MacNEIL Sent: Monday, October 22, 2007 12:13 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Healthcheck ((IBMCSV,CSV_APF_EXISTS) Yes the DS is migrated on our sandbox and is *SMS-managed* so a DS migrated is ok What did you think? I think this should be fine. SMS managed APF DS are volume independent. (I remember when a SYSPROG got caught on this over 10 years ago.) This is a design flaw! - Too busy driving to stop for gas! -- 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 -- 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
Re: Healthcheck ((IBMCSV,CSV_APF_EXISTS)
I agree but I thought an APF dataset should never migrate like Ed said. HSM does not interface with the APF API. Unfortunately, it just checks date and sends it off. But, it shouldn't matter. If you have a product that is used infrequently, why not migrate the load libs? You could set up a MGMTCLAS that never migrates, and assign it to these libraries (manually or automagically), but does it really matter? The issue is more about the fact that the dsn being migrated is not a problem. - Too busy driving to stop for gas! -- 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
Re: Healthcheck ((IBMCSV,CSV_APF_EXISTS)
If you have a product that is used infrequently, why not migrate the load libs? ok so the HC should omit such a combination (SMS-managed and migrated) So the remaining question is this a wrong setup or just the HC miss this valid combination. Roland -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ted MacNEIL Sent: Monday, October 22, 2007 12:33 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Healthcheck ((IBMCSV,CSV_APF_EXISTS) I agree but I thought an APF dataset should never migrate like Ed said. HSM does not interface with the APF API. Unfortunately, it just checks date and sends it off. But, it shouldn't matter. If you have a product that is used infrequently, why not migrate the load libs? -- 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
Re: Healthcheck ((IBMCSV,CSV_APF_EXISTS)
So the remaining question is this a wrong setup or just the HC miss this valid combination. IMHO, migrated APF libraries is not a problem. Under SMS it should be okay. So, HC (again) is in the wrong. But, I had already stated that (or so I thought). What is the difference between migrating an SMS-Managed APF and moving it around manually? I beleive the protection afforded to the library is more important than where it resides. - Too busy driving to stop for gas! -- 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
