Re: DFHSM QUESTION - RECALLING DSN TO ITS ORIGINAL VOLUME
willie bunter wrote: HSEND RECALL 'HESPDE02.ABACKUP.IMS1.HLIST' DFDSSOPTION(VOLCOUNT(ANY)) - FORCENONSMS VOLUME(SMTP17) - BYPASSACS(**) - NULLSTORCLAS Where is your UNIT(???) keyword? As documented, you MUST specify UNIT when specify VOLUME. (and vice versa too). I'm not sure about inlusion of BYPASSACS(**) and NULLSTORCLAS, because FORCENONSMS is sufficient, IMHO. I could not find them also in the manuals for HSEND RECALL command. 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 - RECALLING DSN TO ITS ORIGINAL VOLUME
Elardus, I tried your suggestion : HSEND RECALL 'HESPDE02..ABACKUP.IMS1.HLIST' DFDSSOPTION(VOLCOUNT(ANY)) - FORCENONSMS VOLUME(SMTP17) UNIT(3390) /* However it didn't work. According to the error message ADR472E 72 : During a non-SMS allocation, no target volumes were available and at least one output volume was not selected because it was SMS-managed. Programmer response : If you expect the target data set to be SMS-managed, ensure the ACS routine assigns a storage class or use the BYPASS ACS and STORCLAS keywords to force the data set to be SMS-managed. I tried the BYPASS ACS however I was using NULLSTORCLAS. Could that be my error? PAGE 0001 5695-DF175 DFSMSDSS V1R13.0 DATA SET SERVICES 2013.081 09:20 ADR035I (SCH)-PRIME(06), INSTALLATION EXIT ALTERED BYPASS FAC CLASS CHK DEFAULT TO YES RESTORE INDDNAME(SYS00115) CAT - BYPASSACS(HESPDE02.ABACKUP.IMS1.HLIST ) - NULLMGMTCLAS NULLSTORCLAS - OUTDYNAM((SMTP17)) - REBLOCK(HESPDE02.ABACKUP.IMS1.HLIST ) - VOLCOUNT(ANY) - FORCECP(0) - DATASET(INCLUDE(HESPDE02.ABACKUP.IMS1.HLIST )) ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO COMMAND 'RESTORE ' ADR109I (R/I)-RI01 (01), 2013.081 09:20:11 INITIAL SCAN OF USER CONTROL STATEME NTS COMPLETED ADR050I (001)-PRIME(01), DFSMSDSS INVOKED VIA APPLICATION INTERFACE ADR016I (001)-PRIME(01), RACF LOGGING OPTION IN EFFECT FOR THIS TASK ADR006I (001)-STEND(01), 2013.081 09:20:11 EXECUTION BEGINS ADR780I (001)-TDDS (01), THE INPUT DUMP DATA SET BEING PROCESSED IS IN LOGICAL DATA SET FORMAT AND WAS CREATED BY DFSMSDSS VERSION 1 RELEASE 13 MODIFICATION LEVEL 0 ON 2013.079 12:50:07 ADR472E (001)-NEWDS(06), UNABLE TO SELECT A TARGET VOLUME FOR DATA SET HESPDE02.A BACKUP.IMS1.HLIST, 72 ADR415W (001)-TDLOG(01), NO DATA SETS WERE COPIED, DUMPED, OR RESTORED FROM ANY VOLUME ADR480W (001)-TDLOG(01), THE FOLLOWING DATA SETS WERE NOT PROCESSED FROM THE LO GICALLY FORMATTED DUMP TAPE DUE TO ERRORS: HESPDE02.ABACKUP.IMS1.HLIST ADR006I (001)-STEND(02), 2013.081 09:20:11 EXECUTION ENDS ADR013I (001)-CLTSK(01), 2013.081 09:20:11 TASK COMPLETED WITH RETURN CODE 0008 ADR012I (SCH)-DSSU (01), 2013.081 09:20:11 DFSMSDSS PROCESSING COMPLETE. HIGHES T RETURN CODE IS 0008 FROM: TASK 001 ARC1001I HESPDE02.ABACKUP.IMS1.HLIST RECALL FAILED, RC=0069, REAS=0472 ARC1169I RECALL/RECOVER FAILED DUE TO AN ERROR IN DFDSS From: Elardus Engelbrecht elardus.engelbre...@sita.co.za To: IBM-MAIN@LISTSERV.UA.EDU Sent: Friday, March 22, 2013 9:12:59 AM Subject: Re: DFHSM QUESTION - RECALLING DSN TO ITS ORIGINAL VOLUME willie bunter wrote: HSEND RECALL 'HESPDE02.ABACKUP.IMS1.HLIST' DFDSSOPTION(VOLCOUNT(ANY)) - FORCENONSMS VOLUME(SMTP17) - BYPASSACS(**) - NULLSTORCLAS Where is your UNIT(???) keyword? As documented, you MUST specify UNIT when specify VOLUME. (and vice versa too). I'm not sure about inlusion of BYPASSACS(**) and NULLSTORCLAS, because FORCENONSMS is sufficient, IMHO. I could not find them also in the manuals for HSEND RECALL command. 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 - RECALLING DSN TO ITS ORIGINAL VOLUME
If it is SMS managed, then the volume doesn't matter. You specified a specific volume, so I assumed a non-sms volume. On Fri, Mar 22, 2013 at 8:28 AM, willie bunter williebun...@yahoo.com wrote: Elardus, I tried your suggestion : HSEND RECALL 'HESPDE02..ABACKUP.IMS1.HLIST' DFDSSOPTION(VOLCOUNT(ANY)) - FORCENONSMS VOLUME(SMTP17) UNIT(3390) /* However it didn't work. According to the error message ADR472E 72 : During a non-SMS allocation, no target volumes were available and at least one output volume was not selected because it was SMS-managed. Programmer response : If you expect the target data set to be SMS-managed, ensure the ACS routine assigns a storage class or use the BYPASS ACS and STORCLAS keywords to force the data set to be SMS-managed. I tried the BYPASS ACS however I was using NULLSTORCLAS. Could that be my error? PAGE 0001 5695-DF175 DFSMSDSS V1R13.0 DATA SET SERVICES 2013.081 09:20 ADR035I (SCH)-PRIME(06), INSTALLATION EXIT ALTERED BYPASS FAC CLASS CHK DEFAULT TO YES RESTORE INDDNAME(SYS00115) CAT - BYPASSACS(HESPDE02.ABACKUP.IMS1.HLIST ) - NULLMGMTCLAS NULLSTORCLAS - OUTDYNAM((SMTP17)) - REBLOCK(HESPDE02.ABACKUP.IMS1.HLIST ) - VOLCOUNT(ANY) - FORCECP(0) - DATASET(INCLUDE(HESPDE02.ABACKUP.IMS1.HLIST )) ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO COMMAND 'RESTORE ' ADR109I (R/I)-RI01 (01), 2013.081 09:20:11 INITIAL SCAN OF USER CONTROL STATEME NTS COMPLETED ADR050I (001)-PRIME(01), DFSMSDSS INVOKED VIA APPLICATION INTERFACE ADR016I (001)-PRIME(01), RACF LOGGING OPTION IN EFFECT FOR THIS TASK ADR006I (001)-STEND(01), 2013.081 09:20:11 EXECUTION BEGINS ADR780I (001)-TDDS (01), THE INPUT DUMP DATA SET BEING PROCESSED IS IN LOGICAL DATA SET FORMAT AND WAS CREATED BY DFSMSDSS VERSION 1 RELEASE 13 MODIFICATION LEVEL 0 ON 2013.079 12:50:07 ADR472E (001)-NEWDS(06), UNABLE TO SELECT A TARGET VOLUME FOR DATA SET HESPDE02.A BACKUP.IMS1.HLIST, 72 ADR415W (001)-TDLOG(01), NO DATA SETS WERE COPIED, DUMPED, OR RESTORED FROM ANY VOLUME ADR480W (001)-TDLOG(01), THE FOLLOWING DATA SETS WERE NOT PROCESSED FROM THE LO GICALLY FORMATTED DUMP TAPE DUE TO ERRORS: HESPDE02.ABACKUP.IMS1.HLIST ADR006I (001)-STEND(02), 2013.081 09:20:11 EXECUTION ENDS ADR013I (001)-CLTSK(01), 2013.081 09:20:11 TASK COMPLETED WITH RETURN CODE 0008 ADR012I (SCH)-DSSU (01), 2013.081 09:20:11 DFSMSDSS PROCESSING COMPLETE. HIGHES T RETURN CODE IS 0008 FROM: TASK001 ARC1001I HESPDE02.ABACKUP.IMS1.HLIST RECALL FAILED, RC=0069, REAS=0472 ARC1169I RECALL/RECOVER FAILED DUE TO AN ERROR IN DFDSS From: Elardus Engelbrecht elardus.engelbre...@sita.co.za To: IBM-MAIN@LISTSERV.UA.EDU Sent: Friday, March 22, 2013 9:12:59 AM Subject: Re: DFHSM QUESTION - RECALLING DSN TO ITS ORIGINAL VOLUME willie bunter wrote: HSEND RECALL 'HESPDE02.ABACKUP.IMS1.HLIST' DFDSSOPTION(VOLCOUNT(ANY)) - FORCENONSMS VOLUME(SMTP17) - BYPASSACS(**) - NULLSTORCLAS Where is your UNIT(???) keyword? As documented, you MUST specify UNIT when specify VOLUME. (and vice versa too). I'm not sure about inlusion of BYPASSACS(**) and NULLSTORCLAS, because FORCENONSMS is sufficient, IMHO. I could not find them also in the manuals for HSEND RECALL command. 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 - RECALLING DSN TO ITS ORIGINAL VOLUME
The OS does not guarantee space, the phrase indicates that the user will guarantee there is space. That is, the normal operation for SMS is to locate space on an appropriate volume; guaranteed space subverts this normal process and uses the VOLSER value the user has coded. Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Thursday, March 21, 2013 4:28 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DFHSM QUESTION - RECALLING DSN TO ITS ORIGINAL VOLUME snip I'm pretty sure I don't grasp this Guaranteed Space concept. It sounds as if the OS guarantees space will be available on the original volume(s) for the data set to be recalled. To do this, it must hold that space in reserve, in which case there's precious little to gain by migrating. Or will it restore the data set to the original volume (but not necessarily the original extents) by forcing the migration of other data sets as needed? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION - RECALLING DSN TO ITS ORIGINAL VOLUME
Am I safe to assume that what I am trying to do cannot be done? From: Mike Schwab mike.a.sch...@gmail.com To: IBM-MAIN@LISTSERV.UA.EDU Sent: Friday, March 22, 2013 9:32:59 AM Subject: Re: DFHSM QUESTION - RECALLING DSN TO ITS ORIGINAL VOLUME If it is SMS managed, then the volume doesn't matter. You specified a specific volume, so I assumed a non-sms volume. On Fri, Mar 22, 2013 at 8:28 AM, willie bunter williebun...@yahoo.com wrote: Elardus, I tried your suggestion : HSEND RECALL 'HESPDE02..ABACKUP.IMS1.HLIST' DFDSSOPTION(VOLCOUNT(ANY)) - FORCENONSMS VOLUME(SMTP17) UNIT(3390) /* However it didn't work. According to the error message ADR472E 72 : During a non-SMS allocation, no target volumes were available and at least one output volume was not selected because it was SMS-managed. Programmer response : If you expect the target data set to be SMS-managed, ensure the ACS routine assigns a storage class or use the BYPASS ACS and STORCLAS keywords to force the data set to be SMS-managed. I tried the BYPASS ACS however I was using NULLSTORCLAS. Could that be my error? PAGE 0001 5695-DF175 DFSMSDSS V1R13.0 DATA SET SERVICES 2013.081 09:20 ADR035I (SCH)-PRIME(06), INSTALLATION EXIT ALTERED BYPASS FAC CLASS CHK DEFAULT TO YES RESTORE INDDNAME(SYS00115) CAT - BYPASSACS(HESPDE02.ABACKUP.IMS1.HLIST ) - NULLMGMTCLAS NULLSTORCLAS - OUTDYNAM((SMTP17)) - REBLOCK(HESPDE02.ABACKUP.IMS1.HLIST ) - VOLCOUNT(ANY) - FORCECP(0) - DATASET(INCLUDE(HESPDE02.ABACKUP.IMS1.HLIST )) ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO COMMAND 'RESTORE ' ADR109I (R/I)-RI01 (01), 2013.081 09:20:11 INITIAL SCAN OF USER CONTROL STATEME NTS COMPLETED ADR050I (001)-PRIME(01), DFSMSDSS INVOKED VIA APPLICATION INTERFACE ADR016I (001)-PRIME(01), RACF LOGGING OPTION IN EFFECT FOR THIS TASK ADR006I (001)-STEND(01), 2013.081 09:20:11 EXECUTION BEGINS ADR780I (001)-TDDS (01), THE INPUT DUMP DATA SET BEING PROCESSED IS IN LOGICAL DATA SET FORMAT AND WAS CREATED BY DFSMSDSS VERSION 1 RELEASE 13 MODIFICATION LEVEL 0 ON 2013.079 12:50:07 ADR472E (001)-NEWDS(06), UNABLE TO SELECT A TARGET VOLUME FOR DATA SET HESPDE02.A BACKUP.IMS1.HLIST, 72 ADR415W (001)-TDLOG(01), NO DATA SETS WERE COPIED, DUMPED, OR RESTORED FROM ANY VOLUME ADR480W (001)-TDLOG(01), THE FOLLOWING DATA SETS WERE NOT PROCESSED FROM THE LO GICALLY FORMATTED DUMP TAPE DUE TO ERRORS: HESPDE02.ABACKUP.IMS1.HLIST ADR006I (001)-STEND(02), 2013.081 09:20:11 EXECUTION ENDS ADR013I (001)-CLTSK(01), 2013.081 09:20:11 TASK COMPLETED WITH RETURN CODE 0008 ADR012I (SCH)-DSSU (01), 2013.081 09:20:11 DFSMSDSS PROCESSING COMPLETE. HIGHES T RETURN CODE IS 0008 FROM: TASK 001 ARC1001I HESPDE02.ABACKUP.IMS1.HLIST RECALL FAILED, RC=0069, REAS=0472 ARC1169I RECALL/RECOVER FAILED DUE TO AN ERROR IN DFDSS From: Elardus Engelbrecht elardus.engelbre...@sita.co.za To: IBM-MAIN@LISTSERV.UA.EDU Sent: Friday, March 22, 2013 9:12:59 AM Subject: Re: DFHSM QUESTION - RECALLING DSN TO ITS ORIGINAL VOLUME willie bunter wrote: HSEND RECALL 'HESPDE02.ABACKUP.IMS1.HLIST' DFDSSOPTION(VOLCOUNT(ANY)) - FORCENONSMS VOLUME(SMTP17) - BYPASSACS(**) - NULLSTORCLAS Where is your UNIT(???) keyword? As documented, you MUST specify UNIT when specify VOLUME. (and vice versa too). I'm not sure about inlusion of BYPASSACS(**) and NULLSTORCLAS, because FORCENONSMS is sufficient, IMHO. I could not find them also in the manuals for HSEND RECALL command. 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION - RECALLING DSN TO ITS ORIGINAL VOLUME - FUTHER QUESTION
Wilie, You are correct. Since the problem is with a PROCLIB, restoring it to the same Volume is not as relevant as restoring to the same TTRs. If it gets restored to the same volume, but not the same TTRs, then you will still need to open/close proclibs in-order to get JES2 to refresh its information. For any other type of dataset, it should work. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of willie bunter Sent: Friday, March 22, 2013 5:57 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DFHSM QUESTION - RECALLING DSN TO ITS ORIGINAL VOLUME - FUTHER QUESTION John, According to Lizette's post it won't make a difference. Lizette please correct me if I misspoke: JES2 requires that the data map to the same TTR. So the proclib could be moved, but the tracks not over written. So the TTRs would still be valid for that proc. The minute the space is reused, is when JES2 will provide the I/O error. So it is not use going back to the same volume, but to the exact same TTR placements. From: John Dawes jhn_da...@yahoo.com.au To: IBM-MAIN@LISTSERV.UA.EDU Sent: Friday, March 22, 2013 8:08:15 AM Subject: Re: DFHSM QUESTION - RECALLING DSN TO ITS ORIGINAL VOLUME - FUTHER QUESTION G'day, In further to Willie's post, what if the dsn was recalled to the proper or original volume, must the JES2 proc need to be refreshed because the dsn may not have been placed on the same track or cylinder? From: Walter Marguccio walter_marguc...@yahoo.com To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, 21 March 2013 4:54 PM Subject: Re: DFHSM QUESTION - RECALLING DSN TO ITS ORIGINAL VOLUME From: willie bunter williebun...@yahoo.com I checked the SC. It doesn't have Guaranteed Space. Willie, if the SC doesn't have Guaranteed Space, then there is no way to force hsm to recall a migrated dataset on the original volume (at least that I'm aware of). If your dataset would have had a SC with Guaranteed Space = Yes, then hsm would have recalled it on the same volume where it was allocated. And if the original volume is not there (for whatever reason) the recall would fail. If you have datasets with such a SC, you can test this yourself. Walter Marguccio z/OS Systems Programmer BELENUS LOB Informatic GmbH Munich - Germany -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION - RECALLING DSN TO ITS ORIGINAL VOLUME
From the message, it appears that the volume SMTP17 is an SMS volume but the command has FORCENONSMS. A file can be recalled to a non-sms volume..have done it several times. Regards, Hervey -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of willie bunter Sent: Friday, March 22, 2013 10:02 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DFHSM QUESTION - RECALLING DSN TO ITS ORIGINAL VOLUME Am I safe to assume that what I am trying to do cannot be done? From: Mike Schwab mike.a.sch...@gmail.com To: IBM-MAIN@LISTSERV.UA.EDU Sent: Friday, March 22, 2013 9:32:59 AM Subject: Re: DFHSM QUESTION - RECALLING DSN TO ITS ORIGINAL VOLUME If it is SMS managed, then the volume doesn't matter. You specified a specific volume, so I assumed a non-sms volume. On Fri, Mar 22, 2013 at 8:28 AM, willie bunter williebun...@yahoo.com wrote: Elardus, I tried your suggestion : HSEND RECALL 'HESPDE02..ABACKUP.IMS1.HLIST' DFDSSOPTION(VOLCOUNT(ANY)) - FORCENONSMS VOLUME(SMTP17) UNIT(3390) /* However it didn't work. According to the error message ADR472E 72 : During a non-SMS allocation, no target volumes were available and at least one output volume was not selected because it was SMS-managed. Programmer response : If you expect the target data set to be SMS-managed, ensure the ACS routine assigns a storage class or use the BYPASS ACS and STORCLAS keywords to force the data set to be SMS-managed. I tried the BYPASS ACS however I was using NULLSTORCLAS. Could that be my error? PAGE 0001 5695-DF175 DFSMSDSS V1R13.0 DATA SET SERVICES 2013.081 09:20 ADR035I (SCH)-PRIME(06), INSTALLATION EXIT ALTERED BYPASS FAC CLASS CHK DEFAULT TO YES RESTORE INDDNAME(SYS00115) CAT - BYPASSACS(HESPDE02.ABACKUP.IMS1.HLIST ) - NULLMGMTCLAS NULLSTORCLAS - OUTDYNAM((SMTP17)) - REBLOCK(HESPDE02.ABACKUP.IMS1.HLIST ) - VOLCOUNT(ANY) - FORCECP(0) - DATASET(INCLUDE(HESPDE02.ABACKUP.IMS1.HLIST )) ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO COMMAND 'RESTORE ' ADR109I (R/I)-RI01 (01), 2013.081 09:20:11 INITIAL SCAN OF USER CONTROL STATEME NTS COMPLETED ADR050I (001)-PRIME(01), DFSMSDSS INVOKED VIA APPLICATION INTERFACE ADR016I (001)-PRIME(01), RACF LOGGING OPTION IN EFFECT FOR THIS TASK ADR006I (001)-STEND(01), 2013.081 09:20:11 EXECUTION BEGINS ADR780I (001)-TDDS (01), THE INPUT DUMP DATA SET BEING PROCESSED IS IN LOGICAL DATA SET FORMAT AND WAS CREATED BY DFSMSDSS VERSION 1 RELEASE 13 MODIFICATION LEVEL 0 ON 2013.079 12:50:07 ADR472E (001)-NEWDS(06), UNABLE TO SELECT A TARGET VOLUME FOR DATA SET HESPDE02.A BACKUP.IMS1.HLIST, 72 ADR415W (001)-TDLOG(01), NO DATA SETS WERE COPIED, DUMPED, OR RESTORED FROM ANY VOLUME ADR480W (001)-TDLOG(01), THE FOLLOWING DATA SETS WERE NOT PROCESSED FROM THE LO GICALLY FORMATTED DUMP TAPE DUE TO ERRORS: HESPDE02.ABACKUP.IMS1.HLIST ADR006I (001)-STEND(02), 2013.081 09:20:11 EXECUTION ENDS ADR013I (001)-CLTSK(01), 2013.081 09:20:11 TASK COMPLETED WITH RETURN CODE 0008 ADR012I (SCH)-DSSU (01), 2013.081 09:20:11 DFSMSDSS PROCESSING COMPLETE. HIGHES T RETURN CODE IS 0008 FROM: TASK 001 ARC1001I HESPDE02.ABACKUP.IMS1.HLIST RECALL FAILED, RC=0069, REAS=0472 ARC1169I RECALL/RECOVER FAILED DUE TO AN ERROR IN DFDSS From: Elardus Engelbrecht elardus.engelbre...@sita.co.za To: IBM-MAIN@LISTSERV.UA.EDU Sent: Friday, March 22, 2013 9:12:59 AM Subject: Re: DFHSM QUESTION - RECALLING DSN TO ITS ORIGINAL VOLUME willie bunter wrote: HSEND RECALL 'HESPDE02.ABACKUP.IMS1.HLIST' DFDSSOPTION(VOLCOUNT(ANY)) - FORCENONSMS VOLUME(SMTP17) - BYPASSACS(**) - NULLSTORCLAS Where is your UNIT(???) keyword? As documented, you MUST specify UNIT when specify VOLUME. (and vice versa too). I'm not sure about inlusion of BYPASSACS(**) and NULLSTORCLAS, because FORCENONSMS is sufficient, IMHO. I could not find them also in the manuals for HSEND RECALL command. 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 - RECALLING DSN TO ITS ORIGINAL VOLUME
Hervey, Thanks. I tried the FORENONSMS because it was suggested. From: Hervey Martinez hervey.marti...@custserv.com To: IBM-MAIN@LISTSERV.UA.EDU Sent: Friday, March 22, 2013 10:47:24 AM Subject: Re: DFHSM QUESTION - RECALLING DSN TO ITS ORIGINAL VOLUME From the message, it appears that the volume SMTP17 is an SMS volume but the command has FORCENONSMS. A file can be recalled to a non-sms volume..have done it several times. Regards, Hervey -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of willie bunter Sent: Friday, March 22, 2013 10:02 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DFHSM QUESTION - RECALLING DSN TO ITS ORIGINAL VOLUME Am I safe to assume that what I am trying to do cannot be done? From: Mike Schwab mike.a.sch...@gmail.com To: IBM-MAIN@LISTSERV.UA.EDU Sent: Friday, March 22, 2013 9:32:59 AM Subject: Re: DFHSM QUESTION - RECALLING DSN TO ITS ORIGINAL VOLUME If it is SMS managed, then the volume doesn't matter. You specified a specific volume, so I assumed a non-sms volume. On Fri, Mar 22, 2013 at 8:28 AM, willie bunter williebun...@yahoo.com wrote: Elardus, I tried your suggestion : HSEND RECALL 'HESPDE02..ABACKUP.IMS1.HLIST' DFDSSOPTION(VOLCOUNT(ANY)) - FORCENONSMS VOLUME(SMTP17) UNIT(3390) /* However it didn't work. According to the error message ADR472E 72 : During a non-SMS allocation, no target volumes were available and at least one output volume was not selected because it was SMS-managed. Programmer response : If you expect the target data set to be SMS-managed, ensure the ACS routine assigns a storage class or use the BYPASS ACS and STORCLAS keywords to force the data set to be SMS-managed. I tried the BYPASS ACS however I was using NULLSTORCLAS. Could that be my error? PAGE 0001 5695-DF175 DFSMSDSS V1R13.0 DATA SET SERVICES 2013.081 09:20 ADR035I (SCH)-PRIME(06), INSTALLATION EXIT ALTERED BYPASS FAC CLASS CHK DEFAULT TO YES RESTORE INDDNAME(SYS00115) CAT - BYPASSACS(HESPDE02.ABACKUP.IMS1.HLIST ) - NULLMGMTCLAS NULLSTORCLAS - OUTDYNAM((SMTP17)) - REBLOCK(HESPDE02.ABACKUP.IMS1.HLIST ) - VOLCOUNT(ANY) - FORCECP(0) - DATASET(INCLUDE(HESPDE02.ABACKUP.IMS1.HLIST )) ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO COMMAND 'RESTORE ' ADR109I (R/I)-RI01 (01), 2013.081 09:20:11 INITIAL SCAN OF USER CONTROL STATEME NTS COMPLETED ADR050I (001)-PRIME(01), DFSMSDSS INVOKED VIA APPLICATION INTERFACE ADR016I (001)-PRIME(01), RACF LOGGING OPTION IN EFFECT FOR THIS TASK ADR006I (001)-STEND(01), 2013.081 09:20:11 EXECUTION BEGINS ADR780I (001)-TDDS (01), THE INPUT DUMP DATA SET BEING PROCESSED IS IN LOGICAL DATA SET FORMAT AND WAS CREATED BY DFSMSDSS VERSION 1 RELEASE 13 MODIFICATION LEVEL 0 ON 2013.079 12:50:07 ADR472E (001)-NEWDS(06), UNABLE TO SELECT A TARGET VOLUME FOR DATA SET HESPDE02.A BACKUP.IMS1.HLIST, 72 ADR415W (001)-TDLOG(01), NO DATA SETS WERE COPIED, DUMPED, OR RESTORED FROM ANY VOLUME ADR480W (001)-TDLOG(01), THE FOLLOWING DATA SETS WERE NOT PROCESSED FROM THE LO GICALLY FORMATTED DUMP TAPE DUE TO ERRORS: HESPDE02.ABACKUP.IMS1.HLIST ADR006I (001)-STEND(02), 2013.081 09:20:11 EXECUTION ENDS ADR013I (001)-CLTSK(01), 2013.081 09:20:11 TASK COMPLETED WITH RETURN CODE 0008 ADR012I (SCH)-DSSU (01), 2013.081 09:20:11 DFSMSDSS PROCESSING COMPLETE. HIGHES T RETURN CODE IS 0008 FROM: TASK 001 ARC1001I HESPDE02.ABACKUP.IMS1.HLIST RECALL FAILED, RC=0069, REAS=0472 ARC1169I RECALL/RECOVER FAILED DUE TO AN ERROR IN DFDSS From: Elardus Engelbrecht elardus.engelbre...@sita.co.za To: IBM-MAIN@LISTSERV.UA.EDU Sent: Friday, March 22, 2013 9:12:59 AM Subject: Re: DFHSM QUESTION - RECALLING DSN TO ITS ORIGINAL VOLUME willie bunter wrote: HSEND RECALL 'HESPDE02.ABACKUP.IMS1.HLIST' DFDSSOPTION(VOLCOUNT(ANY)) - FORCENONSMS VOLUME(SMTP17) - BYPASSACS(**) - NULLSTORCLAS Where is your UNIT(???) keyword? As documented, you MUST specify UNIT when specify VOLUME. (and vice versa too). I'm not sure about inlusion of BYPASSACS(**) and NULLSTORCLAS, because FORCENONSMS is sufficient, IMHO. I could not find them also in the manuals for HSEND RECALL command. 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
Re: DFHSM QUESTION - RECALLING DSN TO ITS ORIGINAL VOLUME
Noticing that this thread continues to focus on how to make a recall of the PROCLIB dataset work, I think it should be re-emphasized that any managed data set that is essential to the proper functioning of JES2, or any other critical started task at your site, should really be assigned a Management Class that inhibits migration. In the worst case scenario, you might find yourself in a catch-22 situation where you can't run something you need in order to get DFHSM functional because the rarely-used but required datasets are migrated, or the required ML1/ML2 volume is unavailable. In the best case, start up of some important address space may be delayed because a RECALL must first complete. Long-running address spaces that have JCL references to data sets that are never opened, or which only open some datasets once at start up, have migration exposures even if they are rarely inactive. We have been mildly burned in the past by significant delays to production CICS startup when the CICS down period just happened to overlap with HSM daily migration processing. Last used dates on datasets are updated at OPEN time, so when a CICS that only OPENs a required dataset once at startup is terminated after running for several weeks, that dataset may immediately be eligible for migration if daily migration is active. If the dataset is large, you can end up having to wait many minutes for both migration and subsequent recall to complete before the critical address space can restart. Should that period when the critical datasets are migrated also overlap DR point-in-time backups, you may also be leaving an additional exposure for Disaster Recovery, as during DR, DFHSM RECALL functionality may be delayed for an extended time while switching DFHSM to use DR alternate tape volumes, or some very recent ML2 volumes might be unavailable. You should check all critical address spaces, not just JES2, for managed datasets that should be protected by a no-migrate MgmtClass, and don't forget to include special datasets that might be required just for DR, or which are essential for running TSO/ISPF sessions of personnel who need to manage the early phases of actual DR or DR testing. We preferred to handle such dataset special cases by using DFP fields in dataset and group RACF profiles to assign a special Management Class via RACF, as that was much simpler to change (and less likely to break everything) than trying to maintain those exceptions in the SMS ACS routines. Joel C Ewing On 03/21/2013 11:27 AM, willie bunter wrote: Lizette, Thanks for the advice. I have taken note of the suggestions and hopefully I can have the changes done. Thanks. From: Lizette Koehler stars...@mindspring.com To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, March 21, 2013 12:18:03 PM Subject: Re: DFHSM QUESTION - RECALLING DSN TO ITS ORIGINAL VOLUME Willie, As others have pointed out, a couple of solutions. 1) Use USER PROCLIB datasets in JCLLIB datasets in your JCL. 2) Have a NOMIG class in SMS that will not migrate the dataset. PROCLIBs are touchy to JES2. I typically have my users code JCLLIB statements, and I think the job will wait for the RECALL if they were migrated. I can test that later. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of willie bunter Sent: Thursday, March 21, 2013 8:22 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: DFHSM QUESTION - RECALLING DSN TO ITS ORIGINAL VOLUME Good Day Readers, Several jobs are failing due to the following : IEC143I 213-2C,IFG0194D,JES2,JES2,SYS00035- 0009,9987,SMTP01,SYS2.HESP.BPROCLIB IEF196I IEC143I 213-2C,IFG0194D,JES2,JES2,SYS00035-0009,9987,SMTP01, IEF196I SYS2.HESP.BPROCLIB $HASP307 HESPD01 UNABLE TO OPEN PROC02 IEFC452I HESPD01 - JOB NOT RUN - JCL ERROR The problem was caused by the library which was migrated by HSM was recalled to another volume - SMTP03. The volumes in this Storage Group are SMS managed. I was able to get our MVS support folks to refresh the JES2 proc which rectified the problem (jobs were rerun successsfully). My question is should a problem of this nature occur again (pds migrated) how can I force HSM to recall the dsn to the original volume? In this case the dsn was recalled to another volume other than the orginal. Thanks. ... -- 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 - RECALLING DSN TO ITS ORIGINAL VOLUME
-Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Joel C. Ewing Sent: Friday, March 22, 2013 9:08 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DFHSM QUESTION - RECALLING DSN TO ITS ORIGINAL VOLUME Noticing that this thread continues to focus on how to make a recall of the PROCLIB dataset work, I think it should be re-emphasized that any managed data set that is essential to the proper functioning of JES2, or any other critical started task at your site, should really be assigned a Management Class that inhibits migration. In the worst case scenario, you might find yourself in a catch-22 situation where you can't run something you need in order to get DFHSM functional because the rarely-used but required datasets are migrated, or the required ML1/ML2 volume is unavailable. In the best case, start up of some important address space may be delayed because a RECALL must first complete. And to take it one step further, for datasets such as PROCLIBs where the using tasks thinks it knows the extents, you need to insure that the volumes containing such datasets are never defragged or the datasets are marked unmovable. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION - RECALLING DSN TO ITS ORIGINAL VOLUME
Hi Willie, its not as simple as getting it recalled to the same volume. I believe it's still the case that at jes startup it maps the dataset extents so you would need to get it back to exactly the same place(s) on the pack. The best solution is to make all your jes proclibs non migrateable. A simple alter mgmtclas to something suitable will do the job. Dave *** Good Day Readers, Several jobs are failing due to the following : IEC143I 213-2C,IFG0194D,JES2,JES2,SYS00035-0009,9987,SMTP01,SYS2.HESP.BPROCLIB IEF196I IEC143I 213-2C,IFG0194D,JES2,JES2,SYS00035-0009,9987,SMTP01, IEF196I SYS2.HESP.BPROCLIB $HASP307 HESPD01 UNABLE TO OPEN PROC02 IEFC452I HESPD01 - JOB NOT RUN - JCL ERROR The problem was caused by the library which was migrated by HSM was recalled to another volume - SMTP03. The volumes in this Storage Group are SMS managed. I was able to get our MVS support folks to refresh the JES2 proc which rectified the problem (jobs were rerun successsfully). My question is should a problem of this nature occur again (pds migrated) how can I force HSM to recall the dsn to the original volume? In this case the dsn was recalled to another volume other than the orginal. 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 - RECALLING DSN TO ITS ORIGINAL VOLUME
Devnie, Thanks for the tip. I will heed your advice. I will need to fill out lots of paper work to change the rule. Thanks. From: David Devine david.dev...@sse.com To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, March 21, 2013 11:37:15 AM Subject: Re: DFHSM QUESTION - RECALLING DSN TO ITS ORIGINAL VOLUME Hi Willie, its not as simple as getting it recalled to the same volume. I believe it's still the case that at jes startup it maps the dataset extents so you would need to get it back to exactly the same place(s) on the pack. The best solution is to make all your jes proclibs non migrateable. A simple alter mgmtclas to something suitable will do the job. Dave *** Good Day Readers, Several jobs are failing due to the following : IEC143I 213-2C,IFG0194D,JES2,JES2,SYS00035-0009,9987,SMTP01,SYS2.HESP.BPROCLIB IEF196I IEC143I 213-2C,IFG0194D,JES2,JES2,SYS00035-0009,9987,SMTP01, IEF196I SYS2.HESP.BPROCLIB $HASP307 HESPD01 UNABLE TO OPEN PROC02 IEFC452I HESPD01 - JOB NOT RUN - JCL ERROR The problem was caused by the library which was migrated by HSM was recalled to another volume - SMTP03. The volumes in this Storage Group are SMS managed. I was able to get our MVS support folks to refresh the JES2 proc which rectified the problem (jobs were rerun successsfully). My question is should a problem of this nature occur again (pds migrated) how can I force HSM to recall the dsn to the original volume? In this case the dsn was recalled to another volume other than the orginal. 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 - RECALLING DSN TO ITS ORIGINAL VOLUME
IIRC, After restoring the dataset to the same volume I believe you can submit a job with a /*JOBPARM PROCLIB=ddname where that's one of the proclib concatenation DD's in the JES2 proc. That will have JES reallocate the proclibs and you should be ok. Alan Schwartz ITO Global Services Operations and Engineering Xerox Business Services, LLC 1500 Towerview Rd. Eagan, MN. 55121-1346 p. 612.266.3150 m. 651.274.5819 f. 612.266.3196 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of David Devine Sent: Thursday, March 21, 2013 10:37 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DFHSM QUESTION - RECALLING DSN TO ITS ORIGINAL VOLUME Hi Willie, its not as simple as getting it recalled to the same volume. I believe it's still the case that at jes startup it maps the dataset extents so you would need to get it back to exactly the same place(s) on the pack. The best solution is to make all your jes proclibs non migrateable. A simple alter mgmtclas to something suitable will do the job. Dave *** Good Day Readers, Several jobs are failing due to the following : IEC143I 213-2C,IFG0194D,JES2,JES2,SYS00035-0009,9987,SMTP01,SYS2.HESP.BPROCLIB IEF196I IEC143I 213-2C,IFG0194D,JES2,JES2,SYS00035-0009,9987,SMTP01, IEF196I SYS2.HESP.BPROCLIB $HASP307 HESPD01 UNABLE TO OPEN PROC02 IEFC452I HESPD01 - JOB NOT RUN - JCL ERROR The problem was caused by the library which was migrated by HSM was recalled to another volume - SMTP03. The volumes in this Storage Group are SMS managed. I was able to get our MVS support folks to refresh the JES2 proc which rectified the problem (jobs were rerun successsfully). My question is should a problem of this nature occur again (pds migrated) how can I force HSM to recall the dsn to the original volume? In this case the dsn was recalled to another volume other than the orginal. 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 - RECALLING DSN TO ITS ORIGINAL VOLUME
There are some datasets which shouldn't migrate (probably shouldn't be in SMS pools at all). JES proclibs are in this set of datasets that shouldn't migrate. :) -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of willie bunter Sent: Thursday, March 21, 2013 8:22 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: DFHSM QUESTION - RECALLING DSN TO ITS ORIGINAL VOLUME Good Day Readers, Several jobs are failing due to the following : IEC143I 213-2C,IFG0194D,JES2,JES2,SYS00035- 0009,9987,SMTP01,SYS2.HESP.BPROCLIB IEF196I IEC143I 213-2C,IFG0194D,JES2,JES2,SYS00035-0009,9987,SMTP01, IEF196I SYS2.HESP.BPROCLIB $HASP307 HESPD01 UNABLE TO OPEN PROC02 IEFC452I HESPD01 - JOB NOT RUN - JCL ERROR The problem was caused by the library which was migrated by HSM was recalled to another volume - SMTP03. The volumes in this Storage Group are SMS managed. I was able to get our MVS support folks to refresh the JES2 proc which rectified the problem (jobs were rerun successsfully). My question is should a problem of this nature occur again (pds migrated) how can I force HSM to recall the dsn to the original volume? In this case the dsn was recalled to another volume other than the orginal. 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 - RECALLING DSN TO ITS ORIGINAL VOLUME
Willie, As others have pointed out, a couple of solutions. 1) Use USER PROCLIB datasets in JCLLIB datasets in your JCL. 2) Have a NOMIG class in SMS that will not migrate the dataset. PROCLIBs are touchy to JES2. I typically have my users code JCLLIB statements, and I think the job will wait for the RECALL if they were migrated. I can test that later. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of willie bunter Sent: Thursday, March 21, 2013 8:22 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: DFHSM QUESTION - RECALLING DSN TO ITS ORIGINAL VOLUME Good Day Readers, Several jobs are failing due to the following : IEC143I 213-2C,IFG0194D,JES2,JES2,SYS00035- 0009,9987,SMTP01,SYS2.HESP.BPROCLIB IEF196I IEC143I 213-2C,IFG0194D,JES2,JES2,SYS00035-0009,9987,SMTP01, IEF196I SYS2.HESP.BPROCLIB $HASP307 HESPD01 UNABLE TO OPEN PROC02 IEFC452I HESPD01 - JOB NOT RUN - JCL ERROR The problem was caused by the library which was migrated by HSM was recalled to another volume - SMTP03. The volumes in this Storage Group are SMS managed. I was able to get our MVS support folks to refresh the JES2 proc which rectified the problem (jobs were rerun successsfully). My question is should a problem of this nature occur again (pds migrated) how can I force HSM to recall the dsn to the original volume? In this case the dsn was recalled to another volume other than the orginal. 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 - RECALLING DSN TO ITS ORIGINAL VOLUME
Walter, I checked the SC. It doesn't have Guaranteed Space. From: Walter Marguccio walter_marguc...@yahoo.com To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, March 21, 2013 11:34:52 AM Subject: Re: DFHSM QUESTION - RECALLING DSN TO ITS ORIGINAL VOLUME From: willie bunter williebun...@yahoo.com how can I force HSM to recall the dsn to the original volume? IIRC, if the datasets belongs to a SC whose Guaranteed Space = Yes, then hsm recalls the dataset on the same volume where the dataset originally was. Walter Marguccio z/OS Systems Programmer BELENUS LOB Informatic GmbH Munich - Germany -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION - RECALLING DSN TO ITS ORIGINAL VOLUME
Alan, That's the problem. Restoring the dsn on the same volume. From: Schwartz, Alan alan.schwa...@xerox.com To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, March 21, 2013 12:02:31 PM Subject: Re: DFHSM QUESTION - RECALLING DSN TO ITS ORIGINAL VOLUME IIRC, After restoring the dataset to the same volume I believe you can submit a job with a /*JOBPARM PROCLIB=ddname where that's one of the proclib concatenation DD's in the JES2 proc. That will have JES reallocate the proclibs and you should be ok. Alan Schwartz ITO Global Services Operations and Engineering Xerox Business Services, LLC 1500 Towerview Rd. Eagan, MN. 55121-1346 p. 612.266.3150 m. 651.274.5819 f. 612.266.3196 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of David Devine Sent: Thursday, March 21, 2013 10:37 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DFHSM QUESTION - RECALLING DSN TO ITS ORIGINAL VOLUME Hi Willie, its not as simple as getting it recalled to the same volume. I believe it's still the case that at jes startup it maps the dataset extents so you would need to get it back to exactly the same place(s) on the pack. The best solution is to make all your jes proclibs non migrateable. A simple alter mgmtclas to something suitable will do the job. Dave *** Good Day Readers, Several jobs are failing due to the following : IEC143I 213-2C,IFG0194D,JES2,JES2,SYS00035-0009,9987,SMTP01,SYS2.HESP.BPROCLIB IEF196I IEC143I 213-2C,IFG0194D,JES2,JES2,SYS00035-0009,9987,SMTP01, IEF196I SYS2.HESP.BPROCLIB $HASP307 HESPD01 UNABLE TO OPEN PROC02 IEFC452I HESPD01 - JOB NOT RUN - JCL ERROR The problem was caused by the library which was migrated by HSM was recalled to another volume - SMTP03. The volumes in this Storage Group are SMS managed. I was able to get our MVS support folks to refresh the JES2 proc which rectified the problem (jobs were rerun successsfully). My question is should a problem of this nature occur again (pds migrated) how can I force HSM to recall the dsn to the original volume? In this case the dsn was recalled to another volume other than the orginal. 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 - RECALLING DSN TO ITS ORIGINAL VOLUME
On Thu, 21 Mar 2013 10:37:15 -0500, David Devine wrote: its not as simple as getting it recalled to the same volume. I believe it's still the case that at jes startup it maps the dataset extents so you would need to get it back to exactly the same place(s) on the pack. The best solution is to make all your jes proclibs non migrateable. A simple alter mgmtclas to something suitable will do the job. Does this mean that HSM will migrate a data set while it's open? Eek! -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION - RECALLING DSN TO ITS ORIGINAL VOLUME
Lizette, Thanks for the advice. I have taken note of the suggestions and hopefully I can have the changes done. Thanks. From: Lizette Koehler stars...@mindspring.com To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, March 21, 2013 12:18:03 PM Subject: Re: DFHSM QUESTION - RECALLING DSN TO ITS ORIGINAL VOLUME Willie, As others have pointed out, a couple of solutions. 1) Use USER PROCLIB datasets in JCLLIB datasets in your JCL. 2) Have a NOMIG class in SMS that will not migrate the dataset. PROCLIBs are touchy to JES2. I typically have my users code JCLLIB statements, and I think the job will wait for the RECALL if they were migrated. I can test that later. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of willie bunter Sent: Thursday, March 21, 2013 8:22 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: DFHSM QUESTION - RECALLING DSN TO ITS ORIGINAL VOLUME Good Day Readers, Several jobs are failing due to the following : IEC143I 213-2C,IFG0194D,JES2,JES2,SYS00035- 0009,9987,SMTP01,SYS2.HESP.BPROCLIB IEF196I IEC143I 213-2C,IFG0194D,JES2,JES2,SYS00035-0009,9987,SMTP01, IEF196I SYS2.HESP.BPROCLIB $HASP307 HESPD01 UNABLE TO OPEN PROC02 IEFC452I HESPD01 - JOB NOT RUN - JCL ERROR The problem was caused by the library which was migrated by HSM was recalled to another volume - SMTP03. The volumes in this Storage Group are SMS managed. I was able to get our MVS support folks to refresh the JES2 proc which rectified the problem (jobs were rerun successsfully). My question is should a problem of this nature occur again (pds migrated) how can I force HSM to recall the dsn to the original volume? In this case the dsn was recalled to another volume other than the orginal. 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 - RECALLING DSN TO ITS ORIGINAL VOLUME
No. HSM will not migrate a file if it is open. IIRC, But proclibs have short usage. So it is possible the proclib is not used within the timeframe for migration is specified. JES2 does not always open PROCLIBs after the TTRs are read into JES2 ASID. Unless the environment has multiple PROCxx statements in JES2 that are constantly used, PROC01 PROC02 etc, then the dataset is not needed. JES2 already knows where the data is located on the dasd volume. An JES2 requires that the data map to the same TTR. So the proclib could be moved, but the tracks not over written. So the TTRs would still be valid for that proc. The minute the space is reused, is when JES2 will provide the I/O error. So it is not use going back to the same volume, but to the exact same TTR placements. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Thursday, March 21, 2013 9:23 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DFHSM QUESTION - RECALLING DSN TO ITS ORIGINAL VOLUME On Thu, 21 Mar 2013 10:37:15 -0500, David Devine wrote: its not as simple as getting it recalled to the same volume. I believe it's still the case that at jes startup it maps the dataset extents so you would need to get it back to exactly the same place(s) on the pack. The best solution is to make all your jes proclibs non migrateable. A simple alter mgmtclas to something suitable will do the job. Does this mean that HSM will migrate a data set while it's open? Eek! -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION - RECALLING DSN TO ITS ORIGINAL VOLUME
On Thu, 21 Mar 2013 09:31:31 -0700, Lizette Koehler wrote: No. HSM will not migrate a file if it is open. IIRC, But proclibs have short usage. So it is possible the proclib is not used within the timeframe for migration is specified. JES2 does not always open PROCLIBs after the TTRs are read into JES2 ASID. Unless the environment has multiple PROCxx statements in JES2 that are constantly used, PROC01 PROC02 etc, then the dataset is not needed. JES2 already knows where the data is located on the dasd volume. That breaks everything that ought to be a rule. JES2 should be a law-abiding citizen and hold the data set open. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION - RECALLING DSN TO ITS ORIGINAL VOLUME
Maybe so, but JES2/HASP has done this since day 1 (circa 1975). Many decisions made many moons ago are maintained for historical compatability. Those decisions would not necessarily be the same today. snip No. HSM will not migrate a file if it is open. IIRC, But proclibs have short usage. So it is possible the proclib is not used within the timeframe for migration is specified. JES2 does not always open PROCLIBs after the TTRs are read into JES2 ASID. Unless the environment has multiple PROCxx statements in JES2 that are constantly used, PROC01 PROC02 etc, then the dataset is not needed. JES2 already knows where the data is located on the dasd volume. That breaks everything that ought to be a rule. JES2 should be a law-abiding citizen and hold the data set open. -- gil /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION - RECALLING DSN TO ITS ORIGINAL VOLUME
Add FORCENONSMS UNIT(3390) VOL(volser) to the recall command. hlq.CLIST(HRECN) PROC 2 D V HSEND RECALL D VOL(V) UNIT(3390) FORCENON END /* PROC */ On Thu, Mar 21, 2013 at 10:21 AM, willie bunter williebun...@yahoo.com wrote: Good Day Readers, Several jobs are failing due to the following : IEC143I 213-2C,IFG0194D,JES2,JES2,SYS00035-0009,9987,SMTP01,SYS2.HESP.BPROCLIB IEF196I IEC143I 213-2C,IFG0194D,JES2,JES2,SYS00035-0009,9987,SMTP01, IEF196I SYS2.HESP.BPROCLIB $HASP307 HESPD01 UNABLE TO OPEN PROC02 IEFC452I HESPD01 - JOB NOT RUN - JCL ERROR The problem was caused by the library which was migrated by HSM was recalled to another volume - SMTP03. The volumes in this Storage Group are SMS managed. I was able to get our MVS support folks to refresh the JES2 proc which rectified the problem (jobs were rerun successsfully). My question is should a problem of this nature occur again (pds migrated) how can I force HSM to recall the dsn to the original volume? In this case the dsn was recalled to another volume other than the orginal. Thanks. -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION - RECALLING DSN TO ITS ORIGINAL VOLUME
Exactly. Think back to the days before you had multiple systems to change things from - or even back to before TSO/ISPF. For example, if you had to enlarge a proclib how could you submit a job to do so if it was in use by JES2 and JES2 was up in order for you to submit (read in) a job. You were able to make the change because the NODSI attribute for HASJES20 in the PPT for JES2. For example, allocate a new proclib, copy old to new, rename, then IPL or $PJES2,ABEND / restart. No dynamic proclib support back then either. But it was more than just NODSI, even if you tried to override it, it didn't matter because JES2 used S99NORES in the dynamic allocation. See a thread with subject JES2 DD Concatenation issue from 2008 with lots of information. Brian Peterson authored a requirement to allow DSI to be used for JES2 (HASJES20) in the PPT so PROCLIBs could be ENQed. I forgot when that happened, but I've been running that way for years. Paul, you even contributed to that thread with a job stream scenario to do the rename with the ENQs in place. Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ Maybe so, but JES2/HASP has done this since day 1 (circa 1975). Many decisions made many moons ago are maintained for historical compatability. Those decisions would not necessarily be the same today. snip No. HSM will not migrate a file if it is open. IIRC, But proclibs have short usage. So it is possible the proclib is not used within the timeframe for migration is specified. JES2 does not always open PROCLIBs after the TTRs are read into JES2 ASID. Unless the environment has multiple PROCxx statements in JES2 that are constantly used, PROC01 PROC02 etc, then the dataset is not needed. JES2 already knows where the data is located on the dasd volume. That breaks everything that ought to be a rule. JES2 should be a law-abiding citizen and hold the data set open. -- gil /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION - RECALLING DSN TO ITS ORIGINAL VOLUME
From: willie bunter williebun...@yahoo.com I checked the SC. It doesn't have Guaranteed Space. Willie, if the SC doesn't have Guaranteed Space, then there is no way to force hsm to recall a migrated dataset on the original volume (at least that I'm aware of). If your dataset would have had a SC with Guaranteed Space = Yes, then hsm would have recalled it on the same volume where it was allocated. And if the original volume is not there (for whatever reason) the recall would fail. If you have datasets with such a SC, you can test this yourself. Walter Marguccio z/OS Systems Programmer BELENUS LOB Informatic GmbH Munich - Germany -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION - RECALLING DSN TO ITS ORIGINAL VOLUME
On Thu, 21 Mar 2013 08:34:52 -0700, Walter Marguccio wrote: how can I force HSM to�recall the dsn to�the original volume?� IIRC, if the datasets belongs to a SC whose Guaranteed Space = Yes, then hsm recalls the dataset on the same volume where the dataset originally was.� I'm pretty sure I don't grasp this Guaranteed Space concept. It sounds as if the OS guarantees space will be available on the original volume(s) for the data set to be recalled. To do this, it must hold that space in reserve, in which case there's precious little to gain by migrating. Or will it restore the data set to the original volume (but not necessarily the original extents) by forcing the migration of other data sets as needed? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION - RECALLING DSN TO ITS ORIGINAL VOLUME
According to the official history: History In the mid-1960's a small group of IBM employees working at the Manned Spacecraft Center in Houston worked on a program called HASP (please see next section for How HASP got its name) which eventually was made available as an FDP. Its popularity and use expanded such that by February 1971 IBM released HASP II Version 3.0 as a Type III product with Class A support. This HASP ran as an optional extension to OS/MVT, performing the peripheral functions associated with job processing. In March of 1973 IBM released the SVS (i.e. OS/VS2 Release 1) operating system using a new version of HASP referred to as Version 4.0 HASP II Version 4.0 was not a System Control Program (SCP). It was still optionally available to replace OS/VS2 Release 1 readers and writers and continued to be a Class A service. With the availability of OS/VS2 Release 2 (MVS), HASP's name was changed to JES2. On Mar 21, 2013, at 3:56 PM, Bob Rutledge wrote: Day 1 was somewhat earlier than 1975. We installed HASP at CMU in the preceding decade. Bob Staller, Allan wrote: Maybe so, but JES2/HASP has done this since day 1 (circa 1975). -- 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
