Re: DFHSM QUESTION - RECALLING SMS DSNS TO A SPECIFIC SMS MANAGED DISK
You mention "bypass options". Does this pertain to recalling the file to a non-SMS disk or SMS disk? I would like to try out your suggestion. On Friday, 6 July 2018, 2:53:13 pm GMT-4, Gibney, Dave wrote: There are bypass options, given sufficient authority. Of course, with sufficient authority, the ACS routines could be tweaked for the specific case during recall. :) > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Allan Staller > Sent: Friday, July 06, 2018 11:50 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: DFHSM QUESTION - RECALLING SMS DSNS TO A SPECIFIC SMS > MANAGED DISK > > I don't think ADRDSSU will override the SMS specifications. > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Gibney, Dave > Sent: Friday, July 6, 2018 1:43 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: DFHSM QUESTION - RECALLING SMS DSNS TO A SPECIFIC SMS > MANAGED DISK > > 1. Pull it back. 2. Move it with ADDRDSSU > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > > On Behalf Of Mike Schwab > > Sent: Friday, July 06, 2018 11:24 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: DFHSM QUESTION - RECALLING SMS DSNS TO A SPECIFIC SMS > > MANAGED DISK > > > > If that dataset needs a large allocation, quiesce a/that volume, > > migrate the select volume to move unallocated datasets on it, defrag > > to create larger extents, then recall it. If no active volume has > > enough space, it would go there. > > On Fri, Jul 6, 2018 at 10:07 AM John Dawes <00ff0e22811f-dmarc- > > requ...@listserv.ua.edu> wrote: > > > > > > Allan, > > > Thanks for your suggestion. I looked at that option however being > > > in the > > Production cycle window I cannot do so because jobs could abend if I > > do a DISNEW. > > > On Friday, 6 July 2018, 11:00:02 am GMT-4, Allan Staller > > wrote: > > > > > > AFAIK, Guaranteed Space only (IMO) acceptable way to accomplish > > > what > > you've described. > > > > > > You could place all of the other volumes in the pool in QUIESCE or > > > DISNEW > > for the duration (IMO, not acceptable). > > > You could make the ACS routine and SMS update to place the desired > > > volume in its own SG, restore your data, and reverse the process. > > > (Waaay tooo much work!) > > > > > > HTH, > > > > > > -Original Message- > > > From: IBM Mainframe Discussion List > > > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Dawes > > > Sent: Friday, July 6, 2018 9:48 AM > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > Subject: DFHSM QUESTION - RECALLING SMS DSNS TO A SPECIFIC SMS > > MANAGED > > > DISK > > > > > > G'Day, > > > Because of storage considerations I would like to recall some ML2 > > > SMS > > managed dsns to a specific SMS managed disk. I tried a few things e.g. > > :HSEND RECALL 'CICSV2.XPD2.A7060.ZFE1' VOLUME(ZFE315) - UNIT(3390) > > However the dsn was not recalled to the desired disk. I thought of > > using the GUARANTEED SPACE storage class option as a work around. I > > checked the doc (DFSMShsm Storage Administration Guide) but I could > > not find an example. Is this possible to do? If so, would anyone > > have an example to share? > > > Thanks. > > > > > > > > > -- For IBM-MAIN subscribe / signoff / archive access instructions, > > > send email to lists...@listserv.ua.edu with the message: INFO > > > IBM-MAIN > > > ::DISCLAIMER:: > > > > > > -- > > > > > > -- > > > > > > -- > > > > > > The contents of this e-mail and any attachment(s) are confidential > > > and > > intended for the named recipient(s) only. E-mail transmission is not > > guaranteed to be secure or error-free as information could be > > intercepted, corrupted, lost, destroyed, arrive late or incomplete, or > > may contain viruses in transmission. The e mail and its contents (with > > or without referred errors) shall
Re: DFHSM QUESTION - RECALLING SMS DSNS TO A SPECIFIC SMS MANAGED DISK
There are bypass options, given sufficient authority. Of course, with sufficient authority, the ACS routines could be tweaked for the specific case during recall. :) > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Allan Staller > Sent: Friday, July 06, 2018 11:50 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: DFHSM QUESTION - RECALLING SMS DSNS TO A SPECIFIC SMS > MANAGED DISK > > I don't think ADRDSSU will override the SMS specifications. > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Gibney, Dave > Sent: Friday, July 6, 2018 1:43 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: DFHSM QUESTION - RECALLING SMS DSNS TO A SPECIFIC SMS > MANAGED DISK > > 1. Pull it back. 2. Move it with ADDRDSSU > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > > On Behalf Of Mike Schwab > > Sent: Friday, July 06, 2018 11:24 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: DFHSM QUESTION - RECALLING SMS DSNS TO A SPECIFIC SMS > > MANAGED DISK > > > > If that dataset needs a large allocation, quiesce a/that volume, > > migrate the select volume to move unallocated datasets on it, defrag > > to create larger extents, then recall it. If no active volume has > > enough space, it would go there. > > On Fri, Jul 6, 2018 at 10:07 AM John Dawes <00ff0e22811f-dmarc- > > requ...@listserv.ua.edu> wrote: > > > > > > Allan, > > > Thanks for your suggestion. I looked at that option however being > > > in the > > Production cycle window I cannot do so because jobs could abend if I > > do a DISNEW. > > > On Friday, 6 July 2018, 11:00:02 am GMT-4, Allan Staller > > wrote: > > > > > > AFAIK, Guaranteed Space only (IMO) acceptable way to accomplish > > > what > > you've described. > > > > > > You could place all of the other volumes in the pool in QUIESCE or > > > DISNEW > > for the duration (IMO, not acceptable). > > > You could make the ACS routine and SMS update to place the desired > > > volume in its own SG, restore your data, and reverse the process. > > > (Waaay tooo much work!) > > > > > > HTH, > > > > > > -Original Message- > > > From: IBM Mainframe Discussion List > > > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Dawes > > > Sent: Friday, July 6, 2018 9:48 AM > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > Subject: DFHSM QUESTION - RECALLING SMS DSNS TO A SPECIFIC SMS > > MANAGED > > > DISK > > > > > > G'Day, > > > Because of storage considerations I would like to recall some ML2 > > > SMS > > managed dsns to a specific SMS managed disk. I tried a few things e.g. > > :HSEND RECALL 'CICSV2.XPD2.A7060.ZFE1' VOLUME(ZFE315) - UNIT(3390) > > However the dsn was not recalled to the desired disk. I thought of > > using the GUARANTEED SPACE storage class option as a work around. I > > checked the doc (DFSMShsm Storage Administration Guide) but I could > > not find an example. Is this possible to do? If so, would anyone > > have an example to share? > > > Thanks. > > > > > > > > > -- For IBM-MAIN subscribe / signoff / archive access instructions, > > > send email to lists...@listserv.ua.edu with the message: INFO > > > IBM-MAIN > > > ::DISCLAIMER:: > > > > > > -- > > > > > > -- > > > > > > -- > > > > > > The contents of this e-mail and any attachment(s) are confidential > > > and > > intended for the named recipient(s) only. E-mail transmission is not > > guaranteed to be secure or error-free as information could be > > intercepted, corrupted, lost, destroyed, arrive late or incomplete, or > > may contain viruses in transmission. The e mail and its contents (with > > or without referred errors) shall therefore not attach any lia
Re: DFHSM QUESTION - RECALLING SMS DSNS TO A SPECIFIC SMS MANAGED DISK
I don't think ADRDSSU will override the SMS specifications. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gibney, Dave Sent: Friday, July 6, 2018 1:43 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DFHSM QUESTION - RECALLING SMS DSNS TO A SPECIFIC SMS MANAGED DISK 1. Pull it back. 2. Move it with ADDRDSSU > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Mike Schwab > Sent: Friday, July 06, 2018 11:24 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: DFHSM QUESTION - RECALLING SMS DSNS TO A SPECIFIC SMS > MANAGED DISK > > If that dataset needs a large allocation, quiesce a/that volume, > migrate the select volume to move unallocated datasets on it, defrag > to create larger extents, then recall it. If no active volume has > enough space, it would go there. > On Fri, Jul 6, 2018 at 10:07 AM John Dawes <00ff0e22811f-dmarc- > requ...@listserv.ua.edu> wrote: > > > > Allan, > > Thanks for your suggestion. I looked at that option however being > > in the > Production cycle window I cannot do so because jobs could abend if I > do a DISNEW. > > On Friday, 6 July 2018, 11:00:02 am GMT-4, Allan Staller > wrote: > > > > AFAIK, Guaranteed Space only (IMO) acceptable way to accomplish > > what > you've described. > > > > You could place all of the other volumes in the pool in QUIESCE or > > DISNEW > for the duration (IMO, not acceptable). > > You could make the ACS routine and SMS update to place the desired > > volume in its own SG, restore your data, and reverse the process. > > (Waaay tooo much work!) > > > > HTH, > > > > -Original Message- > > From: IBM Mainframe Discussion List > > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Dawes > > Sent: Friday, July 6, 2018 9:48 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: DFHSM QUESTION - RECALLING SMS DSNS TO A SPECIFIC SMS > MANAGED > > DISK > > > > G'Day, > > Because of storage considerations I would like to recall some ML2 > > SMS > managed dsns to a specific SMS managed disk. I tried a few things e.g. > :HSEND RECALL 'CICSV2.XPD2.A7060.ZFE1' VOLUME(ZFE315) - UNIT(3390) > However the dsn was not recalled to the desired disk. I thought of > using the GUARANTEED SPACE storage class option as a work around. I > checked the doc (DFSMShsm Storage Administration Guide) but I could > not find an example. Is this possible to do? If so, would anyone > have an example to share? > > Thanks. > > > > > > -- For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO > > IBM-MAIN > > ::DISCLAIMER:: > > > > -- > > > > -- > > > > -- > > > > The contents of this e-mail and any attachment(s) are confidential > > and > intended for the named recipient(s) only. E-mail transmission is not > guaranteed to be secure or error-free as information could be > intercepted, corrupted, lost, destroyed, arrive late or incomplete, or > may contain viruses in transmission. The e mail and its contents (with > or without referred errors) shall therefore not attach any liability on the > originator or HCL or its affiliates. > Views or opinions, if any, presented in this email are solely those of > the author and may not necessarily reflect the views or opinions of > HCL or its affiliates. Any form of reproduction, dissemination, > copying, disclosure, modification, distribution and / or publication > of this message without the prior written consent of authorized > representative of HCL is strictly prohibited. If you have received > this email in error please delete it and notify the sender > immediately. Before opening any email and/or attachments, please check them > for viruses and other defects. > > > > -- > > > > -- > > > > -- > > > > > > -
Re: DFHSM QUESTION - RECALLING SMS DSNS TO A SPECIFIC SMS MANAGED DISK
1. Pull it back. 2. Move it with ADDRDSSU > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Mike Schwab > Sent: Friday, July 06, 2018 11:24 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: DFHSM QUESTION - RECALLING SMS DSNS TO A SPECIFIC SMS > MANAGED DISK > > If that dataset needs a large allocation, quiesce a/that volume, migrate the > select volume to move unallocated datasets on it, defrag to create larger > extents, then recall it. If no active volume has enough space, it would go > there. > On Fri, Jul 6, 2018 at 10:07 AM John Dawes <00ff0e22811f-dmarc- > requ...@listserv.ua.edu> wrote: > > > > Allan, > > Thanks for your suggestion. I looked at that option however being in the > Production cycle window I cannot do so because jobs could abend if I do a > DISNEW. > > On Friday, 6 July 2018, 11:00:02 am GMT-4, Allan Staller > wrote: > > > > AFAIK, Guaranteed Space only (IMO) acceptable way to accomplish what > you've described. > > > > You could place all of the other volumes in the pool in QUIESCE or DISNEW > for the duration (IMO, not acceptable). > > You could make the ACS routine and SMS update to place the desired > > volume in its own SG, restore your data, and reverse the process. > > (Waaay tooo much work!) > > > > HTH, > > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > > On Behalf Of John Dawes > > Sent: Friday, July 6, 2018 9:48 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: DFHSM QUESTION - RECALLING SMS DSNS TO A SPECIFIC SMS > MANAGED > > DISK > > > > G'Day, > > Because of storage considerations I would like to recall some ML2 SMS > managed dsns to a specific SMS managed disk. I tried a few things e.g. > :HSEND RECALL 'CICSV2.XPD2.A7060.ZFE1' VOLUME(ZFE315) - UNIT(3390) > However the dsn was not recalled to the desired disk. I thought of using the > GUARANTEED SPACE storage class option as a work around. I checked the > doc (DFSMShsm Storage Administration Guide) but I could not find an > example. Is this possible to do? If so, would anyone have an example to > share? > > Thanks. > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, send > > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > ::DISCLAIMER:: > > -- > > -- > > -- > > > > The contents of this e-mail and any attachment(s) are confidential and > intended for the named recipient(s) only. E-mail transmission is not > guaranteed to be secure or error-free as information could be intercepted, > corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses > in transmission. The e mail and its contents (with or without referred errors) > shall therefore not attach any liability on the originator or HCL or its > affiliates. > Views or opinions, if any, presented in this email are solely those of the > author and may not necessarily reflect the views or opinions of HCL or its > affiliates. Any form of reproduction, dissemination, copying, disclosure, > modification, distribution and / or publication of this message without the > prior written consent of authorized representative of HCL is strictly > prohibited. If you have received this email in error please delete it and > notify > the sender immediately. Before opening any email and/or attachments, > please check them for viruses and other defects. > > -- > > -- > > -- > > > > > > -- > > 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 > > > > -- > Mike A Schwab,
Re: DFHSM QUESTION - RECALLING SMS DSNS TO A SPECIFIC SMS MANAGED DISK
If that dataset needs a large allocation, quiesce a/that volume, migrate the select volume to move unallocated datasets on it, defrag to create larger extents, then recall it. If no active volume has enough space, it would go there. On Fri, Jul 6, 2018 at 10:07 AM John Dawes <00ff0e22811f-dmarc-requ...@listserv.ua.edu> wrote: > > Allan, > Thanks for your suggestion. I looked at that option however being in the > Production cycle window I cannot do so because jobs could abend if I do a > DISNEW. > On Friday, 6 July 2018, 11:00:02 am GMT-4, Allan Staller > wrote: > > AFAIK, Guaranteed Space only (IMO) acceptable way to accomplish what you've > described. > > You could place all of the other volumes in the pool in QUIESCE or DISNEW for > the duration (IMO, not acceptable). > You could make the ACS routine and SMS update to place the desired volume in > its own SG, restore your data, and reverse the process. (Waaay tooo much > work!) > > HTH, > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of John Dawes > Sent: Friday, July 6, 2018 9:48 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: DFHSM QUESTION - RECALLING SMS DSNS TO A SPECIFIC SMS MANAGED DISK > > G'Day, > Because of storage considerations I would like to recall some ML2 SMS managed > dsns to a specific SMS managed disk. I tried a few things e.g. :HSEND RECALL > 'CICSV2.XPD2.A7060.ZFE1' VOLUME(ZFE315) - UNIT(3390) >However the dsn was not recalled to the desired disk. I > thought of using the GUARANTEED SPACE storage class option as a work around. > I checked the doc (DFSMShsm Storage Administration Guide) but I could not > find an example. Is this possible to do? If so, would anyone have an > example to share? > Thanks. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to > lists...@listserv.ua.edu with the message: INFO IBM-MAIN > ::DISCLAIMER:: > -- > The contents of this e-mail and any attachment(s) are confidential and > intended for the named recipient(s) only. E-mail transmission is not > guaranteed to be secure or error-free as information could be intercepted, > corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses > in transmission. The e mail and its contents (with or without referred > errors) shall therefore not attach any liability on the originator or HCL or > its affiliates. Views or opinions, if any, presented in this email are solely > those of the author and may not necessarily reflect the views or opinions of > HCL or its affiliates. Any form of reproduction, dissemination, copying, > disclosure, modification, distribution and / or publication of this message > without the prior written consent of authorized representative of HCL is > strictly prohibited. If you have received this email in error please delete > it and notify the sender immediately. Before opening any email and/or > attachments, please check them for viruses and other defects. > -- > > -- > 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 -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION - RECALLING SMS DSNS TO A SPECIFIC SMS MANAGED DISK
Allan, Thanks for your suggestion. I looked at that option however being in the Production cycle window I cannot do so because jobs could abend if I do a DISNEW. On Friday, 6 July 2018, 11:00:02 am GMT-4, Allan Staller wrote: AFAIK, Guaranteed Space only (IMO) acceptable way to accomplish what you've described. You could place all of the other volumes in the pool in QUIESCE or DISNEW for the duration (IMO, not acceptable). You could make the ACS routine and SMS update to place the desired volume in its own SG, restore your data, and reverse the process. (Waaay tooo much work!) HTH, -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Dawes Sent: Friday, July 6, 2018 9:48 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: DFHSM QUESTION - RECALLING SMS DSNS TO A SPECIFIC SMS MANAGED DISK G'Day, Because of storage considerations I would like to recall some ML2 SMS managed dsns to a specific SMS managed disk. I tried a few things e.g. :HSEND RECALL 'CICSV2.XPD2.A7060.ZFE1' VOLUME(ZFE315) - UNIT(3390) However the dsn was not recalled to the desired disk. I thought of using the GUARANTEED SPACE storage class option as a work around. I checked the doc (DFSMShsm Storage Administration Guide) but I could not find an example. Is this possible to do? If so, would anyone have an example to share? Thanks. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: -- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- -- 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
Re: DFHSM QUESTION - RECALLING SMS DSNS TO A SPECIFIC SMS MANAGED DISK
AFAIK, Guaranteed Space only (IMO) acceptable way to accomplish what you've described. You could place all of the other volumes in the pool in QUIESCE or DISNEW for the duration (IMO, not acceptable). You could make the ACS routine and SMS update to place the desired volume in its own SG, restore your data, and reverse the process. (Waaay tooo much work!) HTH, -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Dawes Sent: Friday, July 6, 2018 9:48 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: DFHSM QUESTION - RECALLING SMS DSNS TO A SPECIFIC SMS MANAGED DISK G'Day, Because of storage considerations I would like to recall some ML2 SMS managed dsns to a specific SMS managed disk. I tried a few things e.g. :HSEND RECALL 'CICSV2.XPD2.A7060.ZFE1' VOLUME(ZFE315) - UNIT(3390) However the dsn was not recalled to the desired disk. I thought of using the GUARANTEED SPACE storage class option as a work around. I checked the doc (DFSMShsm Storage Administration Guide) but I could not find an example. Is this possible to do? If so, would anyone have an example to share? Thanks. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: -- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION - PROBLEM SOLVED.
Just to let you all know I finally was able to delete the records. I was barking up the wrong tree. I was concentrating on the 'B" instead of the "C" records. I dd a FIXCDS C HSMBACK.BACK.T592617.DB2.ARCHLOG2.I8257 DELETE That did the trick. Thanks to all who responded and helped out with their suggestions. On Fri, 7/28/17, willie bunter <williebun...@yahoo.com> wrote: Subject: Re: DFHSM QUESTION To: "IBM Mainframe Discussion List" <IBM-MAIN@LISTSERV.UA.EDU> Received: Friday, July 28, 2017, 12:33 PM Lizette, I have taken note of your suggestion and I will adhere to it. I checked my command and it shows that all the contents of the command is as follows as suggested by Brian: HSEND AUDIT DSCTL(BACKUP) FIX. I didn't have BDELETE or anyother parm in the command. I am not sure why HSM is complaining that the command contained these parms. On Fri, 7/28/17, Lizette Koehler <stars...@mindspring.com> wrote: Subject: Re: DFHSM QUESTION To: IBM-MAIN@LISTSERV.UA.EDU Received: Friday, July 28, 2017, 10:01 AM Willie It would be helpful to include just on pair of COMMAND and RESPONSE rather than all of your error messages. Without the context of what command syntax you entered, it is difficult to assist you. Next. For this message: ARC0085I (H)BDELETE REQUIRES ONE OF THE FOLLOWING MUTUALLY EXCLUSIVE KEYWORDS: ARC0085I (CONT.) ALL, VERSIONS, OR DATE It appears that when you entered the BDELETE command you did not include the subparm of ALL VERSIONS or DATE Please review this process and ensure you are entering the command according to the DFHSM Admin Guide Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of willie bunter > Sent: Friday, July 28, 2017 6:33 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: DFHSM QUESTION > > Brian, > > I tried your suggestion unfortunately it didn't get rid of the ERR 40. Here > is the message that was sent to my terminal: > > ARC0085I (H)BDELETE REQUIRES ONE OF THE FOLLOWING MUTUALLY EXCLUSIVE > KEYWORDS: > ARC0085I (CONT.) ALL, VERSIONS, OR DATE > ARC0085I (H)BDELETE REQUIRES ONE OF THE FOLLOWING MUTUALLY EXCLUSIVE > KEYWORDS: > ARC0085I (CONT.) ALL, VERSIONS, OR DATE > ARC0085I (H)BDELETE REQUIRES ONE OF THE FOLLOWING MUTUALLY EXCLUSIVE > KEYWORDS: > ARC0085I (CONT.) ALL, VERSIONS, OR DATE > ARC0085I (H)BDELETE REQUIRES ONE OF THE FOLLOWING MUTUALLY EXCLUSIVE > KEYWORDS: > ARC0085I (CONT.) ALL, VERSIONS, OR DATE > ARC0085I (H)BDELETE REQUIRES ONE OF THE FOLLOWING MUTUALLY EXCLUSIVE > KEYWORDS: > ARC0085I (CONT.) ALL, VERSIONS, OR DATE > ARC0085I (H)BDELETE REQUIRES ONE OF THE FOLLOWING MUTUALLY EXCLUSIVE > KEYWORDS: > ARC0085I (CONT.) ALL, VERSIONS, OR DATE > ARC0085I (H)BDELETE REQUIRES ONE OF THE FOLLOWING MUTUALLY EXCLUSIVE > KEYWORDS: > ARC0085I (CONT.) ALL, VERSIONS, OR DATE > ARC0085I (H)BDELETE REQUIRES ONE OF THE FOLLOWING MUTUALLY EXCLUSIVE > KEYWORDS: > ARC0085I (CONT.) ALL, VERSIONS, OR DATE > ARC0085I (H)BDELETE REQUIRES ONE OF THE FOLLOWING MUTUALLY EXCLUSIVE > KEYWORDS: > ARC0085I (CONT.) ALL, VERSIONS, OR DATE > > Below is a sample of the output. > /* ERR 40 DB2.ARCHLOG2.A0091613 HSMBACK.BACK.T592617.DB2.ARCHLOG2.I8257 > MISSING > /* FIXCDS B DUMMY.RECOVER.MCB CREATE(X'0014' X'0098257F') > /* FIXCDS B DUMMY.RECOVER.MCB PATCH(X'002E' BITS(1.1.)) > /* FIXCDS B DUMMY.RECOVER.MCB PATCH(X'0030' X'000100010001') > /* FIXCDS B DUMMY.RECOVER.MCB EXPAND(X'0040') > /* FIXCDS B DUMMY.RECOVER.MCB PATCH(X'0050' + > /* > X'404040404040404040404040404040404040404040404040404040404040404040404040404 > 0404040404040') > /* FIXCDS B DUMMY.RECOVER.MCB PATCH(X'0050' > HSMBACK.BACK.T592617.DB2.ARCHLOG2.I8257) > /* FIXCDS B DUMMY.RECOVER.MCB PATCH(X'0082' BITS(0110)) > /* BDELETE DUMMY.RECOVER.MCB > /* MSG 914 - ERROR ON BDELETE COMMAND > /* MSG 998 - AUDIT CONTINUING, SEE COMMAND ACTIVITY LOG > /* FIXCDS B DUMMY.RECOVER.MCB DELETE > - END OF - ENHANCED AUDIT - LISTING - > > > On Thu, 7/27/17, Brian Fraser <brianmfra...@gmail.com> wrote: > > Subject: Re: DFHSM QUESTION > To: IBM-MAIN@LISTSERV.UA.EDU > Received: Thursday, July 27, 2017, 9:18 PM > > HSEND AUDIT DSCTL
Re: DFHSM QUESTION
Note the description in the manual for DFHSM AUDIT AUDIT usually identifies a repair (and takes repair action when FIX is specified) for error messages (*ERR) 30, 35, 36, 40, 41, 42, 43, 44, and 46. AUDIT recommends an additional diagnostic step for error messages (*ERR) 17 if the backup tape involved is a volume written in single file format. If you want AUDIT to continue its attempt to identify a repair action, you must specify an additional AUDIT command using the recommended parameter. For other reported conditions, see Error codes (*ERR) and diagnosis for some troubleshooting hints. It usually does the repair. Which tells me sometimes it cannot. If you need to remove these errors, you may need to open an SR with IBM HSM Level two for further assistance. It could be that in all of the commands that have been entered, something may have been broken links in the xCDS Datasets. And IBM should be able to help you. Anything the list provides may cause further issues in your xCDS datasets. Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of willie bunter > Sent: Friday, July 28, 2017 9:34 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: DFHSM QUESTION > > Lizette, > > I have taken note of your suggestion and I will adhere to it. > I checked my command and it shows that all the contents of the command is as > follows as suggested by Brian: HSEND AUDIT DSCTL(BACKUP) FIX. > > I didn't have BDELETE or anyother parm in the command. I am not sure why HSM > is complaining that the command contained these parms. > > > On Fri, 7/28/17, Lizette Koehler <stars...@mindspring.com> wrote: > > Subject: Re: DFHSM QUESTION > To: IBM-MAIN@LISTSERV.UA.EDU > Received: Friday, July 28, 2017, 10:01 AM > > Willie > > It would be helpful to include just on > pair of COMMAND and RESPONSE rather than all of your error > messages. Without the context of what command syntax you entered, it is > difficult to assist you. > > Next. > > For this message: > > ARC0085I (H)BDELETE REQUIRES ONE OF THE FOLLOWING MUTUALLY EXCLUSIVE > KEYWORDS: > ARC0085I (CONT.) ALL, VERSIONS, OR > DATE > > > > It appears that when you entered the > BDELETE command you did not include the subparm of ALL VERSIONS or DATE > > Please review this process and ensure > you are entering the command according to the DFHSM Admin Guide > > Lizette > > > > -Original Message- > > From: IBM Mainframe Discussion > List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On > > Behalf Of willie bunter > > Sent: Friday, July 28, 2017 6:33 > AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: DFHSM QUESTION > > > > Brian, > > > > I tried your suggestion > unfortunately it didn't get rid of the ERR 40. Here > is the message that > was sent to my > terminal: > > > > ARC0085I (H)BDELETE REQUIRES ONE > OF THE FOLLOWING MUTUALLY EXCLUSIVE > > KEYWORDS: > > ARC0085I (CONT.) ALL, VERSIONS, OR > DATE > > ARC0085I (H)BDELETE REQUIRES ONE > OF THE FOLLOWING MUTUALLY EXCLUSIVE > > KEYWORDS: > > ARC0085I (CONT.) ALL, VERSIONS, OR > DATE > > ARC0085I (H)BDELETE REQUIRES ONE > OF THE FOLLOWING MUTUALLY EXCLUSIVE > > KEYWORDS: > > ARC0085I (CONT.) ALL, VERSIONS, OR > DATE > > ARC0085I (H)BDELETE REQUIRES ONE > OF THE FOLLOWING MUTUALLY EXCLUSIVE > > KEYWORDS: > > ARC0085I (CONT.) ALL, VERSIONS, OR > DATE > > ARC0085I (H)BDELETE REQUIRES ONE > OF THE FOLLOWING MUTUALLY EXCLUSIVE > > KEYWORDS: > > ARC0085I (CONT.) ALL, VERSIONS, OR > DATE > > ARC0085I (H)BDELETE REQUIRES ONE > OF THE FOLLOWING MUTUALLY EXCLUSIVE > > KEYWORDS: > > ARC0085I (CONT.) ALL, VERSIONS, OR > DATE > > ARC0085I (H)BDELETE REQUIRES ONE > OF THE FOLLOWING MUTUALLY EXCLUSIVE > > KEYWORDS: > > ARC0085I (CONT.) ALL, VERSIONS, OR > DATE > > ARC0085I (H)BDELETE REQUIRES ONE > OF THE FOLLOWING MUTUALLY EXCLUSIVE > > KEYWORDS: > > ARC0085I (CONT.) ALL, VERSIONS, OR > DATE > > ARC0085I (H)BDELETE REQUIRES ONE > OF THE FOLLOWING MUTUALLY EXCLUSIVE > > KEYWORDS: > > ARC0085I (CONT.) ALL, VERSIONS, OR > DATE > > > > Below is a sample of the output. > > /* ERR 40 DB2.ARCHLOG2.A0091613 > HSMBACK.BACK.T592617.DB2.ARCHLOG2.I8257 > > MISSING > > /* FIXCDS B DUMMY.RECOVER.MCB > CREATE(X'0014' X'0098257F') > > /* FIXCDS B DUMMY.RECOVER.MCB > PATCH(X'002E' BITS(1.1.)) > > /
Re: DFHSM QUESTION
Stop/Start DFHSM and end the confusion is to which command is getting which response by starting fresh. The reissue the AUDIT with the FIX option. If the error is still there, show both the command and the output > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of willie bunter > Sent: Friday, July 28, 2017 9:34 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: DFHSM QUESTION > > Lizette, > > I have taken note of your suggestion and I will adhere to it. > I checked my command and it shows that all the contents of the command is > as follows as suggested by Brian: HSEND AUDIT DSCTL(BACKUP) FIX. > > I didn't have BDELETE or anyother parm in the command. I am not sure why > HSM is complaining that the command contained these parms. > > > On Fri, 7/28/17, Lizette Koehler <stars...@mindspring.com> wrote: > > Subject: Re: DFHSM QUESTION > To: IBM-MAIN@LISTSERV.UA.EDU > Received: Friday, July 28, 2017, 10:01 AM > > Willie > > It would be helpful to include just on > pair of COMMAND and RESPONSE rather than all of your error > messages. Without the context of what command syntax you entered, it is > difficult to assist you. > > Next. > > For this message: > > ARC0085I (H)BDELETE REQUIRES ONE OF THE FOLLOWING MUTUALLY > EXCLUSIVE KEYWORDS: > ARC0085I (CONT.) ALL, VERSIONS, OR > DATE > > > > It appears that when you entered the > BDELETE command you did not include the subparm of ALL VERSIONS or > DATE > > Please review this process and ensure > you are entering the command according to the DFHSM Admin Guide > > Lizette > > > > -Original Message- > > From: IBM Mainframe Discussion > List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On > > Behalf Of willie bunter > > Sent: Friday, July 28, 2017 6:33 > AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: DFHSM QUESTION > > > > Brian, > > > > I tried your suggestion > unfortunately it didn't get rid of the ERR 40. Here > is the message that > was > sent to my > terminal: > > > > ARC0085I (H)BDELETE REQUIRES ONE > OF THE FOLLOWING MUTUALLY EXCLUSIVE > > KEYWORDS: > > ARC0085I (CONT.) ALL, VERSIONS, OR > DATE > > ARC0085I (H)BDELETE REQUIRES ONE > OF THE FOLLOWING MUTUALLY EXCLUSIVE > > KEYWORDS: > > ARC0085I (CONT.) ALL, VERSIONS, OR > DATE > > ARC0085I (H)BDELETE REQUIRES ONE > OF THE FOLLOWING MUTUALLY EXCLUSIVE > > KEYWORDS: > > ARC0085I (CONT.) ALL, VERSIONS, OR > DATE > > ARC0085I (H)BDELETE REQUIRES ONE > OF THE FOLLOWING MUTUALLY EXCLUSIVE > > KEYWORDS: > > ARC0085I (CONT.) ALL, VERSIONS, OR > DATE > > ARC0085I (H)BDELETE REQUIRES ONE > OF THE FOLLOWING MUTUALLY EXCLUSIVE > > KEYWORDS: > > ARC0085I (CONT.) ALL, VERSIONS, OR > DATE > > ARC0085I (H)BDELETE REQUIRES ONE > OF THE FOLLOWING MUTUALLY EXCLUSIVE > > KEYWORDS: > > ARC0085I (CONT.) ALL, VERSIONS, OR > DATE > > ARC0085I (H)BDELETE REQUIRES ONE > OF THE FOLLOWING MUTUALLY EXCLUSIVE > > KEYWORDS: > > ARC0085I (CONT.) ALL, VERSIONS, OR > DATE > > ARC0085I (H)BDELETE REQUIRES ONE > OF THE FOLLOWING MUTUALLY EXCLUSIVE > > KEYWORDS: > > ARC0085I (CONT.) ALL, VERSIONS, OR > DATE > > ARC0085I (H)BDELETE REQUIRES ONE > OF THE FOLLOWING MUTUALLY EXCLUSIVE > > KEYWORDS: > > ARC0085I (CONT.) ALL, VERSIONS, OR > DATE > > > > Below is a sample of the output. > > /* ERR 40 DB2.ARCHLOG2.A0091613 > HSMBACK.BACK.T592617.DB2.ARCHLOG2.I8257 > > MISSING > > /* FIXCDS B DUMMY.RECOVER.MCB > CREATE(X'0014' X'0098257F') > > /* FIXCDS B DUMMY.RECOVER.MCB > PATCH(X'002E' BITS(1.1.)) > > /* FIXCDS B DUMMY.RECOVER.MCB > PATCH(X'0030' X'000100010001') > > /* FIXCDS B DUMMY.RECOVER.MCB > EXPAND(X'0040') > > /* FIXCDS B DUMMY.RECOVER.MCB > PATCH(X'0050' + > > /* > > > > X'40404040404040404040404040404040404040404040404040404040404040404 > 0404040404 > > 0404040404040') > > /* FIXCDS B DUMMY.RECOVER.MCB > PATCH(X'0050' > > > HSMBACK.BACK.T592617.DB2.ARCHLOG2.I8257) > > /* FIXCDS B DUMMY.RECOVER.MCB > PATCH(X'0082' BITS(0110)) > > /* BDELETE DUMMY.RECOVER.MCB > > /* MSG 914 - ERROR ON BDELETE > COMMAND > > /* MSG 998 - AUDIT CONTINUING, SEE > COMMAND ACTIVITY LOG > > /* FIXCDS B DUM
Re: DFHSM QUESTION
Lizette,
I have taken note of your suggestion and I will adhere to it.
I checked my command and it shows that all the contents of the command is as
follows as suggested by Brian: HSEND AUDIT DSCTL(BACKUP) FIX.
I didn't have BDELETE or anyother parm in the command. I am not sure why HSM
is complaining that the command contained these parms.
On Fri, 7/28/17, Lizette Koehler <stars...@mindspring.com> wrote:
Subject: Re: DFHSM QUESTION
To: IBM-MAIN@LISTSERV.UA.EDU
Received: Friday, July 28, 2017, 10:01 AM
Willie
It would be helpful to include just on
pair of COMMAND and RESPONSE rather than all of your error
messages. Without the context of what command syntax
you entered, it is difficult to assist you.
Next.
For this message:
ARC0085I (H)BDELETE REQUIRES ONE OF THE
FOLLOWING MUTUALLY EXCLUSIVE KEYWORDS:
ARC0085I (CONT.) ALL, VERSIONS, OR
DATE
It appears that when you entered the
BDELETE command you did not include the subparm of ALL
VERSIONS or DATE
Please review this process and ensure
you are entering the command according to the DFHSM Admin
Guide
Lizette
> -Original Message-
> From: IBM Mainframe Discussion
List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On
> Behalf Of willie bunter
> Sent: Friday, July 28, 2017 6:33
AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: DFHSM QUESTION
>
> Brian,
>
> I tried your suggestion
unfortunately it didn't get rid of the ERR 40. Here
> is the message that was sent to my
terminal:
>
> ARC0085I (H)BDELETE REQUIRES ONE
OF THE FOLLOWING MUTUALLY EXCLUSIVE
> KEYWORDS:
> ARC0085I (CONT.) ALL, VERSIONS, OR
DATE
> ARC0085I (H)BDELETE REQUIRES ONE
OF THE FOLLOWING MUTUALLY EXCLUSIVE
> KEYWORDS:
> ARC0085I (CONT.) ALL, VERSIONS, OR
DATE
> ARC0085I (H)BDELETE REQUIRES ONE
OF THE FOLLOWING MUTUALLY EXCLUSIVE
> KEYWORDS:
> ARC0085I (CONT.) ALL, VERSIONS, OR
DATE
> ARC0085I (H)BDELETE REQUIRES ONE
OF THE FOLLOWING MUTUALLY EXCLUSIVE
> KEYWORDS:
> ARC0085I (CONT.) ALL, VERSIONS, OR
DATE
> ARC0085I (H)BDELETE REQUIRES ONE
OF THE FOLLOWING MUTUALLY EXCLUSIVE
> KEYWORDS:
> ARC0085I (CONT.) ALL, VERSIONS, OR
DATE
> ARC0085I (H)BDELETE REQUIRES ONE
OF THE FOLLOWING MUTUALLY EXCLUSIVE
> KEYWORDS:
> ARC0085I (CONT.) ALL, VERSIONS, OR
DATE
> ARC0085I (H)BDELETE REQUIRES ONE
OF THE FOLLOWING MUTUALLY EXCLUSIVE
> KEYWORDS:
> ARC0085I (CONT.) ALL, VERSIONS, OR
DATE
> ARC0085I (H)BDELETE REQUIRES ONE
OF THE FOLLOWING MUTUALLY EXCLUSIVE
> KEYWORDS:
> ARC0085I (CONT.) ALL, VERSIONS, OR
DATE
> ARC0085I (H)BDELETE REQUIRES ONE
OF THE FOLLOWING MUTUALLY EXCLUSIVE
> KEYWORDS:
> ARC0085I (CONT.) ALL, VERSIONS, OR
DATE
>
> Below is a sample of the output.
> /* ERR 40 DB2.ARCHLOG2.A0091613
HSMBACK.BACK.T592617.DB2.ARCHLOG2.I8257
> MISSING
> /* FIXCDS B DUMMY.RECOVER.MCB
CREATE(X'0014' X'0098257F')
> /* FIXCDS B DUMMY.RECOVER.MCB
PATCH(X'002E' BITS(1.1.))
> /* FIXCDS B DUMMY.RECOVER.MCB
PATCH(X'0030' X'000100010001')
> /* FIXCDS B DUMMY.RECOVER.MCB
EXPAND(X'0040')
> /* FIXCDS B DUMMY.RECOVER.MCB
PATCH(X'0050' +
> /*
>
X'404040404040404040404040404040404040404040404040404040404040404040404040404
> 0404040404040')
> /* FIXCDS B DUMMY.RECOVER.MCB
PATCH(X'0050'
>
HSMBACK.BACK.T592617.DB2.ARCHLOG2.I8257)
> /* FIXCDS B DUMMY.RECOVER.MCB
PATCH(X'0082' BITS(0110))
> /* BDELETE DUMMY.RECOVER.MCB
> /* MSG 914 - ERROR ON BDELETE
COMMAND
> /* MSG 998 - AUDIT CONTINUING, SEE
COMMAND ACTIVITY LOG
> /* FIXCDS B DUMMY.RECOVER.MCB
DELETE
> - END OF - ENHANCED
AUDIT - LISTING -
>
>
> On Thu, 7/27/17, Brian Fraser
<brianmfra...@gmail.com>
wrote:
>
> Subject: Re: DFHSM QUESTION
> To: IBM-MAIN@LISTSERV.UA.EDU
> Received: Thursday, July 27,
2017, 9:18 PM
>
> HSEND AUDIT DSCTL(BACKUP)
FIX
>
ODS('dsn.for.output.listing')
> is
> what you should run.
>
>
> On Fri, Jul 28, 2017 at 2:56
AM, Horne, Patti <patti.ho...@fisglobal.com>
> wrote:
>
> >
> You ran the fix on the
BDELETE not the AUDIT.
> >
> >
> >
--
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
Re: DFHSM QUESTION
Willie
It would be helpful to include just on pair of COMMAND and RESPONSE rather than
all of your error messages. Without the context of what command syntax you
entered, it is difficult to assist you.
Next.
For this message:
ARC0085I (H)BDELETE REQUIRES ONE OF THE FOLLOWING MUTUALLY EXCLUSIVE KEYWORDS:
ARC0085I (CONT.) ALL, VERSIONS, OR DATE
It appears that when you entered the BDELETE command you did not include the
subparm of ALL VERSIONS or DATE
Please review this process and ensure you are entering the command according to
the DFHSM Admin Guide
Lizette
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of willie bunter
> Sent: Friday, July 28, 2017 6:33 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: DFHSM QUESTION
>
> Brian,
>
> I tried your suggestion unfortunately it didn't get rid of the ERR 40. Here
> is the message that was sent to my terminal:
>
> ARC0085I (H)BDELETE REQUIRES ONE OF THE FOLLOWING MUTUALLY EXCLUSIVE
> KEYWORDS:
> ARC0085I (CONT.) ALL, VERSIONS, OR DATE
> ARC0085I (H)BDELETE REQUIRES ONE OF THE FOLLOWING MUTUALLY EXCLUSIVE
> KEYWORDS:
> ARC0085I (CONT.) ALL, VERSIONS, OR DATE
> ARC0085I (H)BDELETE REQUIRES ONE OF THE FOLLOWING MUTUALLY EXCLUSIVE
> KEYWORDS:
> ARC0085I (CONT.) ALL, VERSIONS, OR DATE
> ARC0085I (H)BDELETE REQUIRES ONE OF THE FOLLOWING MUTUALLY EXCLUSIVE
> KEYWORDS:
> ARC0085I (CONT.) ALL, VERSIONS, OR DATE
> ARC0085I (H)BDELETE REQUIRES ONE OF THE FOLLOWING MUTUALLY EXCLUSIVE
> KEYWORDS:
> ARC0085I (CONT.) ALL, VERSIONS, OR DATE
> ARC0085I (H)BDELETE REQUIRES ONE OF THE FOLLOWING MUTUALLY EXCLUSIVE
> KEYWORDS:
> ARC0085I (CONT.) ALL, VERSIONS, OR DATE
> ARC0085I (H)BDELETE REQUIRES ONE OF THE FOLLOWING MUTUALLY EXCLUSIVE
> KEYWORDS:
> ARC0085I (CONT.) ALL, VERSIONS, OR DATE
> ARC0085I (H)BDELETE REQUIRES ONE OF THE FOLLOWING MUTUALLY EXCLUSIVE
> KEYWORDS:
> ARC0085I (CONT.) ALL, VERSIONS, OR DATE
> ARC0085I (H)BDELETE REQUIRES ONE OF THE FOLLOWING MUTUALLY EXCLUSIVE
> KEYWORDS:
> ARC0085I (CONT.) ALL, VERSIONS, OR DATE
>
> Below is a sample of the output.
> /* ERR 40 DB2.ARCHLOG2.A0091613 HSMBACK.BACK.T592617.DB2.ARCHLOG2.I8257
> MISSING
> /* FIXCDS B DUMMY.RECOVER.MCB CREATE(X'0014' X'0098257F')
> /* FIXCDS B DUMMY.RECOVER.MCB PATCH(X'002E' BITS(1.1.))
> /* FIXCDS B DUMMY.RECOVER.MCB PATCH(X'0030' X'000100010001')
> /* FIXCDS B DUMMY.RECOVER.MCB EXPAND(X'0040')
> /* FIXCDS B DUMMY.RECOVER.MCB PATCH(X'0050' +
> /*
> X'404040404040404040404040404040404040404040404040404040404040404040404040404
> 0404040404040')
> /* FIXCDS B DUMMY.RECOVER.MCB PATCH(X'0050'
> HSMBACK.BACK.T592617.DB2.ARCHLOG2.I8257)
> /* FIXCDS B DUMMY.RECOVER.MCB PATCH(X'0082' BITS(0110))
> /* BDELETE DUMMY.RECOVER.MCB
> /* MSG 914 - ERROR ON BDELETE COMMAND
> /* MSG 998 - AUDIT CONTINUING, SEE COMMAND ACTIVITY LOG
> /* FIXCDS B DUMMY.RECOVER.MCB DELETE
> - END OF - ENHANCED AUDIT - LISTING -
>
>
> On Thu, 7/27/17, Brian Fraser <brianmfra...@gmail.com> wrote:
>
> Subject: Re: DFHSM QUESTION
> To: IBM-MAIN@LISTSERV.UA.EDU
> Received: Thursday, July 27, 2017, 9:18 PM
>
> HSEND AUDIT DSCTL(BACKUP) FIX
> ODS('dsn.for.output.listing')
> is
> what you should run.
>
>
> On Fri, Jul 28, 2017 at 2:56 AM, Horne, Patti <patti.ho...@fisglobal.com>
> wrote:
>
> >
> You ran the fix on the BDELETE not the AUDIT.
> >
> >
> >
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION
Brian,
I tried your suggestion unfortunately it didn't get rid of the ERR 40. Here is
the message that was sent to my terminal:
ARC0085I (H)BDELETE REQUIRES ONE OF THE FOLLOWING MUTUALLY EXCLUSIVE KEYWORDS:
ARC0085I (CONT.) ALL, VERSIONS, OR DATE
ARC0085I (H)BDELETE REQUIRES ONE OF THE FOLLOWING MUTUALLY EXCLUSIVE KEYWORDS:
ARC0085I (CONT.) ALL, VERSIONS, OR DATE
ARC0085I (H)BDELETE REQUIRES ONE OF THE FOLLOWING MUTUALLY EXCLUSIVE KEYWORDS:
ARC0085I (CONT.) ALL, VERSIONS, OR DATE
ARC0085I (H)BDELETE REQUIRES ONE OF THE FOLLOWING MUTUALLY EXCLUSIVE KEYWORDS:
ARC0085I (CONT.) ALL, VERSIONS, OR DATE
ARC0085I (H)BDELETE REQUIRES ONE OF THE FOLLOWING MUTUALLY EXCLUSIVE KEYWORDS:
ARC0085I (CONT.) ALL, VERSIONS, OR DATE
ARC0085I (H)BDELETE REQUIRES ONE OF THE FOLLOWING MUTUALLY EXCLUSIVE KEYWORDS:
ARC0085I (CONT.) ALL, VERSIONS, OR DATE
ARC0085I (H)BDELETE REQUIRES ONE OF THE FOLLOWING MUTUALLY EXCLUSIVE KEYWORDS:
ARC0085I (CONT.) ALL, VERSIONS, OR DATE
ARC0085I (H)BDELETE REQUIRES ONE OF THE FOLLOWING MUTUALLY EXCLUSIVE KEYWORDS:
ARC0085I (CONT.) ALL, VERSIONS, OR DATE
ARC0085I (H)BDELETE REQUIRES ONE OF THE FOLLOWING MUTUALLY EXCLUSIVE KEYWORDS:
ARC0085I (CONT.) ALL, VERSIONS, OR DATE
Below is a sample of the output.
/* ERR 40 DB2.ARCHLOG2.A0091613 HSMBACK.BACK.T592617.DB2.ARCHLOG2.I8257 MISSING
/* FIXCDS B DUMMY.RECOVER.MCB CREATE(X'0014' X'0098257F')
/* FIXCDS B DUMMY.RECOVER.MCB PATCH(X'002E' BITS(1.1.))
/* FIXCDS B DUMMY.RECOVER.MCB PATCH(X'0030' X'000100010001')
/* FIXCDS B DUMMY.RECOVER.MCB EXPAND(X'0040')
/* FIXCDS B DUMMY.RECOVER.MCB PATCH(X'0050' +
/*
X'4040404040404040404040404040404040404040404040404040404040404040404040404040404040404040')
/* FIXCDS B DUMMY.RECOVER.MCB PATCH(X'0050'
HSMBACK.BACK.T592617.DB2.ARCHLOG2.I8257)
/* FIXCDS B DUMMY.RECOVER.MCB PATCH(X'0082' BITS(0110))
/* BDELETE DUMMY.RECOVER.MCB
/* MSG 914 - ERROR ON BDELETE COMMAND
/* MSG 998 - AUDIT CONTINUING, SEE COMMAND ACTIVITY LOG
/* FIXCDS B DUMMY.RECOVER.MCB DELETE
- END OF - ENHANCED AUDIT - LISTING -
On Thu, 7/27/17, Brian Fraser <brianmfra...@gmail.com> wrote:
Subject: Re: DFHSM QUESTION
To: IBM-MAIN@LISTSERV.UA.EDU
Received: Thursday, July 27, 2017, 9:18 PM
HSEND AUDIT DSCTL(BACKUP) FIX
ODS('dsn.for.output.listing')
is
what you should run.
On Fri, Jul 28, 2017 at 2:56 AM, Horne, Patti
<patti.ho...@fisglobal.com>
wrote:
>
You ran the fix on the BDELETE not the AUDIT.
>
>
>
>
>
-Original Message-
> From: IBM
Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On
> Behalf Of willie bunter
> Sent: Thursday, July 27, 2017 11:23 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: DFHSM QUESTION
>
> I ran the FIX and the
following messages were received :
>
> ARC0085I (H)BDELETE REQUIRES ONE OF THE
FOLLOWING MUTUALLY EXCLUSIVE
>
KEYWORDS:
> ARC0085I (CONT.) ALL,
VERSIONS, OR DATE
> ARC0085I (H)BDELETE
REQUIRES ONE OF THE FOLLOWING MUTUALLY EXCLUSIVE
> KEYWORDS:
> ARC0085I
(CONT.) ALL, VERSIONS, OR DATE
> ARC0085I
(H)BDELETE REQUIRES ONE OF THE FOLLOWING MUTUALLY
EXCLUSIVE
> KEYWORDS:
> ARC0085I (CONT.) ALL, VERSIONS, OR DATE
> ARC0085I (H)BDELETE REQUIRES ONE OF THE
FOLLOWING MUTUALLY EXCLUSIVE
>
KEYWORDS:
> ARC0085I (CONT.) ALL,
VERSIONS, OR DATE
> ARC0085I (H)BDELETE
REQUIRES ONE OF THE FOLLOWING MUTUALLY EXCLUSIVE
> KEYWORDS:
> ARC0085I
(CONT.) ALL, VERSIONS, OR DATE
> ARC0085I
(H)BDELETE REQUIRES ONE OF THE FOLLOWING MUTUALLY
EXCLUSIVE
> KEYWORDS:
> ARC0085I (CONT.) ALL, VERSIONS, OR DATE
> ARC0085I (H)BDELETE REQUIRES ONE OF THE
FOLLOWING MUTUALLY EXCLUSIVE
>
KEYWORDS:
> ARC0085I (CONT.) ALL,
VERSIONS, OR DATE
> ARC0085I (H)BDELETE
REQUIRES ONE OF THE FOLLOWING MUTUALLY EXCLUSIVE
> KEYWORDS:
> ARC0085I
(CONT.) ALL, VERSIONS, OR DATE
>
> Below is my command
>
HSEND AUDIT DATASETCONTROLS(BACKUP) FIX -
>
ODS(SYS2.AUDIT.DATASET.CONTROLS.BCDS.FIX.#2)
>
> On Thu, 7/27/17, Horne, Patti <patti.ho...@fisglobal.com>
wrote:
>
> Subject:
Re: DFHSM QUESTION
> To: IBM-MAIN@LISTSER
Re: DFHSM QUESTION
Brian,
I did that but it didn't clear the ERR 40 records (see below for an example of
the message). Thanks for the suggestion however.
/* ERR 40 DB2.ARCHLOG2.A0091613 HSMBACK.BACK.T592617.DB2.ARCHLOG2.I8257 MISSING
/* FIXCDS B DUMMY.RECOVER.MCB CREATE(X'0014' X'0098257F')
/* FIXCDS B DUMMY.RECOVER.MCB PATCH(X'002E' BITS(1.1.))
/* FIXCDS B DUMMY.RECOVER.MCB PATCH(X'0030' X'000100010001')
/* FIXCDS B DUMMY.RECOVER.MCB EXPAND(X'0040')
/* FIXCDS B DUMMY.RECOVER.MCB PATCH(X'0050' +
/* X'404040404040404040404040404040404040404040404040404040404040404040404040404
/* FIXCDS B DUMMY.RECOVER.MCB PATCH(X'0050' HSMBACK.BACK.T592617.DB2.ARCHLOG
/* FIXCDS B DUMMY.RECOVER.MCB PATCH(X'0082' BITS(0110))
/* BDELETE DUMMY.RECOVER.MCB
/* MSG 914 - ERROR ON BDELETE COMMAND
/* MSG 998 - AUDIT CONTINUING, SEE COMMAND ACTIVITY LOG
/* FIXCDS B DUMMY.RECOVER.MCB DELETE
- END OF - ENHANCED AUDIT - LISTING -
On Thu, 7/27/17, Brian Fraser <brianmfra...@gmail.com> wrote:
Subject: Re: DFHSM QUESTION
To: IBM-MAIN@LISTSERV.UA.EDU
Received: Thursday, July 27, 2017, 10:31 PM
If you run the audit command with
the FIX parameter, then it should delete
any
orphaned C records without a matching B record.
Brian
On Fri, Jul 28, 2017 at 12:11 AM, willie bunter
<
001409bd2345-dmarc-requ...@listserv.ua.edu>
wrote:
> Should I ignore
the ERR 40 when I run the AUDIT report?
>
>
> On Thu, 7/27/17, Lizette Koehler <stars...@mindspring.com>
wrote:
>
> Subject:
Re: DFHSM QUESTION
> To: IBM-MAIN@LISTSERV.UA.EDU
> Received: Thursday, July 27, 2017, 12:06
PM
>
> So is
everything is correct
> now?
>
> Or do you have
more
> questions.
>
> Otherwise I
> think your issues are resolved.
>
> Lizette
>
>
> >
>
-Original Message-
> > From:
IBM
> Mainframe Discussion List
[mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On
> > Behalf Of
willie bunter
> > Sent: Thursday,
July 27, 2017 8:58 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: DFHSM QUESTION
> >
> > I tried
out the
> BDELETE and as expected the
record was not found.
> >
> > ARC0195I TYPE B, KEY
> DB2.ARCHLOG2.A0091613, FIXCDS DELETE,
ERROR=RECORD NOT
> > ARC0195I
(CONT.) FOUND
> > ARC1001I FIXCDS B
DB2.ARCHLOG2.A0091613
> DELETE COMMAND
FAILED, RC=0015,
> >
> ARC1001I (CONT.) REAS=
> > ARC1615I
>
FIXCDS COMMAND REJECTED
> >
> > Below is the HLIST:
> >
> ARC0138I NO
BCDS INFORMATION FOUND FOR DATASET
>
DB2.ARCHLOG2.A0091613
> >
>
> > On Thu, 7/27/17, Lizette Koehler
<stars...@mindspring.com>
> wrote:
> >
> > Subject:
>
Re: DFHSM QUESTION
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Received: Thursday, July 27,
2017, 10:52
> AM
>
>
> > At this
> point, just take one step
> > back.
>
>
> > You wanted to
> delete
> > a
backup version from HSM.
> >
> > The dataset is
> either DB2.ARCHLOG2.A0091613 or
> DB96.ARCHLOG2.B778
> >
> > Issue
an HLIST
> >
>
DSN('DB96.ARCHLOG2.B778') BCDS or
HLIST
>
DSN('DB2.ARCHLOG2.A0091613
> >
')
> BCDS
>
>
> >
>
> If you do not
> > see
> any backup datasets listed for these
datasets, then you
> have deleted
> > the backup copies.
> >
> > If
you still see
> BCDS entries, then you
may need to do more BDELETE
> >
commands.
> >
>
> AUDIT is used to verify content in
> HSM. However, it may create
confusion
> >
>
with its results.
> >
> > I rarely use AUDIT. If the
> > BDELETE works or there are no
longer any
> BCDS entries, I will not
issue
> > AUDIT
> commands.
> >
> >
> > If
you could provide the
> >
description of the problem you are
>
trying to solve with BDELETE and AUDIT,
> > that will be helpful.
> >
>
> > From what you have posted so
far,
> the BDELETE looks like it was
successful
> > at some point.
> >
> >
> > For furth
Re: DFHSM QUESTION
If you run the audit command with the FIX parameter, then it should delete
any orphaned C records without a matching B record.
Brian
On Fri, Jul 28, 2017 at 12:11 AM, willie bunter <
001409bd2345-dmarc-requ...@listserv.ua.edu> wrote:
> Should I ignore the ERR 40 when I run the AUDIT report?
>
>
> On Thu, 7/27/17, Lizette Koehler <stars...@mindspring.com> wrote:
>
> Subject: Re: DFHSM QUESTION
> To: IBM-MAIN@LISTSERV.UA.EDU
> Received: Thursday, July 27, 2017, 12:06 PM
>
> So is everything is correct
> now?
>
> Or do you have more
> questions.
>
> Otherwise I
> think your issues are resolved.
>
> Lizette
>
>
> >
> -Original Message-
> > From: IBM
> Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On
> > Behalf Of willie bunter
> > Sent: Thursday, July 27, 2017 8:58 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: DFHSM QUESTION
> >
> > I tried out the
> BDELETE and as expected the record was not found.
> >
> > ARC0195I TYPE B, KEY
> DB2.ARCHLOG2.A0091613, FIXCDS DELETE, ERROR=RECORD NOT
> > ARC0195I (CONT.) FOUND
> > ARC1001I FIXCDS B DB2.ARCHLOG2.A0091613
> DELETE COMMAND FAILED, RC=0015,
> >
> ARC1001I (CONT.) REAS=
> > ARC1615I
> FIXCDS COMMAND REJECTED
> >
> > Below is the HLIST:
> >
> ARC0138I NO BCDS INFORMATION FOUND FOR DATASET
> DB2.ARCHLOG2.A0091613
> >
>
> > On Thu, 7/27/17, Lizette Koehler <stars...@mindspring.com>
> wrote:
> >
> > Subject:
> Re: DFHSM QUESTION
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Received: Thursday, July 27, 2017, 10:52
> AM
> >
> > At this
> point, just take one step
> > back.
> >
> > You wanted to
> delete
> > a backup version from HSM.
> >
> > The dataset is
> either DB2.ARCHLOG2.A0091613 or
> DB96.ARCHLOG2.B778
> >
> > Issue an HLIST
> >
> DSN('DB96.ARCHLOG2.B778') BCDSor HLIST
> DSN('DB2.ARCHLOG2.A0091613
> > ')
> BCDS
> >
> >
> > If you do not
> > see
> any backup datasets listed for these datasets, then you
> have deleted
> > the backup copies.
> >
> > If you still see
> BCDS entries, then you may need to do more BDELETE
> > commands.
> >
> > AUDIT is used to verify content in
> HSM. However, it may create confusion
> >
> with its results.
> >
> > I rarely use AUDIT. If the
> > BDELETE works or there are no longer any
> BCDS entries, I will not issue
> > AUDIT
> commands.
> >
> >
> > If you could provide the
> > description of the problem you are
> trying to solve with BDELETE and AUDIT,
> > that will be helpful.
> >
>
> > From what you have posted so far,
> the BDELETE looks like it was successful
> > at some point.
> >
> >
> > For further
> > analysis, issue the command
> BACKDS 'DB2.ARCHLOG2.A0091613'
> >
> > Then do the
> HLIST
> >
> DSN('DB2.ARCHLOG2.A0091613') BCDS and see if
> you get an entry
> >
> >
> > Next do the
> BDELETE command for
> >
> DB2.ARCHLOG2.A0091613
> >
> >
> > Repeat the HLIST
> command.
> >
> >
> > If there are
> > no
> entries in the BCDS for this dataset, that should show the
> process in
> > HSM is working.
> >
> >
> > Lizette
> >
> >
> > >
> -Original
> > Message-
> > > From: IBM Mainframe
> > Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On > Behalf Of willie
> > bunter
> >
> > Sent: Thursday, July 27, 2017
> 6:53 AM
> > >
> >
> To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Re: DFHSM QUESTION
> > >
> > > Here
> are the
> > commands I tried :
> > > HSEND FIXCDS B
> > DB96.ARCHLOG2.B778 (message
> received) :
> > >
> > > ARC0195I TYPE B, KEY
> > DB96.ARCHLOG2.B778, FIXCDS DISPLAY,
> ERROR=RECORD NOT > ARC0195I (CONT.)
> > FOUND > ARC1001I FIXCDS B
> DB96.ARCHLOG2.B778 COMMAND FAILED, RC=0015,
> > REAS= > ARC1615I FIXCDS COMMAND
> REJECTED > > HSEND BDELETE
> >
> 'DB2.ARCHLOG2.A0091613' ALL No error message
> received.
> > >
> >
> > I
> >
Re: DFHSM QUESTION
Should I ignore the ERR 40 when I run the AUDIT report?
On Thu, 7/27/17, Lizette Koehler <stars...@mindspring.com> wrote:
Subject: Re: DFHSM QUESTION
To: IBM-MAIN@LISTSERV.UA.EDU
Received: Thursday, July 27, 2017, 12:06 PM
So is everything is correct
now?
Or do you have more
questions.
Otherwise I
think your issues are resolved.
Lizette
>
-Original Message-
> From: IBM
Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On
> Behalf Of willie bunter
> Sent: Thursday, July 27, 2017 8:58 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: DFHSM QUESTION
>
> I tried out the
BDELETE and as expected the record was not found.
>
> ARC0195I TYPE B, KEY
DB2.ARCHLOG2.A0091613, FIXCDS DELETE, ERROR=RECORD NOT
> ARC0195I (CONT.) FOUND
> ARC1001I FIXCDS B DB2.ARCHLOG2.A0091613
DELETE COMMAND FAILED, RC=0015,
>
ARC1001I (CONT.) REAS=
> ARC1615I
FIXCDS COMMAND REJECTED
>
> Below is the HLIST:
>
ARC0138I NO BCDS INFORMATION FOUND FOR DATASET
DB2.ARCHLOG2.A0091613
>
> On Thu, 7/27/17, Lizette Koehler <stars...@mindspring.com>
wrote:
>
> Subject:
Re: DFHSM QUESTION
> To: IBM-MAIN@LISTSERV.UA.EDU
> Received: Thursday, July 27, 2017, 10:52
AM
>
> At this
point, just take one step
> back.
>
> You wanted to
delete
> a backup version from HSM.
>
> The dataset is
either DB2.ARCHLOG2.A0091613 or
DB96.ARCHLOG2.B778
>
> Issue an HLIST
>
DSN('DB96.ARCHLOG2.B778') BCDS or HLIST
DSN('DB2.ARCHLOG2.A0091613
> ')
BCDS
>
>
> If you do not
> see
any backup datasets listed for these datasets, then you
have deleted
> the backup copies.
>
> If you still see
BCDS entries, then you may need to do more BDELETE
> commands.
>
> AUDIT is used to verify content in
HSM. However, it may create confusion
>
with its results.
>
> I rarely use AUDIT. If the
> BDELETE works or there are no longer any
BCDS entries, I will not issue
> AUDIT
commands.
>
>
> If you could provide the
> description of the problem you are
trying to solve with BDELETE and AUDIT,
> that will be helpful.
>
> From what you have posted so far,
the BDELETE looks like it was successful
> at some point.
>
>
> For further
> analysis, issue the command
BACKDS 'DB2.ARCHLOG2.A0091613'
>
> Then do the
HLIST
>
DSN('DB2.ARCHLOG2.A0091613') BCDS and see if
you get an entry
>
>
> Next do the
BDELETE command for
>
DB2.ARCHLOG2.A0091613
>
>
> Repeat the HLIST
command.
>
>
> If there are
> no
entries in the BCDS for this dataset, that should show the
process in
> HSM is working.
>
>
> Lizette
>
>
> >
-----Original
> Message-
> > From: IBM Mainframe
> Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On > Behalf Of willie
> bunter
>
> Sent: Thursday, July 27, 2017
6:53 AM
> >
>
To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: DFHSM QUESTION
> >
> > Here
are the
> commands I tried :
> > HSEND FIXCDS B
> DB96.ARCHLOG2.B778 (message
received) :
> >
> > ARC0195I TYPE B, KEY
> DB96.ARCHLOG2.B778, FIXCDS DISPLAY,
ERROR=RECORD NOT > ARC0195I (CONT.)
> FOUND > ARC1001I FIXCDS B
DB96.ARCHLOG2.B778 COMMAND FAILED, RC=0015,
> REAS= > ARC1615I FIXCDS COMMAND
REJECTED > > HSEND BDELETE
>
'DB2.ARCHLOG2.A0091613' ALL No error message
received.
> >
>
> I
> looked at the ERR 40 in the
doc. It describes my problem however it is >
> not clear what I should do. In this
case the B record does not exist or >
> missing.
> > for
example
> it says "If the backup
version (C) record references a data set > (B)
> record that does not exist, then a new
(B) record is created and the >
>
version added". Not usre ...then a new(B) record
is created and the
> version >
added.
> >
>
> I do not understand this. Any
>
suggestions?
> >
>
> > On Wed, 7/26/17, retired mainframer
<retired-mainfra...@q.com>
> wrote:
> >
> > Subject:
>
Re: DFHSM QUESTION
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Received: Wednesday, July 26,
2017, 1:30 PM > > Please show the
> complete AUDIT > and BDELETE
commands you are using.
> >
> > Did you look up ERR40 in the
"Error
> Codes and
D
Re: DFHSM QUESTION
HSEND AUDIT DSCTL(BACKUP) FIX ODS('dsn.for.output.listing')
is what you should run.
On Fri, Jul 28, 2017 at 2:56 AM, Horne, Patti <patti.ho...@fisglobal.com>
wrote:
> You ran the fix on the BDELETE not the AUDIT.
>
>
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of willie bunter
> Sent: Thursday, July 27, 2017 11:23 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: DFHSM QUESTION
>
> I ran the FIX and the following messages were received :
>
> ARC0085I (H)BDELETE REQUIRES ONE OF THE FOLLOWING MUTUALLY EXCLUSIVE
> KEYWORDS:
> ARC0085I (CONT.) ALL, VERSIONS, OR DATE
> ARC0085I (H)BDELETE REQUIRES ONE OF THE FOLLOWING MUTUALLY EXCLUSIVE
> KEYWORDS:
> ARC0085I (CONT.) ALL, VERSIONS, OR DATE
> ARC0085I (H)BDELETE REQUIRES ONE OF THE FOLLOWING MUTUALLY EXCLUSIVE
> KEYWORDS:
> ARC0085I (CONT.) ALL, VERSIONS, OR DATE
> ARC0085I (H)BDELETE REQUIRES ONE OF THE FOLLOWING MUTUALLY EXCLUSIVE
> KEYWORDS:
> ARC0085I (CONT.) ALL, VERSIONS, OR DATE
> ARC0085I (H)BDELETE REQUIRES ONE OF THE FOLLOWING MUTUALLY EXCLUSIVE
> KEYWORDS:
> ARC0085I (CONT.) ALL, VERSIONS, OR DATE
> ARC0085I (H)BDELETE REQUIRES ONE OF THE FOLLOWING MUTUALLY EXCLUSIVE
> KEYWORDS:
> ARC0085I (CONT.) ALL, VERSIONS, OR DATE
> ARC0085I (H)BDELETE REQUIRES ONE OF THE FOLLOWING MUTUALLY EXCLUSIVE
> KEYWORDS:
> ARC0085I (CONT.) ALL, VERSIONS, OR DATE
> ARC0085I (H)BDELETE REQUIRES ONE OF THE FOLLOWING MUTUALLY EXCLUSIVE
> KEYWORDS:
> ARC0085I (CONT.) ALL, VERSIONS, OR DATE
>
> Below is my command
>HSEND AUDIT DATASETCONTROLS(BACKUP) FIX -
> ODS(SYS2.AUDIT.DATASET.CONTROLS.BCDS.FIX.#2)
> ----
> On Thu, 7/27/17, Horne, Patti <patti.ho...@fisglobal.com> wrote:
>
> Subject: Re: DFHSM QUESTION
> To: IBM-MAIN@LISTSERV.UA.EDU
> Received: Thursday, July 27, 2017, 11:42 AM
>
> Try using FIX on your audit to
> see if it cleans up the error.
>
>
>
> -Original
> Message-
> From: IBM Mainframe Discussion
> List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of willie bunter
> Sent: Thursday,
> July 27, 2017 10:36 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: DFHSM QUESTION
>
> Lizette,
>
>
> The reason why I think that it is a problem because after I run the
> AUDIT using NOFIX the output shows the dsn (*err 40). I do not see this
> for other LPARS.
> My
> understanding is that if any errors appear a clean up is needed to be
> initiated. In this case only ERR 40 appears.
>
>
> On Thu, 7/27/17, Lizette
> Koehler <stars...@mindspring.com>
> wrote:
>
> Subject: Re: DFHSM
> QUESTION
> To: IBM-MAIN@LISTSERV.UA.EDU
> Received: Thursday, July 27, 2017, 10:22 AM
>
> That does not seem to be a
> failure.
>
> It
> just states the
> record you tried to delete
> no longer exists in HSM. Once the record is deleted, it cannot be
> deleted again.
>
>
> Why do you think this is a
> failure?
>
> The message
>
> ARC0195I is all you need to focus on. The ARC1001 or ARC1615I just
> states the command could not do any work.
>
>
>
>
> Lizette
>
>
> >
>
> -Original Message-
> > From:
> IBM
> Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >
> Behalf Of willie bunter > Sent: Thursday, July 27, 2017 6:32 AM > To:
> IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: DFHSM QUESTION > > Brian, >
> > I tried that out however it didn't work (record not found). Below is
> the > output:
> >
> > ARC0195I TYPE B,
> KEY
> DB2.ARCHLOG2.A0091613, FIXCDS DELETE,
> ERROR=RECORD NOT > ARC0195I (CONT.) FOUND > ARC1001I FIXCDS B
> DB2.ARCHLOG2.A0091613 DELETE COMMAND FAILED, RC=0015, > ARC1001I
> (CONT.) REAS= > ARC1615I FIXCDS COMMAND REJECTED >
>
>
> > On Wed, 7/26/17, Brian Fraser <brianmfra...@gmail.com>
> wrote:
> >
>
> > Subject:
> Re: DFHSM QUESTION
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Received: Wednesday, July 26, 2017,
> 9:23 PM > > If you just want to get rid of > the backup, then you
> can do the following.
> >
> > HSEND FIXCDS B
> >
> DB2.ARCHLOG2.A0091613
> *DELETE*
> >
> >
> Regards
> > Brian
>
> >
> > On Thu, Jul 27,
> 2017 at 1:30
> > AM,
> retired mainframer
> <
>
> > retired-mainfra...@q.com>
> > w
Re: DFHSM QUESTION
You ran the fix on the BDELETE not the AUDIT. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of willie bunter Sent: Thursday, July 27, 2017 11:23 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DFHSM QUESTION I ran the FIX and the following messages were received : ARC0085I (H)BDELETE REQUIRES ONE OF THE FOLLOWING MUTUALLY EXCLUSIVE KEYWORDS: ARC0085I (CONT.) ALL, VERSIONS, OR DATE ARC0085I (H)BDELETE REQUIRES ONE OF THE FOLLOWING MUTUALLY EXCLUSIVE KEYWORDS: ARC0085I (CONT.) ALL, VERSIONS, OR DATE ARC0085I (H)BDELETE REQUIRES ONE OF THE FOLLOWING MUTUALLY EXCLUSIVE KEYWORDS: ARC0085I (CONT.) ALL, VERSIONS, OR DATE ARC0085I (H)BDELETE REQUIRES ONE OF THE FOLLOWING MUTUALLY EXCLUSIVE KEYWORDS: ARC0085I (CONT.) ALL, VERSIONS, OR DATE ARC0085I (H)BDELETE REQUIRES ONE OF THE FOLLOWING MUTUALLY EXCLUSIVE KEYWORDS: ARC0085I (CONT.) ALL, VERSIONS, OR DATE ARC0085I (H)BDELETE REQUIRES ONE OF THE FOLLOWING MUTUALLY EXCLUSIVE KEYWORDS: ARC0085I (CONT.) ALL, VERSIONS, OR DATE ARC0085I (H)BDELETE REQUIRES ONE OF THE FOLLOWING MUTUALLY EXCLUSIVE KEYWORDS: ARC0085I (CONT.) ALL, VERSIONS, OR DATE ARC0085I (H)BDELETE REQUIRES ONE OF THE FOLLOWING MUTUALLY EXCLUSIVE KEYWORDS: ARC0085I (CONT.) ALL, VERSIONS, OR DATE Below is my command HSEND AUDIT DATASETCONTROLS(BACKUP) FIX - ODS(SYS2.AUDIT.DATASET.CONTROLS.BCDS.FIX.#2) On Thu, 7/27/17, Horne, Patti <patti.ho...@fisglobal.com> wrote: Subject: Re: DFHSM QUESTION To: IBM-MAIN@LISTSERV.UA.EDU Received: Thursday, July 27, 2017, 11:42 AM Try using FIX on your audit to see if it cleans up the error. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of willie bunter Sent: Thursday, July 27, 2017 10:36 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DFHSM QUESTION Lizette, The reason why I think that it is a problem because after I run the AUDIT using NOFIX the output shows the dsn (*err 40). I do not see this for other LPARS. My understanding is that if any errors appear a clean up is needed to be initiated. In this case only ERR 40 appears. On Thu, 7/27/17, Lizette Koehler <stars...@mindspring.com> wrote: Subject: Re: DFHSM QUESTION To: IBM-MAIN@LISTSERV.UA.EDU Received: Thursday, July 27, 2017, 10:22 AM That does not seem to be a failure. It just states the record you tried to delete no longer exists in HSM. Once the record is deleted, it cannot be deleted again. Why do you think this is a failure? The message ARC0195I is all you need to focus on. The ARC1001 or ARC1615I just states the command could not do any work. Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of willie bunter > Sent: Thursday, July 27, 2017 6:32 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: DFHSM QUESTION > > Brian, > > I tried that out however it didn't work (record not found). Below is the > output: > > ARC0195I TYPE B, KEY DB2.ARCHLOG2.A0091613, FIXCDS DELETE, ERROR=RECORD NOT > ARC0195I (CONT.) FOUND > ARC1001I FIXCDS B DB2.ARCHLOG2.A0091613 DELETE COMMAND FAILED, RC=0015, > ARC1001I (CONT.) REAS= > ARC1615I FIXCDS COMMAND REJECTED > > On Wed, 7/26/17, Brian Fraser <brianmfra...@gmail.com> wrote: > > Subject: Re: DFHSM QUESTION > To: IBM-MAIN@LISTSERV.UA.EDU > Received: Wednesday, July 26, 2017, 9:23 PM > > If you just want to get rid of > the backup, then you can do the following. > > HSEND FIXCDS B > DB2.ARCHLOG2.A0091613 *DELETE* > > Regards > Brian > > On Thu, Jul 27, 2017 at 1:30 > AM, retired mainframer < > retired-mainfra...@q.com> > wrote: > > > Please show the > complete AUDIT and BDELETE commands you are using. > > > > Did you look up ERR40 > in the "Error Codes and Diagnosis" section (section > 3 in my copy) of the > "Using the AUDIT Command" chapter (my chapter 67)? > > The table (51) identifies several > possible causes and corrective actions. > > > BDELETE is the proper action for only one of the causes. > > > > > -Original > Message----- > > > From: IBM Mainframe > Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > > Behalf Of willie > bunter > > Sent: Wednesday, July 26, 2017 7:27 AM > > To: IBM- > m...@listserv.ua.edu > > Subject: DFHSM QUESTION > > > > Good Day, > > > &
Re: DFHSM QUESTION
I understand that the record doesn't exist. However my question is how do I perform the clean up of the ERR 40 records? On Thu, 7/27/17, Carmen Vitullo <cvitu...@hughes.net> wrote: Subject: Re: DFHSM QUESTION To: IBM-MAIN@LISTSERV.UA.EDU Received: Thursday, July 27, 2017, 10:38 AM I think it's time to list the contents of the BCDS, I don't have HSM so I can't provide the correct command, HSEND LIST LEVEL(DB96) BCDS or (BACKUPCONTROLDATASET) OUTDATASET(xxx.yyy.xxx) ?? but I tent to agree with Lizette, the record in the BCDS does not exist * RECORD NOT FOUND—The indicated record was not found; you could not delete or update it. Carmen - Original Message - From: "willie bunter" <001409bd2345-dmarc-requ...@listserv.ua.edu> To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, July 27, 2017 8:52:37 AM Subject: Re: DFHSM QUESTION Here are the commands I tried : HSEND FIXCDS B DB96.ARCHLOG2.B778 (message received) : ARC0195I TYPE B, KEY DB96.ARCHLOG2.B778, FIXCDS DISPLAY, ERROR=RECORD NOT ARC0195I (CONT.) FOUND ARC1001I FIXCDS B DB96.ARCHLOG2.B778 COMMAND FAILED, RC=0015, REAS= ARC1615I FIXCDS COMMAND REJECTED HSEND BDELETE 'DB2.ARCHLOG2.A0091613' ALL No error message received. I looked at the ERR 40 in the doc. It describes my problem however it is not clear what I should do. In this case the B record does not exist or missing. for example it says "If the backup version (C) record references a data set (B) record that does not exist, then a new (B) record is created and the version added". Not usre ...then a new(B) record is created and the version added. I do not understand this. Any suggestions? On Wed, 7/26/17, retired mainframer <retired-mainfra...@q.com> wrote: Subject: Re: DFHSM QUESTION To: IBM-MAIN@LISTSERV.UA.EDU Received: Wednesday, July 26, 2017, 1:30 PM Please show the complete AUDIT and BDELETE commands you are using. Did you look up ERR40 in the "Error Codes and Diagnosis" section (section 3 in my copy) of the "Using the AUDIT Command" chapter (my chapter 67)? The table (51) identifies several possible causes and corrective actions. BDELETE is the proper action for only one of the causes. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of willie bunter > Sent: Wednesday, July 26, 2017 7:27 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: DFHSM QUESTION > > Good Day, > > I ran an AUDIT of the BCDS. I was 99% successfull of performing a clean up execept for > the following type dsns: > ERR 40 DB2.ARCHLOG2.A0091613 > HSMBACK.BACK.T592617.DB2.ARCHLOG2.I8257 MISSING > FIXCDS B DUMMY.RECOVER.MCB CREATE(X'0014' X'0098257F') > FIXCDS B DUMMY.RECOVER.MCB PATCH(X'002E' BITS(1.1.)) > FIXCDS B DUMMY.RECOVER.MCB PATCH(X'0030' X'000100010001') > FIXCDS B DUMMY.RECOVER.MCB EXPAND(X'0040') > FIXCDS B DUMMY.RECOVER.MCB PATCH(X'0050' + > > X'404040404040404040404040404040404040404040404040404040404040404040404040 > 404 > FIXCDS B DUMMY.RECOVER.MCB PATCH(X'0050' > HSMBACK.BACK.T592617.DB2.ARCHLOG > FIXCDS B DUMMY.RECOVER.MCB PATCH(X'0082' BITS(0110)) > BDELETE DUMMY.RECOVER.MCB > FIXCDS B DUMMY.RECOVER.MCB DELETE > END OF - ENHANCED AUDIT - LISTING - > > I tried a HSEND BDELETE 'DB2.ARCHLOG2.A0091613' ALL . The command which I > ran in batch was successful however when I ran another AUDIT the entry appears. I tried a > HSEND FIXCDS B DB2.ARCHLOG2.A0091613. Again the command was successful, > however the AUDIT says otherwise. -- 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 -- 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
Re: DFHSM QUESTION
I ran the FIX and the following messages were received : ARC0085I (H)BDELETE REQUIRES ONE OF THE FOLLOWING MUTUALLY EXCLUSIVE KEYWORDS: ARC0085I (CONT.) ALL, VERSIONS, OR DATE ARC0085I (H)BDELETE REQUIRES ONE OF THE FOLLOWING MUTUALLY EXCLUSIVE KEYWORDS: ARC0085I (CONT.) ALL, VERSIONS, OR DATE ARC0085I (H)BDELETE REQUIRES ONE OF THE FOLLOWING MUTUALLY EXCLUSIVE KEYWORDS: ARC0085I (CONT.) ALL, VERSIONS, OR DATE ARC0085I (H)BDELETE REQUIRES ONE OF THE FOLLOWING MUTUALLY EXCLUSIVE KEYWORDS: ARC0085I (CONT.) ALL, VERSIONS, OR DATE ARC0085I (H)BDELETE REQUIRES ONE OF THE FOLLOWING MUTUALLY EXCLUSIVE KEYWORDS: ARC0085I (CONT.) ALL, VERSIONS, OR DATE ARC0085I (H)BDELETE REQUIRES ONE OF THE FOLLOWING MUTUALLY EXCLUSIVE KEYWORDS: ARC0085I (CONT.) ALL, VERSIONS, OR DATE ARC0085I (H)BDELETE REQUIRES ONE OF THE FOLLOWING MUTUALLY EXCLUSIVE KEYWORDS: ARC0085I (CONT.) ALL, VERSIONS, OR DATE ARC0085I (H)BDELETE REQUIRES ONE OF THE FOLLOWING MUTUALLY EXCLUSIVE KEYWORDS: ARC0085I (CONT.) ALL, VERSIONS, OR DATE Below is my command HSEND AUDIT DATASETCONTROLS(BACKUP) FIX - ODS(SYS2.AUDIT.DATASET.CONTROLS.BCDS.FIX.#2) On Thu, 7/27/17, Horne, Patti <patti.ho...@fisglobal.com> wrote: Subject: Re: DFHSM QUESTION To: IBM-MAIN@LISTSERV.UA.EDU Received: Thursday, July 27, 2017, 11:42 AM Try using FIX on your audit to see if it cleans up the error. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of willie bunter Sent: Thursday, July 27, 2017 10:36 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DFHSM QUESTION Lizette, The reason why I think that it is a problem because after I run the AUDIT using NOFIX the output shows the dsn (*err 40). I do not see this for other LPARS. My understanding is that if any errors appear a clean up is needed to be initiated. In this case only ERR 40 appears. On Thu, 7/27/17, Lizette Koehler <stars...@mindspring.com> wrote: Subject: Re: DFHSM QUESTION To: IBM-MAIN@LISTSERV.UA.EDU Received: Thursday, July 27, 2017, 10:22 AM That does not seem to be a failure. It just states the record you tried to delete no longer exists in HSM. Once the record is deleted, it cannot be deleted again. Why do you think this is a failure? The message ARC0195I is all you need to focus on. The ARC1001 or ARC1615I just states the command could not do any work. Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of willie bunter > Sent: Thursday, July 27, 2017 6:32 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: DFHSM QUESTION > > Brian, > > I tried that out however it didn't work (record not found). Below is the > output: > > ARC0195I TYPE B, KEY DB2.ARCHLOG2.A0091613, FIXCDS DELETE, ERROR=RECORD NOT > ARC0195I (CONT.) FOUND > ARC1001I FIXCDS B DB2.ARCHLOG2.A0091613 DELETE COMMAND FAILED, RC=0015, > ARC1001I (CONT.) REAS= > ARC1615I FIXCDS COMMAND REJECTED > > On Wed, 7/26/17, Brian Fraser <brianmfra...@gmail.com> wrote: > > Subject: Re: DFHSM QUESTION > To: IBM-MAIN@LISTSERV.UA.EDU > Received: Wednesday, July 26, 2017, 9:23 PM > > If you just want to get rid of > the backup, then you can do the following. > > HSEND FIXCDS B > DB2.ARCHLOG2.A0091613 *DELETE* > > Regards > Brian > > On Thu, Jul 27, 2017 at 1:30 > AM, retired mainframer < > retired-mainfra...@q.com> > wrote: > > > Please show the > complete AUDIT and BDELETE commands you are using. > > > > Did you look up ERR40 > in the "Error Codes and Diagnosis" section (section > 3 in my copy) of the > "Using the AUDIT Command" chapter (my chapter 67)? > > The table (51) identifies several > possible causes and corrective actions. > > > BDELETE is the proper action for only one of the causes. > > > > > -Original > Message- > > > From: IBM Mainframe > Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > > Behalf Of willie > bunter > > Sent: Wednesday, July 26, 2017 7:27 AM > > To: IBM- > m...@listserv.ua.edu > >
Re: DFHSM QUESTION
So is everything is correct now?
Or do you have more questions.
Otherwise I think your issues are resolved.
Lizette
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of willie bunter
> Sent: Thursday, July 27, 2017 8:58 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: DFHSM QUESTION
>
> I tried out the BDELETE and as expected the record was not found.
>
> ARC0195I TYPE B, KEY DB2.ARCHLOG2.A0091613, FIXCDS DELETE, ERROR=RECORD NOT
> ARC0195I (CONT.) FOUND
> ARC1001I FIXCDS B DB2.ARCHLOG2.A0091613 DELETE COMMAND FAILED, RC=0015,
> ARC1001I (CONT.) REAS=
> ARC1615I FIXCDS COMMAND REJECTED
>
> Below is the HLIST:
> ARC0138I NO BCDS INFORMATION FOUND FOR DATASET DB2.ARCHLOG2.A0091613
>
> On Thu, 7/27/17, Lizette Koehler <stars...@mindspring.com> wrote:
>
> Subject: Re: DFHSM QUESTION
> To: IBM-MAIN@LISTSERV.UA.EDU
> Received: Thursday, July 27, 2017, 10:52 AM
>
> At this point, just take one step
> back.
>
> You wanted to delete
> a backup version from HSM.
>
> The dataset is either DB2.ARCHLOG2.A0091613 or DB96.ARCHLOG2.B778
>
> Issue an HLIST
> DSN('DB96.ARCHLOG2.B778') BCDSor HLIST DSN('DB2.ARCHLOG2.A0091613
> ') BCDS
>
>
> If you do not
> see any backup datasets listed for these datasets, then you have deleted
> the backup copies.
>
> If you still see BCDS entries, then you may need to do more BDELETE
> commands.
>
> AUDIT is used to verify content in HSM. However, it may create confusion
> with its results.
>
> I rarely use AUDIT. If the
> BDELETE works or there are no longer any BCDS entries, I will not issue
> AUDIT commands.
>
>
> If you could provide the
> description of the problem you are trying to solve with BDELETE and AUDIT,
> that will be helpful.
>
> From what you have posted so far, the BDELETE looks like it was successful
> at some point.
>
>
> For further
> analysis, issue the command BACKDS 'DB2.ARCHLOG2.A0091613'
>
> Then do the HLIST
> DSN('DB2.ARCHLOG2.A0091613') BCDS and see if you get an entry
>
>
> Next do the BDELETE command for
> DB2.ARCHLOG2.A0091613
>
>
> Repeat the HLIST command.
>
>
> If there are
> no entries in the BCDS for this dataset, that should show the process in
> HSM is working.
>
>
> Lizette
>
>
> > -Original
> Message-
> > From: IBM Mainframe
> Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of willie
> bunter >
> Sent: Thursday, July 27, 2017 6:53 AM
> >
> To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: DFHSM QUESTION
> >
> > Here are the
> commands I tried :
> > HSEND FIXCDS B
> DB96.ARCHLOG2.B778 (message received) :
> >
> > ARC0195I TYPE B, KEY
> DB96.ARCHLOG2.B778, FIXCDS DISPLAY, ERROR=RECORD NOT > ARC0195I (CONT.)
> FOUND > ARC1001I FIXCDS B DB96.ARCHLOG2.B778 COMMAND FAILED, RC=0015,
> REAS= > ARC1615I FIXCDS COMMAND REJECTED > > HSEND BDELETE
> 'DB2.ARCHLOG2.A0091613' ALL No error message received.
> >
> > I
> looked at the ERR 40 in the doc. It describes my problem however it is >
> not clear what I should do. In this case the B record does not exist or >
> missing.
> > for example
> it says "If the backup version (C) record references a data set > (B)
> record that does not exist, then a new (B) record is created and the >
> version added". Not usre ...then a new(B) record is created and the
> version > added.
> >
> > I do not understand this. Any
> suggestions?
> >
>
> > On Wed, 7/26/17, retired mainframer <retired-mainfra...@q.com>
> wrote:
> >
> > Subject:
> Re: DFHSM QUESTION
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Received: Wednesday, July 26, 2017, 1:30 PM > > Please show the
> complete AUDIT > and BDELETE commands you are using.
> >
> > Did you look up ERR40 in the "Error
> Codes and Diagnosis" section (section 3 > in my copy) of the "Using the
> AUDIT Command" chapter (my chapter 67)? The > table (51) identifies
> several possible causes and corrective > actions. BDELETE is the proper
> action for only one of the causes.
> >
> > >
> > -Original Message-
> > > From: IBM
> >
> Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of
> > will
Re: DFHSM QUESTION
I tried out the BDELETE and as expected the record was not found.
ARC0195I TYPE B, KEY DB2.ARCHLOG2.A0091613, FIXCDS DELETE, ERROR=RECORD NOT
ARC0195I (CONT.) FOUND
ARC1001I FIXCDS B DB2.ARCHLOG2.A0091613 DELETE COMMAND FAILED, RC=0015,
ARC1001I (CONT.) REAS=
ARC1615I FIXCDS COMMAND REJECTED
Below is the HLIST:
ARC0138I NO BCDS INFORMATION FOUND FOR DATASET DB2.ARCHLOG2.A0091613
On Thu, 7/27/17, Lizette Koehler <stars...@mindspring.com> wrote:
Subject: Re: DFHSM QUESTION
To: IBM-MAIN@LISTSERV.UA.EDU
Received: Thursday, July 27, 2017, 10:52 AM
At this point, just take one step
back.
You wanted to delete
a backup version from HSM.
The dataset is either DB2.ARCHLOG2.A0091613
or DB96.ARCHLOG2.B778
Issue an HLIST
DSN('DB96.ARCHLOG2.B778') BCDS or
HLIST DSN('DB2.ARCHLOG2.A0091613 ') BCDS
If you do not
see any backup datasets listed for these datasets, then you
have deleted the backup copies.
If you still see BCDS entries, then you may
need to do more BDELETE commands.
AUDIT is used to verify content in HSM.
However, it may create confusion with its results.
I rarely use AUDIT. If the
BDELETE works or there are no longer any BCDS entries, I
will not issue AUDIT commands.
If you could provide the
description of the problem you are trying to solve with
BDELETE and AUDIT, that will be helpful.
From what you have posted so far, the BDELETE
looks like it was successful at some point.
For further
analysis, issue the command BACKDS
'DB2.ARCHLOG2.A0091613'
Then do the HLIST
DSN('DB2.ARCHLOG2.A0091613') BCDS and see if you
get an entry
Next do the BDELETE command for
DB2.ARCHLOG2.A0091613
Repeat the HLIST command.
If there are
no entries in the BCDS for this dataset, that should show
the process in HSM is working.
Lizette
> -Original
Message-
> From: IBM Mainframe
Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On
> Behalf Of willie bunter
>
Sent: Thursday, July 27, 2017 6:53 AM
>
To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: DFHSM QUESTION
>
> Here are the
commands I tried :
> HSEND FIXCDS B
DB96.ARCHLOG2.B778 (message received) :
>
> ARC0195I TYPE B, KEY
DB96.ARCHLOG2.B778, FIXCDS DISPLAY, ERROR=RECORD NOT
> ARC0195I (CONT.) FOUND
> ARC1001I FIXCDS B DB96.ARCHLOG2.B778
COMMAND FAILED, RC=0015, REAS=
>
ARC1615I FIXCDS COMMAND REJECTED
>
> HSEND BDELETE
'DB2.ARCHLOG2.A0091613' ALL No error message
received.
>
> I
looked at the ERR 40 in the doc. It describes my problem
however it is
> not clear what I should
do. In this case the B record does not exist or
> missing.
> for example
it says "If the backup version (C) record references a
data set
> (B) record that does not
exist, then a new (B) record is created and the
> version added". Not usre ...then
a new(B) record is created and the version
> added.
>
> I do not understand this. Any
suggestions?
>
> On Wed, 7/26/17, retired mainframer <retired-mainfra...@q.com>
wrote:
>
> Subject:
Re: DFHSM QUESTION
> To: IBM-MAIN@LISTSERV.UA.EDU
> Received: Wednesday, July 26, 2017, 1:30
PM
>
> Please show
the complete AUDIT
> and BDELETE
commands you are using.
>
> Did you look up ERR40 in the "Error
Codes and Diagnosis" section (section 3
> in my copy) of the "Using the AUDIT
Command" chapter (my chapter 67)? The
> table (51) identifies several possible
causes and corrective
> actions.
BDELETE is the proper action for only one of the
causes.
>
> >
> -Original Message-
> > From: IBM
>
Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On > Behalf Of
> willie bunter
> Sent: Wednesday, July 26, 2017 7:27 AM > To:
IBM-
> m...@listserv.ua.edu
> Subject: DFHSM QUESTION > > Good Day,
> > I ran
> an AUDIT of the
BCDS. I was 99% successfull of performing a clean up
> execept for > the following type
dsns:
> > ERR 40
DB2.ARCHLOG2.A0091613
> >
HSMBACK.BACK.T592617.DB2.ARCHLOG2.I8257
> MISSING
> >
FIXCDS B DUMMY.RECOVER.MCB
>
CREATE(X'0014' X'0098257F')
> > FIXCDS B DUMMY.RECOVER.MCB
> PATCH(X'002E'
BITS(1.1.))
> > FIXCDS B
DUMMY.RECOVER.MCB
>
PATCH(X'0030' X'000100010001')
> > FIXCDS B DUMMY.RECOVER.MCB
> EXPAND(X'0040')
> > FIXCDS B
>
DUMMY.RECOVER.MCB PATCH(X'0050' +
> >
> >
>
X'4040
Re: DFHSM QUESTION
Try using FIX on your audit to see if it cleans up the error. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of willie bunter Sent: Thursday, July 27, 2017 10:36 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DFHSM QUESTION Lizette, The reason why I think that it is a problem because after I run the AUDIT using NOFIX the output shows the dsn (*err 40). I do not see this for other LPARS. My understanding is that if any errors appear a clean up is needed to be initiated. In this case only ERR 40 appears. On Thu, 7/27/17, Lizette Koehler <stars...@mindspring.com> wrote: Subject: Re: DFHSM QUESTION To: IBM-MAIN@LISTSERV.UA.EDU Received: Thursday, July 27, 2017, 10:22 AM That does not seem to be a failure. It just states the record you tried to delete no longer exists in HSM. Once the record is deleted, it cannot be deleted again. Why do you think this is a failure? The message ARC0195I is all you need to focus on. The ARC1001 or ARC1615I just states the command could not do any work. Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of willie bunter > Sent: Thursday, July 27, 2017 6:32 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: DFHSM QUESTION > > Brian, > > I tried that out however it didn't work (record not found). Below is the > output: > > ARC0195I TYPE B, KEY DB2.ARCHLOG2.A0091613, FIXCDS DELETE, ERROR=RECORD NOT > ARC0195I (CONT.) FOUND > ARC1001I FIXCDS B DB2.ARCHLOG2.A0091613 DELETE COMMAND FAILED, RC=0015, > ARC1001I (CONT.) REAS= > ARC1615I FIXCDS COMMAND REJECTED > > On Wed, 7/26/17, Brian Fraser <brianmfra...@gmail.com> wrote: > > Subject: Re: DFHSM QUESTION > To: IBM-MAIN@LISTSERV.UA.EDU > Received: Wednesday, July 26, 2017, 9:23 PM > > If you just want to > get rid of > the backup, then you can do the following. > > HSEND FIXCDS B > DB2.ARCHLOG2.A0091613 *DELETE* > > Regards > Brian > > On Thu, Jul 27, 2017 at 1:30 > AM, retired mainframer < > retired-mainfra...@q.com> > wrote: > > > Please show the > complete AUDIT and BDELETE commands you are using. > > > > Did you look up ERR40 > in the "Error Codes and Diagnosis" section (section > 3 in my copy) of the > "Using the AUDIT Command" chapter (my chapter 67)? > > The table (51) identifies several > possible causes and corrective actions. > > > BDELETE is the proper action for only one of the causes. > > > > > -Original > Message- > > > From: IBM Mainframe > Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > > Behalf Of willie > > bunter > > Sent: Wednesday, July 26, 2017 7:27 AM > > To: IBM- > > m...@listserv.ua.edu > > Subject: DFHSM QUESTION > > > > Good Day, > > > > > > I ran an AUDIT of the BCDS. I was 99% successfull of performing a > > clean > up execept for > > the following type dsns: > > > ERR 40 DB2.ARCHLOG2.A0091613 > > > > HSMBACK.BACK.T592617.DB2.ARCHLOG2.I8257 MISSING > > FIXCDS B > DUMMY.RECOVER.MCB CREATE(X'0014' X'0098257F') > > FIXCDS B > DUMMY.RECOVER.MCB PATCH(X'002E' BITS(1.1.)) > > FIXCDS B > DUMMY.RECOVER.MCB PATCH(X'0030' X'000100010001') > > FIXCDS B > DUMMY.RECOVER.MCB > EXPAND(X'0040') > > > > FIXCDS B DUMMY.RECOVER.MCB PATCH(X'0050' + > > > > > X'404040404040404040404040404040404040404040404040404040404040 > > 404040404040 > > > > 404 > > > FIXCDS B DUMMY.RECOVER.MCB > PATCH(X'0050' > > > > HSMBACK.BACK.T592617.DB2.ARCHLOG > > > > FIXCDS B DUMMY.RECOVER.MCB PATCH(X'0082' > BITS(0110)) > > > BDELETE > DUMMY.RECOVER.MCB > > > FIXCDS B > DUMMY.RECOVER.MCB DELETE > > > END OF > - ENHANCED AUDIT - LISTING - > > > > > > > I tried a HSEND BDELETE > 'DB2.ARCHLOG2.A0091613' ALL . The command which > I > > ran in batch was > successful however when I ran another AUDIT the entry > appears. I tried a > > > HSEND FIXCDS B DB2.ARCHLOG2.A0091613. Again the command was > successful, > > however the AUDIT says otherwise. > > > > -- F
Re: DFHSM QUESTION
Lizette, The reason why I think that it is a problem because after I run the AUDIT using NOFIX the output shows the dsn (*err 40). I do not see this for other LPARS. My understanding is that if any errors appear a clean up is needed to be initiated. In this case only ERR 40 appears. On Thu, 7/27/17, Lizette Koehler <stars...@mindspring.com> wrote: Subject: Re: DFHSM QUESTION To: IBM-MAIN@LISTSERV.UA.EDU Received: Thursday, July 27, 2017, 10:22 AM That does not seem to be a failure. It just states the record you tried to delete no longer exists in HSM. Once the record is deleted, it cannot be deleted again. Why do you think this is a failure? The message ARC0195I is all you need to focus on. The ARC1001 or ARC1615I just states the command could not do any work. Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of willie bunter > Sent: Thursday, July 27, 2017 6:32 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: DFHSM QUESTION > > Brian, > > I tried that out however it didn't work (record not found). Below is the > output: > > ARC0195I TYPE B, KEY DB2.ARCHLOG2.A0091613, FIXCDS DELETE, ERROR=RECORD NOT > ARC0195I (CONT.) FOUND > ARC1001I FIXCDS B DB2.ARCHLOG2.A0091613 DELETE COMMAND FAILED, RC=0015, > ARC1001I (CONT.) REAS= > ARC1615I FIXCDS COMMAND REJECTED > > On Wed, 7/26/17, Brian Fraser <brianmfra...@gmail.com> wrote: > > Subject: Re: DFHSM QUESTION > To: IBM-MAIN@LISTSERV.UA.EDU > Received: Wednesday, July 26, 2017, 9:23 PM > > If you just want to get rid of > the backup, then you can do the following. > > HSEND FIXCDS B > DB2.ARCHLOG2.A0091613 *DELETE* > > Regards > Brian > > On Thu, Jul 27, 2017 at 1:30 > AM, retired mainframer < > retired-mainfra...@q.com> > wrote: > > > Please show the > complete AUDIT and BDELETE commands you are using. > > > > Did you look up ERR40 > in the "Error Codes and Diagnosis" section (section > 3 in my copy) of the > "Using the AUDIT Command" chapter (my chapter 67)? > > The table (51) identifies several > possible causes and corrective actions. > > > BDELETE is the proper action for only one of the causes. > > > > > -Original > Message- > > > From: IBM Mainframe > Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > > Behalf Of willie > bunter > > Sent: Wednesday, July 26, 2017 7:27 AM > > To: IBM- > m...@listserv.ua.edu > > Subject: DFHSM QUESTION > > > > Good Day, > > > > > I ran an AUDIT of the BCDS. I was 99% successfull of performing a > clean > up execept for > > the following type dsns: > > > ERR 40 DB2.ARCHLOG2.A0091613 > > > > HSMBACK.BACK.T592617.DB2.ARCHLOG2.I8257 MISSING > > FIXCDS B > DUMMY.RECOVER.MCB CREATE(X'0014' X'0098257F') > > FIXCDS B > DUMMY.RECOVER.MCB PATCH(X'002E' BITS(1.1.)) > > FIXCDS B > DUMMY.RECOVER.MCB PATCH(X'0030' X'000100010001') > > FIXCDS B > DUMMY.RECOVER.MCB > EXPAND(X'0040') > > > > FIXCDS B DUMMY.RECOVER.MCB PATCH(X'0050' + > > > > > X'404040404040404040404040404040404040404040404040404040404040 > > 404040404040 > > > > 404 > > > FIXCDS B DUMMY.RECOVER.MCB > PATCH(X'0050' > > > > HSMBACK.BACK.T592617.DB2.ARCHLOG > > > > FIXCDS B DUMMY.RECOVER.MCB PATCH(X'0082' > BITS(0110)) > > > BDELETE > DUMMY.RECOVER.MCB > > > FIXCDS B > DUMMY.RECOVER.MCB DELETE > > > END OF > - ENHANCED AUDIT - LISTING - > > > > > > > I tried a HSEND BDELETE > 'DB2.ARCHLOG2.A0091613' ALL . The command which > I > > ran in batch was > successful however when I ran another AUDIT the entry > appears. I tried a > > > HSEND FIXCDS B DB2.ARCHLOG2.A0091613. Again the command was > successful, > > however the AUDIT says otherwise. > > > > -- 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
Re: DFHSM QUESTION
At this point, just take one step back.
You wanted to delete a backup version from HSM.
The dataset is either DB2.ARCHLOG2.A0091613 or DB96.ARCHLOG2.B778
Issue an HLIST DSN('DB96.ARCHLOG2.B778') BCDSor HLIST
DSN('DB2.ARCHLOG2.A0091613 ') BCDS
If you do not see any backup datasets listed for these datasets, then you have
deleted the backup copies.
If you still see BCDS entries, then you may need to do more BDELETE commands.
AUDIT is used to verify content in HSM. However, it may create confusion with
its results.
I rarely use AUDIT. If the BDELETE works or there are no longer any BCDS
entries, I will not issue AUDIT commands.
If you could provide the description of the problem you are trying to solve
with BDELETE and AUDIT, that will be helpful.
>From what you have posted so far, the BDELETE looks like it was successful at
>some point.
For further analysis, issue the command BACKDS
'DB2.ARCHLOG2.A0091613'
Then do the HLIST DSN('DB2.ARCHLOG2.A0091613') BCDS and see if you get an
entry
Next do the BDELETE command for DB2.ARCHLOG2.A0091613
Repeat the HLIST command.
If there are no entries in the BCDS for this dataset, that should show the
process in HSM is working.
Lizette
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of willie bunter
> Sent: Thursday, July 27, 2017 6:53 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: DFHSM QUESTION
>
> Here are the commands I tried :
> HSEND FIXCDS B DB96.ARCHLOG2.B778 (message received) :
>
> ARC0195I TYPE B, KEY DB96.ARCHLOG2.B778, FIXCDS DISPLAY, ERROR=RECORD NOT
> ARC0195I (CONT.) FOUND
> ARC1001I FIXCDS B DB96.ARCHLOG2.B778 COMMAND FAILED, RC=0015, REAS=
> ARC1615I FIXCDS COMMAND REJECTED
>
> HSEND BDELETE 'DB2.ARCHLOG2.A0091613' ALL No error message received.
>
> I looked at the ERR 40 in the doc. It describes my problem however it is
> not clear what I should do. In this case the B record does not exist or
> missing.
> for example it says "If the backup version (C) record references a data set
> (B) record that does not exist, then a new (B) record is created and the
> version added". Not usre ...then a new(B) record is created and the version
> added.
>
> I do not understand this. Any suggestions?
> ----
> On Wed, 7/26/17, retired mainframer <retired-mainfra...@q.com> wrote:
>
> Subject: Re: DFHSM QUESTION
> To: IBM-MAIN@LISTSERV.UA.EDU
> Received: Wednesday, July 26, 2017, 1:30 PM
>
> Please show the complete AUDIT
> and BDELETE commands you are using.
>
> Did you look up ERR40 in the "Error Codes and Diagnosis" section (section 3
> in my copy) of the "Using the AUDIT Command" chapter (my chapter 67)? The
> table (51) identifies several possible causes and corrective
> actions. BDELETE is the proper action for only one of the causes.
>
> >
> -Original Message-
> > From: IBM
> Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of
> willie bunter > Sent: Wednesday, July 26, 2017 7:27 AM > To: IBM-
> m...@listserv.ua.edu > Subject: DFHSM QUESTION > > Good Day, > > I ran
> an AUDIT of the BCDS. I was 99% successfull of performing a clean up
> execept for > the following type dsns:
> > ERR 40 DB2.ARCHLOG2.A0091613
> > HSMBACK.BACK.T592617.DB2.ARCHLOG2.I8257
> MISSING
> > FIXCDS B DUMMY.RECOVER.MCB
> CREATE(X'0014' X'0098257F')
> > FIXCDS B DUMMY.RECOVER.MCB
> PATCH(X'002E' BITS(1.1.))
> > FIXCDS B DUMMY.RECOVER.MCB
> PATCH(X'0030' X'000100010001')
> > FIXCDS B DUMMY.RECOVER.MCB
> EXPAND(X'0040')
> > FIXCDS B
> DUMMY.RECOVER.MCB PATCH(X'0050' +
> >
> >
> X'404040404040404040404040404040404040404040404040404040404040404040404040
> > 404
> > FIXCDS B
> DUMMY.RECOVER.MCB PATCH(X'0050'
> > HSMBACK.BACK.T592617.DB2.ARCHLOG
> > FIXCDS B DUMMY.RECOVER.MCB
> PATCH(X'0082' BITS(0110))
> > BDELETE DUMMY.RECOVER.MCB
> > FIXCDS B DUMMY.RECOVER.MCB DELETE
> > END OF - ENHANCED AUDIT - LISTING
> -
> >
> > I tried a HSEND
> BDELETE 'DB2.ARCHLOG2.A0091613' ALL . The command which I > ran in batch
> was successful however when I ran another AUDIT the entry appears. I tried
> a > HSEND FIXCDS B DB2.ARCHLOG2.A0091613. Again the command was
> successful, > however the AUDIT says otherwise.
>
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION
I think it's time to list the contents of the BCDS, I don't have HSM so I can't provide the correct command, HSEND LIST LEVEL(DB96) BCDS or (BACKUPCONTROLDATASET) OUTDATASET(xxx.yyy.xxx) ?? but I tent to agree with Lizette, the record in the BCDS does not exist * RECORD NOT FOUND—The indicated record was not found; you could not delete or update it. Carmen - Original Message - From: "willie bunter" <001409bd2345-dmarc-requ...@listserv.ua.edu> To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, July 27, 2017 8:52:37 AM Subject: Re: DFHSM QUESTION Here are the commands I tried : HSEND FIXCDS B DB96.ARCHLOG2.B778 (message received) : ARC0195I TYPE B, KEY DB96.ARCHLOG2.B778, FIXCDS DISPLAY, ERROR=RECORD NOT ARC0195I (CONT.) FOUND ARC1001I FIXCDS B DB96.ARCHLOG2.B778 COMMAND FAILED, RC=0015, REAS= ARC1615I FIXCDS COMMAND REJECTED HSEND BDELETE 'DB2.ARCHLOG2.A0091613' ALL No error message received. I looked at the ERR 40 in the doc. It describes my problem however it is not clear what I should do. In this case the B record does not exist or missing. for example it says "If the backup version (C) record references a data set (B) record that does not exist, then a new (B) record is created and the version added". Not usre ...then a new(B) record is created and the version added. I do not understand this. Any suggestions? On Wed, 7/26/17, retired mainframer <retired-mainfra...@q.com> wrote: Subject: Re: DFHSM QUESTION To: IBM-MAIN@LISTSERV.UA.EDU Received: Wednesday, July 26, 2017, 1:30 PM Please show the complete AUDIT and BDELETE commands you are using. Did you look up ERR40 in the "Error Codes and Diagnosis" section (section 3 in my copy) of the "Using the AUDIT Command" chapter (my chapter 67)? The table (51) identifies several possible causes and corrective actions. BDELETE is the proper action for only one of the causes. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of willie bunter > Sent: Wednesday, July 26, 2017 7:27 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: DFHSM QUESTION > > Good Day, > > I ran an AUDIT of the BCDS. I was 99% successfull of performing a clean up execept for > the following type dsns: > ERR 40 DB2.ARCHLOG2.A0091613 > HSMBACK.BACK.T592617.DB2.ARCHLOG2.I8257 MISSING > FIXCDS B DUMMY.RECOVER.MCB CREATE(X'0014' X'0098257F') > FIXCDS B DUMMY.RECOVER.MCB PATCH(X'002E' BITS(1.1.)) > FIXCDS B DUMMY.RECOVER.MCB PATCH(X'0030' X'000100010001') > FIXCDS B DUMMY.RECOVER.MCB EXPAND(X'0040') > FIXCDS B DUMMY.RECOVER.MCB PATCH(X'0050' + > > X'404040404040404040404040404040404040404040404040404040404040404040404040 > 404 > FIXCDS B DUMMY.RECOVER.MCB PATCH(X'0050' > HSMBACK.BACK.T592617.DB2.ARCHLOG > FIXCDS B DUMMY.RECOVER.MCB PATCH(X'0082' BITS(0110)) > BDELETE DUMMY.RECOVER.MCB > FIXCDS B DUMMY.RECOVER.MCB DELETE > END OF - ENHANCED AUDIT - LISTING - > > I tried a HSEND BDELETE 'DB2.ARCHLOG2.A0091613' ALL . The command which I > ran in batch was successful however when I ran another AUDIT the entry appears. I tried a > HSEND FIXCDS B DB2.ARCHLOG2.A0091613. Again the command was successful, > however the AUDIT says otherwise. -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION
Here are the commands I tried : HSEND FIXCDS B DB96.ARCHLOG2.B778 (message received) : ARC0195I TYPE B, KEY DB96.ARCHLOG2.B778, FIXCDS DISPLAY, ERROR=RECORD NOT ARC0195I (CONT.) FOUND ARC1001I FIXCDS B DB96.ARCHLOG2.B778 COMMAND FAILED, RC=0015, REAS= ARC1615I FIXCDS COMMAND REJECTED HSEND BDELETE 'DB2.ARCHLOG2.A0091613' ALL No error message received. I looked at the ERR 40 in the doc. It describes my problem however it is not clear what I should do. In this case the B record does not exist or missing. for example it says "If the backup version (C) record references a data set (B) record that does not exist, then a new (B) record is created and the version added". Not usre ...then a new(B) record is created and the version added. I do not understand this. Any suggestions? On Wed, 7/26/17, retired mainframer <retired-mainfra...@q.com> wrote: Subject: Re: DFHSM QUESTION To: IBM-MAIN@LISTSERV.UA.EDU Received: Wednesday, July 26, 2017, 1:30 PM Please show the complete AUDIT and BDELETE commands you are using. Did you look up ERR40 in the "Error Codes and Diagnosis" section (section 3 in my copy) of the "Using the AUDIT Command" chapter (my chapter 67)? The table (51) identifies several possible causes and corrective actions. BDELETE is the proper action for only one of the causes. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of willie bunter > Sent: Wednesday, July 26, 2017 7:27 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: DFHSM QUESTION > > Good Day, > > I ran an AUDIT of the BCDS. I was 99% successfull of performing a clean up execept for > the following type dsns: > ERR 40 DB2.ARCHLOG2.A0091613 > HSMBACK.BACK.T592617.DB2.ARCHLOG2.I8257 MISSING > FIXCDS B DUMMY.RECOVER.MCB CREATE(X'0014' X'0098257F') > FIXCDS B DUMMY.RECOVER.MCB PATCH(X'002E' BITS(1.1.)) > FIXCDS B DUMMY.RECOVER.MCB PATCH(X'0030' X'000100010001') > FIXCDS B DUMMY.RECOVER.MCB EXPAND(X'0040') > FIXCDS B DUMMY.RECOVER.MCB PATCH(X'0050' + > > X'404040404040404040404040404040404040404040404040404040404040404040404040 > 404 > FIXCDS B DUMMY.RECOVER.MCB PATCH(X'0050' > HSMBACK.BACK.T592617.DB2.ARCHLOG > FIXCDS B DUMMY.RECOVER.MCB PATCH(X'0082' BITS(0110)) > BDELETE DUMMY.RECOVER.MCB > FIXCDS B DUMMY.RECOVER.MCB DELETE > END OF - ENHANCED AUDIT - LISTING - > > I tried a HSEND BDELETE 'DB2.ARCHLOG2.A0091613' ALL . The command which I > ran in batch was successful however when I ran another AUDIT the entry appears. I tried a > HSEND FIXCDS B DB2.ARCHLOG2.A0091613. Again the command was successful, > however the AUDIT says otherwise. -- 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
Re: DFHSM QUESTION
Brian, I tried that out however it didn't work (record not found). Below is the output: ARC0195I TYPE B, KEY DB2.ARCHLOG2.A0091613, FIXCDS DELETE, ERROR=RECORD NOT ARC0195I (CONT.) FOUND ARC1001I FIXCDS B DB2.ARCHLOG2.A0091613 DELETE COMMAND FAILED, RC=0015, ARC1001I (CONT.) REAS= ARC1615I FIXCDS COMMAND REJECTED On Wed, 7/26/17, Brian Fraser <brianmfra...@gmail.com> wrote: Subject: Re: DFHSM QUESTION To: IBM-MAIN@LISTSERV.UA.EDU Received: Wednesday, July 26, 2017, 9:23 PM If you just want to get rid of the backup, then you can do the following. HSEND FIXCDS B DB2.ARCHLOG2.A0091613 *DELETE* Regards Brian On Thu, Jul 27, 2017 at 1:30 AM, retired mainframer < retired-mainfra...@q.com> wrote: > Please show the complete AUDIT and BDELETE commands you are using. > > Did you look up ERR40 in the "Error Codes and Diagnosis" section (section > 3 in my copy) of the "Using the AUDIT Command" chapter (my chapter 67)? > The table (51) identifies several possible causes and corrective actions. > BDELETE is the proper action for only one of the causes. > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > > Behalf Of willie bunter > > Sent: Wednesday, July 26, 2017 7:27 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: DFHSM QUESTION > > > > Good Day, > > > > I ran an AUDIT of the BCDS. I was 99% successfull of performing a clean > up execept for > > the following type dsns: > > ERR 40 DB2.ARCHLOG2.A0091613 > > HSMBACK.BACK.T592617.DB2.ARCHLOG2.I8257 MISSING > > FIXCDS B DUMMY.RECOVER.MCB CREATE(X'0014' X'0098257F') > > FIXCDS B DUMMY.RECOVER.MCB PATCH(X'002E' BITS(1.1.)) > > FIXCDS B DUMMY.RECOVER.MCB PATCH(X'0030' X'000100010001') > > FIXCDS B DUMMY.RECOVER.MCB EXPAND(X'0040') > > FIXCDS B DUMMY.RECOVER.MCB PATCH(X'0050' + > > > > X'404040404040404040404040404040404040404040404040404040404040 > 404040404040 > > 404 > > FIXCDS B DUMMY.RECOVER.MCB PATCH(X'0050' > > HSMBACK.BACK.T592617.DB2.ARCHLOG > > FIXCDS B DUMMY.RECOVER.MCB PATCH(X'0082' BITS(0110)) > > BDELETE DUMMY.RECOVER.MCB > > FIXCDS B DUMMY.RECOVER.MCB DELETE > > END OF - ENHANCED AUDIT - LISTING - > > > > I tried a HSEND BDELETE 'DB2.ARCHLOG2.A0091613' ALL . The command which > I > > ran in batch was successful however when I ran another AUDIT the entry > appears. I tried a > > HSEND FIXCDS B DB2.ARCHLOG2.A0091613. Again the command was successful, > > however the AUDIT says otherwise. > > -- > 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION
If you just want to get rid of the backup, then you can do the following. HSEND FIXCDS B DB2.ARCHLOG2.A0091613 *DELETE* Regards Brian On Thu, Jul 27, 2017 at 1:30 AM, retired mainframer < retired-mainfra...@q.com> wrote: > Please show the complete AUDIT and BDELETE commands you are using. > > Did you look up ERR40 in the "Error Codes and Diagnosis" section (section > 3 in my copy) of the "Using the AUDIT Command" chapter (my chapter 67)? > The table (51) identifies several possible causes and corrective actions. > BDELETE is the proper action for only one of the causes. > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > > Behalf Of willie bunter > > Sent: Wednesday, July 26, 2017 7:27 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: DFHSM QUESTION > > > > Good Day, > > > > I ran an AUDIT of the BCDS. I was 99% successfull of performing a clean > up execept for > > the following type dsns: > > ERR 40 DB2.ARCHLOG2.A0091613 > > HSMBACK.BACK.T592617.DB2.ARCHLOG2.I8257 MISSING > > FIXCDS B DUMMY.RECOVER.MCB CREATE(X'0014' X'0098257F') > > FIXCDS B DUMMY.RECOVER.MCB PATCH(X'002E' BITS(1.1.)) > > FIXCDS B DUMMY.RECOVER.MCB PATCH(X'0030' X'000100010001') > > FIXCDS B DUMMY.RECOVER.MCB EXPAND(X'0040') > > FIXCDS B DUMMY.RECOVER.MCB PATCH(X'0050' + > > > > X'404040404040404040404040404040404040404040404040404040404040 > 404040404040 > > 404 > > FIXCDS B DUMMY.RECOVER.MCB PATCH(X'0050' > > HSMBACK.BACK.T592617.DB2.ARCHLOG > > FIXCDS B DUMMY.RECOVER.MCB PATCH(X'0082' BITS(0110)) > > BDELETE DUMMY.RECOVER.MCB > > FIXCDS B DUMMY.RECOVER.MCB DELETE > > END OF - ENHANCED AUDIT - LISTING - > > > > I tried a HSEND BDELETE 'DB2.ARCHLOG2.A0091613' ALL . The command which > I > > ran in batch was successful however when I ran another AUDIT the entry > appears. I tried a > > HSEND FIXCDS B DB2.ARCHLOG2.A0091613. Again the command was successful, > > however the AUDIT says otherwise. > > -- > 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
Re: DFHSM QUESTION
Please show the complete AUDIT and BDELETE commands you are using. Did you look up ERR40 in the "Error Codes and Diagnosis" section (section 3 in my copy) of the "Using the AUDIT Command" chapter (my chapter 67)? The table (51) identifies several possible causes and corrective actions. BDELETE is the proper action for only one of the causes. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of willie bunter > Sent: Wednesday, July 26, 2017 7:27 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: DFHSM QUESTION > > Good Day, > > I ran an AUDIT of the BCDS. I was 99% successfull of performing a clean up > execept for > the following type dsns: > ERR 40 DB2.ARCHLOG2.A0091613 > HSMBACK.BACK.T592617.DB2.ARCHLOG2.I8257 MISSING > FIXCDS B DUMMY.RECOVER.MCB CREATE(X'0014' X'0098257F') > FIXCDS B DUMMY.RECOVER.MCB PATCH(X'002E' BITS(1.1.)) > FIXCDS B DUMMY.RECOVER.MCB PATCH(X'0030' X'000100010001') > FIXCDS B DUMMY.RECOVER.MCB EXPAND(X'0040') > FIXCDS B DUMMY.RECOVER.MCB PATCH(X'0050' + > > X'404040404040404040404040404040404040404040404040404040404040404040404040 > 404 > FIXCDS B DUMMY.RECOVER.MCB PATCH(X'0050' > HSMBACK.BACK.T592617.DB2.ARCHLOG > FIXCDS B DUMMY.RECOVER.MCB PATCH(X'0082' BITS(0110)) > BDELETE DUMMY.RECOVER.MCB > FIXCDS B DUMMY.RECOVER.MCB DELETE > END OF - ENHANCED AUDIT - LISTING - > > I tried a HSEND BDELETE 'DB2.ARCHLOG2.A0091613' ALL . The command which I > ran in batch was successful however when I ran another AUDIT the entry > appears. I tried a > HSEND FIXCDS B DB2.ARCHLOG2.A0091613. Again the command was successful, > however the AUDIT says otherwise. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION - REPOST
Lizette, I verified the syntax of the BDELETE command and it is correct. I ran a HLIST against the dsn and it says "ARC0138I NO BCDS INFORMATION FOUND FOR DATASET DB2.ARCHLOG2.A0091613". I will keep on digging around. On Wed, 7/26/17, Lizette Koehler <stars...@mindspring.com> wrote: Subject: Re: DFHSM QUESTION - REPOST To: IBM-MAIN@LISTSERV.UA.EDU Received: Wednesday, July 26, 2017, 11:15 AM I would suggest if you are running in batch, you may see successful. But I would check the DFHSM Started task for error messages. That you still see the entry seems to indicate that it was not successful. Please check the syntax of your BDELETE Command. https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.arcf000/s4118.htm I suggest you do the following HLIST DSN(your dataset name) BCDS See if you have more than one GEN for the backup. Next review the HSM Command manual for BDELETE and make sure you are entering the command correctly. Lastly, provide all commands and message (full details, mask company proprietary data) There are some functions that will return a OK to a command, but it does not mean that command was successful Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of willie bunter > Sent: Wednesday, July 26, 2017 7:30 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: DFHSM QUESTION - REPOST > > I am reposting my question because some info was truncated. > > I ran an AUDIT of the BCDS. I was 99% successfull of performing a clean up > execept for the following type dsns: > ERR 40 DB2.ARCHLOG2.A0091613 HSMBACK.BACK.T592617.DB2.ARCHLOG2.I8257 MISSING > B RECORD > FIXCDS B DUMMY.RECOVER.MCB CREATE(X'0014' X'0098257F') > FIXCDS B DUMMY.RECOVER.MCB PATCH(X'002E' BITS(1.1.)) > FIXCDS B DUMMY.RECOVER.MCB PATCH(X'0030' X'000100010001') > FIXCDS B DUMMY.RECOVER.MCB EXPAND(X'0040') > FIXCDS B DUMMY.RECOVER.MCB PATCH(X'0050' + > > X'404040404040404040404040404040404040404040404040404040404040404040404040404 > FIXCDS B DUMMY.RECOVER.MCB PATCH(X'0050' > HSMBACK.BACK.T592617.DB2.ARCHLOG > FIXCDS B DUMMY.RECOVER.MCB PATCH(X'0082' BITS(0110)) > BDELETE DUMMY.RECOVER.MCB > FIXCDS B DUMMY.RECOVER.MCB DELETE > END OF - ENHANCED AUDIT - LISTING - > > I tried a HSEND BDELETE 'DB2.ARCHLOG2.A0091613' ALL . The command which I > ran in batch was successful however when I ran another AUDIT the entry > appears. I tried a HSEND FIXCDS B DB2.ARCHLOG2.A0091613. Again the command > was successful, however the AUDIT says otherwise. > > Anything else I could try? > > ---- > On Wed, 7/26/17, willie bunter <001409bd2345-dmarc- > requ...@listserv.ua.edu> wrote: > > Subject: DFHSM QUESTION > To: IBM-MAIN@LISTSERV.UA.EDU > Received: Wednesday, July 26, 2017, 10:26 AM > > Good Day, > > I ran an AUDIT of the BCDS. I was > 99% successfull of performing a clean up execept for the following type > dsns: > ERR 40 DB2.ARCHLOG2.A0091613 > HSMBACK.BACK.T592617.DB2.ARCHLOG2.I8257 MISSING > FIXCDS B DUMMY.RECOVER.MCB > CREATE(X'0014' X'0098257F') > > FIXCDS B DUMMY.RECOVER.MCB > PATCH(X'002E' BITS(1.1.)) > > FIXCDS B DUMMY.RECOVER.MCB > PATCH(X'0030' X'000100010001') > > FIXCDS B DUMMY.RECOVER.MCB > EXPAND(X'0040') > > > FIXCDS B DUMMY.RECOVER.MCB > PATCH(X'0050' + > > > > > X'404040404040404040404040404040404040404040404040404040404040404040404040404 > FIXCDS B DUMMY.RECOVER.MCB > PATCH(X'0050' HSMBACK.BACK.T592617.DB2.ARCHLOG > FIXCDS B DUMMY.RECOVER.MCB > PATCH(X'0082' BITS(0110)) > > BDELETE DUMMY.RECOVER.MCB > > > > FIXCDS B DUMMY.RECOVER.MCB > DELETE > > > END OF - ENHANCED AUDIT - > LISTING - > > > > I tried a HSEND BDELETE > 'DB2.ARCHLOG2.A0091613' ALL . The command which I ran in batch was > successful however when I ran another AUDIT the entry appears. I tried a > HSEND FIXCDS B DB2.ARCHLOG2.A0091613. Again the command was successful, > however the AUDIT says otherwise. > > Anything else I could try? -- 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
Re: DFHSM QUESTION - REPOST
I would suggest if you are running in batch, you may see successful. But I would check the DFHSM Started task for error messages. That you still see the entry seems to indicate that it was not successful. Please check the syntax of your BDELETE Command. https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.arcf000/s4118.htm I suggest you do the following HLIST DSN(your dataset name) BCDS See if you have more than one GEN for the backup. Next review the HSM Command manual for BDELETE and make sure you are entering the command correctly. Lastly, provide all commands and message (full details, mask company proprietary data) There are some functions that will return a OK to a command, but it does not mean that command was successful Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of willie bunter > Sent: Wednesday, July 26, 2017 7:30 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: DFHSM QUESTION - REPOST > > I am reposting my question because some info was truncated. > > I ran an AUDIT of the BCDS. I was 99% successfull of performing a clean up > execept for the following type dsns: > ERR 40 DB2.ARCHLOG2.A0091613 HSMBACK.BACK.T592617.DB2.ARCHLOG2.I8257 MISSING > B RECORD > FIXCDS B DUMMY.RECOVER.MCB CREATE(X'0014' X'0098257F') > FIXCDS B DUMMY.RECOVER.MCB PATCH(X'002E' BITS(1.1.)) > FIXCDS B DUMMY.RECOVER.MCB PATCH(X'0030' X'000100010001') > FIXCDS B DUMMY.RECOVER.MCB EXPAND(X'0040') > FIXCDS B DUMMY.RECOVER.MCB PATCH(X'0050' + > > X'404040404040404040404040404040404040404040404040404040404040404040404040404 > FIXCDS B DUMMY.RECOVER.MCB PATCH(X'0050' > HSMBACK.BACK.T592617.DB2.ARCHLOG > FIXCDS B DUMMY.RECOVER.MCB PATCH(X'0082' BITS(0110)) > BDELETE DUMMY.RECOVER.MCB > FIXCDS B DUMMY.RECOVER.MCB DELETE > END OF - ENHANCED AUDIT - LISTING - > > I tried a HSEND BDELETE 'DB2.ARCHLOG2.A0091613' ALL . The command which I > ran in batch was successful however when I ran another AUDIT the entry > appears. I tried a HSEND FIXCDS B DB2.ARCHLOG2.A0091613. Again the command > was successful, however the AUDIT says otherwise. > > Anything else I could try? > > > On Wed, 7/26/17, willie bunter <001409bd2345-dmarc- > requ...@listserv.ua.edu> wrote: > > Subject: DFHSM QUESTION > To: IBM-MAIN@LISTSERV.UA.EDU > Received: Wednesday, July 26, 2017, 10:26 AM > > Good Day, > > I ran an AUDIT of the BCDS. I was > 99% successfull of performing a clean up execept for the following type > dsns: > ERR 40 DB2.ARCHLOG2.A0091613 > HSMBACK.BACK.T592617.DB2.ARCHLOG2.I8257 MISSING > FIXCDS B DUMMY.RECOVER.MCB > CREATE(X'0014' X'0098257F') > > FIXCDS B DUMMY.RECOVER.MCB > PATCH(X'002E' BITS(1.1.)) > > FIXCDS B DUMMY.RECOVER.MCB > PATCH(X'0030' X'000100010001') > > FIXCDS B DUMMY.RECOVER.MCB > EXPAND(X'0040') > > > FIXCDS B DUMMY.RECOVER.MCB > PATCH(X'0050' + > > > > > X'404040404040404040404040404040404040404040404040404040404040404040404040404 > FIXCDS B DUMMY.RECOVER.MCB > PATCH(X'0050' HSMBACK.BACK.T592617.DB2.ARCHLOG > FIXCDS B DUMMY.RECOVER.MCB > PATCH(X'0082' BITS(0110)) > > BDELETE DUMMY.RECOVER.MCB > > > > FIXCDS B DUMMY.RECOVER.MCB > DELETE > > > END OF - ENHANCED AUDIT - > LISTING - > > > > I tried a HSEND BDELETE > 'DB2.ARCHLOG2.A0091613' ALL . The command which I ran in batch was > successful however when I ran another AUDIT the entry appears. I tried a > HSEND FIXCDS B DB2.ARCHLOG2.A0091613. Again the command was successful, > however the AUDIT says otherwise. > > Anything else I could try? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION - REPOST
I am reposting my question because some info was truncated. I ran an AUDIT of the BCDS. I was 99% successfull of performing a clean up execept for the following type dsns: ERR 40 DB2.ARCHLOG2.A0091613 HSMBACK.BACK.T592617.DB2.ARCHLOG2.I8257 MISSING B RECORD FIXCDS B DUMMY.RECOVER.MCB CREATE(X'0014' X'0098257F') FIXCDS B DUMMY.RECOVER.MCB PATCH(X'002E' BITS(1.1.)) FIXCDS B DUMMY.RECOVER.MCB PATCH(X'0030' X'000100010001') FIXCDS B DUMMY.RECOVER.MCB EXPAND(X'0040') FIXCDS B DUMMY.RECOVER.MCB PATCH(X'0050' + X'404040404040404040404040404040404040404040404040404040404040404040404040404 FIXCDS B DUMMY.RECOVER.MCB PATCH(X'0050' HSMBACK.BACK.T592617.DB2.ARCHLOG FIXCDS B DUMMY.RECOVER.MCB PATCH(X'0082' BITS(0110)) BDELETE DUMMY.RECOVER.MCB FIXCDS B DUMMY.RECOVER.MCB DELETE END OF - ENHANCED AUDIT - LISTING - I tried a HSEND BDELETE 'DB2.ARCHLOG2.A0091613' ALL . The command which I ran in batch was successful however when I ran another AUDIT the entry appears. I tried a HSEND FIXCDS B DB2.ARCHLOG2.A0091613. Again the command was successful, however the AUDIT says otherwise. Anything else I could try? On Wed, 7/26/17, willie bunter <001409bd2345-dmarc-requ...@listserv.ua.edu> wrote: Subject: DFHSM QUESTION To: IBM-MAIN@LISTSERV.UA.EDU Received: Wednesday, July 26, 2017, 10:26 AM Good Day, I ran an AUDIT of the BCDS. I was 99% successfull of performing a clean up execept for the following type dsns: ERR 40 DB2.ARCHLOG2.A0091613 HSMBACK.BACK.T592617.DB2.ARCHLOG2.I8257 MISSING FIXCDS B DUMMY.RECOVER.MCB CREATE(X'0014' X'0098257F') FIXCDS B DUMMY.RECOVER.MCB PATCH(X'002E' BITS(1.1.)) FIXCDS B DUMMY.RECOVER.MCB PATCH(X'0030' X'000100010001') FIXCDS B DUMMY.RECOVER.MCB EXPAND(X'0040') FIXCDS B DUMMY.RECOVER.MCB PATCH(X'0050' + X'404040404040404040404040404040404040404040404040404040404040404040404040404 FIXCDS B DUMMY.RECOVER.MCB PATCH(X'0050' HSMBACK.BACK.T592617.DB2.ARCHLOG FIXCDS B DUMMY.RECOVER.MCB PATCH(X'0082' BITS(0110)) BDELETE DUMMY.RECOVER.MCB FIXCDS B DUMMY.RECOVER.MCB DELETE END OF - ENHANCED AUDIT - LISTING - I tried a HSEND BDELETE 'DB2.ARCHLOG2.A0091613' ALL . The command which I ran in batch was successful however when I ran another AUDIT the entry appears. I tried a HSEND FIXCDS B DB2.ARCHLOG2.A0091613. Again the command was successful, however the AUDIT says otherwise. Anything else I could try? -- 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
DFHSM QUESTION
Good Day, I ran an AUDIT of the BCDS. I was 99% successfull of performing a clean up execept for the following type dsns: ERR 40 DB2.ARCHLOG2.A0091613 HSMBACK.BACK.T592617.DB2.ARCHLOG2.I8257 MISSING FIXCDS B DUMMY.RECOVER.MCB CREATE(X'0014' X'0098257F') FIXCDS B DUMMY.RECOVER.MCB PATCH(X'002E' BITS(1.1.)) FIXCDS B DUMMY.RECOVER.MCB PATCH(X'0030' X'000100010001') FIXCDS B DUMMY.RECOVER.MCB EXPAND(X'0040') FIXCDS B DUMMY.RECOVER.MCB PATCH(X'0050' + X'404040404040404040404040404040404040404040404040404040404040404040404040404 FIXCDS B DUMMY.RECOVER.MCB PATCH(X'0050' HSMBACK.BACK.T592617.DB2.ARCHLOG FIXCDS B DUMMY.RECOVER.MCB PATCH(X'0082' BITS(0110)) BDELETE DUMMY.RECOVER.MCB FIXCDS B DUMMY.RECOVER.MCB DELETE END OF - ENHANCED AUDIT - LISTING - I tried a HSEND BDELETE 'DB2.ARCHLOG2.A0091613' ALL . The command which I ran in batch was successful however when I ran another AUDIT the entry appears. I tried a HSEND FIXCDS B DB2.ARCHLOG2.A0091613. Again the command was successful, however the AUDIT says otherwise. Anything else I could try? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION : ARC0506I - RE- POST
You don't really need to be good at assembler to look up the error code. OTOH, you do need to have that manual, and finding it is something of a scavenger hunt these days. Anyway, I did look it up: 0210 (528) Meaning: Requested data set unavailable. The data set is allocated to another job and its usage attribute conflicts with this request. (dsname allocation) Application Programmer Action: Change the allocation request and resubmit the request. Corresponding Message: IKJ56225I Now the rest of the verbiage in the ARC0506I message don't make much sense to me. How you could get an error code x'0210' on a "SYSOUT TYPE" dataset is beyond me. Further, why they refer you to a manual with incorrect names for the fields is rather asinine. "REAS" must mean S99ERROR, and "EXTENDED REASON CODE" must be S99INFO. Best of all, they elected not to provide any useful details like the DDNAME or DSNAME. Good luck. sas On Tue, Jul 25, 2017 at 12:37 PM, willie bunter < 001409bd2345-dmarc-requ...@listserv.ua.edu> wrote: > Hallo To All Members, > > I am trying to run the following AUDIT command: > HSEND AUDIT DATASETCONTROLS(BACKUP) FIX > > For some reason I am receiving the following error message : > ARC0506I FAILURE TO ALLOCATE SYSOUT TYPE DATA SET, > ARC0506I (CONT.) RC=04, REAS=0210, EXTENDED REASON CODE= > > The doc says "For all dynamic allocation error and information codes, see > the z/OS MVS Programming: Authorized Assembler Services Guide" > > I am not good at ASSEMBLER. Any suggestions? > > Thanks. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- sas -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION : ARC0506I - RE- POST - PROBLEM SOLVED
I found the error. The ODS(.xxx.etc.etc) was in the wrong starting column. The AUDIT is in progress. Thanks. On Tue, 7/25/17, willie bunter <001409bd2345-dmarc-requ...@listserv.ua.edu> wrote: Subject: DFHSM QUESTION : ARC0506I - RE- POST To: IBM-MAIN@LISTSERV.UA.EDU Received: Tuesday, July 25, 2017, 12:37 PM Hallo To All Members, I am trying to run the following AUDIT command: HSEND AUDIT DATASETCONTROLS(BACKUP) FIX For some reason I am receiving the following error message : ARC0506I FAILURE TO ALLOCATE SYSOUT TYPE DATA SET, ARC0506I (CONT.) RC=04, REAS=0210, EXTENDED REASON CODE= The doc says "For all dynamic allocation error and information codes, see the z/OS MVS Programming: Authorized Assembler Services Guide" I am not good at ASSEMBLER. Any suggestions? Thanks. -- 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
Re: DFHSM QUESTION -
Lizette, I re-posted my question. I had a glitch. Yes I am trying to write to a ODS. I will check the HSM guide. As a FYI I did the copy/paste of the command from another LPAR on which I last ran it. On Tue, 7/25/17, Lizette Koehler <stars...@mindspring.com> wrote: Subject: Re: DFHSM QUESTION - To: IBM-MAIN@LISTSERV.UA.EDU Received: Tuesday, July 25, 2017, 12:34 PM You might try writing to a DATASET by using ODS(output.dataset) The command is in the HSM Admin guide The REAS=0210 can be found in ISPF - Issue PF1 (HELP) two times, select I for INDEX. Enter D on the command line and select D1 - DAIR codes It is in there. Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of willie bunter > Sent: Tuesday, July 25, 2017 9:30 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: DFHSM QUESTION - > > Hallo To All Members, > > I am trying to run the following AUDIT command: > HSEND AUDIT DATASETCONTROLS(BACKUP) FIX > > For some reason I am receiving the following error message : > ARC0506I FAILURE TO ALLOCATE SYSOUT TYPE DATA SET, 862 > ARC0506I (CONT.) RC=04, REAS=0210, EXTENDED REASON CODE= -- 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
DFHSM QUESTION : ARC0506I - RE- POST
Hallo To All Members, I am trying to run the following AUDIT command: HSEND AUDIT DATASETCONTROLS(BACKUP) FIX For some reason I am receiving the following error message : ARC0506I FAILURE TO ALLOCATE SYSOUT TYPE DATA SET, ARC0506I (CONT.) RC=04, REAS=0210, EXTENDED REASON CODE= The doc says "For all dynamic allocation error and information codes, see the z/OS MVS Programming: Authorized Assembler Services Guide" I am not good at ASSEMBLER. Any suggestions? Thanks. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION -
You might try writing to a DATASET by using ODS(output.dataset) The command is in the HSM Admin guide The REAS=0210 can be found in ISPF - Issue PF1 (HELP) two times, select I for INDEX. Enter D on the command line and select D1 - DAIR codes It is in there. Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of willie bunter > Sent: Tuesday, July 25, 2017 9:30 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: DFHSM QUESTION - > > Hallo To All Members, > >I am trying to run the following AUDIT command: >HSEND AUDIT DATASETCONTROLS(BACKUP) FIX > > For some reason I am receiving the following error message : > ARC0506I FAILURE TO ALLOCATE SYSOUT TYPE DATA SET, 862 > ARC0506I (CONT.) RC=04, REAS=0210, EXTENDED REASON CODE= -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
DFHSM QUESTION -
Hallo To All Members, I am trying to run the following AUDIT command: HSEND AUDIT DATASETCONTROLS(BACKUP) FIX For some reason I am receiving the following error message : ARC0506I FAILURE TO ALLOCATE SYSOUT TYPE DATA SET, 862 ARC0506I (CONT.) RC=04, REAS=0210, EXTENDED REASON CODE= -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION
Brian, Thanks it worked. That is what I am looking for. Thanks On Fri, 6/30/17, Brian Fraser <brianmfra...@gmail.com> wrote: Subject: Re: DFHSM QUESTION To: IBM-MAIN@LISTSERV.UA.EDU Received: Friday, June 30, 2017, 11:34 AM Try like this: HSEND LIST BCDS DSNAME ODS(dsn) Brian On 29 Jun 2017 21:34, "willie bunter" < 001409bd2345-dmarc-requ...@listserv.ua.edu> wrote: Sorry, I noticed a typo. Should have read DFHSM On Thu, 6/29/17, willie bunter <001409bd2345-dmarc- requ...@listserv.ua.edu> wrote: Subject: DRHSM QUESTION To: IBM-MAIN@LISTSERV.UA.EDU Received: Thursday, June 29, 2017, 8:46 AM Hallo To All, I am trying to get a list of all dsns which have a HSM backup. I tried the following command but it listed the dsns on ML2. Can someone spot my error? HSEND LIST DSN SELECT(BACKUP) - ODS(PRODD.LIST.ALL.BACKUP) Thanks. -- 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 -- 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
Re: DFHSM QUESTION
Correct. 'MCDS' is the default. You just need to specify one of the backup keywords. Glenn -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION
Try like this: HSEND LIST BCDS DSNAME ODS(dsn) Brian On 29 Jun 2017 21:34, "willie bunter" < 001409bd2345-dmarc-requ...@listserv.ua.edu> wrote: Sorry, I noticed a typo. Should have read DFHSM On Thu, 6/29/17, willie bunter <001409bd2345-dmarc- requ...@listserv.ua.edu> wrote: Subject: DRHSM QUESTION To: IBM-MAIN@LISTSERV.UA.EDU Received: Thursday, June 29, 2017, 8:46 AM Hallo To All, I am trying to get a list of all dsns which have a HSM backup. I tried the following command but it listed the dsns on ML2. Can someone spot my error? HSEND LIST DSN SELECT(BACKUP) - ODS(PRODD.LIST.ALL.BACKUP) Thanks. -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION
Sorry, I noticed a typo. Should have read DFHSM On Thu, 6/29/17, willie bunter <001409bd2345-dmarc-requ...@listserv.ua.edu> wrote: Subject: DRHSM QUESTION To: IBM-MAIN@LISTSERV.UA.EDU Received: Thursday, June 29, 2017, 8:46 AM Hallo To All, I am trying to get a list of all dsns which have a HSM backup. I tried the following command but it listed the dsns on ML2. Can someone spot my error? HSEND LIST DSN SELECT(BACKUP) - ODS(PRODD.LIST.ALL.BACKUP) Thanks. -- 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
Re: DFHSM QUESTION
No Problem -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of esmie moo Sent: Thursday, May 25, 2017 9:15 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DFHSM QUESTION Tobias, Thanks for answering my question. From: "Cafiero, Tobias M." <tcafi...@dtcc.com> To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, May 25, 2017 8:52 AM Subject: Re: DFHSM QUESTION There are no Auto Action specified for this SG. If it is active it will fill. Yes to answer your question. Tobias Cafiero Data Resource Management Core Systems Technology Lead System Architect DTCC New York Office: 212-855-1117 E-mail: tcafi...@dtcc.com Web: www.dtcc.com <http://www.dtcc.com/ -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of esmie moo Sent: Thursday, May 25, 2017 8:38 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: DFHSM QUESTION Gentle Readers, Recently a storage group had reached a 93% level. I checked the Storage Group and this is what I found: Auto Migrate .. . N Auto Backup . . N Auto Dump . . . N Overflow. . . . N Allocation/migration Threshold : High 90 (1-100) Low . . 40 (0-99) Alloc/Migr Threshold Track-Managed: High 85 (1-100) Low . . 1 (0-99) Guaranteed Backup Frequency . . . . . . NOLIMIT (1 to or NOLIMIT) Can I correctly assume that the above threshold values will be ignored because there is no MIGRATION? Thanks. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN DTCC DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify us immediately and delete the email and any attachments from your system. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. -- 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 DTCC DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify us immediately and delete the email and any attachments from your system. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION
Tobias, Thanks for answering my question. From: "Cafiero, Tobias M." <tcafi...@dtcc.com> To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, May 25, 2017 8:52 AM Subject: Re: DFHSM QUESTION There are no Auto Action specified for this SG. If it is active it will fill. Yes to answer your question. Tobias Cafiero Data Resource Management Core Systems Technology Lead System Architect DTCC New York Office: 212-855-1117 E-mail: tcafi...@dtcc.com Web: www.dtcc.com <http://www.dtcc.com/ -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of esmie moo Sent: Thursday, May 25, 2017 8:38 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: DFHSM QUESTION Gentle Readers, Recently a storage group had reached a 93% level. I checked the Storage Group and this is what I found: Auto Migrate .. . N Auto Backup . . N Auto Dump . . . N Overflow. . . . N Allocation/migration Threshold : High 90 (1-100) Low . . 40 (0-99) Alloc/Migr Threshold Track-Managed: High 85 (1-100) Low . . 1 (0-99) Guaranteed Backup Frequency . . . . . . NOLIMIT (1 to or NOLIMIT) Can I correctly assume that the above threshold values will be ignored because there is no MIGRATION? Thanks. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN DTCC DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify us immediately and delete the email and any attachments from your system. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. -- 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
Re: DFHSM QUESTION
There are no Auto Action specified for this SG. If it is active it will fill. Yes to answer your question. Tobias Cafiero Data Resource Management Core Systems Technology Lead System Architect DTCC New York Office: 212-855-1117 E-mail: tcafi...@dtcc.com Web: www.dtcc.com <http://www.dtcc.com/ -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of esmie moo Sent: Thursday, May 25, 2017 8:38 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: DFHSM QUESTION Gentle Readers, Recently a storage group had reached a 93% level. I checked the Storage Group and this is what I found: Auto Migrate .. . N Auto Backup . . N Auto Dump . . . N Overflow. . . . N Allocation/migration Threshold : High 90 (1-100) Low . . 40 (0-99) Alloc/Migr Threshold Track-Managed: High 85 (1-100) Low . . 1 (0-99) Guaranteed Backup Frequency . . . . . . NOLIMIT (1 to or NOLIMIT) Can I correctly assume that the above threshold values will be ignored because there is no MIGRATION? Thanks. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN DTCC DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify us immediately and delete the email and any attachments from your system. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
DFHSM QUESTION
Gentle Readers, Recently a storage group had reached a 93% level. I checked the Storage Group and this is what I found: Auto Migrate .. . N Auto Backup . . N Auto Dump . . . N Overflow. . . . N Allocation/migration Threshold : High 90 (1-100) Low . . 40 (0-99) Alloc/Migr Threshold Track-Managed: High 85 (1-100) Low . . 1 (0-99) Guaranteed Backup Frequency . . . . . . NOLIMIT (1 to or NOLIMIT) Can I correctly assume that the above threshold values will be ignored because there is no MIGRATION? Thanks. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION - RECOVER DSN FROM ML2 VOLUME
willie bunter wrote: >I have great news. I found the missing dsn and the volser from the >HSM.JOURNAL.BACKUP.V0009984 file. Thanks to all who helped with their >suggestions and support. Excellent! That is a great accomplishment! Another war story! ;-) Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION - RECOVER DSN FROM ML2 VOLUME
Good Day To All, I have great news. I found the missing dsn and the volser from the HSM.JOURNAL.BACKUP.V0009984 file. Thanks to all who helped with their suggestions and support. . On Mon, 6/20/16, Greg Shirey <wgshi...@benekeith.com> wrote: Subject: Re: DFHSM QUESTION - RECOVER DSN FROM ML2 VOLUME To: IBM-MAIN@LISTSERV.UA.EDU Received: Monday, June 20, 2016, 5:29 PM Willie has already posted that there is no backup. The data set along with the catalog entry has been deleted - as long as the ML2 tape has not been recycled, it can be retrieved from there. There is a documented procedure for doing this in the HSM administration manual. Regards, Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Walter Davies Sent: Monday, June 20, 2016 4:11 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DFHSM QUESTION - RECOVER DSN FROM ML2 VOLUME Just because you delete a data set if it has backups they might still be there. Try allocating the old DSN as empty and restore from a backup. I have done that before. -- 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
Re: DFHSM QUESTION - RECOVER DSN FROM ML2 VOLUME
Willie has already posted that there is no backup. The data set along with the catalog entry has been deleted - as long as the ML2 tape has not been recycled, it can be retrieved from there. There is a documented procedure for doing this in the HSM administration manual. Regards, Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Walter Davies Sent: Monday, June 20, 2016 4:11 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DFHSM QUESTION - RECOVER DSN FROM ML2 VOLUME Just because you delete a data set if it has backups they might still be there. Try allocating the old DSN as empty and restore from a backup. I have done that before. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION - RECOVER DSN FROM ML2 VOLUME
Just because you delete a data set if it has backups they might still be there. Try allocating the old DSN as empty and restore from a backup. I have done that before. On Mon, Jun 20, 2016 at 2:02 PM, willie bunter < 001409bd2345-dmarc-requ...@listserv.ua.edu> wrote: > Elardus > > The user said that she did a HDEL besides the dsn. I did a HLIST however > it was unsuccessful. > > I am looking at the suggestion posted earlier about the doc to recover a > deleted ML2 dsn. > > > On Mon, 6/20/16, Elardus Engelbrecht <elardus.engelbre...@sita.co.za> > wrote: > > Subject: Re: DFHSM QUESTION - RECOVER DSN FROM ML2 VOLUME > To: IBM-MAIN@LISTSERV.UA.EDU > Received: Monday, June 20, 2016, 1:58 PM > > willie bunter wrote: > > >I am checking the journal file hoping to find any trace > of the dsn. I don't have a backup of the dsn that is > why I am trying to find the ML2 volser. > > Urggg. I feel your pain. As a previous Storage Admin > I had to handle those pain. > > > >I cannot issue the HRECALL because the dsn doesn't > exist. The same reason I cannot issue the HRECOVER > because there is no backup. > > Ok. Let us go back. Did you ever issued the HLIST command as > kindly suggested by Lizette? > > If so, then I retract my question. Sorry for being > bothersome. > > Please show us HOW that dataset was deleted (Post JCL + > messages confirming that action). > > Perhaps it was just uncataloged / renamed or such? (SMF > audit trails could help you there) > > Or use ISMF to scan your volsers to see if there is a > [uncataloged] copy lurking somewhere... > > Perhaps you can scan your tape management system to see if > there is a copy sitting somewhere? > > Or do you have any Peer-to-Peer Remote Copy [1] or similar > technology? Perhaps there is a version sitting on your > remote site? > > Groete / Greetings > Elardus Engelbrecht > > [1] - I know that any actions are immediately duplicated to > remote, but perhaps the line was hopefully down or > something? > > -- > 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 > -- Walter Davies Supervising IT Analyst walter.dav...@edcgov.us (530) 621-5420 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION - RECOVER DSN FROM ML2 VOLUME
Elardus The user said that she did a HDEL besides the dsn. I did a HLIST however it was unsuccessful. I am looking at the suggestion posted earlier about the doc to recover a deleted ML2 dsn. On Mon, 6/20/16, Elardus Engelbrecht <elardus.engelbre...@sita.co.za> wrote: Subject: Re: DFHSM QUESTION - RECOVER DSN FROM ML2 VOLUME To: IBM-MAIN@LISTSERV.UA.EDU Received: Monday, June 20, 2016, 1:58 PM willie bunter wrote: >I am checking the journal file hoping to find any trace of the dsn. I don't have a backup of the dsn that is why I am trying to find the ML2 volser. Urggg. I feel your pain. As a previous Storage Admin I had to handle those pain. >I cannot issue the HRECALL because the dsn doesn't exist. The same reason I cannot issue the HRECOVER because there is no backup. Ok. Let us go back. Did you ever issued the HLIST command as kindly suggested by Lizette? If so, then I retract my question. Sorry for being bothersome. Please show us HOW that dataset was deleted (Post JCL + messages confirming that action). Perhaps it was just uncataloged / renamed or such? (SMF audit trails could help you there) Or use ISMF to scan your volsers to see if there is a [uncataloged] copy lurking somewhere... Perhaps you can scan your tape management system to see if there is a copy sitting somewhere? Or do you have any Peer-to-Peer Remote Copy [1] or similar technology? Perhaps there is a version sitting on your remote site? Groete / Greetings Elardus Engelbrecht [1] - I know that any actions are immediately duplicated to remote, but perhaps the line was hopefully down or something? -- 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
Re: DFHSM QUESTION - RECOVER DSN FROM ML2 VOLUME
In the z/OS 1.13 DFSMShsm Storage Admin manual, there is a page titled: 1.20.9 Case 9: Reestablish access to previously deleted migrated data sets (no backup exists, ML2 only) Here is a link: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dgt2s6a2/1.20.9?SHELF=ALL13BE9=20120808094757 Back when I worked at a shop that had HSM, I had to use this procedure several times. I would assume it is still valid. Note, however, that the last step reads: " If you follow all steps correctly and you are still unable to recall the data set, contact IBM Support." Regards, Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Monday, June 20, 2016 1:48 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DFHSM QUESTION - RECOVER DSN FROM ML2 VOLUME If the problem is the dataset was just plain deleted and there is no longer a catalog entry, you need to find a full volume or other DR volume backup for recovery. DFHSM will have nothing available to you. If there is anything left in DFHSM, then either a product like VANTAGE with the DFHSM function included could help. Otherwise contact IBM. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION - RECOVER DSN FROM ML2 VOLUME
So I will use an infamous phrase here: Open an SR with IBM before you do
anything else.
Sometimes they have tools that can help you or at least provide guidance that
this list may not be privy to.
Next, you need to know what volume the dataset resided on.
If you do full volume dumps - weekly, monthly or daily - you might have a
chance to find the dataset.
DFHSM only knows what it knows. If you did a physical delete and not removed
the catalog entry, then you should see a LISTC or 3.4 entry for
Data_set_Deleted_Name MIGRAT
If the problem is the dataset was just plain deleted and there is no longer a
catalog entry, you need to find a full volume or other DR volume backup for
recovery.
DFHSM will have nothing available to you. If there is anything left in DFHSM,
then either a product like VANTAGE with the DFHSM function included could help.
Otherwise contact IBM.
Please explain further what is the specific events and issues.
Otherwise, open an SR with IBM quick.
Lizette
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Staller, Allan
> Sent: Monday, June 20, 2016 10:30 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: DFHSM QUESTION - RECOVER DSN FROM ML2 VOLUME
>
> If the dataset was *DELETED* you will have a tough time.
>
> If the dataset was uncataloged,
>
> DEF NVSAM(name('dsn') DEVT() VOL(MIGRAT)
>
> And then recall the dataset.
>
>
> I cannot issue the HRECALL because the dsn doesn't exist. The same reason I
> cannot issue the HRECOVER because there is no backup.
>
>
>
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION - RECOVER DSN FROM ML2 VOLUME
On 06/20/2016 12:19 PM, willie bunter wrote: > Hallo to All, > > The dsn was migrated about 2 years ago and for some reason it was deleted > today (in error). I am dusting off some old doc and as I had said earlier I > am checking to see what I did. Keep you all posted if I stumble on to > something. > > > On Mon, 6/20/16, Lizette Koehler <stars...@mindspring.com> wrote: > > Subject: Re: DFHSM QUESTION - RECOVER DSN FROM ML2 VOLUME > To: IBM-MAIN@LISTSERV.UA.EDU > Received: Monday, June 20, 2016, 12:41 PM > > If your first statement > is No BACKUP has been taken, then the file is most likely > lost. > > When was the file > migrated? > > Can you show us > the results from a HLIST dsn(/) BOTH > > It will help to know when it was migrated. > > CDS Backups and Journals can > be performed anytime. You just have to know what kind of > performance impact will be felt while it is running > > > Lizette > > > > -Original > Message- > > From: IBM Mainframe > Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On > > Behalf Of willie bunter > > Sent: Monday, June 20, 2016 9:35 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: DFHSM QUESTION - RECOVER DSN FROM > ML2 VOLUME > > > > Good > Day To All, > > > > I > would like to recover a dsn which was migrated to ML2. > Because of a mistake > > in the assigning > of the management class no back up was taken. > > > > I remember > recovering a dsn under the same circumstances. I remember > locating > > the dsn in the > HSM.JOURNAL.BACKUP.V000 (found in column 13 in HEX) and > the > > volser of the ML2. (which I found > in column 77) > > > > I > browsed the online HSM.JOURNAL (using the first and second > HLQ) however I > > was unable to locate > the dsn. My question is do I need to wait for the CDS > > Journal backup to be run (which will > execute tonight at 8 p.m) or is there > > > something else I can try? > > > > Thanks. > > > > -- > ... Depending on how desperate you are to recover the data: If you don't delay and (1) you act before the physical tape that contained the ML2 data set is recycled or physically scratched, (2) you save recent backups of the production DFHSM control data sets made from before the ML2 data set was deleted, and (3) you have access to an isolated test z/OS system which has access to tape drives and on which you can bring up a test DFHSM; then it should be possible to ON THE TEST z/OS SYSTEM: Port the old DFHSM data sets to the test system and bring up DFHSM on those old data sets with everything HELD except for recall; optionally set up an isolated user catalog and alias for the lost data set; catalog (with IDCAMS) the lost data set to VOLSER MIGRAT; set up any ACS definitions and/or storage pools needed to support a recall of the data set (this doesn't need to replicate the production environment as long as the STORCLAS of the data sets maps to a pool with adequate space -- don't know if MGMTCLAS and DATACLAS have to be defined on test system for recall to work); HRECALL the data set to the test storage pool; Use dss to make a tape backup of the data set that can be ported back to production; ON THE PRODUCTION SYSTEM: Read and restore the data set from tape written on test z/OS using dss on the production system; ON THE TEST z/OS SYSTEM: Clean up the no-longer-needed stuff created on the test z/OS system. This is potentially a lot of work and may require some experimentation to get all the pieces right.. I'm pretty sure I actually did this once or twice; but it took the better part of a day and was a long time ago. -- Joel C. Ewing,Bentonville, AR jcew...@acm.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION - RECOVER DSN FROM ML2 VOLUME
willie bunter wrote: >I am checking the journal file hoping to find any trace of the dsn. I don't >have a backup of the dsn that is why I am trying to find the ML2 volser. Urggg. I feel your pain. As a previous Storage Admin I had to handle those pain. >I cannot issue the HRECALL because the dsn doesn't exist. The same reason I >cannot issue the HRECOVER because there is no backup. Ok. Let us go back. Did you ever issued the HLIST command as kindly suggested by Lizette? If so, then I retract my question. Sorry for being bothersome. Please show us HOW that dataset was deleted (Post JCL + messages confirming that action). Perhaps it was just uncataloged / renamed or such? (SMF audit trails could help you there) Or use ISMF to scan your volsers to see if there is a [uncataloged] copy lurking somewhere... Perhaps you can scan your tape management system to see if there is a copy sitting somewhere? Or do you have any Peer-to-Peer Remote Copy [1] or similar technology? Perhaps there is a version sitting on your remote site? Groete / Greetings Elardus Engelbrecht [1] - I know that any actions are immediately duplicated to remote, but perhaps the line was hopefully down or something? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION - RECOVER DSN FROM ML2 VOLUME
If the dataset was *DELETED* you will have a tough time.
If the dataset was uncataloged,
DEF NVSAM(name('dsn') DEVT() VOL(MIGRAT)
And then recall the dataset.
I cannot issue the HRECALL because the dsn doesn't exist. The same reason I
cannot issue the HRECOVER because there is no backup.
This email � including attachments � may contain confidential information. If
you are not the intended recipient, do not copy, distribute or act on it.
Instead, notify the sender immediately and delete the message.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION - RECOVER DSN FROM ML2 VOLUME
I am checking the journal file hoping to find any trace of the dsn. I don't have a backup of the dsn that is why I am trying to find the ML2 volser. I cannot issue the HRECALL because the dsn doesn't exist. The same reason I cannot issue the HRECOVER because there is no backup. On Mon, 6/20/16, retired mainframer <retired-mainfra...@q.com> wrote: Subject: Re: DFHSM QUESTION - RECOVER DSN FROM ML2 VOLUME To: IBM-MAIN@LISTSERV.UA.EDU Received: Monday, June 20, 2016, 1:05 PM Why are you looking in the JOURNAL? It contains only "recent" data since the last CDS backup. How long ago was the dataset migrated? To find the DSN, you need to look in the backup copy that covers the time frame when the migration occurred. But if you need to look up anything about the dataset, you really should be looking in the MCDS. Why do you think you need to know the ML2 volume? ML2 datasets are catalogued on MIGRAT2. Does the DSN show up in 3.4? What happens if you issue an HRECALL against the DSN? If the migrated copy is valid, that should be all you need. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of willie bunter > Sent: Monday, June 20, 2016 9:35 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: DFHSM QUESTION - RECOVER DSN FROM ML2 VOLUME > > Good Day To All, > > I would like to recover a dsn which was migrated to ML2. Because of a mistake in the > assigning of the management class no back up was taken. > > I remember recovering a dsn under the same circumstances. I remember locating the dsn in > the HSM.JOURNAL.BACKUP.V000 (found in column 13 in HEX) and the volser of > the ML2. (which I found in column 77) > > I browsed the online HSM.JOURNAL (using the first and second HLQ) however I was > unable to locate the dsn. My question is do I need to wait for the CDS Journal backup to be > run (which will execute tonight at 8 p.m) or is there something else I can try? -- 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
Re: DFHSM QUESTION - RECOVER DSN FROM ML2 VOLUME
Hallo to All, The dsn was migrated about 2 years ago and for some reason it was deleted today (in error). I am dusting off some old doc and as I had said earlier I am checking to see what I did. Keep you all posted if I stumble on to something. On Mon, 6/20/16, Lizette Koehler <stars...@mindspring.com> wrote: Subject: Re: DFHSM QUESTION - RECOVER DSN FROM ML2 VOLUME To: IBM-MAIN@LISTSERV.UA.EDU Received: Monday, June 20, 2016, 12:41 PM If your first statement is No BACKUP has been taken, then the file is most likely lost. When was the file migrated? Can you show us the results from a HLIST dsn(/) BOTH It will help to know when it was migrated. CDS Backups and Journals can be performed anytime. You just have to know what kind of performance impact will be felt while it is running Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of willie bunter > Sent: Monday, June 20, 2016 9:35 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: DFHSM QUESTION - RECOVER DSN FROM ML2 VOLUME > > Good Day To All, > > I would like to recover a dsn which was migrated to ML2. Because of a mistake > in the assigning of the management class no back up was taken. > > I remember recovering a dsn under the same circumstances. I remember locating > the dsn in the HSM.JOURNAL.BACKUP.V000 (found in column 13 in HEX) and the > volser of the ML2. (which I found in column 77) > > I browsed the online HSM.JOURNAL (using the first and second HLQ) however I > was unable to locate the dsn. My question is do I need to wait for the CDS > Journal backup to be run (which will execute tonight at 8 p.m) or is there > something else I can try? > > Thanks. > -- 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
Re: DFHSM QUESTION - RECOVER DSN FROM ML2 VOLUME
Why are you looking in the JOURNAL? It contains only "recent" data since the last CDS backup. How long ago was the dataset migrated? To find the DSN, you need to look in the backup copy that covers the time frame when the migration occurred. But if you need to look up anything about the dataset, you really should be looking in the MCDS. Why do you think you need to know the ML2 volume? ML2 datasets are catalogued on MIGRAT2. Does the DSN show up in 3.4? What happens if you issue an HRECALL against the DSN? If the migrated copy is valid, that should be all you need. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of willie bunter > Sent: Monday, June 20, 2016 9:35 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: DFHSM QUESTION - RECOVER DSN FROM ML2 VOLUME > > Good Day To All, > > I would like to recover a dsn which was migrated to ML2. Because of a > mistake in the > assigning of the management class no back up was taken. > > I remember recovering a dsn under the same circumstances. I remember > locating the dsn in > the HSM.JOURNAL.BACKUP.V000 (found in column 13 in HEX) and the volser of > the ML2. (which I found in column 77) > > I browsed the online HSM.JOURNAL (using the first and second HLQ) however I > was > unable to locate the dsn. My question is do I need to wait for the CDS > Journal backup to be > run (which will execute tonight at 8 p.m) or is there something else I can > try? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION - RECOVER DSN FROM ML2 VOLUME
Why would the absence of a backup have any impact on the ability to recall a migrated dataset? > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Lizette Koehler > Sent: Monday, June 20, 2016 9:41 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: DFHSM QUESTION - RECOVER DSN FROM ML2 VOLUME > > If your first statement is No BACKUP has been taken, then the file is most > likely lost. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION - RECOVER DSN FROM ML2 VOLUME
Why not just HRECALL the dataset? Of course, if the migrated copy is the damaged dataset, and there are no backups, you are out of luck. I would like to recover a dsn which was migrated to ML2. Because of a mistake in the assigning of the management class no back up was taken. I remember recovering a dsn under the same circumstances. I remember locating the dsn in the HSM.JOURNAL.BACKUP.V000 (found in column 13 in HEX) and the volser of the ML2. (which I found in column 77) I browsed the online HSM.JOURNAL (using the first and second HLQ) however I was unable to locate the dsn. My question is do I need to wait for the CDS Journal backup to be run (which will execute tonight at 8 p.m) or is there something else I can try? This email � including attachments � may contain confidential information. If you are not the intended recipient, do not copy, distribute or act on it. Instead, notify the sender immediately and delete the message. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION - RECOVER DSN FROM ML2 VOLUME
If your first statement is No BACKUP has been taken, then the file is most likely lost. When was the file migrated? Can you show us the results from a HLIST dsn(/) BOTH It will help to know when it was migrated. CDS Backups and Journals can be performed anytime. You just have to know what kind of performance impact will be felt while it is running Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of willie bunter > Sent: Monday, June 20, 2016 9:35 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: DFHSM QUESTION - RECOVER DSN FROM ML2 VOLUME > > Good Day To All, > > I would like to recover a dsn which was migrated to ML2. Because of a mistake > in the assigning of the management class no back up was taken. > > I remember recovering a dsn under the same circumstances. I remember locating > the dsn in the HSM.JOURNAL.BACKUP.V000 (found in column 13 in HEX) and the > volser of the ML2. (which I found in column 77) > > I browsed the online HSM.JOURNAL (using the first and second HLQ) however I > was unable to locate the dsn. My question is do I need to wait for the CDS > Journal backup to be run (which will execute tonight at 8 p.m) or is there > something else I can try? > > Thanks. > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
DFHSM QUESTION - RECOVER DSN FROM ML2 VOLUME
Good Day To All, I would like to recover a dsn which was migrated to ML2. Because of a mistake in the assigning of the management class no back up was taken. I remember recovering a dsn under the same circumstances. I remember locating the dsn in the HSM.JOURNAL.BACKUP.V000 (found in column 13 in HEX) and the volser of the ML2. (which I found in column 77) I browsed the online HSM.JOURNAL (using the first and second HLQ) however I was unable to locate the dsn. My question is do I need to wait for the CDS Journal backup to be run (which will execute tonight at 8 p.m) or is there something else I can try? Thanks. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
DFHSM QUESTION : ARC0036E I/O INHIBITED FOR DFSMSHSM PROBLEM
Hallo All, I noticed in the HSM startup the following error messages: ARC0037I DFSMSHSM PROBLEM DETERMINATION OUTPUT DATA 679 ARC0037I (CONT.) SETS SWITCHED, ARCPDOX=HSM.HSMPDOXC, ARC0037I (CONT.) ARCPDOY=HSM.HSMPDOYC IEC145I 413-04,IFG0194A,DFHSMC,DFHSMC,ARCPDOX,8612,SYS226, HSM.HSMPDOXC ARC0036E I/O INHIBITED FOR DFSMSHSM PROBLEM 682 ARC0036E (CONT.) DETERMINATION OUTPUT DATA SET, REAS= 3 I checked the error message for ARC0036E and it says the following : A failure occurred while attempting to open the ARCPDOX data set It doesn't tell me very much. I noticed that the dsn is at 16 extents. Could this be the cause of the problem? If so, I will have to enlargen both PDA dsns. Could someone shed some light on this? Thanks. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION : ARC0036E I/O INHIBITED FOR DFSMSHSM PROBLEM
Lizette, I checked last week's STC there is no record of the logs being swapped. I stumbled on some procedures and the first last step in it is to do a HSEND SETSYS PDA(ON) and the last step is to do a HSEND SETSYS PDA(OFF) I assume that the PDA is set to OFF when the STC starts up. The dsns are written on DASD. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION : ARC0036E I/O INHIBITED FOR DFSMSHSM PROBLEM
The problem is the S413-04 abend. Basically this says that there is a problem opening with HSM.HSMPDOCX. In particular not all volumes can be mounted. What volume is this DSN catalogued on? Is that volume on-line to your system? We had a similar problem when some accidentally did a VARY ,OFFLINE and the volume was 'PENDING OFFLINE' in the D U display. A simple VARY ,ONLINE fixed the problem for us. Hopefully it is as simple for you. On Mon, Mar 30, 2015 at 8:15 AM, willie bunter 001409bd2345-dmarc-requ...@listserv.ua.edu wrote: Hallo All, I noticed in the HSM startup the following error messages: ARC0037I DFSMSHSM PROBLEM DETERMINATION OUTPUT DATA 679 ARC0037I (CONT.) SETS SWITCHED, ARCPDOX=HSM.HSMPDOXC, ARC0037I (CONT.) ARCPDOY=HSM.HSMPDOYC IEC145I 413-04,IFG0194A,DFHSMC,DFHSMC,ARCPDOX,8612,SYS226, HSM.HSMPDOXC ARC0036E I/O INHIBITED FOR DFSMSHSM PROBLEM 682 ARC0036E (CONT.) DETERMINATION OUTPUT DATA SET, REAS= 3 I checked the error message for ARC0036E and it says the following : A failure occurred while attempting to open the ARCPDOX data set It doesn't tell me very much. I noticed that the dsn is at 16 extents. Could this be the cause of the problem? If so, I will have to enlargen both PDA dsns. Could someone shed some light on this? Thanks. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- If you sent twitter messages while exploring, are you on a textpedition? He's about as useful as a wax frying pan. 10 to the 12th power microphones = 1 Megaphone Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION : ARC0036E I/O INHIBITED FOR DFSMSHSM PROBLEM
Lizette, Sorry I forgot to answer the question about the size of the dsns. This is what it is at: Organization . . . : PS Current Utilization Record format . . . : VB Used cylinders . . : 158 Record length . . . : 1024Used extents . . . : 16 Block size . . . . : 27652 1st extent cylinders: 128 Secondary cylinders : 2 Dates -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION : ARC0036E I/O INHIBITED FOR DFSMSHSM PROBLEM
Our site have been running into this problem for months. You can only have 2 *.HSMPDO* datasets on one volume. When one fills ups, HSM switches datasets (via a rename) and a task is submitted to write out the full one to *.PDA GDG PS dataset. If one dataset fills up before the other one is emptied, the writing to the HSMPDO datasets is stopped and you get this list of messages. The only solution is to increase the size of the HSMPDO datasets until you don't get this message any more. Suggested sizing per IBM manual is 1-3 hours of output per HSMPDO. The problem comes during migration periods where it is filling and swapping every few minutes until it completes. On Mon, Mar 30, 2015 at 8:15 AM, willie bunter 001409bd2345-dmarc-requ...@listserv.ua.edu wrote: Hallo All, I noticed in the HSM startup the following error messages: ARC0037I DFSMSHSM PROBLEM DETERMINATION OUTPUT DATA 679 ARC0037I (CONT.) SETS SWITCHED, ARCPDOX=HSM.HSMPDOXC, ARC0037I (CONT.) ARCPDOY=HSM.HSMPDOYC IEC145I 413-04,IFG0194A,DFHSMC,DFHSMC,ARCPDOX,8612,SYS226, HSM.HSMPDOXC ARC0036E I/O INHIBITED FOR DFSMSHSM PROBLEM 682 ARC0036E (CONT.) DETERMINATION OUTPUT DATA SET, REAS= 3 I checked the error message for ARC0036E and it says the following : A failure occurred while attempting to open the ARCPDOX data set It doesn't tell me very much. I noticed that the dsn is at 16 extents. Could this be the cause of the problem? If so, I will have to enlargen both PDA dsns. Could someone shed some light on this? Thanks. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION : ARC0036E I/O INHIBITED FOR DFSMSHSM PROBLEM
I verified the volumes are ONLINE for the PDA dsns. Something also very strange. I was under the impression that the HSM.HSMPDOXC the HSM.HSMPDOYC were never re-allocated and were reused everytime HSM STC was started up. For some reason I noticed that the dsns were on different volumes the week previous. I will have to check the SMF records to fine the reson. Do both the HSM.HSMPDOXC HSM.HSMPDOyC have to reside on the same volume? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION : ARC0036E I/O INHIBITED FOR DFSMSHSM PROBLEM
Yes. From the Fine Manual: DFSMShsm Implementation and Customization Guide Version 2 Release 1 PP 41-42_ SC23-6869-01 (z/OS 2.1) quote Storage guidance: Both the ARCPDOX and ARCPDOY data sets must be on the same volume. The amount and type of storage you use for your PDA log data sets depends on how much trace history you want to keep. To determine the amount and type of storage, you can use either the short-term work sheet found in “Problem determination aid log data set size work sheet—Short-term trace history” on page 388 or the long-term work sheet found in “Problem determination aid log data set size work sheet—Long-term trace history” on page 390. /quote I doubt this is a new requirement. It has most likely been there for eons… snip Do both the HSM.HSMPDOXC HSM.HSMPDOyC have to reside on the same volume? /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION : ARC0036E I/O INHIBITED FOR DFSMSHSM PROBLEM
Willie, How often do you swap PDA and LOGs for HSM. You should have a process that will offload them when a B37 occurs. Is this DASD or TAPE datasets? If DASD, what is the size/space used? Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of willie bunter Sent: Monday, March 30, 2015 6:15 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: DFHSM QUESTION : ARC0036E I/O INHIBITED FOR DFSMSHSM PROBLEM Hallo All, I noticed in the HSM startup the following error messages: ARC0037I DFSMSHSM PROBLEM DETERMINATION OUTPUT DATA 679 ARC0037I (CONT.) SETS SWITCHED, ARCPDOX=HSM.HSMPDOXC, ARC0037I (CONT.) ARCPDOY=HSM.HSMPDOYC IEC145I 413-04,IFG0194A,DFHSMC,DFHSMC,ARCPDOX,8612,SYS226, HSM.HSMPDOXC ARC0036E I/O INHIBITED FOR DFSMSHSM PROBLEM 682 ARC0036E (CONT.) DETERMINATION OUTPUT DATA SET, REAS= 3 I checked the error message for ARC0036E and it says the following : A failure occurred while attempting to open the ARCPDOX data set It doesn't tell me very much. I noticed that the dsn is at 16 extents. Could this be the cause of the problem? If so, I will have to enlargen both PDA dsns. Could someone shed some light on this? Thanks. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION : ARC0036E I/O INHIBITED FOR DFSMSHSM PROBLEM
Willie - Do you have automation in place so that when the PDA gets a D37 it swaps the log? http://www-01.ibm.com/support/docview.wss?uid=isg3T1012687 IEC031I D37-04,IFG0554P,HSM,HSM,ARCPDOX,3099,HSMP05,MYHSM.LPAR7.HSMPDOX OPS1181O HSM OPSS (*Local*) MVS N/A MESSAGE.ARC0037I START OPSSJOB,N=PDALPAR7 START OPSSJOB,N=PDALPAR7 ARC0037I HSM PROBLEM DETERMINATION OUTPUT DATA 968 ARC0037I (CONT.) SETS SWITCHED, ARCPDOX=MYHSM.LPAR7.HSMPDOX, ARC0037I (CONT.) ARCPDOY=MYHSM.LPAR7.HSMPDOY Mine at 1500 cylinders each Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Willie Bunter Sent: Monday, March 30, 2015 7:23 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DFHSM QUESTION : ARC0036E I/O INHIBITED FOR DFSMSHSM PROBLEM Lizette, I checked last week's STC there is no record of the logs being swapped. I stumbled on some procedures and the first last step in it is to do a HSEND SETSYS PDA(ON) and the last step is to do a HSEND SETSYS PDA(OFF) I assume that the PDA is set to OFF when the STC starts up. The dsns are written on DASD. -- 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
Re: DFHSM QUESTION : ARC0036E I/O INHIBITED FOR DFSMSHSM PROBLEM
Allan, No, they both do not reside on the same volume. I think someone moved the dsns to different volumes. I will check the SMF records to find out more details. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION : ARC0036E I/O INHIBITED FOR DFSMSHSM PROBLEM
Lizette, I scanned through the whole output but there was no IEC031I D37-04. However I remember in the past seeing those messages especially when I was migrating volumes. Unfortunately the STC output is only available for the past 2 startups and both do not have the IEC031I D37-04 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION : ARC0036E I/O INHIBITED FOR DFSMSHSM PROBLEM
Additional Information: The HSMPDO datasets are expected to be re-used by DFhsm. The HSMPDOX/Y datasets are toggled as needed. I would allocate them a some specific size w/no secondary extents. When HSMPDOX is filled, HSM will automatically switch to HSMPDOY. When HSMPDOY is filled, HSM will automatically switch back to HSMPDOX. HTH, From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Staller, Allan Sent: Monday, March 30, 2015 9:40 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DFHSM QUESTION : ARC0036E I/O INHIBITED FOR DFSMSHSM PROBLEM Yes. From the Fine Manual: DFSMShsm Implementation and Customization Guide Version 2 Release 1 PP 41-42_ SC23-6869-01 (z/OS 2.1) quote Storage guidance: Both the ARCPDOX and ARCPDOY data sets must be on the same volume. The amount and type of storage you use for your PDA log data sets depends on how much trace history you want to keep. To determine the amount and type of storage, you can use either the short-term work sheet found in “Problem determination aid log data set size work sheet—Short-term trace history” on page 388 or the long-term work sheet found in “Problem determination aid log data set size work sheet—Long-term trace history” on page 390. /quote I doubt this is a new requirement. It has most likely been there for eons… snip Do both the HSM.HSMPDOXC HSM.HSMPDOyC have to reside on the same volume? /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION : ARC0036E I/O INHIBITED FOR DFSMSHSM PROBLEM
Alan, Thanks for the tip. I will reallocate the dsns on the same volume with a larger space. Thanks for the tip. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION : ARC0036E I/O INHIBITED FOR DFSMSHSM PROBLEM
Just for completeness, here is the technote. http://www-01.ibm.com/support/docview.wss?uid=isg3T1012687 On Mon, Mar 30, 2015 at 8:15 AM, willie bunter 001409bd2345-dmarc-requ...@listserv.ua.edu wrote: Hallo All, I noticed in the HSM startup the following error messages: ARC0037I DFSMSHSM PROBLEM DETERMINATION OUTPUT DATA 679 ARC0037I (CONT.) SETS SWITCHED, ARCPDOX=HSM.HSMPDOXC, ARC0037I (CONT.) ARCPDOY=HSM.HSMPDOYC IEC145I 413-04,IFG0194A,DFHSMC,DFHSMC,ARCPDOX,8612,SYS226, HSM.HSMPDOXC ARC0036E I/O INHIBITED FOR DFSMSHSM PROBLEM 682 ARC0036E (CONT.) DETERMINATION OUTPUT DATA SET, REAS= 3 I checked the error message for ARC0036E and it says the following : A failure occurred while attempting to open the ARCPDOX data set It doesn't tell me very much. I noticed that the dsn is at 16 extents. Could this be the cause of the problem? If so, I will have to enlargen both PDA dsns. Could someone shed some light on this? Thanks. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION - EXPIRATION OF DSN
I don't think so. Or if you are right then there are some big issues in the next few years that IBM's own products won't be able to support. As an example IBM semi announced that soon there will be dynamic storage(DASD) expansion and it will be done with volser (ex ABC001,ABC002 etc etc) ie adding volsers without having to update the ACS routines and DFDSS statements/ or DD JCL and this will apparently include DFHSM and any other product that needs Backup/restore generic volsers. DMS had this ability *LONG TIME AGO*. I don't see any issue about integrity with items like that (in fact our DASD boss when the MSS came in worked with the DMS people to support the concept of MVSGRP in DMS, IBM never did it. Ed On Oct 30, 2014, at 12:48 AM, Elardus Engelbrecht wrote: Ed Gould wrote: There are still quite a few items that DFDSS hasn't caught up with but thats a different horse to flog. Although I was reading an article about z/OS and there are a few things percolating up the like dynamic DASD and the like that will make us wonder why it took so long. Possible reasons: Backward compatibility issues? No business case to catch up? Integrity issues? Groete / Greetings Elardus Engelbrecht -- 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
Re: DFHSM QUESTION - EXPIRATION OF DSN
We put unused volsers into SMS Storage groups then init actual volumes when more space is needed. On Thu, Oct 30, 2014 at 12:20 PM, Ed Gould edgould1...@comcast.net wrote: I don't think so. Or if you are right then there are some big issues in the next few years that IBM's own products won't be able to support. As an example IBM semi announced that soon there will be dynamic storage(DASD) expansion and it will be done with volser (ex ABC001,ABC002 etc etc) ie adding volsers without having to update the ACS routines and DFDSS statements/ or DD JCL and this will apparently include DFHSM and any other product that needs Backup/restore generic volsers. DMS had this ability *LONG TIME AGO*. I don't see any issue about integrity with items like that (in fact our DASD boss when the MSS came in worked with the DMS people to support the concept of MVSGRP in DMS, IBM never did it. Ed On Oct 30, 2014, at 12:48 AM, Elardus Engelbrecht wrote: Ed Gould wrote: There are still quite a few items that DFDSS hasn't caught up with but thats a different horse to flog. Although I was reading an article about z/OS and there are a few things percolating up the like dynamic DASD and the like that will make us wonder why it took so long. Possible reasons: Backward compatibility issues? No business case to catch up? Integrity issues? Groete / Greetings Elardus Engelbrecht -- 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 -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION - EXPIRATION OF DSN
On Oct 30, 2014, at 5:33 PM, Mike Schwab wrote: We put unused volsers into SMS Storage groups then init actual volumes when more space is needed. --SNIP--- You still have to put them in your ACS routines and DFDSS won't allow patterning of volsers (AFAIK). ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION - EXPIRATION OF DSN
Correct. We put in a range of volumes. Example LGA 001-099. We then initialize a few of the volumes, say LGA 001-009. When these volumes get to 90% full, and allocations fail, we init volume LGA 010. Once online it probably will be used for over half the allocations until it becomes fairly balanced. On Thu, Oct 30, 2014 at 6:26 PM, Ed Gould edgould1...@comcast.net wrote: On Oct 30, 2014, at 5:33 PM, Mike Schwab wrote: We put unused volsers into SMS Storage groups then init actual volumes when more space is needed. --SNIP--- You still have to put them in your ACS routines and DFDSS won't allow patterning of volsers (AFAIK). ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
DFHSM QUESTION - EXPIRATION OF DSN
Good Morning Gentle Readers, I have a question about the expiration of a dsn by HSM. The rule says the following : Expiration Attributes Expire after Days Non-usage . : 540 Expire after Date/Days . . . . : NOLIMIT Retention Limit . . . . . . . : 0 However the Migration attributes are as follows: Migration Attributes Primary Days Non-usage . : 4 Level 1 Days Date/Days . : 7 Command or Auto Migrate . : BOTH My question is will HSM delete the dsn if it is NOT migrated? I think that the DSN needs to be migrated in order for HSM to delte the dsn. Could anybody confirm my comprehension or mis-comprehension should it be the case? Thanks. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION - EXPIRATION OF DSN
Esmie, You are posing an invalid situation for what you specified. After 4 days of non-usage, the dsn *will* migrate to ML1. After 7 more days of non-usage, it will migrate to ML2. After 540 days, it will expire. If the dataset has not migrated, numerous possible conditions exist: 1) it was referenced and therefore not eligible for migration because of usage. 2) it has not been backed up and is not eligible for migration 3) the volume is not eligible for migration and/or backup 4) something else is afoot that we are not aware of (premature ending of space management windows, etc.) Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of esmie moo Sent: Wednesday, October 29, 2014 7:32 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: DFHSM QUESTION - EXPIRATION OF DSN Good Morning Gentle Readers, I have a question about the expiration of a dsn by HSM. The rule says the following : Expiration Attributes Expire after Days Non-usage . : 540 Expire after Date/Days . . . . : NOLIMIT Retention Limit . . . . . . . : 0 However the Migration attributes are as follows: Migration Attributes Primary Days Non-usage . : 4 Level 1 Days Date/Days . : 7 Command or Auto Migrate . : BOTH My question is will HSM delete the dsn if it is NOT migrated? I think that the DSN needs to be migrated in order for HSM to delte the dsn. Could anybody confirm my comprehension or mis-comprehension should it be the case? Thanks. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION - EXPIRATION OF DSN
Bob, I understand that. Hoever, if the dsn is not migrated will it be deleted? Does the Expiration attributes take precdence over the Migration attributes/ On Wed, 10/29/14, Richards, Robert B. robert.richa...@opm.gov wrote: Subject: Re: DFHSM QUESTION - EXPIRATION OF DSN To: IBM-MAIN@LISTSERV.UA.EDU Received: Wednesday, October 29, 2014, 7:53 AM Esmie, You are posing an invalid situation for what you specified. After 4 days of non-usage, the dsn *will* migrate to ML1. After 7 more days of non-usage, it will migrate to ML2. After 540 days, it will expire. If the dataset has not migrated, numerous possible conditions exist: 1) it was referenced and therefore not eligible for migration because of usage. 2) it has not been backed up and is not eligible for migration 3) the volume is not eligible for migration and/or backup 4) something else is afoot that we are not aware of (premature ending of space management windows, etc.) Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of esmie moo Sent: Wednesday, October 29, 2014 7:32 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: DFHSM QUESTION - EXPIRATION OF DSN Good Morning Gentle Readers, I have a question about the expiration of a dsn by HSM. The rule says the following : Expiration Attributes Expire after Days Non-usage . : 540 Expire after Date/Days . . . . : NOLIMIT Retention Limit . . . . . . . : 0 However the Migration attributes are as follows: Migration Attributes Primary Days Non-usage . : 4 Level 1 Days Date/Days . : 7 Command or Auto Migrate . : BOTH My question is will HSM delete the dsn if it is NOT migrated? I think that the DSN needs to be migrated in order for HSM to delte the dsn. Could anybody confirm my comprehension or mis-comprehension should it be the case? Thanks. -- 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
Re: DFHSM QUESTION - EXPIRATION OF DSN
If the dsn is not migrated because migration is broken for that dataset *and* 540 days go by, then YES, it will expire if it has not been referenced. For 540 days. It is not a matter of precedence. An exception to all this is threshold mangement. If HSM doesn't think the volume meets criteria to qualify for PSM or SSM, then a dataset can sit on a primary volume forever. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of esmie moo Sent: Wednesday, October 29, 2014 8:24 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DFHSM QUESTION - EXPIRATION OF DSN Bob, I understand that. Hoever, if the dsn is not migrated will it be deleted? Does the Expiration attributes take precdence over the Migration attributes/ On Wed, 10/29/14, Richards, Robert B. robert.richa...@opm.gov wrote: Subject: Re: DFHSM QUESTION - EXPIRATION OF DSN To: IBM-MAIN@LISTSERV.UA.EDU Received: Wednesday, October 29, 2014, 7:53 AM Esmie, You are posing an invalid situation for what you specified. After 4 days of non-usage, the dsn *will* migrate to ML1. After 7 more days of non-usage, it will migrate to ML2. After 540 days, it will expire. If the dataset has not migrated, numerous possible conditions exist: 1) it was referenced and therefore not eligible for migration because of usage. 2) it has not been backed up and is not eligible for migration 3) the volume is not eligible for migration and/or backup 4) something else is afoot that we are not aware of (premature ending of space management windows, etc.) Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of esmie moo Sent: Wednesday, October 29, 2014 7:32 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: DFHSM QUESTION - EXPIRATION OF DSN Good Morning Gentle Readers, I have a question about the expiration of a dsn by HSM. The rule says the following : Expiration Attributes Expire after Days Non-usage . : 540 Expire after Date/Days . . . . : NOLIMIT Retention Limit . . . . . . . : 0 However the Migration attributes are as follows: Migration Attributes Primary Days Non-usage . : 4 Level 1 Days Date/Days . : 7 Command or Auto Migrate . : BOTH My question is will HSM delete the dsn if it is NOT migrated? I think that the DSN needs to be migrated in order for HSM to delte the dsn. Could anybody confirm my comprehension or mis-comprehension should it be the case? Thanks. -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION - EXPIRATION OF DSN
Bob, Thanks very much for your help. On Wed, 10/29/14, Richards, Robert B. robert.richa...@opm.gov wrote: Subject: Re: DFHSM QUESTION - EXPIRATION OF DSN To: IBM-MAIN@LISTSERV.UA.EDU Received: Wednesday, October 29, 2014, 8:50 AM If the dsn is not migrated because migration is broken for that dataset *and* 540 days go by, then YES, it will expire if it has not been referenced. For 540 days. It is not a matter of precedence. An exception to all this is threshold mangement. If HSM doesn't think the volume meets criteria to qualify for PSM or SSM, then a dataset can sit on a primary volume forever. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of esmie moo Sent: Wednesday, October 29, 2014 8:24 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DFHSM QUESTION - EXPIRATION OF DSN Bob, I understand that. Hoever, if the dsn is not migrated will it be deleted? Does the Expiration attributes take precdence over the Migration attributes/ On Wed, 10/29/14, Richards, Robert B. robert.richa...@opm.gov wrote: Subject: Re: DFHSM QUESTION - EXPIRATION OF DSN To: IBM-MAIN@LISTSERV.UA.EDU Received: Wednesday, October 29, 2014, 7:53 AM Esmie, You are posing an invalid situation for what you specified. After 4 days of non-usage, the dsn *will* migrate to ML1. After 7 more days of non-usage, it will migrate to ML2. After 540 days, it will expire. If the dataset has not migrated, numerous possible conditions exist: 1) it was referenced and therefore not eligible for migration because of usage. 2) it has not been backed up and is not eligible for migration 3) the volume is not eligible for migration and/or backup 4) something else is afoot that we are not aware of (premature ending of space management windows, etc.) Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of esmie moo Sent: Wednesday, October 29, 2014 7:32 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: DFHSM QUESTION - EXPIRATION OF DSN Good Morning Gentle Readers, I have a question about the expiration of a dsn by HSM. The rule says the following : Expiration Attributes Expire after Days Non-usage . : 540 Expire after Date/Days . . . . : NOLIMIT Retention Limit . . . . . . . : 0 However the Migration attributes are as follows: Migration Attributes Primary Days Non-usage . : 4 Level 1 Days Date/Days . : 7 Command or Auto Migrate . : BOTH My question is will HSM delete the dsn if it is NOT migrated? I think that the DSN needs to be migrated in order for HSM to delte the dsn. Could anybody confirm my comprehension or mis-comprehension should it be the case? Thanks. -- 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 -- 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
Re: DFHSM QUESTION - EXPIRATION OF DSN
Bob, We have a similar situation at our end. There is a dsn with the following atribute: Expire after Days Non-usage . : 365. Migration Attributes Primary Days Non-usage . : 2 Level 1 Days Date/Days . : 10 Command or Auto Migrate . : BOTH What if the DSN is empty and not backed (because HSM doesn't backup empty dsns) would the dsn be deleted after 365 days non-usage / non referenced? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION - EXPIRATION OF DSN
snip After 4 days of non-usage, the dsn *will* migrate to ML1. After 7 more days of non-usage, it will migrate to ML2. After 540 days, it will expire. /snip Minor correction: After 4 days of non-usage, the dsn *will* migrate to ML1. After 7 days of non-usage, it will migrate to ML2. If not already migrated to ML1, it will migrate directly to ML2. After 540 days, it will expire. HTH, snip After 4 days of non-usage, the dsn *will* migrate to ML1. After 7 more days of non-usage, it will migrate to ML2. After 540 days, it will expire. If the dataset has not migrated, numerous possible conditions exist: 1) it was referenced and therefore not eligible for migration because of usage. 2) it has not been backed up and is not eligible for migration 3) the volume is not eligible for migration and/or backup 4) something else is afoot that we are not aware of (premature ending of space management windows, etc.) Bob snipage I have a question about the expiration of a dsn by HSM. The rule says the following : Expiration Attributes Expire after Days Non-usage . : 540 Expire after Date/Days . . . . : NOLIMIT Retention Limit . . . . . . . : 0 However the Migration attributes are as follows: Migration Attributes Primary Days Non-usage . : 4 Level 1 Days Date/Days . : 7 Command or Auto Migrate . : BOTH My question is will HSM delete the dsn if it is NOT migrated? I think that the DSN needs to be migrated in order for HSM to delte the dsn. Could anybody confirm my comprehension or mis-comprehension should it be the case? /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION - EXPIRATION OF DSN
Yes. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Willie Bunter Sent: Wednesday, October 29, 2014 9:14 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DFHSM QUESTION - EXPIRATION OF DSN Bob, We have a similar situation at our end. There is a dsn with the following atribute: Expire after Days Non-usage . : 365. Migration Attributes Primary Days Non-usage . : 2 Level 1 Days Date/Days . : 10 Command or Auto Migrate . : BOTH What if the DSN is empty and not backed (because HSM doesn't backup empty dsns) would the dsn be deleted after 365 days non-usage / non referenced? -- 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
Re: DFHSM QUESTION - EXPIRATION OF DSN
There is a bit that can be set. Check the dfHSM Implementation Guide for Disabling delete-if-backed-up (DBU) processing for SMS data Sets snip We have a similar situation at our end. There is a dsn with the following atribute: Expire after Days Non-usage . : 365. Migration Attributes Primary Days Non-usage . : 2 Level 1 Days Date/Days . : 10 Command or Auto Migrate . : BOTH What if the DSN is empty and not backed (because HSM doesn't backup empty dsns) would the dsn be deleted after 365 days non-usage / non referenced? /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION - EXPIRATION OF DSN
Hmmm, will this thread ever *expires* ? :-D ;-D :-D Staller, Allan wrote: Minor correction: Thanks. After 4 days of non-usage, the dsn *will* migrate to ML1. After 7 days of non-usage, it will migrate to ML2. If not already migrated to ML1, it will migrate directly to ML2. After 540 days, it will expire. Just a little question if you don't mind, please: 'expire' - does it means it is deleted and uncataloged? What about its backup(s)? Will it stays (with later HBDEL) or not? Ok, I will migrate back to under my rock... Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION - EXPIRATION OF DSN
Thank you Bob. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION - EXPIRATION OF DSN
Expire means deleted and uncatalogued. Backups (if any) are handled as described in the MGMTCLAS for the dataset. This is an entirely different set of processing. snip Staller, Allan wrote: Minor correction: Thanks. After 4 days of non-usage, the dsn *will* migrate to ML1. After 7 days of non-usage, it will migrate to ML2. If not already migrated to ML1, it will migrate directly to ML2. After 540 days, it will expire. Just a little question if you don't mind, please: 'expire' - does it means it is deleted and uncataloged? What about its backup(s)? Will it stays (with later HBDEL) or not? Ok, I will migrate back to under my rock... Groete / Greetings Elardus Engelbrecht /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION - EXPIRATION OF DSN
Staller, Allan wrote: Expire means deleted and uncatalogued. Thanks. That will settle some burning issues with my storage admin who think it is RACF, but I could prove it is HSM. Backups (if any) are handled as described in the MGMTCLAS for the dataset. This is an entirely different set of processing. Yes, thanks for refreshing my memory. One of my DBAs found out too late there were no HSM backups for his *important* datasets. He could restore from an old DFDSS backup his old versions, rebuild the members and he is back in business. Who said this? He who has backup, laugh the last and loudest! Much appreciated! Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION - EXPIRATION OF DSN
Thanks for the tip. This is very handy. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION - EXPIRATION OF DSN
HSM will happily back-up empty datasets. INVALID datasets are another matter. But, it is an easy matter to define a DEFAULT DATACLAS with DSORG=PS and never have another invalid dataset. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Willie Bunter Sent: Wednesday, October 29, 2014 6:14 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DFHSM QUESTION - EXPIRATION OF DSN Bob, We have a similar situation at our end. There is a dsn with the following atribute: Expire after Days Non-usage . : 365. Migration Attributes Primary Days Non-usage . : 2 Level 1 Days Date/Days . : 10 Command or Auto Migrate . : BOTH What if the DSN is empty and not backed (because HSM doesn't backup empty dsns) would the dsn be deleted after 365 days non-usage / non referenced? -- 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
Re: DFHSM QUESTION - EXPIRATION OF DSN
W dniu 2014-10-29 o 18:47, Gibney, Dave pisze: HSM will happily back-up empty datasets. INVALID datasets are another matter. But, it is an easy matter to define a DEFAULT DATACLAS with DSORG=PS and never have another invalid dataset. True. However I would prefer to have some feature to avoid creation of invalid datasets. I saw a lot of invalid datasets and none of them was really need by the creator. From the other hand such common issues gave me a lot of consultant work ;-) -- Radoslaw Skorupka Lodz, Poland --- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2014 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.696.052 złote. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION - EXPIRATION OF DSN
-Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of R.S. Sent: Wednesday, October 29, 2014 2:39 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DFHSM QUESTION - EXPIRATION OF DSN W dniu 2014-10-29 o 18:47, Gibney, Dave pisze: HSM will happily back-up empty datasets. INVALID datasets are another matter. But, it is an easy matter to define a DEFAULT DATACLAS with DSORG=PS and never have another invalid dataset. True. However I would prefer to have some feature to avoid creation of invalid datasets. I saw a lot of invalid datasets and none of them was really need by the creator. A side effect of doing this is that you can also eliminate MODLDSCB's for Generation datasets. From the other hand such common issues gave me a lot of consultant work ;-) -- Radoslaw Skorupka Lodz, Poland --- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526- 021-50-88. Według stanu na dzień 01.01.2014 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.696.052 złote. -- 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
