subject:"DFHSM QUESTION"

Should I ignore the ERR 40 when I run the AUDIT report?  


On Thu, 7/27/17, Lizette Koehler  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 
 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
 
 >  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 co

Re: DFHSM QUESTION

2017-07-27 Thread Brian Fraser

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 
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  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 
>  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 
>   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

Re: DFHSM QUESTION

2017-07-27 Thread Horne, Patti

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  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 
 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 
  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  >

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  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 
 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  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 
 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 
  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

2017-07-27 Thread Lizette Koehler

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  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 
>  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  &g

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  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 
 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 P

Re: DFHSM QUESTION

2017-07-27 Thread Horne, Patti

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  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 
 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.
 >  >
 >  >

 ---

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  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 
 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

2017-07-27 Thread Lizette Koehler

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  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

2017-07-27 Thread Carmen Vitullo

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  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  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

2017-07-27 Thread Lizette Koehler

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  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

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  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

2017-07-26 Thread Brian Fraser

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

2017-07-26 Thread retired mainframer

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

2017-07-26 Thread willie bunter

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  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

2017-07-26 Thread Lizette Koehler

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

2017-07-26 Thread willie bunter

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

2017-07-26 Thread willie bunter

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

2017-07-25 Thread Steve Smith

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  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 -

2017-07-25 Thread Lizette Koehler

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

2017-07-01 Thread willie bunter

Brian,

Thanks it worked.  That is what I am looking for.

Thanks 

On Fri, 6/30/17, Brian Fraser  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

2017-06-30 Thread Glenn Wilcock

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

2017-06-30 Thread Brian Fraser

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

2017-06-29 Thread willie bunter

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

2017-05-25 Thread Cafiero, Tobias M.

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." 
 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

2017-05-25 Thread esmie moo

Tobias,
Thanks for answering my question.

  From: "Cafiero, Tobias M." 
 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

2017-05-25 Thread Cafiero, Tobias M.

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

2017-05-25 Thread esmie moo

 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

2016-06-21 Thread Elardus Engelbrecht

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

2016-06-21 Thread willie bunter

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  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

2016-06-20 Thread Greg Shirey

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

2016-06-20 Thread Walter Davies

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 
> 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  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

2016-06-20 Thread Greg Shirey

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&DT=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

2016-06-20 Thread Lizette Koehler

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

2016-06-20 Thread Joel C. Ewing

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  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

2016-06-20 Thread Elardus Engelbrecht

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

2016-06-20 Thread Staller, Allan

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  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  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

2016-06-20 Thread retired mainframer

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

2016-06-20 Thread retired mainframer

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

2016-06-20 Thread Staller, Allan

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

2016-06-20 Thread Lizette Koehler

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

Re: DFHSM QUESTION : ARC0036E I/O INHIBITED FOR DFSMSHSM PROBLEM

2015-03-30 Thread Mike Schwab

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 : 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

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

2015-03-30 Thread Staller, Allan

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)"


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.


I doubt this is a new requirement. It has most likely been there for eons…


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

2015-03-30 Thread Staller, Allan

Yes. From the Fine Manual: "DFSMShsm Implementation and Customization Guide 
Version 2 Release 1   PP 41-42_ SC23-6869-01 (z/OS 2.1)"


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.


I doubt this is a new requirement. It has most likely been there for eons…


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

2015-03-30 Thread Lizette Koehler

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

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

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

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

2015-03-30 Thread Mike Schwab

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

2015-03-30 Thread Lizette Koehler

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

2015-03-30 Thread John McKown

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

DFHSM QUESTION : ARC0036E I/O INHIBITED FOR DFSMSHSM PROBLEM

2015-03-30 Thread willie bunter

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 - EXPIRATION OF DSN

2014-10-30 Thread Ed Gould


Mike:

Since I am not privy to exact announcements. It was clear that this  
would be dynamic in nature (no intervention other than the initial  
entry) . Myself I am not crazy about it in general, as I like volsers  
to show something of the nature of the contents (call me an old fart).
Also, I am not crazy about volsers "popping" into existence like the  
TARDIS I guess.


Ed

PS: I wonder if somehow IBM would relax the 6 character restriction?

On Oct 30, 2014, at 8:28 PM, Mike Schwab wrote:


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   
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


--
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

2014-10-30 Thread Mike Schwab

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  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

Re: DFHSM QUESTION - EXPIRATION OF DSN

2014-10-30 Thread Ed Gould


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

2014-10-30 Thread Mike Schwab

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  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

2014-10-30 Thread Ed Gould


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

2014-10-29 Thread Elardus Engelbrecht

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

Re: DFHSM QUESTION - EXPIRATION OF DSN

2014-10-29 Thread Ed Gould


On Oct 29, 2014, at 6:44 PM, Gibney, Dave wrote:
-- 
SNIP- 
-
  From the comment it could have been a dataset that didn't have a  
local

standard name.
I had a standard (DASD) that if it didn't have a valid dsorg it  
was deleted. I

regularly went through and deleted them.


25 years ago or more, so did I. With SMS, HSM and DSROG via a  
DEFAULT DATACLAS, I don't have to do this manual deletion of  
obvious errors.


Ahhh the luxury of SMS I could have done so as well, BTW it was not a  
manual effort but a production job that ran once a day (DMS) and it  
was fully automatic.


I disliked DMS for a lot of reasons but it did have a lot of features  
that it took DFDSS 25+ years to catch up up with 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.


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

2014-10-29 Thread z/OS scheduler

Esmie,

If I am you, I will do the following to find out for myself what the state
of affairs are.

I will create a dataset with

Expiration Attributes

   Expire after Days Non-usage  . : 10
   Expire after Date/Days . . . . : NOLIMIT
   Retention Limit  . . . . . . . : 0

Migration Attributes
  Primary Days Non-usage  . : 4
  Level 1 Days Date/Days  . : 7
  Command or Auto Migrate . : BOTH

And see what happens in the 10 days.
There is nothing like the satisfaction of trying it and finding the answer
yourself.

Greetings

James


2014-10-29 11:32 GMT+00:00 esmie moo :

> 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

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Ed Gould
> Sent: Wednesday, October 29, 2014 4:19 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: DFHSM QUESTION - EXPIRATION OF DSN
> 
> On Oct 29, 2014, at 6:14 PM, Gibney, Dave wrote:
> 
> >> -Original Message-
> >> From: IBM Mainframe Discussion List [mailto:IBM-
> m...@listserv.ua.edu]
> >> On Behalf Of Ed Gould
> >> Sent: Wednesday, October 29, 2014 4:04 PM
> >> To: IBM-MAIN@LISTSERV.UA.EDU
> >> Subject: Re: DFHSM QUESTION - EXPIRATION OF DSN
> >>
> >> On Oct 29, 2014, at 4:39 PM, R.S. wrote:
> >>
> >>> 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.
> >>>
> >>
> >> R.S.
> >>   Define invalid datasets, please.
> >
> > From HSM's perspective, they lack a DSORG. Most frequently created by
> > JCL where the program doesn't actually OPEN the output file for some
> > reason.
> > On non-SMS disk, they can also lack an EOF mark with older z/OS (or
> > perhaps OS390)
> >
> 
>   From the comment it could have been a dataset that didn't have a local
> standard name.
> I had a standard (DASD) that if it didn't have a valid dsorg it was deleted. I
> regularly went through and deleted them.

25 years ago or more, so did I. With SMS, HSM and DSROG via a DEFAULT DATACLAS, 
I don't have to do this manual deletion of obvious errors.

> 
> Ed
> 
> --
> 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

2014-10-29 Thread Ed Gould

On Oct 29, 2014, at 6:14 PM, Gibney, Dave wrote:

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On Behalf Of Ed Gould
Sent: Wednesday, October 29, 2014 4:04 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFHSM QUESTION - EXPIRATION OF DSN

On Oct 29, 2014, at 4:39 PM, R.S. wrote:

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.

R.S.
  Define invalid datasets, please.

From HSM's perspective, they lack a DSORG. Most frequently created  
by JCL where the program doesn't actually OPEN the output file for  
some reason.
On non-SMS disk, they can also lack an EOF mark with older z/OS (or  
perhaps OS390)

 From the comment it could have been a dataset that didn't have a  
local standard name.
I had a standard (DASD) that if it didn't have a valid dsorg it was  
deleted. I regularly went through and deleted them.

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

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Ed Gould
> Sent: Wednesday, October 29, 2014 4:04 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: DFHSM QUESTION - EXPIRATION OF DSN
> 
> On Oct 29, 2014, at 4:39 PM, R.S. wrote:
> 
> > 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.
> >
> 
> R.S.
>   Define invalid datasets, please.

>From HSM's perspective, they lack a DSORG. Most frequently created by JCL 
>where the program doesn't actually OPEN the output file for some reason.
On non-SMS disk, they can also lack an EOF mark with older z/OS (or perhaps 
OS390)

> 
> Ed
> 
> --
> 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

2014-10-29 Thread Ed Gould


On Oct 29, 2014, at 4:39 PM, R.S. wrote:


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.




R.S.
 Define invalid datasets, please.

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



> -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

Re: DFHSM QUESTION - EXPIRATION OF DSN

2014-10-29 Thread R.S.

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