Again, I don't know HSM. But don't necessarily take whining and gnashing of teeth as 'failure'. HSM is letting you know (loudly) that a DD statement is missing in case you overlooked it. You might actually take heart in
*ARC0134I BACKUP CONTROL DATA SET NOT OPENED, BACKUP ARC0134I (CONT.) WILL NOT BE ENABLED as an indication of achieving what you wanted. ;-) OTOH abends on OPEN, as with DUMMY, are not likely to be productive. . . JO.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile [email protected] From: "[email protected]" <[email protected]> To: [email protected], Date: 07/03/2013 08:16 AM Subject: Re: Installing HSM or rather: DFHSM woes Sent by: IBM Mainframe Discussion List <[email protected]> > DUMMY muddies the water because > the DDNAME is truly allocated even though there is no tin can at the other > end of the string. A component that wants to use that file may well try to > open it. Depending on how the file is accessed, DUMMY can cause OPEN > failure. Well, not in the case of HSM. During my first start I had deleted the OFFCAT and BAKCAT statements, and that resulted in IEC130I BAKCAT DD STATEMENT MISSING ARC0945I OPEN OF DDNAME=BAKCAT FAILED, VSAM REASON ARC0945I (CONT.) CODE IS X'80' *ARC0134I BACKUP CONTROL DATA SET NOT OPENED, BACKUP ARC0134I (CONT.) WILL NOT BE ENABLED IEC130I OFFCAT DD STATEMENT MISSING ARC0945I OPEN OF DDNAME=OFFCAT FAILED, VSAM REASON ARC0945I (CONT.) CODE IS X'80' At which point I made the dd statements dummy, but I did expect the code to check for DUMMY and then NOT try and open something that just isn't there! > In addition, an application controlled by a parm file may need > some statements tweaked to indicate that the related function is not > desired at all. All this notwithstanding, suggestions to include files now > that you don't think you need is probably sound advice. I have set all the parms in ARCCMD so that the functions should not get used at all. At least I think I did. But the ARCCMD member is apparently read *after* the open failures. The reason I don't want to go and define these (for us) unnecessary data sets are the many warnings and caveats that come with where to allocate this stuff. I don't have all that many volumes (after all, this is an ADCD system), and we don't have any automatisms that could take care of cleaning up after something we don't need. And yes, everybody is aware of the risks of loosing a volume, that's why I periodically take the system down and backup everything to an external drive, which includes all system data sets and would include the state of HSM. In case of failure I would go back to a complete set of backups. (The vital data are not supposed to get migrated at all.) As I said, we need HSM to clean up temporary stuff and to test migration functions. ML1 only. Barbara ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
