Your users don't like automated migration? Point in time backups I can understand but Migration?
OK is there a time of day when volumes are not being 'command migrated'? You might issue a Backvol CDS at that time. Are your Control datasets on any of the volumes being migrated? Dave O'Brien NIH Contractor ________________________________________ From: IBM Mainframe Discussion List [ibm-m...@bama.ua.edu] On Behalf Of Jacky Bright [jacky.bri...@gmail.com] Sent: Wednesday, March 04, 2009 11:38 AM To: IBM-MAIN@bama.ua.edu Subject: Re: DFHSM Issue - Critical Yes. Backing up directly to VTS Tape. No no Backvol CDS command. HSM itself takes the backup of CDS. Observed that when CDS backup is going on many MIGRATE VOLUME commands issued externally. On 3/4/09, O'Brien, David W. (NIH/CIT) [C] <obrie...@mail.nih.gov> wrote: > > For DFHSM to be hung for so long, would lead me to suspect a problem with > allocating the CDS Backup files. > > Jacky, Are you backing up to tape? If YES, Is there a lot of concurrent > tape activity? > Are you submitting a Backvol CDS command separately from normal HSM > operations? > Is the time you submit the CDS Backup command in conflict with Backups or > Space Mgt.? > > Allan, I find that CDS Backups run before my Incremental Backups but then > I've always scheduled Backups before Secondary Space Mgt. Is it possible > that HSM automatically backs up the CDS datasets before the first major > automated process after midnight whether it is Primary or Secondary Space > Mgt. or Incremental Backups if the CDSVERSIONBACKUP parameter is coded in > Parmlib? I haven't found a clear description in the FMs. > > Dave O'Brien > NIH Contractor > ________________________________________ > From: IBM Mainframe Discussion List [ibm-m...@bama.ua.edu] On Behalf Of > Staller, Allan [allan.stal...@kbm1.com] > Sent: Wednesday, March 04, 2009 10:04 AM > To: IBM-MAIN@bama.ua.edu > Subject: Re: DFHSM Issue - Critical > > BTDTGTTS, > > This is what has been colloquially known as a 'fatal embrace' and is not > just limited to DFHSM. > In my experience this has been caused by multiple HSM functions running > in parallel with w/DFHSM CDS backup. > > The CDS backup enqueues exclusively and seperately on all three CDS's > and the journal. If both (typically) backup and migrgration are running > concurrently with the CDS backup, CDS backup can't get all of the > datasets needed to complete. > CDS backup is, however, designed to run concurrently with normal HSM > operation. > > The simplest solution is to move the CDS backup to some other time of > day. > > Note: Secondary space management will always take a CDS backup at the > beginning of its cycle. > > HTH, > <snip> > But when DFHSM is hanging then even for 2 hours intermittently in > response > to QUERY ACTIVE command gets status CDS Backup in progress. When DFHSM > is > cancelled and restarted then backup completes in few minutes. Can CDS > Backup > run concurrently with other DFHSM operations ? > </snip> > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu 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 lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html